enable dynamic exchange or routing information in the virtual network. Adding an additional GRE header between the payload and the tunneling IP header provides multiprotocol functionality. Default GRE Characteristics
Figure lists default GRE characteristics. GRE uses a protocol type field in the GRE header to support the encapsulation of any OSI Layer 3 protocol. GRE tunnels are stateless. This characteristic means that each tunnel endpoint does not keep any information about the state or availability of the remote tunnel endpoint. This feature helps service providers (SP) to provide IP tunnels to SP clients who are not concerned about the internal tunneling architecture at the SP end. This setup gives the users (the clients of SP) flexibility to configure or reconfigure their IP architecture without being concerned about connectivity issues, creating a virtual point-to-point link to routers at remote points over an IP internetwork. GRE does not include any strong security mechanisms to protect its payload. The GRE header, together with the tunneling IP header, creates at least 24 bytes of additional overhead for tunneled packets. Basic GRE Header
Figure shows a GRE tunnel header. A GRE tunnel header contains at least two 2-byte mandatory fields—the GRE flag and the protocol type:

• GRE flags: The GRE flags are encoded in the first two octets. Bit 0 is the most significant bit, and bit 15 is the least significant bit. Some of the GRE flags include the following:
  • Checksum Present (bit 0): If the Checksum Present bit is set to 1, the optional checksum field is present in the GRE header.
  • Key Present (bit 2): If the Key Present bit is set to 1, the optional Key field is present in the GRE header.
  • Sequence Number Present (bit 3): If the Sequence Number Present bit is set to 1, the optional Sequence Number field is present in the GRE header.
  • Version Number (bits 13–15): The Version Number indicates the GRE implementation version. A value of 0 is typically used for basic GRE implementation. Point-to-Point Tunneling Protocol (PPTP) uses Version 1.
• Protocol Type: The Protocol Type field contains the protocol type of the payload packet. In general, the value will be the Ethernet protocol type field for the packet. For IP, the hexadecimal value of 0x800 is used. This field enables the GRE to tunnel any OSI Layer 3 protocol.

Optional GRE Extensions
The GRE tunnel header can contain additional optional header information, depending on the flags in the first two bytes of the GRE header. Figure shows the optional GRE header information that can include the following:

• Tunnel checksum: The tunnel checksum detects packet corruption. This option is not used often because checksums are used on other layers in the protocol stack, typically to ensure the accuracy of the GRE packets.
• Tunnel key: Can be used for two purposes:
  • The tunnel key can be used for basic plaintext authentication of packets in which only the two GRE endpoints share a secret number that enables the tunnel to operate properly. However, anyone in the packet path can easily see the key and be able to spoof tunnel packets.
  • A more common use of the tunnel key is when two routers want to establish parallel tunnels sourced from the same IP address. The tunnel key is then used to distinguish between GRE packets belonging to different tunnels.
• Tunnel sequence number: This number is used to ensure that GRE packets are accepted only if the packets arrive in the correct order.

Cisco IOS also supports a proprietary keepalive mechanism that can be used to detect failures in the GRE tunnel path or detect a failed GRE peer. GRE Configuration Example
The sample configuration in Figure illustrates a basic GRE tunnel configuration that was built with Cisco SDM between a pair of routers. The virtual point-to-point connection is configured with the IP subnet 10.1.1.0/30. Both routers use the IP address of their outbound interface as tunnel sources. The two routers must be configured by mirroring IP addresses (that is, the tunnel source on one router must be specified as the tunnel destination on the other router).

---

Content 3.5 Configuring GRE Tunnels over IPsec 3.5.2 Secure GRE Tunnels? The main function of GRE is to provide powerful yet simple tunneling. GRE supports any OSI Layer 3 protocol as payload, for which it provides virtual point-to-point connectivity. GRE also allows the use of routing protocols across the tunnel. The main limitation of GRE is that it lacks any security functionality. GRE only provides basic plaintext authentication using the tunnel key, which is not secure, and tunnel source and destination addresses. A secure VPN requires characteristics that are not provided by GRE:

• Cryptographically strong confidentiality (that is, encryption)
• Data source authentication that is not vulnerable to man-in-the-middle attacks
• Data integrity assurance that is not vulnerable to man-in-the-middle attacks and spoofing

Securing a GRE Tunnel with IPsec
Figure shows how IPsec provides the tunneling characteristics that GRE lacks:

• Confidentiality through encryption using symmetric algorithms (for example, 3DES or AES)
• Data source authentication using HMACs (for example, MD5 or SHA-1)
• Data integrity verification using HMACs

IPsec, however, was primarily intended to provide the above services to IP traffic only. Development of Cisco IOS software is focused on removing the limitations, but multiprotocol support will always require an additional tunneling protocol. Using crypto maps does not provide a virtual interface that you can configure an address on, and a routing protocol can be run to dynamically exchange routing information. Note
Cisco IOS Release 12.4(4)T and newer can now encrypt multicast using a crypto map and an access list. Older software releases required GRE tunneling to provide support for multicast. GRE over IPsec
Most implementations of point-to-point GRE over IPsec use a hub-and-spoke topology as shown in Figure because this topology uses the minimum number of tunnels required to provide full connectivity between VPN sites. The hub-and-spoke topology minimizes the management overhead associated with the maintenance of the IPsec tunnels. Also, most enterprises have concentric traffic patterns, and thus are not interested in managing more tunnels than necessary. GRE over IPsec is typically used to provide an emulated WAN (by using GRE) over an untrusted transport network (for example, the Internet) in which communication is protected using IPsec. GRE over IPsec Encapsulation
The images in Figure illustrate the combination of GRE and IPsec.

• The top image shows tunnel mode in which both tunneling technologies (IPsec and GRE) introduce their own tunnel IP header.
• The bottom image illustrates the use of transport mode in which IPsec reuses the IP header of the packet that it is protecting and reducing the overhead.

---

Content 3.5 Configuring GRE Tunnels over IPsec 3.5.3 Configuring GRE over IPsec Site-to-Site Tunnel Using SDM To configure a GRE over IPsec tunnel using SDM, follow these six steps: Step 1 Use a web browser to connect to an HTTP server of a router. Click the Configure icon in the top navigation bar to enter the configuration page. Figure shows the configuration page. In the Site to Site VPN tab, there is a brief description of the available site-to-site and GRE options. Use this page to complete the first six steps in creating a GRE over IPsec site-to-site VPN. Step 2 Click the VPN icon in the vertical navigation bar to open the VPN page. Step 3 Choose the Site to Site VPN wizard in the menu. Step 4 Click the Create Site to Site VPN tab at