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.
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
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 mentioned below 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).