generic routing encapsulation

Point-to-Point Generic Routing Encapsulation over IP Security

 

gre network

 

Generic Routing Encapsulation

 

What is generic routing encapsulation? Firstly, let us start with the basics. Numerous technologies connect remote branch sites to HQ or central hub. P2P Generic Routing Encapsulation ( GRE network ) over IPsec is an alternative design to classic WAN technologies, such as ATM, Frame Relay, and Leased lines. GRE over IPsec is a common deployment model to connect several remote branch sites to one or more central sites. Design topologies include the hub-and-spoke, partial mesh, and full mesh. Both partial and full-mesh topologies experience limitations in routing protocol support. A full mesh design is limited by the overhead required to support a design with a full mesh of tunnels. Following a full mesh requirement, a popular design option would be to deploy Dynamic Multipoint VPN ( DMVPN ). Regarding the context of direct connectivity from branch to hub only, hub-and-spoke is by far the most common design.

 

GRE Network: Head-end Architecture 

Single-tier and dual tier

Head-end architectures include a single-tier head-end where the point-to-point GRE network and crypto functionality co-exist on the same device. Dual-tier designs are where the point-to-point GRE network and crypto functionality are not implemented on the same device. Dual tier designs, the routing and GRE control planes are located on one device while the IPsec control plane is housed on another.

 

what is generic routing encapsulation

Diagram: What is generic routing encapsulation?

 

Headend

Router

Crypto

Crypto IP

GRE  

GRE IP

Tunnel Protection

Single Tier

Headend

Static or Dynamic

Static

p2p GRE static

Static

Optional 


Branch

Static

Static or Dynamic

p2p GRE static

Static

Optional 

Dual Tier

Headend

Static or Dynamic

Static

p2p GRE static

Static

Not Valid


Branch

Static

Static or Dynamic

p2p GRE static

Static

Not Valid

 

“Tunnel protection” requires the same source and destination IP address for both the GRE and crypto tunnels. Implementations of dual-tier separate these functions, resulting in the different IP addresses for the GRE and crypto tunnels. Tunnel protection is invalid with dual-tier mode.

 

GRE over IPsec

Preliminary design considerations

Diverse multi-protocol traffic requirements force the use of a Generic Routing Encapsulation ( GRE ) envelope within the IPsec tunnel. The p2p GRE tunnel is encrypted inside the IPsec crypto tunnel. Native IPsec is not multi-protocol and has no support for IP multicast or broadcast traffic. As a result, proper propagation of routing protocol control packets cannot take place in a native IPsec tunnel. However, OSPF design cases are available where you can run OSPF network type non-broadcast and explicitly configure the remote OSPF neighbors, resulting in OSPF over the IPsec tunnel without GRE. With a GRE over IPsec design, all traffic between hub and branch sites is first encapsulated in the p2p GRE packet before the encryption takes place.

GRE over IPsec

Diagram: GRE over IPSec.

 

GRE over IPSec Key Points

Redundancy

Redundant designs are implemented with the branch having two or more tunnels to the campus head. The head-end routers can be geographically separated or co-located. Routing protocols are used with redundant tunnels providing high availability with dynamic path selection. The head-end router can either propagate a summary route ( 10.0.0.0/8 ) or a default route ( 0.0.0.0/0 ) to the branch sites, and a preferred routing metric will be used for the primary path. If OSPF is RP, head-end selection is based on OSPF costs.

 

Recursive Routing

Each branch must add a static route to their respective ISP IP addresses for each head-end. The static avoids recursive routing through the p2p GRE tunnel. Recursive routing occurs when the route to the GRE tunnel source outside the IP address of the opposing router is learned via a route with a next-hop of the inside IP address of the opposing p2p GRE tunnel. Recursive routing causes the tunnel to flap and the p2p GRE packets to route into their p2p GRE tunnel. To overcome recursive routing, my best practice is to ensure that the outside tunnel is routed directly to ISP instead of inside the p2p GRE tunnel.

 

%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing

 

Split tunneling

If the head-end advertises a summary route to the branch, split tunneling is enabled on all packets that are not destined for the summary. Any packets not destined for the summary are split-tunneled to the Internet. For example, split tunneling is not used for the branch sites in a design where the head-end router advertises a default route ( 0.0.0.0/0 ) through the p2p GRE tunnel.

 

Control plane

Routing protocol HELLO packets initiated from the branch office force the tunnel to establish. Routing protocol control plane packets are used to maintain and keep the tunnel up. HELLO, packets provide a similar function to GRE keepalives. Routing protocol HELLO operates at Layer 3, and GRE keepalives at Layer 2.

 

Branch router considerations

The branch router can have p2p GRE over IPSEC with a static or dynamic public address. Both the GRE and crypto tunnels are sourced from a static address with a static public IP address. With dynamic address allocation, the GRE is sourced from a loopback address privately assigned (non-routable), and the crypto tunnel is sourced from a dynamically assigned public IP address.

 

A key point: Video on multi-cloud
The following video you may find useful is on the multi-cloud. Connecting to the cloud and in multi-cloud scenarios may call for the need for protection with IPsec.

 

 

Generic routing encapsulation

Key design points

Summary of key design points

  • Deploy IPsec in tunnel mode for flexibility with NAT. The default Tunnel mode adds 20 bytes to the total packet size. However, the transport mode does not work when the crypto tunnel transitions to either a NAT or PAT device.

  • With GRE IPsec tunnel mode, the entire GRE packet ( which includes the original IP header packet ) is encapsulated and encrypted. No part of the GRE tunnel is exposed.

  • Use routing protocols for dynamic redundancy but scaling routing protocols can affect CPU overhead. Keep in mind a higher-end limit to the number of routing protocol peers.

  • Implement GRE for routing protocol support. For example, GRE requires that additional headers are added to the beginning of each packet; the header must also be encrypted, affecting the router's performance.

  • GRE is stateless and, by default, offers limited flow control mechanisms.

  • Configure redundant tunnels for high availability but with scalability limitations. For example, P2P GRE is limited to 2047 tunnels with VPN SPA and 2000 tunnels with SUP720.

  • Implement Triple DES ( 3DES ) or AES for encryption of transmitted data. Even considering AES has a wider key length, there is little or no variation in the performance of these.

  • Implement Dead Peer Detection ( DPD ) to detect loss of ISAKMP peer. Alternatively, IPSEC tunnel protection can be considered for single-tier head architecture.

  • Hardware-accelerated encryption is useful to protect the router's CPU from intensive processing.

  • Set the local Maximum Transmission Unity ( MTU ) and Path MTU to minimize fragmentation.

  • For a small number of sites, one can use pre-shared keys for tunnel authentication. However, large deployments look into Digital Certificates / PKI.

  • Keep CPU at head-end and branch sites around the 65% - 80% mark.

 

generic routing encapsulation

 

Matt Conran
Latest posts by Matt Conran (see all)

Comments are closed.