04-19-2007 04:06 AM
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.
04-19-2007 08:10 PM
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
04-20-2007 09:13 AM
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!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide