Thank you and Marko both for you responses. That is the exact type of response that I was looking for. I'm absolutely sick and tired of getting the "you never need to know that", "don't worry about it", and "it's not something you would ever need on the job" answers that I have been getting.
I apologize, I should have clarified one thing: I'm speaking outside of CEF or MPLS. I've been reading all the available documentation on those topics and do understand the theoretical foundations of both. However, I'm speaking more about routing without CEF or MPLS. Having said that, it sounds to me that the RIB is the key that I'm looking for. It also sounds to me that switching is the foundation of routing. Also, I've had my eye on Inside Cisco IOS Software Architecture for a while now, but have been put off by the publication date. If you feel that the basic ideas haven't changed, then I'll just nab it. However, I'll look at the CEF book. It's been my experience that books on a specific feature usually also go into depth regarding the lack of the feature. I've just checked: it looks like they are both on Safari Books. Thank you again, David p.s. I'm asking because, as I say, I'm an escalation engineer, but in a different technology field. I'm moving into the world of network engineering, but my study-depth demands will not change. Given my math/physics major back in my college days and in my current job, I do not enjoy the "it's just magic" feeling. On Sun, Nov 21, 2010 at 4:02 PM, Adam Booth <[email protected]> wrote: > Hi David, > > What you are describing is pretty much the case, routing protocols have > their own databases which are then feed into the routing information base, > the same prefix could come in to the router from different protocols, so > administration distance is used as the tiebreaker here as to which protocols > for the prefix should be used. Multiple paths to a destination is provided > to the RIB by the source protocol which is then used to determine the FIB > (Forwarding information base) which has the L2 info like MAC > Address/DLCI/VLAN and the egress port, however you probably want to know how > things like CEF operates as well as MPLS and how the LFIB works. > > This book > http://www.ciscopress.com/bookstore/product.asp?isbn=1587052369(Cisco Express > Forwarding) maybe of interest to you to, it describes in fair > detail how routing, switching and CEF operate probably in less detail than a > Cisco code monkey would need to know but in more detail than most people > really need to be aware of, however if that sounds a bit more than you > really need, it does also have a reasonable troubleshooting section on CEF > (or things that get blamed on CEF), so if you provide deep level support in > this area, perhaps its of help for you and it does cover some of the > variations of "software" and centralised and distributed hardware routing > platforms. > > Cheers, > Adam > > On Mon, Nov 22, 2010 at 7:26 AM, David Betz <[email protected]> wrote: > >> I've been looking, but I cannot seem to find what I'm looking for. Can >> anyone direct me to any resources on the mechanics on the routing table? >> >> My theory: all routing goes through the routing table and only the routing >> table. It seems to me that in the running of a router, no packets ever >> cares about what EIGRP, OSPF, BGP, or RIP are doing. They are >> abstracted/black-boxed from the packet. If this is true, then, QED, EIGRP >> does NOT provide load-balancing (as every books seems to suggest); it >> provides multiple paths to the routing table and THE ROUTING TABLE provides >> load balancing. This has been driving me mad for the longest time. I work >> with extreme accuracies in my day job as an escalation engineer (core dump >> analyzer) and I really need to have this perfectly precise in my mind or I'm >> going to absolutely lose it. >> >> In sum: isn't it all about the routing table... and the routing protocols >> (IGP/EGP) just provide information to the routing table... with all routing >> actually routing the routing table and ONLY the routing table? >> >> If this is true, then when the routing table is solid... then, you have no >> reason to look at the routing protocol databases or tables. >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >> >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
