The popularity of Virtual Private Network (VPN) solutions has risen considerably over the last several years. The hardware is getting to a point where VPN acceleration is cost effective and able to be performed on a single device. This is because of a number of factors including the fact that technologies are being developed that offer flexibility for a number of different deployment models. The cost and speed of public transit (Internet) has become an obvious option for business traffic. These and a number of other factors are joined together to make using VPNs for site-to-site traffic transit a worthwhile solution.

This article focuses on the differences between Generic Routing Encapsulation (GRE) ,Point-to-Point tunnels and Multipoint Generic Routing Encapsulation (mGRE).  Multipoint tunnels are configured only on the hub router.

Point-to-Point Generic Routing Encapsulation (GRE) Tunnels

The traditional implementation of a GRE tunnel involved the configuration of a point-to-point tunnel going between two sites. This type of configuration works well when this is the behavior and there are a limited number of tunnels that need to be configured. However, if there are a large number of spoke sites, the configuration of the hub router and the number of independent IP address ranges (one per tunnel) could get excessive rather quickly; an example of this is shown in Figure 1.

Figure 1 – Point-to-Point GRE

Dynamic (Hub Side) Multipoint Generic Routing Encapsulation (mGRE) Tunnels

The next type of GRE configuration uses mGRE at the hub site (R1 in this case) and normal point-to-point GRE configuration at the spokes. There are two main ways that this can be configured but before jumping into this a short discussion of the Next Hop Resolution Protocol (NHRP) is required. NHRP is used similarly to the Address Resolution Protocol (ARP) on Ethernet, it provides the ability to map a tunnel IP address with a logical (Non-Broadcast Multi-Access (NBMA)) IP address; this allows mGRE to have dynamically set up tunnels without having to explicitly configure a mapping entry between each potential next-hop destination. This is of course an oversimplification but for the purposes of this article this amount of information should clarify the next part of this section.

As stated above there are two different ways to configure mGRE on the hub and leave a “normal” GRE configuration on the spokes; the first uses static NHRP mapping statements on the hub router and the second uses dynamic NHRP mapping on the hub router.

Figure 2 shows an example of the configuration required using static NHRP mapping statements; the figure also shows some additional NHRP configuration statements that would be required if using EIGRP (or any routing protocol requiring multicast).

Figure 2 – Dynamic (Hub Side) mGRE using static NHRP statements

The configuration shown in Figure 2 is one option but would certainly get rather lengthy if there are several branch routers. It does however require a very simple branch configuration.

The configuration shown in Figure 3 is generally recommended by Cisco (when only using mGRE at the hub site). It includes the use of dynamic NHRP on the hub router; this method is referred to as Hub-and-Spoke Only by Cisco because it does not provide the ability for spoke routers to directly speak to each other.

Figure 3 - Dynamic (Hub Side) mGRE using dynamic NHRP

When using dynamic NHRP, the hub router requires that each of the spoke routers be configured to register with a Next Hop Server (NHS), which would also typically be the hub router. This NHS keeps track of the NHRP mappings so that the hub device knows where to send traffic being sent to multiple tunnel destinations; for this to work correctly the IP address of the NHS server must also be statically mapped on the spoke routers. The other thing that needs to be changed from the default settings is the holdtime.  By default, the holdtime of a NHRP entry is 2 hours; Cisco recommends that this be changed to 10 minutes (600 seconds). The other thing that is shown is the configuration of a registration timeout; by default this is set to 1/3 the value of the NHRP holdtime. If neither of these settings is changed and something happens to the mappings on the hub router, the spokes will not attempt to re-register for 40 minutes leaving the connection unidirectional for that amount of time (mapping works from the spoke to the hub, but not from the hub to the spoke).

Dynamic (Both Sides) Multipoint Generic Routing Encapsulation (mGRE) Tunnels

The last type of configuration that will be shown in this article is the use of mGRE on both the hub and the spokes. This allows for some interesting forwarding options which are not possible with the other configurations shown, including the ability to forward traffic directly from spoke-to-spoke without having to route traffic through the hub.

With all of the configurations shown up to this point the only available way for spokes to send traffic to other spokes was to forward traffic through the hub. This is fine but does require an extra hop that may not be required when forwarding traffic. In the sample configurations and topology used in this article, all of the routers are configured to connect through an Ethernet Cloud (Ethernet switch). This could however be the same as being configured using an Ethernet Internet connection through any ISP. The point here is that each of the spokes has the ability to forward traffic directly to each other on the underling IP network. When this is possible it would typically be more efficient for spoke-to-spoke traffic to be routed directly between the spokes without having to jump through the hub router. With the other configuration options shown above this is not possible and all tunneled traffic regardless of destination must be forwarded through the hub. However, if both the hub and the spokes were configured to use mGRE then the ability to set up dynamic spoke-to-spoke tunnels is permitted. The configurations shown in Figure 4 show how to do this.

Figure 4 - Dynamic (Both Sides) mGRE using dynamic NHRP

With this configuration, each of the spokes still uses the hub as a NHS which allows the hub to keep track of each of the spoke sites, it also provides mGRE and NHRP to work together to tell the spokes what the forwarding information is for the other spokes. This information can then be used for each of the spokes to dynamically set up mGRE tunnels between each of the other spokes as the need is required.

In this configuration EIGRP is being used. Both the disabling of split horizon and the disabling of next hop marking is required. The reason behind the latter is because, by default, an EIGRP router will advertise routes with a destination of self (i.e. to get to this network send traffic to me); but in this case EIGRP needs to advertise the original advertising EIGRP router IP address. Without this all of the spokes would still forward traffic through the hub router.

Summary

The intention of this article was to give an overview to both mGRE and NHRP and how they can be used to set up both static and dynamic tunnels, both of these technologies are used heavily when implementing Dynamic Multipoint Virtual Private Networks (DMVPN).Hopefully the content in this article will get the reader interested and allow them the ability to play around with these features on their own equipment or labs.

Ready to test your skills in Computer Networking? See how they stack up with this assessment from Smarterer. Start this Computer Networking test now