Fragmentation on IPSec Links

[nohare]

I have a hub-spoke setup between a central site and 3 Remote sites. IPSec VPN tunnels establish fine and data can pass.....sort of. Any sized UDP packets are routed back-and-forth between the central and remote sites. TCP however causes some serious issues. At the central site they have a number of Intranet servers and Lotus Notes servers which the remote site users need to connect to. Whenever an attempt is made to connect to the servers (either Lotus or Intranet), the "Debug ip icmp" command on the central-site router displays a large number of entries saying that packets are too large and they need fragmenting but the DF bit is set. Initially, I tried changing the IP TCP MSS value on all 4 routers (3 remote, 1 central) to 1400 but this made no difference. I then used a route-map which sets the DF bit to zero for these TCP traffic flows, and again this made no difference.

Even with PATH-MTU-DISCOVERY enabled on all routers (which have full ICMP connectivity between rach other) it makes no difference.

The remote sites don't transmit that much heavy traffic so fragmentation is a possiblity (I am aware of performance issues with fragging).

Has anyone had this problem? And more importantly, can it be sorted ? Also, is there an alternative to fragging ??

Regards

Nathan

[a-vazquez]

The DF bit is probably being set by the Lotus and Intranet servers themselves. You’ll have to set the MTU to 1400 on those servers.

[jesschen]

Do you have "no ip unreachable" configured on those router interfaces? If you do, try to enable "ip unreachable". It did the trick for me, or try the following link.

http://www.cisco.com/warp/public/105/38.shtml

[wzhang]

Well, we need to first figure out who is at fault

here. The routers will do PMTUD by default, so any

packets larger than the outbound interface MTU will

be dropped and an ICMP 3/4 message is sent. It

appears that part is working. What you want to do is

to take a sniffer trace on the LAN segment between

the Lotus server and the router. You will be looking

for two things:

1. the advertised next-hop mtu in the ICMP packet

sent back by the router (plese see RFC1191) for the

packet format. This value should be the logical

outbound interface mtu (outbound interface ip mtu

minus the IPSec overhead). I've seen the router

not calculating this correctly. If this is the case,

open up a TAC case to have it addressed.

2. after the server receives the ICMP packet, does

it lower its MTU according to the advertised next-

hop mtu? It should. If it doesn't then it's

not doing PMTUD correctly.

Idealy, you don't want to fragment for best performance. However, you do have the choice to

have the router fragment if all else fails. You can

do this with one of the following two ways:

1. clear DF bit with the policy map. It should work,

hard to say why it's not without any debugs in your

case.

2. use the crypto DF bit override feature introduced

in 12.2T.

Other alternative is to use "tcp adjust-mss" to manipulate the MSS during TCP negotiation.