From: Howard C. Berkowitz (hcb@xxxxxxxxxxxx)
Date: Sat Aug 03 2002 - 01:56:20 GMT-3
cciecandidate wrote,
>Howard ;
>that is not right after the weight and the local pref , it is number
>8 or 9 in the decision algo , the question was about number 3 which
>is stated about "locally originated routes" not the "origin code of
>the route"
I did misspeak the order of preference of ORIGIN, but "locally
originated" is not the same as checking ORIGIN.
Again, here's the order. Local origination (#4) has nothing to do
with iBGP or eBGP (#6); it has to do with routes generated on the
same router that is making the BGP selection decision:
At 12:47 AM -0400 8/3/02, Howard C. Berkowitz wrote:
>
>1. Discard any route whose next hop is unreachable.
>
>2. If the next hop is accessible, prefer the route with the highest
>weight. Weight is a Cisco-specific parameter that is not transmitted
>in BGP updates, but is a manually configured parameter local to the
>current router.
>
>3. Prefer the route with the highest local preference attribute.
>
>4, Prefer routes originated on the current router.
>5, A widely used criterion that is not part of the IETF
>specifications is to prefer the route with the shortest AS_PATH
>(i.e., the least number of AS in the path).
Note: shortest AS_PATH is part of the new BGP draft.
>
>6. If routes have the same AS_PATH length, prefer Interior to
>Exterior to Incomplete origin.
> Cisco interprets confederation routes as interior, but the
>algorithm prefers confederation exterior to confederation interior.
To correct my earlier error, the most preferred to least preferred origins are:
INTERIOR
CONFEDERATION EXTERIOR
CONFEDERATION INTERIOR
EXTERNAL
INCOMPLETE
>
>7. Of paths with the same origin, prefer those with the lowest MED value.
> In the absence of a specific IETF interpretation, Cisco's
>default was to assume routes without an explicit MED have a MED of
>zero. Recently, the IETF clarified the expected behavior, which is
>the opposite of Cisco's interpretation. This clarification
>specifies that when presented with routes that either have MEDs or
>do not, the routes without MEDs should be less preferable than a
>route with an explicit MED of any value.
> Also, the BGP specification states that MEDs should be compared
>only between connections to the same adjacent AS. There are
>applications such as multilateral exchange points, however, where it
>can be very useful to compare MEDs between multiple adjacent AS. See
>Chapter 12.
>
>8. If the MEDs are equal, prefer routes with external rather than
>internal sources.
> Some implementations reverse the order of this and the next step.
>
>9. Prefer the path through the closest IGP neighbor (i.e., lowest IGP metric).
>
>10. Otherwise, select the path with the lowest originating router ID.
>
> Since router IDs must be unique, this will be a final tie
>breaker. Router ID is selected by the same algorithm used to select
>the OSPF router ID. The BGP specification does not support equal
>cost multipath, but several vendor implementations have proprietary
>extensions for doing so.
>
>11. If multiple paths are enabled, add the current route if both
>the current best route and the new route are external and come from
>the same adjacent AS. Cisco supports up to 6 load-shared paths.
>
>
>
>--
>
>On Fri, 02 Aug 2002 21:48:51
> Howard C. Berkowitz wrote:
>>At 7:08 PM -0700 8/2/02, Carlos A. Silva wrote:
>>>one thing that you might want to consider is that right
>>>after weight and local preference, the router will look at admin distance.
>>>that is: it will make a decision between preferring ebgp or ibgp.
>>>
>>>hth.
>>
>>
>>To be slightly picky, the BGP route selection algorithm isn't looking
>>at AD, but at the BGP ORIGIN attribute. The order of preference in
>>IOS is, from most preferred to least preferred,
>>
>> EXTERNAL
>> CONFEDERATION EXTERNAL
>> INTERNAL
>> INCOMPLETE
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:15 GMT-3