[c-nsp] l2tpv3 config - MTU question
Paul Stewart
paul at paulstewart.org
Thu Feb 26 12:32:56 EST 2009
Thank you ...
Perhaps I should have explained a little more in depth - my problem at this
moment is that with dfbit=off I still cannot do a ping larger than 1472 and
can't understand why it's NOT being fragmented....;)
Cheers,
Paul
-----Original Message-----
From: Ge Moua [mailto:moua0100 at umn.edu]
Sent: Thursday, February 26, 2009 12:11 PM
To: Paul Stewart
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] l2tpv3 config - MTU question
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/
>>
>>
>
>
More information about the cisco-nsp
mailing list