NHRP/DMVPN/GRE/MPLS/jumbled mess of thoughts

hurricane1091

I'm looking at this book and seeing this hub and spoke scenario, and it's challenging me. What seems odd is that from my CCNA days, I studied Frame Relay (I will be learning MPLS soon from CCNP!) and how a spoke could learn about a network behind another spoke, from the hub, via OSPF, EIGRP, etc. However, you apparently could not just form a direct connection between spokes. This DMVPN allows for that to happen though (in conjunction with NHRP and mGRE). What if you were not using it though, and you wanted traffic sent in plain text direction between spokes instead of doing to the hub first? Is that how MPLS works or what? Maybe someone can clear up MPLS? I would believe here that satellite offices are not connected via MPLS, so your option would be from from Spoke A to Hub to Spoke B thru MPLS, or Spoke A to Spoke B thru the regular internet using DMVPN.

I'm confused, and if I sound crazy I'm sorry, it's early in the morning. But I've literally just started reading the book.

fredrikjj

. What if you were not using it though, and you wanted traffic sent in plain text direction between spokes instead of doing to the hub first?

You could just use DMVPN without encryption in that case. DMVPN is kind of modular in the sense that you can set it up with or without several of the components. For example, to satisfy your requirement of sending plain text, you could just not use encryption. You could also disable spoke to spoke communication entirely if you wanted to, etc. It's pretty cool.

hurricane1091

fredrikjj wrote: »

You could just use DMVPN without encryption in that case. DMVPN is kind of modular in the sense that you can set it up with or without several of the components. For example, to satisfy your requirement of sending plain text, you could just not use encryption. You could also disable spoke to spoke communication entirely if you wanted to, etc. It's pretty cool.

Okay, thank you. So follow me here for a second. Let's say we have Hub A, and it is connected to Spoke A and Spoke B (Spoke A and B are not connected). Spoke A contains 10.1.1.0/24, Spoke B contains 192.168.1.0/24. Spoke A knows this through EIGRP from Hub A (how EIGRP communicates over the WAN is beyond me at this point). So Spoke A will send packets destined to 192.168.1.0/24 to Hub A, since Hub A told him about it.

If that is right, let's continue. Spoke A learns the physical IP (public IP?) of Spoke B via Hub A thru NHRP (how does Spoke A already know the logical IP?). Spoke A can now directly communicate with Spoke B with a DMVPN over the public internet instead of going to Hub A first. Correct? Now, why is GRE needed here if we're not sending anything unsupported over the wire (like multicast)?

fredrikjj

Now, why is GRE needed here if we're not sending anything unsupported over the wire (like multicast)?

Ok, let's say that spoke A and spoke B has learned of each other's public IP addresses (called NBMA addresses in DMVPN, and sometimes underlay addresses, or transport addresses). Spoke A wants to send a packet to the 10.1.1.0/24 network that exists at spoke B. Some host at spoke A creates a packet where the destination IP address is 10.1.1.1 and the source address is for example 192.168.1.1, and sends to his nearest router. Then what? This packet can never arrive at spoke B with the destination address being 10.1.1.1 because it's not an address that is routed towards B by every router between A and B.

Some kind of encapsulation of the packet is required where another IP header is added so that it can be delivered to the public address of spoke B. Let's say that this address is 83.1.1.1. When the packet is routed from spoke A to spoke B, it's routed as if it's a normal IP packet with the destination address 83.1.1.1. When it arrives at spoke B, the outer header with 83.1.1.1 is removed and it's again a packet destined for 10.1.1.1.

There are several types of encapsulations, and GRE just happens to be the de facto standard for IP based tunnels. Like you point out, if you are just sending IP unicast, you don't really need the extra GRE header. You could use an IP in IP encapsulation in that case, but there's really not much point to doing this.

fredrikjj

Spoke A learns the physical IP (public IP?) of Spoke B via Hub A thru NHRP (how does Spoke A already know the logical IP?)

Either through having the other spoke's tunnel IP address (what you call logical IP) as the next hop for routes to that spoke, or by receiving a NHRP redirect message from the hub. What method is used depends on if you are using phase 2 or phase 3 DMVPN.

hurricane1091

fredrikjj wrote: »

Ok, let's say that spoke A and spoke B has learned of each other's public IP addresses (called NBMA addresses in DMVPN, and sometimes underlay addresses, or transport addresses). Spoke A wants to send a packet to the 10.1.1.0/24 network that exists at spoke B. Some host at spoke A creates a packet where the destination IP address is 10.1.1.1 and the source address is for example 192.168.1.1, and sends to his nearest router. Then what? This packet can never arrive at spoke B with the destination address being 10.1.1.1 because it's not an address that is routed towards B by every router between A and B.

Some kind of encapsulation of the packet is required where another IP header is added so that it can be delivered to the public address of spoke B. Let's say that this address is 83.1.1.1. When the packet is routed from spoke A to spoke B, it's routed as if it's a normal IP packet with the destination address 83.1.1.1. When it arrives at spoke B, the outer header with 83.1.1.1 is removed and it's again a packet destined for 10.1.1.1.

There are several types of encapsulations, and GRE just happens to be the de facto standard for IP based tunnels. Like you point out, if you are just sending IP unicast, you don't really need the extra GRE header. You could use an IP in IP encapsulation in that case, but there's really not much point to doing this.

Very helpful, thank you bunches. I also was speaking with my boss and it cleared up some stuff about our environment. I still question why the sh ip nhrp command displays one tunnel that is static


xxx.xxx.xxx.x/32 via xxx.xxx.xxx.x
Tunnelxx created XyXw, never expire
Type: static, Flags:
NBMA address: xxx.xxx.xxx.xxx

I now understand DMVPN in our environment is used as a fail over, and this tunnel exists to get back to the nhrp server, so no other tunnels are open. I can see that tunnel interface in the running-config though. It has to be static right? I would imagine without a static tunnel back to the nhrp server, you would have no way of dynamically making other tunnels?

fredrikjj

hurricane1091 wrote: »

It has to be static right? I would imagine without a static tunnel back to the nhrp server, you would have no way of dynamically making other tunnels?

correct.

hurricane1091

fredrikjj wrote: »

correct.

Awesome, thanks so much.