DMVPN-Part2

Routing protocols in Phase 1:

The next hop will always be the HUB.

In Phase1, the control plane should be kept as simple as possible because the data plane is always going to be point-to-point hub and spoke tunnels

regardless of the next-hop and routing protocol.

Eigrp:

On enabling eigrp, the spokes can establish adjacency with the hub.

They can’t establish adjacency with other spokes as they cannot replicate multicast traffic directly between them (in all the three phases of dmvpn).

To establish connectivity between spokes, we have two options

First one is, advertise a default route

R5(config-if)#int tun0

R5(config-if)#ip summary-address eigrp 100 0.0.0.0 0.0.0.0

Second one is, disable split-horizon. Spokes will learn the routes from other spokes but the next-hop will be the HUB.

R5(config-if)#int tun0

R5(config-if)#no ip split-horizon eigrp 100

ODR:

ODR is based on CDP.

CDP is enabled by default from IOS 15.x.Just make sure cdp is running on the tunnel interfaces.

R5#show cdp neighbors

Steps to run ODR

First enable cdp on the tunnel interface,

R5(config)#cdp run

R5(config)#int tun0

R5(config-if)#cdp enable

Enable ODR, this must be done the hub, the hub will announce a default route to the spokes and spokes will send their connected links information in the cdp messages to the HUB.

R5(config)#router odr

If any other routing protocol is enabled ODR will not run.

Exchange routing information without enabling any routing protocol.

BGP:

One of the major advantage of DMVPN is ,

We can easily add a spoke without changing any configuration on the existing devices.

When using BGP,this advantage is broken. We may have to do BGP configuration changes, policy changes.

We can use dynamic BGP configuration as a workaround for this.

We can use iBGP or eBGP to speak to the HUB.

RIP:

Normal configuration commands to enable rip.

We can send a default route to the spokes as

R5(config)#route-map DEFAULT  permit 10
R5(config-route-map)#set interface Tunnel0
R5(config)#router rip
R5(config-router)#default-information originate route-map DEFAULT

Or

Disable split horizon

R5(config)#int Tu0
R5(config-if)#no ip split-horizon

OSPF:

When OSPF is configured over GRE tunnel interfaces, the OSPF network type defaults to point-to-point.

This is not supported in a DMVPN design, because the hub must maintain multiple adjacencies on the same interface, one for each remote spoke.

In DMVPN Phase 1 with OSPF, the OSPF network type is set to point-to-multipoint on the hub at a minimum. With the hub being OSPF network type point-to-multipoint and the spokes being OSPF network type point-to-point, adjacency is supported, as long as the timer values match.

DMVPN PHASE2:

The main problem with phase1 is all the spoke to spoke traffic must pass through HUB putting huge stress on the hub resources.

This limitation was primarily due to the configuration of the spoke as ‘point-point gre tunnel’ rather than ‘multipoint gre tunnel’.

Phase2 permits spoke to spoke tunnels, for this we need to configure the spokes as ‘multipoint gre tunnels’

The only configuration change we need to do is, on all the spokes

R4(config-if)#int tun0

R4(config-if)#no tunnel destination àremoving point-to-point tunnel setting

R4(config-if)#tunnel mode gre multipoint àenabling multipoint gre tunnel on spokes

No configuration changes on the hub.

Routing tables in phase2,

We now know all the networks behind the spokes with next-hops

R4#sh ip route

Gateway of last resort is not set

      14.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C        14.1.1.0/24 is directly connected, Tunnel0

L        14.1.1.4/32 is directly connected, Tunnel0

      150.1.0.0/32 is subnetted, 5 subnets

D        150.1.1.1 [90/28288000] via 14.1.1.1, 00:00:16, Tunnel0

D        150.1.2.2 [90/28288000] via 14.1.1.2, 00:00:16, Tunnel0

D        150.1.3.3 [90/28288000] via 14.1.1.3, 00:00:16, Tunnel0

C        150.1.4.4 is directly connected, Loopback0

D        150.1.5.5 [90/27008000] via 14.1.1.5, 00:00:33, Tunnel0

The implications are

·        Summarization is not allowed on the hubàif summarized, all the traffic will take the path spoke-hub-spoke

·        Next-hop must always be preserved by the hub

Routing protocols in phase2:

Eigrp:

The following configuration must be done on the hub

R5(config-if)#int tun0

R5(config-if)#no ip split-horizon eigrp 100àto advertise networks behind the spokes

R5(config-if)#no ip next-hop-self eigrp 100

OSPF:

One of the main requirements in phase2 is, the routing protocol must preserve the next-hop.

We need to use the OSPF network type that preserves the next-hop, so ospf network type point-to-multipoint is not supported in phase2.

Routing table with ospf network type point-to-multipoint

R2#show ip route ospf

O        150.1.1.1 [110/2001] via 14.1.1.5, 00:0:27, Tunnel0

O        150.1.3.3 [110/2001] via 14.1.1.5, 00:0:27, Tunnel0

O        150.1.4.4 [110/2001] via 14.1.1.5, 00:0:34, Tunnel0

To run ospf in phase2, we need to use the network type Broadcast or NBMA which preserves the next-hop.

It means

·        we need to configure the spokes that they never become DR and BDR(spoke to spoke direct flooding is not possible, spokes all are in same layer3 but not in same layer2 )

·        Not more than 2 hubs are permitted one DR and BDR

By default the network type on tunnel interface is point-to-multipoint, the following configuration must be done on the spokes

R4(config-if)#int tun0

R4(config-if)#ip ospf priority 0 àso that spokes never attempt to claim as DR/BDR because hub cannot preempt them once they think they are DR/BDR

R4(config-if)#ip ospf network broadcast

On the hub,

R5(config-if)#int tun0

R5(config-if)#ip ospf network broadcast

The routing table with ospf network type broadcast/NBMA

R2#show ip route ospf

O        150.1.1.1 [110/2001] via 14.1.1.1, 00:0:27, Tunnel0

O        150.1.3.3 [110/2001] via 14.1.1.3, 00:0:27, Tunnel0

O        150.1.4.4 [110/2001] via 14.1.1.4, 00:0:34, Tunnel0

The next-hop is preserved and when R2 wants to communicate with 150.1.3.3,a spoke-to-spoke tunnel will be established between R2 and R3

A nice and simple explanation of spoke-to-spoke tunnel creation,

https://fredrikjj.wordpress.com/2014/08/14/mgre-and-nhrp-static-phase-1-phase-2/

Here are the steps,

1. R2 gets a packet with a next hop R3. There is no NHRP map entry for R3, so an NHRP resolution request is sent to the hub.
2. The request from R2 will also have the NBMA address of R2. The hub relays the request to R3.
3. R3 receives the request, adds its own address mapping to it and sends it as an NHRP reply directly to R2.
4. R3 then sends its own request to the hub that relays it to R2.
5. R2 receives the request from R3 via the hub and replies by adding its own mapping to the packet and sending it directly to R3

Technically, the requests themselves provide enough information to build a spoke to spoke tunnel but the replies accomplish two things. They acknowledge to the other spoke that the request was received and also verify that spoke to spoke NBMA reachability exists.

DMVPN PHASE3:

The problem with phase2 is scalability.

·        Summarization is not allowed at hub, as a result all the spokes must have routes to all the subnets. This results in huge routing tables/updates.

·        Scalability when the no. of devices increases, very good explanation is provided at the following link

http://brbccie.blogspot.in/2014/05/dmvpn.html

Phase3 solves the main issue of phase1 in a different way.

When the spoke forwards a packet to the hub, the hub will check if the destination is reachable via the same tunnel and in such a case will redirect the spoke to the destination attached spoke.

This is how phase3 works,

1.     R1 and R2 announce the subnets attached to the hub.

2.     The hub can be configured to advertise a default route to the spokes.

3.     Now R1 needs to send traffic to 23.1.1.1, it will send the packet to hub.

4.     The hub will see that the destination is reachable via the same tunnel, so it will send nhrp redirect packet to R1.

5.     R1 will send an nhrp resolution request for the IP 23.1.1.1.The hub will relay this nhrp request to R2.

6.     R2 will send the nhrp reply directly to R1(nhrp request packet will have the nbma address of R1).

7.     R1 will install a route in its routing table for the prefix 23.1.1.0/24 via 22.1.1.1 with an AD of 250

In phase3,a new route is installed in the routing table that tells the spoke how to reach the remote spoke.

We can do summarization and use default routes at the hub.

Configuration:

On the hub,

R5(config-if)#int tun0

R5(config-if)#ip nhrp redirect

On the spokes,

R4(config-if)#int tun0

R4(config-if)#ip nhrp shortcutàmake sure tunnel mode is gre multipoint

OSPF:

In phase2, ospf network type point-to-multipoint is nor supported as the hub will not preserve the next-hop and will always set itself as the next-hop.

In phase3, we can use point-to-multipoint network type as the hub can send a redirect message for other spokes traffic.