DX NetOps

Hi Guys,

On network devices, we have to disable SNMP  traps on the user interfaces via NCM. We can create tasks  with required parameters and user interface details ( refer below  screenshot)   to disable the SNMP  traps   

This we have to do one by one on  all the devices to disable the SNMP traps for user interfaces.

Any suggestions how to perform the same on bulk devices. ( Challenge is user interface range differs for other devices in estate.)

Has anyone done something similar via NCM ?

Appreciate your help and thoughts on this.

Thank you !

Sandeep Mazwar

Hi Guys,

Any thoughts on this ?

Regards,

Sandeep M

What do you mean by user interfaces?  Are there any interfaces where you do want the link up/down traps?  Is there anything that your interfaces would have in common in the configuration?  We've done a lot with NCM policies to manage interface configurations, but it's mostly been applying the same configuration to all of the interfaces on a switch.

For instance, to make sure that all of the interfaces on a Cisco switch are auto-negotiate speed and duplex, we set up a block policy with a start tag of (?m)^(interface (Fast|Gigabit|TenGigabit)Ethernet([0-9/]*)) and an end tag of !.  In that block, the configuration must not contain either regexp:

speed [0-9]*

duplex (half|full)

Hi Mathias,

User interface is the access port. Currently if a user disconnects from any interface, trap is getting generated resulting an alarm. We need to disable SNMP traps  for  all the ports except Uplink/ Downlink port.

Thanks !

Sandeep

That's basically the exact same policy that I described for our auto-negotiate policy.  We wanted to enable auto/auto for every interface that wasn't an uplink interface.  You might have to adjust the regexp for NX OS, but you'll probably find that something similar works.

Hi Mathias,

How to figure out that an interface is Uplink/Downlink or access port? Challenge is - on Network devices,  interface names are not standard and differs from one device to other.

So applying a common policy seems to be a challenge.

Thanks !

Sandeep Mazwar

Use a dynamic global collection based on searching for the X_ifAlias (0x13224). .You can find more information on that here. Run the command on the devices in that GC either manually or via attached policy.

But you can't apply an NCM policy to a GC of interfaces, it has to apply to the configuration.  You need some way to pick out the uplinks from the context of the configuration, whether that is the interface type or interface description or always using the same interfaces for the uplink.

I'm sure there's always a way to build a search within Spectrum that can filter out devices. That or have a script that builds the device list one by one and adds it to the specific GC that can be later used in a push NCM task.

The problem here isn't filtering devices, it's filtering interfaces.  Every switch will have an uplink.  The NCM policy needs to be able to change all of the interfaces that aren't uplink for all of the devices that it is applied to.  You can make a GC that will sort out those interfaces, but you can't only apply the NCM policy to those interfaces because NCM applies to device configurations.

Reconfiguring the switches to standard labeling is a challenge. Is there any workaround to get this done ?

I was thinking to pull the report from CABI for Uplink interfaces details and then  running upload task from NCM but the efforts  are not worth it seems.           

Isn't it easier to disable altogether snmp traps for all interfaces and then move on enabling on specific uplink interfaces?

I know NCM policies apply against devices, not interfaces. But if you create let's say 3 or 4 GC each one identifying a specific port used as uplink, you can send the same task (enable link status trap) for those devices that have that specific port. How many different uplink ports can there be?

In that case, I'm not sure what you can do.  Make a pass with NCM to fix the easy switches, reconfigure the switches to standardize and label as much as you can, and repeat until it all works?

I had the same issue and what I did is take the problem the other way around:

   How can I tell Spectrum to ignore the traps for those end users interfaces and alert me for the ones I care about?

Changing thousand of ports descriptions is hard to do, takes time and is error prone. Here is what I did:

1. Ensure the topology is good. Care needs to be taken in this step as it is the base of the automation that follows. When you look at the interface tab of a model, you will have another model listed in the "Device Connected" column
2. You need to create 2 global collections, 1 with the interfaces you want to know about and the other with all the other interfaces. This is the hard part as you want this to be dynamic so you don't have to edit it every time the topology changes. Here is my Search Criteria for the Policy_ManagedPorts collection. It will vary for you:
   
   
   You will also need one for unmanaged ports and you need to ensure that no port gets into both of these
3. Under Policy Manager, I created a Port Management policy with 2 rules:
   1. Priority 1, Managed that will change some of the port attributes to enable the monitoring and alerting of the ports that are important to you:
      
   2. Priority 2, Unmanaged that will do the exact opposite for the ports I do not want to be alerted for. This is telling Spectrum to ignore the up/down traps:
      

So as long as you keep the topology up to date, everything will update itself automatically.

I hope I understood you issue.

Herve Bouchard

I think you can use this, as long as you're not monitoring the CPE. If you're managing the CPEs also, then a 'Router link' or a 'Switch link' could identify a client device, one you'd not be interested in having notifications for.