Make config change for uplink ports only

[Chris Augustine]

Hello.  

I've got about 150+ 2910al switches in my environment.  We recently enabled link up/down traps on all ports to satisfy a requirement for a NAC solution we are implementing.  Now, we are asked to disable the traps for uplink ports only.

My problem is that not all the uplinks are the same port.  I know I can use a variable and enter a range, but on some switches where we needed as many ports as possible, we used 45-47 for copper while 48 is the fiber.  I would also need to include A1 through B2 on some switches because of the interconnect ports we have connected.  So using a range would also turn off the traps on some ports where we don't want to turn it off.

Is there a way to target just the ports with a fiber GBIC in them or any other way IMC can handle this?  Or am I left to ssh'ing into each switch and turning it off manually?

Thanks

[LindsayHill]

There might be some ways of doing it, but they will involve a little bit of scripting.

Couple of questions:

* Do you have the eAPI license (either purchased the API license, or you have IMC Enterprise)?

* How can you identify an uplink port? If you were logged onto a switch, what would you do to identify which ports are used for uplinks?

[Chris Augustine]

Thanks for the reply.

A quick look shows that I'm running standard edition and I'm unauthorized for eAPI.

When I'm logged into a switch I could determine an uplink by a couple of ways.  Anything with a fiber gbic would be an uplink.  So I could do a "sh int br" and look for anything of type 1000SX or LX.  Or a "sh lldp info remote-device" would let me see the sys name of the switches at the other end.  All the switches would be named with a specific naming convention.

[LindsayHill]

You've got a few steps to it. First is identifying the interfaces you want to change. Second is writing code to make the changes you want. Third is stitching those together.

IMC Configuration Templates support checking the output of a command, and using that as success/fail criteria. Unfortunately it doesn't support quite the level of branching you'd need in order to implement this all as one step.

You could use an IMC Compliance Policy to check the output of Display Commands, and use the "Check & Get" function. That could run the equivalent of "show int br | include 1000[SL]X". That would give you a list of switches & interfaces, although it might not be super-simple to export as a table. 

You can write an IMC Configuration Template to run the equivalent of:

interface range X/Y - X/Z

  no snmp trap link-status

The beginning & end of the range could be passed in as parameters. Then when you run that template, you could just give it the start & end interface.  I'm guessing that there are some commonalities on your switches. So you might only need to do a couple of runs of that with a couple of different ranges set, and you'd cover most of your switches.  You could then manually clean up the remainders.  You'd use the Compliance Policy output to provide the lists of switches to use for each run.

It's a bit manual, but at least it's a little bit nicer than doing everything manually. Should cover the 80% case.

There are two alternatives I can think of:

• Do you have a consistent description on those uplink ports? Let's say all uplink ports have a consistent description of "UPLINK to switch ZZZZ X/Y."
  If you have a standard like that, you could write a Compliance Policy that looks at interface configurations. It would look for something like "description UPLINK .*" AND NOT "no snmp trap link-status".
  You could then give it a remediation action to run "snmp trap link-status".  This may actually be the simplest way if you have some sort of policy around descriptions. 
• Write your own expect scripts that take a list of switches, and for each switch, runs the equivalent of "foreach interface in `show int br | include 1000[SL]X';do int $interface; no snmp trap link-status;done"

If you had API access, there's a couple more programmatic ways of doing it, including even using the API to fix up your interface descriptions if they're not set right.