01-11-2002 09:29 AM - edited 02-21-2020 11:33 AM
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
01-18-2002 07:02 AM
The DF bit is probably being set by the Lotus and Intranet servers themselves. Youll have to set the MTU to 1400 on those servers.
02-07-2002 12:46 PM
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.
02-27-2002 07:58 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide