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.mate...@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 >
