Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

PRI Issue - Drops Everyday

Status
Not open for further replies.

msteeler

Technical User
Jan 29, 2003
324
US
Hello,

I have a site where we installed a PRI and it was working fine for a month with no issues. In the last 3 weeks the PRI drops at least once a day and I have to remote reload the router or if I'm not around have someone cycle the power on the router and this brings it back up. I've opened tickets with the teleco and they say the circuit is clean.

What can I look at on my side to see if there are issues? I've changed the cabling between the NIC and router. Below is what the interface looks like. It does have CRC and input errors but I think that is from rebooting the router. Anything else I can look at or test? Clocking? Thanks

ILMNV-BMDO-VG1#sh int s0/0/1:23
Serial0/0/1:23 is up, line protocol is up (spoofing)
Hardware is DSX1
MTU 1500 bytes, BW 64 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:00:04, output 00:00:04, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
44759 packets input, 208216 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
330 runts, 1 giants, 0 throttles
1235 input errors, 1035 CRC, 0 frame, 199 overrun, 0 ignored, 165 abort
44803 packets output, 214229 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
47 carrier transitions
 
Rebooting the router is quite extreme to resolve an issue with a PRI. Have you tried just shutting down the interface itself and then turning it back on? Additionally what is the output of "show isdn status" when the Pri stops working?
 
I was going to try a shut/no shut the next time but I haven't been in the office to do so. I show the router has been up for 5 days which means no one onsite has shut it down and I haven't done a remote reload. In the 5 days they say their phones have dropped, so the PRI is coming back up without a reload.

The telco is sending a tech out today to test. Anything I should look for on my side? Thanks

The ISDN status looks the same when we have the issue....

VG1#sh isdn status
Global ISDN Switchtype = primary-dms100
ISDN Serial0/0/1:23 interface
dsl 0, interface ISDN Switchtype = primary-dms100
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
4 Active Layer 3 Call(s)
CCB:callid=8166, sapi=0, ces=0, B-chan=23, calltype=VOICE
CCB:callid=8183, sapi=0, ces=0, B-chan=21, calltype=VOICE
CCB:callid=8184, sapi=0, ces=0, B-chan=20, calltype=VOICE
CCB:callid=818C, sapi=0, ces=0, B-chan=22, calltype=VOICE
Active dsl 0 CCBs = 4
The Free Channel Mask: 0x8007FFFF
Number of L2 Discards = 0, L2 Session ID = 24
Total Allocated ISDN CCBs = 4
 
If the show isdn status output looks the same as it does now, as in Multiple Frames Established, then the issue isn't with the PRI itself.

1. Would you clarify what you mean when you say their "phones drop"? Are they dropping the current caller, does the phone reset?

2. Is this a VG to CUCM or is this UCME? IF CUCM, are the CUCM located on the same site and are they H323 or MGCP?
 
The phones will drop the call and when you try and call this site you get a busy signal until the PRI is back up. The phones don't reset so they are still registed to the CUCM 9.1.2. The CUCM is located at another site and hosts 10 other locations. None of the other sites are having this issue and all have a PRI. Each site has a VG with a PRI and this particular one is h323. In the serial print out above what about the 47 carrier transitions? Thanks
 
Is this VG configured as the MTP for the device pool? I saw those errors, but will commonly see some after the router reboots and calls are attempting to come in while the router is trying to register. Is this a copper PRI, or is this a handoff to a local device?
 
Cooper PRI going from the NIU to the VG. Sorry, what is MTP? Thanks
 
I just did a sh controllers... below is what I get for s0/0/1:23

hdlc_chan hdlc_quad owner_idb chan chan_bitfield wic_slot port
========= ========= ========= ==== ============= ======== ====
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
23 800000 13A98714 23 100 0 1
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
-1 0 0 0 0 0 0
 
MTP - Media Termination Point, it's needed for SIP and H323 gateways.
 
Have the telco get someone on site to do a manual loopback to their C.O. on the router side of the demarc. The Telco will only see errors coming in to them if they do no loop back and will only see a portion of their smartjack if they do a loop back. The manual loop will show all their hardware and wiring, and is a much better indicator. ON a PBX the error counters build up the more users get on the circuit until it eventually fails, I assume this is what is happening with you to, it will reset itself withing a few minutes and work fine until the errors build up again.
Bottom line - get the telco out to check their lines thoroughly.
 
Okay, so I did get the telco onsite to test and they did see errors from their equipment. They said they fixed it yesterday so I cleared the counters so I could look this morning to see if there were ant errors on the serial int and the controller.... zero errors. Now I see an email from yesterday that they still dropped calls after the issue had been resolved. If the PRI would have dropped I would think I would see some errors on the serial int or the controller. Before the fix I had input errors, CRC errors, and a lot of carrier transitons. This morning everything is clean. Maybe I'll reload the switches and see if that helps. Thanks
 
Give yourself a little time so users are not "confusing" when their errors occurred.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top