EIGRP
Showing posts with label EIGRP. Show all posts
Showing posts with label EIGRP. Show all posts
The BIG lab - Part 6 - Route Redistribution (2.90)

The BIG lab - Part 6 - Route Redistribution (2.90)

06:02:00 Add Comment
We have now reached part 6 of this series, we have OSPF, RIP and EIGRP working in our network, but at the moment these networks are all self-contained and have visibility only within their own routing processes. So lets do some redistribution between them and get all of our networks talking to each other and have some end-to-end visibilty.

 We will redistribute OSPF into RIP and EIGRP into RIP, and hopefully at the end of this post we should have working routes all the way from R1 (OSPF) through our RIP routers all the way over to R10 (EIGRP).

 So what is redistribution? Well, hopefully you have already covered this in the CCNP, but if not (and hopefully this series has been a good start for those doing the CCNA, CCNP or CCIE), then we'll briefly cover the basics of redistribution before we put this into our topology.

Route Redistribution

In small scale networks it's often the case that one routing protocol is used, as the networks grow, and expand there may be the need (such as migrating from one routing protocol to another) that different IGPs are used. Route redistribution allows for routes from one routing protocol to be advertised into another. These redistributed routes will be learned as external routes, and as such usually have a higher (therefore less preferred) metric to the local routes.

 For redistribution to work we need a router to run both routing protocols, having one interface in each of the different routing domains.

 In our topology R4 will handle redistribution between OSPF and RIP, and both R4 and R5 will handle redistribution between RIP and EIGRP. It is the redistribution between RIP and EIGRP that will cause us some potential issues, and to understand why we need to have a quick look at Administrative Distances.

Administrative Distances

The default Administrative Distances (AD) are as follows, and the ones we need to concern ourselves with are bolded:
Routing Protocol Administrative Distance
Connected interface 0
Static route 1
EIGRP Summary route 5
External BGP 20
Internal EIGRP 90
IGRP 100
OSPF 110
IS-IS 115
RIP 120
EGP 140
ODR 160
External EIGRP 170
Internal BGP 200
Because OSPF into RIP only has one redistribution point (R4) then we will be OK, but because EIGRP into RIP has two redistribution points (R4 and R5) we will have EIGRP summary routes (that we set up in the previous lab) with an AD of 5, Internal EIGRP (on R4 and R5) with an AD of 90 being redistributed into RIP (AD of 120), and it is these internal EIGRP routes that might cause us an issue, as lower AD is preferred. In short we have the potential for a routing loop. If we do encounter any issues then we can look at distribution-lists or route-tagging to overcome any issues. I have covered routing loops before, so this will be a good refresher. Like they say though the proof is in the pudding, so let's get on and get started.

Redistributing RIP into EIGRP

EIGRP uses bandwidth and delay as its main metrics, but will also use reliability, load and MTU.

 We start by entering the EIGRP process on R5
R5(config)#router eigrp 10
R5(config-router)#redistribute rip ?
     metric     Metric for redistributed routes
     route-map  Route map reference
R5(config-router)#redistribute rip metric ?
     <1-4294967295>  Bandwidth metric in Kbits per second
The first metric we need to set is the bandwidth, so lets set this as 10000. The next next metric is delay, which we will set at 1000
R5(config-router)#redistribute rip metric 10000 ?
      <0-4294967295>  EIGRP delay metric, in 10 microsecond units
Thankfully IOS is very helpful and gives us a good idea for how we should set our metrics. So for the next metric, which is reliability we know that 255 is the most reliable 
R5(config-router)#redistribute rip metric 10000 1000 ?
     <0-255>  EIGRP reliability metric where 255 is 100% reliable
And for load we should set it at the lowest possible (1) 
R5(config-router)#redistribute rip metric 10000 1000 255 ?
     <1-255>  EIGRP Effective bandwidth metric (Loading) where 255 is 100% loaded
Lastly we can set the MTU at 1500. 
R5(config-router)#redistribute rip metric 10000 1000 255 1 ?
     <1-65535>  EIGRP MTU of the path
And thats it the full command would be: 
R5(config-router)#redistribute rip metric 10000 1000 255 1 1500
We do the same on R4: 
R4(config)#router eigrp 10
R4(config-router)#redistribute rip metric 10000 1000 255 1 1500
R4(config-router)#exit
R4(config)#exit

Redistributing EIGRP into RIP

Not much has, so far, changed within our routing tables on R4 or R5, which is not overly surprising. So let's redistribute EIGRP into RIP. The commands to use are: 
R5(config)#router rip
R5(config-router)#redistribute eigrp 10 metric 2
R5(config-router)#exit
R5(config)#exit
And this is identical for R4 The command specifies that we are redistributing eigrp AS 10 into RIP and setting the metric (and RIP only uses hop count for its calculations) at 2. If a metric is not supplied RIP will assume a metric of 0 and will not advertise the redistributed routes.

Confirming mutual redistribution between RIP and EIGRP

R6 is a good router to look at to check for our redistributed EIGRP routes. Without any redistribution the routing table for R6 looks like this:

R6#sh ip route | beg Gate
Gateway of last resort is not set       
   10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
R        10.20.1.0/24 [120/1] via 10.20.2.1, 00:00:00, Serial0/0
C        10.20.2.0/24 is directly connected, Serial0/0
L        10.20.2.2/32 is directly connected, Serial0/0
R        10.35.1.0/24 [120/1] via 10.20.2.1, 00:00:00, Serial0/0

 (Note that R7 is currently turned off...)

After redistributing RIP into EIGRP, and EIGRP into RIP, the routing table on R6 looks like this:

 R6#sh ip route | beg Gate
Gateway of last resort is not set       
   10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
R        10.20.1.0/24 [120/1] via 10.20.2.1, 00:00:00, Serial0/0
C        10.20.2.0/24 is directly connected, Serial0/0
L        10.20.2.2/32 is directly connected, Serial0/0
R        10.25.1.0/24 [120/2] via 10.20.2.1, 00:00:00, Serial0/0
R        10.30.1.0/24 [120/2] via 10.20.2.1, 00:00:00, Serial0/0
R        10.31.1.0/24 [120/2] via 10.20.2.1, 00:00:00, Serial0/0
R        10.35.1.0/24 [120/1] via 10.20.2.1, 00:00:00, Serial0/0      
   172.20.0.0/16 is variably subnetted, 3 subnets, 2 masks
R        172.20.20.0/24 [120/2] via 10.20.2.1, 00:00:00, Serial0/0
R        172.20.30.0/24 [120/2] via 10.20.2.1, 00:00:00, Serial0/0
R        172.20.40.0/23 [120/2] via 10.20.2.1, 00:00:00, Serial0/0

So we can see that R6 which is just running RIP, now knows of the EIGRP network, and has learned the EIGRP routes through our redistribution, and they have an AD of 120, and a hop count of 2. We can also look at R10 to see the effects of redistribution. 

 Before we started to redistribute the routing table of R10 looked like this:

R10#sh ip route | beg Gate
Gateway of last resort is not set       
   10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D        10.20.1.0/24 [90/3193856] via 10.31.1.1, 00:02:23, Serial1/0
D        10.20.2.0/24 [90/3705856] via 10.31.1.1, 00:02:23, Serial1/0
D        10.25.1.0/24 [90/2681856] via 10.31.1.1, 00:02:23, Serial1/0
D        10.30.1.0/24 [90/2681856] via 10.31.1.1, 00:02:23, Serial1/0
C        10.31.1.0/24 is directly connected, Serial1/0
L        10.31.1.2/32 is directly connected, Serial1/0
D        10.35.1.0/24 [90/41536000] via 10.31.1.1, 00:02:23, Serial1/0       
   172.20.0.0/16 is variably subnetted, 9 subnets, 3 masks
C        172.20.20.0/24 is directly connected, Loopback0
L        172.20.20.1/32 is directly connected, Loopback0
C        172.20.30.0/24 is directly connected, Loopback1
L        172.20.30.1/32 is directly connected, Loopback1
D        172.20.40.0/23 is a summary, 00:02:25, Null0
C        172.20.40.0/24 is directly connected, Loopback2
L        172.20.40.1/32 is directly connected, Loopback2
C        172.20.41.0/24 is directly connected, Loopback3
L        172.20.41.1/32 is directly connected, Loopback3

And once we turn on R7 it now looks like this:

R10#sh ip route | beg Gate
Gateway of last resort is not set       
   10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
D        10.20.1.0/24 [90/3193856] via 10.31.1.1, 00:19:27, Serial1/0
D        10.20.2.0/24 [90/3705856] via 10.31.1.1, 00:19:27, Serial1/0
D EX     10.20.3.0/24 [170/2937856] via 10.31.1.1, 00:06:31, Serial1/0
D        10.25.1.0/24 [90/2681856] via 10.31.1.1, 00:19:27, Serial1/0
D        10.30.1.0/24 [90/2681856] via 10.31.1.1, 00:19:27, Serial1/0
C        10.31.1.0/24 is directly connected, Serial1/0
L        10.31.1.2/32 is directly connected, Serial1/0
D        10.35.1.0/24 [90/41536000] via 10.31.1.1, 00:19:27, Serial1/0
D EX     10.60.1.0/24 [170/2937856] via 10.31.1.1, 00:06:12, Serial1/0       
   172.20.0.0/16 is variably subnetted, 9 subnets, 3 masks
C        172.20.20.0/24 is directly connected, Loopback0
L        172.20.20.1/32 is directly connected, Loopback0
C        172.20.30.0/24 is directly connected, Loopback1
L        172.20.30.1/32 is directly connected, Loopback1
D        172.20.40.0/23 is a summary, 00:19:44, Null0
C        172.20.40.0/24 is directly connected, Loopback2
L        172.20.40.1/32 is directly connected, Loopback2
C        172.20.41.0/24 is directly connected, Loopback3
L        172.20.41.1/32 is directly connected, Loopback3
We can see that R7 has the following IP addresses assigned to it:
R7#sh ip int bri
Interface          IP-Address  OK? Method  Status                           Protocol
Serial0/0         unassigned YES TFTP      administratively down down
Serial0/1         10.20.3.2     YES TFTP      up                                 up
Serial0/2         unassigned YES TFTP      administratively down down
Serial0/3         unassigned YES TFTP      administratively down down
Loopback0     10.60.1.1     YES TFTP      up                                 up

 So R10 now knows of both the 10.20.3.0/24 network and the 10.60.1.0/24 network, and that they are being advertised as an EIGRP External (D EX) with an AD of 170. We can confirm reachability as well:

 R10#ping 10.60.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.60.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/44/48 ms
R10#

Mutual redistribution of RIP and OSPF

Lets start by redistributing RIP into OSPF
R2's current routing table looks like this (with R12, R13 and R14 turned off - due to not wanting to completely drain my laptop resources):

R2#sh ip route | beg Gate
Gateway of last resort is not set
      1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        1.2.3.0/24 is directly connected, Multilink1
L        1.2.3.5/32 is directly connected, Multilink1
      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C        10.1.1.0/24 is directly connected, Serial0/2
L        10.1.1.1/32 is directly connected, Serial0/2
O IA     10.1.2.0/24 [110/128] via 10.1.1.2, 00:04:00, Serial0/2
C        10.1.6.0/24 is directly connected, Serial0/3
L        10.1.6.1/32 is directly connected, Serial0/3
O IA     10.10.1.0/24 [110/33] via 1.2.3.4, 00:04:00, Multilink1

 We can see that we have some OSPF Inter-Area routes (denoted by O IA).

 Once R4 is added to the OSPF domain via it's s0/0 interface in area 3, the routing table looks like this:

 R4#sh ip route | beg Gate
Gateway of last resort is not set
      1.0.0.0/24 is subnetted, 1 subnets
O IA     1.2.3.0 [110/96] via 10.1.6.1, 00:01:41, Serial0/0
      10.0.0.0/8 is variably subnetted, 15 subnets, 2 masks
O IA     10.1.1.0/24 [110/128] via 10.1.6.1, 00:01:41, Serial0/0
O IA     10.1.2.0/24 [110/192] via 10.1.6.1, 00:01:41, Serial0/0
C        10.1.6.0/24 is directly connected, Serial0/0
L        10.1.6.2/32 is directly connected, Serial0/0
O IA     10.10.1.0/24 [110/97] via 10.1.6.1, 00:01:41, Serial0/0
C        10.20.1.0/24 is directly connected, Serial0/1
L        10.20.1.1/32 is directly connected, Serial0/1
D        10.20.2.0/24 [90/2681856] via 10.20.1.2, 00:02:09, Serial0/1
R        10.20.3.0/24 [120/2] via 10.20.1.2, 00:00:06, Serial0/1
C        10.25.1.0/24 is directly connected, Serial0/2
L        10.25.1.1/32 is directly connected, Serial0/2
D        10.30.1.0/24 [90/2681856] via 10.25.1.2, 00:02:13, Serial0/2
D        10.31.1.0/24 [90/2681856] via 10.25.1.2, 00:02:13, Serial0/2
D        10.35.1.0/24 [90/41024000] via 10.20.1.2, 00:02:13, Serial0/1
R        10.60.1.0/24 [120/3] via 10.20.1.2, 00:00:10, Serial0/1
      172.20.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.20.20.0/24 [90/2809856] via 10.25.1.2, 00:02:13, Serial0/2
D        172.20.30.0/24 [90/2809856] via 10.25.1.2, 00:02:13, Serial0/2
D        172.20.40.0/23 [90/2809856] via 10.25.1.2, 00:02:13, Serial0/2
R4(config)#router rip
R4(config-router)#redistribute ospf 1 metric 2
R6's routing table now looks like this:

 R6#sh ip route | beg Gate
Gateway of last resort is not set
      1.0.0.0/24 is subnetted, 1 subnets
R        1.2.3.0 [120/3] via 10.20.2.1, 00:00:28, Serial0/0
      10.0.0.0/8 is variably subnetted, 14 subnets, 2 masks
R        10.1.1.0/24 [120/3] via 10.20.2.1, 00:00:28, Serial0/0
R        10.1.2.0/24 [120/3] via 10.20.2.1, 00:00:28, Serial0/0
R        10.1.6.0/24 [120/2] via 10.20.2.1, 00:00:28, Serial0/0
R        10.10.1.0/24 [120/3] via 10.20.2.1, 00:00:28, Serial0/0
R        10.20.1.0/24 [120/1] via 10.20.2.1, 00:00:28, Serial0/0
C        10.20.2.0/24 is directly connected, Serial0/0
L        10.20.2.2/32 is directly connected, Serial0/0
C        10.20.3.0/24 is directly connected, Serial0/1
L        10.20.3.1/32 is directly connected, Serial0/1
R        10.25.1.0/24 [120/2] via 10.20.2.1, 00:00:28, Serial0/0
R        10.30.1.0/24 [120/2] via 10.20.2.1, 00:00:28, Serial0/0
R        10.31.1.0/24 [120/2] via 10.20.2.1, 00:00:28, Serial0/0
R        10.35.1.0/24 [120/1] via 10.20.2.1, 00:00:28, Serial0/0
R        10.60.1.0/24 [120/1] via 10.20.3.2, 00:00:05, Serial0/1
      172.20.0.0/16 is variably subnetted, 3 subnets, 2 masks
R        172.20.20.0/24 [120/2] via 10.20.2.1, 00:00:28, Serial0/0
R        172.20.30.0/24 [120/2] via 10.20.2.1, 00:00:28, Serial0/0
R        172.20.40.0/23 [120/2] via 10.20.2.1, 00:00:28, Serial0/0

 And R10's looks like this:

 R10#sh ip route | beg Gate
Gateway of last resort is not set
      1.0.0.0/24 is subnetted, 1 subnets
D EX     1.2.3.0 [170/41792000] via 10.31.1.1, 00:01:58, Serial1/0
      10.0.0.0/8 is variably subnetted, 13 subnets, 2 masks
D EX     10.1.1.0/24 [170/41792000] via 10.31.1.1, 00:01:58, Serial1/0
D EX     10.1.2.0/24 [170/41792000] via 10.31.1.1, 00:01:58, Serial1/0
D        10.1.6.0/24 [90/3193856] via 10.31.1.1, 00:05:50, Serial1/0
D EX     10.10.1.0/24 [170/41792000] via 10.31.1.1, 00:01:58, Serial1/0
D        10.20.1.0/24 [90/3193856] via 10.31.1.1, 00:40:20, Serial1/0
D        10.20.2.0/24 [90/3705856] via 10.31.1.1, 00:40:20, Serial1/0
D EX     10.20.3.0/24 [170/2937856] via 10.31.1.1, 00:27:24, Serial1/0
D        10.25.1.0/24 [90/2681856] via 10.31.1.1, 00:40:20, Serial1/0
D        10.30.1.0/24 [90/2681856] via 10.31.1.1, 00:40:20, Serial1/0
C        10.31.1.0/24 is directly connected, Serial1/0
L        10.31.1.2/32 is directly connected, Serial1/0
D        10.35.1.0/24 [90/41536000] via 10.31.1.1, 00:40:20, Serial1/0
D EX     10.60.1.0/24 [170/2937856] via 10.31.1.1, 00:27:05, Serial1/0
      172.20.0.0/16 is variably subnetted, 9 subnets, 3 masks
C        172.20.20.0/24 is directly connected, Loopback0
L        172.20.20.1/32 is directly connected, Loopback0
C        172.20.30.0/24 is directly connected, Loopback1
L        172.20.30.1/32 is directly connected, Loopback1

So R6 has learnt of the routes through RIP, and R10 has learnt of the OSPF routes via EIGRP.

 Now lets send our RIP routes (and hopefully all of the redistributed EIGRP routes) into OSPF.

 Before redistribution R1's routing table looks like this:

 R1#sh ip route | beg Gate
Gateway of last resort is not set
      1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        1.2.3.0/24 is directly connected, Multilink1
L        1.2.3.4/32 is directly connected, Multilink1
      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O        10.1.1.0/24 [110/96] via 1.2.3.5, 00:00:51, Multilink1
O IA     10.1.2.0/24 [110/160] via 1.2.3.5, 00:00:47, Multilink1
C        10.10.1.0/24 is directly connected, Loopback0
L        10.10.1.1/32 is directly connected, Loopback0
R4(config)#router ospf 1
R4(config-router)#redistribute rip subnets metric 2000
R1#sh ip route | beg Gate
Gateway of last resort is not set
      1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        1.2.3.0/24 is directly connected, Multilink1
L        1.2.3.4/32 is directly connected, Multilink1
      10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
O        10.1.1.0/24 [110/96] via 1.2.3.5, 00:23:34, Multilink1
O IA     10.1.2.0/24 [110/160] via 1.2.3.5, 00:23:30, Multilink1
O IA     10.1.6.0/24 [110/96] via 1.2.3.5, 00:15:30, Multilink1
C        10.10.1.0/24 is directly connected, Loopback0
L        10.10.1.1/32 is directly connected, Loopback0
O E2     10.20.1.0/24 [110/20] via 1.2.3.5, 00:00:45, Multilink1
O E2     10.20.3.0/24 [110/20] via 1.2.3.5, 00:00:45, Multilink1
O E2     10.25.1.0/24 [110/20] via 1.2.3.5, 00:00:45, Multilink1
O E2     10.60.1.0/24 [110/20] via 1.2.3.5, 00:00:45, Multilink1

 And now we can see that R1 has learnt of the RIP routes as OSFP External Type 2, but not the EIGRP, so lets just do the last couple of redistribution commands:
R4(config)#router eigrp 10
R4(config-router)#redistribute ospf 1 metric 10000 1000 255 1 1500
R4(config-router)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric 2222
R4(config-router)#exit
R4(config)#exit
And now we can see, using R1, R7 and R10 (as these are on the periphery of our network) that we have full reachability:

R1#sh ip route | beg Gate
Gateway of last resort is not set
      1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        1.2.3.0/24 is directly connected, Multilink1
L        1.2.3.4/32 is directly connected, Multilink1
      10.0.0.0/8 is variably subnetted, 13 subnets, 2 masks
O        10.1.1.0/24 [110/96] via 1.2.3.5, 00:43:07, Multilink1
O IA     10.1.2.0/24 [110/160] via 1.2.3.5, 00:43:03, Multilink1
O IA     10.1.6.0/24 [110/96] via 1.2.3.5, 00:35:03, Multilink1
C        10.10.1.0/24 is directly connected, Loopback0
L        10.10.1.1/32 is directly connected, Loopback0
O E2     10.20.1.0/24 [110/2222] via 1.2.3.5, 00:05:06, Multilink1
O E2     10.20.2.0/24 [110/2222] via 1.2.3.5, 00:05:06, Multilink1
O E2     10.20.3.0/24 [110/2000] via 1.2.3.5, 00:17:35, Multilink1
O E2     10.25.1.0/24 [110/2222] via 1.2.3.5, 00:05:06, Multilink1
O E2     10.30.1.0/24 [110/2222] via 1.2.3.5, 00:05:06, Multilink1
O E2     10.31.1.0/24 [110/2222] via 1.2.3.5, 00:05:06, Multilink1
O E2     10.35.1.0/24 [110/2222] via 1.2.3.5, 00:05:06, Multilink1
O E2     10.60.1.0/24 [110/2000] via 1.2.3.5, 00:17:35, Multilink1
      172.20.0.0/16 is variably subnetted, 3 subnets, 2 masks
O E2     172.20.20.0/24 [110/2222] via 1.2.3.5, 00:05:06, Multilink1
O E2     172.20.30.0/24 [110/2222] via 1.2.3.5, 00:05:06, Multilink1
O E2     172.20.40.0/23 [110/2222] via 1.2.3.5, 00:05:06, Multilink1

 R7#sh ip route | beg Gateway
Gateway of last resort is not set
      1.0.0.0/24 is subnetted, 1 subnets
R        1.2.3.0 [120/4] via 10.20.3.1, 00:00:28, Serial0/1
      10.0.0.0/8 is variably subnetted, 14 subnets, 2 masks
R        10.1.1.0/24 [120/4] via 10.20.3.1, 00:00:28, Serial0/1
R        10.1.2.0/24 [120/4] via 10.20.3.1, 00:00:28, Serial0/1
R        10.1.6.0/24 [120/3] via 10.20.3.1, 00:00:28, Serial0/1
R        10.10.1.0/24 [120/4] via 10.20.3.1, 00:00:28, Serial0/1
R        10.20.1.0/24 [120/2] via 10.20.3.1, 00:00:28, Serial0/1
R        10.20.2.0/24 [120/1] via 10.20.3.1, 00:00:28, Serial0/1
C        10.20.3.0/24 is directly connected, Serial0/1
L        10.20.3.2/32 is directly connected, Serial0/1
R        10.25.1.0/24 [120/3] via 10.20.3.1, 00:00:28, Serial0/1
R        10.30.1.0/24 [120/3] via 10.20.3.1, 00:00:28, Serial0/1
R        10.31.1.0/24 [120/3] via 10.20.3.1, 00:00:28, Serial0/1
R        10.35.1.0/24 [120/2] via 10.20.3.1, 00:00:28, Serial0/1
C        10.60.1.0/24 is directly connected, Loopback0
L        10.60.1.1/32 is directly connected, Loopback0
      172.20.0.0/16 is variably subnetted, 3 subnets, 2 masks
R        172.20.20.0/24 [120/3] via 10.20.3.1, 00:00:28, Serial0/1
R        172.20.30.0/24 [120/3] via 10.20.3.1, 00:00:28, Serial0/1
R        172.20.40.0/23 [120/3] via 10.20.3.1, 00:00:28, Serial0/1

 R10#sh ip route | beg Gate
Gateway of last resort is not set
      1.0.0.0/24 is subnetted, 1 subnets
D EX     1.2.3.0 [170/2937856] via 10.31.1.1, 00:07:16, Serial1/0
      10.0.0.0/8 is variably subnetted, 13 subnets, 2 masks
D EX     10.1.1.0/24 [170/2937856] via 10.31.1.1, 00:07:16, Serial1/0
D EX     10.1.2.0/24 [170/2937856] via 10.31.1.1, 00:07:16, Serial1/0
D        10.1.6.0/24 [90/3193856] via 10.31.1.1, 00:32:34, Serial1/0
D EX     10.10.1.0/24 [170/2937856] via 10.31.1.1, 00:07:16, Serial1/0
D        10.20.1.0/24 [90/3193856] via 10.31.1.1, 01:07:04, Serial1/0
D        10.20.2.0/24 [90/3705856] via 10.31.1.1, 01:07:04, Serial1/0
D EX     10.20.3.0/24 [170/2937856] via 10.31.1.1, 00:54:08, Serial1/0
D        10.25.1.0/24 [90/2681856] via 10.31.1.1, 01:07:04, Serial1/0
D        10.30.1.0/24 [90/2681856] via 10.31.1.1, 01:07:04, Serial1/0
C        10.31.1.0/24 is directly connected, Serial1/0
L        10.31.1.2/32 is directly connected, Serial1/0
D        10.35.1.0/24 [90/41536000] via 10.31.1.1, 01:07:04, Serial1/0
D EX     10.60.1.0/24 [170/2937856] via 10.31.1.1, 00:53:49, Serial1/0
      172.20.0.0/16 is variably subnetted, 9 subnets, 3 masks
C        172.20.20.0/24 is directly connected, Loopback0
L        172.20.20.1/32 is directly connected, Loopback0
C        172.20.30.0/24 is directly connected, Loopback1
L        172.20.30.1/32 is directly connected, Loopback1
D        172.20.40.0/23 is a summary, 01:07:08, Null0
C        172.20.40.0/24 is directly connected, Loopback2
L        172.20.40.1/32 is directly connected, Loopback2
C        172.20.41.0/24 is directly connected, Loopback3
L        172.20.41.1/32 is directly connected, Loopback3

 We have avoided routing loops in this scenario, but if the topology was the other way around, with EIGRP on the left hand side, and OSPF on the other, we would have had a routing loop on R4 and R5 into the OSPF domain. Thankfully this was not the case.

Now we can move on to Part 7 and set up a tunnel.

The BIG lab - Part 5 - EIGRP

02:24:00 Add Comment
So far in this extended series we have set up some trunking and etherchannel in part 1, PPP in part 2, OSPF in part 3, and RIPv2 in part 4. In this part we will cover EIGRP, before we can then move on to redistributing our routing protocols into each other.

To remind ourselves of the topology here is the layout:

We will be using the following IP addressing schemes:

R4 - s0/2 - 10.25.1.1/24
R5 - s0/2 - 10.35.1.1/24
R8 - s0/0 - 10.25.1.2/24, s0/1 - 10.30.1.1/24. s0/2 - 10.31.1.1/24
R9 - s0/0 - 10.35.1.2/24, s0/1 - 10.30.1.2/24
R10 - s1/0 - 10.31.1.2/24

The exam guide lists the following as things we need to know for EIGRP:

2.50 Implement IPv4 Enhanced Interior Gateway Routing Protocol (EIGRP) 
   (a) Best path 
   (b) Loop-free paths 
   (c) EIGRP operations when alternate loop-free paths are available, and when they are not
   (d) EIGRP queries 
   (e) Manual summarization and autosummarization 
   (f) EIGRP stubs 

So what can we do with our EIGRP network to fulfil the requirements? We can set up an EIGRP stub on R10, using some loopbacks we can do some summarization, and tune our path selection between R5 and its connections between R4 and R9. So hopefully we can tick most of the boxes. First let's get a brief overview of EIGRP. C and D would be best left (due to the length of discussion) for reading outside of this post, grab a copy of the Odom book for these.

A (very) brief overview of EIGRP

EIGRP is Cisco proprietary, its a hybrid routing protocol with features from both distance-vector and link-state protocols. EIGRP uses the DUAL (Diffusing Update Algorithm) to determine the best path to use, and to ensure a loop-free network. 

Like BGP, EIGRP will form neighbor relationships with adjacent routers in the same AS (Autonomous System). Traffic uses the IP address 224.0.0.10 via either multicast or unicast. Updates are only sent when a change occurs.

EIGRP supports VLSM, has an administrative distance of 90 for local routes, and 170 for routes that have originated outside of the local AS. Metrics used by EIGRP are bandwidth and delay, but can also factor in reliability, load and MTU.

 I am not going to explain everything about EIGRP, as this would make for a very long post, there are a number of very good books on the subject and I would again refer you to the CCIE Routing and Switching guide by Wendell Odom for a complete explanation. Before we jump into the configuration I will briefly explain what the FD is though. The FD is the Feasible Distance, and this is the route with the lowest metric (therefore preferred) to each network, when it is added to the routing table it is known as the Successor. An alternate route is the Feasible Successor (FS)

Basic EIGRP configuration

According to our topology and IP addressing above the routers have been set up as follows:

 R4 configuration
We start by assigning the IP address to the interface.
interface Serial0/2
 ip address 10.25.1.1 255.255.255.0
We then create the EIGRP process with an AS of 10.
R4(config)#router eigrp 10
R4(config-router)#no auto-summary
R4(config-router)#network 10.25.1.0 0.255.255.255
The end result looks like this: 
interface Serial0/2
 ip address 10.25.1.1 255.255.255.0
!
router eigrp 10
 network 10.0.0.0
 no auto-summary
The other routers are configured similarly to R4
R5 configuration
interface Serial0/0
 ip address 10.20.1.2 255.255.255.0
 serial restart-delay 0
!
interface Serial0/1
 ip address 10.20.2.1 255.255.255.0
 serial restart-delay 0
!
interface Serial0/2
 ip address 10.35.1.1 255.255.255.0
 serial restart-delay 0
!
interface Serial0/3
 no ip address
 shutdown
 serial restart-delay 0
!
!
router eigrp 10
 network 10.0.0.0
 no auto-summary
R8 configuration
interface Serial0/0
 ip address 10.25.1.2 255.255.255.0
!
interface Serial0/1
 ip address 10.30.1.1 255.255.255.0
!
interface Serial0/2
 ip address 10.31.1.1 255.255.255.0
!
router eigrp 10
 network 10.0.0.0
 no auto-summary
R9 configuration
interface Serial0/0
 ip address 10.35.1.2 255.255.255.0
!
interface Serial0/1
 ip address 10.30.1.2 255.255.255.0
!
router eigrp 10
 network 10.0.0.0
 no auto-summary
R10 configuration
interface Serial1/0 
 ip address 10.31.1.2 255.255.255.0
!
router eigrp 10 
 network 10.0.0.0
 no auto-summary

Confirming EIRGP adjacencies

We can use the "show ip route" command to confirm that we are receiving EIGRP routes, which are indicated by a "D" ,and have an AD of 90:

R4#sh ip route | beg Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C        10.20.1.0/24 is directly connected, Serial0/1
L        10.20.1.1/32 is directly connected, Serial0/1
C        10.25.1.0/24 is directly connected, Serial0/2
L        10.25.1.1/32 is directly connected, Serial0/2
D        10.30.1.0/24 [90/2681856] via 10.25.1.2, 00:03:02, Serial0/2
D        10.31.1.0/24 [90/2681856] via 10.25.1.2, 00:08:30, Serial0/2
D        10.35.1.0/24 [90/2681856] via 10.20.1.2, 00:03:04, Serial0/1

R5#sh ip route | beg Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C        10.20.1.0/24 is directly connected, Serial0/0
L        10.20.1.2/32 is directly connected, Serial0/0
D        10.25.1.0/24 [90/2681856] via 10.20.1.1, 00:03:21, Serial0/0
D        10.30.1.0/24 [90/2681856] via 10.35.1.2, 00:03:21, Serial0/2
D        10.31.1.0/24 [90/3193856] via 10.35.1.2, 00:03:21, Serial0/2
                                  [90/3193856] via 10.20.1.1, 00:03:21, Serial0/0
C        10.35.1.0/24 is directly connected, Serial0/2
L        10.35.1.1/32 is directly connected, Serial0/2

There are two routes on R5 that are bolded as we will be looking at these later on...

R8#sh ip route | beg Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
D        10.20.1.0/24 [90/2681856] via 10.25.1.1, 00:03:39, Serial0/0
C        10.25.1.0/24 is directly connected, Serial0/0
L        10.25.1.2/32 is directly connected, Serial0/0
C        10.30.1.0/24 is directly connected, Serial0/1
L        10.30.1.1/32 is directly connected, Serial0/1
C        10.31.1.0/24 is directly connected, Serial0/2
L        10.31.1.1/32 is directly connected, Serial0/2
D        10.35.1.0/24 [90/2681856] via 10.30.1.2, 00:03:42, Serial0/1

R9#sh ip route | beg Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D        10.20.1.0/24 [90/2681856] via 10.35.1.1, 00:03:58, Serial0/0
D        10.25.1.0/24 [90/2681856] via 10.30.1.1, 00:03:58, Serial0/1
C        10.30.1.0/24 is directly connected, Serial0/1
L        10.30.1.2/32 is directly connected, Serial0/1
D        10.31.1.0/24 [90/2681856] via 10.30.1.1, 00:03:58, Serial0/1
C        10.35.1.0/24 is directly connected, Serial0/0
L        10.35.1.2/32 is directly connected, Serial0/0

R10#sh ip route | beg Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D        10.20.1.0/24 [90/3193856] via 10.31.1.1, 00:03:55, Serial1/0
D        10.25.1.0/24 [90/2681856] via 10.31.1.1, 00:03:55, Serial1/0
D        10.30.1.0/24 [90/2681856] via 10.31.1.1, 00:03:55, Serial1/0
C        10.31.1.0/24 is directly connected, Serial1/0
L        10.31.1.2/32 is directly connected, Serial1/0
D        10.35.1.0/24 [90/3193856] via 10.31.1.1, 00:03:55, Serial1/0

Best Path

R5 has two routes to the 10.31.1.0/24 network, one through Serial 0/0 (R4), and one through Serial 0/2 (R9).

R5#sh ip route | beg Gate
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C        10.20.1.0/24 is directly connected, Serial0/0
L        10.20.1.2/32 is directly connected, Serial0/0
D        10.25.1.0/24 [90/2681856] via 10.20.1.1, 00:00:24, Serial0/0
D        10.30.1.0/24 [90/2681856] via 10.35.1.2, 00:00:24, Serial0/2
D        10.31.1.0/24 [90/3193856] via 10.35.1.2, 00:00:24, Serial0/2
                                  [90/3193856] via 10.20.1.1, 00:00:24, Serial0/0
C        10.35.1.0/24 is directly connected, Serial0/2
L        10.35.1.1/32 is directly connected, Serial0/2
      172.20.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.20.20.0/24 [90/3321856] via 10.35.1.2, 00:00:24, Serial0/2
                                      [90/3321856] via 10.20.1.1, 00:00:24, Serial0/0
D        172.20.30.0/24 [90/3321856] via 10.35.1.2, 00:00:24, Serial0/2
                                      [90/3321856] via 10.20.1.1, 00:00:24, Serial0/0
D        172.20.40.0/23 [90/3321856] via 10.35.1.2, 00:00:24, Serial0/2
                                      [90/3321856] via 10.20.1.1, 00:00:24, Serial0/0

If we wanted to make the route through Serial 0/0 the preferred route we can do this in a number of ways. Because the (main) metrics used by EIGRP are bandwidth and delay, it makes sense for us to tweak the bandwidth between R5 and R9. This should match on both sides, otherwise adjacencies may not form. To change the bandwidth (from the default of 1544) we enter the interface configuration mode and set the bandwidth:
R5#conf t
R5(config)#int s0/2
R5(config-if)#bandwidth 64
R5(config-if)#exit
R5(config)#exit

R9#conf t
R9(config)#int s0/0
R9(config-if)#bandwidth 64
R9(config-if)#exit
R9(config)#
Now we can see that the R5 prefers R4 as its route to the rest of the EIGRP network:

R5#sh ip route | beg Gateway

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C        10.20.1.0/24 is directly connected, Serial0/0
L        10.20.1.2/32 is directly connected, Serial0/0
D        10.25.1.0/24 [90/2681856] via 10.20.1.1, 00:00:09, Serial0/0
D        10.30.1.0/24 [90/3193856] via 10.20.1.1, 00:00:09, Serial0/0
D        10.31.1.0/24 [90/3193856] via 10.20.1.1, 00:00:09, Serial0/0
C        10.35.1.0/24 is directly connected, Serial0/2
L        10.35.1.1/32 is directly connected, Serial0/2
      172.20.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.20.20.0/24 [90/3321856] via 10.20.1.1, 00:00:09, Serial0/0
D        172.20.30.0/24 [90/3321856] via 10.20.1.1, 00:00:09, Serial0/0
D        172.20.40.0/23 [90/3321856] via 10.20.1.1, 00:00:09, Serial0/0

The routes do not show up now, but we can confirm that that are there (and have a look at the last part of this port on Loop-free paths to see where the back up routes are kept), and to confirm that the routes via R9 are still viable we can shut down R5's connection to R4 and check the routing table:
R5#conf t
R5(config)#int s0/0
R5(config-if)#shut
R5(config-if)#exit
R5(config)#exit
R5#
R5#sh ip route | beg Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D        10.20.1.0/24 [90/42048000] via 10.35.1.2, 00:00:11, Serial0/2
D        10.25.1.0/24 [90/41536000] via 10.35.1.2, 00:00:11, Serial0/2
D        10.30.1.0/24 [90/41024000] via 10.35.1.2, 00:00:11, Serial0/2
D        10.31.1.0/24 [90/41536000] via 10.35.1.2, 00:00:11, Serial0/2
C        10.35.1.0/24 is directly connected, Serial0/2
L        10.35.1.1/32 is directly connected, Serial0/2
      172.20.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.20.20.0/24 [90/41664000] via 10.35.1.2, 00:00:11, Serial0/2
D        172.20.30.0/24 [90/41664000] via 10.35.1.2, 00:00:11, Serial0/2
D        172.20.40.0/23 [90/41664000] via 10.35.1.2, 00:00:11, Serial0/2
R5#

Once again if we bring the interface back up again, after the adjacency re-establishes the route via R4 again becomes the preferred route:
R5(config)#int s0/0
R5(config-if)#no shut
R5(config-if)#exit
*Nov  5 13:53:14.657: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Nov  5 13:53:15.661: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
R5(config)#exit
R5#
*Nov  5 13:53:17.081: %SYS-5-CONFIG_I: Configured from console by console
*Nov  5 13:53:23.433: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.20.1.1 (Serial0/0) is up: new adjacency
R5#sh ip route | beg Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C        10.20.1.0/24 is directly connected, Serial0/0
L        10.20.1.2/32 is directly connected, Serial0/0
D        10.25.1.0/24 [90/2681856] via 10.20.1.1, 00:00:01, Serial0/0
D        10.30.1.0/24 [90/3193856] via 10.20.1.1, 00:00:01, Serial0/0
D        10.31.1.0/24 [90/3193856] via 10.20.1.1, 00:00:01, Serial0/0
C        10.35.1.0/24 is directly connected, Serial0/2
L        10.35.1.1/32 is directly connected, Serial0/2
      172.20.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.20.20.0/24 [90/3321856] via 10.20.1.1, 00:00:01, Serial0/0
D        172.20.30.0/24 [90/3321856] via 10.20.1.1, 00:00:01, Serial0/0
D        172.20.40.0/23 [90/3321856] via 10.20.1.1, 00:00:01, Serial0/0

Manual summarization and autosummarization 

We have already seen the effect of auto-summarization above, even using the command "no auto-summary", EIGRP will still summarize across major network boundaries.  In order to look at manual summarization we will create four loopback interfaces on R10, and summarize two of them:
R10(config)#int lo0
R10(config-if)#ip address 172.20.20.1 255.255.255.0
R10(config-if)#int lo1
R10(config-if)#ip address 172.20.30.1 255.255.255.0
R10(config-if)#exit
R10(config)#router eigrp 10
R10(config-router)#network 172.20.20.0 0.255.255.255
R10(config-router)#network 172.20.30.0 0.255.255.255
R10(config-router)#exit
R4#sh ip route | beg Gateway
Gateway of last resort is not set

<omitted for brevity>
      172.20.0.0/24 is subnetted, 2 subnets
D        172.20.20.0 [90/2809856] via 10.25.1.2, 00:00:24, Serial0/2
D        172.20.30.0 [90/2809856] via 10.25.1.2, 00:00:24, Serial0/2

And above we can see that we have our two new loopback networks being advertised through to R4.

Now we will create two more loopbacks, and summarize these addresses:
R10(config)#int lo2
R10(config-if)#ip address 172.20.40.1 255.255.255.0
R10(config-if)#int lo3
R10(config-if)#ip address 172.20.41.1 255.255.255.0
R10(config-if)#exit
R10(config)#int s1/0
R10(config-if)#ip summary-address eigrp 10 172.20.40.0 255.255.254.0
R10(config-if)#exit
R10#sh ip route | beg Gateway
Gateway of last resort is not set

<omitted for brevity>
      172.20.0.0/16 is variably subnetted, 9 subnets, 3 masks
C        172.20.20.0/24 is directly connected, Loopback0
L        172.20.20.1/32 is directly connected, Loopback0
C        172.20.30.0/24 is directly connected, Loopback1
L        172.20.30.1/32 is directly connected, Loopback1
D        172.20.40.0/23 is a summary, 00:00:35, Null0
C        172.20.40.0/24 is directly connected, Loopback2
L        172.20.40.1/32 is directly connected, Loopback2
C        172.20.41.0/24 is directly connected, Loopback3
L        172.20.41.1/32 is directly connected, Loopback3

The use of a summary address automatically creates a route to Null0, and if we look on R4 we can see the summary route being advertised as a /23:

R4#sh ip route | beg Gateway
Gateway of last resort is not set

<omitted for brevity>
      172.20.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.20.20.0/24 [90/2809856] via 10.25.1.2, 00:06:32, Serial0/2
D        172.20.30.0/24 [90/2809856] via 10.25.1.2, 00:06:32, Serial0/2
D        172.20.40.0/23 [90/2809856] via 10.25.1.2, 00:00:48, Serial0/2

EIGRP stubs 

Stub routers improve EIGRP convergence and conserve bandwidth. There are four types of stub: 

  • Receive-only – router will not share updates with neighbors
  • Connected – router will only advertise connected networks
  • Static – router will only advertise static networks
  • Summary – router will only advertise summary routes
Looking at R4 we can see that R10 is advertising the loopbacks as follows:

R4#sh ip route | beg Gateway
Gateway of last resort is not set

<omitted for brevity>

      172.20.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.20.20.0/24 [90/2809856] via 10.25.1.2, 00:20:59, Serial0/2
D        172.20.30.0/24 [90/2809856] via 10.25.1.2, 00:20:59, Serial0/2
D        172.20.40.0/23 [90/2809856] via 10.25.1.2, 00:15:15, Serial0/2

We can configure R10 to advertise the connected networks with the following commands:
R10(config)#router eigrp 10
R10(config-router)#eigrp stub connected
R10(config-router)#
*Nov  5 13:35:44.125: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.31.1.1 (Serial1/0) is down: peer info changed
*Nov  5 13:35:45.021: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.31.1.1 (Serial1/0) is up: new adjacency
R10(config-router)#exit
And if we look again at R4 we can see that all of the connected routes are advertised but we have lost the summary route:

R4#sh ip route | beg Gateway
Gateway of last resort is not set

<omitted for brevity>
      172.20.0.0/24 is subnetted, 4 subnets
D        172.20.20.0 [90/2809856] via 10.25.1.2, 00:00:08, Serial0/2
D        172.20.30.0 [90/2809856] via 10.25.1.2, 00:00:08, Serial0/2
D        172.20.40.0 [90/2809856] via 10.25.1.2, 00:00:08, Serial0/2
D        172.20.41.0 [90/2809856] via 10.25.1.2, 00:00:08, Serial0/2

We can advertise both the connected and summary routes using the following command:
R10(config-router)#eigrp stub connected summary
R10(config-router)#
*Nov  5 13:37:30.293: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.31.1.1 (Serial1/0) is down: peer info changed
*Nov  5 13:37:31.069: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.31.1.1 (Serial1/0) is up: new adjacency
And we can see that the summary routes is back, as well as keeping in the non-summarised routes:

R4#sh ip route | beg Gateway
Gateway of last resort is not set

<omitted for brevity>

      172.20.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.20.20.0/24 [90/2809856] via 10.25.1.2, 00:00:03, Serial0/2
D        172.20.30.0/24 [90/2809856] via 10.25.1.2, 00:00:03, Serial0/2
D        172.20.40.0/23 [90/2809856] via 10.25.1.2, 00:00:03, Serial0/2

The default command of "eigrp stub" actually advertised both connected and summary routes, so we could just use the following:
R10(config)#router eigrp 10
R10(config-router)#eigrp stub
And we can see that R4 looks the same:

R4#sh ip route | beg Gateway
Gateway of last resort is not set

<omitted for brevity>
      172.20.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.20.20.0/24 [90/2809856] via 10.25.1.2, 00:00:03, Serial0/2
D        172.20.30.0/24 [90/2809856] via 10.25.1.2, 00:00:03, Serial0/2
D        172.20.40.0/23 [90/2809856] via 10.25.1.2, 00:00:03, Serial0/2

Loop-free paths

As mentioned earlier when we looked at confirming the adjacencies it looke dlike we had lost the routes from R5 through R9 to the rest of the EIGRP network:

R5#sh ip route | beg Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C        10.20.1.0/24 is directly connected, Serial0/0
L        10.20.1.2/32 is directly connected, Serial0/0
D        10.25.1.0/24 [90/2681856] via 10.20.1.1, 00:00:01, Serial0/0
D        10.30.1.0/24 [90/3193856] via 10.20.1.1, 00:00:01, Serial0/0
D        10.31.1.0/24 [90/3193856] via 10.20.1.1, 00:00:01, Serial0/0
C        10.35.1.0/24 is directly connected, Serial0/2
L        10.35.1.1/32 is directly connected, Serial0/2
      172.20.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.20.20.0/24 [90/3321856] via 10.20.1.1, 00:00:01, Serial0/0
D        172.20.30.0/24 [90/3321856] via 10.20.1.1, 00:00:01, Serial0/0
D        172.20.40.0/23 [90/3321856] via 10.20.1.1, 00:00:01, Serial0/0
R5#

But if we look at the actual topology we can see that they are kept within the EIGRP topology table:

R5#sh ip eigrp topology
EIGRP-IPv4 Topology Table for AS(10)/ID(10.35.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 10.30.1.0/24, 1 successors, FD is 3193856
        via 10.20.1.1 (3193856/2681856), Serial0/0
        via 10.35.1.2 (41024000/2169856), Serial0/2
P 10.31.1.0/24, 1 successors, FD is 3193856
        via 10.20.1.1 (3193856/2681856), Serial0/0
        via 10.35.1.2 (41536000/2681856), Serial0/2
P 172.20.30.0/24, 1 successors, FD is 3321856
        via 10.20.1.1 (3321856/2809856), Serial0/0
        via 10.35.1.2 (41664000/2809856), Serial0/2
P 10.20.1.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0
P 10.25.1.0/24, 1 successors, FD is 2681856
        via 10.20.1.1 (2681856/2169856), Serial0/0
P 172.20.40.0/23, 1 successors, FD is 3321856
        via 10.20.1.1 (3321856/2809856), Serial0/0
        via 10.35.1.2 (41664000/2809856), Serial0/2
P 172.20.20.0/24, 1 successors, FD is 3321856
        via 10.20.1.1 (3321856/2809856), Serial0/0
        via 10.35.1.2 (41664000/2809856), Serial0/2
P 10.35.1.0/24, 1 successors, FD is 40512000
        via Connected, Serial0/2

So although the routes are not shown in the routing table, they are listed in the topology table. The preferred route (the FD) is the one listed in the routing table, and is shown in bold text.

So now we have a full EIGRP topology working we can move on to part 6, and start redistributing our networks between our IGPs. There is a lot more to EIGRP than is shown here, and we will revisit EIGRP later on and discuss some more advanced topics, such as authentication, more metric tuning, the effect of passive interfaces, load balancing and troubleshooting. But for now we can move on to part 6 of this series.
Subscribe to: Posts (Atom)