Some applications set the DF-bit in the IP header to 1. When using IPSEC in ESP mode, your original IP packet is encapsulated and a new (ESP) header is put on the packet. Due to this the original datagram size is enlarged. Depening on the size, it may exceed the maximum MTU of Ethernet/FastEthernet. Your ISP will most likely use Ethernet somewhere on your path to the other side. So the packets cannot be fragmented when the DF-bit is set to 1. The device that has to take care of this fragmentation will send a specific ICMP message to the sender (don't remember the exact number), requesting to set the DF bit to 0. When the originator can receive this ICMP request it will set its DF-bit to 0 when resending. This last part is the problem since ICMP is blocked on most Firewalls. Changing the maximum size of the original (non-encapsulated) packets seems the best solution.
You can change the MTU on your end devices, but that's not a practical solution. The best solution seemed to be a reset of the tcp-mss value in the IP header during the 3-way tcp handshake. During this handshake you can enforce the Maximum Segment Size (=MTU) to be used in the data flow.
I don't know if this can be done on a Cisco router. We use Netscreen for our Branch Office IPSEC VPN's and there you can do this with this command: set flow tcp-mss 1392 (default is 1492 of course, 1450 will do the trick as well, ESP header isn't that big). If anyone knows how to do this on a Cisco, please post this information.
MPLS gives you no security at all. To me it seems like a big VLAN, adding tags or ids to your packets, but not encrypting your data at all. Security is out of your hands. If you use it, combine it with IPSEC.
Changing the MTU size is advisable when working with IPSEC tunnels in situations when dealing with very large UDP and TCP packets Many servers and workstations have a Default MTU value of 1492 and when these types of packets with IPSEC headers are passed through a UAC on 6400 and 7200 series devices they get dropped regardless of MTU size configured on the the network devices so in this scenario tweaking MTU on the WS or server would be advisable.
Strict IPSEC traffic set MTU size for -50 of max MTU of suspect interface
GRE tunneling over IPSEC set MTU size between -60 to 100 would be a best guess
When working with VIDEO packets mack sure that your packets are divisible by 188 or you suffer quality in streams
So for Ethernet
1492 - 50
8192 - 50
Will vary but You shouldn't have to change MTU on ATM I don't think you'll see a benefit in performance either way.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :