Wednesday, December 31, 2014

DMVPN - phase three - EIGRP

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) :

dmvpn-3-1.jpg

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.

No comments:

Post a Comment