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