I'll have to simulate the failure again and dig a bit deeper to be sure, but my thought is that even tho the tunnel is up, the spoke still needs to get the next hop info from the hub, thus the NHRP. When it can't get to the hub, it doesn't "know" to use the tunnel because the spoke's routing table isn't updated with the route info to get other spokes. The spoke's routing table only contains info on how to route to the hub.
Thanks for ur great time... to have a direct spoke to spoke connectivity between the spokes . on Hub use the command R1# ip nhrp redirect and on spokes use R2# ip nhrp redirect R2# ip nhrp shortcut and the same on R3 as well R3# ip nhrp redirect R3# ip nhrp shortcut Hope it resolves ....
This is a fantastic video. Full of brilliant info.My question is can we use HSRP for redundancy on the hub router. In other words if we had another router on standby in case of a hub failover?Cheers
Hi, first of all, a very good video, thank you. Can you let me know, which program you used? I did the same im GNS3 but were not able to configure the cloud.
I love this video! As for your questions, I believe I know the answer to your first question on redundancy. Like you, I am some what familiar with the routing processes so in the past I have seen multiple "Hub" routers that are configured in a mesh like design. For example, R1 and R2 are Hubs that are physically or dynamically connected to each other and share the same network information. If one of the routers were to fail, the "spokes" would then rely on the either router for tunnel information. If I am off, please let me know. Again, I am not an expert and this is just something I have seen in the past. Does what I said makes sense?
Just so you know.... when naming your NHS's.. you're not limited to 1 IP addy... you just need additional map commands for all servers and you have your wanted redundancy...
Great video. Thanks for taking time to share. I got a doubt when you are simulating a failure from R1 side. You did a ping from R2 to R3, which was successful (means dynamic tunnel was established b/w R2, R3). Then you shut the interface on R1. But as you said that spoke devices use hub only to establish the tunnel and not for the data traffic. Then as we already established the tunnel why the ping from R2 to R3 failed when we shut the interface on R1? Can you please help me understand this?
What Happens if your DMVPN host site goes down? How can the branch sites continue to communicate if they have to be actively instructed for each cross connection, or did I miss something? Can you configure an alternate DMVPN Host for failover negotiation?
Great video. But implementing a DMVPN *Phase 2* solution sorts out all your issues with lack of redundancy with the HUB. You don't need to have all your traffic flowing through R1 before going to spoke sites.
I'll have to simulate the failure again and dig a bit deeper to be sure, but my thought is that even tho the tunnel is up, the spoke still needs to get the next hop info from the hub, thus the NHRP. When it can't get to the hub, it doesn't "know" to use the tunnel because the spoke's routing table isn't updated with the route info to get other spokes. The spoke's routing table only contains info on how to route to the hub.
very good. ur explanation is very good. I became a big fan of you.
Thanks for ur great time... to have a direct spoke to spoke connectivity between the spokes .
on Hub use the command
R1# ip nhrp redirect
and on spokes use
R2# ip nhrp redirect
R2# ip nhrp shortcut
and the same on R3 as well
R3# ip nhrp redirect
R3# ip nhrp shortcut
Hope it resolves ....
this video helped a lot... and some of the comments on the video.. cleared the doubt for redundancy as well. Thanks for sharing. :-)
Thanks for the detailed videos... I know there is a way to do a 2 headend solution which may take care of the single point of failure...
This is a fantastic video. Full of brilliant info.My question is can we use HSRP for redundancy on the hub router. In other words if we had another router on standby in case of a hub failover?Cheers
Hi, first of all, a very good video, thank you. Can you let me know, which program you used? I did the same im GNS3 but were not able to configure the cloud.
I love this video! As for your questions, I believe I know the answer to your first question on redundancy. Like you, I am some what familiar with the routing processes so in the past I have seen multiple "Hub" routers that are configured in a mesh like design. For example, R1 and R2 are Hubs that are physically or dynamically connected to each other and share the same network information. If one of the routers were to fail, the "spokes" would then rely on the either router for tunnel information. If I am off, please let me know. Again, I am not an expert and this is just something I have seen in the past. Does what I said makes sense?
Just so you know.... when naming your NHS's.. you're not limited to 1 IP addy... you just need additional map commands for all servers and you have your wanted redundancy...
Great video. Thanks for taking time to share. I got a doubt when you are simulating a failure from R1 side. You did a ping from R2 to R3, which was successful (means dynamic tunnel was established b/w R2, R3). Then you shut the interface on R1. But as you said that spoke devices use hub only to establish the tunnel and not for the data traffic. Then as we already established the tunnel why the ping from R2 to R3 failed when we shut the interface on R1? Can you please help me understand this?
Question I am trying to recreate this in GNS3 how did you configure the cloud I am just a little confused on that part everything else I got.
Thanks
Great Video, very helpful.
Thanks for a detailed video of DMPVN , can you explain difference between config EIGRP and OSPF BGP through DMPVN
What Happens if your DMVPN host site goes down? How can the branch sites continue to communicate if they have to be actively instructed for each cross connection, or did I miss something? Can you configure an alternate DMVPN Host for failover negotiation?
Great video. But implementing a DMVPN *Phase 2* solution sorts out all your issues with lack of redundancy with the HUB. You don't need to have all your traffic flowing through R1 before going to spoke sites.
Nice.. Redundancy is required for large network. (more than 2 spokes)
Nice Video
Great video....
Thank you for good job !!!!
Awesome
GOOD