Subject: RE: AW: multilink ppp with l2tp?

From: Tatsuya Yanagibashi <[email-masked]>
Date: Fri, 6 Oct 2000 15:50:49 -0700

I was working for mp on l2tp problem before. The another 
problem could appear in following situation.

(1)LAC and remote PPP device negotiated LCP config option 
which is including "Multi-Link Endpoint-Discriminator(ED)".

(2)If LNS is going to "re"negotiate LCP config again, this 
ED value might be different from old value which LAC sent 
before.

On normal PPP device implementation, it will not expect to
recieve ED value which is changed during LCP negotiation 
on same physical link. These client implementation cannot 
establish even PPP session itself.

One of solution is LAC is doing ProxyLCP which is including 
original ED value, then LNS must not renegotiate or LNS 
resend the same ED which LAC and client have negotiated 
already during LCP renegotiation, I think.

Regards,   

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

 +----+----+     
 |.. .|    |            Tatsuya Yanagibashi
 |_~__|    |     
 | .. |~~_~|             Network Consultant
 | .  |    |          CoSine Communications Inc.
 +----+----+     
 C o S i n e     e-mail:  [email-masked] 
Communications

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

-----Original Message-----
From: James Carlson
To: Klausberger Walter
Cc: [email-masked]
Sent: 2000/10/06 7:44
Subject: Re: AW: multilink ppp with l2tp?

Klausberger Walter writes:
> 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!)?

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.)

> - Is there a common way to distribute information about incomming PPP
> 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.

> - Would you recommend to terminate the MP in this chassis anyway to
avoid
> 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.

-- 
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 22:12:48 -0400 (EDT)

> establish even PPP session itself.

Right.  Actually, in any decent implementation, the changing of the ED
doesn't itself cause a problem.  It merely means that if it was part
of a bundle with the original value, then it's not with the new value.

The real problem is that the initial value that the LAC sends out may
not match what the client side saw from another LAC or the LNS itself.

Consider a client that establishes link 1 through LAC A, then
renegotiates LCP with the LNS in order to get MP running.  In the
process it gets an ED value from its peer.  The client then attempts
to establish link 2 through LAC B.  If LAC B unwittingly offers an ED
value -- on initial negotiation before the LNS identity is even known
-- that happens to be different from the one that the LNS has offered
for its side, then the client will tear down link 2, since it appears
to have landed on the wrong system.

The client side doesn't (and shouldn't) know that these LACs are
standing in the way of connecting to the LNS.  The problem is that, in
terms of the packets the client sees, the LACs don't always look
exactly the same as the LNS does.

> already during LCP renegotiation, I think.

Actually, it's worse than that.  By definition of MP, the ED values
that the "client" end of the link sees from the peer must be the same
on all links.  This implies that the LACs must all give the same ED
value.

ProxyLCP doesn't fix this.  (In fact, I see nothing for which ProxyLCP
is actually required.  But that's another story ...)

-- 
James Carlson                                  <[email-masked]>
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp