Blog Home | INE Home | Members | Contact Us | Subscribe

Free Resources View Archives All Access Pass CCIE Bloggers

09 Understanding Redistribution (Part I)

Feb Search
Posted by Petr Lapukhov, 4xCCIE/CCDE in IGP 27 Comments Search

UPDATE: For more information on Redistribution see the video series Understanding Route Submit

Redistribution Excerpts from CCIE R&S ATC

Categories
Abstract: Describe the purpose of redistribution and the issues involved.
Select Category

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

CCIE Bloggers
Lets start straight with a rolling out a group of definitions. Redistribution is a process of passing the routing
Brian Dennis, CCIEx5 #2210
information from one routing domain to another. The ultimate goal of redistribution is to provide full IP connectivity
Routing & Sw itching
between different routing domains. Another goal (not always required, though) is to provide redundant
Voice
connectivity, i.e. backup paths between routing domains. Routing domain is a set of routers running the same Security
routing protocol. Redistribution process is performed by border routers i.e. routers belonging to more than one Service Provider
ISP Dial
routing domain. On the contrary, internal routers belong just to one routing domain. Redistribution may be one-
Brian McGahan, CCIEx4 #8593,
way (from one domain to another but not vice-versa) or two-way (bi-directional). Next, internal routes are the IGP CCDE #2013::13
prefixes native to a routing protocol; i.e. they are originated by IGPs natural method, and their respective subnets Design
belong to the IGP routing domain. External routes are the IGP prefixes injected into IGP routing domain via a Data Center
Routing & Sw itching
border router they have no corresponding IP subnets in the routing domain. They appear to be attached
Security
somehow to the border router that has originated them, and detailed information about their reachability is Service Provider
compressed and lost during the redistribution. Transit routing domain is the domain used as path to transport Mark Snow , CCIEx4 #14073
packets between two other routing domains. Domain becomes transit when two border routers perform bi- Data Center
directional redistribution with two other routing domains. Stub routing domain is configured not to transit packets Collaboration
(effectively by blocking transit redistribution) between two other domains. Security
Voice
Petr Lapukhov, CCIEx4 #16379,
Lets look at a picture to clarify the concepts. CCDE #2010::7
Design
Fig 1.1 Routing & Sw itching
Security
Service Provider
Voice

Popular Posts
No posts to display

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 its IGPs (EIGRP, OSPF, RIPv2: 90, 110,
120), but well 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, its 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, its 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 dont have a central routing domain attached to all other domains in topology? Lets 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.

Tags: eigrp, external, General, internal, ospf, redistribution, rip

Download this page as a PDF

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 w ith a focus on computer programming, and progressed into netw orking
w ith his first exposure to Novell NetWare in 1991. Initially involved w ith Kazan State University's campus netw ork
support and UNIX system administration, he w ent through the path of becoming a netw orking consultant, taking part in
many netw ork deployment projects. Petr currently has over 12 years of experience w orking in the Cisco netw orking
field, and is the only person in the w orld to have obtained four CCIEs in under tw o years, passing each on his first
attempt. Petr is an exceptional case in that he has been w orking w ith all of the technologies covered in his four CCIE
tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing
self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied
Mathematics.
Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website

You can leave a response, or trackback from your own site.

27 Responses to Understanding Redistribution (Part I)

February 9, 2008 at 10:33 am

Understanding Redistribution : CCIE Journey

[...] Understanding Redistribution (Part I) [...]

Reply

February 9, 2008 at 10:27 pm

Rama

Nice article. Because of lack of RFC/standard for redistribution, it is a special art form that need to be mastered by CCIE candidates.

Reply

February 11, 2008 at 1:21 am

Ali

This is the Best and most organized explaination on the redistribution I have ever read.Please continue ASAP Thanks

Reply

February 13, 2008 at 10:25 pm

George

Good explanation, I like this document. It serves as a guideline when doing redistribution. Ive been trying to collect documents on
redistribution and this is definitely one of them! Thanks Petr!

Reply

February 17, 2008 at 11:59 pm

Barooq

Very good explanation.

Cant wait for the next part with config examples and more complex scenarios.

Reply

Understanding Redistribution (Part II) - Internetwork Experts CCIE Blog - Helping you become a Cisco
Certified Internetwork Expert
February 19, 2008 at 11:32 am

[...] Understanding Redistribution (Part I) [...]

Reply

February 19, 2008 at 4:48 pm

Understanding Redistribution Part II from Internetwork Expert : CCIE Journey

[...] 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. [...]

Reply

February 21, 2008 at 2:22 pm

Returning Some Link Love CCIE Pursuit

[...] Part I [...]

Reply

February 26, 2008 at 1:44 am

Liviu Cohen

Thanks, it helped me a lot.

Reply

March 6, 2008 at 12:18 pm

Nikolay Abromov

Really helpful!

Reply

March 15, 2008 at 10:19 am

fadel

Thanks, your blog is really helpful source.

Reply

March 24, 2008 at 1:48 am

Ivan Seiler

Very well structed document. This approach makes something that could be very difficult and confusing, something much easy.
Thank you for this helpful explanation (and I thought that cisco documentation was very clear )

Reply

March 31, 2008 at 4:42 am

Aminon S. Manyeruke

Thanx for the article. It has enhanced my understanding of redistribution.Previously it was hazy. Keep up the good work.

Reply

May 18, 2008 at 1:13 pm

IE Blog: understanding redistribution Just another CCIE

[...] Part I Part II Part III [...]

Reply

October 11, 2008 at 6:19 pm

Janardhana Achladi

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.

I did not understand how OSPF will have different AD for external prefixes? Can some one explain?

Reply

October 11, 2008 at 6:42 pm

Janardhana Achladi

I got this now. I believe petr intent to explain OSPF and EIGRP ability to distinguish between external and internal routes, where as
RIP doesnt.

Reply

December 2, 2008 at 5:38 pm

Weiborao

Thank Petr Lapukhov, for giving us quite a good article.

I have a question about the detail of route redistribution.
Is there any Inter-process communication between the two routing processes? For example, a router is running both RIPv2 and
OSPF,and redistributing RIPv2 to OSPF.There must be a IPC between RIPv2 and OSPF,right?
And from the article Redistributing Routing Protocols on CCO. I learned that
The rules for redistribution on a Cisco router dictate that the redistributed route be present in the routing table. So, although the
RIPv2 gets updates ervery 30 seconds, the RIP routing table doesnt change, and the redistribution will not be affected.Is that right?
Can someone give a deep explanation on route redistributing?

Reply

January 6, 2009 at 1:29 am

franc_maurer

I think the Rule 2, though good for loop avoidance, breaks redundancy requirement in most cases (if there is any). In such a simple
topology, everything will be fine (redundancy will be maintaned) but consider the situation if R1 is connected with R2 and R3 with
point2point links (instead of the shared medium) and R3 has a RIP neighbor directly connected, lets say R10(that router is running
only RIP). In such case we should redistribute on R3 all the RIP prefixes learned from R10 and than redistribute them back to RIP
from OSPF on R2 (which is in contrast with Rule 2). If we do not do this in if the link R1-R3 fails R1 will have no knowledge about
R10 prefixes.

You can take even the comparison to OSPF areas further: this is exactly what happens in OSPF if the Area0 is partitioned (because
the Area 0 prefixes are not redistributed back to Area 0 if the Are0 is partitioned the reachability is broken)

What do you guys think about it?

Reply

February 16, 2009 at 9:52 pm

swallow09

!!Thank!!

Reply

May 5, 2010 at 6:54 pm

eric

In this scenario, what if BGP was used to redist the routes?

I have a scenario of:

OSPF Network AS1/ R1 R2 R3 OSPF Network AS2

I want to run:
BGP between R1 and R2 (AS1)
OSPF between R2 and R3 (AS2)

Can I just redist R1 OSPF into BGP to have the routes on R2, then on R2 redist BGP into OSPF to have the routes on R3? In turn, I
was thinking to redist R2 OSPF ingo BGP to get routes to R1, but I think
I will hit the loop case. Will BGP prevent the loop?? Or do I still need to do Rule 1 and Rule 2?

Thanks!!!

Reply

June 23, 2010 at 6:48 pm

Josh

I am confused about something for Rule 1.

Petr states

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.

Shouldnt this read First we should ensure that RIP AD is always LESS THAN any other protocols external AS? ie RIP AD = 109 and
OSPF external AD = 110 on border router???

Also shouldnt next sentance read Next we need to configure so that RIPv2 internal routes have METRIC less than any other
protocols external routes METRIC
????

Reply

August 8, 2010 at 4:38 am

KishSquared

Josh,

Petr is actually correct. The reason the RIP AD must be greater than other externals is because the border router in question is as
much a part of the other routing protocol as RIP. For example, R4 above is an OSPF router as much as a RIP router. You want RIPs
external routes to be higher than OSPFs external routes.

However, RIP doesnt allow this configuration since it lacks the notion of external routes. So the trick to doing this is to make a
blanket statement (all RIP routes are external), and configure this on the border router. Next, make an exception to the rule by
manually setting internal RIP routes below external ADs. This effectively creates the concept of external RIP routes, since RIP
doesnt take care of that for us.

Finally, Petr was flowing with his train of thought regarding the AD vs Metric. He obviously opted to use metric, but the point is that the
internal routers need to somehow know which routes are external, and you do that by setting a high metric. You could technically
perform AD manipulation on them as well, I believe, but theres no reason to go to such effort unless your RIP domain is huge.

Reply

November 28, 2010 at 11:46 am

varun

Thanks a lot for the information.

Cheers
varun

Reply

September 30, 2012 at 11:07 am

Vinicius Arcanjo

The best article ever written about redistribution.

Thank you!

Reply

Dec ember 12, 2012 at 11:09 am

Understanding Redistribution INE Tom Giembicki's CCIE Blog

[...] link http://blog.ine.com/2008/02/09/understanding-redistribution-part-i/ will take you to the INE website post made by 4x CCIE Petr
Labukhov who has created one of the [...]

Reply

July 6, 2013 at 6:56 am

Redistribution Expert Lab | Jonas vg till CCIE

[...] Hr krde jag fast rtt rejlt och tog istllet och lste Petr Lapukhovs blogg om detta,
se http://blog.ine.com/2008/02/09/understanding-redistribution-part-i/. Dr anger han bl.a. tv regler vi alltid ska utg [...]

Reply

October 8, 2013 at 11:31 pm

Shibin

Awesome explanation. Since redistribution is a complicated lesson, Im very much confused of it. This article really help me a lot.

Reply

Leave a Reply

Name (required)

Mail (will not be published) (required)

Submit Comment

twitter.com/ine

2011 INE, Inc., All Rights Reserved

pdfcrowd.com