DMVPN Flashcards
GRE
A GRE tunnel provides connectivity to a wide variety of network layer protocols by encapsulating and forwarding those packets over an IP-based network. The original use of GRE tunnels was to provide a transport mechanism for nonroutable legacy protocols such as DECnet, Systems Network Architecture (SNA), and IPX.
DMVPN uses Multipoint GRE (mGRE) encapsulation and supports dynamic routing protocols, which eliminates many of the support issues associated with other VPN technologies. GRE tunnels are classified as an overlay network because a GRE tunnel is built on top of an existing transport network, also known as an underlay network.
Additional header information is added to a packet when the router encapsulates the packet for the GRE tunnel. The new header information contains the remote endpoint IP address as the destination. The new IP headers allow the packet to be routed between the two tunnel endpoints without inspection of the packet’s payload. After the packet reaches the remote endpoint, the GRE headers are removed, and the original packet is forwarded out the remote router.
GRE Tunnel Topology
The 172.16.0.0/16 network range is the transport (underlay) network, and 192.168.100.0/24 is used for the GRE tunnel (overlay network).
GRE tunnel configuration:
- The tunnel source interface indicates the interface that will be used for encapsulation and decapsulation of the GRE tunnel.
- The tunnel destination is the remote router’s underlay IP address toward which the local router sends GRE packets.
- Virtual interfaces do not have the concept of latency and need to have a reference bandwidth configured so that routing protocols that use bandwidth for best-path calculation can make intelligent decisions.
- The GRE tunnel adds a minimum of 24 bytes to the packet size to accommodate the headers that are added to the packet. Specifying the IP MTU on the tunnel interface has the router perform the fragmentation in advance of the host having to detect and specify the packet MTU.
Multipoint GRE
Our “regular” GRE tunnels are point-to-point and don’t scale well.
When we use GRE Multipoint, there will be only one tunnel interface on each router.
The cool thing about DMVPN is that we use multipoint GRE so we can have multiple destinations. When we need to tunnel something between branch office 1/2 or 3/4, we automatically “build” new tunnels.
When there is traffic between the branch offices, we can tunnel it directly instead of sending it through the HQ router.
When two branch routers want to tunnel some traffic, how do they know what IP address to use?
When we configure point-to-point GRE tunnels we have to configure a source and destination IP address that are used to build the GRE tunnel.
The “inner” source and destination IP addresses are known to use, these are the IP address of the tunnel interfaces. We encapsulate this IP packet, put a GRE header in front of it and then we have to fill in the “outer” source and destination IP addresses so that this packet can be routed on the Internet. The branch1 router knows it’s own public IP address but it has no clue what the public IP address of branch2 is…To fix this, we need some help from another protocol, NHRP.
NHRP Flow
We need something that helps our branch1 router figure out what the public IP address is of the branch2 router.
- One router will be the NHRP server (NHS).
- All other routers will be NHRP clients (NHC).
- NHRP clients register themselves with the NHRP server and report their public IP address (NBMA IP).
- The NHRP server keeps track of all public IP addresses in its cache.
- When one router wants to tunnel something to another router, it will request the NHRP server for the public IP address of the other router.
NHRP Registration Request
The destination IP address of the hub router will be statically configured on the spoke routers.
The routers will use a NHRP registration request message to register their public IP addresses to the hub.
NHRP Cache
The hub, our NHRP server will create a mapping between the public IP addresses and the IP addresses of the tunnel interfaces.
NHRP Resolution Request
Spoke1 decides that it wants to send something to Spoke2. It needs to figure out the destination public IP address of Spoke2 so it will send a NHRP resolution request, asking the Hub router what the public IP address of Spoke 2 is.
NHRP Resolution Reply
The Hub router checks its cache, finds an entry for Spoke2 and sends the NHRP resolution reply to Spoke1 with the public IP address of Spoke2.
On-Demand Tunnel
Spoke1 now knows the destination public IP address of Spoke2 and is able to tunnel something directly. This is great, we only required the hub to figure out what the public IP address is and all traffic can be sent from spoke to spoke directly.
NHRP
Next-Hop Resolution Protocol
Next Hop Resolution Protocol (NHRP) is defined in RFC 2332 as a method to provide address resolution for hosts or networks (with ARP-like capability) for nonbroadcast multi-access (NBMA) networks such as Frame Relay and ATM networks.
NHRP is a client/server protocol that allows devices to register themselves over directly connected or disparate networks. NHRP next-hop servers (NHSs) are responsible for registering addresses or networks, maintaining an NHRP repository, and replying to any queries received by next-hop clients (NHCs).
How does NHRP work?
DMVPN uses mGRE tunnels and therefore requires a method of mapping tunnel IP addresses to the transport (underlay) IP address. NHRP provides the technology for mapping those IP addresses. DMVPN spokes (NHCs) are statically configured with the IP addresses of the hubs (NHSs) so that they can register their tunnel and NBMA (transport) IP addresses with the hubs. When a spoke-to-spoke tunnel is established, NHRP messages provide the necessary information for the spokes to locate each other so that they can build a spoke-to-spoke DMVPN tunnel. The NHRP messages also allow a spoke to locate a remote network.
The NBMA address refers to the transport network, and the protocol address refers to the IP address assigned to the overlay network (tunnel IP address or a network/host address).
NHRP Messages Types
Registration: Messages sent by the NHC (DMVPN spoke) toward the NHS (DMVPN hub). Registration allows the hubs to know a spoke’s NBMA information.
Resolution: A resolution request is sent during the actual query, and a resolution reply provides the tunnel IP address and the NBMA IP address of the remote spoke.
Redirect: Redirect messages are an essential component of DMVPN Phase 3. They allow an intermediate router to notify the encapsulator (a router) that a specific network can be reached by using a more optimal path (spoke-to-spoke tunnel).
DMVPN Benefits
Zero-touch provisioning: DMVPN hubs do not require additional configuration when additional spokes are added. DMVPN spokes can use a templated tunnel configuration.
Spoke-to-spoke tunnels: DMVPN provides full-mesh connectivity while requiring configuration of only the initial spoke-to-hub tunnel. Dynamic spoke-to-spoke tunnels are created as needed and torn down when no longer needed. There is no packet loss while building dynamic on-demand spoke-to-spoke tunnels after the initial spoke-to-hub tunnels are established. A spoke maintains forwarding states only for spokes with which it is communicating.
Multiprotocol support: DMVPN can use IPv4, IPv6, and MPLS as the overlay or transport network protocol.
Multicast support: DMVPN allows multicast traffic to flow on the tunnel interfaces.
DMVPN Intro
DMVPN is a combination of mGRE, the Next-Hop Resolution Protocol (NHRP),
and IPSec (optional). DMVPN can be implemented as Phase 1, Phase 2, or Phase 3.
There are two GRE flavors: GRE and mGRE
GRE, which is a point-to-point logical link, is configured with a tunnel source and tunnel
destination. The tunnel source can either be an IP address or an interface. When a tunnel
destination is configured, it ties the tunnel to a specific endpoint. This makes a GRE
tunnel a point-to-point tunnel. If there are 200 endpoints, each endpoint would need
to configure 199 GRE tunnels.
With Multipoint Generic Routing Encapsulation (mGRE), the configuration includes the
tunnel source and tunnel mode. The tunnel destination is NOT configured. Therefore, the
tunnel can have many endpoints, and only a single tunnel interface is utilized. The end-
points can be configured as a GRE tunnel or an mGRE tunnel.