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
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
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,
Here
are the steps,
- 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.
- The
request from R2 will also have the NBMA address of R2. The hub relays the
request to R3.
- R3
receives the request, adds its own address mapping to it and sends it as
an NHRP reply directly to R2.
- R3
then sends its own request to the hub that relays it to R2.
- 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
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.
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.
No comments:
Post a Comment