From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Wed May 12 2004 - 18:32:52 GMT-3
Dave,
I have been following your debugs of redistribution. Thanks for sharing
them!
Basically I think mastering redistribution is one big step into being
able to do the lab (BTW, when are you trying yours ?) and would like to
discuss with you some items, if you don't mind.
(For once, I've come to make sense of the distribute OUT list <protocol>
if it works like you say - and cisco says - :-)
I've still some gray areas... like:
1) at time 10:29:39, OSPF has basically 2 independent type 5 LSAs (one
at R2 and one at R4) with the same attributes: metric 20 type 2.
How is R4's ospf process able to prefer R2 LSA over its own ?
Same type of issue on R4, but now in RIP. Once OSPF decided to insert
its own 10.10.10.0 network in the RIB, then RIP gets it from there and
prefers it with metric 2 to the previously installed one that had metric
1! Why ?
On the other side, there's a confirmation in some books that
redistribution always occurs from the routing table, and never from
internal protocol tables, so there is no way to have redistribution
"cascades" so to speak. Somehow routes are marked internally as learned
from the RIB vs learned from elsewhere, and protocols will not install
locally a route that comes from the RIB.
-Carlos
David Buechner wrote:
> 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
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
This archive was generated by hypermail 2.1.4 : Wed Jun 02 2004 - 11:12:10 GMT-3