Fine then! I was suspicious about some changes in thread-next (where this
problem can be actually reproduced with a good probability) and now I know that
I should assess the whole algorithm instead.
Thanks a lot!
Maria
On October 7, 2022 11:29:09 AM UTC, Mihai wrote:
>Hi Maria,
>
>Yes you are
Hi Maria,
Yes you are correct, the metric is not a random value but an old value,
probably the first one after OSPF established.
It looks like any subsequent change in the OSPF topology/metrics is not
reflected in the BGP_NH metric.
Best regards,
Mihai
On 03/10/2022 12:43, Maria Matejka via
Hello!
I'd suspect the internal nexthop resolving mechanisms of missing the
OSPF route update. When working on the multithreaded version, I came
across a similar kind of bug and I honestly don't know yet how exactly
this may be broken.
That said, is it possible that the metric is just an obs
Hello,
The same issue on another RR, the BGP_Metric=60380 while the
OSPF_Metric=60315.
bird> sh route 10:10 202.81.16.0/24 all
Table vpntab4:
10:10 202.81.16.0/24 unicast [ROUTER2 2022-09-29 15:21:18 from
10.100.186.6] * (100/60380) [AS4826i]
Type: BGP univ
BGP.origin: IGP
Hello,
First I would like to thank you for this amazing software!
I am running Bird 2.0.7 as RR for L3VPNs and on one RR the OSPF metric
for the BGP NH is different than what's seen in BGP as shown below.
BGP PREF/METRIC = (100/61580) , OSPF_METRIC = 61480.
bird> sh route 10:10 94.207.96.0/
