«

Hello -
How is the metric calculated in BGP?

Would specifying route-maps for BGP neighbors (neighbor x.x.x.x
route-map NAME in) and having (set as-path prepend AS-NUM) in that
route-map cause a metric not to be calculated?

I have 4 uplinks to 4 different providers. 2 have route-maps specified
for outbound packets. These 2 never show a metric in "show ip bgp x.x.x.x"

I have a 3rd link (no route-map) that 95% of the time has a metric of 0.
What causes that?

Thank you.
David

In article <>,
David Hill <> wrote:

> Hello -
> How is the metric calculated in BGP?

However you want. The only automatic metric-setting mechanism is the
route-map statement "set metric-type internal", which causes the IGP
metric to be copied into the BGP advertisement.

>
> Would specifying route-maps for BGP neighbors (neighbor x.x.x.x
> route-map NAME in) and having (set as-path prepend AS-NUM) in that
> route-map cause a metric not to be calculated?

Unless you enable "bgp always-compare-med", metric is ignored when
comparing paths that come from different remote ASes. The reason for
this is that the metric is often related to the remote AS's IGP; since
there's no reason to expect that two different ASes use the same IGP or
that their metrics are comparable, it doesn't usually make sense to
compare them.

>
> I have 4 uplinks to 4 different providers. 2 have route-maps specified
> for outbound packets. These 2 never show a metric in "show ip bgp x.x.x.x"
>
> I have a 3rd link (no route-map) that 95% of the time has a metric of 0.
> What causes that?

One ISP is sending you MEDs, the other three aren't.

--
Barry Margolin,
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Barry Margolin wrote:

> In article <>,
> David Hill <> wrote:
>
>
>>Hello -
>>How is the metric calculated in BGP?
>
>
> However you want. The only automatic metric-setting mechanism is the
> route-map statement "set metric-type internal", which causes the IGP
> metric to be copied into the BGP advertisement.
>
>
>>Would specifying route-maps for BGP neighbors (neighbor x.x.x.x
>>route-map NAME in) and having (set as-path prepend AS-NUM) in that
>>route-map cause a metric not to be calculated?
>
>
> Unless you enable "bgp always-compare-med", metric is ignored when
> comparing paths that come from different remote ASes. The reason for
> this is that the metric is often related to the remote AS's IGP; since
> there's no reason to expect that two different ASes use the same IGP or
> that their metrics are comparable, it doesn't usually make sense to
> compare them.
>
>
>>I have 4 uplinks to 4 different providers. 2 have route-maps specified
>>for outbound packets. These 2 never show a metric in "show ip bgp x.x.x.x"
>>
>>I have a 3rd link (no route-map) that 95% of the time has a metric of 0.
>> What causes that?
>
>
> One ISP is sending you MEDs, the other three aren't.
>

Excellent! Thanks for the help.

As you said above:
Unless you enable "bgp always-compare-med", metric is ignored when
comparing paths that come from different remote ASes.

I do not have "bgp always-compare-med" enabled. So if the number of AS
hops are the same down two different uplinks/different remote ASes, then
how was the following route chosen as best?

1239 3561
...Sprint
Origin IGP, metric 26, localpref 100, weight 1000, valid,
external, best
6347 3561
...Savvis
Origin IGP, localpref 100, weight 1000, valid, external

I do not set the metric. So I am assuming Sprint sends us MED's, Savvis
doesn't. If the path _is_ chosen because Sprint sent us a metric of 26
and Savvis sends us nothing (so metric is 0), should we have Savvis send
us MEDs too?

Thanks in advance.

In article <>,
David Hill <> wrote:

> As you said above:
> Unless you enable "bgp always-compare-med", metric is ignored when
> comparing paths that come from different remote ASes.
>
> I do not have "bgp always-compare-med" enabled. So if the number of AS
> hops are the same down two different uplinks/different remote ASes, then
> how was the following route chosen as best?
>
> 1239 3561
> ...Sprint
> Origin IGP, metric 26, localpref 100, weight 1000, valid,
> external, best
> 6347 3561
> ...Savvis
> Origin IGP, localpref 100, weight 1000, valid, external
>
> I do not set the metric. So I am assuming Sprint sends us MED's, Savvis
> doesn't. If the path _is_ chosen because Sprint sent us a metric of 26
> and Savvis sends us nothing (so metric is 0), should we have Savvis send
> us MEDs too?

It doesn't matter -- as I said in the sentence you quoted, the metric is
ignored. BTW, if metrics were being compared, Savvis would have won,
since the lowest metric is best (it's assumed to be a distance of some
kind).

If the weight, path length, localpref, and origin are the same, Cisco
uses the age of the path as the deciding factor. So it's probably using
the Sprint path because it learned it earlier.

Before Cisco added this to their criteria, they used the neighbor ID
(which is usually its IP address), always preferring the one with the
lowest ID.

If you want to prefer Savvis over Sprint when the path lengths are the
same, you can pad the AS path of the Sprint routes with a route-map.

--
Barry Margolin,
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Barry Margolin wrote:
> In article <>,
> David Hill <> wrote:
>
>
>>As you said above:
>> Unless you enable "bgp always-compare-med", metric is ignored when
>> comparing paths that come from different remote ASes.
>>
>>I do not have "bgp always-compare-med" enabled. So if the number of AS
>>hops are the same down two different uplinks/different remote ASes, then
>>how was the following route chosen as best?
>>
>> 1239 3561
>> ...Sprint
>> Origin IGP, metric 26, localpref 100, weight 1000, valid,
>>external, best
>> 6347 3561
>> ...Savvis
>> Origin IGP, localpref 100, weight 1000, valid, external
>>
>>I do not set the metric. So I am assuming Sprint sends us MED's, Savvis
>>doesn't. If the path _is_ chosen because Sprint sent us a metric of 26
>>and Savvis sends us nothing (so metric is 0), should we have Savvis send
>>us MEDs too?
>
>
> It doesn't matter -- as I said in the sentence you quoted, the metric is
> ignored. BTW, if metrics were being compared, Savvis would have won,
> since the lowest metric is best (it's assumed to be a distance of some
> kind).
>
> If the weight, path length, localpref, and origin are the same, Cisco
> uses the age of the path as the deciding factor. So it's probably using
> the Sprint path because it learned it earlier.
>
> Before Cisco added this to their criteria, they used the neighbor ID
> (which is usually its IP address), always preferring the one with the
> lowest ID.
>
> If you want to prefer Savvis over Sprint when the path lengths are the
> same, you can pad the AS path of the Sprint routes with a route-map.
>

Things are a lot clearer now

Thanks for your help, Barry

[theapplebee]

Is metric value transport to peer on Juniper ? I think peer accept metric value, but not forward it to peer.
Any one have answer?