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

Ye

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.

HTH

Rick

Hello Pciaccio

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

Router A#

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 on B

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

Router A#

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

Ye

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.

HTH

Rick

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 ?

dear Amolwaghmare,

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

Ye

Ye

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.

HTH

Rick

Alright Mr Rick

i'll test with new ip and tell you the result when i'm done .

There are only two pins which enter your NT box.

You have to place it just over Tx and Rx that's all!