RE: metric 0 vs 'no metric at all'
And just to update, those drafts have made it into RFC 4271 http://www.ietf.org/rfc/rfc4271.txt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Danny McPherson Sent: Tuesday, January 03, 2006 3:49 PM To: [EMAIL PROTECTED] Subject: Re: metric 0 vs 'no metric at all' On Jan 3, 2006, at 1:03 AM, Daniel Roesen wrote: > > So the spec is fuzzy about how "no MED vs. MED=0" should be > treated, but > vendors seem to largely agree to "no MED == MED 0". I know of no > deviation, except the old ERX bug which got fixed (ERX treated "no > MED" > as best, even better than MED=0 - contrary to documentation). I recall some earlier implementations from "well known" vendors that had varying behavior for MED processing as well. Fortunately, the update to RFC 1771: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-26.txt is considerably more explicit about this behavior, as well as a slew of other previously-left-to-the-implementation items ironed out through a great deal of implementation and deployment experience. The "BGP Experience" and "BGP MED Considerations" Internet- drafts provide a good bit of additional insight into some of these behaviors. -danny
Re: metric 0 vs 'no metric at all'
On Tue, 3 Jan 2006, Alexander Koch wrote: > I was wondering if someone had done any or some research on this before... > basically I am not sure with all the many implementations of BGP and all the > vendors if and what those will do when they see a metric of 0 and no metric. I > am not an expert knowing the actual protocol's messages exchanged, but I see > some routes with nothing in the metric field on the various show commands, and > some have explicit '0' metric. > > I do not trust all the BGP implementations around, and we consider changing > the default outbound, with MEDs of course still available on request. i had this some time ago, cant remember where but i found some answers... basically no metric is undefined, and can be handled either as all-zero or all-ones or anything you want really the best practice was to set med manually to ensure the expected behaviour occurred. Steve
Re: metric 0 vs 'no metric at all'
On Jan 3, 2006, at 1:03 AM, Daniel Roesen wrote: So the spec is fuzzy about how "no MED vs. MED=0" should be treated, but vendors seem to largely agree to "no MED == MED 0". I know of no deviation, except the old ERX bug which got fixed (ERX treated "no MED" as best, even better than MED=0 - contrary to documentation). I recall some earlier implementations from "well known" vendors that had varying behavior for MED processing as well. Fortunately, the update to RFC 1771: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-26.txt is considerably more explicit about this behavior, as well as a slew of other previously-left-to-the-implementation items ironed out through a great deal of implementation and deployment experience. The "BGP Experience" and "BGP MED Considerations" Internet- drafts provide a good bit of additional insight into some of these behaviors. -danny
Re: metric 0 vs 'no metric at all'
:-> "Alexander" == Alexander Koch <[EMAIL PROTECTED]> writes: > Hiya, > I was wondering if someone had done any or some research on > this before... basically I am not sure with all the many > implementations of BGP and all the vendors if and what those > will do when they see a metric of 0 and no metric. I am not > an expert knowing the actual protocol's messages exchanged, > but I see some routes with nothing in the metric field on > the various show commands, and some have explicit '0' metric. > I do not trust all the BGP implementations around, and we > consider changing the default outbound, with MEDs of course > still available on request. Cisco has a knob for this: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/123tip2r/ip2_b1gt.htm#wp1076618 default is treating missing med as 0, which tends to surprise peers/customers who want to send med only on a few routes (i.e., if you want to set a med on a route, always set it on all your bgp sessions, because you can't tell if your neighbor has set "missing-as-worst" or not). Pf > Alexander -- --- Pierfrancesco Caci | Network & System Administrator - INOC-DBA: 6762*PFC [EMAIL PROTECTED] | Telecom Italia Sparkle - http://etabeta.noc.seabone.net/ Linux paperino 2.4.20 #1 Mon Dec 2 17:02:14 CET 2002 i686 GNU/Linux
Re: metric 0 vs 'no metric at all'
On Tue, Jan 03, 2006 at 08:21:43AM +0100, Alexander Koch wrote: > I was wondering if someone had done any or some research on > this before... Yup, when troubleshooting the ERXes former wrong handling of "no MED". :-) > basically I am not sure with all the many > implementations of BGP and all the vendors if and what those > will do when they see a metric of 0 and no metric. "no MED" is supposed to be equal to "MED=0". Some BGP implementations (e.g. ERX / Juniper E-Series) have knobs like "bgp bestpath missing-as-worst" to fiddle with that. RFC1771 states: d) MULTI_EXIT_DISC (Type Code 4): This is an optional non-transitive attribute that is a four octet non-negative integer. The value of this attribute may be used by a BGP speaker's decision process to discriminate among multiple exit points to a neighboring autonomous system. The MULTI_EXIT_DISC attribute may be used on external (inter-AS) links to discriminate among multiple exit or entry points to the same neighboring AS. The value of the MULTI_EXIT_DISC attribute is a four octet unsigned number which is called a metric. All other factors being equal, the exit or entry point with lower metric should be preferred. If received over external links, the MULTI_EXIT_DISC attribute may be propagated over internal links to other BGP speakers within the same AS. The MULTI_EXIT_DISC attribute is never propagated to other BGP speakers in neighboring AS's. So the spec is fuzzy about how "no MED vs. MED=0" should be treated, but vendors seem to largely agree to "no MED == MED 0". I know of no deviation, except the old ERX bug which got fixed (ERX treated "no MED" as best, even better than MED=0 - contrary to documentation). > I am not an expert knowing the actual protocol's messages exchanged, > but I see some routes with nothing in the metric field on the > various show commands, and some have explicit '0' metric. MED is an optional attribute which may be present or not. Best regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
