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.
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
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
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
Hello Heng.
Yes you are correct!
Laz
1 Like
Hello Lagapides
Thank you so much for your time. I got it now .
Sovandara
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.
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
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
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
Hello Laz,
I don’t quite get the advantage Phase 3 has over Phase 2. Can you explain a little bit more?
Thanks
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
Hi ,
Both Phase-1 & Phase-2 seems to be same. I didn’t find any difference in them . Can you please comment on this .
Hi there.
In Phase 1, the spokes aren’t able to communicate with other spokes. They are only able to communicate with the hub. Also, the spokes build static point-to-point GRE tunnels to the hub.
In Phase 2, the spokes can communicate with other spokes by using the hub to reach the other spokes. In addition, the spokes build dynamic multipoint GRE tunnels to the hub (instead static of point-to-point GRE tunnels).
Hello Sirisha
@brandonwilson.mog has got it. As described in the lesson as well, Phase 1 has no spoke to spoke communication while Phase 2 does. Phase 1: all traffic goes through the hub, Phase 2: traffic can go directly from spoke to spoke WITHOUT going through the hub. If you go through the configuration of both of these, you will be able to see the differences more clearly. Take a look at these lessons:
DMVPN Phase 1 Basic Configuration
DMVPN Phase 2 Basic Configuration
I hope this has been helpful!
Laz
Hi Guys - I’m after a explanantion of of what a NBMA network actually is/means? What types of NBMA are common today apart from DMVPN? Thanks - Gareth.
Hello Gareth
NBMA essentially describes the functionality of a network at Layer 2. An NBMA network is:
- non broadcast - which means that communication can only occur from one host to another. Broadcast and multicast are not inherently supported.
- multiple access - multiple hosts share the same medium
In contrast, Ethernet is multiple access, but inherently supports broadcast communication.
For NBMAs, data is transmitted only directly from one host to another single host over a virtual circuit or across a switched fabric. Although not inherently supported, multicast and broadcast can be simulated by creating multiple unicast communications to create what are known as pseudo-broadcasts.
Once again, the NBMA operation is a Layer 2 phenomenon. You can run IP over NBMA networks and if configured correctly, IP operation will take place and will not know the difference. The only thing you may need to adjust is the split horizon rule for dynamic routing protocols.
Typical examples of NBMAs include ATM, Frame Relay, X.25 as well as home power line networks. As you can see from this list of technologies, apart from DMVPN, NBMA networks do not have an extensively wide application base, and are primarily older technologies that are on their way to being phased out. Nevertheless, there are still enough NBMA networks to warrant a good understanding of the mechanisms involved.
I hope this has been helpful!
Laz
DMVPN requires GRE, which adds an additional 4 byte header, plus a new IP header for total of 24 bytes minimum. What is best practice for tunnel MTU configuration? I’ve seen recommends of,
interface tunnel 0
ip mtu 1400
ip tcp adjust-tss 1360
Following the configuration in this lesson,
show ip interface tunnel 0
Tunnel0 is up, line protocol is up
Internet address is 172.16.123.3/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1476 bytes
Hello Ronald
In general, if you are using GRE, you do require 24 extra bytes minimum as you correctly mentioned. As a result, you can use an MTU of 1500-24=1476 as in the configuration of the lesson, and it would work. However, it is of benefit to use something like 1400 ip mtu with a tcp adjust-tss of 1360 because this will make the IP MTU much smaller than the interface MTU of 1500 (for Ethernet) and thus allow for any stray QinQ frames (+ 4 bytes) or further tunneling that may occur. The TCP adjustment of 1360 causes hosts transmitting over such a link to negotiate TCP sessions with an even smaller MTU so that no fragmentation will be necessary.
So if you are administrator of the whole network infrastructure and you are sure that the MTU settings you are applying are enough, then you should maximize the MTU sizes to what is necessary. If however your topology involves a WAN provider or a neighboring network for which you do not have full control over, it may be a good idea to use the 1400 values to ensure that no additional overhead will cause fragmentation or packet loss.
For more info on MTU, MSS, and related configurations, take a look at the following lesson:
I hope this has been helpful!
Laz
1 Like
Thanks Laz - I’ve only ever known ethernet in my time as a network engineer so to imagine that something else can exist in it’s place at layer 2 is a strange concept for me! 
I’ve since heard that home power line network can actually be used to shuttle ethernet frames around too… absolute madness! 
1 Like