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.
Alexander
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
:-> "Alexander" == Alexander Koch <efraim@clues.de> 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
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
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
And just to update, those drafts have made it into RFC 4271
http://www.ietf.org/rfc/rfc4271.txt