From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Wed May 12 2004 - 08:40:22 GMT-3
If the AD is the same, then metric would be the tie breaker...
David Hiers wrote:
> 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
>
> _______________________________________________________________________
> 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
>
> _______________________________________________________________________
> 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
>
> _______________________________________________________________________
> 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