DMVPN – Huge DMVPN Lab, multi-branch deployment considerations, Phase 1 to Phase 2 DMVPN clearly demonstrated, lots of configuration and verification!

DMVPN_Top1

The above Topology has already been configured with its respective IP Addressing / Routing Protocols, all Adjacencies are Up/Up, and we are ready to jump straight into NHRP (Next Hop Resolution Protocol) configuration on the Hub / NHS (Next Hop Server) which will be PHX1 Router in this Topology and then onto the DMVPN Spokes!

If you want to fully grasp the fundamentals of DMVPN, you found the right spot!

All locations WAN routers have their Fa0/0 configured with “ip ospf pri 0” so the ISP Router shows all neighbors as DROTHER:

ISP#sh ip ospf nei

Neighbor ID Pri State Dead Time Address Interface
172.16.123.13 0 FULL/DROTHER 00:00:36 172.16.123.13 FastEthernet3/0
172.16.123.9 0 FULL/DROTHER 00:00:30 172.16.123.9 FastEthernet2/0
172.16.123.5 0 FULL/DROTHER 00:00:33 172.16.123.5 FastEthernet1/0
172.16.123.1 0 FULL/DROTHER 00:00:37 172.16.123.1 FastEthernet0/0

A quick connectivity test across the “WAN” was done on PHX1 before configuration:

PHX1#ping 172.16.123.9
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/47/52 ms
PHX1#

As will be seen, as logical Tunnel Interfaces are created for the DMVPN their network will need to be added to EIGRP on the edge routers, as you cannot enter IP Addresses into EIGRP that do not exist on the router!

A quick explanation of how to plan a deployment successfully

All Logical Tunnel interfaces must be on the same common subnet to communicate, so you will want to measure twice and cut once when planning your subnet scheme, and the NHRP Network-ID must match between participants as its unique identifier to the NHS or “Hub” router similar to an OSPF Area # or EIGRP AS #.

I chose 192.168.1.0/24 for my Logical network, using the different locations LAN’s unique # as their last octet address, and the NHRP network-id of 11 as that number will not be used anywhere else in this lab.

You may be able to make your EIGRP AS 11, OSPF Area 11, and Network-ID 11 however that is the kind of thing bug reports are made of in Cisco TAC documentation 🙂

With that I will walk step by step first through Hub or NHS Configuration

The Hub or NHS (Next Hop Server) router has a fairly basic configuration as compared to spokes as shown below, as it will dynamically process traffic from the Spokes or NHC (Next Hop Client) routers.

So I will start with the Hub, and work around the Topology.

First step in configuring the Tunnel Interface / IP Assignment / Adding to EIGRP

PHX1(config)#int tu0
PHX1(config-if)#
*Dec 5 12:39:52.931: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
PHX1(config-if)#ip address 192.168.1.10 255.255.255.0
PHX1(config-if)#router eigrp 100
PHX1(config-router)#network 192.168.1.0
PHX1(config-router)#int tu0
PHX1(config-if)#ip nhrp network-id 11
PHX1(config-if)#

This should be like a template to ensure everything is matching, EIGRP at all sites is aware of the DMVPN network as soon as we IP the Tunnel Interface, life is good!

Next step

PHX1(config-if)#
PHX1(config-if)#ip nhrp map multicast dynamic
PHX1(config-if)#

This command is telling the Tunnel Interface to allow Dynamic Multicast traffic to flow through it, being the Dynamic nature of DMVPN / Multicast nature of Routing, we will need this enabled across all the edge routers.

Next step

PHX1(config-if)#
PHX1(config-if)#tunnel source fa0/0
PHX1(config-if)#

The “tunnel source” for DMVPN ideally will be the physical WAN facing interface rather than the public IP, although the WAN IP as a tunnel source can work, the physical interface is likely to change far less than the IP Address.

DMVPN does not have a “tunnel destination” because the destination is Dynamic!

Next step

PHX1(config-if)#
PHX1(config-if)#tunnel mode gre multipoint
PHX1(config-if)#
*Dec 5 13:04:01.027: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
PHX1(config-if)#

Which brings us to the point of the Destination being “Dynamic” rather than static, defining multipoint as the GRE tunnel mode means it is not a 1:1 mapping, like a site to site VPN or a GRE Tunneling IPv4 traffic through an IPv6 network.

Final step of adjusting the Tunnel Interface MTU for IPSec

PHX1(config-if)#
PHX1(config-if)#ip mtu 1400
PHX1(config-if)#

The Maximum Transmission Unit (MTU) of the Tunnel Interface technically only needs to be 1420 MTU for IPSec encryption to avoid fragmentation (assuming the Physical Egress Interface is at the default 1500 MTU), however I give it a little breathing room at 1400.

The MTU does not need to be adjusted if the Tunnel Interface is not using any kind of encryption or authentication, for initial configuration of DMVPN the MTU does not need to be adjusted at all.

Everything you need to know about Tunnel Fragmentation can be found here.

And thus the Hubs Tunnel interface comes to life!

The final configuration of the PHX1 Router as the NHS is simply a Tunnel Interface:

PHX1(config-if)#do sh run int tu0
Building configuration…

Current configuration : 207 bytes
!
interface Tunnel0
ip address 192.168.1.10 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast dynamic
ip nhrp network-id 11
tunnel source FastEthernet0/0
tunnel mode gre multipoint
end

PHX1(config-if)#

This is as far as the configuration need to go for DMVPN communication with no IPSec Security Profile being applied right now, however the spoke sites will need a few extra commands we will walk through to reach the Hub or NHRP “NHS” or Next Hop Server that assists in the creation of VPN tunnels between DMVPN participants.

Minneapolis

MPLS1(config)#int tu0
*Dec 5 13:10:49.699: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
MPLS1(config-if)#ip add 192.168.1.1 255.255.255.0
MPLS1(config-if)#router eigrp 100
MPLS1(config-router)#network 192.168.1.0
MPLS1(config-router)#int tu0
MPLS1(config-if)#ip nhrp network-id 11
MPLS1(config-if)#ip nhrp map multicast dynamic
MPLS1(config-if)#tunnel source fa0/0
MPLS1(config-if)#tunnel mode gre multipoint
MPLS1(config-if)#ip mtu 1400
*Dec 5 13:12:59.819: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
MPLS1(config-if)#

Defining NHS Server

MPLS1(config-if)#
MPLS1(config-if)#ip nhrp nhs 192.168.1.10
MPLS1(config-if)#

This is telling the tunnel where its NHRP Next Hop Server is located in the logical Tunnel IP Network called the “Overlay” Address, which next we map to the “Underlay” Address.

Mapping Logical to Public Address (Overlay to Underlay)

MPLS1(config-if)#
MPLS1(config-if)#ip nhrp map 192.168.1.10 172.16.123.1
MPLS1(config-if)#

After defining the NHS by the logical “Overlay” IP Address, it is then mapped to its publicly routable IP Address called the “Underlay” IP Address, which would be the publicly routed WAN / Internet as demonstrated here over my “WAN” :

MPLS1(config-if)#do ping 172.16.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/50/60 ms
MPLS1(config-if)#

The NHS is reachable via the “Underlay” or WAN Address, so life is good.

Defining where to send Multicast Traffic (NHS Underlay IP)

MPLS1(config-if)#
MPLS1(config-if)#ip nhrp map multicast 172.16.123.1
MPLS1(config-if)#

This tells the NHRP Tunnel Interface where to direct its Multicast traffic (the NHS) for help dynamically creating VPN Tunnel to other DMVPN Participants.

For comparison to the NHS, our first spoke Tunnel Interface appears as this:

MPLS1(config-if)#do sh run int tu0
Building configuration…

Current configuration : 320 bytes
!
interface Tunnel0
ip address 192.168.1.1 255.255.255.0
no ip redirects
ip nhrp map multicast dynamic
ip nhrp map 192.168.1.10 172.16.123.1
ip nhrp map multicast 172.16.123.1
ip nhrp network-id 11
ip nhrp nhs 192.168.10.1
ip nhrp nhs 192.168.1.10
tunnel source FastEthernet0/0
tunnel mode gre multipoint
end

MPLS1(config-if)#

This is bare bones configuration, no encryption or authentication on the Tunnel, which is all we are doing is creating Tunnel interfaces to publicly reachable WAN routers.

Atlanta

ATL1(config)#int tu0
*Dec 5 13:14:01.899: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
ATL1(config-if)#ip add 192.168.1.2 255.255.255.0
ATL1(config-if)#router eigrp 100
ATL1(config-router)#network 192.168.1.0
ATL1(config-router)#int tu0
ATL1(config-if)#ip nhrp network-id 11
ATL1(config-if)#ip nhrp map multicast dynamic
ATL1(config-if)#tunnel source fa0/0
ATL1(config-if)#tunnel mode gre multipoint
ATL1(config-if)#ip mtu 1400
*Dec 5 13:14:25.715: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
ATL1(config-if)#ip nhrp nhs 192.168.1.10
ATL1(config-if)#ip nhrp map 192.168.1.10 172.16.123.1
ATL1(config-if)#ip nhrp map multicast 172.16.123.1
ATL1(config-if)#

Milwaukee

MIL1(config)#int tu0
*Dec 5 13:15:31.947: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
MIL1(config-if)#ip add 192.168.1.3 255.255.255.0
MIL1(config-if)#router eigrp 100
MIL1(config-router)#network 192.168.1.0
MIL1(config-router)#int tu0
MIL1(config-if)#ip nhrp network-id 11
MIL1(config-if)#ip nhrp map multicast dynamic
MIL1(config-if)#tunnel source fa0/0
MIL1(config-if)#tunnel mode gre multipoint
MIL1(config-if)#ip mtu 1400
*Dec 5 13:16:15.363: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
MIL1(config-if)#ip nhrp nhs 192.168.1.10
MIL1(config-if)#ip nhrp map 192.168.1.10 172.16.123.1
MIL1(config-if)#ip nhrp map multicast 172.16.123.1
MIL1(config-if)#

These sites are now fully DMVPN ready with zero encryption or authentication, though we do have the MTU on the Tunnel Interface adjusted to apply IPSec, that has not been done yet as we hammer through the core NHRP / GRE concepts and configurations.

To review the steps exactly for NHS configuration

  1. Create tunnel interface
  2. Assign Tunnel “Overlay” IP Address
  3. Assign IP NHRP Network-ID #
  4. Configure “ip nhrp map multicast dynamic”
  5. Configure WAN interface or WAN IP as “tunnel source”
  6. Configure “tunnel mode gre multipoint”

That is it, you have an NHS Server for the DMVPN Network, want to add a spoke?

7. Configure “ip nhrp nhs (logical ip)”
8. Configure “ip nhrp map (NHS Overlay) (NHS Underlay)”
9. Configure “ip nhrp map multicast (NHS Overlay)”

Want to add 50 more spokes? Repeat as needed with a unique IP within the common “Overlay” subnet and make sure the sites can communicate over the WAN!

So what is visible from where in our Network Topology after that configuration?

Lets review the Topology once more and look at our “internal” routers IP Route tables:

DMVPN_Top1

PHX2 – 10.10.10.0/24

PHX2#sh ip route
(Codes redacted)

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
D 10.0.1.0/24 [90/26887680] via 10.10.10.254, 01:14:02, FastEthernet1/0
D 10.0.2.0/24 [90/26887680] via 10.10.10.254, 00:44:17, FastEthernet1/0
D 10.0.3.0/24 [90/26887680] via 10.10.10.254, 00:43:54, FastEthernet1/0
C 10.0.10.0/24 is directly connected, FastEthernet2/0
L 10.0.10.1/32 is directly connected, FastEthernet2/0
D 10.10.1.0/24
[90/26885120] via 10.10.10.254, 01:14:02, FastEthernet1/0
D 10.10.2.0/24
[90/26885120] via 10.10.10.254, 00:44:17, FastEthernet1/0
D 10.10.3.0/24
[90/26885120] via 10.10.10.254, 00:43:54, FastEthernet1/0
C 10.10.10.0/24 is directly connected, FastEthernet1/0
L 10.10.10.253/32 is directly connected, FastEthernet1/0
D 192.168.1.0/24 [90/26882560] via 10.10.10.254, 01:47:24, FastEthernet1/0
PHX2#

Behind PHX1 (NHS) we can see all other EIGRP Networks, along with the DMVPN Tunnel Network of 192.168.1.0/24, so everything looks good here.

MPLS2 – 10.10.1.0/24

MPLS2#sh ip route
(Codes redacted)

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C 10.0.1.0/24 is directly connected, FastEthernet2/0
L 10.0.1.1/32 is directly connected, FastEthernet2/0
D 10.0.10.0/24 [90/26887680] via 10.10.1.254, 01:05:44, FastEthernet1/0
C 10.10.1.0/24 is directly connected, FastEthernet1/0
L 10.10.1.253/32 is directly connected, FastEthernet1/0
D 10.10.10.0/24
[90/26885120] via 10.10.1.254, 01:05:44, FastEthernet1/0
D 192.168.1.0/24 [90/26882560] via 10.10.1.254, 01:59:55, FastEthernet1/0
MPLS2#

I was wondering what could be causing this as we have OSPF running over the WAN, however all of our EIGRP advertisements are still subject to the rule of “Split Horizon” of Distance Vector routing, which means PHX1 Fa0/0 will send EIGRP Advertisements out of the same interface it is received on!

This being the case, Split Horizon must be disabled on the NHS Tunnel Interface

PHX1(config)#int tu0
PHX1(config-if)#no ip split-horizon eigrp 100
PHX1(config-if)#
*Dec 5 15:41:36.579: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.1.3 (Tunnel0) is resync: split horizon changed
*Dec 5 15:41:36.579: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.1.2 (Tunnel0) is resync: split horizon changed
*Dec 5 15:41:36.583: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.1.1 (Tunnel0) is resync: split horizon changed
PHX1(config-if)#

Turning off Split Horizon causes all EIGRP Adjacencies to bounce, now lets see how the MPLS2 IP Route Table is looking after this change:

MPLS2#sh ip route
(Codes redacted)

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
C 10.0.1.0/24 is directly connected, FastEthernet2/0
L 10.0.1.1/32 is directly connected, FastEthernet2/0
D 10.0.2.0/24 [90/28167680] via 10.10.1.254, 00:01:58, FastEthernet1/0
D 10.0.3.0/24 [90/28167680] via 10.10.1.254, 00:01:58, FastEthernet1/0
D 10.0.10.0/24 [90/26887680] via 10.10.1.254, 01:33:08, FastEthernet1/0
C 10.10.1.0/24 is directly connected, FastEthernet1/0
L 10.10.1.253/32 is directly connected, FastEthernet1/0
D 10.10.2.0/24 [90/28165120] via 10.10.1.254, 00:01:58, FastEthernet1/0
D 10.10.3.0/24 [90/28165120] via 10.10.1.254, 00:01:58, FastEthernet1/0
D 10.10.10.0/24
[90/26885120] via 10.10.1.254, 01:33:08, FastEthernet1/0
D 192.168.1.0/24 [90/26882560] via 10.10.1.254, 02:27:19, FastEthernet1/0
MPLS2#

We have lift off! Lets test out our network reachability with a traceroute:

MPLS2#traceroute 10.10.2.254
Type escape sequence to abort.
Tracing the route to 10.10.2.254
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.1.254 52 msec 48 msec 48 msec   <— MPLS1 Fa1/0 Internal Interface
2 192.168.1.10 48 msec 56 msec 68 msec   <— PHX1 (NHS) Overlay Address
3 192.168.1.2 88 msec * 60 msec   <— ATL1 Overlay Address
MPLS2#

That doesn’t look like spoke to spoke to me, lets try that again:

MPLS2#traceroute 10.10.2.254
Type escape sequence to abort.
Tracing the route to 10.10.2.254
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.1.254 56 msec 48 msec 44 msec
2 192.168.1.10 48 msec 48 msec 48 msec
3 192.168.1.2 68 msec * 52 msec
MPLS2#

Traffic from Minneapolis (and all spoke sites) are relying on the NHS to “relay” their communication, rather than Dynamically forming VPN Tunnels between peers.

This is what you call a “Phase 1 DMVPN” deployment, where sites CAN dynamically communicate with each other, however the communication must route up to the NHS first to then be relayed to the destination – This is better but NOT what we want!

We want to get to Phase 2 DMVPN where the NHS just assists with creating VPN Tunnels between DMVPN Peers, not being the work horse for all communication!

Fortunately Phase 2 DMVPN is one quick command away on the NHS router!

Coming fresh out of CCNP R/S Certification the command required for this is kind of surprising, completely not surprising, and I will explain why after showing it:

PHX1(config-if)#
PHX1(config-if)#no ip next-hop-self eigrp 100
PHX1(config-if)#
*Dec 5 15:53:07.271: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.1.3 (Tunnel0) is down: next_hop_self value changed
*Dec 5 15:53:07.307: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.1.2 (Tunnel0) is down: next_hop_self value changed
*Dec 5 15:53:07.339: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.1.1 (Tunnel0) is down: next_hop_self value changed
*Dec 5 15:53:08.135: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.1.3 (Tunnel0) is up: new adjacency
*Dec 5 15:53:08.227: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.1.1 (Tunnel0) is up: new adjacency
PHX1(config-if)#
*Dec 5 15:53:08.311: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.1.2 (Tunnel0) is up: new adjacency
PHX1(config-if)#

When studying BGP rules, one of them states that iBGP Peers must have “next-hop-self” to designate themselves as a sort of “Route Reflector” or quite literally a next hop for distant networks, whereas with DMVPN and EIGRP we are literally doing the reverse 🙂

That is just so cool to understand the concept of “next-hop-self” and how by removing that, we are telling the NHS not to make itself part of the path, mind = blown!

SO, after all that geeking out, lets take a look back at MPLS2 IP Route Table:

MPLS2#sh ip route
(Codes redacted)

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
C 10.0.1.0/24 is directly connected, FastEthernet2/0
L 10.0.1.1/32 is directly connected, FastEthernet2/0
D 10.0.2.0/24 [90/28167680] via 10.10.1.254, 00:06:04, FastEthernet1/0
D 10.0.3.0/24 [90/28167680] via 10.10.1.254, 00:06:04, FastEthernet1/0
D 10.0.10.0/24 [90/26887680] via 10.10.1.254, 00:06:04, FastEthernet1/0
C 10.10.1.0/24 is directly connected, FastEthernet1/0
L 10.10.1.253/32 is directly connected, FastEthernet1/0
D 10.10.2.0/24 [90/28165120] via 10.10.1.254, 00:06:04, FastEthernet1/0
D 10.10.3.0/24 [90/28165120] via 10.10.1.254, 00:06:04, FastEthernet1/0
D 10.10.10.0/24
[90/26885120] via 10.10.1.254, 00:06:04, FastEthernet1/0
D 192.168.1.0/24 [90/26882560] via 10.10.1.254, 02:42:38, FastEthernet1/0
MPLS2#

Still looking good, now lets do TWO traceroutes to see if a Tunnel builds!

MPLS2#traceroute 10.10.2.254
Type escape sequence to abort.
Tracing the route to 10.10.2.254
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.1.254 52 msec 48 msec 48 msec
2 192.168.1.10 92 msec 48 msec 48 msec
3 192.168.1.2 68 msec * 36 msec
MPLS2#traceroute 10.10.2.254
Type escape sequence to abort.
Tracing the route to 10.10.2.254
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.1.254 32 msec 52 msec 44 msec
2 192.168.1.2 48 msec * 56 msec
MPLS2#

*** !!! WE ARE NOW AT PHASE 2 DMVPN LADIES AND GENTLEMEN !!! ***

Lets see if ATL2 “internal” Router can just 2-hop traceroute right back to MPLS2:

ATL2#traceroute 10.10.1.254
Type escape sequence to abort.
Tracing the route to 10.10.1.254
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.2.254 52 msec 52 msec 48 msec
2 192.168.1.1 68 msec * 32 msec
ATL2#

Kapow!

The sites do need to initiate the “interesting traffic” as its called with a site-to-site IPSec VPN Tunnel, but it doesn’t establish a traditional Tunnel session as I’d look at it:

ATL1#sh cry isa sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status

IPv6 Crypto ISAKMP SA

ATL1#sh cry ipsec sa
No SAs found
ATL1#

It just dynamically adds the Minneapolis Routes to ATL1’s IP Route Table as though it were off a trusted internal phyiscal interface:

ATL1#sh ip route
(Codes redacted)

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
D 10.0.1.0/24 [90/28165120] via 192.168.1.1, 00:12:09, Tunnel0
D 10.0.2.0/24 [90/30720] via 10.10.2.253, 00:12:09, FastEthernet1/0
D 10.0.3.0/24 [90/28165120] via 192.168.1.3, 00:12:09, Tunnel0
D 10.0.10.0/24 [90/26885120] via 192.168.1.10, 00:12:09, Tunnel0
D 10.10.1.0/24 [90/28162560] via 192.168.1.1, 00:12:09, Tunnel0
C 10.10.2.0/24 is directly connected, FastEthernet1/0
L 10.10.2.254/32 is directly connected, FastEthernet1/0
D 10.10.3.0/24 [90/28162560] via 192.168.1.3, 00:12:09, Tunnel0
D 10.10.10.0/24 [90/26882560] via 192.168.1.10, 00:12:09, Tunnel0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
O 172.16.123.0/30 [110/2] via 172.16.123.10, 03:27:52, FastEthernet0/0
O 172.16.123.4/30 [110/2] via 172.16.123.10, 03:27:52, FastEthernet0/0
C 172.16.123.8/30 is directly connected, FastEthernet0/0
L 172.16.123.9/32 is directly connected, FastEthernet0/0
O 172.16.123.12/30 [110/2] via 172.16.123.10, 03:27:52, FastEthernet0/0
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, Tunnel0
L 192.168.1.2/32 is directly connected, Tunnel0
ATL1#

As long as the sites remain reachable, and they are advertising routes to each other which keeps the routes in the IP Route Table, its a VPN Tunnel without a VPN Tunnel!

P1toP2

This graphic is quite literally the birth of a Phase 1 DMVPN Network to a Phase 2 DMVPN Network, and fully understanding what it means and what it took to get it there is a huge sense of accomplishment coming from someone who has studied this in depth before!

The CCNP level studies were quite intense, but getting into these CCIE Level topics of MPLS and DMVPN, it really opens up network technologies infinitely. Amazing 🙂

I will halt this DMVPN madness here, as I could keep geeking out for days in a post!

Next up I will walk through an IPSec Profile setup, explore some different options to tweak the DMVPN settings between sites, though I am not sure I will necessarily make it to “Phase 3 DMVPN” before I am back to MPLS at Layer 2 (AToM / VPLS / Etc).

Until next time!

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s