Wow... I'm a bit surprised knowing that.

One scenario that I used in some customers is to used the IGP metric to populate the BGP MED. But I did it on Juniper, Huawei, and Cisco.
I never needed it on Bird.

By what you described, I presume.
If I can't test that IGP attribute, probably I also won't be able to pass that info to MED.

Does it makes sense?

Em qui., 24 de mar. de 2022 04:41, Maria Matejka <maria.matejka@nic.cz> escreveu:
Hello!

> Our routers speak OSPF and have a full mesh of BGP connections for our
> internal routes. This works quite well.
>
> One router sees the other through OSPF:
>
> 80.241.60.8/32     via 10.25.19.251 on bond0.19 [ospf1 2022-03-17] * I
> (150/2474) [80.241.60.8]
>          Type: OSPF unicast univ
>          OSPF.metric1: 2474
>          OSPF.metric2: 16777215
>          OSPF.tag: 0x00000000
>          OSPF.router_id: 80.241.60.8
>
> The BGP session is established to 80.241.60.8 and e.g. this route is
> learned:
>
> 192.168.100.0/22   via 10.25.19.251 on bond0.19 [thor 2022-03-17 from
> 80.241.60.8] * (100/2474) [i]
>          Type: BGP unicast univ
>          BGP.origin: IGP
>          BGP.as_path:
>          BGP.next_hop: 80.241.60.8
>          BGP.local_pref: 100
>
> In the first line the ospf_metric1 is shown: (100/2474)
> But when I try to filter on it (because I want to drop routes with a too
> high metric),
> the route attribute ospf_metric1 is "(void)".
>
> This seems to be because it's a BGP route and not an OSPF route.
>
> Is it somehow possible to achieve this?

The OSPF metric is copied there as an inaccessible "igp_metric"
attribute. This is quite a silly behavior and in fact, I'm just a
handful of commits before enabling filtering by this general attribute.

This change will happen in a branch that should eventually merge into
some future v2.0.x branch as well as the v3 branch. We won't backport it
into v1.6.x.

Maria