Hello, I found a strange behaviour on my BIRD route reflector: BIRD version: 2.0.7 Topology: ------ vrr01_ny2_nyc RR1 || ------ vrr01_pa4_par ---- CORE1 I have one route A.A.A.A received via two other Router reflector (vrr01_ny2_nyc / vrr01_pa4_par) The origin of the route is 185.x.x.x $ birdc show route A.A.A.A/32 table ipv4_rr all BIRD 2.0.7 ready. Table ipv4_rr: A.A.A.A/32 unicast [ipv4_vrr01_ny2_nyc 00:54:45.006 from 100.100.254.133] * (100/67955) [AS65030?] via 100.99.0.120 on eth2.666 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 64655 65030 BGP.next_hop: 185.x.x.x BGP.local_pref: 100 BGP.community: (35280,843) (35280,844) (35280,1010) (35280,2060) (35280,3070) BGP.originator_id: 185.x.x.x BGP.cluster_list: 0.0.0.21 0.0.0.11 unicast [ipv4_vrr01_pa4_par 2022-04-14 from 100.100.254.134] (100/68045) [AS65030?] via 100.99.0.120 on eth2.666 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 64655 65030 BGP.next_hop: 185.x.x.x BGP.local_pref: 100 BGP.community: (35280,843) (35280,844) (35280,1010) (35280,2060) (35280,3070) BGP.originator_id: 185.x.x.x BGP.cluster_list: 0.0.0.11 I check the metric to 185.x.x.x and I see 67955, but on my second route (learned via vrr01_pa4_par), I see another value (68045) $ birdc show route 185.x.x.x BIRD 2.0.7 ready. Table master4: 185.x.x.x /32 unicast [ospfv2 23:56:36.331] I (150/67955) [185.x.x.x] via 100.99.0.120 on eth2.666 Can you help me to understand the behaviour? I don’t understand why the second route is not preferred as the cluster_list is smaller (probably the BGP algorithm in BIRD). More information $ birdc show route 100.100.254.133/32 BIRD 2.0.7 ready. Table master4: 100.100.254.133/32 unicast [ospfv2 2022-04-20] I (150/133525) [100.100.254.133] via 100.99.0.120 on eth2.666 $ birdc show route 100.100.254.134/32 BIRD 2.0.7 ready. Table master4: 100.100.254.134/32 unicast [ospfv2 2022-04-20] I (150/132615) [100.100.254.134] via 100.99.0.120 on eth2.666 Part of the configuration (same for the 2 peers) protocol bgp ipv4_vrr01_ny2_nyc from IPV4_RR_PEER { description "IPv4 vrr01.ny2.nyc"; neighbor 100.100.254.133; ipv4 { import filter bgp_in_rr_v4; export filter bgp_full_view_v4; }; } protocol bgp ipv4_vrr01_pa4_par from IPV4_RR_PEER { description "IPv4 vrr01.pa4.par"; neighbor 100.100.254.134; ipv4 { import filter bgp_in_rr_v4; export filter bgp_full_view_v4; }; } Does somebody have the full BGP algorithm? Alexandre Corso AS35280
Am 26.04.22 um 04:57 schrieb Alexandre Corso:
Does somebody have the full BGP algorithm?
The BIRD documentation covers it in section "Route selection rules" of https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.3 Regards -- Robert Sander Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 220009 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin
On Tue, Apr 26, 2022 at 10:57:16AM +0800, Alexandre Corso wrote:
Hello,
I found a strange behaviour on my BIRD route reflector:
BIRD version: 2.0.7 Topology: ------ vrr01_ny2_nyc RR1 || ------ vrr01_pa4_par ---- CORE1
I have one route A.A.A.A received via two other Router reflector (vrr01_ny2_nyc / vrr01_pa4_par) The origin of the route is 185.x.x.x
$ birdc show route A.A.A.A/32 table ipv4_rr all BIRD 2.0.7 ready. Table ipv4_rr: A.A.A.A/32 unicast [ipv4_vrr01_ny2_nyc 00:54:45.006 from 100.100.254.133] * (100/67955) [AS65030?] via 100.99.0.120 on eth2.666 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 64655 65030 BGP.next_hop: 185.x.x.x BGP.local_pref: 100 BGP.community: (35280,843) (35280,844) (35280,1010) (35280,2060) (35280,3070) BGP.originator_id: 185.x.x.x BGP.cluster_list: 0.0.0.21 0.0.0.11 unicast [ipv4_vrr01_pa4_par 2022-04-14 from 100.100.254.134] (100/68045) [AS65030?] via 100.99.0.120 on eth2.666 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 64655 65030 BGP.next_hop: 185.x.x.x BGP.local_pref: 100 BGP.community: (35280,843) (35280,844) (35280,1010) (35280,2060) (35280,3070) BGP.originator_id: 185.x.x.x BGP.cluster_list: 0.0.0.11
I check the metric to 185.x.x.x and I see 67955, but on my second route (learned via vrr01_pa4_par), I see another value (68045)
$ birdc show route 185.x.x.x BIRD 2.0.7 ready. Table master4: 185.x.x.x /32 unicast [ospfv2 23:56:36.331] I (150/67955) [185.x.x.x] via 100.99.0.120 on eth2.666
Can you help me to understand the behaviour? I don’t understand why the second route is not preferred as the cluster_list is smaller (probably the BGP algorithm in BIRD).
Hello Generally, lengths of cluster_lists are not that important, the IGP cost difference (67955 vs 68045) has higher priority. The main question is why they have different IGP cost if both have the same bgp_next_hop (if 185.x.x.x is the same for both routes). That may be a bug. Do you have some filters? Do you have more routes for 185.x.x.x? Do you use BGP import table? -- 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."
participants (3)
-
Alexandre Corso -
Ondrej Zajicek -
Robert Sander