L2TP Multilink across multiple DSL lines

Unanswered Question

Hi,

I'm trying to do IOS-to-IOS L2TP multilink to incease the throughput of DSL by using multiple lines. The problem I've encountered is IPCP negotiation does not successfully complete when I bond 2 (or more) virtual-PPP interfaces into a multilink interface. At the LCP layer things seem to be fine e.g. virtual-ppp interfaces get bundled togther on both sides.

The LNS keeps sending the client a CONFREQ to which it responds, but after that there is a timeout (LNS does not like what it gets back), so IPCP never completes and the virtual-access interfaces never become operational.

If I remove the multilink interface and add ip addr neg + chap to the virtual-ppp interfaces, each one comes up independantly with their own IPs. Test (summary) configs as follows;

L2TP Client Router

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

multilink bundle-name authenticated

pseudowire-class bdsl

encapsulation l2tpv2

interface Multilink1

ip address negotiated

no cdp enable

ppp authentication chap callin

ppp chap hostname l2-user1

ppp chap password 0 l2-pass1

ppp multilink

ppp multilink group 1

interface Virtual-PPP1

no ip address

no cdp enable

ppp multilink

ppp multilink group 1

pseudowire 50.50.50.50 10 pw-class bdsl

interface Virtual-PPP2

no ip address

no cdp enable

ppp multilink

ppp multilink group 1

pseudowire 50.50.50.51 20 pw-class bdsl

interface Dialer1

ip address negotiated

ip mtu 1492

ip nat outside

ip virtual-reassembly

encapsulation ppp

dialer pool 1

no cdp enable

ppp authentication chap callin

ppp chap hostname user1

ppp chap password 0 pass1

interface Dialer2

ip address negotiated

ip mtu 1492

ip nat outside

ip virtual-reassembly

encapsulation ppp

dialer pool 2

no cdp enable

ppp authentication chap callin

ppp chap hostname user1

ppp chap password 0 pass1

ip route 50.50.50.50 255.255.255.255 Dialer1

ip route 50.50.50.51 255.255.255.255 Dialer2

LNS Router

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

aaa new-model

aaa authentication ppp default local

aaa authorization network default local

aaa session-id common

multilink virtual-template 1

multilink bundle-name authenticated

vpdn enable

vpdn-group l2-clients

accept-dialin

protocol l2tp

virtual-template 1

no l2tp tunnel authentication

username l2-user1 password 0 l2-pass1

interface Loopback0

ip address 150.150.150.1 255.255.255.255

interface FastEthernet0/0

ip address 50.50.50.51 255.255.255.0 secondary

ip address 50.50.50.50 255.255.255.0

interface Virtual-Template1

ip unnumbered Loopback0

peer default ip address pool l2-pool

no keepalive

ppp authentication chap

ppp multilink

ip local pool l2-pool 150.150.150.100 150.150.150.110

So my question is, does anyone know if the above config is possible? If so what paramters could be tuned to get IPCP to complete on the Multilink interface?

Lastly if anyone has an alternate method of achieving tunnel bonding over multiple dynamic IP DSL (Dialer) interfaces, I would be very interested.

PS: Testing done on IOS 12.4(15)T7 Adv IP Srv

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
drolemc Fri, 07/17/2009 - 14:01

If the subnet mask is not available from either the NRP configuration or the RADIUS user profile, the NRP rejects IPCP subnet mask negotiation from the CPE.

Hi,

Tried every possible combination for setting the mask using ppp ipcp mask, however it made no difference.

I'm starting to think this is a bug/incompatibility in IOS between the Multilink & Virtual-PPP interfaces. If one looks at PPP neg debugs on either end ...

LNS Router

Jul 18 19:09:25.531: Vi4 IPCP: O CONFREQ [REQsent] id 4 len 10

Jul 18 19:09:25.531: Vi4 IPCP: Address 150.150.150.1 (0x030696969601)

Jul 18 19:09:27.543: Vi4 IPCP: Timeout: State REQsent

L2TP Client Router

Jul 18 19:09:25.510: Mu1 IPCP: I CONFREQ [ACKsent] id 4 len 10

Jul 18 19:09:25.514: Mu1 IPCP: Address 150.150.150.1 (0x030696969601)

Jul 18 19:09:25.518: Mu1 IPCP: O CONFACK [ACKsent] id 4 len 10

Jul 18 19:09:25.518: Mu1 IPCP: Address 150.150.150.1 (0x030696969601)

one can see that the LNS Router sends out a CONFREQ to which the L2TP Client seems to reply with a CONFACK, however if one traces the wire, only the original CONFREQ is seen. The response the L2TP Client Router believes it sent is never seen on the wire. This is where the bug/incompatibility lies, even when using the latest version of IOS 12.4(24)T on both ends.

Thanks for your input anyway.

Actions

This Discussion