ML PPP problems - can't connect two routers over ISDN

Bojan Zivancevic · ‎04-19-2007

I tried to solve this for quite a while, but... No luck. Here's the current situation:

Router that performs the dialing has an ISDN BRI card. This is 2621XM with IOS 12.3(6f). Hostname is RTBeograd.

Access router has a PRI (E1) interface, and this is 3620 with IOS 12.2(7c). Hostname is RTAccess.

Both routers have basic IOS images, nothing fancy.

Here's the cut-down configuration and the 'debug ppp multilink events' info:

RTBeograd

=========

username RTAccess password yyyyyyyy

interface BRI0/0

ip unnumbered FastEthernet0/0

encapsulation ppp

dialer pool-member 1

isdn switch-type basic-net3

ppp authentication chap callin

ppp multilink

interface Dialer1

ip unnumbered FastEthernet0/0

encapsulation ppp

dialer pool 1

dialer string xxxxxxx

dialer load-threshold 1 either

dialer-group 1

ppp authentication chap callin

ppp multilink

.Apr 19 13:46:30.980: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0/0, TEI 112 changed to up

.Apr 19 13:46:32.188: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up

.Apr 19 13:46:32.688: BR0/0:1 MLP: Request add link to bundle

.Apr 19 13:46:32.688: BR0/0:1 MLP: Adding link to bundle

.Apr 19 13:46:32.692: Vi2 MLP: Invalid dialer BR0/0:1

.Apr 19 13:46:32.692: BR0/0:1 MLP: Bundle failed in creation/cloning

.Apr 19 13:46:32.696: BR0/0:1 MLP: Link for xxxxxxx not added to bundle

.Apr 19 13:46:32.708: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to xxxxxxx RTAccess

.Apr 19 13:46:33.284: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to down

.Apr 19 13:46:35.384: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0/0, TEI 112 changed to down

RTAccess:

=========

interface Serial1/0:15

no ip address

encapsulation ppp

dialer rotary-group 0

dialer-group 1

isdn switch-type primary-net5

ppp multilink

interface Dialer0

ip unnumbered Loopback0

encapsulation ppp

dialer in-band

dialer load-threshold 1 either

dialer-group 1

peer default ip address pool dialin_pool

ppp authentication chap backup

ppp multilink

.Apr 19 13:46:31.838 CEST: %LINK-3-UPDOWN: Interface Serial1/0:12, changed state to up

.Apr 19 13:46:32.874 CEST: Se1/0:12 MLP: Link for 113038962 not added to bundle

.Apr 19 13:46:33.174 CEST: %ISDN-6-CONNECT: Interface Serial1/0:12 is now connected to qqqqqqq RTBeograd

.Apr 19 13:46:33.174 CEST: %ISDN-6-DISCONNECT: Interface Serial1/0:12 disconnected from qqqqqqq RTBeograd, call lasted 1 seconds

.Apr 19 13:46:33.214 CEST: %LINK-3-UPDOWN: Interface Serial1/0:12, changed state to down

-----------------------------------

So, the call lasts a second and then access router hangs up. We are using tacacs+ server, and I've tried various debug aaa auth*** commands and everything seems to be ok in that part.

Any help is greatly appreciated.

spremkumar · ‎04-19-2007

hi

My first suggestion would be removing the ip address assigned to the bri port on the 2600 series router make it as no ip address.

also on the dialer 1 do assign an ip address from the private pool either in 10.x.x.x or 17.16.x.x or 192.168.x.x..

Since its gonna be PRI at the head end you can take a /30 ip for the dialer interface purpose and assign the same respectively on both the sides.

once you are done with that try to reestablish the connectivity.

is there any specific requirement for having this command under your config ?

peer default ip address pool dialin_pool

You need to make sure on the authentication front too make them unique on both the ends so that you dont have any authentication related issues later..

regds

Bojan Zivancevic · ‎04-20-2007

Thanks for all the help. I didn't mention all the details because I didn't want to overload the post. :) The access router servers as a backup "collector" i.e. we have some 50 routers connected over frame relay links, with isdn backups. So, there are specific reasons for the commands you mentioned.

But, as I was searching the web for the solution, some guys enlightened my brain quite a bit. MLPPP is absolutely not required of you have cisco gear exclusively - and we do. So, I removed multilink commands, shortened the load-interval command, and used plain old BOD functionality. And now it works like a charm. :)

I don't know what happened, I tried debug ppp negotiation and authentication, and there's nothing wrong with these guys.

My guess it has something to do with the change of IOS in my calling router. Before the upgrade, MLPPP worked. Afterwards - nope.

Anyway, I'm not going to dig deeper into this, because I already wasted many hours debugging it. :)

Thanks anyway!