Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Community Member

New PRI don't carry data


We are converting service providers and a new local company has installed a PRI line to replace our existing PRI from our old provider. We are trying to test the new PRI line before we disconnect the old one, but the new PRI will not carry data. The configuration on the routers is the same, with the exception of the phone number in the dialer-map statement. We plug the new PRI into the Router and changed the number at the remote location to dial into the test number.

While debugging the connection, the call is accepted but PPP authentication fails and the line drops after 20 seconds. It appears that no packets are being exchanged over the line. I just see Se1/0:1 EVT: Packet 0 0x633C32E4 which repeats with timeouts. We are using CHAP. Like I said before, the configuration does not change from the original PRI to the new PRI except for the test number to dial into the new PRI on the remote router.

I can provide detailed debugs or whatever is needed, but I thought that maybe someone has seen this and knew of an easy solution. I personally believe that there is still something not provisioned exactly right on the PRI but I know nothing about the phone system, and the phone guy knows nothing about routers or data.



Hall of Fame Super Gold

Re: New PRI don't carry data


It is difficult for me to understand how a problem in provisioning the new PRI could produce authentication errors.

It might be helpful if you could run debug ppp authentication and post the output.

If you want to investigate possible provisioning problems it might be helpful to run a separate debug of debug isdn q931.




Re: New PRI don't carry data

You may have a CHAP issue here. Try doing a Debug PPP Negotiation on the router.Then do a call to see the output.If a CHAP issue then the odds are that your CHAP passwords are not matched...

Community Member

Re: New PRI don't carry data

Ok here are some PPP debugs. Seems like there is something wrong with the line. The hub site is not able to get packets back to the remote site. All the packets upstream are getting dropped, lost, whatever.


See atachement (bad)


See attachment.

Any ideas what the provider needs to look at in provisioning the line?


CreatePlease to create content