【problem analysis】
Let's start with an experiment and the
experiment topology is as follows:
PC1——-***Gateway1―――――***Gateway2——–PC2
In the above-mentioned networking, a GRE tunnel is established between VPN gateways 1 and 2, and PC1 and PC2 communicate with each other through the GRE tunnel.
At this time, we will find that when PC1 pings the 1448 packet, it is found on PC2 that the packet is not fragmented, and when ping 1449, PC2 will find that the packet from PC1 has been fragmented. why?
The length of the IP packet from PC1 is 1448 + 8 (ICMP header length) + 20 (IP header length), reaching *** gateway 1, *** gateway 1 is sent to the GRE tunnel port, encapsulating the GRE header (4 bytes), and adding The upper outer IP header reaches the outer Ethernet port of the VPN gateway. At this time, the length of the IP packet has become: 1448 + 8 + 20 + 4 + 20 = 1500 bytes, which is exactly equal to the MTU of the Ethernet port, so it is successfully transmitted. When pinging 1449, the outer Ethernet port is 1501 bytes, which exceeds the MTU of 1500, and because the DF bit of the message is not set to 1, it can be fragmented. The *** network is about sending the message in fragments. . This is what we are seeing.
In the above experiment, since the application is ping, the message can be fragmented, so there is no problem with intercommunication. However, if it is an application such as WEB access, some packets are not allowed to be fragmented. In this way, packets exceeding 1500 will be lost on the outer Ethernet port, resulting in communication failure.
It can be seen from the above experiment that because *** will add some additional headers, if the MTU of the two communication parties cannot be changed accordingly, it is easy to cause a problem of interoperability.
The following uses HTTP as an example to explain why this problem occurs and how to solve it.
Let's first look at why HTTP cannot automatically fragment communication like ICMP.
Suppose that after PC1/2 establishes an HTTP connection, PC2 hopes to download a large web page from PC1. PC2 starts sending, the DF position of its IP is 1, fragmentation is not allowed, and the length of the IP packet is 1500 bytes. After reaching the external network port of *** gateway 1, *** gateway 1 finds that its length exceeds 1500 bytes, so it discards it, and sends back an ICMP message that the destination address is unreachable to PC1. The error code is " Fragmentation needed" indicates that fragmentation is needed, but fragmentation is not allowed, and "MTU of next hop: 1500" is also given. After PC1 receives the message, it sends it out at 1500 bytes, but it is discarded, so it forms a loop and cannot communicate.
According to the above analysis, it is easy to get the following solution. Set the MTU to 1500-4-20=1476 on the outgoing interface of VPN gateway 1, so that when VPN gateway 1 returns an ICMP unreachable message, it will give "MTU of" next hop: 1476". PC2 will use 1476 as its maximum MTU to send to the outside world and reach the VPN gateway 1. After encapsulating the GRE and outer IP header, it will not exceed 1500 and will be sent to the opposite end smoothly.
At this time, only the download problem is solved. If PC2 needs to upload large files to PC1, it is also necessary to set the MTU value of the outgoing interface of *** gateway 2 to be less than 1476.
to sum up
Of course, you can also change the TCP MSS value of the outgoing interface of the VPN gateway 1, and change it to 1500-4-20-20 (TCP header)=1456 bytes, which can also ensure the smooth passage of TCP applications such as HTTP. But this situation only applies to TCP applications. The above-mentioned solution is also applicable to other tunnel technologies. In applications such as L2TP and IPSEC, the MTU or MSS can be set according to the value of its header.
This article is reproduced in the public account: Network Road Blog