DMVPN Phase 2 (Obsolete)

Introduction

The disadvantage of phase 1 is that there is no direct spoke to spoke tunnels. In phase 2, all spoke routers use multipoint GRE tunnels so we do have direct spoke to spoke tunneling. When a spoke router wants to reach another spoke, it will send an NHRP Resolution Request to the hub to find the NBMA IP address of the other spoke.

Two requirements to make spoke to spoke tunnels to work:

  1. Spoke routers need to have a route for the network that they are trying to reach.
    • Summarization on the hub is not possible since the spoke routers require specific routes.
  2. The next hop IP address of the route has to be the remote spoke.
    • 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. We will deal with this.

To allow the dynamic spoke-to-spoke tunnels to form, you need to change the spokes to multipoint tunnels. As you do that, you need to make sure that you also add a static entry for the hub, because without that entry, the NHRP Registration cannot be sent. The question then becomes, how does a spoke learn the NHRP mapping of another spoke? A system of requests and replies are used where a spoke sends a request for a particular spoke that it wants to send traffic to. It then gets a reply from the spoke in question.

This phase of DMVPN deployment has some restrictions:

  • Summarization is not allowed on the hub.
  • Default routing is not allowed on the hub.
  • The spokes must always maintain next-hop reachability.

The process looks something like the following:

  1. Spoke 1 forwards a packet with a next hop that is another spoke, spoke 2. There is no NHRP map entry for this spoke, so an NHRP Resolution Request is sent to the hub.
  2. The request from spoke 1 contains the tunnel IP address of spoke 2. The hub relays the request to spoke 2.
  3. Spoke 2 receives the request, adds its own address mapping to it, and sends it as an NHRP Reply directly to spoke 1.
				
					[+] NHRP Registration Request and Reply Packets between Spoke and Hub routers.

10	46.676013	172.16.31.1	172.16.11.1	NHRP	130	NHRP Registration Request, ID=137
11	46.693684	172.16.11.1	172.16.31.1	NHRP	150	NHRP Registration Reply, ID=137, Code=Success

'NHRP Registration Request'
NHRP Mandatory Part
    Source Protocol Len: 4
    Destination Protocol Len: 4
    Flags: 0x0002, Cisco NAT Supported
    Request ID: 0x00000089 (137)
    Source NBMA Address: 172.16.31.1
    Source Protocol Address: 192.168.100.31
    Destination Protocol Address: 192.168.100.11
    Client Information Entry

[+] NHRP Resolution Request and Reply between Spoke and Hub routers.

24	113.443221	172.16.31.1	172.16.11.1	NHRP	110	NHRP Resolution Request, ID=3
27	113.480314	172.16.41.1	172.16.31.1	NHRP	158	NHRP Resolution Reply, ID=3, Code=Success

'NHRP Resolution Request'
NHRP Mandatory Part
    Source Protocol Len: 4
    Destination Protocol Len: 4
    Flags: 0xc802, Is Router, Authoritative, Stable Binding, Cisco NAT Supported
    Request ID: 0x00000003 (3)
    Source NBMA Address: 172.16.31.1
    Source Protocol Address: 192.168.100.31
    Destination Protocol Address: 192.168.100.41
    Client Information Entry

				
			

Tunnel

  • mGRE on hub and spokes
  • NHRP required for spoke registration to hub
  • NHRP required for spoke-to-spoke resolution
  • Spoke-to-spoke tunnel triggered by spoke

Routing

  • Summarization/default routing at hub is NOT allowed
  • Next-hop on spokes is always preserved by the hub
  • Multi-level hierarchy requires hub daisy-chaining

Routing Scenarios

Tunnel

Changing the DMVPN phase 1 to phase 2 is pretty straight forward. We remove the static tunnel destination on the spoke routers and we turn the GRE interfaces into GRE multipoint.

				
					[ Hub ]
interface Tunnel0
 bandwidth 4000
 ip address 192.168.100.11 255.255.255.0
 ip mtu 1400
 ip nhrp network-id 1
 ip nhrp map multicast dynamic
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
end
				
			
				
					[ Spokes ]
interface Tunnel0
 bandwidth 4000
 ip address 192.168.100.31 255.255.255.0
 ip mtu 1400
 ip nhrp network-id 1
 ip nhrp nhs 192.168.100.11 nbma 172.16.11.1 multicast
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
end
				
			

EIGRP

EIGRP works well for DMVPN.
Two things to keep in mind for Phase 2:

  1. EIGRP has split-horizon enabled by default
  2. EIGRP changes the next-hop IP address

By fixing those two points we will have direct spoke to spoke connectivity.

				
					[ Hub ]
router eigrp A
 address-family ipv4 unicast autonomous-system 15
  af-interface Tunnel0
   no next-hop-self
   no split-horizon
  exit-af-interface
  !
  network 11.0.0.0
  network 192.0.0.0 0.255.255.255
 exit-address-family
				
			
				
					[ Spoke 1 ]
router eigrp A
  address-family ipv4 unicast autonomous-system 15
   network 31.0.0.0
   network 192.0.0.0 0.255.255.255
 exit-address-family
 
[ Spoke 2 ]
router eigrp A
 address-family ipv4 unicast autonomous-system 15
  network 41.0.0.0
  network 192.0.0.0 0.255.255.255
 exit-address-family
				
			
  • The hub has learned the networks from the spoke routers.
  • The spokes learned the 11.11.11.11/32 network from the Hub but not each other’s networks. Like RIP, EIGRP is a distance vector routing protocol so split horizon is preventing the hub from advertising these networks.
  • After disabling split-horizon spokes have learned each other networks.
  • There is another problem, next-hop IP points to Hub, when EIGRP advertises a network it will set its own IP address as the next-hop.
  • When spokes try to reach each other networks, it will go through the hub. We don’t want this so tell EIGRP not to change the next-hop IP address.
  • After disabling this, the next hop is now preserved which allows the spoke routers to reach each other directly.
				
					'[DMVPN]'
R11#show dmvpn
/*omitted*/
Interface: Tunnel0, IPv4 NHRP Details 
Type:Hub, NHRP Peers:2, 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 172.16.31.1      192.168.100.31    UP 01:00:07     D
     1 172.16.41.1      192.168.100.41    UP 01:00:07     D
R11#

R11#show ip nhrp 
192.168.100.31/32 via 192.168.100.31
   Tunnel0 created 01:00:19, expire 00:09:41
   Type: dynamic, Flags: registered nhop 
   NBMA address: 172.16.31.1 
192.168.100.41/32 via 192.168.100.41
   Tunnel0 created 01:00:19, expire 00:09:40
   Type: dynamic, Flags: registered nhop 
   NBMA address: 172.16.41.1 
R11#

'[Routing]'
R11#show ip route eigrp 
/*omitted*/
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
      31.0.0.0/32 is subnetted, 1 subnets
D        31.31.31.31 [90/26880640] via 192.168.100.31, 00:05:06, Tunnel0
      41.0.0.0/32 is subnetted, 1 subnets
D        41.41.41.41 [90/26880640] via 192.168.100.41, 00:05:04, Tunnel0
R11#
				
			
				
					'[DMVPN]'
R31#show dmvpn 
/*omitted*/
Interface: Tunnel0, IPv4 NHRP Details 
Type:Spoke, NHRP Peers:2, 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 172.16.11.1      192.168.100.11    UP 00:58:20     S
     1 172.16.41.1      192.168.100.41    UP 00:02:24     D
R31#

R31#show ip nhrp 
192.168.100.11/32 via 192.168.100.11
   Tunnel0 created 00:58:54, never expire 
   Type: static, Flags: used 
   NBMA address: 172.16.11.1 
192.168.100.41/32 via 192.168.100.41
   Tunnel0 created 00:02:47, expire 00:07:11
   Type: dynamic, Flags: router used nhop 
   NBMA address: 172.16.41.1 
R31#

'[Routing] - split-horizon/next-hop-self disabled'
R31#show ip route eigrp
/*omitted*/
Gateway of last resort is not set
      11.0.0.0/32 is subnetted, 1 subnets
D        11.11.11.11 [90/26880640] via 192.168.100.11, 00:01:12, Tunnel0
      41.0.0.0/32 is subnetted, 1 subnets
D        41.41.41.41 [90/52480640] via 192.168.100.41, 00:01:10, Tunnel0
R31#

R31#traceroute 31.31.31.31 source lo0
Type escape sequence to abort.
Tracing the route to 31.31.31.31
VRF info: (vrf in name/id, vrf out name/id)
  1 31.31.31.31 1 msec *  1 msec
R31#
				
			

OSPF

  • Point-to-Point: Doesn't work since we are using mGRE tunnels.
  • Broadcast: Best OSPF network to use for Phase 2.
    • Dynamic Peering and next-hop addresses are preserved.
  • Non-Broadcast: Behaves the same as broadcast with the exception that we have to configure static neighbors.
  • Point-to-Multipoint: Not recommended because the next-hop addresses are changed by the Hub, we won't have direct spoke-to-spoke communication.
  • Point-to-Multipoint Non-Broadcast: Same thing as the previous one with the difference of configuring static neighbors.

When using DMVPN Phase 2, we have only two choices if we want direct spoke-to-spoke communication, Broadcast and Non-Broadcast.

Broadcast

  • Make sure spoke routers will never be elected as DR/BDR.
    • interface tunnel0
      • ip ospf priority 0
  • Dynamic OSPF peering.
  • Next-hop IPs are preserved which allow for spoke-to-spoke communication.
				
					'[DMVPN]'
R11#show dmvpn
/*omitted*/
Interface: Tunnel0, IPv4 NHRP Details 
Type:Hub, NHRP Peers:2, 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 172.16.31.1      192.168.100.31    UP 01:17:27     D
     1 172.16.41.1      192.168.100.41    UP 01:17:27     D
R11#

R11#show ip nhrp 
192.168.100.31/32 via 192.168.100.31
   Tunnel0 created 01:17:33, expire 00:09:06
   Type: dynamic, Flags: registered used nhop 
   NBMA address: 172.16.31.1 
192.168.100.41/32 via 192.168.100.41
   Tunnel0 created 01:17:33, expire 00:09:06
   Type: dynamic, Flags: registered nhop 
   NBMA address: 172.16.41.1 
R11#

'[Routing]'
R11#show ip ospf neighbor 
Neighbor ID     Pri   State           Dead Time   Address         Interface
31.31.31.31       0   FULL/DROTHER    00:00:37    192.168.100.31  Tunnel0
41.41.41.41       0   FULL/DROTHER    00:00:37    192.168.100.41  Tunnel0
R11#

R11#show ip route ospf
/*omitted*/
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
      31.0.0.0/32 is subnetted, 1 subnets
O        31.31.31.31 [110/26] via 192.168.100.31, 00:02:21, Tunnel0
      41.0.0.0/32 is subnetted, 1 subnets
O        41.41.41.41 [110/26] via 192.168.100.41, 00:02:11, Tunnel0
R11#

				
			
				
					'[DMVPN]'
R31#show dmvpn
/*omitted*/
Interface: Tunnel0, IPv4 NHRP Details 
Type:Spoke, NHRP Peers:2, 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 172.16.11.1      192.168.100.11    UP 01:19:42     S
     1 172.16.41.1      192.168.100.41    UP 00:02:25     D
R31#

R31#show ip nhrp 
192.168.100.11/32 via 192.168.100.11
   Tunnel0 created 01:19:57, never expire 
   Type: static, Flags: used 
   NBMA address: 172.16.11.1 
192.168.100.41/32 via 192.168.100.41
   Tunnel0 created 00:02:30, expire 00:07:29
   Type: dynamic, Flags: router used nhop 
   NBMA address: 172.16.41.1 
R31#

'[Routing]'
R31#show ip ospf neighbor 
Neighbor ID     Pri   State           Dead Time   Address         Interface
11.11.11.11       1   FULL/DR         00:00:31    192.168.100.11  Tunnel0
R31#

R31#show ip route ospf
/*omitted*/
Gateway of last resort is not set
      11.0.0.0/32 is subnetted, 1 subnets
O        11.11.11.11 [110/26] via 192.168.100.11, 00:04:00, Tunnel0
      41.0.0.0/32 is subnetted, 1 subnets
O        41.41.41.41 [110/26] via 192.168.100.41, 00:03:50, Tunnel0
R31#

R31#traceroute 41.41.41.41 source lo0
/*Type escape sequence to abort.
Tracing the route to 41.41.41.41
VRF info: (vrf in name/id, vrf out name/id)*/
  1 192.168.100.41 7 msec *  11 msec
R31#
				
			

Non-Broadcast

  • The non-broadcast OSPF network type behaves the same as broadcast with the exception that we have to configure static neighbors.
  • Hub and Spoke routers
    • interface tunnel0
      • ip ospf network non-broadcast
  • Hub router
    • router ospf 1
      • neighbor 192.168.100.31
      • neighbor 192.168.100.41
  • The end result will be the same as Broadcast with the only difference of static neighbors.

Point-to-Multipoint

Next-hop IP address points to the Hub. All spoke-to-spoke traffic will be sent through the hub router. There is no way to change this.

Point-to-Multipoint Non-Broadcast

Same issue as the previous one, the only difference is that we configure static neighbors.

BGP

  • Spoke routers have to learn each others networks if we want direct spoke-to-spoke communication. This means we can’t use the same AS on all spoke routers since they would not accept prefixes that have the same AS number in the AS path.
  • We need a different AS number for each spoke router, this means we can’t use dynamic neighbors so we’ll have to configure them manually.

EBGP with Different AS on Spokes

EBGP preserves the next-hop addresses which is good to allow direct spoke-to-spoke communication.

				
					[ Hub ]
router bgp 11000
 bgp log-neighbor-changes
 network 10.11.11.0 mask 255.255.255.0
 neighbor 192.168.100.31 remote-as 31000
 neighbor 192.168.100.41 remote-as 41000
				
			
				
					[ Spoke 1 ]
router bgp 31000
 bgp log-neighbor-changes
 network 10.31.31.0 mask 255.255.255.0
 neighbor 192.168.100.11 remote-as 11000
 
[ Spoke 2 ]
router bgp 41000
 bgp log-neighbor-changes
 network 10.41.41.0 mask 255.255.255.0
 neighbor 192.168.100.11 remote-as 11000
				
			
				
					'[DMVPN]'
R11#show dmvpn 
/*omitted*/
Interface: Tunnel0, IPv4 NHRP Details 
Type:Hub, NHRP Peers:2, 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 172.16.31.1      192.168.100.31    UP 01:38:40     D
     1 172.16.41.1      192.168.100.41    UP 01:38:39     D
R11#

R11#show ip nhrp 
192.168.100.31/32 via 192.168.100.31
   Tunnel0 created 01:38:49, expire 00:07:51
   Type: dynamic, Flags: registered used nhop 
   NBMA address: 172.16.31.1 
192.168.100.41/32 via 192.168.100.41
   Tunnel0 created 01:38:49, expire 00:07:50
   Type: dynamic, Flags: registered used nhop 
   NBMA address: 172.16.41.1 
R11#

'[Routing]'
R11#show ip bgp summ
/*BGP router identifier 11.11.11.11, local AS number 11000*/
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.100.31  4        31000       7       8        4    0    0 00:02:57        1
192.168.100.41  4        41000       6       8        4    0    0 00:02:21        1
R11#

R11#show ip bgp
/*omitted*/
     Network          Next Hop            Metric LocPrf Weight Path
 *>   11.11.11.11/32   0.0.0.0                  0         32768 i
 *>   31.31.31.31/32   192.168.100.31           0             0 31000 i
 *>   41.41.41.41/32   192.168.100.41           0             0 41000 i
R11#

R11#show ip route bgp
/*omitted*/
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
      31.0.0.0/32 is subnetted, 1 subnets
B        31.31.31.31 [20/0] via 192.168.100.31, 00:04:07
      41.0.0.0/32 is subnetted, 1 subnets
B        41.41.41.41 [20/0] via 192.168.100.41, 00:04:07
R11#
				
			
				
					'[DMVPN]'
R31#show dmvpn
/*omitted*/
Interface: Tunnel0, IPv4 NHRP Details 
Type:Spoke, NHRP Peers:2, 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 172.16.11.1      192.168.100.11    UP 01:42:03     S
     1 172.16.41.1      192.168.100.41    UP 00:05:09     D
R31#

R31#show ip nhrp
192.168.100.11/32 via 192.168.100.11
   Tunnel0 created 01:42:18, never expire 
   Type: static, Flags: used 
   NBMA address: 172.16.11.1 
192.168.100.41/32 via 192.168.100.41
   Tunnel0 created 00:05:14, expire 00:04:45
   Type: dynamic, Flags: router used nhop 
   NBMA address: 172.16.41.1 
R31#

'[Routing]'
R31#show ip route bgp
/*omitted*/
Gateway of last resort is not set
      11.0.0.0/32 is subnetted, 1 subnets
B        11.11.11.11 [20/0] via 192.168.100.11, 00:07:11
      41.0.0.0/32 is subnetted, 1 subnets
B        41.41.41.41 [20/0] via 192.168.100.41, 00:06:40
R31#

R31#traceroute 41.41.41.41 sour loo0
/*Type escape sequence to abort.
Tracing the route to 41.41.41.41
VRF info: (vrf in name/id, vrf out name/id)*/
  1 192.168.100.41 5 msec *  8 msec
R31#
				
			

IBGP Dynamic Peers

  • The advantage of iBGP is that we can use dynamic peers.
  • We need to make sure that prefixes from one spoke router will be advertised to another spoke router. To do this, we configure the Hub router as a route reflector.
  • Just like eBGP, the next-hop IP addresses are preserved.
				
					[ Hub ]
router bgp 65000
 bgp listen range 192.168.100.0/24 peer-group SPOKES
 network 11.11.11.0 mask 255.255.255.255
 neighbor SPOKES peer-group
 neighbor SPOKES remote-as 65000
 neighbor SPOKES route-reflector-client
				
			
				
					[ Spoke 1 ]
router bgp 65000
 network 31.31.31.31 mask 255.255.255.255
 neighbor 192.168.100.11 remote-as 65000

[ Spoke 2 ]
router bgp 65000
 network 41.41.41.41 mask 255.255.255.255
 neighbor 192.168.100.11 remote-as 65000
				
			
				
					'[DMVPN]'
R11#show dmvpn 
/*omitted*/

Interface: Tunnel0, IPv4 NHRP Details 
Type:Hub, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 172.16.31.1      192.168.100.31    UP 01:56:12     D
     1 172.16.41.1      192.168.100.41    UP 01:56:12     D
R11#

R11#show ip nhrp 
192.168.100.31/32 via 192.168.100.31
   Tunnel0 created 01:56:15, expire 00:07:04
   Type: dynamic, Flags: registered used nhop 
   NBMA address: 172.16.31.1 
192.168.100.41/32 via 192.168.100.41
   Tunnel0 created 01:56:15, expire 00:07:04
   Type: dynamic, Flags: registered used nhop 
   NBMA address: 172.16.41.1 
R11#

'[Routing]'
R11#show ip bgp summ
/*BGP router identifier 11.11.11.11, local AS number 65000*/
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
*192.168.100.31 4        65000       6       9        7    0    0 00:01:00        1
*192.168.100.41 4        65000       6       6        7    0    0 00:01:03        1
* Dynamically created based on a listen range command
Dynamically created neighbors: 2, Subnet ranges: 1

BGP peergroup SPOKES listen range group members: 
  192.168.100.0/24 

Total dynamically created neighbors: 2/(100 max), Subnet ranges: 1
R11#

R11#show ip route bgp
/*omitted*/
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
      31.0.0.0/32 is subnetted, 1 subnets
B        31.31.31.31 [200/0] via 192.168.100.31, 00:01:09
      41.0.0.0/32 is subnetted, 1 subnets
B        41.41.41.41 [200/0] via 192.168.100.41, 00:01:13
R11#
				
			
				
					'[DMVPN]'
R31#show dmvpn 
/*omitted*/
Interface: Tunnel0, IPv4 NHRP Details 
Type:Spoke, NHRP Peers:2, 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 172.16.11.1      192.168.100.11    UP 01:58:41     S
     1 172.16.41.1      192.168.100.41    UP 00:02:57     D
R31#

R31#show ip nhrp 
192.168.100.11/32 via 192.168.100.11
   Tunnel0 created 01:58:55, never expire 
   Type: static, Flags: used 
   NBMA address: 172.16.11.1 
192.168.100.41/32 via 192.168.100.41
   Tunnel0 created 00:03:01, expire 00:06:57
   Type: dynamic, Flags: router used nhop 
   NBMA address: 172.16.41.1 
R31#

'[Routing]'
R31#show ip route bgp
/*omitted*/
Gateway of last resort is not set
      41.0.0.0/32 is subnetted, 1 subnets
B        41.41.41.41 [200/0] via 192.168.100.41, 00:03:30
R31#

R31#traceroute 41.41.41.41 sour lo0
/*Type escape sequence to abort.
Tracing the route to 41.41.41.41
VRF info: (vrf in name/id, vrf out name/id)*/
  1 192.168.100.41 6 msec *  4 msec
R31#
				
			

Leave a Reply

Related Post

DMVPNDMVPN

Overlay Tunnels An overlay network is a logical or virtual network built over a physical transport network referred to as an underlay network. Examples of overlay tunneling technologies include the

DMVPN Phase 3DMVPN Phase 3

Introduction Spoke routers will only have a single default route pointing to the hub router. But the spoke routers will be able to access other spoke routers or the network(s)