Tassos Chatzithomaoglou <[email protected]> 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. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
