Maybe I'm getting confused... But in other engines I basically use MED as an inheritance from igp_metric. Combine that with cumulative med, and that's all I've needed to get by so far. I honestly don't remember ever looking at igp_metric as something other than MED.
But maybe that's an overly simplistic view on my part. Em sex., 14 de mar. de 2025 às 06:58, Maria Matejka via Bird-users < [email protected]> escreveu: > Dear BIRD users, > > we’d like to do a public survey about naming things. In short, there are > two different route attributes in BIRD 2: > > - The whole route’s total metric from here to the destination, if set > explicitly by igp_metric = N in filters. I.e., a generic alternative > to protocol-specific IGP metrics like ospf_metric1 or babel_metric. > - Metric of the route’s part between here and bgp_next_hop, determined > by recursive next hop resolution. I.e., from > that route which resolved the recursive next hop, the value in the > first meaning of igp_metric is taken and stored here. > > *Both of these two attributes are internally named igp_metric in BIRD 2.* > However, only the first one is accessible by filters. When rewriting the > attribute handling code for BIRD 3, I merged them together. This is > technically not a bug per se and for now, yet it behaves weirdly in corner > cases and confuses people. > > We plan to split these attributes back in BIRD 3, but we don’t want (and > technically also can’t) use the same name any more. > > *How to name these two attributes better?* > > Looking forward to your suggestions and opinions. > > Happy routing! > Maria and the BIRD Team > ------------------------------ > > Follows longer explanation on IGP metric, feel free to skip that. > > What’s the IGP metric? Let’s consider an iBGP route, received from a BGP > peer in the same AS, via a multihop session. This route’s next hop is often > not locally known and has to be resolved by finding a matching route (let’s > call that route an IGP route) and using that route’s nexthop, as expected > by RFC 4271, section 5.1.3. We call such a situation “recursive nexthop”. > > Such a route pair then may look like follows (shortened): > > 2001:db8:2::/48 unicast [ibgp3 <removed> from 10.1.4.1] * (100/40) > [AS65532i] > via fe80::386c:8fff:feb8:206c on ve1 > hostentry: via 2001:db8:1:13::2 fe80::585b:d3ff:febd:1dd9 table > master6 > bgp_next_hop: 2001:db8:1:13::2 fe80::585b:d3ff:febd:1dd9 > igp_metric: 40 > source: BGP > 2001:db8:1:13::/64 unicast [ospf6 <removed>] * I (150/40) [10.0.1.4] > via fe80::386c:8fff:feb8:206c on ve1 > ospf_metric1: 40 > source: OSPF > > The bgp_next_hop attribute is non-local, and there is another route able > to resolve that attribute to the local next hop. That route’s metric is > transferred to the BGP route as igp_metric. In BIRD 2, that’s just an > internal value, displayed on the first line as (100/40), which is > preference (100) and the IGP metric (40). > > But you may also have a static route instead of the OSPF one: > > protocol static { > ipv6; > route 2001:db8:1:13::/64 via fe80::386c:8fff:feb8:206c dev ve1 { > igp_metric = 40; }; > } > > Here the igp_metric semantics is the whole route’s metric. This metric > can then be used in next hop resolution and applied to the BGP route. And > in the BGP route, there will be this igp_metric attribute copied, > representing only the metric from here to bgp_next_hop. > > – > Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o. > -- Douglas Fernando Fischer Engº de Controle e Automação
