Bird does not prefer older eBGP route - RFC5004 and "older prefer on"
Hello Bird users, Have you ever use RFC 5004 and “older prefer” knob. I am trying to use it but it seems not to work: 1.Router learns the same route from different ebgp peers, it prefers route from r01a and this route is exported to BGP peers 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 2023-06-14] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 2023-06-14] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 2023-06-14] (100) [AS4250627482?] via 192.168.196.133 on vlan.203 2.Once we lose links to r01a and r01b route from r02a is preferred and exported to BGP peers. It is expected 172.232.160.0/19 unicast [192.168.196.133__r02a.tor106 2023-06-14] * (100) [AS4250627482?] via 192.168.196.133 on vlan.203 3.When links to r01a and r01b. are again online route, route from r01a is pricked as primary and exported to BGP. It causes route oscillation 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:14:19.982] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 09:14:19.896] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 2023-06-14] (100) [AS4250627482?] via 192.168.196.133 on vlan.203 4.I believe it is default behavior not to prefer older path. According to documentation RFC 5004 and "prefer older on" should fix my problem, but it does not work. Bird doc says: prefer older switch Standard route selection algorithm breaks ties by comparing router IDs. This changes the behavior to prefer older routes (when both are external and from different peer). For details, see RFC 5004. Default: off. 5. According to documentation RFC 5004 and "prefer older on" should fix my problem, but it does not work. a) added "prefer older on", bgp flapped and routes were re-learnt 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:22:12.949] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 09:22:13.527] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 09:22:12.683] (100) [AS4250627482?] via 192.168.196.133 on vlan.203 b) shut links to r01a and r01b 172.232.160.0/19 unicast [192.168.196.133__r02a.tor106 09:22:12.683] * (100) [AS4250627482?] via 192.168.196.133 on vlan.203 c) unshut links to r01a and r01b, route from r01a is again preferred, so looks like "older" knob does not work 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:27:55.841] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 09:27:54.448] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 09:22:12.683] (100) [AS4250627482?]. ---> this route is older via 192.168.196.133 on vlan.203 Thanks, Dariusz
Hello! I suspect that the routes either aren't all external, or are otherwise compared different before it comes to breaking ties. Could you please share the `show route all` output to see all the relevant BGP attributes? Maria On 6/30/23 11:43, Mazur, Dariusz via Bird-users wrote:
Hello Bird users,
Have you ever use RFC 5004 and “older prefer” knob. I am trying to use it but it seems not to work:
*1.Router learns the same route from different ebgp peers, it prefers route from r01a and this route is exported to BGP peers*
172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 2023-06-14] * (100) [AS4250627481?]
via 192.168.196.129 on vlan.201
unicast [192.168.196.131__r01b.tor106 2023-06-14] (100) [AS4250627481?]
via 192.168.196.131 on vlan.202
unicast [192.168.196.133__r02a.tor106 2023-06-14] (100) [AS4250627482?]
via 192.168.196.133 on vlan.203
*2.Once we lose links to r01a and r01b route from r02a is preferred and exported to BGP peers. It is expected*
172.232.160.0/19 unicast [192.168.196.133__r02a.tor106 2023-06-14] * (100) [AS4250627482?]
via 192.168.196.133 on vlan.203
*3.When links to r01a and r01b. are again online route, route from r01a is pricked as primary and exported to BGP. It causes route oscillation*
172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:14:19.982] * (100) [AS4250627481?]
via 192.168.196.129 on vlan.201
unicast [192.168.196.131__r01b.tor106 09:14:19.896] (100) [AS4250627481?]
via 192.168.196.131 on vlan.202
unicast [192.168.196.133__r02a.tor106 2023-06-14] (100) [AS4250627482?]
via 192.168.196.133 on vlan.203
*4.I believe it is default behavior not to prefer older path. According to documentation RFC 5004 and "prefer older on" should fix my problem, but it does not work.*
Bird doc says:
/prefer older switch/
/Standard route selection algorithm breaks ties by comparing router IDs. This changes the behavior to prefer older routes (when both are external and from different peer). For details, see RFC 5004. Default: off./
*5. According to documentation RFC 5004 and "prefer older on" should fix my problem, but it does not work.*
*a) added "prefer older on", bgp flapped and routes were re-learnt*
172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:22:12.949] * (100) [AS4250627481?]
via 192.168.196.129 on vlan.201
unicast [192.168.196.131__r01b.tor106 09:22:13.527] (100) [AS4250627481?]
via 192.168.196.131 on vlan.202
unicast [192.168.196.133__r02a.tor106 09:22:12.683] (100) [AS4250627482?]
via 192.168.196.133 on vlan.203
*b) shut links to r01a and r01b*
*172.232.160.0/19 unicast [192.168.196.133__r02a.tor106 09:22:12.683] * (100) [AS4250627482?]*
* via 192.168.196.133 on vlan.203*
*c) unshut links to r01a and r01b, route from r01a is again preferred, so looks like "older" knob does not work*
172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:27:55.841] * (100) [AS4250627481?]
via 192.168.196.129 on vlan.201
unicast [192.168.196.131__r01b.tor106 09:27:54.448] (100) [AS4250627481?]
via 192.168.196.131 on vlan.202
unicast [192.168.196.133__r02a.tor106 09:22:12.683] (100) [AS4250627482?]. *---> this route is older*
via 192.168.196.133 on vlan.203
Thanks,
Dariusz
-- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
Hello Maria, Thanks for response. Attributes look the same. Maybe the problem is these routes are learnt via iBGP, what is not visible in "show route all' Our simplified topology looks like below: 1.Host_1 and Host_2 announces 172.232.160.0/19 2.Host_1 and Host_2 have different ASNs and they use eBGP to peer with ToRs 3.All tors are connected to r01.leaf over iBGP Host1----eBGP----r01a.tor----iBGP-----r01.leaf ----eBGP----r01b.tor----iBGP Host2----eBGP----r02a.tor----iBGP-----r01.leaf ----eBGP----r02b.tor----iBGP Show route all from r01.leaf 172.232.160.0/19 unicast [192.168.196.1__r01a.tor106 2023-06-30] * (100) [AS4250627481?] via 192.168.196.1 on vlan.201 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 4250627481 BGP.next_hop: 192.168.196.1 BGP.med: 0 BGP.local_pref: 400 BGP.atomic_aggr: BGP.aggregator: 23.219.179.225 AS4250627481 BGP.community: (63949,1000) (63949,1002) (63949,1004) (63949,1005) (65110,31107) (65310,31107) (65518,31107) unicast [192.168.196.3__r01b.tor106 2023-06-30] (100) [AS4250627481?] via 192.168.196.3 on vlan.202 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 4250627481 BGP.next_hop: 192.168.196.3 BGP.med: 0 BGP.local_pref: 400 BGP.atomic_aggr: BGP.aggregator: 23.219.179.225 AS4250627481 BGP.community: (63949,1000) (63949,1002) (63949,1004) (63949,1005) (65110,31107) (65310,31107) (65518,31107) unicast [192.168.196.5__r02a.tor106 2023-06-30] (100) [AS4250627482?] via 192.168.196.5 on vlan.203 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 4250627482 BGP.next_hop: 192.168.196.5 BGP.med: 0 BGP.local_pref: 400 BGP.atomic_aggr: BGP.aggregator: 23.219.179.226 AS4250627482 BGP.community: (63949,1000) (63949,1002) (63949,1004) (63949,1005) (65110,31107) (65310,31107) (65518,31107) unicast [192.168.196.7__r02b.tor106 2023-06-30] (100) [AS4250627482? via 192.168.196.7 on vlan.204 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 4250627482 BGP.next_hop: 192.168.196.7 BGP.med: 0 BGP.local_pref: 400 BGP.atomic_aggr: BGP.aggregator: 23.219.179.226 AS4250627482 BGP.community: (63949,1000) (63949,1002) (63949,1004) (63949,1005) (65110,31107) (65310,31107) (65518,31107) Thanks, Dariusz From: Maria Matejka via Bird-users <bird-users@network.cz> Reply-To: Maria Matejka <maria.matejka@nic.cz> Date: Friday, June 30, 2023 at 12:53 PM To: "bird-users@network.cz" <bird-users@network.cz> Subject: Re: Bird does not prefer older eBGP route - RFC5004 and "older prefer on" Hello! I suspect that the routes either aren't all external, or are otherwise compared different before it comes to breaking ties. Could you please share the `show route all` output to see all the relevant BGP attributes? Maria On 6/30/23 11:43, Mazur, Dariusz via Bird-users wrote: Hello Bird users, Have you ever use RFC 5004 and “older prefer” knob. I am trying to use it but it seems not to work: 1.Router learns the same route from different ebgp peers, it prefers route from r01a and this route is exported to BGP peers 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 2023-06-14] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 2023-06-14] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 2023-06-14] (100) [AS4250627482?] via 192.168.196.133 on vlan.203 2.Once we lose links to r01a and r01b route from r02a is preferred and exported to BGP peers. It is expected 172.232.160.0/19 unicast [192.168.196.133__r02a.tor106 2023-06-14] * (100) [AS4250627482?] via 192.168.196.133 on vlan.203 3.When links to r01a and r01b. are again online route, route from r01a is pricked as primary and exported to BGP. It causes route oscillation 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:14:19.982] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 09:14:19.896] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 2023-06-14] (100) [AS4250627482?] via 192.168.196.133 on vlan.203 4.I believe it is default behavior not to prefer older path. According to documentation RFC 5004 and "prefer older on" should fix my problem, but it does not work. Bird doc says: prefer older switch Standard route selection algorithm breaks ties by comparing router IDs. This changes the behavior to prefer older routes (when both are external and from different peer). For details, see RFC 5004. Default: off. 5. According to documentation RFC 5004 and "prefer older on" should fix my problem, but it does not work. a) added "prefer older on", bgp flapped and routes were re-learnt 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:22:12.949] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 09:22:13.527] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 09:22:12.683] (100) [AS4250627482?] via 192.168.196.133 on vlan.203 b) shut links to r01a and r01b 172.232.160.0/19 unicast [192.168.196.133__r02a.tor106 09:22:12.683] * (100) [AS4250627482?] via 192.168.196.133 on vlan.203 c) unshut links to r01a and r01b, route from r01a is again preferred, so looks like "older" knob does not work 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:27:55.841] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 09:27:54.448] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 09:22:12.683] (100) [AS4250627482?]. ---> this route is older via 192.168.196.133 on vlan.203 Thanks, Dariusz -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
Well yes, the "prefer older" works only for eBGP, as stated in RFC 5004. With iBGP, this isn't invoked as you may run into some nasty routing loops. If you need this feature, feel free to send in a patch. Maria On 7/3/23 13:46, Mazur, Dariusz wrote:
Hello Maria,
Thanks for response. Attributes look the same. Maybe the problem is these routes are learnt via iBGP, what is not visible in "show route all'
Our simplified topology looks like below:
1.Host_1 and Host_2 announces 172.232.160.0/19
2.Host_1 and Host_2 have different ASNs and they use eBGP to peer with ToRs
3.All tors are connected to r01.leaf over iBGP
Host1----eBGP----r01a.tor----iBGP-----r01.leaf
----eBGP----r01b.tor----iBGP
Host2----eBGP----r02a.tor----iBGP-----r01.leaf
----eBGP----r02b.tor----iBGP
Show route all from r01.leaf
172.232.160.0/19 unicast [192.168.196.1__r01a.tor106 2023-06-30] * (100) [AS4250627481?]
via 192.168.196.1 on vlan.201
Type: BGP univ
BGP.origin: Incomplete
BGP.as_path: 4250627481
BGP.next_hop: 192.168.196.1
BGP.med: 0
BGP.local_pref: 400
BGP.atomic_aggr:
BGP.aggregator: 23.219.179.225 AS4250627481
BGP.community: (63949,1000) (63949,1002) (63949,1004) (63949,1005) (65110,31107) (65310,31107) (65518,31107)
unicast [192.168.196.3__r01b.tor106 2023-06-30] (100) [AS4250627481?]
via 192.168.196.3 on vlan.202
Type: BGP univ
BGP.origin: Incomplete
BGP.as_path: 4250627481
BGP.next_hop: 192.168.196.3
BGP.med: 0
BGP.local_pref: 400
BGP.atomic_aggr:
BGP.aggregator: 23.219.179.225 AS4250627481
BGP.community: (63949,1000) (63949,1002) (63949,1004) (63949,1005) (65110,31107) (65310,31107) (65518,31107)
unicast [192.168.196.5__r02a.tor106 2023-06-30] (100) [AS4250627482?]
via 192.168.196.5 on vlan.203
Type: BGP univ
BGP.origin: Incomplete
BGP.as_path: 4250627482
BGP.next_hop: 192.168.196.5
BGP.med: 0
BGP.local_pref: 400
BGP.atomic_aggr:
BGP.aggregator: 23.219.179.226 AS4250627482
BGP.community: (63949,1000) (63949,1002) (63949,1004) (63949,1005) (65110,31107) (65310,31107) (65518,31107)
unicast [192.168.196.7__r02b.tor106 2023-06-30] (100) [AS4250627482?
via 192.168.196.7 on vlan.204
Type: BGP univ
BGP.origin: Incomplete
BGP.as_path: 4250627482
BGP.next_hop: 192.168.196.7
BGP.med: 0
BGP.local_pref: 400
BGP.atomic_aggr:
BGP.aggregator: 23.219.179.226 AS4250627482
BGP.community: (63949,1000) (63949,1002) (63949,1004) (63949,1005) (65110,31107) (65310,31107) (65518,31107)
Thanks,
Dariusz
*From: *Maria Matejka via Bird-users <bird-users@network.cz> *Reply-To: *Maria Matejka <maria.matejka@nic.cz> *Date: *Friday, June 30, 2023 at 12:53 PM *To: *"bird-users@network.cz" <bird-users@network.cz> *Subject: *Re: Bird does not prefer older eBGP route - RFC5004 and "older prefer on"
Hello!
I suspect that the routes either aren't all external, or are otherwise compared different before it comes to breaking ties. Could you please share the `show route all` output to see all the relevant BGP attributes?
Maria
On 6/30/23 11:43, Mazur, Dariusz via Bird-users wrote:
Hello Bird users,
Have you ever use RFC 5004 and “older prefer” knob. I am trying to use it but it seems not to work:
*1.Router learns the same route from different ebgp peers, it prefers route from r01a and this route is exported to BGP peers*
172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 2023-06-14] * (100) [AS4250627481?]
via 192.168.196.129 on vlan.201
unicast [192.168.196.131__r01b.tor106 2023-06-14] (100) [AS4250627481?]
via 192.168.196.131 on vlan.202
unicast [192.168.196.133__r02a.tor106 2023-06-14] (100) [AS4250627482?]
via 192.168.196.133 on vlan.203
*2.Once we lose links to r01a and r01b route from r02a is preferred and exported to BGP peers. It is expected*
172.232.160.0/19 unicast [192.168.196.133__r02a.tor106 2023-06-14] * (100) [AS4250627482?]
via 192.168.196.133 on vlan.203
*3.When links to r01a and r01b. are again online route, route from r01a is pricked as primary and exported to BGP. It causes route oscillation*
172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:14:19.982] * (100) [AS4250627481?]
via 192.168.196.129 on vlan.201
unicast [192.168.196.131__r01b.tor106 09:14:19.896] (100) [AS4250627481?]
via 192.168.196.131 on vlan.202
unicast [192.168.196.133__r02a.tor106 2023-06-14] (100) [AS4250627482?]
via 192.168.196.133 on vlan.203
*4.I believe it is default behavior not to prefer older path. According to documentation RFC 5004 and "prefer older on" should fix my problem, but it does not work.*
Bird doc says:
/prefer older switch/
/Standard route selection algorithm breaks ties by comparing router IDs. This changes the behavior to prefer older routes (when both are external and from different peer). For details, see RFC 5004. Default: off./
*5. According to documentation RFC 5004 and "prefer older on" should fix my problem, but it does not work.*
*a) added "prefer older on", bgp flapped and routes were re-learnt*
172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:22:12.949] * (100) [AS4250627481?]
via 192.168.196.129 on vlan.201
unicast [192.168.196.131__r01b.tor106 09:22:13.527] (100) [AS4250627481?]
via 192.168.196.131 on vlan.202
unicast [192.168.196.133__r02a.tor106 09:22:12.683] (100) [AS4250627482?]
via 192.168.196.133 on vlan.203
*b) shut links to r01a and r01b*
*172.232.160.0/19 unicast [192.168.196.133__r02a.tor106 09:22:12.683] * (100) [AS4250627482?]*
* via 192.168.196.133 on vlan.203*
*c) unshut links to r01a and r01b, route from r01a is again preferred, so looks like "older" knob does not work*
172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:27:55.841] * (100) [AS4250627481?]
via 192.168.196.129 on vlan.201
unicast [192.168.196.131__r01b.tor106 09:27:54.448] (100) [AS4250627481?]
via 192.168.196.131 on vlan.202
unicast [192.168.196.133__r02a.tor106 09:22:12.683] (100) [AS4250627482?]. *---> this route is older*
via 192.168.196.133 on vlan.203
Thanks,
Dariusz
-- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
-- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
participants (2)
-
Maria Matejka -
Mazur, Dariusz