From: David Hiers (David_Hiers@adp.com)
Date: Tue May 11 2004 - 13:56:42 GMT-3
Want a headache? Set the AD of all protocols to the same number, and re-run the test.
I messed around with this a year or so ago, and came away believing that there must be some undocumented tie breakers.
David
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Richard Dumoulin
Sent: Tuesday, May 11, 2004 8:08 AM
To: David Buechner; ccielab@groupstudy.com
Subject: RE: Route Redistribution
So you had a deep look at redistribution. Interesting paper thanks,
--Richard
-----Original Message-----
From: David Buechner [mailto:dbuechn@attglobal.net]
Sent: martes, 11 de mayo de 2004 17:06
To: ccielab@groupstudy.com
Subject: Route Redistribution
Hi all!
There were some questions in the last couple of months which got me started
thinking. The questions were about situations in which you're
redistributing with three different protocols on one router, i.e. EIGRP -
OSPF - RIP. The question was along the lines of "I redistribute EIGRP into
OSPF and OSPF into RIP - why don't the EIGRP routes show up in RIP?" My
experience in doing scenarios had been that this was working as designed,
but I finally felt compelled to understand this better. I've read some
Cisco doc and labbed some situations to prove to myself how this works and
thought I'd share my thoughts with you. Hopefully these are helpful to
someone. And if I'm wrong in any of this please let me know!
One thing I noticed in reading the Cisco doc is that talk about
redistributing "derived routes" between "routing domains." The more I read
this the more it occurred to me that what they're talking about is routes
in the main IP routing table which were learned from a particular
protocol. So for example, in the question above: RIP will learn about OSPF
routes by searching the main routing table for OSPF derived routes rather
than by searching the OSPF database directly. If we track the distribution
path for an EIGRP learned route then it would seem that A) the EIGRP route
will be installed in the main routing table as it has the lowest distance,
B) OSPF will learn the route through redistribution since an EIGRP derived
route is in the main routing table, and C) RIP will not learn about the
route since there is no OSPF derived route in the main routing table to
redistribute. As expected then you must also redistribute EIGRP directly
into RIP to get the EIGRP routes.
To test all this I set up a small 4 router network which looks like this:
R4
|
------------------------------------ Frame Cloud
| | |
R1 R2 R3
| | |
------------------------------------ Ethernet 10.10.10.0/24
R4 is the hub of a frame cloud with spokes out to R1, R2, and R3. R1, R2,
and R3 all have ethernet interfaces in a common IP subnet. R1 is talking
RIP to R4. R2 is talking OPSF to R4. R3 is talking EIGRP to R4. R4 is
redistributing every each protocol into both of the others. I then used
the 3550 to which these routers are connected to bring interfaces online or
take them offline. I did some debugs on the routers which I logged to a
syslog server. Rather than send an even longer e-mail I put the results up
on a web page at: http://home.comcast.net/~dbuechner/syslog.html
What I learned is that my expectations seemed to bear out on the
routers. I was able to see routes get modified or dropped based on
redistribution criteria. For example if you do the following: the EIGRP
router (R3) has the only active ethernet interface. R1 and R2 are learning
about this interface from redistribution into RIP and OSPF on R4. If I
then configure a STATIC route to 10.10.10.0/24 on R4 the STATIC route
replaces the EIGRP route in the main routing table. The lack of the EIGRP
route in the main routing table then causes both OSPF and RIP (and
therefore R2 and R1) to lose their routes to the interface.
I also understand the 'distribution list <x> out <routing-protocol>'
statement better now. Essentially what you are doing is applying the
access-list <x> to routes derived from <routing-protocol> when you send
updates out. So for example I was getting a route from EIGRP which I
redistributed into RIP. I then added a distribution list to filter this
route by adding 'distribution list 1 out eigrp 1' under the RIP
protocol. RIP then lost the route. If i shutdown the R3 interface and
brought up the R2 interface I then had an OSPF derived route in the routing
table on R4. This route got redistributed through RIP to R1 because the
distribution list command was specifically looking for EIGRP. Also, when
the distribution list is keeping RIP from advertising the route I did
notice one (originally confusing) thing: the route still shows up in the
RIP database on R4. The distribution list doesn't keep the route out of
the database, just out of the updates being sent out.
The more I thought about this the more sense it made. While I certainly
don't have access to the IOS code I started to remember my CS training -
specifically in the areas of algorithms and data structures. It makes
sense from a coding perspective for the OSPF process to be isolated from
changes to the data structures used by other routing protocols. If
everyone just looks at the main routing table it is much cleaner.
What's happening also makes sense from a routing perspective. The whole
reason behind administrative distances is to handle the mismatch between
routing protocol metrics. It makes sense that the same problem would occur
when you redistribute. If I'm redistributing two protocols into OSPF, for
example, and both have routes to somewhere in common, how else would I
decide which route to take on except by utilizing the AD? Since the AD
determination is already done for a route to be placed in the main routing
table it makes sense to get your routes for redistribution from there as
well.
I hope this all makes sense and that it is helpful to someone. If I'm out
in left field *PLEASE* say so! I'd hate to be wrong myself, and I'd hate
to lead others astray. :-)
Back to the lab!!
David
This archive was generated by hypermail 2.1.4 : Wed Jun 02 2004 - 11:12:09 GMT-3