Jun
24

Update: Redistribution case studies are now available in the workbook starting here.  More will be added to the list before class tomorrow.

If you're not already an All Access Pass member then you can sign up here for a free trial here.  AAP access includes not only access to the live RSv5 ATC class I'm currently running and the streaming playlist of the RSv5 ATC, but also include streaming access to our entire video library of literally thousands of hours of content - and growing.

The direct URL for live class tomorrow is http://live.ine.com. Remember the big advantage of attending the class live is that you get to ask me questions in real-time.  I hope to see you there!

 

 

Tomorrow class session for CCIE RSv5 ATC has been rescheduled to Thursday June 26th at 08:00 PDT (15:00 UTC).  This class session is going to focus on redistribution case studies.  The reason for the off class day tomorrow is as follows.

I'm currently in the process of adding a new section the the CCIE RSv5 Workbook on Redistribution.  Tomorrow you will see the new section be posted here:

The class session on Thursday will be open to all attendees. I will be reviewing the case studies posted here and talking about what the problems are, and what their specific resolutions will be.  This means that if you want to follow along with the class live, you can use the diagrams and initial configs that will be posted to this new workbook session in order to do so.

I'll post another update tomorrow with the specific links to the redistribution labs and the links to the class on Thursday.

In the meantime new videos have been added to the RSv5 ATC playlist and can be found here.  I hope to see you in class on Thursday!

 

 

 

 

Apr
04

Hi Brian,

What is the major difference in using an E1 route over an E2 route in OSPF?

From what I’ve observed, if you redistribute a route into OSPF either E1 or E2, the upstream router will still use the shortest path to get to the ASBR regardless of what is shown in the routing table.

The more I read about this, the more confused I get. Am I missing something?

Matt

Hi Matt,

This is actually a very common area of confusion and misunderstanding in OSPF. Part of the problem is that the vast majority of CCNA and CCNP texts teach the theory that for OSPF path selection of E1 vs E2 routes, E1 routes use the redistributed cost plus the cost to the ASBR, while with E2 routes only use the redistributed cost. When I just checked the most recent CCNP ROUTE text from Cisco Press, it specifically says that "[w]hen flooded, OSPF has little work to do to calculate the metric for an E2 route, because by definition, the E2 route’s metric is simply the metric listed in the Type 5 LSA. In other words, the OSPF routers do not add any internal OSPF cost to the metric for an E2 route." While technically true, this statement is an oversimplification. For CCNP level, this might be fine, but for CCIE level it is not.

The key point that I'll demonstrate in this post is that while it is true that "OSPF routers do not add any internal OSPF cost to the metric for an E2 route", both the intra-area and inter-area cost is still considered in the OSPF path selection state machine for these routes.

First, let's review the order of the OSPF path selection process. Regardless of a route’s metric or administrative distance, OSPF will choose routes in the following order:

Intra-Area (O)
Inter-Area (O IA)
External Type 1 (E1)
External Type 2 (E2)
NSSA Type 1 (N1)
NSSA Type 2 (N2)

To demonstrate this, take the following topology:

R1 connects to R2 and R3 via area 0. R2 and R3 connect to R4 and R5 via area 1 respectively. R4 and R5 connect to R6 via another routing domain, which is EIGRP in this case. R6 advertises the prefix 10.1.6.0/24 into EIGRP. R4 and R5 perform mutual redistribution between EIGRP and OSPF with the default parameters, as follows:

R4:
router eigrp 10
redistribute ospf 1 metric 100000 100 255 1 1500
!
router ospf 1
redistribute eigrp 10 subnets

R5:
router eigrp 10
redistribute ospf 1 metric 100000 100 255 1 1500
!
router ospf 1
redistribute eigrp 10 subnets

The result of this is that R1 learns the prefix 10.1.6.0/24 as an OSPF E2 route via both R2 and R3, with a default cost of 20. This can be seen in the routing table output below. The other OSPF learned routes are the transit links between the routers in question.

R1#sh ip route ospf
10.0.0.0/24 is subnetted, 8 subnets
O E2 10.1.6.0 [110/20] via 10.1.13.3, 00:09:43, FastEthernet0/0.13
[110/20] via 10.1.12.2, 00:09:43, FastEthernet0/0.12
O IA 10.1.24.0 [110/2] via 10.1.12.2, 00:56:44, FastEthernet0/0.12
O E2 10.1.46.0 [110/20] via 10.1.13.3, 00:09:43, FastEthernet0/0.13
[110/20] via 10.1.12.2, 00:09:43, FastEthernet0/0.12
O IA 10.1.35.0 [110/2] via 10.1.13.3, 00:56:44, FastEthernet0/0.13
O E2 10.1.56.0 [110/20] via 10.1.13.3, 00:09:43, FastEthernet0/0.13
[110/20] via 10.1.12.2, 00:09:43, FastEthernet0/0.12

Note that all the routes redistributed from EIGRP appear on R1 with a default metric of 20. Now let’s examine the details of the route 10.1.6.0/24 on R1.

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
Last update from 10.1.13.3 on FastEthernet0/0.13, 00:12:03 ago
Routing Descriptor Blocks:
10.1.13.3, from 10.1.5.5, 00:12:03 ago, via FastEthernet0/0.13
Route metric is 20, traffic share count is 1
* 10.1.12.2, from 10.1.4.4, 00:12:03 ago, via FastEthernet0/0.12
Route metric is 20, traffic share count is 1

As expected, the metric of both paths via R2 and R3 have a metric of 20. However, there is an additional field in the route’s output called the “forward metric”. This field denotes the cost to the ASBR(s). In this case, the ASBRs are R4 and R5 for the routes via R2 and R3 respectively. Since all interfaces are FastEthernet, with a default OSPF cost of 1, the cost to both R4 and R5 is 2, or essentially 2 hops.

The reason that multiple routes are installed in R1’s routing table is that the route type (E2), the metric (20), and the forward metric (2) are all a tie. If any of these fields were to change, the path selection would change.

To demonstrate this, let’s change the route type to E1 under R4’s OSPF process. This can be accomplished as follows:

R4#config t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric-type 1
R4(config-router)#end
R4#

The result of this change is that R1 now only installs a single route to 10.1.6.0/24, the E1 route learned via R2.

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
Known via "ospf 1", distance 110, metric 22, type extern 1
Last update from 10.1.12.2 on FastEthernet0/0.12, 00:00:35 ago
Routing Descriptor Blocks:
* 10.1.12.2, from 10.1.4.4, 00:00:35 ago, via FastEthernet0/0.12
Route metric is 22, traffic share count is 1

Note that the metric and the forward metric seen in the previous E2 route is now collapsed into the single “metric” field of the E1 route. Although the value is technically the same, a cost of 2 to the ASBR, and the cost of 20 the ASBR reports in, the E1 route is preferred over the E2 route due to the OSPF path selection state machine preference. Even if we were to raise the metric of the E1 route so that the cost is higher than the E2 route, the E1 route would be preferred:

R4#config t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric-type 1 metric 100
R4(config-router)#end
R4#

R1 still installs the E1 route, even though the E1 metric of 102 is higher than the E2 metric of 20 plus a forward metric of 2.

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
Known via "ospf 1", distance 110, metric 102, type extern 1
Last update from 10.1.12.2 on FastEthernet0/0.12, 00:00:15 ago
Routing Descriptor Blocks:
* 10.1.12.2, from 10.1.4.4, 00:00:15 ago, via FastEthernet0/0.12
Route metric is 102, traffic share count is 1

R1 still knows about both the E1 and the E2 route in the Link-State Database, but the E1 route must always be preferred:

R1#show ip ospf database external 10.1.6.0

OSPF Router with ID (10.1.1.1) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA
LS age: 64
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.1.6.0 (External Network Number )
Advertising Router: 10.1.4.4
LS Seq Number: 80000003
Checksum: 0x1C8E
Length: 36
Network Mask: /24
Metric Type: 1 (Comparable directly to link state metric)
TOS: 0
Metric: 100
Forward Address: 0.0.0.0
External Route Tag: 0

LS age: 1388
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.1.6.0 (External Network Number )
Advertising Router: 10.1.5.5
LS Seq Number: 80000001
Checksum: 0x7307
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0

This is the behavior we would expect, because E1 routes must always be preferred over E2 routes. Now let’s look at some of the commonly misunderstood cases, where the E2 routes use both the metric and the forward metric for their path selection.

First, R4’s redistribution is modified to return the metric-type to E2, but to use a higher metric of 100 than the default of 20:

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric-type 2 metric 100
R4(config-router)#end
R4#

The result on R1 is that the route via R4 is less preferred, since it now has a metric of 100 (and still a forward metric of 2) vs the metric of 20 (and the forward metric of 2) via R5.

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
Last update from 10.1.13.3 on FastEthernet0/0.13, 00:00:30 ago
Routing Descriptor Blocks:
* 10.1.13.3, from 10.1.5.5, 00:00:30 ago, via FastEthernet0/0.13
Route metric is 20, traffic share count is 1

The alternate route via R4 can still be seen in the database.

R1#show ip ospf database external 10.1.6.0

OSPF Router with ID (10.1.1.1) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA
LS age: 34
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.1.6.0 (External Network Number )
Advertising Router: 10.1.4.4
LS Seq Number: 80000004
Checksum: 0x9D8B
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 100
Forward Address: 0.0.0.0
External Route Tag: 0

Routing Bit Set on this LSA
LS age: 1653
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.1.6.0 (External Network Number )
Advertising Router: 10.1.5.5
LS Seq Number: 80000001
Checksum: 0x7307
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0

This is the path selection that we would ideally want, because the total cost of the path via R4 is 102 (metric of 100 plus a forward metric of 2), while the cost of the path via R5 is 22 (metric of 20 plus a forward metric of 2). The result of this path selection would be the same if we were to change both routes to E1, as seen below.

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric-type 1 metric 100
R4(config-router)#end
R4#

R5#config t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#router ospf 1
R5(config-router)#redistribute eigrp 10 subnets metric-type 1
R5(config-router)#end
R5#

R1 still chooses the route via R5, since this has a cost of 22 vs R4’s cost of 102.

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
Known via "ospf 1", distance 110, metric 22, type extern 1
Last update from 10.1.13.3 on FastEthernet0/0.13, 00:00:41 ago
Routing Descriptor Blocks:
* 10.1.13.3, from 10.1.5.5, 00:00:41 ago, via FastEthernet0/0.13
Route metric is 22, traffic share count is 1

R1#show ip ospf database external 10.1.6.0

OSPF Router with ID (10.1.1.1) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA
LS age: 56
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.1.6.0 (External Network Number )
Advertising Router: 10.1.4.4
LS Seq Number: 80000005
Checksum: 0x1890
Length: 36
Network Mask: /24
Metric Type: 1 (Comparable directly to link state metric)
TOS: 0
Metric: 100
Forward Address: 0.0.0.0
External Route Tag: 0

Routing Bit Set on this LSA
LS age: 45
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.1.6.0 (External Network Number )
Advertising Router: 10.1.5.5
LS Seq Number: 80000003
Checksum: 0xEB0D
Length: 36
Network Mask: /24
Metric Type: 1 (Comparable directly to link state metric)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0

R1#

Note that the E1 route itself in the database does not include the cost to the ASBR. This must be calculated separately either based on the Type-1 LSA or Type-4 LSA, depending on whether the route to the ASBR is Intra-Area or Inter-Area respectively.

So now this begs the question, why does it matter if we use E1 vs E2? Of course as we saw E1 is always preferred over E2, due to the OSPF path selection order, but what is the difference between having *all* E1 routes vs having *all* E2 routes? Now let’s at a case where it *does* matter if you’re using E1 vs E2.

R1’s OSPF cost on the link to R2 is increased as follows:

R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface Fa0/0.12
R1(config-subif)#ip ospf cost 100
R1(config-subif)#end
R1#

R4 and R5’s redistribution is modified as follows:

R4#config t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric-type 1 metric 99
R4(config-router)#end
R4#

R5#config t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#router ospf 1
R5(config-router)#redistribute eigrp 10 subnets metric-type 1 metric 198
R5(config-router)#end
R5#

Now R1’s routes to the prefix 10.1.6.0/24 are as follows: Path 1 via the link to R2 with a cost of 100, plus the link to R4 with a cost of 1, plus the redistributed metric of 99, making this total path a cost of 200. Next, Path 2 is available via the link to R3 with a cost of 1, plus the link to R5 with a cost of 1, plus the redistributed metric of 198, masking this total path a cost of 200 as well. The result is that R1 installs both paths equally:

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
Known via "ospf 1", distance 110, metric 200, type extern 1
Last update from 10.1.12.2 on FastEthernet0/0.12, 00:02:54 ago
Routing Descriptor Blocks:
* 10.1.13.3, from 10.1.5.5, 00:02:54 ago, via FastEthernet0/0.13
Route metric is 200, traffic share count is 1
10.1.12.2, from 10.1.4.4, 00:02:54 ago, via FastEthernet0/0.12
Route metric is 200, traffic share count is 1

Note that the database lists the costs of the Type-5 External LSAs as different though:

R1#show ip ospf database external 10.1.6.0

OSPF Router with ID (10.1.1.1) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA
LS age: 291
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.1.6.0 (External Network Number )
Advertising Router: 10.1.4.4
LS Seq Number: 80000006
Checksum: 0xC9C
Length: 36
Network Mask: /24
Metric Type: 1 (Comparable directly to link state metric)
TOS: 0
Metric: 99
Forward Address: 0.0.0.0
External Route Tag: 0

Routing Bit Set on this LSA
LS age: 207
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.1.6.0 (External Network Number )
Advertising Router: 10.1.5.5
LS Seq Number: 80000004
Checksum: 0xE460
Length: 36
Network Mask: /24
Metric Type: 1 (Comparable directly to link state metric)
TOS: 0
Metric: 198
Forward Address: 0.0.0.0
External Route Tag: 0

What happens if we were to change the metric-type to 2 on both R4 and R5 now? Let’s see:

R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric-type 2 metric 99
R4(config-router)#end
R4#

R5#config t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#router ospf 1
R5(config-router)#redistribute eigrp 10 subnets metric-type 2 metric 198
R5(config-router)#end
R5#

Even though the end-to-end costs are still the same, R1 should now prefer the path with the lower redistributed metric via R4:

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
Known via "ospf 1", distance 110, metric 99, type extern 2, forward metric 101
Last update from 10.1.12.2 on FastEthernet0/0.12, 00:01:09 ago
Routing Descriptor Blocks:
* 10.1.12.2, from 10.1.4.4, 00:01:09 ago, via FastEthernet0/0.12
Route metric is 99, traffic share count is 1

The forward metric of this route means that the total cost is still 200 (the metric of 99 plus the forward metric of 101). In this case, even though both paths are technically equal, only the path with the lower redistribution metric is installed. Now let’s see what happens if we do set the redistribution metric the same.

R4#config t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric-type 2 metric 1
R4(config-router)#end
R4#

R5#config t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#router ospf 1
R5(config-router)#redistribute eigrp 10 subnets metric-type 2 metric 1
R5(config-router)#end
R5#

Both routes now have the same metric of 1, so both should be installed in R1’s routing table, right? Let’s check:

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
Known via "ospf 1", distance 110, metric 1, type extern 2, forward metric 2
Last update from 10.1.13.3 on FastEthernet0/0.13, 00:00:42 ago
Routing Descriptor Blocks:
* 10.1.13.3, from 10.1.5.5, 00:00:42 ago, via FastEthernet0/0.13
Route metric is 1, traffic share count is 1

This is the result we may not expect. Only the path via R5 is installed, not the path via R4. Let’s look at the database and see why:

R1#show ip ospf database external 10.1.6.0

OSPF Router with ID (10.1.1.1) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA
LS age: 56
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.1.6.0 (External Network Number )
Advertising Router: 10.1.4.4
LS Seq Number: 80000008
Checksum: 0xB3D4
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 0

Routing Bit Set on this LSA
LS age: 47
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.1.6.0 (External Network Number )
Advertising Router: 10.1.5.5
LS Seq Number: 80000006
Checksum: 0xAADD
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 0

Both of these routes show the same cost, as denoted by the “Metric: 1”, so why is one being chosen over the other? The reason is that in reality, OSPF External Type-2 (E2) routes *do* take the cost to the ASBR into account during route calculation. The problem though is that by looking at just the External LSA’s information, we can’t see why we’re choosing one over the other.

Now let’s go through the entire recursion process in the database to figure out why R1 is choosing the path via R5 over the path to R4.

First, as we saw above, R1 finds both routes to the prefix with a metric of 1. Since this is a tie, the next thing R1 does is determine if the route to the ASBR is via an Intra-Area path. This is done by looking up the Type-1 Router LSA for the Advertising Router field found in the Type-5 External LSA.

R1#show ip ospf database router 10.1.4.4

OSPF Router with ID (10.1.1.1) (Process ID 1)
R1#show ip ospf database router 10.1.5.5

OSPF Router with ID (10.1.1.1) (Process ID 1)
R1#

This output on R1 means that it does not have an Intra-Area path to either of the ASBRs advertising these routes. The next step is to check if there is an Inter-Area path. This is done by examining the Type-4 ASBR Summary LSA.

R1#show ip ospf database asbr-summary 10.1.4.4

OSPF Router with ID (10.1.1.1) (Process ID 1)

Summary ASB Link States (Area 0)

Routing Bit Set on this LSA
LS age: 1889
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 10.1.4.4 (AS Boundary Router address)
Advertising Router: 10.1.2.2
LS Seq Number: 80000002
Checksum: 0x24F3
Length: 28
Network Mask: /0
TOS: 0 Metric: 1

R1#show ip ospf database asbr-summary 10.1.5.5

OSPF Router with ID (10.1.1.1) (Process ID 1)

Summary ASB Link States (Area 0)

Routing Bit Set on this LSA
LS age: 1871
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 10.1.5.5 (AS Boundary Router address)
Advertising Router: 10.1.3.3
LS Seq Number: 80000002
Checksum: 0x212
Length: 28
Network Mask: /0
TOS: 0 Metric: 1

This output indicates that R1 does have Inter-Area routes to the ASBRs R4 and R5. The Inter-Area metric to reach them is 1 via ABRs R2 (10.1.2.2) and R3 (10.1.3.3) respectively. Now R1 needs to know which ABR is closer, R2 or R3? This is accomplished by looking up the Type-1 Router LSA to the ABRs that are originating the Type-4 ASBR Summary LSAs.

R1#show ip ospf database router 10.1.2.2

OSPF Router with ID (10.1.1.1) (Process ID 1)

Router Link States (Area 0)

Routing Bit Set on this LSA
LS age: 724
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.1.2.2
Advertising Router: 10.1.2.2
LS Seq Number: 8000000D
Checksum: 0xA332
Length: 36
Area Border Router
Number of Links: 1

Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.12.2
(Link Data) Router Interface address: 10.1.12.2
Number of TOS metrics: 0
TOS 0 Metrics: 1

R1#show ip ospf database router 10.1.3.3

OSPF Router with ID (10.1.1.1) (Process ID 1)

Router Link States (Area 0)

Routing Bit Set on this LSA
LS age: 1217
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.1.3.3
Advertising Router: 10.1.3.3
LS Seq Number: 80000010
Checksum: 0x9537
Length: 36
Area Border Router
Number of Links: 1

Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.13.1
(Link Data) Router Interface address: 10.1.13.3
Number of TOS metrics: 0
TOS 0 Metrics: 1

This output indicates that R2 and R3 are adjacent with the Designated Routers 10.1.12.2 and 10.1.13.3 respectively. Since R1 is also adjacent with these DRs, the cost from R1 to the DR is now added to the path.

R1#show ip ospf database router 10.1.1.1

OSPF Router with ID (10.1.1.1) (Process ID 1)

Router Link States (Area 0)

LS age: 948
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.1.1.1
Advertising Router: 10.1.1.1
LS Seq Number: 8000000F
Checksum: 0x6FA6
Length: 60
Number of Links: 3

Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.1.1.1
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1

Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.13.1
(Link Data) Router Interface address: 10.1.13.1
Number of TOS metrics: 0
TOS 0 Metrics: 1

Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.12.2
(Link Data) Router Interface address: 10.1.12.1
Number of TOS metrics: 0
TOS 0 Metrics: 100

R1 now knows that its cost to the DR 10.1.12.2 is 100, who is adjacent with R2, whose cost to R4 is 1, whose redistributed metric is 1. R1 also now knows that its cost to the DR 10.1.13.3 is 1, who is adjacent with R3, whose cost to R5 is 1, whose redistributed metric is 1. This means that the total cost to go to 10.1.6.0 via the R1 -> R2 -> R4 path is 102, while the total cost to go to 10.1.6.0 via the R1 -> R3 -> R5 path is 3.

The final result of this is that R1 chooses the shorter path to the ASBR, which is the R1 -> R3 -> R5 path. Although the other route to the prefix is via an E2 route with the same external cost, one is preferred over another due to the shorter ASBR path.

Based on this we can see that both E1 and E2 routes take both the redistributed cost and the cost to the ASBR into account when making their path selection. The key difference is that E1 is always preferred over E2, followed by the E2 route with the lower redistribution metric. If multiple E2 routes exist with the same redistribution metric, the path with the lower forward metric (metric to the ASBR) is preferred. If there are multiple E2 routes with both the same redistribution metric and forward metric, they can both be installed in the routing table. Why does OSPF do this though? Originally this stems from the design concepts of "hot potato" and "cold potato" routing.

Think of a routing domain learning external routes. Typically those prefixes have some "external" metric associated with them - for example, E2 external metric or the BGP MED attribute value. If the routers in the local domain select the exit point based on the external metric they are said to perform "cold potato" routing. This means that the exit point is selected based on the external metric preference, e.g. distances to the prefix in the bordering routing system. This optimizes link utilization in the external system but may lead to suboptimal path selection in the local domain. Conversely, "hot potato" routing is the model where the exit point selection is performed based on the local metric to the exit point associated with the prefix. In other words, "hot potato" model tries to push packets out of the local system as quick as possible, optimizing internal link utilization.

Now within the scope of OSPF, think of the E2 route selection process: OSPF chooses the best exit point based on the external metric and uses the internal cost to ASBR as a tie breaker. In other words, OSPF performs "cold potato" routing with respect to E2 prefixes. It is easy to turn this process into "hot potato" by ensuring that every exit point uses the same E2 metric value. It is also possible to perform other sorts of traffic engineering by selectively manipulating the external metric associated with the E2 route, allowing for full flexibility of exit point selection.

Finally, we approach E1. This type of routing is a hybrid of hot and cold routing models - external metrics are directly added to the internal metrics. This implicitly assumes that external metrics are "comparable" to the internal metrics. In turn, this means E1 is meant to be used with another OSPF domain that uses a similar metric system. This is commonly found in split/merge scenarios where you have multiple routing processes within the same autonomous system, and want to achieve optimum path selection accounting for both metrics in both systems. This is similar to the way EIGRP performs metric computation for external prefixes.

So there we have it. While it is technically true that "OSPF routers do not add any internal OSPF cost to the metric for an E2 route", both the intra-area and inter-area cost can still be considered in the OSPF path selection regardless of whether the route is E1 or E2.

Aug
30

One of the most popular series on this blog site is the Redistribution series by Petr Lapukhov.

I wanted to share a document that helped one of my recent, incredibly dedicated, 12 Day Bootcamp students, Sean Coetzee. Thanks for sharing Sean!

Redistributing Routing Protocols

http://www.cisco.com/application/pdf/paws/8606/redist.pdf

Feb
15

The leading question:

"Is it possible (and if so, how) to redistribute or originate a default route based on time of day?"

The short answer is "Sure, why not?"...  But the longer answer has to do with how do we warp the forces of the universe to make that happen???

Well, start with what we know.  We know we can do time-ranges in access-lists, right?  Can we do them in standard access-lists (what we see used for redistribution all the time)?

Rack1R1(config-if)#exit
Rack1R1(config)#access-list 1 permit 172.16.0.0 0.15.255.255 ?
log  Log matches against this entry
<cr>

Rack1R1(config)#

Nope.  There's a bummer.  So we will need to use EXTENDED ACL's in order to make this work.  So now we are reaching the point of "Yes, it can be done, but it will make my head hurt." as the answer.   :)

First, as a little review, check out a blog we did last year providing some information on that sort of thing in conjunction with a distribute-list in different routing protocols.

http://blog.internetworkexpert.com/2008/01/04/using-extended-access-lists-in-a-distribute-list/

After you've had a little time to review that stuff, let's move on with the testing! I have nabbed my routers in a configured state already. I just recently finished with creating more detailed solutions for Mock Lab 4 (it's a fun one!), so that's the topology that I have going right now. Specifics should really matter, I was just hunting for any particular spot of redistribution in order to see what we could accomplish here.

On R3 I happen to have found some redistribution between OSPF and RIP that looks like fun.

R3 Starting:

Rack1R3(config)#do sh run | s router
router ospf 1
log-adjacency-changes
area 0 authentication message-digest
area 123 virtual-link 150.1.1.1 message-digest-key 1 md5 CISCO
redistribute rip metric-type 1 subnets route-map Red-RIP
network 145.1.3.3 0.0.0.0 area 0
network 145.1.13.3 0.0.0.0 area 123
network 145.1.23.3 0.0.0.0 area 123
network 150.1.3.3 0.0.0.0 area 0
router rip
version 2
redistribute ospf 1 metric 7 route-map RIP-R6
passive-interface default
no passive-interface FastEthernet0/0
network 145.1.0.0
distribute-list 11 out FastEthernet0/0
no auto-summary
Rack1R3(config)#

Rack1R3(config)#do sh run | s route-map
redistribute rip metric-type 1 subnets route-map Red-RIP
redistribute ospf 1 metric 7 route-map RIP-R6
route-map RIP-R6 permit 10
match ip address prefix-list R4-R5-Link
set metric 2
route-map RIP-R6 permit 20
set metric 10
route-map Red-RIP deny 10
match ip address prefix-list NAT-Route
route-map Red-RIP permit 20
set metric-type type-1
Rack1R3(config)#

All devices have "debug ip routing" turned on.

Rack1R3(config)#do sh clock
*02:02:28.984 UTC Sun Feb 15 2009
Rack1R3(config)#

No NTP is running, so we can deal with the current clock settings.   So let's look at our route-maps...  The one called RIP-R6 is going from OSPF to RIP.

Rack1R3(config)#do sh ip ro os
51.0.0.0/32 is subnetted, 1 subnets
O E2    51.51.51.51 [110/20] via 145.1.23.2, 3w2d, Serial1/3.23
O E1 204.12.1.0/24 [110/865] via 145.1.23.2, 1w6d, Serial1/3.23
[110/865] via 145.1.13.1, 1w6d, Serial1/2.13
145.1.0.0/16 is variably subnetted, 20 subnets, 2 masks
O IA    145.1.17.0/24 [110/782] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.5.0/24 [110/865] via 145.1.23.2, 1w6d, Serial1/3.23
[110/865] via 145.1.13.1, 1w6d, Serial1/2.13
O       145.1.7.0/24 [110/783] via 145.1.13.1, 3w2d, Serial1/2.13
O       145.1.12.0/24 [110/845] via 145.1.23.2, 3w2d, Serial1/3.23
[110/845] via 145.1.13.1, 3w2d, Serial1/2.13
O       145.1.48.0/24 [110/847] via 145.1.23.2, 3w2d, Serial1/3.23
[110/847] via 145.1.13.1, 3w2d, Serial1/2.13
O IA    145.1.58.0/24 [110/846] via 145.1.23.2, 3w2d, Serial1/3.23
[110/846] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.45.5/32 [110/867] via 145.1.23.2, 3w2d, Serial1/3.23
[110/867] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.45.4/32 [110/865] via 145.1.23.2, 3w2d, Serial1/3.23
[110/865] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.45.0/24 [110/865] via 145.1.23.2, 3w2d, Serial1/3.23
[110/865] via 145.1.13.1, 3w2d, Serial1/2.13
O       145.1.47.0/24 [110/1782] via 145.1.13.1, 3w2d, Serial1/2.13
O IA    145.1.125.5/32 [110/845] via 145.1.23.2, 3w2d, Serial1/3.23
[110/845] via 145.1.13.1, 3w2d, Serial1/2.13
O IA    145.1.125.1/32 [110/781] via 145.1.13.1, 3w2d, Serial1/2.13
O E1    145.1.125.0/24 [110/867] via 145.1.23.2, 1w6d, Serial1/3.23
[110/867] via 145.1.13.1, 1w6d, Serial1/2.13
O IA    145.1.125.2/32 [110/781] via 145.1.23.2, 3w2d, Serial1/3.23
O IA 192.10.1.0/24 [110/782] via 145.1.23.2, 3w2d, Serial1/3.23
150.1.0.0/16 is variably subnetted, 7 subnets, 3 masks
O       150.1.7.7/32 [110/783] via 145.1.13.1, 3w2d, Serial1/2.13
O       150.1.4.4/32 [110/848] via 145.1.23.2, 3w2d, Serial1/3.23
[110/848] via 145.1.13.1, 3w2d, Serial1/2.13
O       150.1.2.2/32 [110/782] via 145.1.23.2, 3w2d, Serial1/3.23
O       150.1.1.1/32 [110/782] via 145.1.13.1, 3w2d, Serial1/2.13
O IA    150.1.0.0/20 [110/846] via 145.1.23.2, 3w2d, Serial1/3.23
[110/846] via 145.1.13.1, 3w2d, Serial1/2.13
Rack1R3(config)#

We have quite a few OSPF routes, so we can always pick on a few others just to play.   But let's change things around momentarily.

Rack1R3(config)#do sh run | in prefix-list
ip prefix-list NAT-Route seq 5 permit 145.1.133.0/24
ip prefix-list R4-R5-Link seq 5 permit 145.1.45.0/24
match ip address prefix-list R4-R5-Link
match ip address prefix-list NAT-Route
Rack1R3(config)#

Right now, we're matching a Prefix List...  That will need to change.  Let's create a time-range as well.

R3

time-range First12
periodic daily 0:00 to 11:59
exit

access-list 101 permit ip host 145.1.45.0 host 255.255.255.0 time-range First12

route-map RIP-R6 permit 10
no match ip address prefix-list R4-R5-Link
match ip address 101
set metric 2

Rack1R3(config)#do sh access-list 101
Extended IP access list 101
10 permit ip host 145.1.45.0 host 255.255.255.0 time-range First12 (active) (2 matches)
Rack1R3(config)#

So we're active now.  This is good.   We'll see this route via other paths in this lab, but the metric here is the key.  And we'll notice this change as well.  Since we started re-advertising the route:

Rack1R6(config-router)#
*Feb 15 03:17:13.656: RT: rip's 145.1.45.0/24 (via 145.1.36.3) metric changed from distance/metric [120/10] to [120/2]
*Feb 15 03:17:13.656: RT: NET-RED 145.1.45.0/24
Rack1R6(config-router)#

Notice the metric change.   Now let's go back to R3 and change the time!

Rack1R3#clock set 15:00:00 feb 15 2009
Rack1R3#
*Feb 15 15:00:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 02:22:08 UTC Sun Feb 15 2009 to 15:00:00 UTC Sun Feb 15 2009, configured from console by console.
Rack1R3#

Rack1R3(config)#do sh access-list 101
Extended IP access list 101
10 permit ip host 145.1.45.0 host 255.255.255.0 time-range First12 (inactive) (2 matches)
Rack1R3(config)#

Notice that now we are inactive on our time.     **Time Passes**

Well, 20 minutes later and still no update.   Our problem with this is that change IN THE ROUTING TABLE trigger changes to redistribution.  We still learn this route via OSPF and therefore nothing has changed.  If we were to trigger a change in OSPF that would lead to a status change, we would see the route withdrawn.

How do you trigger a status change?  Clear it.

Rack1R3(config)#do clear ip route 145.1.45.0
Rack1R3(config)#
Feb 15 15:12:28.719: RT: del 145.1.45.0/24 via 145.1.23.2, ospf metric [110/865]
Feb 15 15:12:28.719: RT: del 145.1.45.0/24 via 145.1.13.1, ospf metric [110/865]
Feb 15 15:12:28.719: RT: delete subnet route to 145.1.45.0/24
Feb 15 15:12:28.719: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.723: RT: SET_LAST_RDB for 145.1.45.0/24
NEW rdb: via 145.1.13.1

Feb 15 15:12:28.723: RT: add 145.1.45.0/24 via 145.1.13.1, ospf metric [110/867]
Feb 15 15:12:28.723: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.723: RT: add 145.1.45.0/24 via 145.1.23.2, ospf metric [110/867]
Feb 15 15:12:28.723: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.723: RT:ospf's 145.1.45.0/24 (via 145.1.13.1) metric changed from distance/metric [110/867] to [110/865]
Feb 15 15:12:28.723: RT: del 145.1.45.0/24 via 145.1.23.2, ospf metric [110/867]
Feb 15 15:12:28.723: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.723: RT: NET-RED 145.1.45.0/24
Feb 15 15:12:28.727: RT: add 145.1.45.0/24 via 145.1.23.2, ospf metric [110/865]
Feb 15 15:12:28.727: RT: NET-RED 145.1.45.0/24
Rack1R3(config)#

From R3's perspective, notice that it comes back just as it was before.

Rack1R6(config-router)#
*Feb 15 03:32:27.576: RT: rip's 145.1.45.0/24 (via 145.1.36.3) metric changed from distance/metric [120/2] to [120/10]
*Feb 15 03:32:27.576: RT: NET-RED 145.1.45.0/24
Rack1R6(config-router)#

On R6 though, it changed because the criteria changed.   What if we change the clock and do it again?  (By the way, subsequent 'clear ip route' commands on R3 make no difference on R6 as long as the time range is still inactive)

Rack1R3(config)#do clock set 3:00:00 feb 15 2009
Rack1R3(config)#
Rack1R3(config)#
Feb 15 03:00:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 15:14:57 UTC Sun Feb 15 2009 to 03:00:00 UTC Sun Feb 15 2009, configured from console by console.
Rack1R3(config)#
Rack1R3(config)#do sh access-list 101
Extended IP access list 101
10 permit ip host 145.1.45.0 host 255.255.255.0 time-range First12 (active) (2 matches)
Rack1R3(config)#

Back to active now.  Clearing....

Rack1R6(config-router)#
*Feb 15 03:35:24.672: RT: rip's 145.1.45.0/24 (via 145.1.36.3) metric changed from distance/metric [120/10] to [120/2]
*Feb 15 03:35:24.672: RT: NET-RED 145.1.45.0/24
Rack1R6(config-router)#

Back to a metric of 2 on R6.  So the redistribution is happening again...  So....  Can the router trigger itself?  Do we have mechanisms to do so?  You betchya!  But it's not perfectly simple!   But then again, you would be a CCIE if everything were always simple!  Or more importantly, EVERYONE would be a CCIE if it were simple!

We can use EEM (Embedded Event Manager, complicated) or KRON (time scheduler, easier) to trigger things.   My vote is kron!  In the unix world you'd know this as cron.

R3

kron policy-list ChgRedist
cli clear ip route 145.1.45.0
exit

kron occurrence Midnight at 0:00 recurring
policy-list ChgRedist
kron occurrence Noon at 12:00 recurring
policy-list ChgRedist
exit

Rack1R3(config)#do sh kron schedule
Kron Occurrence Schedule
Midnight inactive, will run again in 0 days 20:55:41 at 0 :00 on
Noon inactive, will run again in 0 days 08:55:41 at 12:00 on

Rack1R3(config)#

Rack1R3(config)#do clock set 11:58:00 feb 15 2009
Feb 15 11:58:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 03:05:50 UTC Sun Feb 15 2009 to 11:58:00 UTC Sun Feb 15 2009, configured from console by console.
Rack1R3(config)#do sh kron schedule
Kron Occurrence Schedule
Midnight inactive, will run again in 0 days 12:01:55 at 0 :00 on
Noon inactive, will run again in 0 days 00:01:55 at 12:00 on

Rack1R3(config)#

Rack1R3(config)#do deb kron all
All kron debug flags are on

Rack1R3(config)#

Now we just wait and see!  (Pretend you've been staring at this for two minutes now!)

Rack1R3(config)#
Feb 15 11:59:59.999: Major 1, Minor 0
Feb 15 11:59:59.999: Timer Event Noon
Feb 15 11:59:59.999: Kron delay for next Noon 60000
Feb 15 11:59:59.999: Call parse_cmd 'clear ip route 145.1.45.0'
Feb 15 11:59:59.999: RT: del 145.1.45.0/24 via 145.1.23.2, ospf metric [110/865]
Feb 15 11:59:59.999: RT: del 145.1.45.0/24 via 145.1.13.1, ospf metric [110/865]
Feb 15 11:59:59.999: RT: delete subnet route to 145.1.45.0/24
Feb 15 11:59:59.999: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.003: Kron CLI return 0
''
Feb 15 12:00:00.003: Major 4, Minor 7
Feb 15 12:00:00.003: Respond to end of CLI Process
Feb 15 12:00:00.003: RT: SET_LAST_RDB for 145.1.45.0/24
NEW rdb: via 145.1.13.1

Rack1R3(config)#
Feb 15 12:00:00.003: RT: add 145.1.45.0/24 via 145.1.13.1, ospf metric [110/867]
Feb 15 12:00:00.003: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.003: RT: add 145.1.45.0/24 via 145.1.23.2, ospf metric [110/867]
Feb 15 12:00:00.003: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.003: RT: ospf's 145.1.45.0/24 (via 145.1.13.1) metric changed from distance/metric [110/867] to [110/865]
Feb 15 12:00:00.007: RT: del 145.1.45.0/24 via 145.1.23.2, ospf metric [110/867]
Feb 15 12:00:00.007: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.007: RT: NET-RED 145.1.45.0/24
Feb 15 12:00:00.007: RT: add 145.1.45.0/24 via 145.1.23.2, ospf metric [110/865]
Feb 15 12:00:00.007: RT: NET-RED 145.1.45.0/24
Rack1R3(config)#

That looks like the router magically did what we wanted it to on R3! And on R6:

Rack1R6(config-router)#
*Feb 15 03:43:46.695: RT: rip's 145.1.45.0/24 (via 145.1.36.3) metric changed from distance/metric [120/2] to [120/10]
*Feb 15 03:43:46.695: RT: NET-RED 145.1.45.0/24
Rack1R6(config-router)#

Bingo!  Exactly what you wanted.

Rack1R3(config)#do sh kron sched
Kron Occurrence Schedule
Midnight inactive, will run again in 0 days 11:58:24 at 0 :00 on
Noon inactive, will run again in 0 days 23:59:24 at 12:00 on

Rack1R3(config)#

And in 12 hours'ish we'll see the process reverse itself.  So yes, you CAN have redistribution on a timed basis, it's just not necessarily a pretty thing!

Jul
19

For the benefit of those who do not have access to the lab below is the task and the diagram:

4.11. IGP Redistribution
• Redistribute between RIP and OSPF on SW1.
• Redistribute between OSPF and EIGRP on R2, R3, and R4.
• Ensure that full reachability is maintained throughout the IGP domain when the Frame Relay circuit between R3 and R5 is down.

3 Points

First off this task is only worth 3 points but will take most people 45 minutes to 1 hour to complete due to the fact the requirements create a routing loop. This means that it's really not worth 3 points in the real lab due to the fact you're giving away 1 hour of your 8 hours for just 3 points. In the real lab most people would be better off just getting full IP reachability and moving on. Think about it like this. If you could give up 3 points in every lab and implement you own solution to obtain full IP reachability would you be better off?

When you run across a redistribution task in a lab your first goal is to determine what is the minimum redistribution needed to achieve full reachability. This is your "safety net" in the event you are not able to complete the task as required or do not have the time to fully complete the task as required. You can pass the lab without getting these 3 points but you can't really expect to pass the lab without having full IP reachability.

Since our first goal is just to determine what is needed to obtain full IP reachability lets look at this network and determine where we need to perform redistribution to achieve this. Obviously we must redistribute between RIP and OSPF on SW1 to provide reachability between the OSPF and RIP domains. Since this will be a single point of redistribution between RIP and OSPF and these protocols are only both run on one router (SW1) we will not have any problems. This means we can just redistribute RIP into OSPF, then OSPF into RIP and finally verify our redistribution by viewing the routing tables and doing some basic pinging. No tagging, filtering, distribute-list, etc is needed on SW1.

Once the RIP and OSPF redistribution is finished and verified we should then move onto the EIGRP and OSPF redistribution. Do not make the mistake of moving onto the EIGRP and OSPF redistribution without first verifying your RIP and OSPF redistribution. You must verify each stage of the network as it's built. If you wait until the end of the IGP section to test for full IP reachability it will be much harder to determine what the cause of the problems are. Think about it like this. If I gave you a network and told you to find 10 errors in it would it be easier to find the 10 errors after I've applied all of the configuration or would it be easier to check for the errors as I apply each part of the configuration? If you didn't answer the latter I would hope you never have aspirations on becoming an airline engine inspector ;-)

First off we need to determine what are the minimum points of redistribution needed between OSPF and EIGRP to obtain full IP reachability. Normally this is easy to determine but in this network we have a backup link being used. In the real lab we don't need to worry about redundancy or sub-optimal routing unless specified directly or indirectly. In this case we need to take redundancy into consideration since full IP reachability will need to be obtained when the network is in two different states. The first state is when the backup link is in the standby mode. The second state is when the backup interface is active due to the fact the primary link is down. In this case the backup link is the serial between R4 and R5 and the primary link is the Frame Relay connection between R3 and R5.

Now that we know what items to take into consideration for the EIGRP and OSPF redistribution we can determine that at a minimum EIGRP and OSPF will need to be redistributed on R4 and either R2 or R3. R4 is selected for redistribution because when the backup link is active it will need to provide connectivity between R5 and the rest of the network.

Where we start having problems is with the redistribution on R2 or R3 so lets look at what the problem is. OSPF routes going into EIGRP will not present a problem because once the OSPF routes are in EIGRP they will have a higher AD. Remember that the problems with redistribution occur when we take a higher AD protocol and then redistribute it into a lower AD protocol and finally attempt to redistribute it back into the original higher AD protocol (Higher->Lower->Higher). In this case the OSPF routes will have an AD of 170 when redistributed into EIGRP. Since the AD of EIGRP external is 170 these routes will not overtake the original OSPF routes. So lower AD protocol to higher AD protocol isn't a problem. For those who have always wondered why the external distance of EIGRP is 170 now you know ;-)

Now that we know we shouldn't have any problems with the OSPF routes going into EIGRP we next need to consider if we'll have any problems with EIGRP routes going into OSPF. By default EIGRP internal routes have an AD of 90 and an AD of 170 for external routes. This being the case we'll need to consider the higher->lower->higher problem for both types of routes (internal and external). For the internal EIGRP routes there won't be a problem since we will be going from a lower AD protocol to higher AD protocol. It's the external EIGRP routes that weren't originally OSPF routes. In this lab a previous task asked for the Ethernet segments (E0/0 and E0/1) on R5 to be redistributed into EIGRP. These are the routes which we will see that create the routing loop problem.

We should now be able to see what the problem is. It's the external EIGRP routes being redistributed into OSPF and then possibly back into EIGRP. This is because we have the higher->lower->higher situation. The higher (external EIGRP) going into a lower (OSPF) and finally back into a higher (external EIGRP).

To illustrate the problem I have mutual redistribution configured between EIGRP and OSPF on both R2 and R3. We can see from the output below that R2 and R3 can not reach R5's E0/0 interface but they can reach R5's Loopback0 interface. The only difference is the Loopback is an internal EIGRP route while the Ethernet is an external EIGRP route. This is exactly what we expected to happen.

Rack1R2#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

1 132.1.23.3 16 msec 17 msec 16 msec
2 132.1.0.2 36 msec 32 msec 36 msec
3 132.1.23.3 32 msec 32 msec 32 msec
4 132.1.0.2 52 msec 56 msec 52 msec
5 132.1.23.3 48 msec 48 msec 48 msec
6 132.1.0.2 68 msec 68 msec 68 msec
7 132.1.23.3 64 msec 68 msec 64 msec
8 132.1.0.2 88 msec 88 msec 84 msec
9 132.1.23.3 105 msec 96 msec 96 msec
10 132.1.0.2 120 msec 104 msec 101 msec
Rack1R2#
Rack1R2#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

1 132.1.23.3 16 msec 16 msec 16 msec
2 132.1.35.5 44 msec * 44 msec
Rack1R2#

Rack1R3#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

1 132.1.0.2 28 msec 32 msec 28 msec
2 * * *
3 132.1.0.2 44 msec 48 msec 44 msec
4 * * *
5 132.1.0.2 60 msec 64 msec 64 msec
6 * * *
7 132.1.0.2 76 msec 84 msec 81 msec
8 * * *
9 132.1.0.2 269 msec 128 msec *
10 * * *
Rack1R3#
Rack1R3#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

1 132.1.35.5 32 msec * 28 msec
Rack1R3#

Now that we know what the problem is we need to consider all of the possible solutions and implement the simplest solution. First off we could break this potential routing loop by just removing redistribution from R2. The output below shows the traceroutes from R2 and R3 to R5 when redistribution has been removed from R2.

Rack1R2#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

1 132.1.23.3 16 msec 16 msec 16 msec
2 132.1.35.5 44 msec * 60 msec
Rack1R2#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

1 132.1.0.3 28 msec 32 msec 28 msec
2 132.1.35.5 56 msec * 56 msec
Rack1R2#

Rack1R3#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

1 132.1.35.5 28 msec * 28 msec
Rack1R3#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

1 132.1.35.5 32 msec * 28 msec
Rack1R3#

It may seem like everything is working now but there is actually another problem that we need to resolve. R6 is not getting the external EIGRP routes originated by R5's.

Rack1R6#show ip route 132.1.5.0
% Subnet not in table
Rack1R6#show ip route 150.1.5.0
Routing entry for 150.1.5.0/24
Known via "eigrp 10", distance 90, metric 21154560, type internal
Redistributing via eigrp 10
Last update from 132.1.26.2 on FastEthernet0/0.26, 00:14:03 ago
Routing Descriptor Blocks:
* 132.1.26.2, from 132.1.26.2, 00:14:03 ago, via FastEthernet0/0.26
Route metric is 21154560, traffic share count is 1
Total delay is 45100 microseconds, minimum bandwidth is 128 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 5/255, Hops 3

Rack1R6#

So lets look back at the first router who should be receiving them and view it's routing table.

Rack1R3#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
Known via "eigrp 10", distance 170, metric 2560512256, type external
Redistributing via ospf 1, eigrp 10
Advertised by ospf 1 subnets
Last update from 132.1.35.5 on Serial1/1.1, 00:43:58 ago
Routing Descriptor Blocks:
* 132.1.35.5, from 132.1.35.5, 00:43:58 ago, via Serial1/1.1
Route metric is 2560512256, traffic share count is 1
Total delay is 20010 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1

Rack1R3#show ip route 150.1.5.0
Routing entry for 150.1.5.0/24
Known via "eigrp 10", distance 90, metric 20640000, type internal
Redistributing via ospf 1, eigrp 10
Advertised by ospf 1 subnets
Last update from 132.1.35.5 on Serial1/1.1, 20:48:19 ago
Routing Descriptor Blocks:
* 132.1.35.5, from 132.1.35.5, 20:48:19 ago, via Serial1/1.1
Route metric is 20640000, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 128 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 5/255, Hops 1

Rack1R3#

So R3 has them. Next lets go to R2 and view it's routing table.

Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 64
Last update from 132.1.0.3 on Serial0/0, 00:02:36 ago
Routing Descriptor Blocks:
* 132.1.0.3, from 150.1.3.3, 00:02:36 ago, via Serial0/0
Route metric is 20, traffic share count is 1

Rack1R2#show ip route 150.1.5.0
Routing entry for 150.1.5.0/24
Known via "eigrp 10", distance 90, metric 21152000, type internal
Redistributing via eigrp 10
Last update from 132.1.23.3 on Serial0/1, 21:14:51 ago
Routing Descriptor Blocks:
* 132.1.23.3, from 132.1.23.3, 21:14:51 ago, via Serial0/1
Route metric is 21152000, traffic share count is 1
Total delay is 45000 microseconds, minimum bandwidth is 128 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 5/255, Hops 2

Rack1R2#

R2 has the external EIGRP route (R5's Ethernet0/0) as an OSPF route and the internal EIGRP route (R5's Loopback0) still as an internal EIGRP route. This is what we expect to happen since the OSPF route has an AD of 110 and the external EIGRP route has an AD of 170. But why doesn't R6 get the 132.1.5.0/24 route? R6 doesn't get the route because EIGRP is not sending it due to the fact the route isn't in the routing table as an EIGRP route. This is important to understand so let me repeat it. When EIGRP goes to send an update to it's neighbors it selects the routes from the IP routing table and not the EIGRP topology table. This is the same behavior as RIP in that the route must be in the routing table as a RIP route or a connected route advertised by RIP before it can be sent. So what routes is EIGRP sending? It's going to send the directly connected routes that EIGRP is advertising from the network statement under the routing process and the dynamically learned EIGRP routes in the routing table. Of course it will not send the EIGRP routes from the routing table back out the same interface they were learned on due to split horizon. So this is why the 132.1.5.0/24 route does not get advertised onto R6 even though EIGRP has the route from R3 in it's topology table.

Rack1R2#show ip eigrp topology 132.1.5.0/24
IP-EIGRP (AS 10): Topology entry for 132.1.5.0/24
State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295
Routing Descriptor Blocks:
132.1.23.3 (Serial0/1), from 132.1.23.3, Send flag is 0x0
Composite metric is (2561024256/2560512256), Route is External
Vector metric:
Minimum bandwidth is 1 Kbit
Total delay is 40010 microseconds
Reliability is 1/255
Load is 1/255
Minimum MTU is 1
Hop count is 2
External data:
Originating router is 150.1.5.5
AS number of route is 0
External protocol is Connected, external metric is 0
Administrator tag is 0 (0x00000000)
Rack1R2#

The goal of any solution to this problem is to ensure that the 132.1.5.0/24 route is installed into R2's routing table as an EIGRP route. Basically there are a few standard methods we could use to achieve this goal so lets list them out:

1) Administrative distance
2) Filtering
3) Summarization

Using administrative distance there are multiple ways to resolve the problem. Below I've listed a few of them.

1) Change the administrative distance of the external EIGRP routes to be lower than the OSPF routes on R2.
2) Change the administrative distance of the external OSPF routes to be higher than the external EIGRP routes on R2.
3) Change the administrative distance for all of the OSPF routes to be higher than the external EIGRP routes on R2.
4) Change the administrative distance of just the OSPF routes originated by R3 on R2.
5) Change the administrative distance of just the 132.1.5.0/24 OSPF route on R2.
6) Change the administrative distance of just the 132.1.5.0/24 OSPF route originated by R3 on R2.

As we can see there are a lot of options using AD to ensure the 132.1.5.0/24 gets installed into R2's routing table as an EIGRP route. If we were to select one of the options, option 6 would be the best. The reason 6 would be the best option is because it's the most specific option. We normally want to select the most specific solution as we don't want to implement a solution that could effect other routes. There are actually a couple schools of thought on this and both could be considered correct. The other way of looking at it would be to select the simplest solution regardless of what other routes it effects. Personally I prefer to select the most precise solution assuming that it's not overly complicated.

Let's look at what option 6 applied to R2:

Rack1R2(config)#ip access-list standard OSPF_AD
Rack1R2(config-std-nacl)#permit 132.1.5.0
Rack1R2(config-std-nacl)#router ospf 1
Rack1R2(config-router)# distance 171 150.1.3.3 0.0.0.0 OSPF_AD
Rack1R2(config-router)#^Z
Rack1R2#
Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
Known via "eigrp 10", distance 170, metric 2561024256, type external
Redistributing via eigrp 10
Last update from 132.1.23.3 on Serial0/1, 00:01:24 ago
Routing Descriptor Blocks:
* 132.1.23.3, from 132.1.23.3, 00:01:24 ago, via Serial0/1
Route metric is 2561024256, traffic share count is 1
Total delay is 40010 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 2

Rack1R2#show ip ospf database external 132.1.5.0

OSPF Router with ID (150.1.2.2) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA
LS age: 1513
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 132.1.5.0 (External Network Number )
Advertising Router: 150.1.3.3
LS Seq Number: 80000001
Checksum: 0x6F09
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0

Rack1R2#

Now the route is in R2's routing table as an EIGRP route R6 should have learned it from R2. R6 should also now be able to reach R5 E0/0.

Rack1R6#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
Known via "eigrp 10", distance 170, metric 2561026816, type external
Redistributing via eigrp 10
Last update from 132.1.26.2 on FastEthernet0/0.26, 00:02:08 ago
Routing Descriptor Blocks:
* 132.1.26.2, from 132.1.26.2, 00:02:08 ago, via FastEthernet0/0.26
Route metric is 2561026816, traffic share count is 1
Total delay is 40110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 3

Rack1R6#traceroute 132.1.5.5

Type escape sequence to abort.
Tracing the route to 132.1.5.5

1 132.1.26.2 0 msec 4 msec 4 msec
2 132.1.23.3 16 msec 20 msec 16 msec
3 132.1.35.5 48 msec * 44 msec
Rack1R6#

We can see that the administrative distance solution works. Now lets look at the filtering option and remove the administrative distance solution. The simplest filtering option would be to not allow R2 to install the 132.1.5.0/24 OSPF route into it's routing table.

Rack1R2(config)#ip access-list standard OSPF_FILTER
Rack1R2(config-std-nacl)#deny 132.1.5.0
Rack1R2(config-std-nacl)#permit any
Rack1R2(config-std-nacl)#router ospf 1
Rack1R2(config-router)#distribute-list OSPF_FILTER in
Rack1R2(config-router)#^Z
Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
Known via "eigrp 10", distance 170, metric 2561024256, type external
Redistributing via eigrp 10
Last update from 132.1.23.3 on Serial0/1, 00:00:06 ago
Routing Descriptor Blocks:
* 132.1.23.3, from 132.1.23.3, 00:00:06 ago, via Serial0/1
Route metric is 2561024256, traffic share count is 1
Total delay is 40010 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 2

Rack1R2#

The next option we listed was to use summarization. Before we do that I'll remove the distribute list and then summarize the 132.1.5.0/24 route to 132.1.4.0/23 when it's advertised by OSPF on R3. By doing this R2 will receive the 132.1.5.0/24 via external EIGRP from R3 over the serial and the 132.1.4.0/23 via OSPF from R3 over the Frame Relay link. Since the external EIGRP route is more specific R2 will use it to reach R5's E0/0 interface and in turn advertise the route onto R6.

Rack1R3(config)#router ospf 1
Rack1R3(config-router)#summary-address 132.1.4.0 255.255.254.0

Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
Known via "eigrp 10", distance 170, metric 2561024256, type external
Redistributing via eigrp 10
Last update from 132.1.23.3 on Serial0/1, 00:00:21 ago
Routing Descriptor Blocks:
* 132.1.23.3, from 132.1.23.3, 00:00:21 ago, via Serial0/1
Route metric is 2561024256, traffic share count is 1
Total delay is 40010 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 2

Rack1R2#show ip route 132.1.4.0
Routing entry for 132.1.4.0/23
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 64
Last update from 132.1.0.3 on Serial0/0, 00:00:26 ago
Routing Descriptor Blocks:
* 132.1.0.3, from 150.1.3.3, 00:00:26 ago, via Serial0/0
Route metric is 20, traffic share count is 1

Rack1R2#

Rack1R6#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
Known via "eigrp 10", distance 170, metric 2561026816, type external
Redistributing via eigrp 10
Last update from 132.1.26.2 on FastEthernet0/0.26, 00:00:39 ago
Routing Descriptor Blocks:
* 132.1.26.2, from 132.1.26.2, 00:00:39 ago, via FastEthernet0/0.26
Route metric is 2561026816, traffic share count is 1
Total delay is 40110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 3

Rack1R6#traceroute 132.1.5.5

Type escape sequence to abort.
Tracing the route to 132.1.5.5

1 132.1.26.2 0 msec 4 msec 0 msec
2 132.1.23.3 16 msec 16 msec 16 msec
3 132.1.35.5 48 msec * 44 msec
Rack1R6#

Technically we could have not allowed the 132.1.5.0/24 route from being redistributed into OSPF on R3 by filtering it with a route-map. Additionally we could have also used the "not-advertise" option on the summary command to summarize the route but not advertise. This is basically just a different way of filtering since the not-advertise option summarizes the routes but doesn't advertise the summary.

To this point we have achieve full IP reachability but we have not met the requirements of the task. The task stated that redistribution should be done on both R2 and R3. We've only done it on R3. Now we need to perform redistribution on R2. We will need to implement whatever solution we used on R3 on R2.

Rack1R2(config)#router ospf 1
Rack1R2(config-router)#redistribute eigrp 10 subnets
Rack1R2(config-router)#summary-address 132.1.4.0 255.255.254.0
Rack1R2(config-router)#
Rack1R2(config-router)#router eigrp 1
Rack1R2(config-router)#redistribute ospf 1 metric 1 1 1 1 1
Rack1R2(config-router)#

We can now verify that we still have reachability from R6:

Rack1R6#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
Known via "eigrp 10", distance 170, metric 2561026816, type external
Redistributing via eigrp 10
Last update from 132.1.26.2 on FastEthernet0/0.26, 00:00:04 ago
Routing Descriptor Blocks:
* 132.1.26.2, from 132.1.26.2, 00:00:04 ago, via FastEthernet0/0.26
Route metric is 2561026816, traffic share count is 1
Total delay is 40110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 3

Rack1R6#traceroute 132.1.5.5

Type escape sequence to abort.
Tracing the route to 132.1.5.5

1 132.1.26.2 4 msec 0 msec 4 msec
2 132.1.23.3 16 msec 16 msec 20 msec
3 132.1.35.5 48 msec * 44 msec
Rack1R6#

We can now do a full reachabilty test to ensure everything is reachable. We will also need to do another reachabilty test when the backup link is active. Before we do that we should implement the same solution we used to stop the routing loop on R2 and R3 on R4. We do this because when the Frame Relay link between R3 and R5 is down the 132.1.5.0/24 route will be redistributed into OSPF on R4.

Rack1R4(config)#router ospf 1
Rack1R4(config-router)#redistribute eigrp 10 subnets
Rack1R4(config-router)#summary-address 132.1.4.0 255.255.254.0
Rack1R4(config-router)#
Rack1R4(config-router)#router eigrp 1
Rack1R4(config-router)#redistribute ospf 1 metric 1 1 1 1 1
Rack1R4(config-router)#

I need to add that for simplicity I only discussed the solution in regards to the 132.1.5.0/24 network but in the full solution we would need to consider the other network that is being redistributed into EIGRP on R5 (192.10.1.0/24). Also you may have noticed that the routing loop problem only occurred because a previous task asked us to redistributed the connected Ethernet interfaces into EIGRP on R5. If we would have just solved that 2 point task by advertising it natively using network statements we wouldn't have had any routing loop problems and only lost the 2 points ;-)

Lastly you will find similar in-depth discussions added to the new IEWB-RS Volume II version 5 in regards to route redistribution. It's important that everyone understands not only the solution we chose but what problems the solution is resolving along with any other possible solutions.

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.

Feb
09

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

Abstract: Describe the purpose of redistribution and the issues involved.

Prerequisites: Good understanding of IGP routing protocols (OSPF, EIGRP, RIPv2).

Let's start straight with a rolling out a group of definitions. Redistribution is a process of passing the routing information from one routing domain to another. The ultimate goal of redistribution is to provide full IP connectivity between different routing domains. Another goal (not always required, though) is to provide redundant connectivity, i.e. backup paths between routing domains. Routing domain is a set of routers running the same routing protocol. Redistribution process is performed by border routers - i.e. routers belonging to more than one routing domain. On the contrary, internal routers belong just to one routing domain. Redistribution may be one-way (from one domain to another but not vice-versa) or two-way (bi-directional). Next, internal routes are the IGP prefixes native to a routing protocol; i.e. they are originated by IGP's natural method, and their respective subnets belong to the IGP routing domain. External routes are the IGP prefixes injected into IGP routing domain via a border router - they have no corresponding IP subnets in the routing domain. They appear to be "attached" somehow to the border router that has originated them, and detailed information about their reachability is "compressed" and lost during the redistribution. Transit routing domain is the domain used as path to transport packets between two other routing domains. Domain becomes transit when two border routers perform bi-directional redistribution with two other routing domains. Stub routing domain is configured not to transit packets (effectively by blocking transit redistribution) between two other domains.

Let's look at a picture to clarify the concepts.

Fig 1.1

Redistribution_1

The routing domains on the picture are described in the following table:

Table 1.1

Domain Routers
OSPF R2,R3,R4
EIGRP 123 R1,R2,R3
RIPv2 R4,R5,BB2
EIGRP 356 R3,R5,R6

Examples of internal routers are R1, R6, BB2. The border routers on the picture are reflected in the following table:

Table 1.2

Protocol OSPF EIGRP 356 EIGRP 123 RIPv2
OSPF N/A R3 R2,R3 R4
EIGRP 356 R3 N/A R3 R5
EIGRP 123 R2,R3 R3 N/A NONE
RIPv2 R4 R5 NONE N/A

We will further use the figure and the tables for reference. Note that each domain on Fig 1.1 may be configured to be either transit or stub. For example, if we configure bi-directional redistribution on R3 between RIPv2 and OSPF and also on R2 between EIGRP 123 and OSPF, the OSPF domain will become transit point between two other domains. However, if we take R2 and R3, and configure R2 and R3 to send default routes into EIGRP 123, while redistributing EIGRP 123 into OSPF, we will make EIGRP 123 a stub domain.

What is redistribution needed for?

As we mentioned, the goal is to provide full connectivity between different routing domains. Usually, redistribution is needed when you merge two networks or migrate your network from one routing protocol to another. As such, redistribution is usually deemed to be a temporary solution. However, in reality, we often find that there is nothing more permanent than a temporary solution. And with the respect to CCIE lab exam, you are simply forced to face the redistribution, since the lab scenarios almost anytime involve a number of IGPs running on the topology. Note a very important "functional" property of redistribution: effectively, redistribution is used to "broadcast" the complete routing information among all the routing domain in a given topology.

What are the problems with redistribution?

a) Suboptimal routing

As it has been mentioned already, the external routes have no detailed information about their reachability. Even more, their original routing metric (e.g. cost) has to be converted to the native metric (e.g. to hop count). This is where a concept of seed metric appears. Seed metric is the initial metric assigned to external routes, redistributed into internal protocol (e.g. under RIP routing process: redistribute ospf 1 metric 1). In effect, external prefixes appear to be "attached" to the advertising border router, with "native" seed metric assigned. Due to such "simplifications", and loss of detailed information, suboptimal routing may occur.

Example:

For our example, take EIGRP 123 routing domain. If RIPv2 routes enter EIGRP 123 domain by transiting OSPF and EIGRP 356 domains, packets from R1 to BB2 may take path R1->R2->R4->BB2 (if R2 sets better seed metric). In some worse cases, this route may even take path R1->R2->R3->R5->BB2 (if R2 thinks RIPv2 external routes transiting EIGRP 356 and redistributed into OSPF are better than RIPv2 injected into OSPF by R4) . Sometimes, due to asymmetric redistributions packets may take one path in forward direction and the other in the backward (e.g. packets from R1 to BB2 flow R1->R2->R4->BB2 and packets from BB2 to R1 flow BB2->R5->R3->R1).

b) Routing Loops

The other, more dangerous problem, is possibility that routing loops they may appear due to redistribution. Every routing protocol is able to converge to a loop-free routing only if it has full information on the existing topology. OSPF needs a complete link-state view of the intra-area topologies and star-like connectivity of non-backbone area to Area0. EIGRP requires a to carry out diffusing computations on all the routers in order to provide a loop free routing. RIP slow converges by executing a Bellman-Ford algorithm (gradient-driven optimization) on a whole topology. Since redistribution squashes and hides the original information, no IGP could guarantee a loop-free topology. Loops usually occur when IGP native information (internal routes) re-enter the routing domain as external prefixes due to use of two-way redistribution. The last important thing to note: external routes are always redistributed in a "distance-vector" fashion - i.e. advertised as a vector of prefixes and associated distances, even with link-state protocols.

Example:

Imagine that R4, R5 and R3 are configured for bi-directional redistribution between OSPF, RIPv2 and EIGRP 356 respectively. In effect, RIPv2 routes may transit EIGRP and OSPF, and appear on R4 as OSPF routes. Due to OSPF higher AD, they will be preferred at R4 over native routes, and will leak into RIPv2 domain. Further, BB2 may prefer those "looped back" routes (if say R4 is closer to BB2 than R5) and try to reach R5 connected interfaces via R4->R3. But thanks to two-way redistribution R3 will think R5 is better being reached via R4 - a loop is formed.

Is there a way to overcome those issues?

The answer is - "yes, by using a carefully designed redistribution policy". Since routing protocols could not find and isolate the inter-domain loops, we either need to invent a new "super-routing" protocol, running on top of all IGPs (they call it BGP actually, and use to redistribute routing information between autonomous systems), or configure redistribution so that no routing loops would potentially occur and (hopefully) routing become "somewhat" optimal. We are going to describe a set of heuristics (rules of thumb) that could help us designing loop-less redistribution schemes. We start with the concept of administrative distance.

Administrative distance is a special preference value that allows selection of one protocols prefixes over another. This feature definitely needed on border routers (running multiple IGPs), which may receive the same prefixes via different IGPs. Cisco has assigned some default AD values to it's IGPs (EIGRP, OSPF, RIPv2: 90, 110, 120), but we'll see how this should be changed in accordance with policy. For now, we should note that two protocols - OSPF and EIGRP - offer capability to assign different administrative distance values to internal and external prefixes, thanks to their property to distinguish internal and external routes. This is a very powerful feature, which we are going to use extensively during our redistribution policy design.

Here comes our first rule of thumb. Rule 1: Router should always prefer internal prefix information over any external information. Clearly this is because external information is condensed and incomplete. For our example, if R4 receives a native prefix via RIPv2 and the same prefix via OSPF, it should prefer RIPv2 information over OSPF, even though OSPF has better AD than RIPv2 by default. This is easy to implement, thanks to the fact that we can change OSPF external AD independently of OSPF internal AD. The same rule holds true for any internal router: (not just for border routers) always prefer internal information over external for the same prefix. For example if R2 Loopback0 is advertised as native into EIGRP 123 and OSPF, and then redistributed into OSPF via R3 somehow, R4 should be configure so that OSPF external AD is higher than internal AD, and so that internal prefix is always preferred. This rule also eliminates suboptimal routing, by making sure no "dubious" paths are selected to reach a prefix. Effectively it is implemented so that all protocol external ADs are greater than any protocol internal AD (e.g. OSPF External AD > RIP Internal AD, EIGRP External AD > RIP Internal AD etc). However, RIPv2 has no notion of external routes.

So how could we implement this rule with RIPv2? First we should ensure that RIP AD is always greater than any other protocols external AD - on border routers, where this is needed. Next we need to configure so that RIPv2 internal routes have AD less that any other protocols external AD. To do this, we can take an access-list, enumerate all RIPv2 prefixes, and selectively assign a lower AD to those prefixes. Again, note that this procedure is needed on border routers only, and that you can re-use the access-list. Next, we need to make sure that inside a RIPv2 domain external routes are always considered worse than internal. We can effectively implement this by assigning a relatively high seed metric to redistributed (external) routes - say 8 hops. Since RIP topologies of large diameter are rare, it's safe to assume with our policy that any prefix with metric (hop count) > 8 is an external one. (We may even use this property to distinguish RIPv2 internal prefixes in route-maps, thank to match metric feature).

Next rule of thumb is known as Rule 2: Split-Horizon - Never redistribute a prefix injected from domain A into B back to domain A. This rule is targeted to eliminate "short" loops, by preventing the routing information leaked out of a routing domain to re-enter the same domain via some other point. For out example, it R2 and R3 are doing a two-way redistribution, we may want to prohibit EIGRP routes to transit the OSPF domain and enter the EIGRP domain again. This kind of situations occurs when two routing domains have more than one point of mutual redistribution. While the rule could be implemented playing with AD values or matching only internal routs in route-maps, it's easier and more generic to use tagged routes and filter based on tag information. For example we may tag EIGRP 123 routes injected into OSPF with the tag value of "123" and then configure to block routes with this tag, when redistributing from OSPF into EIGRP 123. Additionally, we tag OSPF routes with tag 110 when sending them to EIGRP 123 domain, and block routes with the same tag entering back the OSPF domain. While this rule may seem to be effective on detecting only "short" loops, it could be used to develop a simple, yet loop-free redistribution strategy.

First, recall how OSPF behaves with respect to inter-area routes exchange. In essence, all areas are linked to a backbone and form a star - loop-free - topology. OSPF then safely passes down the areas summary LSA using the distance-vector behavior, and never advertises those LSA back into backbone. This way, the core knows all the routing information and redistributes it down to leaves. And thanks to a loop-free "skeleton" we are guaranteed to never face any routing loops even with distance-vector advertisements. Now we can reuse this idea among the heterogenous routing domains. Take one routing domain and make it the center of the new star - in essence, make it the only transit domain in the topology. The other domains will effectively become "stub" domains, using our previous definitions - i.e. they exchange routes only with the core routing domain. Proceed with configuring two-way redistribution on border routers (enable route prefix exchange). If a given domain has more than one point of attachment to the star core (the backbone), configure to implement Rule 2 on border routers. Next, implement Rule 1 on border routers, to avoid suboptimal routing issues. That does the trick! For our example, we may configure mutual redistribution on R2 (EIGRP 123 and OSPF), R3 (EIGRP 123 and OSPF), R4 (RIPv2 and OSPF). We will then need to implement tag-based filtering on R2 and R3, as well as tune ADs in accordance with Rule 1. The detailed configuration examples will follow in the further publications.

Okay, now what if we don't have a "central" routing domain attached to all other domains in topology? Let's say R3 is not running OSPF in our example, and we have all routing domains connected in "ring" fashion. In short, the same idea still may be utilized, by replacing pure "star-like" topology with "tree". Tree is loop-less too, so there is a guarantee that no loops will form. We are going to discuss this, and other more complicated scenarios in the next publications.

Jan
15

Hi Brians,

Just a quick question about the "include-connected" command when redistributing IPv6 protocols (especially RIPng and OSPFv3). From the DocCD it says that it allows the quote "target protocol to redistribute routes learned by the source protocol and connected prefixes on those interfaces over which the source protocol is running". Is there any reason why this is now necessary to do with IPv6 routing protocols, whereas IPv4 routing protocols would automatically advertise the networks of the connected interfaces if the source protocol is running on them. By the way, this blog is a fantastic idea/revison tool. Keep up the excellent work.

Kind Regards,

Colin

Hi Colin,

In current IOS versions for IPv4 redistribution is a two step process. Let’s suppose that we are trying to redistribute RIPv2 into OSPFv2 by issuing the “redistribute rip subnets” command under the OSPF process. The first thing the router does is to look at the “show ip route rip” output. All of these prefixes are candidate to be redistributed into OSPF. Next the router looks at the “show ip route connected” output. The routes for any connected interfaces from this output running RIPv2 are also candidate to be redistributed into OSPF. In other words, we don’t have to issue the “redistribute connected subnets” to get connected interfaces that run RIP to be sent into the OSPF process.

In previous IOS versions this was not always the case however. In many network designs, especially in service provider environments, transit links themselves are not advertised into the routing domain. Based on this design traffic cannot be sent *to* the network itself, only *through* the network. Over the course of IOS releases however this behavior was mostly updated, and now we see that IPv4 protocols, with the exception of IS-IS, do automatically redistribute their connected interfaces.

For IPv6 whether or not connected links are included in redistribution is up to you at the time of configuration. If we take the previous case for IPv4 and translate it to IPv6 we’ll see that the behavior is not the same. By this I mean that if we issue the “redistribute rip 1” command under the OSPFv3 process, the router will only look at the output of the routes from the “show ipv6 route rip” command, and not the output from the “show ipv6 route connected”. To get connected interfaces to be included in this redistribution we can either issue a separate “redistribute connected” command under OSPFv3, which will take all connected IPv6 interfaces by default, not those just running RIPng, or we can issue the “redistribute rip 1 include-connected” command. This is the preferred design as it gives us more flexibility as to which particular networks we choose to advertise.

Subscribe to INE Blog Updates

New Blog Posts!