Wouldn’t it be great if there was some attribute you could query and set on a device? Then you could automagically configure that device based on that attribute that you just set for fully automated device onboarding!
Welcome to Dynamic Device Attribute Pollers and Auto-Configuration Parameters! Rolls right off the tongue doesn’t it? Being able to automatically set a device attribute and then subsequent configurations based on the result can save a lot of administrative time during device onboarding. Automating the task also reduces human error (Did I remember to apply the right service checks?) and contributes to documenting additional device information.
Some example use cases can be to document OS versions using non standard OIDs, custom contact or location information, obtaining chassis types for proper sub-type polling, etc. Let’s take a journey to solve a very specific use case. Before departure, I’ll explain the two main areas mentioned above as a primer to level set all those reading this – Dynamic Device Attribute Pollers and Auto-Configuration Parameters.
Dynamic Device Attribute Pollers (simply attribute poller(s) going forward) are SNMP-based pollers that can query a device and store the value of the response we get. It is ideal to use a singleton OID, meaning your query brings back exactly one response. Attribute pollers are configured within a Device Type Administration page, where you can configure additional performance pollers as well. These SNMP OIDs typically end with a zero, for example sysName(.1.3.6.1.2.1.1.5.0) would come back with the system name. Our attribute pollers can query a table OID as well, meaning a call that brings back multiple responses. However, the Netreo platform will only record the first response in the Device Attribute.
Auto-Configuration Parameters (auto-config rules for short) are essentially “if this, then that” logic for automagically configuring devices during device onboarding. You can manually run a device through these rules by setting a schedule or triggering a re-discovery with the proper flag set. You can further automate device configuration by purchasing the AIOps: Autopilot add-on. With AIOps: Autopilot, Netreo automatically checks devices for auto-config rules compliance and assigns properties as configured. Getting into auto-config rules can be a blog all unto itself, so we’ll focus on just the parts to solve our needs.
Now that we’re primed, let’s discuss our needs. I need to make sure I have proper checks in place for my Switch Stack configurations as I’m onboarding my network infrastructure. I don’t have any logical naming convention or other logical way to know if a switch is in a stack. However, it’s crucial I monitor their stack statuses.
As I mentioned, using a singleton OID is typically preferred. So, one solution is performing an SNMP query for the vendor product ID and see if it’s a stack capable model. This tells us it can be in a switch stack, but doesn’t necessarily mean it is. Using this method could lead to false positives if we’re monitoring for stack members but none exist.
Enter cswStackPortOperStatus(.1.3.6.1.4.1.9.9.500.1.2.2.1.1); this SNMP query will return the statuses of the StackPorts, if they are up, down or forced down. Netreo, will record the first StackPort status. Based on this value, we can have our auto-config rule trigger and apply the appropriate property. In my example, Netreo is applying a Functional Group that is then applied to a Device Template that has my necessary Switch Stack Service Checks configured within.
To wrap this up, we were able to get a dynamic value that can be changed and updated with a simple re-poll of the device. When you’re onboarding devices for a large enterprise, automating device configuration is a huge time saver. Doing so also takes human assumption and error out of the equation, plus simplifies the life of your Netreo administrator. And don’t forget, you can always visit Netreo Documentation for detailed information on all Netreo features.
