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?
That is correct. It should be possible in some next version in both
current lines (2 and 3) in near future, now it simply doesn't work.
M.
Em qui., 24 de mar. de 2022 04:41, Maria Matejka <maria.mate...@nic.cz
<mailto: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 <http://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 <http://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
