ppp chap authentication issue

Unanswered Question
Jun 18th, 2008

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.

Attachment: 
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
shillyar Wed, 06/18/2008 - 10:49

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

Kevin Frazer Wed, 06/18/2008 - 10:59

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.

Paolo Bevilacqua Wed, 06/18/2008 - 11:05

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.

Kevin Frazer Wed, 06/18/2008 - 11:16

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.

Paolo Bevilacqua Wed, 06/18/2008 - 11:56

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 Wed, 06/18/2008 - 10:50

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

shillyar Wed, 06/18/2008 - 12:20

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 Sat, 04/17/2010 - 11:51

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 Sun, 05/29/2011 - 03:16

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).

Actions

This Discussion