Pierre, comments inline At 07:26 PM 8/11/2002 +0000, Pierre-Alex Guanel wrote: >Hey Pete, > >Thanks for the explaination. It does make sense now! > >There were two things I was not aware of: > >1) Routers prefers the EBGP routes due to E vs I preference >2) You are only allowed to advertise your best path for a particular NLRI > >I went back to my books and tried to find references on the first point. >This is what I found: (Doyle, TCP IP vol2 : page 115) > >1) Prefer path with the highest administrative weight >2) Prefer path with highest Local_Pref value >3) Prefer path originated locally i.e. from an IGP >4) Prefer path with shortest AS_Path >5) Prefer path with lowerst origin code >6) Prefer path with lowest multi_exit_disc value >7) Prefer EBGP paths over IBGP path >8) Prefer path with shortest path to bgp next_hop >9 install equal-cost routes in the Loc-RIB (maximum-path enabled) >10)prefer path with lowest BGP router ID (maximum-path not enabled) > >There is no mention of EBGP path versus IBGP. Worse, if I was to go by the >rules above I would have to conclude that R4 should have chosen the path via >AS102 because of the highest LocPref. (see below)
See the below step 7. Always remember much of this is implementation specific (ie this is Cisco's way of doing things) http://www.cisco.com/warp/public/459/25.shtml For the ietf defined performance, see 9.1.1.2 section d of: http://search.ietf.org/internet-drafts/draft-ietf-idr-bgp4-17.txt I believe Cisco supercedes the step 7 above by imposing an AD (internal degree of preference) of 20 on EBGP routes and 200 on IBGP which hard codes hot-potato routing. >R4>sib >BGP table version is 3, local router ID is 192.168.250.4 >Status codes: s suppressed, d damped, h history, * valid, > best, i - >internal >Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path >*> 172.16.0.0 10.10.4.2 0 100 101 i >* i 10.10.2.1 100 0 102 101 i > >There must be a set of rules out there that precede the rules above ... >Where did you learn about those? Are they published some place? First off, always be wary of secondary source information. Books are a great way to learn about concepts, history, design strategy etc, but are not necessarily accurate in all details. Tech publishers print most anything these days to capitalize on a willing market which often results is less than accurate information circulating about. There are many exceptions of course (and Jeff's above in my opinion is certainly one) but it's always wise to understand that just because it was written and published doesn't mean its credible. For clarification of small details like the above, it is always best to consult the primary reference. With that in mind, I think it's key to stay up to date with both the IETF standard sets (ie drafts/rfc's etc) along with the various vendor implementations of the specs. Often the two differ in many aspects. Furthermore, the IETF endeavors to standardize behaviors and semantics to ensure inter operability, but expressly attempts not to impose limitations or guidelines governing how a particular vendor implements code for a particular application. That is to say, they leave the interpretation of how to best implement a spec to the vendor community which leads to numerous (hopefully) inter operable solutions that may vary greatly in their composition. >Thanks, > >Pierre-Alex Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=51206&t=51169 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
