RE: How route redistribution EXACTLY works --- need confirmatio n

From: Lab Candidate (labccie@xxxxxxxxx)
Date: Fri Feb 15 2002 - 20:18:49 GMT-3


   
James,

GateD is written by Cornell University.
you can download it at:
ftp://ftp.gated.merit.edu/research.and.development/gated/

Also you can find the Zebra at:
ftp://ftp.zebra.org/pub/zebra/

---

--- "Xu, James" <james.xu@eds.com> wrote: > I take that for compliment :-). > > Thanks for you and everyone's response, and that is the reason why this > Forum is so great! Since the thread started, I have been receiving > overwhelming response. Some negitive, mostly positive. That are all O.K., > what matters is through all of this discussion, the truth will comes out, > the simple truth about how the redistribution really works in this Cisco > world. > Enough for that. Back to the topic. > > Mike: If I understand you corrctly, then > > A route from routing protocol can be counted as "eligible for the RIB", if > they would be in the routing table without intervention of another routing > protocol. > > I will do some testing in this weekend to see if this added condition will > be enough to explain the redistribution mechanism. > > Howard: The reference material is great, that will be helpful for me to get > a good handle for this topic. As a fact, I just scan through the OSPF book > by John Moy, it does offer some good information about route propagation in > a single protocol. However, it stays short to touch the topic of interaction > between two protocols. By the way, do you have links to the free Zebra code, > and GateD code (I believe GateD is a commercial product from NexHop?). > > James > > > ------------------------------- > Consider the following: > > interface loopback 0 > ip address 192.168.1.0 255.255.255.0 > ! > router rip > network 192.168.1.0 > ! > router eigrp 1 > network 192.168.1.0 > ! > router ospf 1 > network 192.168.1.0 0.0.0.255 area 0 > > > When we look at the RIB (sh ip route,) we see that because routes sourced > from connected interfaces have the lowest AD, only they actually make it to > the RIB. > > But each of the routing protocols will contain 192.168.1.0/24 as a valid > route that _could_ be chosen for the RIB even though in this case it wasn't > actually placed in the RIB. And thus, 192.168.1.0/24 is redistributable by > all of these processes. > > Mike > > ----Original Message----- > From: Michael Davis [mailto:miked@netrus.net] > Sent: Friday, February 15, 2002 1:22 PM > To: Howard C. Berkowitz; ccielab@groupstudy.com > Subject: Re: How route redistribution EXACTLY works --- need > confirmation > > > Great thread James. I like questions that challenge assumptions. What is > it they say about assumptions?! > > Howard, I think, as you said before, we won't know definititively how IOS > does this without a thorough review of souce code. Though I'm sure Cisco > won't be sharing those details with us. ;-) I've just tried to describe, > from a pragmatic standpoint, the behavior I've experienced. > > Your mileage may vary! > > ----- Original Message ----- > From: "Howard C. Berkowitz" <hcb@gettcomm.com> > To: <ccielab@groupstudy.com> > Sent: Friday, February 15, 2002 12:22 PM > Subject: RE: How route redistribution EXACTLY works --- need confirmation > > > > >Mike: > > > > > >I like the condition you added, which is "routes eligible for the RIB". I > > >think, you mean another routing source, which has lower adminstrative > > >distance, didn't inject the same route into routing table. > > > > > >For ospf, when you say the routing bit set, do you mean the routes > resulted > > >from SPF, and also in the RIB? In other words, any route which does not > > >exist in the routing table will not be redistributed? > > > > That is definitely the case for BGP; it's part of loop prevention. > > BGP will also not announce a route that has a next hop that cannot be > > resolved in the RIB. > > > > I don't know definitively if that's done in Cisco's IGPs, but, in > > general, it is a basic principle of avoiding loops.



This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:24 GMT-3