From: Howard C. Berkowitz (hcb@xxxxxxxxxxxx)
Date: Thu Feb 14 2002 - 23:06:39 GMT-3
>SO, it is from internal database of the routing process and not from
>routing table of the
>router. Could you let the group know how this conclusion is dedrive.
>
>Parry Chua
>
The fundamental issue here is that no standard defines how different
routing protocols interact. Even the one RFC that did deal with
BGP-OSPF interaction has been retired. The interaction, therefore,
is up to the implementer, and truly to know, one would need access
either to the IOS code or to someone who does. When I was at Nortel,
I did deal with code for several experimental routers, and, to the
best of my recollection, each one did it a little differently. I'd
have to talk to one of the original IOS routing code implementers,
most of whom are now at Juniper or Procket, to know why the original
design decisions were made.
Where I designed code, the imported routes came from what was
logically the individual protocol databases. Getting them from the
main RIB (i.e., that which you see with show IP route) wouldn't give
me access to everything the protocol knew. There could be very rare
situations, for example, where I'd want OSPF to consider a route
learned from RIP rather than eBGP, but if the same route was sourced
by both RIP and eBGP, the RIP route would never make it into the RIB.
As you get deeper and deeper into routing code, you are getting more
and more into things the vendors consider confidential, as they may
have a major effect on capacity or performance. There also are
tradeoffs. For the same received routes, the Loc-RIB on a Bay RS
router takes much less memory than on a Cisco IOS router, but you
can't do some of the filtering that you can do in IOS.
No production router is likely to use the original Dijkstra algorithm
for link state computations. While the actual algorithms used have
the same results as Dijkstra's, they are much more efficient.
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:23 GMT-3