Subject: AW: multilink ppp with l2tp?

From: Klausberger Walter <[email-masked]>
Date: Fri, 6 Oct 2000 16:30:04 +0200

I like the idea of terminating the MP in the LAC, although I am not sure if
anyone ever tried this.

Let me ask another question. What about MP over multi-chassis?
- Is it really common to forward the PPP connection from one chassis to the
other via L2TP, or is there another way (I would have to implement LNS on a
LAC!)?
- Is there a common way to distribute information about incomming PPP
sessions between the chassis?
- Would you recommend to terminate the MP in this chassis anyway to avoid
multiple links over the L2TP to the remote LNS?

with best regards
Walter Klausberger

-------------------------------
Siemens AG Austria
Boschstrasse 10
1190 Vienna
Austria

Tel: +49(5)1707-42683
<[email-masked]>
-------------------------------

-----Ursprüngliche Nachricht-----
Von: James Carlson [mailto:[email-masked]]
Gesendet am: Freitag, 06. Oktober 2000 14:40
An: S.Rajesh Kumar
Cc: [email-masked]
Betreff: Re: multilink ppp with l2tp?

S.Rajesh Kumar writes:
> (1) Does anyone use l2tp to tunnel multilink ppp?
> Any well-known issues?

Yes; many.  Multilink is negotiated by way of LCP MRRU.  Many L2TP
implementations negotiate LCP in the LAC before ever contacting the
LNS.  This means that the caller who is trying to establish a second
link must be tolerant of getting a reject on MRRU at first (from the
LAC), followed by LCP renegotiation (by the LNS) with MRRU.  (I know
of no demand-dialing peers that are so tolerant, and I think making
them tolerant to accomodate an L2TP problem would be unwarranted.)

I think it's fair to say that MP interacts poorly with most L2TP
implementations.  L2TP is far from transparent.

(This is not true if you're not doing proxy LCP.  If L2TP is merely a
configured tunnel between the LAC and LNS, then this part of the
problem is simpler.)

> (2) How does ProxyLCP work in this case? Is the LAC expected to be
> the same for all links in a bundle? What if multiple links in a bundle
> go through different LACs?

They'll either have to be configured to give the same LCP Endpoint-
Discriminator, or the peer will have to be tolerant of being presented
with the "wrong" E-D and having LCP renegotiated with the "right" one
later.

> (3) RFC1990 on Multilink PPP suggests a mechanism of using increasing
> sequence numbers on links within a multilink bundle alongwith a scheme
> where a receiver can quickly detect a lost fragment.

It's quite a bit more than a suggestion.  It's a requirement.  MP will
fail miserably if you reorder fragments.

> Would this break
> if the ppp session (multilink) were tunneled over an IP network, with its
> possibility of reordering?

Unless you use the "Sequencing Required" option in L2TP, you may well
break the ordering rule in MP.

I'm probably in the minority on this, but I'd recommend doing the
bundling locally -- on the LAC if possible -- and then carrying the
reassembled packets back to the LNS via L2TP.  You have to do stateful
inspection and modification of the LCP messages at the LAC in order to
do this, so that the LNS can remain unaware of the MP options, but
it's not an impossible thing to do; ISDN TAs have done it for years.
(There are, of course, other problems; for instance, this mode of
operation breaks CHAP.)

The reason I recommend bundling locally is twofold.  First, as you've
noticed, L2TP interacts with MP in some undesirable ways in the
establishment of links.  Second, and more subtly, MP performs very
badly when there's differential delay between the links or noticable
fragment loss, as occurs with non-error (congestion) events.
Tunneling the links across an internet is one good way to destroy MP
performance.

You might want to get a copy of Rich Shea's book on L2TP.  It covers a
number of deployment issues such as this.

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
Second Edition now available - http://people.ne.mediaone.net/carlson/ppp

---

From: James Carlson <[email-masked]>
Date: Fri, 6 Oct 2000 10:44:48 -0400 (EDT)

> other via L2TP, or is there another way (I would have to implement LNS on a

I don't know how common it is to use L2TP for this, but it's certainly
the way Xylogics/Bay Networks/Nortel servers worked.  See RFC 2701.

Yes, you do need LNS functionality in the access server to do this.  I
don't understand the "!" in your comment, though, since once you have
LAC functionality there, LNS isn't so hard -- it reuses a fair part of
the code.

There are other, proprietary schemes to forward the MP links within a
multi-chassis group.  I would assume (but don't know for certain) that
Cisco uses L2F.  Ascend/Lucent used an ad-hoc UDP-based protocol (you
can find some reverse-engineered documentation of it in my book) to do
both bundle head discovery and the data forwarding.  I'm not sure what
Livingston/Lucent did.

An alternative is to toss the whole mess out and put the LAC
functionality into the so-called "client" system.  You'd then dial in
using normal MP to the access server for regular Internet (not VPN)
access, and run PPP/L2TP/UDP (or Mobile IP) over that connection.
This avoids the multilink problems in L2TP and, as a bonus, gives
control of the tunneling and security back to the user.  (I'm sure
ISPs wouldn't be thrilled about that; I believe they intend to charge
extra for VPN services.  There are also cases where this couldn't be
made to work, such as if the access server is connected to a non-IP
network and provides no local Internet access.)

> sessions between the chassis?

There are, unfortunately, many proprietary systems.  One (Nortel's) is
documented.  The others, Cisco's SGBP (Stack Group Bidding Protocol)
and Ascend's STACKS, aren't.

> multiple links over the L2TP to the remote LNS?

Yes, that was my point, though I didn't make it clear enough.  Local
connections are better for MP link forwarding than non-local ones.