DMVPN Flashcards

1
Q

GRE

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

GRE Tunnel Topology

A

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.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Multipoint GRE

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

When two branch routers want to tunnel some traffic, how do they know what IP address to use?

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

NHRP Flow

A

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.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

NHRP Registration Request

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

NHRP Cache

A

The hub, our NHRP server will create a mapping between the public IP addresses and the IP addresses of the tunnel interfaces.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

NHRP Resolution Request

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

NHRP Resolution Reply

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

On-Demand Tunnel

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

NHRP

Next-Hop Resolution Protocol

A

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 well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

How does NHRP work?

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

NHRP Messages Types

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

DMVPN Benefits

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

DMVPN Intro

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

NHRP Intro

A

NHRP is used by the spokes connected to an NBMA network to determine the NBMA
IP address of the next-hop router
. With NHRP, you can map a tunnel IP address to
an NBMA IP address either statically or dynamically. The NBMA IP address is the IP
address acquired from the service provider. The tunnel IP address is the IP address that
you assigned to the tunnel interface, typically using RFC 1918 addressing.

NHRP is like the Address Resolution Protocol (ARP). Why is it like ARP? Because it allows NHCs to dynamically register their NBMA-IP-address-to-tunnel-IP-address mapping.

This is the reason why dynamic registration and queries are very useful. In these scenarios, it is almost impossible to preconfigure the logical tunnel IP address to the physical NBMA IP address mapping for the NHCs on the NHS. NHRP is a resolution protocol that allows the NHCs to dynamically discover the logical-IP-address-to-physical-IP-address mapping for other NHCs within the same NBMA network.

17
Q

DMVPN Phase 1

A

Phase 1: Spoke-to-Hub

VPN tunnels are created only between spoke and hub sites. Traffic between spokes must traverse the hub to reach any other spoke.

The hub is the only router that is using a multipoint GRE interface, all spokes will be using regular point-to-point GRE tunnel interfaces. This means that there will be no direct spoke-to-spoke communication, all traffic has to go through the hub!

Since our traffic has to go through the hub, our routing configuration will be quite simple. Spoke routers only need a summary or default route to the hub to reach other spoke routers.

18
Q

DMVPN Phase 2

A

Phase 2: Spoke-to-Spoke

DMVPN Phase 2 allows spoke-to-spoke communication on a dynamic basis by creating an on-demand VPN tunnel between the spoke devices.

The disadvantage of phase 1 is that there is no direct spoke to spoke tunnels.
In phase 2, all spoke routers use multipoint GRE tunnels so we do have direct spoke-to-spoke tunneling. When a spoke router wants to reach another spoke, it will send an NHRP resolution request to the hub to find the NBMA IP address of the other spoke.

Summarization on the hub is not possible since the spoke routers require specific routes.

19
Q

DMVPN Phase 2 Notes

A

To allow the dynamic spoke-to-spoke tunnels to form, you need to change the spokes to multipoint tunnels. As you do that, you need to make sure that you also add a static entry for the hub, because without that entry, the NHRP registration cannot be sent.

The question then becomes, how does a spoke learn the NHRP mapping of another spoke? A system of requests and replies are used where a spoke sends a request for a particular spoke that it wants to send traffic to. It then gets a reply from the spoke in question.

  • Spoke1 forwards a packet with a next-hop that is another spoke, spoke2. There is no NHRP map entry for this spoke, so an NHRP resolution request is sent to the hub.
  • The request from spoke1 contains the tunnel IP address of spoke2. The hub relays the request to spoke2.
  • Spoke2 receives the request, adds its own address mapping to it, and sends it as an NHRP reply directly to spoke1.
  • Spoke1 receives the request from spoke2 via the hub and replies by adding its own mapping to the packet and sending it directly to spoke2.
20
Q

How does it work?

A

The following traceroute should go through the hub router to reach 10.1.1.2, because
this is the initial communication between the two spokes. R4 needs to send a resolution
request to the hub router, R1. R1 receives the message and redirects that request to the
destination spoke, R2. Because R4 includes its tunnel-IP-address-to-NBMA-IP-address
mapping in the resolution request message, R2 caches the mapping information for R4
when it receives that message. R2 establishes a tunnel to R4 directly. When R4 receives
the resolution message from R2, it caches the tunnel-IP-address-to-NBMA-IP-address
mapping for R2. From that point on, it goes directly to R4.

21
Q

Phase 2 Config

A
  • Summarization is not allowed on the hub.
  • Default routing is not allowed on the hub.
  • The spokes must always maintain next-hop reachability.

The spokes are configured with a tunnel source, a tunnel mode, and an NHRP network
ID
. The NHRP network ID enables NHRP on the tunnel interface. The configurationip nhrp nhs 10.1.1.1identifies the NHRP next-hop server. The configurationip nhrp map 10.1.1.1 192.1.1.1 maps the hub’s tunnel IP address to the hub’s NBMA IP address. If this mapping is not configured, the spokes won’t be able to communicate with the hub router. This mapping is needed because the spokes are configured with a multipoint GRE tunnel.

The first traceroute should go through the hub router to reach 10.1.1.2, because this is the initial communication between the two spokes. R4 needs to send a resolution request to the hub router, R1. R1 receives the message and redirects that request to the destination spoke, R2. Because R4 includes its tunnel-IP-address-to-NBMA-IP-address mapping in the resolution request message, R2 caches the mapping information for R4 when it receives that message. R2 establishes a tunnel to R4 directly. When R4 receives the resolution reply message from R2, it caches the tunnel-IP-address-to-NBMA-IP-address mapping for R2. From that point on, traffic flows directly between spokes.

22
Q

DMVPN Phase 3

A

Phase 3: Hierarchical Tree Spoke-to-Spoke

The spoke routers no longer need specific routes to reach remote spokes and it doesn’t matter what the next hop IP address is. When a spoke router wants to reach a remote spoke, they will forward their traffic to the hub.
When the hub receives the traffic, it will realize that another spoke is the destination and it will then send a NHRP redirect to both spokes.
When the spokes receive the NHRP redirect, they will both send a NHRP resolution to figure out each other’s NBMA IP addresses.
The spoke routers will then install a new entry in the routing table so that they can reach each other directly.

23
Q

DMVPN Phase 3 Notes

A

NHRP Phase 3 allows the spokes to support NHRP resolution requests, meaning that
the hub is not the only device that contains the NHRP database.

When traffic goes from a spoke to the hub, and the hub sees that the destination is
reachable via another spoke, it sends an NHRP Redirect, which causes the spoke to
install routes to each other.

  • A spoke-to-spoke tunnel is triggered by the hub via NHRP Redirect.
  • Summarization is allowed on the hub.
  • Default routing is allowed on the hub.
  • Next-hop values on the spokes are always modified.
  • ip nhrp redirect: This command allows a hub router to send out NHRP Traffic Indication messages.
  • ip nhrp shortcut: This command allows a spoke router to accept incoming NHRP Traffic Indication messages, and in turn send an NHRP Resolution Request message for the original packet’s destination address and then, after receiving an NHRP Resolution Reply, install the destination network discovered through the Resolution Reply into the routing table with the responding spoke router as a next hop.
24
Q

The spoke routers will only have a single default route pointing to the
hub router, R1. But the spoke routers will be able to access other spoke routers or the
network(s) that the other spoke routers are advertising directly without going through the
hub router. How is this possible?

A

The data packet is forwarded from the originating spoke to the hub based on the routing table of the originating spoke. No NHRP messaging is triggered by the originating spoke at this point, because it is not certain whether the destination is located in a DMVPN or in a normal network.

The hub router receives the data packet from the originating spoke and forwards it to the destination spoke according to its routing table. The hub also realizes that the packet is being forwarded within the same DMVPN because the incoming and outgoing interface have the same nhrp network-id configured. The hub router thus realizes that it is a transit router for the data packets between the spokes.

The hub router sends an NHRP Traffic Indication message back to the originating spoke router, telling it that for the original packet whose header is carried in the Traffic Indication body, there might be a more direct way to the destination rather than through the hub.

Upon receiving the NHRP Traffic Indication message, the originating spoke triggers an NHRP Resolution Request to map the known destination IP address of the original packet to the unknown NBMA address of the destination spoke. As in Phase 2, the spoke router includes its tunnel-IP-to-NBMA-IP mapping in the Resolution Request.

The hub router receives the NHRP Resolution Request. Based on the destination address of the original packet indicated in the Resolution Request, it looks up the matching destination network in its routing table, finds the next hop, and forwards the Resolution Request to the next hop.

The destination spoke receives the NHRP Resolution Request. Using its contents, it learns about the originating spoke’s tunnel IP and NBMA IP and adds this mapping into its NHRP table. The destination spoke then creates an NHRP Resolution Reply packet with its own tunnel IP and NBMA IP. In addition, because the Resolution Request asked about the original packet’s destination address rather than the tunnel IP address of the destination spoke, the destination spoke will also insert the original packet’s destination address and the netmask of the matching destination network from its routing table into its Resolution Reply.

After the originating spoke receives the Resolution Reply, it will add the mapping for the destination spoke’s tunnel IP and NBMA IP into its NHRP table. In addition, using the original packet’s destination address and the netmask of the matching network on the destination spoke carried in the Resolution Reply, the originating spoke will compute the address of the destination network and insert this network into its routing table, with the next-hop address pointing to the destination spoke’s tunnel IP. Because this added network has a longer prefix than the default route, it will be matched first for every packet going to this destination network. This will cause
subsequent packets to be sent to the destination spoke directly, rather than being routed over the hub.

25
Q

DMVPN Comparison

A
26
Q

Config Notes

A

The NHRP network ID (which enables NHRP on that tunnel interface).

This enables multicasting and allows the Interior Gateway Protocols (IGPs) to use multicasting over the tunnel interface.

Because the tunnel destination is configured, it ties that tunnel to that destination only. This makes the tunnel a point-to-point tunnel and not a multipoint tunnel.

ip nhrp map multicast dynamic, Because IGPs use multicast to form an adjacency,
before any IGP is configured, we need to provide multicast capability to all routers.

If the adjacency is not formed, you may need the spoke routers to re-register their
tunnel-IP-to-NBMA-IP mapping with the hub router. One way to achieve this is to con-
figure the ip nhrp registration timeout 5 command. This command sends a registration
request to the hub router every 5 seconds

interface tunnel 0

ip summary-address eigrp 100 0.0.0.0 0.0.0.0

27
Q

Why to add static map for the Hub router on the spokes?

A

When a spoke router initially connects to the DMVPN network, it registers its tunnel-IP-
address-to-NBMA-IP-address mapping with the hub router. The hub router will acknowl-
edge the registration by sending back the registration message that was initiated by the
spoke with a success code. This registration enables the mGRE interface on the hub router
to build a dynamic GRE tunnel back to the registering spoke router. This means that the
spoke routers must be configured with the tunnel IP address of the hub; otherwise, they
won’t know where to go to register their tunnel-IP-address-to-NBMA-IP-address mapping.