BGP - Re-Advertise Metric (MED)

General questions
1

Hello,

I have an inbound route-map applied that adds the peer’s round trip time to the metric value when routes are imported:

set policy route-map gen-in rule 50 set metric '+rtt'

Applied like so:

set protocols bgp peer-group PEER-GROUP address-family ipv4-unicast route-map import 'gen-in'

And this works great! However, I would like to re-advertise the metric to my peers. I tried doing the same, but with an outbound route-map:

set policy route-map gen-out rule 10 set metric '+rtt'

set protocols bgp peer-group PEER-GROUP address-family ipv4-unicast route-map export 'gen-out'

However, the metric set on advertised routes is 0. I think on a level this makes sense, as it is local RTT is basically nothing.

However, I would like to re-advertise the metric as added when routes are imported. Why, you may ask? I’m toying around with abusing MED to determine which path may be the lowest latency.

Example fictitious logical eBGP topology:

image
image668×828 13.3 KB

From a logical standpoint, the “shortest” path between Node B and Node D is the direct path, but the “fastest” path is actually B <> E <> D.

When Node E receives Node B’s prefixes, it imports them with a metric of 20. When Node E re-advertises Node B’s prefixes to Node D, it passes along a metric of 20, and when Node D imports them it adds 15 to the metric for an installed metric of 35.

Of course, for this to work, we need to enable set protocols bgp parameters always-compare-med.

Is it possible to re-advertise metric manipulated upon import?

2

I haven’t used that route-map setting, but my guess is it only calculates on the ingress. In that case, setting it outbound wouldn’t have an effect.

MED is nontransitive, so you can’t forward the MED value received by an eBGP peer. You can only reset it outbound. In that case, it makes sense it would be 0, since it is not forwarding on the MED it received, but regenerating it outbound, where the RTT isn’t calculated (again, assuming it’s only on the ingress).

You’d need some minimal scripting to make this work how you want.

1 Like
3

Thanks for the reply!

I figured this was the case as it goes against BGP spec, so it makes sense. The good news is I have no real world application for this…it’s just something I’ve been contemplating if there is a feasible way to relay path latency.

I suppose if each peer adds RTT to routes at import, you can tweak BGP best path selection to prefer the peer with the lowest metric, but that doesn’t necessarily guarantee that the lowest latent peer is the lowest latent path.

I think if I were to cobble a script together, it would need to do the following:

  • For routes a peer originates, it likely is fine to send metric of 0 because we can rely on the receiving peer to set metric to RTT.
  • For routes a peer re-advertises, it would need to grab the lowest metric for a given route and re-advertise it. The receiving peer would then add RTT of the sending peer upon import.

I think it could work, but I don’t think it would scale well. Definitely something to ponder, heh!

4

I’d probably avoid using MED for a solution like this, since it can often cause issues.

An alternative would be to store the values as communities, and then use those communities to create latency buckets. For instance you could have a bucket schema like this:

Community Bucket
<rtr-id>:10000-9 Matches latencies from 0-9ms
<rtr-id>:10010-29 Matches latencies from 10-19ms
<rtr-id>:10020-39 Matches latencies from 20-29ms

…and so on.

Then match those communities in a route-map (using regex), setting a decrementing local-pref per bucket (e.g. 1000, 990, 980, etc…). And you just update the communities (e.g. non-additive) when re-advertising.

You’d lose granularity with this, but you honestly don’t want to really differentiate at single digit delays, since that could lead to instability in routing.

What you lose in granular path selection ,you gain in extensibility. For instance, you can store jitter and interface load as other communities like this:

Community Usage
<rtr-id>:1xxxx Latency
<rtr-id>:2xxxx Jitter
<rtr-id>:3xxxx Load

VyOS supports both OWAMP and TWAMP, which would be good for generating the delay and jitter metrics

1 Like