No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


GRE Failed to Set up Tunnels Due to the Inconsistency of Fragmentation and Reassembly Mechanisms Between the Local and Peer Devices

Publication Date:  2012-07-27 Views:  98 Downloads:  0
Issue Description
The GRE tunnel is established between the NE40E and the router produced by company E to carry the multimedia message (MMS) service. Some Dopod and SonyEricsson handsets failed to send or receive MMSs.
For the networking, refer to the Appendix. 
Alarm Information
Handling Process
1. Checking the configuration of the NE40E, the engineer found that the MTU value was 1600. Catching packets for analysis, the engineer found that MMS packets to and from Dopod and SonyEricsson handsets were larger than 1,600 bytes. Then the engineer used the GRE fragmentation mechanism to divide a large packet into two fragments on the NE40E. For the screen shot of packet catching, refer to the Appendixes "Fragment 1 Catching" (No. 11) and "Fragment 2 Catching" (No. 12).
The Appendixes show the difference between fragments 1 and 2:
Fragment 1 is encapsulated in three layers: external IP header + GRE header + internal IP header
Fragment 2 is encapsulated in one layer: external IP header
Note: According to the descriptions in the GRE protocol, the external IP header = the source IP configured for the GRE tunnel (; the internal IP header = the source IP of the packet before GRE encapsulation (
2. Analysis: The external IP header and the GRE header are meaningless to the end users outside the tunnel. Users only require the original internal IP header. Only the first fragment of the packet after the GRE fragmentation has the internal IP header, and the subsequent fragments do not have the internal IP header. If the peer device does not reassemble and process the fragments, the subsequent fragments cannot be reassembled with the first fragment after reaching the peer, and continue to be forwarded.
3. During the GRE fragmentation and reassembly, the VRP made by Huawei sends the GRE packet to the interface board for fragmentation. Because the interface board can only recognize the type of packet to be fragmented is GRE packet, only the first fragment has an internal IP header (private network address) and the subsequent fragments only have external IP headers. If the packet shall run out of the tunnel and be forwarded after fragments reach the peer device, the fragments are to be reassembled on the GRE board. The reassembly is performed according to the external IP header rather than the internal IP header.
4. Obviously, the device produced by company E also fragmentizes and reassembles GRE fragments according to the internal IP header rather than the external IP header. Therefore, fragments cannot be resembled, and the tunnel cannot be established. 
Root Cause
1. Because the MMS services carried by the GRE tunnel between the NE40E and GGSN of Huawei was normal, the problem was probably caused by the cooperation between the NE40E and the router produced by company E.
2. Because only some Dopod and SonyEricsson handsets failed to send or receive MMSs, the problem was caused by the comparatively large packets sent and received by the handsets, according to the analysis of A&S engineers. Therefore, the engineer set about checking the MTU value and the GRE fragmentation mechanism. 
1. The local and peer devices shall perform GRE fragmentation and reassembly under the same mechanism to ensure the establishment of the tunnel.
2. If the processing mechanisms on the local and peer devices are not the same, increase the MTU value to avoid fragmentation and evade the problem.