1. If I don't set the tunnel interface a command "tunnel path-mtu-discovery", the tunnel0 interface will not perform PMTUD as it will clear the DF bit after encap the packets and then send to IPSec for encryption. This is the current configuration of my router. But why I also can see the icmp unreachable(type 3, code 4) sent by this router to my hosts in LAN? Does the tunnel0 interface still sends icmp unreachable to hosts which send packets with DF bit 1 even though the "tunnel path-mth-discovery" not be enabled?
2. After I read the Cisco document mentioned above, I decide to set "ip tcp adjusted-mss 1360" to ethernet interface which point to my LAN in order to tell the hosts to send MSS which meet the IPSec packet size and set "tunnel path-mth-discovery" to let the tunnel0 interface to add DF bit 1 to new encapsulated GRE packets' IP header so that IPSec will not fragment those GRE packets. Is this decision right?
The IPSec crypto map is applied to one of the Gigabit Ethernet interface of the 2821. Another Gi0/1 is for LAN. One tunnel0 interface. Loopback0's IP is the tunnel source.
MTU 1476 in "show ip int tunnel0"
MTU 1514 in "show int tunnel0" and "show int loopback0"
MTU 1500 in "show int gi0/1" and "show int gi0/0"
Path MTU 1500 in "show crypto ip sa"(Gi0/1 has crypto map point to another Cisco 2821)
1) If you do not set the PMTUD - it does not "clear" the DF bit. It just does not copy the DF bit in the GRE header.
2) If you have already set the tcp mss adjust command - there should be no requirement for you to also enable the PMTUD - as any packet that traverses the tunnel AFTER TCP SYN/TCP SYN ACK will NEVER exceed the tunnel MTU even with the DF bit set.
Personally I have found that when dealing with "Windows" PC's and Servers PMTU and PMTUD does not work. Within networking I have found, the below:-
1) Calculate the best MTU/MSS for GRE/IPSEC - giving some "fudge"
2) When using tcp-adjust-mss - place on the tunnel interfaces.
1) If a router tries to forward an IP datagram, with the DF bit set, onto the tunnel that has a lower MTU than the size of the packet, the router will drop the packet and return an ICMP "Destination Unreachable" message is sent back to the source of the IP datagram, with the code indicating "fragmentation needed and DF set". When the source station receives the ICMP message, it will lower the send MSS, and when TCP retransmits the segment, it will use the smaller segment size. BUT I have found that windows IGNORES the icmp "fragmentation needed" - even when PMTU and PMTUD are enabled on the servers/workstations.
2) I personally have implemented it on the tunnel interfaces in networks where I have found this issue. Personally I configure as close to the source as the problem as possible - in this instance the tunnel, but it's not really close to the issue. What you could do is just lower the MTU of the NIC's for all your devices at the site - however this does not scale well if you have to manually "touch" hundreds or thousands of machines.
Hi everyone, I would like to thank you in advance for any help you can provide a newcomer like myself!
Im studying the 100-105 book by Odom and am currently on the topic of Port security. I purchased a used 2960 and I'm trying to follow a...
While deploying a number of 18xx/2802/3802 model access points (APs), which run AP-COS as their operating platform. It can be observed on some occasions that while many of their access points were able to join the fabric WLC withou...
I am going to design and build an LAN network under a tunnel underground with long distance between the switches.
I will have 2 Catalyst switches and 8 Industrial IE3000, and they will be connected with fiber.
For now I am planning on use Layer-2 s...