Range Sets and 'Overriding Behaviors'

[doug_schulze]

So it all starts with actual behaviors. As we all know is the ability to do a protocol selected discovery, maybe some old school load balancing or the Domain Awareness that was put out to pasture with Powershell discovery.

Now if you have every built a range set you've seen the field for overriding behavior..At first glance it made sense what it did.. It allowed you to chose a specific method (behavior) of discovering a IP set in a particular way. So say in one schedule you wanted two range sets.. One for Server IP's and the other for Routers.. Well I only want to scan ssh/wmi for the servers and only snmp but I wanted to run them at the same time, overriding behaviors should help me accomplish that right?

I'm in Singapore this month and my friends here have a problem.. They need to scan desktop segments at the same time as "normal" segments but only go after SNMP in their desktop world (Discovery find me the LAN printers, let an import take care of the desktops) and for everything else get it all... So I wanted to share and of course, get it documented on the wiki which is coming.. but followers here get the sneak preview…So here ya go..

The key for overriding behaviors to work;
-The schedule must have a behavior as well
-You cannot assign a specific mid server to a schedule AND have range sets trying to use an overriding behavior at the same time, the schedule will just use the one mid server which we all know follows the 'All' functionality..
-The overriding behaviors cannot share the same mid server, they must be configured with different mid servers or the system will merge both requests into one shazzam probe defeating the purpose…But don't worry LoadBalanced clusters will come in handy here, more on that later.

So in the scenario proved out today..

We have a LB cluster with 2 (or more) mid server applications.. But for ease of my typing I'm only going to reference MidA and MidB…

I created a range set for Server networks, range set for LAN Segments…
Created a behavior for ALL using MidA, behavior for SNMP calling MidB
Clustered MidA and MidB into one LoadBalanced group

Matched Servers range set to ALL Behavior (overriding behavior of course), SNMP only behavior to LAN segments range set

Applied both range sets to a single schedule… But now I'm sure you're asking what Behavior did I add to the schedule? (Since I just said it was required).. Well that's another cool part.. While I could have created a generic ALL behavior using MidA/B the overriding behaviors wouldn't have cared and would have done their job, so in this scenario if you just added any other IP ranges or sets, that generic 'All behavior' would have taken care of business..

But in this case I didn't want it.. I wanted to manage all IP Ranges to behaviors at the Range Set level and keep the schedule solely for time execution only… So I was able to create a blank behavior .. Meaning no functions or functionality definitions, just a record..Very Cool!

Applying that blank behavior to the schedule and Bingo! Everything runs like a champ, following the rules of the overriding behaviors as defined in the RangeSets.. Blank Behavior fills the required field for me and does nothing...

Now about the MidServer clusters…When the schedule runs ….MidA did the ALL behavior, MidB was tasked to scan just SNMP for the designated LAN IP ranges (as designed)..Now for all the subsequent probes that get triggered... load balancing kicks in and all mid servers in the cluster join in the work, be it for WMI, SSH or SNMP.. At this point I'm a happy guy because the primary key was 'don't do WMI protocol scan on the LAN segments' ...which was taken care of in the beginning!

So yes fair enough, there needs to be some modifications here (as I have brought up with development) ..meaning Overriding behaviors should not care if there is a specific mid server defined and overriding behaviors should be able to share the same mid server

I think ultimately, the Range set direction should take precedence over the schedule. And I have asked development to add the Location attribute (cmn_location) to a range set (as it is in the schedule) so it populates all devices in that range set with that value AND add company (core_company) to the schedule and Range Set so that as well auto populates ci's with that to help asset management gain some value from this too!..….

We'll see how that all goes but till then, I hope this helps you gain some additional functionality in your day to day Discovery work!

[Stijn Verhulst3]

Doug,

this is a really value adding article/post. Thank you and great job!

[gk13]

Hi Doug,

does that still works as described in the actual London release, or did developement pick up your idea that the ovveriding behaviour in the range set takes precedence ove whatever is defined in the schedule?

[Community Alums]

Hey Doug,

I came across this article and found it very informative.  I was wondering if you had any insight into how this fits into the New York release?  We recently upgraded and I haven't had time to do a deep dive into the release notes yet.

[David77]

An old post, but it helped me to FINALLY get one of my overriding behaviors to work. 
Thanks Doug!!!!