[c-nsp] What MTU for Bellsouth BBG / BRAS <-> LNS l2TP tunnel?

[Krzysztof Adamski]

On Fri, 29 Oct 2004, Brian Feeny wrote:

>
> On Oct 29, 2004, at 7:51 AM, Gert Doering wrote:
>
> > Hi,
> >
> > On Fri, Oct 29, 2004 at 07:28:03AM -0500, Brian Feeny wrote:
> >> But still, the Link between myself and Bellsouth is only 1500, and
> >> since this is the link on which
> >> l2tp tunneling is being done, thats going to create a problem with it
> >> being so low.  I did a test, and
> >> my LNS reports back to remote sites MTU of 1492, which sounds correct
> >> for PMTU Discovery since
> >> thats the PPPoE layer responding back its limit.
> >
> > That's the PPPoE limit, yes.  Unfortunately, if you send 1492-byte
> > packets, the L2TP packet will be too large, and the routers will need
> > to fragment/defragment the "outer" packet, which costs lots of CPU.
>
> Right, the 1492 packet will be too large.  But, why doesn't the Redback
> fragment the outer packet like you say it should?  What I am saying is
> that if DF is set its just dropping the packets, I wouldn't think the
> outer
> packet would care about the DF of the inner packet, but it seems too,
> since with "ignore df-bit" all works, but without setting that flag,
> anything
> with DF bit is dropped.  I follow your logic, if the 1492 is received,
> its too
> big once you add the the l2tp overhead, and should be fragmented, and
> the worse thing you would think you have to deal with is the fact that
> your causing unnecessary fragmentation and assembly.  But what I am
> seeing
> is that max packet sizes with DF bit set the user does not receive.  I
> do realize
> the outside l2tp tunnel is not involved in the inner packet stream as
> far as DF
> and other flags are concerned, but it almost seems like for whatever
> reason
> it doesnt fragment the packets, or maybe it does and that leads to
> problems
> on reassembly, but the packets never make it.
>
> >
> > One approach is to set the virtual-template MTU to 1454, to make sure
> > that L2TP packets never need fragmentation.  In this case, 1454 is also
> > the MTU that will be discovered by PMTUd.
>
> Does that really work though?  I mean, if you set the PPP interface to
> 1454
> do PPPoE routers negotiate that MTU or just still blatently set 1492.
> In other
> words, I am not sure the whole learning of MTU via PPP is something that
> works well with PPPoE i may be wrong about this though.  I under stand
> this
> reasoning however, and believe me I have tried it, and it didn't work
> which is
> why I mention this, your just making sure that you account for worst
> case scenerio
> of encapsulation/header/overhead.  I do this by setting "ppp mtu 1454"
> under the interface
> which talks PPP to my customers, flapping there session (to re-run LCP
> negotiation), and
> stuff like Amazon (which insists on setting DF in all packets) don't
> work.

The answer to this question is "it depends", if the device that the user
is using supports the full PPP standard then it will work, but many
(mostly Linksys) do not.

> >
> > The best approach is to use PPPoA (no MTU issues) and carry L2TP over
> > something that has a larger MTU - either Ethernet with switches and
> > routers that can do that, or ATM / serial lines / ...
> >
>
> Isn't setting the L2TP link MTU between myself and Bellsouth an option
> like
> above with PPPoA?  I mean if I increase the MTU on the L2TP link between
> myself and Bellsouth, it wont have to fragment to go over the L2TP
> link, and
> then at the other end of the L2TP link it should output a packet that
> should fit
> fine onto the wire.......but please correct me if I am wrong.
>
> I just don't know about the whole PPP learning its MTU thing, if that
> really works
> the way it should.  If it does, then I guess the two options are
> lowering the PPP link
> MTU, or increasing the L2TP link MTU.
>
> Brian
>
>
>
> > [..]
> >> Another "fix" that works, is to set "ip ignore-df bit" on the
> >> Interface
> >> on my LNS that terminates customers
> >
> > This is mostly a workaround for the problems with PMTUd and stupid
> > firewall adminstrators.  It won't help the L2TP fragmentation issue.
> >
> > Actually, it's a real mess in that case.  A 1500 byte packet is
> > fragmented
> > into 1492+8 byte, and then the 1492+L2TP packet is fragmented
> > *again*...
> >
> > gert
> > --
> > USENET is *not* the non-clickable part of WWW!
> >
> > //www.muc.de/~gert/
> > Gert Doering - Munich, Germany
> > gert at greenie.muc.de
> > fax: +49-89-35655025
> > gert at net.informatik.tu-muenchen.de
> >
> ------------------------------------------------------------------------
> ------
> Brian Feeny, CCIE #8036, CISSP    	e: signal at shreve.net
> Network Engineer           			p: 318.213.4709
> ShreveNet Inc.             			f: 318.221.6612
>
>