I have one PRI (out of three) that keeps failing for unknown reasons. I moved the circuit from one 6513 to a different 6513 and a different 6608 card and the circuit still fails. AT&T tells me there isn't any thing wrong with their end. I just watched the Total Rx RTP Lost Pkts counter go from 28 to 4294901788 in a matter of minutes. In addition I just reset the PRI by disconnecting it from the blade and then plugging it back in. The uptime counter shows 57873 seconds. I just reset it it not 300 seconds ago.
Thoughts? The IPTT book claims I can execute a number of ISDN commands on the 6513, but none of them seem to work on our models.
This first thing I would do (if possible) is to move one of the good PRI's to the problem interface on the 6608 (see if the problem follows or not) If the problem does not follow, then it is almost surely a problem with the Telco end. They always hate to admit any fault, so you need to prove your theory. We have been running PRI's on 6608's for almost 4 years and have never had any problems like this that could be blamed on the 6608.
I had AT&T out to re-wire the interface. While on site and with the PRI removed from the route group, they claimed they saw a number of errors comming from the Cisco gear.
They rewired the NIC and we changed out all the patch cables between the NIU and the 6608. We even moved the PRI from the 6608 on one 6513 to a different 6608 on a different 6513 and the problem went along. We're now wondering if we've exceeded the distance limitations on the NIC.
I cannot refrain from saying how much Rob is right about telcos not willing to admit problems with they circuits. Just two weeks ago a customer's PRI sat down for more than a week because telco insisted 'everything was fine' and asked for router replacement. They were checking only the physical layer and ignoring our complains and traces about their switch spitting out 'RNR' as crazy. Finally one less uneducated techinician went to check things on the switch and found that the card where our router was hosted was, oh, out of resources. They been switched to another card (a purely software operation) and thing went right immediately. I haven't heard an excuse from them, not to mention they had strict SLA terms!!!
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...