ISDN- traffic not being passed

[jdevoll]

Configuring ISDN between two sites, ISDN comes up fine, PPP negotiaties just fine, but I cannot get packets accross the line. If I ping from one router to the other (src 2.2.2.2 dst 2.2.2.1) with debug IP packet logging I get this on the destination side:

02:53:43: IP: tableid=0, s=2.2.2.2 (BRI0/0), d=2.2.2.1 (BRI0/0), routed via RIB

02:53:43: IP: s=2.2.2.2 (BRI0/0), d=2.2.2.1 (BRI0/0), len 100, rcvd 3

02:53:43: IP: tableid=0, s=2.2.2.1 (local), d=2.2.2.2 (BRI0/0), routed via RIB

02:53:43: IP: s=2.2.2.1 (local), d=2.2.2.2 (BRI0/0), len 100, sending

02:53:43: IP: s=2.2.2.1 (local), d=2.2.2.2 (BRI0/0), len 100, encapsulation fail

ed

02:53:45: IP: tableid=0, s=2.2.2.2 (BRI0/0), d=2.2.2.1 (BRI0/0), routed via RIB

02:53:45: IP: s=2.2.2.2 (BRI0/0), d=2.2.2.1 (BRI0/0), len 100, rcvd 3

02:53:45: IP: tableid=0, s=2.2.2.1 (local), d=2.2.2.2 (BRI0/0), routed via RIB

02:53:45: IP: s=2.2.2.1 (local), d=2.2.2.2 (BRI0/0), len 100, sending

02:53:45: IP: s=2.2.2.1 (local), d=2.2.2.2 (BRI0/0), len 100, encapsulation failed

I also get the same thing if I ping in the other direction. So I'm getting packets to go 1 way, but on the return trip they aren't getting encapsulated. I've never seen anything like this before, has anybody else?

[lgijssel]

This is definitely a configuration issue.

Your config is probably more complicated than you pretend. Appearently there is some form of bridging in use also. (routed via RIB??)

Please post your configs so that we can have a look at them.

Regards,

Leo

[jdevoll]

Aactually the config is about as simple as one can get, there?s no bridging involved here either.

I figured it out though, and you are correct, it is a config issue. I had configured BOTH sides to dial (via dialer map). When RouterA sent icmp to RouterB, RouterA dialed up the ISDN. RouterB received the packets and attempted to dial up RouterA, however RouterA's ISDN was already up and therefore it was busy when RouterB attempted to dial. RouterB then dropped the packets at the interface.

A careful inspection of 'debug isdn q931' revealed the 'busy' issue. I had glossed over the output before and had missed this little issue.

Lesson learned, if you?re running a debug... PAY ATTENTION! : )

Educate me please; what does the RIB have to do with bridging? I have always assumed it was the data structure that contains the routing tables.

[jdevoll]

forgot about one other issue, I had neglected to configure any auth. To be honest, I need to go back and test whether the 'busy' issue was an actual issue or whether is was simply the lack of auth.

It's been a long time since I've delt with ISDN, refreshing my brain in the lab before I hit production.

[jdevoll]

interesting...

Naturally the fault was a lack of a 'ppp authentication' statement on either end of conversation. debug isdn q931 manifests this problem as:

ISDN BR0/0: RX <- DISCONNECT pd = 8 callref = 0xdf Cause i = 0x8291 - User busy

Interestingly enough, LCP and NCP (IPCP) negotiate just fine without authentication configured (verified proper state progression via debugs). Seems odd that it was left for Q931 to identify this issue. I would think it appropriate to leave this to LCP!?

At any rate, I'm golden and I learned quite a bit. Amazing the things that you figure out once you ask somebody. It never ceases to amaze me!

[Richard Burts]

Jeremy

What do you think that LCP should do? As far as LCP (and NCP) are concerned things are working - there was not any failure in their negotiation. Authentication is not required by the protocol and failure to require authentication is not an LCP problem.

It might help to take a closer look at why failure to authenticate is a problem. In your situation side 1 is sending a packet to side 2. Side 1 opens the BRI and places a call. Side 2 answers and the configured negotiation takes place (without authentication). Side 2 has received the packet and needs to send a response. Side 2 does not know that it already has an open connection to side 1 and side 2 attempts to open the BRI and place a call to side 1. (You and I know that side 2 has an open connection to side 1 but since there was no authentication side 2 is not sure who it is connected to and attempts to open a new connection.)

And that is why configuring authentication solves the problem. With authentication configured when side 1 calls side 2 and side 2 needs to respond it knows to use the open connection. There is no attempt to open a new connection and no problem. And that is indirectly why Q931 shows the problem but LCP and NCP do not show a problem.

HTH

Rick