Blog Ine Com 2008 02 19 Understanding Redistribution Part II PDF

Blog Home | INE Home | Members | Contact Us | Subscribe
Free Resources View Archives All Access Pass CCIE Bloggers
19 Understanding Redistribution (Part II)

Feb Search
Posted by Petr Lapukhov, 4xCCIE/CCDE in IGP 21 Comments Search
UPDATE: For more information on Redistribution see the video series Understanding Route Submit
Redistribution Excerpts from CCIE R&S ATC

Categories
Simple Redistribution Step-by-Step
Select Category
Were 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
!
router ospf 1
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. Lets 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
CCIE Bloggers
D EX 150.18.4.0 Brian Dennis CCIE #2210
[170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0 Routing & Sw itching

ISP Dial
Security
D EX 150.18.2.0
Service Provider
[170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0 Voice
[170/2560002816] via 174.18.123.2, 00:02:03, FastEthernet0/0 Brian McGahan CCIE #8593
D EX 150.18.3.0 Routing & Sw itching
[170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0 Security
[170/2560002816] via 174.18.123.2, 00:02:03, FastEthernet0/0 Service Provider
Petr Lapukhov CCIE #16379
Just as we would expect, R1 has two routes from each OSPF prefix, since both R2 and R3 assign the same seed Routing & Sw itching
Security
metric to redistributed routes.
Service Provider
Voice
Mark Snow CCIE #14073
Rack18R2#show ip route | beg Gate
Voice
Gateway of last resort is not set Security

C 174.18.234.0 is directly connected, Serial0/0 Popular Posts
C 174.18.123.0 is directly connected, FastEthernet0/0 CCIE SPv3 Advanced
Technologies Class Now
O 150.18.4.0 [110/65] via 174.18.234.4, 00:00:19, Serial0/0
Available
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 Cisco Performance Routing (PfR)
O 150.18.3.0 [110/65] via 174.18.234.3, 00:00:19, Serial0/0 / Optimized Edge Routing (OER) -
Part 1
SO Many Voice Updates!
Gateway of last resort is not set

C 174.18.234.0 is directly connected, Serial1/0
C 174.18.0.0 is directly connected, FastEthernet0/1
O 150.18.4.0 [110/782] via 174.18.234.4, 00:00:54, Serial1/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
!
router ospf 1
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:

D EX 174.18.234.0
D EX 174.18.0.0
D EX 150.18.4.0
D EX 150.18.5.0
D EX 150.18.6.0
D EX 150.18.2.0
D EX 150.18.3.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:


O E2 174.18.0.0 [110/20] via 174.18.234.3, 00:02:20, Serial0/0
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
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:


O 150.18.4.0 [110/782] via 174.18.234.4, 00:02:47, Serial1/0
O 150.18.2.0 [110/782] via 174.18.234.2, 00:02:47, Serial1/0
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:

D EX 222.22.2.0/24
D EX 220.20.3.0/24
D EX 174.18.234.0
D EX 174.18.0.0
D EX 192.10.18.0/24
D EX 150.18.4.0
D EX 150.18.5.0
D EX 150.18.6.0
D EX 150.18.2.0
D EX 150.18.3.0
D EX 205.90.31.0/24
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:

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
O E2 174.18.0.0 [110/20] via 174.18.234.3, 00:03:29, Serial0/0
O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:03:29, Serial0/0
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
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

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
O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0
O 150.18.4.0 [110/782] via 174.18.234.4, 00:03:56, Serial1/0
O 150.18.2.0 [110/782] via 174.18.234.2, 00:03:56, Serial1/0
O E2 205.90.31.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0

R 222.22.2.0/24 [120/7] via 192.10.18.254, 00:00:19, FastEthernet0/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
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
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 its more, well,
effective to reach them over Ethernet links.
Rack18R5#sh ip route | beg Gate


R 174.18.234.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1
C 192.10.18.0/24 is directly connected, 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:

D EX 222.22.2.0/24 [170/2560002816] via 174.18.0.3, 00:07:29, FastEthernet0/0
D EX 174.18.234.0
D EX 150.18.4.0 [170/2560002816] via 174.18.0.3, 00:10:31, FastEthernet0/0
BB2>sh ip ro rip
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
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. Were 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:

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
O E2 174.18.0.0 [110/20] via 174.18.234.3, 00:15:13, Serial0/0
O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:15:13, Serial0/0
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
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:

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
O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:16:10, Serial1/0
O 150.18.4.0 [110/782] via 174.18.234.4, 00:16:10, Serial1/0
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
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 cant
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 whats going around. Okay, and its 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:

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
O E2 174.18.0.0 [160/20] via 174.18.234.3, 00:00:35, Serial0/0
O E2 192.10.18.0/24 [160/20] via 174.18.234.4, 00:00:35, Serial0/0
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
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:

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
O E2 192.10.18.0/24 [160/20] via 174.18.234.4, 00:01:14, Serial1/0
O 150.18.4.0 [80/782] via 174.18.234.4, 00:01:14, Serial1/0
O 150.18.2.0 [80/782] via 174.18.234.2, 00:01:14, Serial1/0
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.

D EX 222.22.2.0/24
D EX 220.20.3.0/24
D EX 174.18.234.0
D EX 192.10.18.0/24
D EX 150.18.4.0
D EX 150.18.2.0
D EX 150.18.3.0
D EX 205.90.31.0/24
R6 also learns EIGRP 123 routes via R3:

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

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
O E2 192.10.18.0/24 [160/20] via 174.18.234.4, 02:23:04, Serial1/0
O 150.18.4.0 [80/782] via 174.18.234.4, 02:23:04, Serial1/0
O 150.18.2.0 [80/782] via 174.18.234.2, 02:23:04, Serial1/0
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.
Tags: distance, eigrp, filtering, metric, 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.
21 Responses to Understanding Redistribution (Part II)
February 20, 2008 at 2:31 am

Fernando
Great Post!!! Seldom ive seen such a clear and structured explanation.
Reply
February 20, 2008 at 3:05 pm

Barooq
After banging my head on almost each redistribution task in IEWB first 7 labs and not understanding anything, (I partly blame the
WB. Man it goes to lengths explaining CCNA level stuff, like frame relay mappings or spanning tree but almost mute on
redistribution) I am finally getting a bit understanding. And since I cant afford COD, this blog is the greatest resource I have.
Cant wait for your next post, rather all the posts on redistribution:)
Reply
February 23, 2008 at 4:04 pm

Returning Some Link Love CCIE Pursuit
[...] Part II [...]
Reply
February 25, 2008 at 5:57 am

Week 7 summary Richard Bannisters CCIE Blog
[...] is a link to a great read regarding redistribution I had a look at this week: Understanding Redistribution (Part 2) by Petr Lapukhov,
CCIE #16379 @ Internetwork [...]
Reply
May 18, 2008 at 1:23 pm

IE Blog: understanding redistribution Just another CCIE
[...] I Part II Part [...]
Reply
August 10, 2008 at 8:23 am

Oluwaseyi
This is awesome, even CiscoPress cannot explain it better than this.
Reply
August 29, 2008 at 7:30 am

chukabume
Just wanted to clarify if the distance ospf external command is in 12.4 release , which will be in the routers for the lab ?
Reply
January 3, 2009 at 10:18 pm

Omarept
Good post, I replicated the scenario, and I noticed that before of change the R1 loopback from advertise to redistribute you wrote
down:
This seems to be an easy one. Were 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.
however full connectivity is not reached because R6 cannot get R1 loopback.

in your R6 routing table R1 loopback is not present:
it was copied directly from your post (I got the same result):

D EX 174.18.234.0
Rgds.
Reply
March 13, 2009 at 7:56 am

Alex
Excellent article thanks! Question: what do you guys use or recommend for a lab simulations? I heard of gns3 but I was wondering
if there is something better out there
Thank you in advance.
CheerS!
Reply
March 23, 2009 at 12:41 am

ruhann
Omarept you are right.

The reason though is simple.
A redistributed route cant be redistributed again on the same router. Here it being R3 (EIGRP123> OSPF >x> EIGRP356).
Easy fix as Petr did, Redistribute between EIGRP123 EIGRP356 directly
Reply
June 3, 2009 at 2:31 am

khalid malik
hi
Thank It is really good ways to understand.
Q1) In which router interface you defined
222.22.2.0/24 these ?
If it loopback then it should start with 150.X.X.X ? I am confuse Please help me ?
Reply
August 30, 2009 at 11:28 am

Abdo
Hi Peter ,
I just want to know ,R3 is not runing RIP and in part I you have this (if we configure bi-directional redistribution on R3 between RIPv2
and OSPF ) is this right ???
Reply
September 24, 2010 at 3:09 am

Blog Post Catalogue | CCIE Blog
[...] Understanding Redistribution: Part 2 [...]
Reply
October 7, 2010 at 4:53 am

jdr
Hello,
I am reproducing this lab scenario on my gear.

I noticed, that to achieve output like this:

D EX 174.18.234.0
D EX 150.18.4.0
D EX 150.18.2.0
D EX 150.18.3.0
after mutual redistribution betweend EIGRP123 and OSPF on R2 and R3 you need to configure loopback0 interfaces on all ospf
routers to ip ospf network point-to-point.
Reply

jdr
Actually, there is another hidden snag, just before:
This seems to be an easy one. Were done, full connectivity attained, and no loops were introduced.
As Omarept said before, we do not have reachability to R1s loopback from the R6 router.
This is true, and also we does not have reachability to 174.18.123.0/24 network.
This is due to redistibution thing on R3.
As you remember, the redistribution on router is non-transitive, and routes redistributed on R3 from EIG 356 to OSPF1 are not
redistributed to EIG 123 even if we have redistribution from OSPF1 to EIG 123 on the same device, and vice-versa.
The reason we can see them in EIG123 domain is that R2 knows that routes from R3 over OSPF1, and can redistribute it to EIG123.
Here, in EIG 356 situation is slightly different. As we know, the router wont redistribute from EIG123 through ospf 1 to EIG356. R3
knows that routes by the EIG123 routing process, and since EIG123 AD (90) is better than OSPF1 AD (110), it will use routes
received from EIG123. Thats the reason why it cannot redistribute it over to the EIG356.
Reply

jdr
Just another note on changing ospf ad.

On my lab, when I copy and paste to the router:
Rack1R2(config-router)#router ospf 1
Rack1R2(config-router)#distance ospf intra-area 80
Rack1R2(config-router)#distance ospf inter-area 80
Rack1R2(config-router)#distance ospf external 160
The result of prefixes imported from rip is unpredictable, very often it ends up looping this prefixes between R2 and R3:
Rack1R2#show ip route | b Gate


via 174.1.123.3? Oh, thats bad.

O E2 222.22.2.0/24 [160/20] via 174.1.234.2, 00:05:40, Serial0/0

O E2 220.20.3.0/24 [160/20] via 174.1.234.2, 00:05:40, Serial0/0
via 174.1.234.2? Yeah, even worse.

O E2 222.22.2.0/24 [110/20] via 174.1.234.2, 00:05:55, Serial0/0

O E2 220.20.3.0/24 [110/20] via 174.1.234.2, 00:05:55, Serial0/0
Whoops
Rack1R4#traceroute 222.22.2.2
Type escape sequence to abort.

Tracing the route to 222.22.2.2
1 174.1.234.2 28 msec 28 msec 28 msec

2 174.1.123.3 28 msec 28 msec 28 msec
3 174.1.234.2 36 msec 36 msec 36 msec
4 174.1.123.3 36 msec 36 msec 40 msec
5 174.1.234.2 44 msec 44 msec 48 msec
6 174.1.123.3 48 msec 48 msec 48 msec
7 174.1.234.2 56 msec 60 msec 56 msec
8 174.1.123.3 60 msec 56 msec 56 msec
9 174.1.234.2 64 msec 68 msec 68 msec
10 174.1.123.3 68 msec 68 msec 68 msec
11 174.1.234.2 76 msec 76 msec 76 msec
12 174.1.123.3 80 msec 76 msec 80 msec
13 174.1.234.2 88 msec 88 msec 88 msec
14 174.1.123.3 88 msec 88 msec 88 msec
15 174.1.234.2 100 msec 96 msec 100 msec
16 174.1.123.3 96 msec 96 msec 96 msec
17 174.1.234.2 108 msec 108 msec 108 msec
18 174.1.123.3 108 msec 104 msec 104 msec
19 174.1.234.2 120 msec 116 msec 120 msec
20 174.1.123.3 116 msec 120 msec 116 msec
21 174.1.234.2 132 msec 124 msec 128 msec
22 174.1.123.3 128 msec 128 msec 128 msec
23 174.1.234.2 140 msec 136 msec 136 msec
24 174.1.123.3 136 msec 136 msec 140 msec
25 174.1.234.2 148 msec 148 msec 148 msec
26 174.1.123.3 148 msec 148 msec 144 msec
27 174.1.234.2 160 msec 156 msec 160 msec
28 174.1.123.3 156 msec 160 msec 156 msec
29 174.1.234.2 168 msec 168 msec 168 msec
30 174.1.123.3 196 msec 168 msec 164 msec
Not so cool, after all. We have routing loop in progress.

I cant actually figure out whats happening, guess it is somehow connected to copying and paste distance configuration to the ospf
process.
Couldnt reproduce this behaviour if I change distance using one single command under ospf:
distance ospf intra-area 80 inter-area 80 external 160
After reloading R2 and R3 everything is Okay.

I tried to do some debugs, on ip ospf rib, and heres what I got:
[blablabla]
*Oct 6 22:23:24.971: OSPF-RIB-LOCAL: Synced 222.22.2.0/255.255.255.0 type 16 added 1 paths, deleted 0 paths, change flag
04, spf 26, route instance 26
*Oct 6 22:23:24.971: OSPF-RIB-GLOBAL: Network update succeeded 220.20.3.0/255.255.255.0, via 174.1.234.4 on Serial0/0,
distance 20, flags 00, source 4.4.4.4, tag 00, type 16, return: 0
distance 20, flags 00, source 4.4.4
[blablabla]
[blablabla]
*Oct 6 22:23:25.495: OSPF-RIB-GLOBAL: Route delete succeeded 222.22.2.0/255.255.255.0 via 174.1.234.4 on Serial0/0, source
4.4.4.4, type 16, return: 2
*Oct 6 22:23:25.495: OSPF-RIB-LOCAL: No more paths for 222.22.2.0/255.255.255.0 type 16 delete route from local RIB
4.4.4.4, type 16, return: 2
4.4.4.4, type 16, return: 2
*Oct 6 22:23:25.535: OSPF-RIB-REDIST: Callback for 222.22.2.0/255.255.255.0 redistributed from process OSPF Router
*Oct 6 22:23:25.535: OSPF-RIB-REDIST: 222.22.2.0/255.255.255.0, metric -1734964480, tag 00, attributes 00, will be advertised
[blablabla]
Anyway, I think that is it somehow connected to internal ospf mechanisms responsible for changing routing table after ospf
distances was changed.
R2 drops routes from ospf peers just to reload them after a while with another AD.
In the meantime, eigrp 123 injects its routes to rip networks to the ospf1 process on R2:
Rack1R2#show ip route 222.22.2.0
Routing entry for 222.22.2.0/24
Known via eigrp 123, distance 170, metric 2560002816, type external
Redistributing via eigrp 123, ospf 1
Advertised by ospf 1 subnets
Last update from 174.1.123.3 on FastEthernet0/0, 00:21:23 ago
Routing Descriptor Blocks:
* 174.1.123.3, from 174.1.123.3, 00:21:23 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1
and then R2 advertises those to all other routers in the ospf1 area0.
Unfortunatly, AD for whole ospf process on R4 is still 110, so it preempts valid routes, learned from rip.
After R4 route cache is poisoned with those informations, there is no possibility to break this loop, since valid informations are lost.
Finally, R3 lose its route to RIP prefixes from R4, and learn invalid informations from R2, next it redistributes that invalid information
to eig123 process.
Then again, R2 redistribute this information to OSPF all over again.

Known via ospf 1, distance 160, metric 20, type extern 2, forward metric 64
Redistributing via eigrp 123, eigrp 356
Advertised by eigrp 123 metric 1 1 1 1 1
eigrp 356 metric 1 1 1 1 1
Last update from 174.1.234.2 on Serial0/0, 00:25:31 ago
* 174.1.234.2, from 2.2.2.2, 00:25:31 ago, via Serial0/0

Redistributing via rip
Advertised by rip metric 8
Possible solution to break that loop is to set OSPF distances on R4 just like we did on R2 and R3 (particularly the external one):
Rack1R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R4(config)#router ospf 1
Rack1R4(config-router)#distance ospf intra-area 80
Rack1R4(config-router)#distance ospf inter-area 80
Rack1R4(config-router)#distance ospf external 160
Rack1R4(config-router)#^Z

Redistributing via rip
Advertised by rip metric 8
a little bit later:

Known via rip, distance 120, metric 7
Redistributing via ospf 1, rip
Advertised by ospf 1 subnets
Last update from 192.10.1.254 on FastEthernet0/0, 00:00:04 ago
* 192.10.1.254, from 192.10.1.254, 00:00:04 ago, via FastEthernet0/0
And R2 shows some debugs:
Rack1R2#
*Oct 6 22:51:49.475: OSPF-RIB-LOCAL: Add 205.90.31.0/255.255.255.0, area dummy area, type 16, dist 20, forward 64, tag 00, via
174.1.234.4 Serial0/0, route flags 0800, path flags 00, source 4.4.4.4, spf 33, list-type 3
*Oct 6 22:51:49.479: OSPF-RIB-REDIST: 205.90.31.0/255.255.255.0, metric -1734964480, tag 00, attributes 00, will be flushed
0xE, spf 33, route instance 33
ip routes from R2&R3:
Rack1R2#show ip route ospf | i E2

O E2 222.22.2.0/24 [160/20] via 174.1.234.4, 00:02:48, Serial0/0
O E2 220.20.3.0/24 [160/20] via 174.1.234.4, 00:02:48, Serial0/0
O E2 174.1.0.0 [160/20] via 174.1.234.3, 00:31:12, Serial0/0
O E2 192.10.1.0/24 [160/20] via 174.1.234.4, 00:31:12, Serial0/0
O E2 150.1.6.0 [160/20] via 174.1.234.3, 00:31:12, Serial0/0
O E2 150.1.5.0 [160/20] via 174.1.234.3, 00:31:12, Serial0/0
O E2 205.90.31.0/24 [160/20] via 174.1.234.4, 00:02:48, Serial0/0
Rack1R3#show ip route ospf | i E2

O E2 222.22.2.0/24 [160/20] via 174.1.234.4, 00:03:20, Serial0/0
O E2 220.20.3.0/24 [160/20] via 174.1.234.4, 00:03:20, Serial0/0
O E2 192.10.1.0/24 [160/20] via 174.1.234.4, 00:41:43, Serial0/0
O E2 205.90.31.0/24 [160/20] via 174.1.234.4, 00:03:20, Serial0/0
much better now.
Reply
December 8, 2010 at 3:39 pm

Recurso de INE en "CCIE en castellano"
[...] Understanding Redistribution: Part 2 [...]
Reply
April 12, 2011 at 12:37 pm

kevin
Hi,
This is probably something thats obvious to all of you, but I am hoping someone could help me understand something here.
After R3 has been configured to mutually redistribute EIGRP356 and EIGRP123, shouldnt R1 have two routes to R5 and R6s
loopback?
For example, R6s loopback interface (150.18.6.0) is redistributed into OSPF and EIGRP123 via R3. R2 would see ospf E2 route for
150.18.6.0 with AD of 160 at this time and and redistribute it into EIGRP123. Why doesn R1 see this redistribution from R2?
Thank you.
Reply
April 12, 2011 at 12:55 pm

kevin
Ah, I figured it out I forgot that EIGRP356s metric is carried over into EIGRP123 whereas in R2s case its using an arbitrary
metric 1 1 1 1 1 when its redistributing the prefix into EIGRP123.
Reply
July 6, 2011 at 9:17 am

CCIE link #9 Daniels quest for CCIE
[...] use feature X or Y I should know how to do it using feature Z. So here is part second part in the route redistribution [...]
Reply
July 19, 2011 at 6:09 am

cedric
wit wew!!! no exact word how Im thankful for this post, I really gained my confidence in redistribution. all I can say is more power to
you Petr and God bless you always.
Reply
Leave a Reply
Name (required)
Mail (will not be published) (required)
Submit Comment
$399 CCIE R&S Live Online 5-Day CCIE R&S Printed Vol I - IV Workbook New CCIE Security 5-Day Live
Written Bootcamp! Bundle Special for only $799! Bootcamp dates have been added
http://t.co/KtM1Xn1u http://t.co/TWyLv7YC for January and May 2012 in
twitter.com/inetraining Chicago, IL! Sign Up Today!
http://t.co/XsgqosG4
2011 INE, Inc., All Rights Reserved
pdfcrowd.com

Blog Ine Com 2008 02 19 Understanding Redistribution Part II PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Blog Ine Com 2008 02 19 Understanding Redistribution Part II PDF

Uploaded by

Copyright:

Available Formats

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

Free Resources View Archives All Access Pass CCIE Bloggers

19 Understanding Redistribution (Part II)

Redistribution Excerpts from CCIE R&S ATC

Rack18R1#show ip route eigrp

[170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0 Routing & Sw itching

174.18.0.0/24 is subnetted, 2 subnets

174.18.0.0/24 is subnetted, 3 subnets

Rack18R1#show ip route eigrp

R2 sees EIGRP 356 routes reachable via R3:

Rack18R2#show ip route | beg Gate

174.18.0.0/24 is subnetted, 3 subnets

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

Rack18R3#show ip route | beg Gate

174.18.0.0/24 is subnetted, 3 subnets

Check to see the full routing table of R1:

Rack18R1#show ip route eigrp

Rack18R2#show ip route | beg Gate

O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:03:29, Serial0/0

Rack18R3#show ip route | beg Gate

O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0

Rack18R4#show ip route | beg Gate

R 222.22.2.0/24 [120/7] via 192.10.18.254, 00:00:19, FastEthernet0/0

Rack18R5#sh ip route | beg Gate

R 222.22.2.0/24 [120/7] via 192.10.18.254, 00:00:25, FastEthernet0/1

Rack18R6#show ip route eigrp

See what happens:

Rack18R2#show ip route | beg Gate

O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:15:13, Serial0/0

Rack18R3#show ip route | beg Gate

O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:16:10, Serial1/0

See how this works on R2 and R3:

Rack18R2#show ip route | beg Gate

O E2 222.22.2.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

O E2 222.22.2.0/24 [160/20] via 174.18.234.4, 00:00:55, Serial1/0

Rack18R1#show ip route eigrp

R6 also learns EIGRP 123 routes via R3:

Rack18R6#show ip route eigrp

Rack18R3#show ip route | beg Gate

O E2 222.22.2.0/24 [160/20] via 174.18.234.4, 02:22:45, Serial1/0

Tags: distance, eigrp, filtering, metric, ospf, redistribution, rip

Download this page as a PDF

About Petr Lapukhov, 4xCCIE/CCDE:

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

21 Responses to Understanding Redistribution (Part II)

February 20, 2008 at 2:31 am

February 20, 2008 at 3:05 pm

February 23, 2008 at 4:04 pm

[...] Part II [...]

February 25, 2008 at 5:57 am

May 18, 2008 at 1:23 pm

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

August 10, 2008 at 8:23 am

This is awesome, even CiscoPress cannot explain it better than this.

August 29, 2008 at 7:30 am

January 3, 2009 at 10:18 pm

however full connectivity is not reached because R6 cannot get R1 loopback.

Rack18R6#show ip route eigrp

March 13, 2009 at 7:56 am

Thank you in advance.

March 23, 2009 at 12:41 am