[c-nsp] l2tpv3 config - MTU question

Thu Feb 26 12:10:42 EST 2009

We've got about a half-dozen sites deployed on this, with about 1000 
user base total, and it's running most fine, caveats:
* watch out for VTP as thiere may be some out of order packets that 
causes VTP convergence to fail; run the CE side in vtp transparent mode 
and add vlan manually
* another trick we've been think about is adjusting MTU on the end 
workstations
* mtu 1472 works fine as defrag/frag will happen on the pe/ce equipment; 
no worries with running high cpu on end-workstation due to frag/defrag 
operations
* "clear ip tra" & "sh ip tra" will show frag stat on routers

hope this helps.

Regards,
Ge Moua | Email: moua0100 at umn.edu

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services

Paul Stewart wrote:
> Thanks - yes, absolutely and I can figure that into the equation.  Been
> reading a lot of discussions in archives and Google about this.  I want to
> ensure that however/where we deploy this that we can provide a full 1500 MTU
> *without* having desktops make MTU adjustments basically.... at the expense
> of fragmentation and CPU (which we can account for).  No matter what I've
> tried so far I can't get a ping through our pair of test routers larger than
> 1472 though yet....
>
> This avoids websites being unreachable (Microsoft comes to mind) and other
> MTU annoyances we've encountered over time...
>
> Paul
>
>
> -----Original Message-----
> From: Ge Moua [mailto:moua0100 at umn.edu] 
> Sent: Thursday, February 26, 2009 11:50 AM
> To: Paul Stewart
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] l2tpv3 config - MTU question
>
> I was tackling a similar issue over here too, I think it may have to do 
> with the fact that l2tpv3 and ethernet headers are taking some of the 
> mtu allocation.
>
> Regards,
> Ge Moua | Email: moua0100 at umn.edu
>
> Network Design Engineer
> University of Minnesota | Networking & Telecommunications Services
>
>
>
> Paul Stewart wrote:
>   
>> Hi folks.
>>
>>  
>>
>> I've setup a pair of 1841's back to back for testing l2tpv3 deployment for
>>     
> a
>   
>> client..
>>
>>  
>>
>> FastE0/0 from each 1841 is connected to one another at 10.0.0.0/24 - each
>> router has a loopback of 192.168.254.1 and .2  - OSPF is running and am
>>     
> able
>   
>> to successfully ping each other's loopback with redistributed subnets
>>     
> etc..
>   
>>  
>>
>> Configured each router to look like this:
>>
>>  
>>
>> pseudowire-class test
>>
>>  encapsulation l2tpv3
>>
>>  sequencing both
>>
>>  ip local interface Loopback0
>>
>>  
>>
>> interface FastEthernet0/0
>>
>>  ip address 10.0.0.2 255.255.255.0
>>
>>  duplex auto
>>
>>  speed auto
>>
>>  
>>
>> interface FastEthernet0/1
>>
>>  no ip address
>>
>>  duplex auto
>>
>>  speed auto
>>
>>  no cdp enable
>>
>>  xconnect 192.168.254.2 1234 pw-class test
>>
>>  
>>
>> Have a notebook hooked up to each FastE0/1 port and assigned 172.16.0.1
>>     
> and
>   
>> .2 on them.  I can ping back and forth proving connectivity etc.
>>
>>  
>>
>> My problem/question is how to get a packet of 1500 bytes to transverse the
>> link - obviously fragmented but that's ok.    In the real-world deployment
>> of this setup we are limited to 1500 MTU in most situations and will
>>     
> presume
>   
>> no mini-jumbo support anywhere (from a config perspective at least).
>>
>>  
>>
>> In my first config I had Path MTU discovery enabled and could only ping up
>> to 1440 bytes.  With that disabled I can now ping to 1472 but not beyond.
>>     
>
>   
>>  
>>
>> With Path MTU turned on it looked like this:
>>
>>  
>>
>> site2#sh l2tun session all
>>
>>  
>>
>> %No active L2F tunnels
>>
>>  
>>
>> L2TP Session Information Total tunnels 1 sessions 1
>>
>>  
>>
>> Session id 53211 is up, tunnel id 32076
>>
>> Call serial number is 1293300000
>>
>> Remote tunnel name is site1
>>
>>   Internet address is 192.168.254.1
>>
>>   Session is L2TP signalled
>>
>>   Session state is established, time since change 00:26:44
>>
>>     114 Packets sent, 116 received
>>
>>     30446 Bytes sent, 29032 received
>>
>>   Last clearing of "show vpdn" counters never
>>
>>     Receive packets dropped:
>>
>>       out-of-order:             0
>>
>>       total:                    0
>>
>>     Send packets dropped:
>>
>>       exceeded session MTU:     1
>>
>>       total:                    1
>>
>>   Session vcid is 1234
>>
>>   Session Layer 2 circuit, type is Ethernet, name is FastEthernet0/1
>>
>>   Circuit state is UP
>>
>>     Remote session id is 22201, remote tunnel id 12358
>>
>>   Session PMTU enabled, path MTU is 1500 bytes
>>
>>   DF bit on, ToS reflect disabled, ToS value 0, TTL value 255
>>
>>   No session cookie information available
>>
>>   UDP checksums are disabled
>>
>>   SSS switching enabled
>>
>>   Sequencing is on
>>
>>     Ns 114, Nr 116, 0 out of order packets received
>>
>>   Unique ID is 1
>>
>>  
>>
>> %No active PPTP tunnels
>>
>>  
>>
>>  
>>
>> Upon looking further I could see the DF bit on which I believe would
>>     
> explain
>   
>> the 1440 byte limit I hit.  But with that disabled I am puzzled or missing
>> something as to why I cannot fragment packets up to full 1500?   What I am
>> missing here?  Do I need to make MTU adjustments towards the FastE0/1
>> interface to force fragmentation before the l2tpv3 tunnel?
>>
>>  
>>
>> Thanks in advance,
>>
>>  
>>
>> Paul
>>
>> _______________________________________________
>> 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/
>>   
>>     
>
>   