A single network protocol, such as IPv4, is used to transmit packets on a backbone network, whereas other protocols, such as IPv6 and Internet Packet Exchange (IPX), are used to transmit packets on non-backbone networks. Because the backbone and non-backbone networks use different protocols, packets cannot be transmitted between the non-backbone networks over the backbone network. Generic Routing Encapsulation (GRE) resolves this issue by providing a mechanism of encapsulating the packets of a protocol into the packets of another protocol.
On the network shown in Figure 1, groups 1 and 2 are the non-backbone networks running Novell IPX, and teams 1 and 2 are the non-backbone networks running IPv6. The backbone network is an IPv4 network. To transmit packets between groups 1 and 2 and between teams 1 and 2 over the backbone network, use GRE to establish a tunnel between Device A and Device B. When Device A receives a packet from group 1 or team 1, Device A encapsulates the packet into a GRE packet. The GRE packet is then encapsulated into an IPv4 packet for forwarding.
GRE packet format
After receiving a network layer protocol packet that needs to be encapsulated and routed, such as an IPX packet, the system adds a GRE header to the packet and encapsulates the packet into another protocol, such as IP. Then, the IP protocol is responsible for forwarding the packet. Figure 2 shows the format of a GRE packet.
Payload: is received by the system and needs to be encapsulated and routed.
Passenger protocol: is used by the packet before encapsulation.
Encapsulation protocol: is used to encapsulate passenger protocol packets. It is also called the carrier protocol.
Transport or delivery protocol: is responsible for forwarding the encapsulated packets.
The following shows the format of an IPX packet encapsulated for transmission over an IP tunnel.
Figure 4 shows the format of a GRE header.
The meaning of each field is as follows:
C: indicates the Checksum bit. If it is set to 1, the Checksum field is present in the GRE header; if it is set to 0, the GRE header does not contain the Checksum field.
K: indicates the Key bit. If it is set to 1, the Key field is present in the GRE header; if it is set to 0, the GRE header does not contain the Key field.
Recursion: indicates the number of times that a packet is encapsulated by GRE. This field increases by one after each encapsulation. If the number of encapsulations is greater than 3, the packet is discarded. This field is used to prevent a packet from being encapsulated infinitely.
According to relevant standards, the default value of the Recursion field is 0.
According to relevant standards, no errors will occur if the Recursion field value on the transmit end is different from that on the receive end. The receive end ignores this field.
The Recursion field is only used to indicate the number of times that a packet is encapsulated by GRE. When GRE decapsulates a packet, it is unaware of this field.
Flags: indicates the reserved field. At present, it must be set to 0.
Version: indicates the version number. It must be set to 0. Version number 1 is used by PPTP as defined in relevant standards.
Protocol type: indicates the type of the passenger protocol.
Checksum: indicates the checksum of the GRE header and the payload.
Key: indicates the Key field. It is used by the receive end to authenticate the received packet.
On a device, the GRE header does not contain the Source Route field. Therefore, Bit 1, Bit 3, and Bit 4 are all set to 0.
The transmission of packets over a GRE tunnel can be divided into two phases: encapsulation and decapsulation. On the network shown in Figure 5, a private network packet is encapsulated on the ingress PE and decapsulated on the egress PE.
After the ingress PE receives a private network packet, the ingress PE delivers the packet to the private network protocol module for processing.
The private network protocol module checks the destination address field in the private network packet header, searches the routing table or forwarding table of the private network for the outbound interface, and determines how to route this packet. If the outbound interface is the GRE tunnel interface, the private network protocol module sends the packet to the tunnel module.
Upon receipt of the packet, the tunnel module processes the packet as follows:
Adds a GRE header to the packet. Specifically, the tunnel module encapsulates the packet according to the protocol type of the Passenger packet and the Key parameter configured for the current GRE tunnel.
Adds a transport protocol header to the packet based on the configuration. For example, if the transport protocol is the IP protocol, the source and destination addresses carried in the IP header are the source and destination addresses of the tunnel.
Delivers the packet to the IP module. Based on the destination address in the IP header, the IP module searches the public network routing table for the outbound interface and sends the packet. The encapsulated packet is then transmitted on the IP public network.
The decapsulation process is opposite to the encapsulation process. After the egress PE receives the packet, the egress PE analyzes the IP header. After determining that the destination of the packet is itself and the Protocol Type field is 47, which indicates that the protocol is GRE (see relevant standards and 2784), the egress PE delivers the packet to the GRE module for processing. The GRE module removes the IP and GRE headers and learns from the Protocol Type field in the GRE header that the Passenger protocol is the protocol running on the private network. The GRE module then delivers the packet to the module corresponding to this protocol, which forwards the packet as an ordinary packet.
GRE offers the following benefits:
Enables packets to be transmitted between networks running different protocols using a single network protocol.
Enlarges the scope of route transmission.
Connects discontinuous sub-networks for VPN establishment.