At 01:19 PM 2/26/02, s vermill wrote: >I don't think Cisco publishes what the hex codes mean after the "new serial >state = 0xnnnn" line. Anyone know?
I don't think so either. I sometimes think that Cisco's debug tools are really designed to help their internal QA people more than their customers. >I did find reference to something >generic that read "hardware has interrupted the software." You seem to have >a lot going on in that regard. Every four or five seconds on both ends of >the link you are experiencing one or more hardware interrupts. I was thinking all the changes were related to possibly troubleshooting in a panic, removing and replacing cables, etc. This isn't meant as a criticism. It's just a possible explanation for some of the weirdnesses. Another weirdness was that the router sent 18 keepalives with no ACK before giving up. It's supposed to only send 3. But I think it must have kept sending as the link flapped..... We need more data to help troubleshoot. Priscilla > As a last >resort, I would look into control lead options (no pulse, ignore dcd, etc). >Actually, the TAC would certainly have access to those code values so they >would be my true last resort. > >It's difficult to say which is the horse and which is the cart. Are your >routers not successfully exchanging keepalives because of the hardware >activity or is your hardware activity the result of not exchanging >keepalives? If I recall, dtr is supposed to pulse once, then again in 5 >seconds, and then every 30 seconds until the protocol comes back up. I have >no idea what dcd and dsr are supposed to do when running as a dce. > >Scott ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=36551&t=36423 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
