cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1342
Views
0
Helpful
10
Replies

ppp chap authentication issue

Kevin Frazer
Level 1
Level 1

By doing a debug on both router that are participating in the authenication, this is what i get. This is an ISDN backup. Any ideas? Output attached.

10 Replies 10

shillyar
Cisco Employee
Cisco Employee

Hello,

It looks like you have an ISDN issue with data packets not making it across the link as all you see is "0" OUTBOUND PPP packets.

Check to make sure your switch type is correct on both side and also verify your spids are correct look at " sh isdn status" to make sure you have L1 and L2 up. if all that is good then call telco and tell them you cant pass data across your iSDN line.

Thx Steve

Thank you for replying so quickly. The switch type and SPIDS are correct and a 'show isdn status' confirms L1 and L2 are up as well. I have a ticket opened with the telco right now. Hopefully its on their end:) Thanks for the input.

Hi, it should not be ISDN issue, as the call is connected OK:

Jun 18 18:38:29.999 UTC: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to 17187527060 N/A

It is theoretically possible that an ISDN call doesn't pass data, but also very unlikely.

The call is connecting but it is only lasting for 20 seconds. Could it not be a CHAP authentication failure? It looks like the CONFREQ is not being returned or reaching the host router that initiated the ISDN call.

Indeed, and you can find further by looking in the other router. You can also take a trace of all L3 frames with the debug isdn 921 commands.

paolo bevilacqua
Hall of Fame
Hall of Fame

In this trace, you are not getting any PPPP input. Is the other router is configured properly ?

shillyar
Cisco Employee
Cisco Employee

Hi,

Just remeber this being a telco issue is assuming the remote side is also sending ppp packets and this we dont see them on teh rmeote end. I did not see any ppp debugs from the remote side but, if you at least see I and O ppp packets this will be a telco issue as i have seen it many times. If the remote is not sending ppp packets then its 99% a conf issue.

g.sanchezjavier
Level 1
Level 1

It's possible that the issue is in the PPP auth. Activate the debug ppp authentication to view more detailed info about authentication. Verify that the other end is correctly configured with the correct usernames and CHAP authentication.

Ed Simson
Level 1
Level 1

Funny, I just took a look at what I figured must be the last four BRI backups anywhere and started troubleshooting why they didn't work, when they dial their PRI headend.  I see the exact same issue, its interesting because initially the call connects but from what it looks like the call is not capable of passing data (if you disable authentication it will change the message but will not change the behavior).  I am going to work on this tuesday, I think I have solved this issue before and if I remember correctly this was related to the number on the PRI headend terminating via switched termination rather than dedicated.  I will let you know what I find.

In the mean time you can make sure that your remote end can pass data by making a loopback connection (no need to do anything physically): just use the command isdn call interface to call yourself, if you have debug ppp negotiate and debug isdn q931 you should see the call setup go out and then come right back from the ISDN switch, it should proceded and the router should even try to authenticate with itself (depending on your exact setup the 2-way auth will likely fail but it proves you can send data to the local teleco and back).

Three years old thread, unlikely the OP is still on it.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco