[c-nsp] l2tpv3 config - MTU question
Ge Moua
moua0100 at umn.edu
Thu Feb 26 12:50:33 EST 2009
Ok, I see.
Are you seeing this with more than one test workstation. I wonder if it
is a end-station issue.
df=off should allow for large ping payloads
what is the syntax you are using on the end-workstation.
Regards,
Ge Moua | Email: moua0100 at umn.edu
Network Design Engineer
University of Minnesota | Networking & Telecommunications Services
Paul Stewart wrote:
> 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