Today I’m going to test a phase 3 with EIGRP. To present all
differences, pros, cons I have changed LAN’s IP addresses ( I strongly
recommend to read my previous posts about different variances of DMVPN) :
Before I start configuring the phase 3 I would like to show some limitations of the phase 2. As you know for phase 2 we can’t summarize what means every spoke needs to keep all spoke routers in its routing table to be able to establish spoke-to-spoke communication.
Let’s test it on my example:
R1:
R2:
R3:
This is an example of phase 2 where R2 can communicate directly with R3:
but the mandatory requirement is presence of a destination IP in the routing table:
Let’s imagine now the routing table in a huge network with thousand of spoke routers. If we have middle or high models as a spoke, it shouldn’t be a problem, but in real word, in most branches, you can find low models and for them managing so big routing table can be the problem.
When I try to summarize the LANs subnet on R1:
I can see following entries in R2 routing table:
Now I received only summary route: 100.0.0.0/8 but I can’t establish direct connection with R3:
so, it works as the phase 1.
Now I change the configuration that enables the phase 3 and then I check if I can summary LAN’s subnets.
R1:
R2 and R3:
Let’s initiate test traffic from R2 to R3 LAN:
As you see the phase 3 works fine. I check now routing, cef and nhrp tables:
As you see above, once I generate some traffic, I can see dynamic (temporary) tunnels.
By the routing and cef tables the traffic to 100.22.22.22 should be sent via the hub (10.10.10.1). Only the NHRP table tells you how the traffic will be sent:
Now I summarize 10.0.0.0/8 subnet on R1 and then I test spoke-to-spoke communication:
As you see above R2 learned only 100.0.0.0/8 subnet without specific subnets like I tested earlier.
Above output shows I can send traffic to r3 using spoke-to-spoke communication. The main pros of the phase 3 is the ability of using ‘auto-summary’ for eigrp and communication with R2 directly, what was impossible with the phase 2.
Before I start configuring the phase 3 I would like to show some limitations of the phase 2. As you know for phase 2 we can’t summarize what means every spoke needs to keep all spoke routers in its routing table to be able to establish spoke-to-spoke communication.
Let’s test it on my example:
R1:
!
interface Loopback0
ip address 100.11.11.11 255.255.255.0
!
router eigrp 1
network 10.10.10.0 0.0.0.255
network 100.11.11.0 0.0.0.255
no auto-summary
!R2:
!
interface Loopback0
ip address 100.22.22.22 255.255.255.0
!
router eigrp 1
network 10.10.10.0 0.0.0.255
network 100.22.22.0 0.0.0.255
no auto-summary
!R3:
!
interface Loopback0
ip address 100.33.33.33 255.255.255.0
!
router eigrp 1
network 10.10.10.0 0.0.0.255
network 100.33.33.0 0.0.0.255
no auto-summary
!This is an example of phase 2 where R2 can communicate directly with R3:
R2#traceroute 100.33.33.33 source 100.22.22.22
Type escape sequence to abort.
Tracing the route to 100.33.33.33
1 10.10.10.3 72 msec 72 msec 24 msec
R2#but the mandatory requirement is presence of a destination IP in the routing table:
R2#sh ip route eigrp
100.0.0.0/24 is subnetted, 3 subnets
D 100.33.33.0 [90/310172416] via 10.10.10.3, 00:17:08, Tunnel0
D 100.11.11.0 [90/297372416] via 10.10.10.1, 00:17:08, Tunnel0
R2#Let’s imagine now the routing table in a huge network with thousand of spoke routers. If we have middle or high models as a spoke, it shouldn’t be a problem, but in real word, in most branches, you can find low models and for them managing so big routing table can be the problem.
When I try to summarize the LANs subnet on R1:
R1#sh run | s router
router eigrp 1
network 10.10.10.0 0.0.0.255
network 100.11.11.0 0.0.0.255
auto-summary
R1#I can see following entries in R2 routing table:
R2#sh ip route 100.0.0.0
Routing entry for 100.0.0.0/8, 2 known subnets
Attached (1 connections)
Variably subnetted with 2 masks
Redistributing via eigrp 1
C 100.22.22.0/24 is directly connected, Loopback0
D 100.0.0.0/8 [90/297372416] via 10.10.10.1, 00:01:25, Tunnel0
R2#Now I received only summary route: 100.0.0.0/8 but I can’t establish direct connection with R3:
R2#traceroute 100.33.33.33 source 100.22.22.22
Type escape sequence to abort.
Tracing the route to 100.33.33.33
1 10.10.10.1 72 msec 36 msec 32 msec
2 10.10.10.3 108 msec 76 msec 108 msec
R2# R2#traceroute 100.33.33.33 source 100.22.22.22
Type escape sequence to abort.
Tracing the route to 100.33.33.33
1 10.10.10.1 68 msec 48 msec 44 msec
2 10.10.10.3 88 msec 92 msec 100 msec
R2#so, it works as the phase 1.
Now I change the configuration that enables the phase 3 and then I check if I can summary LAN’s subnets.
R1:
!
interface Tunnel0
ip nhrp redirect
no ip split-horizon eigrp 1
ip next-hop-self eigrp 1
!
router eigrp 1
network 10.10.10.0 0.0.0.255
network 100.11.11.0 0.0.0.255
no auto-summary
!R2 and R3:
!
interface Tunnel0
ip nhrp shortcut
!Let’s initiate test traffic from R2 to R3 LAN:
R2#traceroute 100.33.33.33 source 100.22.22.22
Type escape sequence to abort.
Tracing the route to 100.33.33.33
1 10.10.10.1 40 msec 56 msec 76 msec
2 10.10.10.3 104 msec 88 msec 140 msec
R2# R2#traceroute 100.33.33.33 source 100.22.22.22
Type escape sequence to abort.
Tracing the route to 100.33.33.33
1 10.10.10.3 104 msec 104 msec 72 msec
R2#As you see the phase 3 works fine. I check now routing, cef and nhrp tables:
R2#sh ip route 100.0.0.0
Routing entry for 100.0.0.0/24, 3 known subnets
Attached (1 connections)
Redistributing via eigrp 1
D 100.33.33.0 [90/310172416] via 10.10.10.1, 00:07:04, Tunnel0
C 100.22.22.0 is directly connected, Loopback0
D 100.11.11.0 [90/297372416] via 10.10.10.1, 00:07:05, Tunnel0
R2# R2#sh ip cef 100.33.33.33
100.33.33.0/24, version 32, epoch 0
0 packets, 0 bytes
via 10.10.10.1, Tunnel0, 0 dependencies
next hop 10.10.10.1, Tunnel0
valid adjacency
R2# R2#sh ip nhrp
10.10.10.1/32 via 10.10.10.1, Tunnel0 created 01:33:37, never expire
Type: static, Flags: nat used
NBMA address: 5.5.5.1
10.10.10.2/32 via 10.10.10.2, Tunnel0 created 00:31:41, expire 01:28:18
Type: dynamic, Flags: router unique nat local
NBMA address: 6.6.6.1
(no-socket)
10.10.10.3/32 via 10.10.10.3, Tunnel0 created 00:31:41, expire 01:28:18
Type: dynamic, Flags: router nat implicit
NBMA address: 7.7.7.1
100.33.33.0/24 via 10.10.10.3, Tunnel0 created 00:03:24, expire 01:56:35
Type: dynamic, Flags: router nat
NBMA address: 7.7.7.1
R2#As you see above, once I generate some traffic, I can see dynamic (temporary) tunnels.
By the routing and cef tables the traffic to 100.22.22.22 should be sent via the hub (10.10.10.1). Only the NHRP table tells you how the traffic will be sent:
R2#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
Tunnel0, Type:Spoke, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 5.5.5.1 10.10.10.1 UP 01:32:01 S
2 7.7.7.1 10.10.10.3 UP 00:32:44 D
R2#Now I summarize 10.0.0.0/8 subnet on R1 and then I test spoke-to-spoke communication:
R1#sh run | s router
router eigrp 1
network 10.10.10.0 0.0.0.255
network 100.11.11.0 0.0.0.255
auto-summary
R1# R2#sh ip route 100.0.0.0
Routing entry for 100.0.0.0/8, 2 known subnets
Attached (1 connections)
Variably subnetted with 2 masks
Redistributing via eigrp 1
C 100.22.22.0/24 is directly connected, Loopback0
D 100.0.0.0/8 [90/297372416] via 10.10.10.1, 00:00:37, Tunnel0
R2#As you see above R2 learned only 100.0.0.0/8 subnet without specific subnets like I tested earlier.
R2#traceroute 100.33.33.33 source 100.22.22.22
Type escape sequence to abort.
Tracing the route to 100.33.33.33
1 10.10.10.3 96 msec 60 msec 128 msec
R2#Above output shows I can send traffic to r3 using spoke-to-spoke communication. The main pros of the phase 3 is the ability of using ‘auto-summary’ for eigrp and communication with R2 directly, what was impossible with the phase 2.
Comments
Post a Comment