[c-nsp] Monitoring Nexus 7000 platform

[Lincoln Dale]

On 18/08/2009, at 3:15 AM, Lee wrote:
> But that's assuming netconf/xml makes expect scripts a bit
> less dependent on the exact formatting of the output.  If upgrading
> the OS requires updating the xml definition in the script (eg. bump
> netconf:base:1.0 to netconf:base:1.1) .. well, seems like not such a
> big win.

those should not change - because its referring to Netconf version.
we also don't use "strict" checking on the input data, so while by the  
standard one SHOULD always specify the right namespace for things  
(e.g. looking up interface-related stats should always be for  
xmlns:if_manager), the reality is you could put something wrong there  
and it'll still currently work.

> The other example that came to mind was finding switch ports that
> haven't been used in however many days.  CatOS has the "show port
> usage" command; I haven't found the IOS equivalent yet but IOS
> switches do have the ifLastChange mib variable.

you can use ifLastChange in IF-MIB, or you can use the 'last flapped'  
info from CLI.

e.g. if you did a:
	switch# show interface | egrep '(^Eth|flapped)'
	Ethernet1/1 is down (suspended)
	  Last link flapped 3week(s) 5day(s)
	Ethernet1/2 is down (suspended)
	  Last link flapped 3week(s) 5day(s)
	Ethernet1/5 is down (Link not connected)
	  Last link flapped never
	Ethernet1/6 is down (Link not connected)
	  Last link flapped never

which i think will give you the equivalent of what you want (albeit  
perhaps not in a nice column display).

its forseeable you could use sed/awk/tr to columnize it if you wish.
(i've found an example of egrep / tr / sed below, just for giggles):
	switch# show interface | egrep '(^Eth|flapped)' | tr '\n' '\t' | sed  
's/Ether/\nEther/g'

	Ethernet1/1 is down (suspended)   Last link flapped 3week(s) 5day(s)
	Ethernet1/2 is down (suspended)   Last link flapped 3week(s) 5day(s)
	Ethernet1/5 is down (Link not connected)          Last link flapped  
never
	Ethernet1/6 is down (Link not connected)          Last link flapped  
never

the above assumes you're not disrupting the box (i.e. above stats  
won't survive across disruptive reloads), but since you can do code  
upgrades/downgrades nondisruptive with ISSU that shouldn't pose any  
issues.


>> its a bit heavyweight versus a flag, but assuming your script wanted
>> to do something intelligent based on said output, could be useful.
>
> Usually all I want to do is make sure everything's been saved before a
> scheduled power outage :)

another approach i've seen some people use is to automatically save a  
changed config after a period of time if its not already saved.
this can be accomplished off-box via scripts - or on-box via an event  
manager (EEM) applet.

doing automated 'config checkpoints' is also not a bad thing if this  
is a device getting a lot of config changes.
you can do that off-box via scripts (e.g. RANCID) or on-box via  
checkpoint functionality which gives you rollbacks too.


cheers,

lincoln.