metric 0 vs 'no metric at all'

[Alexander Koch]

Hiya

I was wondering if someone had done any or some research o
this before... basically I am not sure with all the man
implementations of BGP and all the vendors if and what thos
will do when they see a metric of 0 and no metric. I am no
an expert knowing the actual protocol's messages exchanged
but I see some routes with nothing in the metric field o
the various show commands, and some have explicit '0' metric

I do not trust all the BGP implementations around, and w
consider changing the default outbound, with MEDs of cours
still available on request

Alexande

[Daniel Roesen]

On Tue, Jan 03, 2006 at 08:21:43AM +0100, Alexander Koch wrote
> I was wondering if someone had done any or some research o
> this before..

Yup, when troubleshooting the ERXes former wrong handling o
"no MED". :-

> basically I am not sure with all the man
> implementations of BGP and all the vendors if and what thos
> will do when they see a metric of 0 and no metric

"no MED" is supposed to be equal to "MED=0". Some BGP implementation
(e.g. ERX / Juniper E-Series) have knobs like "bgp bestpat
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 fou
octet non-negative integer. The value of this attribute ma
be used by a BGP speaker's decision process to discriminat
among multiple exit points to a neighboring autonomou
system

The MULTI_EXIT_DISC attribute may be used on external (inter-AS
links to discriminate among multiple exit or entry points to the sam
neighboring AS. The value of the MULTI_EXIT_DISC attribute is a fou
octet unsigned number which is called a metric. All other factor
being equal, the exit or entry point with lower metric should b
preferred. If received over external links, the MULTI_EXIT_DIS
attribute may be propagated over internal links to other BGP speaker
within the same AS. The MULTI_EXIT_DISC attribute is neve
propagated to other BGP speakers in neighboring AS's

So the spec is fuzzy about how "no MED vs. MED=0" should be treated, bu
vendors seem to largely agree to "no MED == MED 0". I know of n
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 th
> various show commands, and some have explicit '0' metric

MED is an optional attribute which may be present or not

Best regards
Danie

--
CLUE-RIPE -- Jabber: ***@cluenet.de -- ***@IRCnet -- PGP: 0xA85C8AA

[Danny McPherson]

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, bu
> vendors seem to largely agree to "no MED == MED 0". I know of n
> 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 tha
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.tx

is considerably more explicit about this behavior, as well as a sle
of other previously-left-to-the-implementation items ironed ou
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 thes
behaviors

-dann

[Doug Marschke]

And just to update, those drafts have made it into RFC 427

http://www.ietf.org/rfc/rfc4271.tx

-----Original Message----
From: owner-***@merit.edu [mailto:owner-***@merit.edu] On Behalf O
Danny McPherso
Sent: Tuesday, January 03, 2006 3:49 P
To: ***@nanog.or
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, bu
> vendors seem to largely agree to "no MED == MED 0". I know of n
> 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 tha
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.tx

is considerably more explicit about this behavior, as well as a sle
of other previously-left-to-the-implementation items ironed ou
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 thes
behaviors

-dann

[Pierfrancesco Caci]

:-> "Alexander" == Alexander Koch <***@clues.de> writes

> Hiya

> I was wondering if someone had done any or some research o
> this before... basically I am not sure with all the man
> implementations of BGP and all the vendors if and what thos
> will do when they see a metric of 0 and no metric. I am no
> an expert knowing the actual protocol's messages exchanged
> but I see some routes with nothing in the metric field o
> the various show commands, and some have explicit '0' metric

> I do not trust all the BGP implementations around, and w
> consider changing the default outbound, with MEDs of cours
> 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#wp107661

default is treating missing med as 0, which tends to surprise peers/customer
who want to send med only on a few routes (i.e., if you want to set
med on a route, always set it on all your bgp sessions, because yo
can't tell if your neighbor has set "missing-as-worst" or not)

P

> Alexande


--

[Stephen J. Wilcox]

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 th
> vendors if and what those will do when they see a metric of 0 and no metric.
> am not an expert knowing the actual protocol's messages exchanged, but I se
> some routes with nothing in the metric field on the various show commands, an
> some have explicit '0' metric
>
> I do not trust all the BGP implementations around, and we consider changin
> 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 reall

the best practice was to set med manually to ensure the expected behaviour
occurred

Stev