Introduction to DMVPN

(Davis W) #13

Hi Rene,

Is this DMVPN works behind NAT like 3G/4G network?

As i understand DMVPN need UDP port 500, 4500, GRE and ESP. Without port forwarding, it will still working?

Davis

0 Likes

(Andrew P) #14

Davis,
Technically, DMVPN and IPSec are independent of each other. However, since DMVPN doesn’t provide any level of security (other than password authentication for Hubs/Spokes), people often pair it with IPSec when running on a public network. It shouldn’t make a difference if your connection type happens to be 3/4G, DSL, or MPLS, for example. One of the benefits of DMVPN is its ability to allow just about any connection type–as long as the spokes and hub(s) have IP connectivity, DMVPN should work.

DMVPN does work even when devices are behind a NAT. If you wanted to use IPSec with a DMVPN NAT environment, you would need to make sure the device performing the NAT supports NAT-T (UDP 4500), which is designed to allow IPSec to function through a NAT.

0 Likes

(Davis W) #15

Hi Andrew,

I tested behind NAT in home router public IP, it works for DMVPN with and without IPSEC protection. Once i change WAN to 3G connection. The DMVPN is down.

So i remove the IPSEC protection and only configure basic DMVPN, still not able to bring up the DMVPN. Since i don’t use the IPSEC protection, so i should not care the NAT-T or UDP500 and ESP. What can be reason the DMVPN is not up?

Davis

0 Likes

(Andrew P) #16

You will have to start doing basic troubleshooting like debugging NHRP, look at the outputs of #show dmvpn, testing icmp connectivity between hubs and spokes, etc. I don’t have an answer for you.

0 Likes

(Davis W) #17

Hi Andrew,

The DMVPN is working now behind 3G network.

Davis

0 Likes

(Rafa) #18

Could you give some examples of how this would be good for a back up network? If our circuit to the internet goes down, arent we kinda screwed anyway? Thanks…

0 Likes

(Andrew P) #19

Rafa,
Not in the case where sites might have multiple circuits. For example, in my company, where we have locations all over the country, MPLS is our primary means of connecting sites, but if there is a problem with this circuit, or the provider, then a secondary standard Internet connection (many of our smaller sites simply use DSL or even 4G cellular), could take over with DMVPN configured over it.

0 Likes

(Riz H) #20

Do you guys have GNS3 topology file for it?

0 Likes

(Rene Molenaar) #21

We don’t have any GNS3 topology files but each DMVPN example does have configuration files. You will only have to create a new GNS3 topology, then copy/paste the commands.

0 Likes

(Heng S) #22

Hi Rene
Could you help me with Phase 3. Since I read when we use phase 3 spoke router 1 want send data to spoke router 2 but it has to forward the traffic to hub router and hub router will it will realize that another spoke is the destination and it will then send a NHRP redirect to both spokes.
After that spoke1 will know how to establish direct GRE tunnel to spoke router 2 , then start to send their traffic. So does it mean that Spoke router 1 need to send its data 2 time ? since first one send to hub to get NHRP and after establish direct GRE with Spoke router 2 it start to send data again.
Please help
Sovnadara

0 Likes

(Lazaros Agapides) #23

Hello Heng

This is a very good question. Looking at the process in more detail, when using Phase 3.

Initially, (and that is the key word) all spoke to spoke packets are switched across the hub. In order for a spoke to learn about the true NBMA IP address of another spoke, the NHRP redirect message is used.

So when a hub receives an IP packet inbound on its interface and switches it out of the same interface, it sends a special NHRP redirect message to the source indicating that this is a suboptimal path. It should look for a better way using NHRP resolution. The original packet however is still routed to its destination.

When the originating router receives the redirect message, it contains the destination IP address of the original IP packet as its payload. The router then sends the NHRP request for the redirected destination IP targeted originally, that is, the destination spoke. The resolution request travels via the regular IP routing path, through the hub until it reaches the target spoke.

The destination spoke responds to the resolution request using the IP of the source router sending it directly AND NOT THROUGH THE HUB, thus completing the spoke to spoke communication.

Now for your specific question, because the initial communication occurs via the hub, the hub still routes the packet successfully to the destination spoke. So the initial traffic sent does arrive at the destination spoke (via the hub) so it does not have to be resent. All subsequent communications that occur without the use of the hub will continue the flow of data.

I hope this has been helpful!

Laz

2 Likes

(Heng S) #24

Hello lagapides
oh I almost got it, just a bit more. So mean when spoke 1 want to send data to spoke 2 first ip package is contain its data via destination of spoke 2 then hub router saw spoke 2 destination in its own NHRP cache so it will send redirect message back to spoke 1 to told that there is a better way to go to spoke 2 without through me (include NMBA address of spoke 2). am i right ?
Thank for you explaination
Sovandara

0 Likes

(Lazaros Agapides) #25

Hello Heng.

Yes you are correct!

Laz

1 Like

(Heng S) #26

Hello Lagapides
Thank you so much for your time. I got it now .
Sovandara

0 Likes

(Chris N) #27

Does DMVPN support QoS and multicast within the tunnels themselves? And can you use dynamic IPs for the hub and spokes? It seems hard to for the Hub, because you have to configure the NHS.

0 Likes

(Lazaros Agapides) #28

Hello Chris

It is possible to implement what is called Per Tunnel QoS for DMVPN. More information can be found here:


Secondly, multicast is also configurable over DMVPN. You can find out more about it at the following link. (Cisco refers to DMVPN using the iWAN marketing term in the document, but rest assured it is DMVPN).

As for the dynamic IPs, the hub MUST have a static IP, but the spokes can have dynamic IPs. Because the hub is a Next Hop Server (NHS), when the spoke brings the tunnel up it will register with the NHS via NHRP. Via this procedure, the hub will be informed of the dynamic mapping of public to private IPs for the spokes. Just make sure that the IP address of the hub is correctly referenced in the configurations of the spokes so they can register. This clearly shows why the hub IP must be static.

I hope this has been helpful!

Laz

1 Like

(Chris N) #29

I notice that on all of your examples, you don’t use the “tunnel key” command? Is this only needed when multiple DMVPN configurations are used?

1 Like

(Lazaros Agapides) #30

Hello Chris

You are absolutely right. The tunnel key command is used to differentiate between the existing tunnels. The IP alone is not enough since the packet must be decapsulated to determine that, and you can’t do that unless you have the tunnel key. If there is only one tunnel, however, the tunnel key command is not needed.

In older IOS versions, this command was mandatory for DMVPN even if a single tunnel interface was used. This has been changed however, and this is why it is no longer necessary.

I hope this has been helpful!

Laz

1 Like

(Trust_the P) #31

Hello Laz,

I don’t quite get the advantage Phase 3 has over Phase 2. Can you explain a little bit more?

Thanks

0 Likes

(Lazaros Agapides) #32

Hello sales2161

The primary difference between the two has to do with how NHRP operates. As stated in the lesson, with Phase 2,

There are two requirements to make spoke to spoke tunnels work:

  • Spoke routers need to have a route for the network that they are trying to reach.
  • The next hop IP address of the route has to be the remote spoke.

Now the problem with this is stated like so in the lesson:

We are using a hub and spoke topology so only the hub will exchange routing information with the spokes. Depending on the routing protocol, it’s possible that the hub changes the next hop IP address of routes that it advertises to the spokes. When it does then a spoke will use the hub as the destination when it’s trying to reach a remote spoke.

This means that there will still be cases where the route the packets take will be via the hub, something that is undesirable and inefficient. Phase 3 solves this problem.

In Phase 3, the spoke routers don’t need to have a route for the remote spoke destination nor do they need a next hop address. Traffic from one spoke destined to another will begin being sent to the hub. When the hub receives the first packet, it discovers that the traffic is coming from a spoke, and that the destination is another spoke and it will send an NHRP redirect to both spokes. When this occurs, both spokes will send an NHRP resolution packet to discover each other’s NBMA IP address. This will then be installed in the routing table as new entries in both routers, and they can reach each other directly.

I hope this has been helpful!

Laz

0 Likes