GRE Fundamentals

Implementation

Packets transmitted over a GRE tunnel undergo encapsulation and decapsulation processes. An ingress provider edge (PE) device encapsulates packets of the X protocol and transmits them across a GRE tunnel, and the egress PE device decapsulates the packets. Figure 1 shows this process.

Figure 1 Transmitting X protocol packets over a GRE tunnel

The packet encapsulation process is as follows:
1. The ingress PE receives an X protocol packet from the interface connected to the X network, and sends it to the X protocol.
2. The X protocol checks the destination address in the packet header and searches the routing table or the forwarding table for the outbound interface. If the outbound interface is a GRE tunnel interface, the ingress PE adds a GRE header to the packet.
3. Since the backbone network runs the IP protocol, the ingress PE adds an IP header to the packet. The source address and destination address in the IP header are the tunnel source and destination address, respectively.
4. The ingress PE searches the IP routing table for the outbound interface based on the destination address in the IP header (tunnel destination address) and transmits the packet over the IP backbone network.
For details on the format of the encapsulated packet, see Packet Format.
The decapsulation process is a reversal of the encapsulation process.
1. The egress PE receives the packet from the GRE tunnel interface and analyzes the IP header in the packet finding that the egress PE itself is the destination. The egress PE then removes the IP header and delivers the packet to the GRE protocol for processing.
2. The GRE protocol removes the GRE header and delivers the packet to the X protocol.

Packet Format

Figure 2 shows the format of a GRE-encapsulated packet.

Passenger protocol: indicates the protocol of the original packet. The original packet is encapsulated in a GRE packet as the payload.
Encapsulation protocol (carrier protocol): indicates the protocol used to encapsulate passenger protocol packets by adding a GRE header.
Transport protocol (delivery protocol): indicates the protocol used to transmit encapsulated packets.

Figure 2 GRE packet format

Table 1 describes the fields in a GRE header.

**Table 1** Description of fields in a GRE header
Field	Description
C	Checksum bit. 1: The GRE header contains the Checksum field. 0: The GRE header does not contain the Checksum field.
K	Key bit. 1: The GRE header contains the Key field. 0: The GRE header does not contain the Key field.
Recursion	Number of times a packet is encapsulated by GRE. The value of this field is incremented by 1 every time the packet is encapsulated. If the packet is encapsulated more than three times, the device discards the packet. This field prevents a packet from being encapsulated infinitely. NOTE: According to RFC1701, the default value of this field is 0. According to RFC2784, no error will occur if the field value on the transmit end is different from that on the receive end, and the receive end must ignore the field. This field is only used to indicate the number of times a packet is encapsulated. During GRE decapsulation, this field does not affect packet processing.
Flags	Reserved field. The value must be set to 0.
Version	Version number. The value must be set to 0.
Protocol Type	Passenger protocol type. A common passenger protocol is IPv4 protocol, with a value of 0800.
Checksum	Checksum of the GRE header and the payload.
Key	Keyword. This field is used to authenticate the packet at the receive end.

Currently, the GRE header does not contain the Source Route field; therefore, bit 1, bit 3, and bit 4 are all set to 0.