Jul
08

For a limited time we are publishing the Route Redistribution videos from our CCIE Routing & Switching Advanced Technologies Class for public viewing.  These videos cover all aspects of Route Redistribution needed for the CCIE R&S Lab Exam outside of the scope of MPLS, and will also be useful for any engineers looking for more information on how the Route Redistribution process works.

Specifically these videos cover basic and advanced route redistribution configuration, verification, and troubleshooting, including how and why route redistribution loops occur, how to identify and fix loops related to both Administrative Distance and Metric, TCL scripting for reachability testing, route tagging, the IP Route Profile feature, how to use and interpret the debug ip routing output, and other related topics.  Links the videos are as follows:

For technical questions about the topics covered in these videos please visit INE's Online Community.

All of these videos and others totalling over 80 hours for the CCIE R&S ATC series are included in all of our All Access Pass subscriptions at just $159 per month, along with access to over 900 hours of other training videos that include, but are not limited to:

  • CCNA Routing & Switching
  • CCNA Security
  • CCNA Voice
  • CCNA Wireless
  • CCNP Routing & Switching
  • CCNP Security
  • CCNP Voice
  • CCIE Routing & Switching
  • CCIE Security
  • CCIE Voice
  • CCIE Service Provider
Dec
30

To start my reading from Petr's excellent CCDE reading list for his upcoming LIVE and ONLINE CCDE Bootcamps, I decided to start with:
EIGRP for IP: Basic Operation and Configuration by Russ White and Alvaro Retana
I was able to grab an Amazon Kindle version for about $9, and EIGRP has always been one of my favorite protocols.
The text dives right in to none other than the composite metric of EIGRP and it brought a smile to my face as I thought about all of the misconceptions I had regarding this topic from early on in my Cisco studies. Let us review some key points regarding this metric and hopefully put some of your own misconceptions to rest.

  • While we are taught since CCNA days that the EIGRP metric consists of 5 possible components - BW, Delay, Load, Reliability, and MTU; we realize when we look at the actual formula for the metric computation, MTU is actually not part of the metric. Why have we been taught this then? Cisco indicates that MTU is used as a tie-breaker in a situation that might require it. To review the actual formula that is used to compute the metric, click here.
  • Notice from the formula that the K (constant values) impact which components of the metric are actually considered. By default K1 is set to 1 and K3 is set to 1 to ensure that Bandwidth and Delay are utilized in the calculation. If you wanted to make Bandwidth twice as significant in the calculation, you could set K1 to 2, as an example. The metric weights command is used for this manipulation. Note that it starts with a TOS parameter that should always be set to 0. Cisco never did fully implement this functionality.
  • The Bandwidth that effects the metric is taken from the bandwidth command used in interface configuration mode. Obviously, if you do not provide this value - the Cisco router will select a default based on the interface type.
  • The Delay value that effects the metric is taken from the delay command used in interface configuration mode. This value depends on the interface hardware type, e.g. it is lower for Ethernet but higher for Serial interfaces. Note how the Delay parameter allows you to influence EIGRP pathing decisions without the manipulation of the Bandwidth value. This is nice since other mechanisms could be relying heavily on the bandwidth setting, e.g. EIGRP bandwidth pacing or absolute QoS reservation values for CBWFQ.
  • The actual metric value for a prefix is derived from the SUM of the delay values in the path, and the LOWEST bandwidth value along the path. This is yet another reason to use more predictive Delay manipulations to change EIGRP path preference.

In the next post on the EIGRP metric, we will examine this at the actual command line, and discuss EIGRP load balancing options. Thanks for reading!

Dec
23

CCNA students can typically rattle off the fact that EIGRP uses Bandwidth and Delay in its composite metric calculation by default. In fact, they tend to know this as well as their own last name. But I often notice they might have some pretty big misconceptions about how this metric is really calculated, and how they can manipulate it.

Here are some very important "Core Knowledge" facts that we need to keep in mind about the EIGRP metric:

  • The metric formula uses the bandwidth and delay values that are set as default on the interface, or those values configured on the interface by an administrator
  • The bandwidth value that is used in the calculation is the slowest bandwidth in the path from source to destination; to remember this just think of the "weakest link" in the path
  • The delay value used in the calculation is the sum of the delay values in the path
  • You can set the bandwidth value of an interface using the BANDWIDTH command and you can set the delay value of an interface using the DELAY command
  • Setting bandwidth or delay on an interface does not change any physical properties of the interface at all; you are just changing the values that the interface reports for EIGRP metric purposes

Let's examine some of this at the command line:

R1#show run interface fa0/0
Building configuration...

Current configuration : 95 bytes
!
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
duplex auto
speed auto

Notice that we have not set BANDWIDTH or DELAY under this interface at all. Let us examine what EIGRP will be using regarding this interface in its overall calculation:

R1#show interface fa0/0
FastEthernet0/0 is up, line protocol is up
Hardware is Gt96k FE, address is c201.0111.0000 (bia c201.0111.0000)
Internet address is 10.10.10.1/24
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255

Notice the values that EIGRP can use by default are in place.

The DELAY command is a powerful command for manipulating EIGRP paths. Since the BANDWIDTH command can end up impacting a lot of other configurations (like QoS), we can use the DELAY command to manipulate EIGRP metrics (and therefore, paths) without having to touch the BANDWIDTH command.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface fa0/0
R1(config-if)#delay ?
<1-16777215>  Throughput delay (tens of microseconds)

Notice from the above output just how easy it is to manipulate this value, and therefore, impact the EIGRP metric.

I hope you are enjoying your CCNA training here at INE, and I hope you will return to our blog often!

Feb
19

UPDATE: For more information on Redistribution see the video series Understanding Route Redistribution – Excerpts from CCIE R&S ATC

Simple Redistribution Step-by-Step

We're going to take our basic topology from the previous post Understanding Redistribution Part I , and configure to provide full connectivity between all devices with the most simple configuration. Then we are going to tweak some settings and see how they affect redistribution and optimal routing. This is going to be an introductory example to illustrate the redistribution control techniques mentioned previously.

First, we configure IGP routing per the diagram, and advertise Loopback0 interfaces (150.X.Y.Y/24, where X is the rack number, and Y is the router number) into IGP. Specifically, R2, R3 and R4 Loopbacks are advertised into OSPF Area 0. R5 and R6 Loopbacks are advertised into EIGRP 356 and R1 Loopback interface is simply advertised into EIGRP 123.

Next, we propose OSPF to be the core routing domain, used as transit path to reach any other domains. All other domains, in effect, will be connected as stub (non-transit) to the core domain. We start with EIGRP 123 and OSPF domains, and enable mutual redistribution between them on R2 and R3 routers:

R2:
!
! Metric values are chosen just to be easy to type in
! No big secret rules of thumb behind this one
!
router eigrp 123
redistribute ospf 1 metric 1 1 1 1 1
!
router ospf 1
redistribute eigrp 123 subnets

R3:
router eigrp 123
redistribute ospf 1 metric 1 1 1 1 1
!
router ospf 1
redistribute eigrp 123 subnets

In effect, we would expect both routing domains to become transit for each other. However, EIGRP has a really nice feature of assigning default AD value of 170 to external routes. This, in turn, prevents circular redistribution - all OSPF routes injected into EIGRP 123 domain have AD of 170, and are effectively stopped from being advertised back into OSPF, since native OSPF routes preempt them. Let's see the routing table states:

Rack18R1#show ip route eigrp
174.18.0.0/24 is subnetted, 2 subnets
D EX 174.18.234.0
[170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:02:03, FastEthernet0/0
150.18.0.0/24 is subnetted, 4 subnets
D EX 150.18.4.0
[170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:02:03, FastEthernet0/0
D EX 150.18.2.0
[170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:02:03, FastEthernet0/0
D EX 150.18.3.0
[170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:02:03, FastEthernet0/0

Just as we would expect, R1 has two routes from each OSPF prefix, since both R2 and R3 assign the same seed metric to redistributed routes.

Rack18R2#show ip route | beg Gate
Gateway of last resort is not set

174.18.0.0/24 is subnetted, 2 subnets
C 174.18.234.0 is directly connected, Serial0/0
C 174.18.123.0 is directly connected, FastEthernet0/0
150.18.0.0/24 is subnetted, 4 subnets
O 150.18.4.0 [110/65] via 174.18.234.4, 00:00:19, Serial0/0
D 150.18.1.0 [90/156160] via 174.18.123.1, 00:00:13, FastEthernet0/0
C 150.18.2.0 is directly connected, Loopback0
O 150.18.3.0 [110/65] via 174.18.234.3, 00:00:19, Serial0/0

Rack18R3#show ip route | beg Gate
Gateway of last resort is not set

174.18.0.0/24 is subnetted, 3 subnets
C 174.18.234.0 is directly connected, Serial1/0
C 174.18.0.0 is directly connected, FastEthernet0/1
C 174.18.123.0 is directly connected, FastEthernet0/0
150.18.0.0/24 is subnetted, 6 subnets
O 150.18.4.0 [110/782] via 174.18.234.4, 00:00:54, Serial1/0
D 150.18.5.0 [90/156160] via 174.18.0.5, 00:17:51, FastEthernet0/1
D 150.18.6.0 [90/156160] via 174.18.0.6, 00:17:49, FastEthernet0/1
D 150.18.1.0 [90/156160] via 174.18.123.1, 00:00:48, FastEthernet0/0
O 150.18.2.0 [110/782] via 174.18.234.2, 00:00:54, Serial1/0
C 150.18.3.0 is directly connected, Loopback0

All seems to be fine here too; thanks to EIGRP AD value of 90, EIGRP "native" prefixes are reachable via EIGRP, and OSPF native subnets are reachable via OSPF (since EIGRP External AD value is 170). Next, we move a step further, and redistribute between OSPF and EIGRP 356 domains, i.e. attach the latter domain to the "core":

R3:
router eigrp 356
redistribute ospf 1 metric 1 1 1 1 1
!
router ospf 1
redistribute eigrp 123 subnets
redistribute eigrp 356 subnets

Since EIGRP 356 domain has just one point of attachement to the core, there should be no big problems. Look at the routing table of R1:

Rack18R1#show ip route eigrp
174.18.0.0/24 is subnetted, 3 subnets
D EX 174.18.234.0
[170/2560002816] via 174.18.123.3, 00:05:52, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:05:52, FastEthernet0/0
D EX 174.18.0.0
[170/2560002816] via 174.18.123.2, 00:01:36, FastEthernet0/0
150.18.0.0/24 is subnetted, 6 subnets
D EX 150.18.4.0
[170/2560002816] via 174.18.123.3, 00:05:52, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:05:52, FastEthernet0/0
D EX 150.18.5.0
[170/2560002816] via 174.18.123.2, 00:01:36, FastEthernet0/0
D EX 150.18.6.0
[170/2560002816] via 174.18.123.2, 00:01:36, FastEthernet0/0
D EX 150.18.2.0
[170/2560002816] via 174.18.123.3, 00:05:52, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:05:52, FastEthernet0/0
D EX 150.18.3.0
[170/2560002816] via 174.18.123.3, 00:05:52, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:05:52, FastEthernet0/0

Ah, great. R1 sees R5 and R6 loopback as they are advertised by R2 only. Naturally, redistribution between local routing processes on R3 is non-transitive - when we inject EIGRP 356 routes into OSPF, they are not further propagated into EIGRP 123, even though OSPF is redistributed into EIGRP 123. So R1 packets would have to transit OSPF domain, in order to reach R5 and R6.

R2 sees EIGRP 356 routes reachable via R3:

Rack18R2#show ip route | beg Gate
Gateway of last resort is not set

174.18.0.0/24 is subnetted, 3 subnets
C 174.18.234.0 is directly connected, Serial0/0
O E2 174.18.0.0 [110/20] via 174.18.234.3, 00:02:20, Serial0/0
C 174.18.123.0 is directly connected, FastEthernet0/0
150.18.0.0/24 is subnetted, 6 subnets
O 150.18.4.0 [110/65] via 174.18.234.4, 00:06:41, Serial0/0
O E2 150.18.5.0 [110/20] via 174.18.234.3, 00:02:20, Serial0/0
O E2 150.18.6.0 [110/20] via 174.18.234.3, 00:02:20, Serial0/0
D 150.18.1.0 [90/156160] via 174.18.123.1, 00:06:35, FastEthernet0/0
C 150.18.2.0 is directly connected, Loopback0
O 150.18.3.0 [110/65] via 174.18.234.3, 00:06:41, Serial0/0

And R3 in turn sees them as EIGRP 356 native ones:

Rack18R3#show ip route | beg Gate
Gateway of last resort is not set

174.18.0.0/24 is subnetted, 3 subnets
C 174.18.234.0 is directly connected, Serial1/0
C 174.18.0.0 is directly connected, FastEthernet0/1
C 174.18.123.0 is directly connected, FastEthernet0/0
150.18.0.0/24 is subnetted, 6 subnets
O 150.18.4.0 [110/782] via 174.18.234.4, 00:02:47, Serial1/0
D 150.18.5.0 [90/156160] via 174.18.0.5, 00:02:36, FastEthernet0/1
D 150.18.6.0 [90/156160] via 174.18.0.6, 00:02:36, FastEthernet0/1
D 150.18.1.0 [90/156160] via 174.18.123.1, 00:02:34, FastEthernet0/0
O 150.18.2.0 [110/782] via 174.18.234.2, 00:02:47, Serial1/0
C 150.18.3.0 is directly connected, Loopback0

Fine, now to finish the picture, we redistribute between RIP and OSPF on R4

R4:
router ospf 1
redistribute rip subnets
!
! Assign some large metric value to redistributed routes
!
router rip
redistribute ospf 1 metric 8

Check to see the full routing table of R1:

Rack18R1#show ip route eigrp
D EX 222.22.2.0/24
[170/2560002816] via 174.18.123.3, 00:02:16, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:02:16, FastEthernet0/0
D EX 220.20.3.0/24
[170/2560002816] via 174.18.123.3, 00:02:16, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:02:16, FastEthernet0/0
174.18.0.0/24 is subnetted, 3 subnets
D EX 174.18.234.0
[170/2560002816] via 174.18.123.3, 00:05:17, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:05:17, FastEthernet0/0
D EX 174.18.0.0
[170/2560002816] via 174.18.123.2, 00:08:33, FastEthernet0/0
D EX 192.10.18.0/24
[170/2560002816] via 174.18.123.3, 00:02:16, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:02:16, FastEthernet0/0
150.18.0.0/24 is subnetted, 6 subnets
D EX 150.18.4.0
[170/2560002816] via 174.18.123.3, 00:05:17, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:05:17, FastEthernet0/0
D EX 150.18.5.0
[170/2560002816] via 174.18.123.2, 00:05:14, FastEthernet0/0
D EX 150.18.6.0
[170/2560002816] via 174.18.123.2, 00:05:15, FastEthernet0/0
D EX 150.18.2.0
[170/2560002816] via 174.18.123.3, 00:05:20, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:05:20, FastEthernet0/0
D EX 150.18.3.0
[170/2560002816] via 174.18.123.3, 00:05:20, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:05:20, FastEthernet0/0
D EX 205.90.31.0/24
[170/2560002816] via 174.18.123.3, 00:02:19, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:02:19, FastEthernet0/0

Seems like we have connectivity to all prefixes, even the ones injected by BB2 (205.90.31.0/24 etc). All of them, with except to EIGRP 356 routes are symmetrically reachable via R2 and R3. Now, a long snapshot of all other routing tables:

Rack18R2#show ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:03:29, Serial0/0
O E2 220.20.3.0/24 [110/20] via 174.18.234.4, 00:03:29, Serial0/0
174.18.0.0/24 is subnetted, 3 subnets
C 174.18.234.0 is directly connected, Serial0/0
O E2 174.18.0.0 [110/20] via 174.18.234.3, 00:03:29, Serial0/0
C 174.18.123.0 is directly connected, FastEthernet0/0
O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:03:29, Serial0/0
150.18.0.0/24 is subnetted, 6 subnets
O 150.18.4.0 [110/65] via 174.18.234.4, 00:03:29, Serial0/0
O E2 150.18.5.0 [110/20] via 174.18.234.3, 00:03:29, Serial0/0
O E2 150.18.6.0 [110/20] via 174.18.234.3, 00:03:29, Serial0/0
D 150.18.1.0 [90/156160] via 174.18.123.1, 00:19:36, FastEthernet0/0
C 150.18.2.0 is directly connected, Loopback0
O 150.18.3.0 [110/65] via 174.18.234.3, 00:03:29, Serial0/0
O E2 205.90.31.0/24 [110/20] via 174.18.234.4, 00:03:29, Serial0/0

Rack18R3#show ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0
O E2 220.20.3.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0
174.18.0.0/24 is subnetted, 3 subnets
C 174.18.234.0 is directly connected, Serial1/0
C 174.18.0.0 is directly connected, FastEthernet0/1
C 174.18.123.0 is directly connected, FastEthernet0/0
O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0
150.18.0.0/24 is subnetted, 6 subnets
O 150.18.4.0 [110/782] via 174.18.234.4, 00:03:56, Serial1/0
D 150.18.5.0 [90/156160] via 174.18.0.5, 00:06:58, FastEthernet0/1
D 150.18.6.0 [90/156160] via 174.18.0.6, 00:06:58, FastEthernet0/1
D 150.18.1.0 [90/156160] via 174.18.123.1, 00:06:57, FastEthernet0/0
O 150.18.2.0 [110/782] via 174.18.234.2, 00:03:56, Serial1/0
C 150.18.3.0 is directly connected, Loopback0
O E2 205.90.31.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0

Rack18R4#show ip route | beg Gate
Gateway of last resort is not set

R 222.22.2.0/24 [120/7] via 192.10.18.254, 00:00:19, FastEthernet0/0
R 220.20.3.0/24 [120/7] via 192.10.18.254, 00:00:19, FastEthernet0/0
174.18.0.0/24 is subnetted, 3 subnets
C 174.18.234.0 is directly connected, Serial0/0
O E2 174.18.0.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0
O E2 174.18.123.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0
[110/20] via 174.18.234.2, 00:05:11, Serial0/0
C 192.10.18.0/24 is directly connected, FastEthernet0/0
150.18.0.0/24 is subnetted, 6 subnets
C 150.18.4.0 is directly connected, Loopback0
O E2 150.18.5.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0
O E2 150.18.6.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0
O E2 150.18.1.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0
[110/20] via 174.18.234.2, 00:05:11, Serial0/0
O 150.18.2.0 [110/65] via 174.18.234.2, 00:05:11, Serial0/0
O 150.18.3.0 [110/65] via 174.18.234.3, 00:05:11, Serial0/0
R 205.90.31.0/24 [120/7] via 192.10.18.254, 00:00:20, FastEthernet0/0

A quick stop at R5. Since RIPv2 AD is 120, and EIGRP External AD is 170, R5 sees all non EIGRP 356 routes via RIP. Not a big problem right now, but it creates "suboptimal" paths to EIGRP 123 routes, since it's more, well, effective to reach them over Ethernet links.

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

R 222.22.2.0/24 [120/7] via 192.10.18.254, 00:00:25, FastEthernet0/1
R 220.20.3.0/24 [120/7] via 192.10.18.254, 00:00:25, FastEthernet0/1
174.18.0.0/24 is subnetted, 3 subnets
R 174.18.234.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1
C 174.18.0.0 is directly connected, FastEthernet0/0
R 174.18.123.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1
C 192.10.18.0/24 is directly connected, FastEthernet0/1
150.18.0.0/24 is subnetted, 6 subnets
R 150.18.4.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1
C 150.18.5.0 is directly connected, Loopback0
D 150.18.6.0 [90/156160] via 174.18.0.6, 00:43:41, FastEthernet0/0
R 150.18.1.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1
R 150.18.2.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1
R 150.18.3.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1
R 205.90.31.0/24 [120/7] via 192.10.18.254, 00:00:25, FastEthernet0/1

We may opt to craeate an access-list, select all RIP routes, and freeze their AD down to 120. Next we can rais global RIP distance to something bigger than 170, to fix this issue. Not a big deal, though! OK, so the only left are R6 and BB2:

Rack18R6#show ip route eigrp
D EX 222.22.2.0/24 [170/2560002816] via 174.18.0.3, 00:07:29, FastEthernet0/0
D EX 220.20.3.0/24 [170/2560002816] via 174.18.0.3, 00:07:29, FastEthernet0/0
174.18.0.0/24 is subnetted, 2 subnets
D EX 174.18.234.0
[170/2560002816] via 174.18.0.3, 00:10:31, FastEthernet0/0
D EX 192.10.18.0/24 [170/2560002816] via 174.18.0.3, 00:07:29, FastEthernet0/0
150.18.0.0/24 is subnetted, 5 subnets
D EX 150.18.4.0 [170/2560002816] via 174.18.0.3, 00:10:31, FastEthernet0/0
D 150.18.5.0 [90/156160] via 174.18.0.5, 00:41:30, FastEthernet0/0
D EX 150.18.2.0 [170/2560002816] via 174.18.0.3, 00:10:31, FastEthernet0/0
D EX 150.18.3.0 [170/2560002816] via 174.18.0.3, 00:10:31, FastEthernet0/0
D EX 205.90.31.0/24 [170/2560002816] via 174.18.0.3, 00:07:29, FastEthernet0/0

BB2>sh ip ro rip
174.18.0.0/24 is subnetted, 3 subnets
R 174.18.234.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
R 174.18.0.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
R 174.18.123.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
150.18.0.0/24 is subnetted, 6 subnets
R 150.18.4.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
R 150.18.5.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
R 150.18.6.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
R 150.18.1.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
R 150.18.2.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0
R 150.18.3.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0

This seems to be an easy one. We're done, full connectivity attained, and no loops were introduced. Thanks to EIGRP External AD there is no need to manually filter routes on the border routes between EIGRP 123 and OSPF. But what if we are asked to redistribute some "native" EIGRP 123 prefixes (e.g. R1 Loopback0) instead of advertising them?

R1:
router eigrp 123
redistribute connected
network 174.18.123.1 0.0.0.0

See what happens:

Rack18R2#show ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:15:13, Serial0/0
O E2 220.20.3.0/24 [110/20] via 174.18.234.4, 00:15:13, Serial0/0
174.18.0.0/24 is subnetted, 3 subnets
C 174.18.234.0 is directly connected, Serial0/0
O E2 174.18.0.0 [110/20] via 174.18.234.3, 00:15:13, Serial0/0
C 174.18.123.0 is directly connected, FastEthernet0/0
O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:15:13, Serial0/0
150.18.0.0/24 is subnetted, 6 subnets
O 150.18.4.0 [110/65] via 174.18.234.4, 00:15:13, Serial0/0
O E2 150.18.5.0 [110/20] via 174.18.234.3, 00:15:13, Serial0/0
O E2 150.18.6.0 [110/20] via 174.18.234.3, 00:15:13, Serial0/0
D EX 150.18.1.0 [170/156160] via 174.18.123.1, 00:01:49, FastEthernet0/0
C 150.18.2.0 is directly connected, Loopback0
O 150.18.3.0 [110/65] via 174.18.234.3, 00:15:13, Serial0/0
O E2 205.90.31.0/24 [110/20] via 174.18.234.4, 00:15:13, Serial0/0

R2 sees R1 Loopback0 as EIGRP external route reachable via R1. However, the situation is different on R3:

Rack18R3#show ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:16:10, Serial1/0
O E2 220.20.3.0/24 [110/20] via 174.18.234.4, 00:16:10, Serial1/0
174.18.0.0/24 is subnetted, 3 subnets
C 174.18.234.0 is directly connected, Serial1/0
C 174.18.0.0 is directly connected, FastEthernet0/1
C 174.18.123.0 is directly connected, FastEthernet0/0
O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:16:10, Serial1/0
150.18.0.0/24 is subnetted, 6 subnets
O 150.18.4.0 [110/782] via 174.18.234.4, 00:16:10, Serial1/0
D 150.18.5.0 [90/156160] via 174.18.0.5, 00:19:12, FastEthernet0/1
D 150.18.6.0 [90/156160] via 174.18.0.6, 00:19:12, FastEthernet0/1
O E2 150.18.1.0 [110/20] via 174.18.234.2, 00:02:46, Serial1/0
O 150.18.2.0 [110/782] via 174.18.234.2, 00:16:10, Serial1/0
C 150.18.3.0 is directly connected, Loopback0
O E2 205.90.31.0/24 [110/20] via 174.18.234.4, 00:16:10, Serial1/0

Thanks to R1 Loopback0 being redistributed into OSPF, R3 prefers it via R2, not R1, due to AD values. Not a very big problem in this scenario, but in more complex cases this may lead to routing loops, since suboptimal path may be chosen. In order to fix this, we may adjust AD for the EIGRP prefix. However, there is a problem here - we can't change EIGRP external AD selectively, only for all prefixes at once.

This why we may choose to play with AD under OSPF. We may simply adjust AD for R1 Loopback0 prefix to a value of 171. However, we may go further, and simulate the feature of EIGRP with OSPF - speficically, make sure OSPF internal routes have AD different from the external prefixes. For EIGRP the values are 90 and 170. What values should we pick up for OSPF? Well, since OSPF is the core routing domain, it has more information available on what's going around. Okay, and it's the only transit domain, so we should make sure it has the highest preference among others. So it makes sense to set internal/external AD for OSPF to 80 and 160 - lower than the EIGRP values. This ensure that internal routes are always preferred over external, but core routing protocol is always the most trusted one.

R2 & R3:
access-list 1 permit 150.18.1.0
!
router ospf 1
distance ospf intra-area 80
distance ospf inter-area 80
distance ospf external 160
distance 171 0.0.0.0 255.255.255.255 1

See how this works on R2 and R3:

Rack18R2#show ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [160/20] via 174.18.234.4, 00:00:07, Serial0/0
O E2 220.20.3.0/24 [160/20] via 174.18.234.4, 00:00:07, Serial0/0
174.18.0.0/24 is subnetted, 3 subnets
C 174.18.234.0 is directly connected, Serial0/0
O E2 174.18.0.0 [160/20] via 174.18.234.3, 00:00:35, Serial0/0
C 174.18.123.0 is directly connected, FastEthernet0/0
O E2 192.10.18.0/24 [160/20] via 174.18.234.4, 00:00:35, Serial0/0
150.18.0.0/24 is subnetted, 6 subnets
O 150.18.4.0 [80/65] via 174.18.234.4, 00:00:35, Serial0/0
O E2 150.18.5.0 [160/20] via 174.18.234.3, 00:00:35, Serial0/0
O E2 150.18.6.0 [160/20] via 174.18.234.3, 00:00:35, Serial0/0
D EX 150.18.1.0 [170/156160] via 174.18.123.1, 00:03:10, FastEthernet0/0
C 150.18.2.0 is directly connected, Loopback0
O 150.18.3.0 [80/65] via 174.18.234.3, 00:00:35, Serial0/0
O E2 205.90.31.0/24 [160/20] via 174.18.234.4, 00:00:07, Serial0/0

OK, just as it was before, next comes R3:

Rack18R3#show ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [160/20] via 174.18.234.4, 00:00:55, Serial1/0
O E2 220.20.3.0/24 [160/20] via 174.18.234.4, 00:00:55, Serial1/0
174.18.0.0/24 is subnetted, 3 subnets
C 174.18.234.0 is directly connected, Serial1/0
C 174.18.0.0 is directly connected, FastEthernet0/1
C 174.18.123.0 is directly connected, FastEthernet0/0
O E2 192.10.18.0/24 [160/20] via 174.18.234.4, 00:01:14, Serial1/0
150.18.0.0/24 is subnetted, 6 subnets
O 150.18.4.0 [80/782] via 174.18.234.4, 00:01:14, Serial1/0
D 150.18.5.0 [90/156160] via 174.18.0.5, 00:37:14, FastEthernet0/1
D 150.18.6.0 [90/156160] via 174.18.0.6, 00:37:14, FastEthernet0/1
D EX 150.18.1.0 [170/156160] via 174.18.123.1, 00:03:58, FastEthernet0/0
O 150.18.2.0 [80/782] via 174.18.234.2, 00:01:14, Serial1/0
C 150.18.3.0 is directly connected, Loopback0
O E2 205.90.31.0/24 [160/20] via 174.18.234.4, 00:00:56, Serial1/0

All seems to look great, with except to the fact that EIGRP 123 and EIGRP 356 have to transit OSPF domain in order to reach each other. Though this is only true for R1, still we need to find out a way to resolve this issue. What if we start exhanging routes on R3 between EIGRP 123 and EIGRP 356? This will not cause any new domain to become transit - because EIGRP external AD will block the external routes from being re-injected into the core domain. This is why we may safely turn on mutual redistribution between the two domains.

R3:
router eigrp 123
redistribute eigrp 356
!
router eigrp 356
redistribute eigrp 123

Observe the effect on R1 now. Note the metrics assigned to R5 and R6 Loopback prefixes - they are taken directly from EIGRP 356 native prefixe metric values.

Rack18R1#show ip route eigrp
D EX 222.22.2.0/24
[170/2560002816] via 174.18.123.3, 00:20:05, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:20:05, FastEthernet0/0
D EX 220.20.3.0/24
[170/2560002816] via 174.18.123.3, 00:20:05, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:20:05, FastEthernet0/0
174.18.0.0/24 is subnetted, 3 subnets
D EX 174.18.234.0
[170/2560002816] via 174.18.123.3, 00:35:22, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:35:22, FastEthernet0/0
D EX 174.18.0.0 [170/30720] via 174.18.123.3, 00:00:37, FastEthernet0/0
D EX 192.10.18.0/24
[170/2560002816] via 174.18.123.3, 00:20:33, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:20:33, FastEthernet0/0
150.18.0.0/24 is subnetted, 6 subnets
D EX 150.18.4.0
[170/2560002816] via 174.18.123.3, 00:20:33, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:20:33, FastEthernet0/0
D EX 150.18.5.0 [170/158720] via 174.18.123.3, 00:00:38, FastEthernet0/0
D EX 150.18.6.0 [170/158720] via 174.18.123.3, 00:00:38, FastEthernet0/0
D EX 150.18.2.0
[170/2560002816] via 174.18.123.3, 00:20:25, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:20:25, FastEthernet0/0
D EX 150.18.3.0
[170/2560002816] via 174.18.123.3, 00:20:37, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:20:37, FastEthernet0/0
D EX 205.90.31.0/24
[170/2560002816] via 174.18.123.3, 00:20:09, FastEthernet0/0
[170/2560002816] via 174.18.123.2, 00:20:09, FastEthernet0/0

R6 also learns EIGRP 123 routes via R3:

Rack18R6#show ip route eigrp
D EX 222.22.2.0/24 [170/2560002816] via 174.18.0.3, 00:23:59, FastEthernet0/0
D EX 220.20.3.0/24 [170/2560002816] via 174.18.0.3, 00:23:59, FastEthernet0/0
174.18.0.0/24 is subnetted, 3 subnets
D EX 174.18.234.0
[170/2560002816] via 174.18.0.3, 01:00:18, FastEthernet0/0
D EX 174.18.123.0 [170/30720] via 174.18.0.3, 00:04:15, FastEthernet0/0
D EX 192.10.18.0/24 [170/2560002816] via 174.18.0.3, 00:27:22, FastEthernet0/0
150.18.0.0/24 is subnetted, 6 subnets
D EX 150.18.4.0 [170/2560002816] via 174.18.0.3, 00:27:22, FastEthernet0/0
D 150.18.5.0 [90/156160] via 174.18.0.5, 01:31:17, FastEthernet0/0
D EX 150.18.1.0 [170/158720] via 174.18.0.3, 00:04:15, FastEthernet0/0
D EX 150.18.2.0 [170/2560002816] via 174.18.0.3, 00:24:18, FastEthernet0/0
D EX 150.18.3.0 [170/2560002816] via 174.18.0.3, 01:00:18, FastEthernet0/0
D EX 205.90.31.0/24 [170/2560002816] via 174.18.0.3, 00:23:59, FastEthernet0/0

R3 will not transit OSPF backbone, due to our choice of administrative distances:

Rack18R3#show ip route | beg Gate
Gateway of last resort is not set

O E2 222.22.2.0/24 [160/20] via 174.18.234.4, 02:22:45, Serial1/0
O E2 220.20.3.0/24 [160/20] via 174.18.234.4, 02:22:45, Serial1/0
174.18.0.0/24 is subnetted, 3 subnets
C 174.18.234.0 is directly connected, Serial1/0
C 174.18.0.0 is directly connected, FastEthernet0/1
C 174.18.123.0 is directly connected, FastEthernet0/0
O E2 192.10.18.0/24 [160/20] via 174.18.234.4, 02:23:04, Serial1/0
150.18.0.0/24 is subnetted, 6 subnets
O 150.18.4.0 [80/782] via 174.18.234.4, 02:23:04, Serial1/0
D 150.18.5.0 [90/156160] via 174.18.0.5, 02:59:03, FastEthernet0/1
D 150.18.6.0 [90/156160] via 174.18.0.6, 02:59:04, FastEthernet0/1
D EX 150.18.1.0 [170/156160] via 174.18.123.1, 02:25:48, FastEthernet0/0
O 150.18.2.0 [80/782] via 174.18.234.2, 02:23:04, Serial1/0
C 150.18.3.0 is directly connected, Loopback0
O E2 205.90.31.0/24 [160/20] via 174.18.234.4, 02:22:45, Serial1/0

So we come up with (mostly) optimal redistribution configuration for our topology. What we learned so far, is that Split-horizon rule may also be implemented using the Administrative Disatnces. EIGRP implements this extremely useful feature automatically, while OSPF should be manually tuned for that. However, as we will learn in further examples, some additional work is needed for RIP. Also, now we remember that redistribution is non-transitive on local router. Finally, we learned a way to introduce a kind of hierarchy of administrative distances for a star-like routing domain topology (core transit domain, and stub edge domains). More complicated examples are to follow this post.

Subscribe to INE Blog Updates