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

Fri Oct 29 18:45:19 EDT 2004

Brian Feeny [signal at shreve.net] 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?

Yes, it should. The LAC shouldn't care whether or not the DF bit is
set. It should encapsulate (in L2TP) and fragment (if necessary). You
could imagine a "feature" where the LAC peeks into the payload and if
the DF bit is set and the encapsulated packet would be too large, it
would drop the packet. But in doing so, it should send an ICMP message
back to the client to notify them of the MTU limitation. This is
somewhat of a layering violation (IMHO), but also happens to be a
rarely-used feature in IOS. Basically we spoof the ICMP message to
make it look like it came from the destination IP address.

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

Automatic learning of MTU via PPP MRU negotiation depends on the
client. Certain clients can handle this (like WinXP, MacOSX, and Linux
I think). Unfortunately "smart" clients are not universal, so everyone
is forced to implement multiple overlapping solutions for the same
problem...

Dennis

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

> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/