This topic is to discuss the following lesson:
When would we choose to use Phase 1, 2, or 3, and why? I understand the differences between the three, but do we gain any benefit from implementing one or the other that is noticeable to end users?
It seems to me that perhaps allowing spoke routers to talk to each other may decrease latency in the real world, as they would not have to hop through the hub router, but other than that I’m not sure.
The different versions are like an evolution of DMVPN. We don’t really use phase 1 anymore unless you have a really good reason why you want to force all traffic through the hub (security perhaps?). Otherwise, it’s more effective to allow spoke-to-spoke traffic.
Both phase 2 and 3 allow spoke-to-spoke traffic, the advantage of phase 3 is that we use the “shortcuts” so you don’t need specific entries anymore in the routing tables of the spoke routers. I can’t think of any advantages right now that phase 2 has over phase 3 so if you implement this, you probably want to use phase 3.
Good point on passing traffic through hub for security purposes. Some organizations may require snooping of traffic. Phase 1 sounds like it would be a very limited use case, and phase 3 is the ideal and more often seen implementation.
Thank you for the quick response!
Great explanation Rene, this is the clearest example of DMVPN I’ve ever read and it was easy to read.
Great lab so far. I was able to configure one spoke to the hub… I got stumped trying to add Spoke 2. Help me understand… Is there only one physical interface on the HUB that I will use to connect to both Spoke routers?? How will I connect to Spoke 2 from the Hub router. It’s just a matter of understanding the Lab diagram and the underlay network. I appreciate your time… Thanks.
That’s right, the hub only has one physical interface and there’s only one tunnel interface. Both spoke routers will “land” on the same tunnel interface of the hub router.
Thank you Rene for your quick response. I’m a bit thick on this one… I created another network to bypass. But I still would like to understand how Spoke 1 and Spoke 2 share a physical interface on the Hub… How is it possible for each Spoke to share G0/1? My apologies if I’m making this difficult but this question will clear up a lot. Jevon
No problem Jevon
Take a look at the configuration here:
The Gigabit interfaces are for the “underlay” network. These could be the interfaces that connect your router to the ISP, it’s where you have your public IP address. Just like with “regular” routing, you can connect from many different sources to one IP address.
The tunnel interface on the hub router uses the Gigabit Interface as its source and it can accept connections from many different spokes. All spoke routers connect to the same IP address and the hub will accept these connections.
They aren’t sharing a physical interface. They are connected together through a logical inteface–the tunnel interface. Each device has its own physical interface that actually sends and receives the bits on the wire.
Thank you Rene and Andrew, I wasn’t able to look at the video @work yesterday… It cleared everything up. I didn’t realize you were using a switch before the router.
That’s good to hear Jevon. I used a switch to connect the three routers together but in real life, these routers will probably be able to reach each other through an Internet connection with some public IP addresses.
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?
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.
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?
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.
The DMVPN is working now behind 3G network.
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…
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.
Do you guys have GNS3 topology file for it?