l2tpv3 and mtu issues

[tgurney]

Has anyone configured l2tpv3 using pseudowire configs? Currently configured as:

pseudowire-class class42

encapsulation l2tpv3

ip local interface Loopback1

ip pmtu max 1400

ip dfbit set

Haven't had a chance to sniff it yet but appears some servers are unable to create tcp connections when mtu is set to higher than 1358 in our case.

Ideas?

[mchin345]

Can you post a show tech from router and brief description of the topology?

[tgurney]

A show tech from two routers and a visio drawing. Note two metroE links between the VISI and Berbee environments. Note that the two vlan 37's at each site are separate and unique to each other.

Attempting to bridge 4 vlans between Berbee and VISI. In pseudo-wire classes I've set ip pmtu max 1400. We are having major problems with TCP sessions and MTU. It appears that if server MTU is set to 1358 then nothing fails. So the workaround is to set MTU on servers to 1350.

Appears to me that when a server with MTU higher than 1358 sends a packet larger then 1358 and has df bit set the packet is dropped by the 7206's and an ICMP 3 4 is sent with a MSS of 1358. Servers should then negotiate back down. That doesn't seem to be happening. Cisco says the network is working correctly and I have to agree from a theoretical point, but this seems like something fundamental within the l2tp config.

[rakesh.hegde]

The answer to your question is in your configureation itself. Take out " ip df bit set " from the psudowire class to allow packets to be fragmented before tunneling

-Rakesh

[tgurney]

I took the ip dfbit set out of the configuration last week. Still having issues with large packets.

[rakesh.hegde]

What you are seeing over L2TPV3 may be a symptom not the problem itself. Looks like you are having issues with TCP MSS vlaue. Tse servers are using a MSS value thats would require frangmentation. The router can not do that because the DF bit it set. You have two options.

1. apply a policy map to the interface to cleat the df bit

access-l 100 permit tcp any any

route-map cleardf

match ip address 100

set ip df 0

int gig x/x

ip policy rotue-map cleardf

2. Adjust MSS value to 1300 (MTU is MSS+40 ) for any TCP connections on the router

int gig x/x

ip tcp adjust-mss 1300

I have mostly used option 2

HTH

-Rakesh

[tgurney]

Rackesh , I like the route map option .

So si the best place for that on the 7206 dot1q subinterface ? Or the l2tpv3 loopback interfaces?

[rakesh.hegde]

IF the topology is some thing is like

6500 L3 Vlan 10 interface -> subinterface gig x/x.10 on the 7206 with xconnect.

I would apply it to Vlan 10 on 6500. I would leave the 7206 (the edge router) alone to do jsut L2TPV3.

I have implemented L2tpV3 with IPSEC encryption for one of our customers. Initially I had EIGRP neighbor flap because of MTU. I fiexed it by not removing PMTUD and DF bit commands from the psudo wire class

HTH

-Rakesh

[rakesh.hegde]

The last sentence should read 'I fiexed it by removing PMTUD and DF bit commands from the psudo wire class '

-Rakesh

[cemosoccer1]

Removing PMTUD and DF bit commands from the psudo wire class worked for me.

Thanks Rakesh

[steve_mils]

Hi - did you ever figure out what was happening here. We see the same problem and suspect that the problem can be fixed by patching the servers with the latest service pack. For example see the following link for Windows 2003 servers:

http://support.microsoft.com/kb/925280

If this is the case then it proves that the network does indeed work. We're yet to try this ourselves but I'm wondering if you ever did this; or were your servers already patched?

Cheers, Steve