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

[Brian Feeny]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20041029/194309e8/PGP.bin