GRE is used to encapsulate an arbitrary layer protocol over another arbitrary layer protocol. In general, GRE allows a tunnel to be created using a certain protocol, which then hides the contents of another protocol carried within the tunnel. Tunneling provides a mechanism to transport packets of one protocol within another protocol. The protocol that is carried is called as the passenger protocol, and the protocol that is used for carrying the passenger protocol is called as the transport protocol. Generic Routing Encapsulation (GRE) is one of the available tunneling mechanisms which uses IP as the transport protocol and can be used for carrying many different passenger protocols. The tunnels behave as virtual point-to-point links that have two endpoints identified by the tunnel source and tunnel destination addresses at each endpoint.
A GRE packet header structure is represented in the diagram below.
The interesting fields in this header are as follows:
Flags- The following descriptions are taken from RFC 1701 with comments added for clarification:
- Checksum Present (bit 0)- If the Checksum Present bit is set to 1, the checksum field is present and contains valid information. If either the Checksum Present bit or the Routing Present bit is set, both the Checksum and Offset fields are present in the GRE packet.
- Routing Present (bit 1)- If the Routing Present bit is set to 1, the Offset and Routing fields are present and contain valid information. If either the Checksum Present bit or the RoutingPresent bit is set, both the Checksum and Offset fields are present in the GRE packet.
- Key Present (bit 2)- If the Key Present bit is set to 1, the Key field is present in the GRE header. Otherwise, the Key field is not present in the GRE header.
- Sequence Number Present (bit 3)- If the Sequence Number Present bit is set to 1, the Sequence Number field is present. Otherwise, the Sequence Number field is not present in the GRE header.
- Strict Source Route (bit 4)- It is recommended that this bit be set to 1 only if all the routing information consists of strict source routes.
- Recursion Control (bits 5-7)- Recursion control contains a 3-bit unsigned integer that contains the number of additional encapsulations that are permissible. This should default to 0.
- Version Number (bits 13-15)- The Version Number field must contain the value 0.
• Protocol Type- The Protocol Type field contains the protocol type of the packet in the payload of the GRE packet. For example, when IP is the protocol being carried inside the GRE packet, this field is set to 0x800.
• Checksum- This field is used to ensure the integrity of the GRE header and the payload packet. It contains an IP checksum of the GRE header and the payload packet.
• Key- The Key field contains a number that is used to authenticate the GRE packet's encapsulator. This is a very weak form of security offered by GRE. In essence, the key prevents misconfiguration or injection of packets from a foreign source. The two tunnel endpoints accept GRE packets only with the correct key in the header. The key needs to be manually configured on both the endpoints. This is obviously not a feature to be relied on for security, because as soon as an attacker figures out the key simply by looking at a GRE packet, he or she can generate as authentic a GRE packet as the original encapsulator.
Another use of the key is to identify individual traffic flow within a tunnel. For example, packets might need to be routed based on context information not present in the encapsulated data. The Key field provides this context and defines a logical traffic flow between encapsulator and decapsulator. An example of this is the not very widely-deployed multipoint GRE tunnels. These tunnels require that a key be defined in order for the traffic to be distinguished. For the sake of this chapter, we will focus on the more common point-to-point GRE tunnels.
• Sequence Number- The two endpoints can use the sequence number to track the sequence in which packets are being received and optionally drop packets that arrive out of sequence. This is useful when carrying passenger protocols that function poorly when they receive packets out of order (such as LLC2-based protocols).
• Routing- The Routing field lists Source Route Entries (SREs). This field is not very commonly used. It is used when there is a need to do source routing on GRE packets.
hi,currently only CPU and memory are being monitored in solarwinds for our cisco switches: 3850, 9300, N5K, ME3600x, etc.i would need to add hardware monitoring for the hot swap modules, i.e. fans and power supply.is there a specific SNMP trap that i need...
hi,currently only CPU and memory are being monitored in solarwinds for our cisco ASR1K routers.i would need to add hardware monitoring for the ASR modules, i.e. fans, power supply, and route processors.is there a specific SNMP trap that i need to configur...
Hi All, We have 4 sites, each site has its DHCP server, we changed that to be one DHCP server at the HQ office and all other sites will be assigned TCP/IP configuration from that one DHCP server. On each site, we configured DHCP Relay "ip-...
Hi, Glad that I'm part of this community. Expert in GNS and Cisco, I really need your help. I can't ping my Microsoft KM-Test Adapter from GNS router. McAfee Live Firewall and Real-Time Scanning already disable but to no avail. What would be the problem h...
Hello, guys, I am using cisco packet tracer I used for configuration all ipv6 and I have faced problem in frame relay I configured it but still does not work I will upload the packet. plz, help thank you.