Hi! The primary route in BIRD, marked by '*', confuses me. Consider the following two default routes as displayed by BIRD (2.0.2) and the Linux kernel (4.14.51+). bird> show route Table master4: 0.0.0.0/0 unicast [ospf1 19:54:43.687] * E1 (110/350) [172.20.4.41] via 172.20.4.41 on p1-1-1-1-2 unicast [kernel1 19:47:39.563] (40) via 172.20.0.1 on eth1 # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.20.0.1 0.0.0.0 UG 0 0 0 eth1 0.0.0.0 172.20.4.41 0.0.0.0 UG 32 0 0 p1-1-1-1-2 BIRD shows that the OSPF route with administrative distance of 110 is primary, and not the kernel route with administrative distance of 40. When BIRD pushes the OSPF route to the kernel, it uses the metric 32 by default, whereas the default kernel route has metric 0. Both routes are installed to the FIB, but the kernel will elect the route via eth1. Why is not the default route over eth1 shown as primary in BIRD? Can we control if BIRD pushes the OSPF route into the kernel here? The kernel already has a more preferred default route. Thanks, Kenth
On Fri, Sep 21, 2018 at 06:51:17AM +0000, Kenth Eriksson wrote:
Hi!
The primary route in BIRD, marked by '*', confuses me. Consider the following two default routes as displayed by BIRD (2.0.2) and the Linux kernel (4.14.51+).
bird> show route Table master4: 0.0.0.0/0 unicast [ospf1 19:54:43.687] * E1 (110/350) [172.20.4.41] via 172.20.4.41 on p1-1-1-1-2 unicast [kernel1 19:47:39.563] (40) via 172.20.0.1 on eth1
# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.20.0.1 0.0.0.0 UG 0 0 0 eth1 0.0.0.0 172.20.4.41 0.0.0.0 UG 32 0 0 p1-1-1-1-2
BIRD shows that the OSPF route with administrative distance of 110 is primary, and not the kernel route with administrative distance of 40.
Hi BIRD on Linux cannot overwrite alien/kernel routes in kernel routing table. It uses kernel metric 32 to avoid collisions with them.
When BIRD pushes the OSPF route to the kernel, it uses the metric 32 by default, whereas the default kernel route has metric 0. Both routes are installed to the FIB, but the kernel will elect the route via eth1. Why is not the default route over eth1 shown as primary in BIRD?
That is because kernel protocol has low preference. Set it to higher value. Set preference for kernel protocol to higher value than OSPF. I see you have 40 and 110, which are not default values anyway.
Can we control if BIRD pushes the OSPF route into the kernel here? The kernel already has a more preferred default route.
If kernel route wins in BIRD table, then OSPF route will not be pushed to kernel. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Fri, 2018-09-21 at 12:44 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Fri, Sep 21, 2018 at 06:51:17AM +0000, Kenth Eriksson wrote:
Hi!
The primary route in BIRD, marked by '*', confuses me. Consider the following two default routes as displayed by BIRD (2.0.2) and the Linux kernel (4.14.51+).
bird> show route Table master4: 0.0.0.0/0 unicast [ospf1 19:54:43.687] * E1 (110/350) [172.20.4.41] via 172.20.4.41 on p1-1-1-1-2 unicast [kernel1 19:47:39.563] (40) via 172.20.0.1 on eth1
# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.20.0.1 0.0.0.0 UG 0 0 0 eth1 0.0.0.0 172.20.4.41 0.0.0.0 UG 32 0 0 p1-1-1-1-2
BIRD shows that the OSPF route with administrative distance of 110 is primary, and not the kernel route with administrative distance of 40.
Hi
BIRD on Linux cannot overwrite alien/kernel routes in kernel routing table. It uses kernel metric 32 to avoid collisions with them.
When BIRD pushes the OSPF route to the kernel, it uses the metric 32 by default, whereas the default kernel route has metric 0. Both routes are installed to the FIB, but the kernel will elect the route via eth1. Why is not the default route over eth1 shown as primary in BIRD?
That is because kernel protocol has low preference. Set it to higher value. Set preference for kernel protocol to higher value than OSPF. I see you have 40 and 110, which are not default values anyway.
So the preference value in BIRD is not the same as administrative distance? I believe both Juniper and Cisco treats lower preference value / administrative distance value as a more preferred route. https://www.juniper.net/documentation/en_US/junos/topics/reference/general/r... Is preference value inverted in BIRD?
Can we control if BIRD pushes the OSPF route into the kernel here? The kernel already has a more preferred default route.
If kernel route wins in BIRD table, then OSPF route will not be pushed to kernel.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Fri, Sep 21, 2018 at 11:58:41AM +0000, Kenth Eriksson wrote:
So the preference value in BIRD is not the same as administrative distance? I believe both Juniper and Cisco treats lower preference value / administrative distance value as a more preferred route.
https://www.juniper.net/documentation/en_US/junos/topics/reference/general/r...
Is preference value inverted in BIRD?
It has same position/usage as administrative distance in Juniper/Cisco, but it is inverted (lower is better) relative to them. Generally, for property called 'metric' or 'distance' it makes sense that lower is better, while for 'preference' it makes sense that higher is better, it this sense Cisco and BIRD have it in natural way, while Juniper has it inverted. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Fri, 2018-09-21 at 15:52 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Fri, Sep 21, 2018 at 11:58:41AM +0000, Kenth Eriksson wrote:
So the preference value in BIRD is not the same as administrative distance? I believe both Juniper and Cisco treats lower preference value / administrative distance value as a more preferred route.
https://www.juniper.net/documentation/en_US/junos/topics/reference/general/r...
Is preference value inverted in BIRD?
It has same position/usage as administrative distance in Juniper/Cisco, but it is inverted (lower is better) relative to them.
Generally, for property called 'metric' or 'distance' it makes sense that lower is better, while for 'preference' it makes sense that higher is better, it this sense Cisco and BIRD have it in natural way, while Juniper has it inverted.
I believe Cisco uses administrative distance, which is inverted from how BIRD has defined its preference value. This wiki article has a table for Cisco AD. https://en.wikipedia.org/wiki/Administrative_distance I still think BIRD confuses a user here (at least me). Consider the following route in BIRD; 172.20.4.41/32 unicast [ospf1 2018-09-21] * I (110/50) [172.20.4.41] via 172.20.4.41 on p1-1-1-1-2 The preference value is 110 and higher is better. The OSPF metric is 50 and lower is better. If BIRD were to use administrative distance instead of preference, then you know that lower is always better. Any plans to support AD? Thanks, Kenth
On September 24, 2018 10:00:05 AM GMT+02:00, Kenth Eriksson <Kenth.Eriksson@infinera.com> wrote:
On Fri, 2018-09-21 at 15:52 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Fri, Sep 21, 2018 at 11:58:41AM +0000, Kenth Eriksson wrote:
So the preference value in BIRD is not the same as administrative distance? I believe both Juniper and Cisco treats lower preference value / administrative distance value as a more preferred route.
https://www.juniper.net/documentation/en_US/junos/topics/reference/general/r...
Is preference value inverted in BIRD?
It has same position/usage as administrative distance in Juniper/Cisco, but it is inverted (lower is better) relative to them.
Generally, for property called 'metric' or 'distance' it makes sense that lower is better, while for 'preference' it makes sense that higher is better, it this sense Cisco and BIRD have it in natural way, while Juniper has it inverted.
I believe Cisco uses administrative distance, which is inverted from how BIRD has defined its preference value. This wiki article has a table for Cisco AD.
https://en.wikipedia.org/wiki/Administrative_distance
I still think BIRD confuses a user here (at least me). Consider the following route in BIRD;
172.20.4.41/32 unicast [ospf1 2018-09-21] * I (110/50) [172.20.4.41] via 172.20.4.41 on p1-1-1-1-2
The preference value is 110 and higher is better. The OSPF metric is 50 and lower is better. If BIRD were to use administrative distance instead of preference, then you know that lower is always better.
BGP LOCAL_PREF is the higher the better. There is no worldwide consensus, even in BGP there is MED which is the lower the better. We might even vote what is better, whether the lower or the higher value. So the original developers of BIRD wisely chose one of these two approaches. I don't know whether they had long discussions before or they just wisely flipped a coin. I don't even know how this was solved in Cisco in 1998 and whether they knew it and did it as a kind of strange vendor lock in or whatever else. I don't think that the development time is worth the outcome. Taking into account that there are many users who would need to change their filters because of this backwards incompatible change, it is an utter nonsense to ever do it. Showing 110/50 is confusing, anyway, we can show it in a better way to not confuse the user. Could you please suggest a better format or even send in a patch? This is quite easy to change in ospf_get_route_info() in file proto/ospf/ospf.c We also don't have the keyword AD in our docs so it may be a problem for people coming from Cisco. If you could send a docs patch (doc/bird.sgml) to mention it and point to the preference, you're also welcome.
Any plans to support AD?
Not at this moment. This feature would be redundant to preference, wouldn't it? Maria
participants (3)
-
Kenth Eriksson -
Maria Jan Matějka -
Ondrej Zajicek