MTU problems with MPLS

[killermonkeys]

I have discovered that one of my routers, a 7206VXR with a PA-FE-FX "does not support user settable mtu". This seems to be causing a problem with some customers with firewalls (Path MTU Discovery isn't working on them...).

I have turned up the MTU to 1526 on all interfaces and turned the MPLS MTU setting down, but I cannot make these problems go away. Are there any workarounds for this? Are there any means at all for forcibly fragmenting packets?

As I said the router in question is a 7206VXR, NPE-300 and the interface is a PA-FE-FX, it is running IOS 12.2(10b).

[Harold Ritter]

Are you simply setting up MPLS VPN?

You don't need to change the interface MTU. You need to set the "mpls mtu" to 1524 which would allow you up to 6 labels.

Hope this helps,

[killermonkeys]

This is for regular MPLS, not a VPN. Perhaps I am looking for the solution in the wrong place? Here is a more detailed look:

(bgp peer) PE1 PE2 (eigrp) R3

PE1 and PE2 are MPLS, R3 is a provider router that does not (yet) do MPLS.

PE1 has a eBGP peer with several colocated servers off it. R3 has DSL customers on it.

When customers attempt to go to certain sites off PE1 with firewalls they are unable to, however unfirewalled sites are accessible.

Pinging and tracing always works, however when attempting a TCP connection it appears to have significant drops and is ultimately unusable.

My theory is that the lack of Path MTU discovery is causing the hosts to be inaccessible. I have tried with tag-switching mtu 1524, 1500, and 1508 on both sides of the PE1 and PE2.

Turning off tag-switching between PE1 and PE2 solves the problem, so that is unfortunately the solution I have adopted for the time being.

The particulars of the problem: only certain hosts which all seem to be firewalled, pings always successful, packets at greater than 1496+ fail.

[Harold Ritter · Accepted solution]

What type of switch do you use between PE1 and PE2. Make sure it does support baby giant frames.

Hope this helps,

[killermonkeys]

I am using catalyst 2900XL's running IOS 12.0(5.2)XU, which support configurable MTU up to 2018. I have tried it with the maximum MTU available as well as 1526 on both interfaces with no change. One side is also an ISL trunk. Is it possible that ISL + MPLS is the problem?

[killermonkeys]

PE1#ping

Protocol [ip]:

Target IP address: H1

Repeat count [5]: 1

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]: y

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]: y

Sweep min size [36]: 1480

Sweep max size [18024]: 1500

Sweep interval [1]:

Type escape sequence to abort.

Sending 21, [1480..1500]-byte ICMP Echos to H1, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!....

Success rate is 80 percent (17/21), round-trip min/avg/max = 56/59/60 ms

This is a ping from PE1 to H1 (which is off PE2).

It talks about this problem in MPLS and VPN Arch Vol II, and specifies that procedure and says that this indicates a failure of either a LSP or a switch that doesn't support baby giants. As my switch does support them appropriately, I am thinking it is the PA at fault, but I can find no documentation about what MTU it supports and whether MPLS works through it.

Thanks,

Kenny

[Harold Ritter]

All the information I could find internally is indicating that the pa-fe-xx does support baby giants up to 1534. Could have something with the trunk configuration on the switch.

Hope this helps,

[Peter_T]

I am sure if it would work, but you can probably try "ip mtu 1460" on the outgoing interface so that IP fragmentation would take place before adding MPLS tag.

[autobot130]

Since you cannot adjust the MTU by using the "ip mtu xxx" command.... try to change the TCP windowing down.

Command: (config-if)#ip tcp adjust-mss 1436

Might need to play around with the number to find what is acceptable to your applications.

[killermonkeys]

What I ended up doing was: connect a 7500 to a 7200 both with PA-FE-TX, and it worked. Then I plugged in a 2900XL switch in between them. This did not work. I set mtu on the two ports on the switch. I then (after tearing hair, jumping up and down, etc) rebooted the switch. The switch came back up in with the interfaces already configured for MTU 2018. This finally worked. 12.0(5.2)XU is the version that all the switches in question were running.

The other problem that I realized was that the path that was working was actually going through a 3550, not a 2900XL.

So I reloaded the switches in question that evening, and low and behold, everything was peachy, 1500 byte packets worked again. I can't really guess why this is the case, but reload + coming up configured with MTU works, configuring the MTU to be larger while running doesn't. I should also mention that these ports are actually WS-X2922-XL-V and WS-X2924-XL-V modules, not the regular ports... I know, I know.

I've heard stranger things and I'm happy to get so rest now and play with the new features MPLS provides. You guys were very helpful, particularly hritter, in pointing me toward the switches, otherwise I would have probably replaced the PA-FE with a gigabit card.