Posts Tagged ‘dynamic’
DMVPN stands for Dynamic Multipoint VPN and it is an effective solution for dynamic secure overlay networks. In short, DMVPN is combination of the following technologies:
1) Multipoint GRE (mGRE)
2) Next-Hop Resolution Protocol (NHRP)
4) Dynamic Routing Protocol (EIGRP, RIP, OSPF, BGP)
3) Dynamic IPsec encryption
5) Cisco Express Forwarding (CEF)
Assuming that reader has a general understanding of what DMVPN is and a solid understanding of IPsec/CEF, we are going to describe the role and function of each component in details. In this post we are going to illustrate two major phases of DMVPN evolution:
1) Phase 1 – Hub and Spoke (mGRE hub, p2p GRE spokes)
2) Phase 2 – Hub and Spoke with Spoke-to-Spoke tunnels (mGRE everywhere)
As for DMVPN Phase 3 – “Scalable Infrastructure”, a separate post is required to cover the subject. This is due to the significant changes made to NHRP resolution logic (NHRP redirects and shortcuts), which are better being illustrated when a reader has good understanding of first two phases. However, some hints about Phase 3 will be also provided in this post.
Note: Before we start, I would like to thank my friend Alexander Kitaev, for taking time to review the post and providing me with useful feedback.
I ran into these nasty frame relay mappings during an initial lab set-up and was wondering why they are there, (even with inverse-arp disabled), and what they are actually doing. I was able to remove them only after writing my configuration to memory, and then performing a reload of the router.Router(config-if)#do show frame map Serial0/0 (up): ip 0.0.0.0 dlci 113(0x71,0x1C10) broadcast, CISCO, status defined, inactive Serial0/0 (up): ip 0.0.0.0 dlci 105(0x69,0x1890) broadcast, CISCO, status defined, active Serial0/0 (up): ip 0.0.0.0 dlci 104(0x68,0x1880) broadcast, CISCO, status defined, active Serial0/0 (up): ip 0.0.0.0 dlci 103(0x67,0x1870) broadcast, CISCO, status defined, active
This is actually an error relating to AutoInstall over Frame Relay. When the router boots up and does not have a configuration file saved in NVRAM, it attempts to run autoinstall to automatically find an IP address and download a config. The first thing the router does is to detect the encapsulation on its WAN interfaces, which in this case is Frame Relay. Once the router finds that it’s running Frame Relay, it attempts to send a config request via TFTP. In order to do this it needs an IP address, so it sends a BOOTP request out all DLCIs. Since the router doesn’t know what the unicast IP addresses are on the other ends of the circuits, it creates IPv4 mappings to 0.0.0.0 for all circuits and includes the “broadcast” keyword on them. This allows the router to encapsulate the BOOTP request out all DLCIs.
If you haven’t actually configured IP helper-address or a BOOTP server, the operation will fail. The result of this that we see is that when Frame Relay is re-enabled on the interfaces the mappings to 0.0.0.0 reappear. In some versions of IOS this can be fixed by removing Frame Relay and re-applying it, for example:
router#config t router(config)#interface s0/0 router(config-if)#encapsulation ppp router(config-if)#encapsulation frame-relay router(config-if)#end router#
In most versions however this does not work. Therefore the way to fix this is just to have the router not do autoinstall on bootup. Since the router does autoinstall because it doesn’t have a config saved in memory, the only way to 100% fix it is to save your config to NVRAM (wr m), and to reload.