Route matching filter not exported
Hello bird users, I've a strange case in which a router does not export routes that are matched by the export filter. I am using the filter "static_and_bgp" inside our iBGP sessions: -------------------------------------------------------------------------------- bird> show protocol all ibgp_server137 Name Proto Table State Since Info ibgp_server137 BGP --- up 2024-05-12 Established BGP state: Established Neighbor address: 2a0a:e5c0:0:b::89 Neighbor AS: 199553 Local AS: 199553 Neighbor ID: 91.194.139.7 Local capabilities Multiprotocol AF announced: ipv4 ipv6 Route refresh Extended next hop IPv6 nexthop: ipv4 Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Neighbor capabilities Multiprotocol AF announced: ipv4 ipv6 Route refresh Extended next hop IPv6 nexthop: ipv4 Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Session: internal AS4 Source address: 2a0a:e5c0:0:b::91 Hold timer: 197.601/240 Keepalive timer: 4.476/80 Channel ipv6 State: UP Table: master6 Preference: 100 Input filter: ACCEPT Output filter: static_and_bgp Routes: 204647 imported, 2 exported, 204647 preferred Route change stats: received rejected filtered ignored accepted Import updates: 6285634 0 0 3097 6282537 Import withdraws: 3559063 0 --- 189 3558874 Export updates: 6768067 6387362 37995 --- 342710 Export withdraws: 3370586 --- --- --- 334365 BGP Next hop: 2a0a:e5c0:0:b::91 fe80::2f0:cbff:fefe:b70c IGP IPv6 table: master6 Channel ipv4 State: UP Table: master4 Preference: 100 Input filter: ACCEPT Output filter: static_and_bgp Routes: 947321 imported, 3 exported, 947318 preferred Route change stats: received rejected filtered ignored accepted Import updates: 22332349 0 0 2202 22330147 Import withdraws: 15475598 0 --- 343 15475255 Export updates: 24213451 22602108 0 --- 1611343 Export withdraws: 14527850 --- --- --- 1598351 BGP Next hop: 2a0a:e5c0:0:b::91 fe80::2f0:cbff:fefe:b70c IGP IPv4 table: master4 IGP IPv6 table: master6 -------------------------------------------------------------------------------- As you can see, the router in question only exports 2 IPv6 routes and 3 IPv4 routes and uses the filter "static_and_bgp". When I check the route count matching the filter, the numbers look very different: -------------------------------------------------------------------------------- bird> show route filter static_and_bgp count 2841971 of 2841971 routes for 947325 networks in table master4 613945 of 613983 routes for 204686 networks in table master6 Total: 3455916 of 3455954 routes for 1152011 networks in 2 tables bird> -------------------------------------------------------------------------------- And looking at some routes in detail: -------------------------------------------------------------------------------- bird> show route filter static_and_bgp Table master4: 0.0.0.0/0 unicast [ibgp_server137 11:03:59.224 from 2a0a:e5c0:0:b::89] * (100/?) [AS209898i] via fe80::3eec:efff:fed2:d1e4 on eth0 unicast [outgoing_server120 08:53:28.568] (100) [AS209898i] via 2a0a:e5c0:31:4::1 on tun1 unicast [outgoing_server121 08:55:44.577] (100) [AS209898i] via 2a0a:e5c0:32:4::1 on tun0 49.14.107.0/24 unicast [ibgp_server137 11:03:59.224 from 2a0a:e5c0:0:b::89] * (100/?) [AS45271i] via fe80::3eec:efff:fed2:d1e4 on eth0 unicast [outgoing_server120 08:55:43.482] (100) [AS45271i] via 2a0a:e5c0:31:4::1 on tun1 unicast [outgoing_server121 08:55:44.577] (100) [AS45271i] via 2a0a:e5c0:32:4::1 on tun0 181.123.200.0/22 unicast [ibgp_server137 11:03:59.224 from 2a0a:e5c0:0:b::89] * (100/?) [AS23201i] via fe80::3eec:efff:fed2:d1e4 on eth0 unicast [outgoing_server120 08:55:30.698] (100) [AS23201i] via 2a0a:e5c0:31:4::1 on tun1 unicast [outgoing_server121 08:55:44.577] (100) [AS23201i] via 2a0a:e5c0:32:4::1 on tun0 88.218.186.0/24 unicast [ibgp_server137 11:03:59.224 from 2a0a:e5c0:0:b::89] * (100/?) [AS62240i] via fe80::3eec:efff:fed2:d1e4 on eth0 unicast [outgoing_server120 08:55:22.108] (100) [AS62240i] via 2a0a:e5c0:31:4::1 on tun1 unicast [outgoing_server121 08:55:44.577] (100) [AS62240i] via 2a0a:e5c0:32:4::1 on tun0 -------------------------------------------------------------------------------- I verified that 2a0a:e5c0:31:4::1 and 2a0a:e5c0:32:4::1 are resolvable via OSPF on the other routers: -------------------------------------------------------------------------------- bird> show route for 2a0a:e5c0:32:4::1 Table master6: 2a0a:e5c0:32:4::/64 unicast [ospf6 2024-05-12] * I (150/20) [91.194.139.99] via fe80::2f0:cbff:fefe:b70c on eth2 unicast [outgoing_server120 11:11:16.933] (100) [AS209898i] via 2a0a:e5c0:31:2::1 on oserver120 bird> -------------------------------------------------------------------------------- But this should not matter at this stage, because the originating router does not seem to try to send this route. What am I missing, why is a route matching the same filter not being exported? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch
Hello, Just curious. You've done "reload out" to your session after changing the filter, right? Regards, Alexander On Fri, May 17, 2024 at 4:45 PM Nico Schottelius via Bird-users <bird-users@network.cz> wrote:
Hello bird users,
I've a strange case in which a router does not export routes that are matched by the export filter. I am using the filter "static_and_bgp" inside our iBGP sessions:
-------------------------------------------------------------------------------- bird> show protocol all ibgp_server137 Name Proto Table State Since Info ibgp_server137 BGP --- up 2024-05-12 Established BGP state: Established Neighbor address: 2a0a:e5c0:0:b::89 Neighbor AS: 199553 Local AS: 199553 Neighbor ID: 91.194.139.7 Local capabilities Multiprotocol AF announced: ipv4 ipv6 Route refresh Extended next hop IPv6 nexthop: ipv4 Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Neighbor capabilities Multiprotocol AF announced: ipv4 ipv6 Route refresh Extended next hop IPv6 nexthop: ipv4 Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Session: internal AS4 Source address: 2a0a:e5c0:0:b::91 Hold timer: 197.601/240 Keepalive timer: 4.476/80 Channel ipv6 State: UP Table: master6 Preference: 100 Input filter: ACCEPT Output filter: static_and_bgp Routes: 204647 imported, 2 exported, 204647 preferred Route change stats: received rejected filtered ignored accepted Import updates: 6285634 0 0 3097 6282537 Import withdraws: 3559063 0 --- 189 3558874 Export updates: 6768067 6387362 37995 --- 342710 Export withdraws: 3370586 --- --- --- 334365 BGP Next hop: 2a0a:e5c0:0:b::91 fe80::2f0:cbff:fefe:b70c IGP IPv6 table: master6 Channel ipv4 State: UP Table: master4 Preference: 100 Input filter: ACCEPT Output filter: static_and_bgp Routes: 947321 imported, 3 exported, 947318 preferred Route change stats: received rejected filtered ignored accepted Import updates: 22332349 0 0 2202 22330147 Import withdraws: 15475598 0 --- 343 15475255 Export updates: 24213451 22602108 0 --- 1611343 Export withdraws: 14527850 --- --- --- 1598351 BGP Next hop: 2a0a:e5c0:0:b::91 fe80::2f0:cbff:fefe:b70c IGP IPv4 table: master4 IGP IPv6 table: master6 --------------------------------------------------------------------------------
As you can see, the router in question only exports 2 IPv6 routes and 3 IPv4 routes and uses the filter "static_and_bgp".
When I check the route count matching the filter, the numbers look very different:
-------------------------------------------------------------------------------- bird> show route filter static_and_bgp count 2841971 of 2841971 routes for 947325 networks in table master4 613945 of 613983 routes for 204686 networks in table master6 Total: 3455916 of 3455954 routes for 1152011 networks in 2 tables bird> --------------------------------------------------------------------------------
And looking at some routes in detail:
-------------------------------------------------------------------------------- bird> show route filter static_and_bgp Table master4: 0.0.0.0/0 unicast [ibgp_server137 11:03:59.224 from 2a0a:e5c0:0:b::89] * (100/?) [AS209898i] via fe80::3eec:efff:fed2:d1e4 on eth0 unicast [outgoing_server120 08:53:28.568] (100) [AS209898i] via 2a0a:e5c0:31:4::1 on tun1 unicast [outgoing_server121 08:55:44.577] (100) [AS209898i] via 2a0a:e5c0:32:4::1 on tun0 49.14.107.0/24 unicast [ibgp_server137 11:03:59.224 from 2a0a:e5c0:0:b::89] * (100/?) [AS45271i] via fe80::3eec:efff:fed2:d1e4 on eth0 unicast [outgoing_server120 08:55:43.482] (100) [AS45271i] via 2a0a:e5c0:31:4::1 on tun1 unicast [outgoing_server121 08:55:44.577] (100) [AS45271i] via 2a0a:e5c0:32:4::1 on tun0 181.123.200.0/22 unicast [ibgp_server137 11:03:59.224 from 2a0a:e5c0:0:b::89] * (100/?) [AS23201i] via fe80::3eec:efff:fed2:d1e4 on eth0 unicast [outgoing_server120 08:55:30.698] (100) [AS23201i] via 2a0a:e5c0:31:4::1 on tun1 unicast [outgoing_server121 08:55:44.577] (100) [AS23201i] via 2a0a:e5c0:32:4::1 on tun0 88.218.186.0/24 unicast [ibgp_server137 11:03:59.224 from 2a0a:e5c0:0:b::89] * (100/?) [AS62240i] via fe80::3eec:efff:fed2:d1e4 on eth0 unicast [outgoing_server120 08:55:22.108] (100) [AS62240i] via 2a0a:e5c0:31:4::1 on tun1 unicast [outgoing_server121 08:55:44.577] (100) [AS62240i] via 2a0a:e5c0:32:4::1 on tun0 --------------------------------------------------------------------------------
I verified that 2a0a:e5c0:31:4::1 and 2a0a:e5c0:32:4::1 are resolvable via OSPF on the other routers:
-------------------------------------------------------------------------------- bird> show route for 2a0a:e5c0:32:4::1 Table master6: 2a0a:e5c0:32:4::/64 unicast [ospf6 2024-05-12] * I (150/20) [91.194.139.99] via fe80::2f0:cbff:fefe:b70c on eth2 unicast [outgoing_server120 11:11:16.933] (100) [AS209898i] via 2a0a:e5c0:31:2::1 on oserver120 bird> --------------------------------------------------------------------------------
But this should not matter at this stage, because the originating router does not seem to try to send this route.
What am I missing, why is a route matching the same filter not being exported?
Best regards,
Nico
-- Sustainable and modern Infrastructures by ungleich.ch
OK, I see that routes you showed have best from protocol ibgp. So I suppose they received from ibgp peer, and your are sending them to ibgp peer too. That is not allowed by default. On Fri, May 17, 2024, 17:00 Nico Schottelius <nico.schottelius@ungleich.ch> wrote:
Ciao Alexander,
Alexander Zubkov <green@qrator.net> writes:
Hello,
Just curious. You've done "reload out" to your session after changing the filter, right?
this is a very good point, but in this case the whole bird daemon is restarted, so this should not be an issue.
BR,
Nico
Hello Alexander, the route is received via eBGP and should be redistributed via iBGP: bird> show route all 49.14.107.0/24 Table master4: 49.14.107.0/24 unicast [outgoing_server120 16:13:14.594] * (100) [AS45271i] via 2a0a:e5c0:31:4::1 on tun1 Type: BGP univ BGP.origin: IGP BGP.as_path: 209898 15576 3356 55644 45271 BGP.next_hop: 2a0a:e5c0:31:4::1 fe80::2010:be9e:ed5f:ea08 BGP.local_pref: 50 BGP.atomic_aggr: BGP.aggregator: 10.100.230.241 AS65010 BGP.community: (3356,2) (3356,22) (3356,100) (3356,123) (3356,502) (3356,903) (3356,2112) (15576,100) (15576,102) (15576,1000) BGP.otc: 209898 unicast [outgoing_server121 16:13:14.700] (100) [AS45271i] via 2a0a:e5c0:32:4::1 on tun0 Type: BGP univ BGP.origin: IGP BGP.as_path: 209898 15576 3356 55644 45271 BGP.next_hop: 2a0a:e5c0:32:4::1 fe80::5cd3:b71c:f90a:b469 BGP.local_pref: 50 BGP.atomic_aggr: BGP.aggregator: 10.100.230.241 AS65010 BGP.community: (3356,2) (3356,22) (3356,100) (3356,123) (3356,502) (3356,903) (3356,2112) (15576,100) (15576,102) (15576,1000) BGP.otc: 209898 The only difference to other routers is that the bgp local preference is 50, but from my understanding it should still be exported via iBGP. BR, Nico Alexander Zubkov <green@qrator.net> writes:
OK, I see that routes you showed have best from protocol ibgp. So I suppose they received from ibgp peer, and your are sending them to ibgp peer too. That is not allowed by default.
On Fri, May 17, 2024, 17:00 Nico Schottelius <nico.schottelius@ungleich.ch> wrote:
Ciao Alexander,
Alexander Zubkov <green@qrator.net> writes:
Hello,
Just curious. You've done "reload out" to your session after changing the filter, right?
this is a very good point, but in this case the whole bird daemon is restarted, so this should not be an issue.
BR,
Nico
-- Sustainable and modern Infrastructures by ungleich.ch
That looks different from the output in the first email. There best routes were received not only from ibgp, but from the same peer, so it seems ok that they were not sent back. For this output you have now session with your ibgp peer eatablished, but it still do not see the routes. Localpref should not affect exporting directly, yes. It can alter the best route, which will be considered for exporting. On Fri, May 17, 2024, 18:36 Nico Schottelius <nico.schottelius@ungleich.ch> wrote:
Hello Alexander,
the route is received via eBGP and should be redistributed via iBGP:
bird> show route all 49.14.107.0/24 Table master4: 49.14.107.0/24 unicast [outgoing_server120 16:13:14.594] * (100) [AS45271i] via 2a0a:e5c0:31:4::1 on tun1 Type: BGP univ BGP.origin: IGP BGP.as_path: 209898 15576 3356 55644 45271 BGP.next_hop: 2a0a:e5c0:31:4::1 fe80::2010:be9e:ed5f:ea08 BGP.local_pref: 50 BGP.atomic_aggr: BGP.aggregator: 10.100.230.241 AS65010 BGP.community: (3356,2) (3356,22) (3356,100) (3356,123) (3356,502) (3356,903) (3356,2112) (15576,100) (15576,102) (15576,1000) BGP.otc: 209898 unicast [outgoing_server121 16:13:14.700] (100) [AS45271i] via 2a0a:e5c0:32:4::1 on tun0 Type: BGP univ BGP.origin: IGP BGP.as_path: 209898 15576 3356 55644 45271 BGP.next_hop: 2a0a:e5c0:32:4::1 fe80::5cd3:b71c:f90a:b469 BGP.local_pref: 50 BGP.atomic_aggr: BGP.aggregator: 10.100.230.241 AS65010 BGP.community: (3356,2) (3356,22) (3356,100) (3356,123) (3356,502) (3356,903) (3356,2112) (15576,100) (15576,102) (15576,1000) BGP.otc: 209898
The only difference to other routers is that the bgp local preference is 50, but from my understanding it should still be exported via iBGP.
BR,
Nico
Alexander Zubkov <green@qrator.net> writes:
OK, I see that routes you showed have best from protocol ibgp. So I suppose they received from ibgp peer, and your are sending them to ibgp peer too. That is not allowed by default.
On Fri, May 17, 2024, 17:00 Nico Schottelius < nico.schottelius@ungleich.ch> wrote:
Ciao Alexander,
Alexander Zubkov <green@qrator.net> writes:
Hello,
Just curious. You've done "reload out" to your session after changing the filter, right?
this is a very good point, but in this case the whole bird daemon is restarted, so this should not be an issue.
BR,
Nico
-- Sustainable and modern Infrastructures by ungleich.ch
I've a question to the list in regards to iBGP behaviour: - the router in question imports all routes with a bgp_local_pref of 50 [A] - the other routers import eBGP routes with a bgp_local_pref of 100 [B] - my assumption would be that the lower preference route would propagated via iBGP, however that is not the case - the above router also receive the higher preference routes via iBGP Is the default iBGP behaviour to *not* export routes with lower preference to other routers? That would explain the behaviour I see. Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch
Say you have router A having routes with localpref 50, and router B with localpref 100. When A receives a prefix from B, it will be the best in A's table. Router A will not try to propagate routes with localpref 50, because only the best route are propagated (usually). And as the best route is that was received from B, then B will get nothing back. On Fri, May 17, 2024, 19:16 Nico Schottelius <nico.schottelius@ungleich.ch> wrote:
I've a question to the list in regards to iBGP behaviour:
- the router in question imports all routes with a bgp_local_pref of 50 [A] - the other routers import eBGP routes with a bgp_local_pref of 100 [B] - my assumption would be that the lower preference route would propagated via iBGP, however that is not the case - the above router also receive the higher preference routes via iBGP
Is the default iBGP behaviour to *not* export routes with lower preference to other routers? That would explain the behaviour I see.
Best regards,
Nico
-- Sustainable and modern Infrastructures by ungleich.ch
participants (2)
-
Alexander Zubkov -
Nico Schottelius