[c-nsp] rancid and inventory with "^"

[Alexander Clouter]

Tassos Chatzithomaoglou <achatz at forthnet.gr> wrote:
>
> Is anyone having issues with rancid collecting the inventory when 
> there are "^" characters in the output?
> 
>   !NAME: "temperature outlet 9 ", DESCR: "module 9 outlet temperature Sensor"
>   !NAME: "temperature inlet 9 ",  DESCR: "module 9 inlet temperature Sensor"
> + !NAME: "temperature device-1 9 ", DESCR: "module 9 device-1 temperature Sensor"
> + !NAME: "temperature device-2 9 ", DESCR: "module 9 device-2 temperature Sensor"
>   !opv1^T^LB
>   !NAME: "Gi9/2",                 DESCR: "Transceiver Port Gi9/2"
>   !NAME: "Transceiver Port Container Gi9/2", DESCR: "Transceiver Port Container Gi9/2"
>   !NAME: "Transceiver Gi9/2",     DESCR: "Transceiver 1000BaseT Gi9/2"
> 
> We get daily differences (whole config parts are removed and readded), 
> because rancid believes that something has changed, although this is 
> not the case. Probably has to do with the expect code.
> 
Yep, and Cisco were not too helpful in trying to get this fixed, their 
suggestion was to stop rancid making an inventory request :-/

Their initial suggestion was to stop calling 'show inv raw' in rancid as 
it is more a command not to be used by Joe Public (meant to be for 
internal use/diagnostics apparently) and that I should not be using it.  
I asked for another command that would give me the serial numbers of the 
GBIC's, but turns out 'show inv raw' is the only way.

They then suggested that I sit at the console and manually check the 
output of 'show inv raw' and see if I notice anything in the logs when 
that occurs...  I pointed out their madness and handed them a perl 
script that polled every five minutes by SSHing in, yanking the config 
and storing it locally.  This meant you could quickly use the file size 
to see when it choked and run 'diff -u'.  This replicated the problem 
after an hour or so to which the response was that my script is 
corrupting the output and so was rancid.

It was suggested that unplugging and replugging in 'flapping' 
transceivers (the config changes for us were the gigabit slots on the 
SUP) could fix it, and it did for a short time...then it came back and 
would not go.  I got bored hounding after them and added it to the list 
of items as another reason to leave Cisco...</grumble>

Anyway, there was a thread here that kicked this off into life:

http://marc.info/?l=cisco-nsp&m=126780984709176&w=2

Offline, various people contacted me and the only common element we 
could find was that problem started with SXI3 and we all had a 10Gb line 
cards in our 6500's.  Cisco say they could not replicate the problem, 
although they have had several reports of it.

The problem was with me most of last month (and on and off for months 
before that), however it has been behaving recently; probably as our 
6509 has actually been turned off and on due to the regularity of power 
outages at my organisation.

My suggestion:
 * you probably will find some gigabit interfaces are being 
	persistently referred to, unplug and plug them back in
 * re-seat the line card :)
 * issue a 'reload' at some maintenance window and update to SXI4
 * completely power off the box and turn it on

A 'reload' seemed never to quite work for us, I got the impression that 
there is some dice rolling occurring when the box is powered on/reload'ed 
that decides if you will be plagued with this issue during the uptime of 
the box. :-/

Good hunting

-- 
Alexander Clouter
.sigmonster says: No one can put you down without your full cooperation.