Dynamic Multipoint VPN, also known as DMVPN, is a useful method for creating dynamic, secure overlay networks. It is a combination of multi-point GRE and NHRP (Next Hop Resolution Protocol).
In our previous blog, we explained how two private networks would communicate over the public network with the help of GRE (Generic Router Encapsulation). As GRE has multiple drawbacks such as it is a point-to-point tunnel, not scalable and it requires static tic public IP on each site which is costly.
Phases in DMVPN: –
- Phase 1 – Topology will be hub and spoke
- Phase 2 – Topology will be full mesh
- Phase 3 – Topology will be full mesh
Let’s understand from the below topology.
The tunnel on Router 1 is configured in multipoint GRE allowing the tunnel to have “many” destinations. Router 2 and Router 3 are in point-to-point mode GRE. The spoke router maintains the NHRP table which contains the tunnel IP address and NBMA IP address i.e., public ip of R1 statically. The spoke router sends an NHRP registration message to a hub with its tunnel and NBMA IP address.
How spoke router will find where the NHRP registration message is to be sent?
NHRP is a combination of NHS (Next hop server) and NHC (Next hop client). The Hub router will be NHS and the spoke will be NHC. The tunnel IP of the hub will be NHS. NHC router will register itself on the NHS router.
How to enable NHRP?
Router(config)# interface tunnel 1
Router(config)# ip nhrp network-id 1
How to statically map tunnel ip and NBMA IP in NHRP table?
Router(config)# interface tunnel 1
Router(config)# ip nhrp map <tunnel ip> <NBMA IP>
If the tunnel destination address is multicast, this can seem normal (e.g., 239.1.1.1). On top of a multicast-capable network, the tunnel could be used to efficiently transport the same data (such as a video stream) to numerous locations. In reality, mGRE is utilized in this manner by Cisco IOS to implement Multicast VPN. However, specific “glue” is required to map tunnel IP addresses to “physical” or “real” IP addresses, used by endpoint routers, if tunnel endpoints need to exchange unicast packets. This glue is referred to as NHRP, as we’ll see later.
It should be noted that GRE can employ a specific “multiplexor” field in the tunnel header to distinguish between multiple mGRE tunnels that are sourced from the same interface (for example, Loopback0) of a single router. You can define this field, which is referred to as “tunnel key,” under tunnel configuration. In fact, using a “tunnel key” was required up until IOS 12.3(14)T or 12.3(11)T3; otherwise, the mGRE tunnel would not start. Since the mentioned versions, a tunnel configuration without a key is possible. The requirement was eliminated for two causes. The best switching speed on the 6500 and 7600 platforms is sacrificed when you configure the hardware ASICs of those platforms to not allow mGRE tunnel-key processing.
Generic NHRP
Let’s now discuss NHRP, the element that gives DMVPN its true dynamic nature. To build a routing optimization strategy inside NBMA (non-broadcast multiple access) networks, such as ATM, Frame-Relay, and SMDS (anyone remembers this one nowadays?), the protocol was originally defined in RFC 2332 (the year 1998) The basic concept was to leverage SVC (switched virtual circuits) to establish transient shortcuts in an incompletely mesh NBMA cloud. Take a look at the schematic representation below, where the partial-meshed NBMA cloud is covered by IP subnet 10.0.0.0/24. Similar to ARP in that it supports L3 to L2 address resolution, NHRP performs this task more quickly, making it appropriate for partially meshed NBMA clouds that offer dynamic layer 2 connections.
The NHRP procedure is illustrated in the following in a simple and schematic manner. In the topology shown above, packets must be sent across PVCs between R1-R2, R2-R3, and then R3-R4 for R1 to reach R4. It would make more sense for R1 to create SVC with R4 directly and transfer packets over the best route if the NMBA cloud permits using SVC (Switched Virtual Circuits, Dynamic Paths). To “make a call,” R1 must, however, be aware of the NMBA address (such as the ATM NSAP) connected to R4. It would be preferable to make R1 dynamically learn the IP address to NSAP (NBMA address) mapping for R4.
Let’s now assume that all NBMA interfaces in the network have NHRP enabled. Every router in the topology performs as either an NHS or NHC (Next-Hop Client) (Next-Hop Server). One of NHC’s duties is to register its IP address that is assigned to an NBMA Layer 2 address with NHS (e.g., ATM NSAP address). You must configure each NHC with at least one NHS’s IP address in order to enable registration. NHS responds to NHC inquiries and serves as a database agent, holding all registered mappings. The packet can be forwarded to another NHS to see if it has the requested association if the NHS does not already have the requested entry in its database. Be aware that a router may serve as both a Next-Hop client and server.
Zindagi Technologies is an IT consulting company having engineers with decades of experience in planning, designing, and implementing Data Centers along with Managed IT Services, cybersecurity, and cloud services. If you want to secure your network, we are just a call away. Please ping us at +91-9773973971 or drop a mail and we will get in touch with you according to your need.
Author
Jainul Khan
Associate Consultant
