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 Bird-users wrote:
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 obsolete value from
some previous route version?
Thanks for your report.
Maria
On 9/30/22 17:10, Mihai via Bird-users wrote:
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
BGP.as_path: 4826
BGP.next_hop: 10.100.186.6
bird> show route 10.100.186.6/32
Table master4:
10.100.186.6/32 unicast [OSPF 2022-09-30 15:01:51] IA (150/60315)
[10.100.186.4]
On 30/09/2022 09:08, Mihai wrote:
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/19 all primary
Table vpntab4:
10:10 94.207.96.0/19 unicast [ROUTER1 2022-09-28 00:10:09 from
10.100.186.1] * (100/61580) [AS15802i]
Type: BGP univ
BGP.origin: IGP
BGP.as_path: 15802
BGP.next_hop: 10.100.184.8
bird> sh route 10.100.184.8/32
Table master4:
10.100.184.8/32 unicast [OSPF 2022-09-29 12:33:35] IA
(150/61480) [10.100.186.5]
After restarting the BIRD OSPF adjancency the BGP metric changed to
61480.
Any help in understanding the issue would be much appreciated.
Thank you!
