Cost effective solutions for private internetwork communication have utilized technologies such as IPSec to enable shared public networks to act as a medium for bridging the gap between remote offices. This solution provides secure transmission to IP packet payloads but does not enable routing protocols such as RIP and OSPF to be carried between the two tunnel endpoints. GRE was originally developed as a means of supporting the transmission of protocols such as IPX through IP networks, however over time the primary role of GRE has transitioned towards the support of routing based protocol tunneling
GRE can be applied within an autonomous system to overcome certain limitations found in IGP protocols. RIP routes offer for example a hop limit of 15 hops beyond which all routes are subjected to the count to infinity rule. The application of GRE in such environments will allow for a tunnel to be created over which routing updates can be carried, allowing the scale of such distance vector routing to be increased significantly where necessary
One of the major limitations of GRE is in its lack of ability to secure packets as they are carried across a public network. The traffic carried within a GRE tunnel is not subjected to encryption since such features are not supported by GRE. As a result IPSec solutions are employed together with GRE to enable GRE tunnels to be established within IPSec tunnels to extend features including integrity and confidentiality to GRE.
After receiving a packet from the interface that is connected to the private network, the packet is delivered 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 outgoing interface in the routing table or forwarding table of the private network, and determines how to route this packet. If the outgoing interface is the tunnel interface, the private network protocol module sends the packet to the tunnel module.
After receiving the packet, the tunnel module firstly encapsulates the packet according to the protocol type of the passenger protocol and checksum parameters are configured for the current GRE tunnel. That is, the tunnel module adds a GRE header to the packet. It next adds an IP header according to the configuration. The source address of this IP header is the source address of the tunnel; the destination address of the IP header is the destination address of the tunnel, following which the packet is delivered to the IP module. The IP module searches for the appropriate outgoing interface in the public network routing table based on the destination address in the IP header, and forwards the packet. The encapsulated packet is then transmitted over the public network.
After receiving the packet from the interface that is connected to the public network, the egress interface analyzes the IP header, determines the destination of the packet and discovers the Protocol Type field is 47, indicating that the protocol is GRE.
The egress interface delivers the packet to the GRE module for processing. The GRE module removes the IP header and the GRE header, and learns from the Protocol Type field in the GRE header that the passenger protocol is the protocol run on the private network, the GRE module then delivers the packet to this protocol. The protocol itself handles the packet as with any ordinary packet.
Key authentication indicates the authentication on a tunnel interface. This security mechanism can prevent the tunnel interface from incorrectly identifying and receiving the packets from other devices. If the K bit in the GRE header is set to 1, the Key field is inserted into the GRE header. Both the receiver and the sender perform the key authentication on the tunnel.
The Key field contains a four-byte value, which is inserted into the GRE header during packet encapsulation. The Key field is used to identify the traffic in the tunnel. Packets of the same traffic flow have the same Key field. When packets are decapsulated, the tunnel end identifies the packets of the same traffic according to the Key field. The authentication can be passed only when the Key fields set on both ends of the tunnel are consistent, otherwise the packets are discarded.
The keepalive detection function is used to detect whether the tunnel link is in the keepalive state at any time, that is, whether the peer of the tunnel is reachable. If the peer is not reachable, the tunnel is disconnected to prevent black holes occuring. After the Keepalive function is enabled, the local end of the GRE tunnel periodically sends a keepalive detection packet to the peer. If the peer is reachable, the local end receives a reply packet from the peer. The keepalive function will operate as long as at least one end is configured with the keepalive function, the peer does not need to have the keepalive function enabled. If the peer receives a keepalive detection packet, it sends a reply packet to the local end, irrespective of whether it is configured with the keepalive function.
After the keepalive function is enabled, the source of a GRE tunnel creates a counter, periodically sends the keepalive detection packets, and counts the number of detection packets. The number increments by one after each detection packet is sent.
If the source receives a reply packet before the counter value reaches the preset value, the source considers that the peer is reachable. If the source does not receive a reply packet before the counter reaches the preset value that defines the number of retries, the source considers that the peer is unreachable and will proceed to close the tunnel connection.
The establishment of GRE requires initially the creation of a tunnel interface. After creating a tunnel interface, specify GRE as the encapsulation type, set the tunnel source address or source interface, and set the tunnel destination address. In addition, set the tunnel interface network address so that the tunnel can support routes. Routes for a tunnel must be available on both the source and destination devices so that packets encapsulated with GRE can be forwarded correctly. A route passing through tunnel interfaces can be a static route or a dynamic route.
One other key point that should be taken into account during the configuration phase is the MTU. GRE results in an additional 24 bytes of overhead being applied to the existing headers and payload, resulting in the potential for unnecessary fragmentation to occur. This can be resolved by adjusting the MTU size using the mtu <mtu> command to allow packets to compensate for the additional overhead created. An MTU of 1476 is considered a sufficient adjustment to the MTU, to reduce additional load on the interface.
The running status and routing information for the GRE tunnel interface can be observed following the creation of the tunnel interface. An active tunnel interface can be confirmed when the tunnel’s current state and link layer (line) protocol state are both showing as UP. Any adjustment to the existing MTU can be identified to ensure that additional overhead is not created as a result of fragmentation. The Internet address represents the configured tunnel IP address at the egress interface. The tunnel source and destination displays the IP addresses of the physical interface that are being used, over which the GRE tunnel is established.
The reachability of networks over the GRE tunnel can be determined based on the IP routing table that is viewed using the display ip routing table command. In this case it is possible to identify the internal source network address of a local network, and its ability to reach the destination network address of a remote network over a GRE based tunnel interface. The destination address refers to the network address that is reached over the GRE tunnel, while the next hop address references the IP address of the GRE remote tunnel interface
The keepalive function can enabled on the GRE tunnel interface by specifying the keepalive [period <period> [retry-times <retry-times> ] ] command, where the period determines the number of seconds taken before each keepalive is sent, this by default is set to a period of 5 seconds. The number of times for which a keepalive will be sent is defined using the retry-times <retry-times> parameter, which by default is set to 3 tries. If the peer fails to respond within the number of retries defined, communication between the two ends of the tunnel will be considered to have failed and the GRE tunnel will proceed to be torn down.
The display interface tunnel command can again be applied to assess whether the tunnel is still active following a loss of communication between the GRE tunnel endpoints. In the example it is found that the link layer status of the GRE tunnel has transitioned to a down state denoting that a failure in communication has occurred. The keepalive function is currently enabled and displays a keepalive period of three seconds between each message sent. The number of retries has also been determined as allowing a loss of replies up to three times.
GRE provides a means for establishing dynamic routing between remote networks that commonly belong to a single administrative domain such as in the case of branch offices. IPSec VPN is generally used to provide a site-to-site private tunnel over which routing dynamic information may wish to be transmitted, however IPSec VPN tunnels will not support the forwarding of routing updates over IPSec directly, therefore GRE is implemented.
The Internet address represents a virtual tunnel network address over which the GRE is established, while the tunnel source references the entry-point at which the tunnel is established.