i have a problem with isdn connection.
i use it as the backup connection for leased line.
When i make a test call to other end router using "isdn test call" the connection disconnect after a few seconds.
i tried some solutions from TAC Case collectoin but can't solved yet.
even though i changed to another BRI interface, the line still got disconnected.
I attach some debug output, please help me to fix this problem.
With Best Regards
One thing I noticed is on Router B Debug there is a statement about not end to end ISDN. I have seen issues with this in that the call tries to go thru a carrier network and they route the call through an old Switch 56k dial network. Since your call is dictated as 64k. the call will not go through because a sw56k network runs at 56k. Try lowering your bandwidth on your B channels to 56k.This way you force the call to connect at 56k...
thanks for your reply pciaccio
i tried with "isdn test call int bri xxxxx 56"
also set the bandwidth to 56k, but cannot maintain the connection
Can you post the configurations from both ends as well as the results from the
SHOW ISDN STATS commnand
SHOW ISDN SERVICE command
Current Debug outputs from DEBUG ISDN Q931
and DEBUG PPP NEGOTIATION
Somewhere in these outputs should be an answer...
The debugs posted from router A are a bit more complete than the debugs from router B - especially in showing ppp negotiation. It might be helpful to see an equally complete set of debugs from router B.
But in the debugs that are posted I believe that we see that LCP negotiation is successful and that authentication seems to be successful. But I see no sign of NCP negotiation. The outputs requested by Phil would be helpful but I think it will be especially important to see the router configs.
Here's the partial configuration from both router. I can't access the routers coz i'm away for a few days.
The ip address aren't the real public address.
I'll send you the debug status later
One thing i remember is both of the layer two are active in routers.
this is the last thing i got :D frm router A.
i'm not familiar with ISDN , please help me
ISDN Q931 packets debugging is on
Router A#ter mo
Feb 2 23:34:18.105: ISDN BR1/0: RX <- SETUP pd = 8 callref = 0x01
Feb 2 23:34:18.105: Sending Complete
Feb 2 23:34:18.105: Bearer Capability i = 0x8890218F
Feb 2 23:34:18.105: Channel ID i = 0x89
Feb 2 23:34:18.109: Called Party Number i = 0xC1, 'xxxxxxx', Plan:ISDN, Type:Subscriber(local)
Feb 2 23:34:18.113: ISDN BR1/0: Event: Received a DATA call from
1 at 56 Kb/s
Feb 2 23:34:18.113: ISDN BR1/0: Event: Accepting the call id 0xED
Feb 2 23:34:18.117: %LINK-3-UPDOWN: Interface BRI1/0:1, changed state to up
Feb 2 23:34:18.121: ISDN BR1/0: TX -> CALL_PROC pd = 8 callref = 0x81
Feb 2 23:34:18.121: Channel ID i = 0x89
Feb 2 23:34:18.221: ISDN BR1/0: TX -> CONNECT pd = 8 callref = 0x81
Feb 2 23:34:18.369: ISDN BR1/0: RX <- CONNECT_ACK pd = 8 callref = 0x01
Feb 2 23:34:19.249: %ISDN-6-CONNECT: Interface BRI1/0:1 is now connected to Router B
Feb 2 23:34:19.249: %ISDN-6-DISCONNECT: Interface BRI1/0:1 disconnected from
Router B, call lasted 1 seconds
Feb 2 23:34:19.253: ISDN BR1/0: TX -> DISCONNECT pd = 8 callref = 0x81
Feb 2 23:34:19.257: Cause i = 0x8090 - Normal call clearing
Feb 2 23:34:19.421: ISDN BR1/0: RX <- RELEASE pd = 8 callref = 0x01
Feb 2 23:34:19.425: %LINK-3-UPDOWN: Interface BRI1/0:1, changed state to down
I believe that I may see what is the problem. It is a bit complex so let me explain it this way:
- I believe that one clue is my observation that LCP works and ppp authentication seems to work but that NCP does not work (in which the IP address is negotiated).
- first we should be clear about one aspect of backup interface. When an interface is configured as backup to a primary interface (in this case dialer0) the interface is in a special state can will not operate unless there is a failure of the primary interface. So your dialer0 will not operate unless there is a failure of the primary interface (the multilink interface).
- when you use the test call command it is directed at the BRI and the BRI activates. It places the call, the LCP negotiates successfully, and authentication is successful (since authentication is configured on the BRI). But when it gets to NCP there is no IP address on the BRI. The IP address is on dialer0 and that interface is in the special state, so there is no IP address for the call.
I believe that there are several ways that you can get around this. The most simple solution would be to remove the backup interface command from the multilink interface while you do your test. With the backup interface command removed the dialer0 interface will work. After the test is completed you can replace the backup interface command on the multilink interface.
Another solution (especially if you do not want to remove the backup interface command) would be to configure a second dialer interface and to use the second dialer interface for the test.
Just to add one of my practical experience.
Take a led and place it on two lines of isdn , if the led stays on it means line is not having problem,
if led blinks off and on in betweens then the link is not stable.
If link blinks off and on , go to mux and check there whether the link is ok till there.
I faced this crazy situation once and after with help of led i was able to find that the link from mux to router was getting disturbed due to the electric cablings which were near to isdn line.
Layout of cable was again done but not from besides of electric cables and then we were ok.
Also during this troublshooting i found that isdn was getting connected and disconnected.
Best of Luck!
Thanks so much guys,
very much appreciate for your help.
Hello Mr Rburts,
Do i need to assign an IP address when i configure new dialer interface and make a test call ? or can i use with ip unnumbered fa0/0 ?
please specify the pin number in testing with LED. You mean,we need to test the RJ-45 cable first from Network Termination equipment and then go to test the ISDN line.
Thanks in advance
The most important thing is that the new dialer have an IP address with which to negotiate. I would probably assign an IP to it if it were me. But I would think that ip unnumbered would also be ok.