March 2023 - Bird-users - Mailing Lists

Help with Route Reflector and BGP multipath.
by Arnaud Houdelette-Langlois 04 Mar '23

04 Mar '23

Hi. We are using bird for BGP/OSPF routing on our FreeBSD routers/firewalls for quite some time now. I'm trying to setup linux server load-balancing using ExaBGP, and bird as Route-Reflectors. Between the bird machines and linux servers, we got Force10 L3 switchs, also setup as route-reflector clients. I have no problem setting up the BGP sessions, bird receives both routes from the 2 servers. But I can't manage to have the L3 switchs getting both routes in return. birdc's "show route export bgp_sw3" only shows one of the 2 routes. I tried enabling add-path without success. Maybe I'm missing something ? Thanks for your help. -- Arnaud Houdelette-Langlois Administrateur des infrastructures systèmes et réseaux

3 5

Re: BIRD continues exporting routes but reports no exports
by Hugo Slabbert 03 Mar '23

03 Mar '23

(copying back to the list as this went direct inadvertently) Gotcha, thanks. Having export tables available is a great idea to help debug this, thanks. We'll enable that on some dev nodes to see if we can validate things going wonky and to give an additional view. The protocol reload is also a helpful idea to probably use in conjunction with that, to validate how things look before/after. On Thu, Mar 2, 2023, 16:26 Alexander Zubkov <green(a)qrator.net> wrote: > > Is `show route export` showing what BIRD thinks should be exported based > on current filters, or what it's actively sending to those peers? > > It should be the first variant. So the problem not that config is read > incorrectly, but that bird is not reloading protocols with changed filters. > As if the "soft" configure was called. You probably could also workaround > it by calling reload on your protocols. > > You can also enable export tables on your bgp session channels to examine > what was actually sent to the neighbor. > > On Thu, Mar 2, 2023, 23:13 Hugo Slabbert via Bird-users < > bird-users(a)network.cz> wrote: > >> Hi folks, >> >> We're seeing an issue where BIRD is reporting one thing for BGP route >> exports (via `show route export <protocol>`) but actually doing >> something different. >> >> We see this when we change some of the conditions around export. Our >> export filters include a function that evaluates as either true or false, >> for a global toggle of whether we should proceed on with any exports to >> relevant peers. Roughly it looks like this: >> >> ``` >> function do_export () >> bool DRAIN_NODE; >> bool HEALTHY; >> { >> DRAIN_NODE = false; >> HEALTHY = false; >> include "includes/birdwatch/*"; >> return HEALTHY && !DRAIN_NODE; >> } >> ``` >> >> That function is then included as the first term in relevant export >> filters, e.g.: >> >> ``` >> filter PUBLIC_EXPORT_v4 { >> if !do_export() then reject; >> # other export terms here >> } >> ``` >> >> We have external programs that monitor for whether the host is indicated >> as drained, or if the process that's handling traffic for the box is >> healthy. If those conditions change, they add or remove config snippets at >> the `includes/birdwatch/` directory to change the values of the >> DRAIN_NODE or HEALTHY bools, and we then call `birdc configure` to >> reload the config and pick up the change to either stop exports or proceed >> on with them. Doing the common trick of adding/removing /32s from loopbacks >> or such for DIRECT export don't fit our use case, so this method provides >> external programs control over global export state for those filters. >> >> This has worked cleanly for us so far. But, recently we've hit an issue. >> Assuming we start in a "non-drained" state where DRAIN_NODE is false and >> HEALTHY is true, so we're exporting routes as expected, we then: >> >> * toggle DRAIN_NODE to be true >> * execute `birdc configure` to reload the configuration >> >> When we look at exported routes, e.g. `show route export <bgp peer >> protocol>`, BIRD shows no routes exported, as expected. However, those >> BGP peers definitely do still see routes advertised from BIRD. We are also >> using https://github.com/czerwonk/bird_exporter, and the >> `bird_protocol_prefix_export_count` metrics for exported routes for the >> drained host remain at their previous levels. In other words: >> >> * birdc says nothing is being exported >> * but peers still are seeing prefixes from BIRD >> * and bird_exporter still shows prefixes being exported from BIRD >> >> Effectively, the `birdc show route export` output is lying. >> >> We've tried adding a sleep between when the include snippet that changes >> the DRAIN_NODE value is written and when we hit `birdc configure`, but >> that doesn't appear to make any difference. If we execute `birdc >> configure` *twice*, though, everything's fine: The actual exports are >> stopped. That's true without any sleep or break between running configure >> as well; literally just `birdc configure` back to back in the script >> that manages this. >> >> We do not see any indication of issues in the `birdc configure` runs or >> in BIRD's logs. >> >> The reverse also does occur, where if we start with the DRAIN_NODE set to >> true and are exporting nothing, then unset DRAIN_NODE and hit `birdc >> configure`: `show route export` shows things being exported, but >> neighbours actually don't hear any routes. >> >> We have not seen this occur in our smaller dev environment, but it has >> shown up in our more scaled environment. The relevant hosts have a couple >> of upstream v4 and v6 peers feeding them defaults, with: >> >> Import: >> * 1x IPv4 default route per BGP upstream peer, 2x total >> * 1x IPv6 default route per BGP upstream peer, 2x total >> Export: >> * 1-5 IPv4 /24s per BGP upstream peer >> * 0-1 IPv6 /48s per BGP upstream peer >> >> They have a larger number of downstream BGP peers, currently around 138 >> but that number can fluctuate. Each of those peers have an IPv4 and IPv6 >> channel, running over an IPv6 transport (`extended next hop on` for the >> ipv4 channel). >> >> At the moment those have: >> >> Import: >> * 2x IPv6 routes per peer (one /48, one /128) >> * 63x IPv4 routes per peer (all /24s) >> Export: >> * 21x IPv6 routes per peer (all /128s) >> * 1-5x IPv6 routes per peer (all /24s) >> >> So this does end up with the boxes have ~290 BGP "protocols", between v4 >> and v6 channels combined, ~9300 routes imported (between v4 and v6, >> multiplied by peers), and ~3,100 routes exported (between v4 and v6, >> multiplied by peers). >> >> Any thoughts on what could be causing BIRD to fail to apply the policy >> properly on the first `birdc configure` but succeeding on the second? Or >> why the route export output is incorrect after the first `birdc >> configure` but the metrics exporter being correct? Is `show route export` >> showing what BIRD *thinks* should be exported based on current filters, >> or what it's actively sending to those peers? Or any thoughts on how we can >> further debug or trace this to figure out what's confusing BIRD? >> >

1 0

[PATCH 0/3] babel: Add support for the RTT extension
by Toke Høiland-Jørgensen 03 Mar '23

03 Mar '23

This series adds support to the Babel protocol for the RTT extension, specified by this IETF draft: https://datatracker.ietf.org/doc/html/draft-ietf-babel-rtt-extension-00 The extension adds timestamps to Babel messages and uses them to compute the RTT between two Babel peers. A configurable additional cost is added to routes from based on these RTT vales. This is useful in particular for geographically distributed networks (such as overlay networks) where a route can be short in terms of hops, but each hop covers a long distance (and thus a long RTT). The extension is not currently on the IETF standards track because the document needs to be rewritten (see earlier message from Juliusz), but it's been in babeld for a while and considered quite useful there, so I think it would be nice to have it available in Bird as well. For details on the implementation, see the individual patches. Note that this series conflicts with Daniel's patches for moving the route selection into the Bird nest. Figured I'd send them now so this can be part of the discussion of that other patch (and also Daniel is one of the current users of this extension so I expect he'd be interested in having the two be compatible). Toke Høiland-Jørgensen (3): lib/timer: Add current_time_now() function for immediate timestamp babel: Add support for the RTT extension babel: Add route metric smoothing doc/bird.sgml | 63 +++++++++++-- lib/timer.c | 13 +++ lib/timer.h | 1 + proto/babel/babel.c | 205 +++++++++++++++++++++++++++++++++++++++--- proto/babel/babel.h | 40 +++++++++ proto/babel/config.Y | 30 ++++++- proto/babel/packets.c | 126 +++++++++++++++++++++++++- 7 files changed, 452 insertions(+), 26 deletions(-) -- 2.39.1

5 15

Invalid checksum in OSPF v2 LSA
by Prem Anand 02 Mar '23

02 Mar '23

Hi All, I have a working OSPFv2 session in Full state, between bird and flock <https://www.flocknetworks.com/non-wp-content/docs/flockrs/21.1/ospfv2/ospfv…>. On restarting the ospf session from bird, while it is already in full state, following log messages were seen, which claims that bird had received a LSA with invalid checksum from flock. After a brief troubleshooting session with the flock developers, it was found that bird complains about an LSA that it itself had originated and sent to flock earlier. Flock doesn't modify anything in the LSA and sends it back in the LSUpd when it receives a LSReq Here 1.1.1.1 is flock and 100.100.100.100 is bird 2023-03-02 10:07:30.421 <TRACE> ospf1: HELLO packet received from nbr 1.1.1.1 on bird-0-0-L 2023-03-02 10:07:35.318 <TRACE> ospf1: LSREQ packet sent to nbr 1.1.1.1 on bird-0-0-L 2023-03-02 10:07:35.318 <TRACE> ospf1: length 36 2023-03-02 10:07:35.318 <TRACE> ospf1: router 100.100.100.100 2023-03-02 10:07:35.318 <TRACE> ospf1: LSR Type: 0001, Id: 100.100.100.100, Rt: 100.100.100.100 2023-03-02 10:07:35.322 <TRACE> ospf1: LSUPD packet received from nbr 1.1.1.1 on bird-0-0-L 2023-03-02 10:07:35.322 <TRACE> ospf1: length 64 2023-03-02 10:07:35.322 <TRACE> ospf1: router 1.1.1.1 2023-03-02 10:07:35.322 <TRACE> ospf1: LSA Type: 0001, Id: 100.100.100.100, Rt: 100.100.100.100, Seq: 80000003, Age: 2101, Sum: 1984 2023-03-02 10:07:35.322 <RMT> ospf1: Bad LSA (Type: 2001, Id: 100.100.100.100, Rt: 100.100.100.100) in LSUPD 2023-03-02 10:07:35.322 <RMT> ospf1: received from nbr 1.1.1.1 on bird-0-0-L - support(a)flocknetworks.com I have attached the full ospf logs from bird and the ospf packet captures using tshark along with this. Can someone have a look and check if it is possible for bird to generate LSA with wrong checksum? Bird config: ============ log "/var/log/bird.log" all; router id 100.100.100.100; protocol device { scan time 10; } ipv4 table table1; protocol bfd bfd_bird { interface "*" { interval 0 us; multiplier 3; }; } protocol ospf v2 ospf1 { area 0.0.0.0 { networks { 10.100.1.0/24; }; interface "bird-0-0-L" { hello 10; dead 40; bfd on; }; }; ipv4 { table table1; export all; import all; }; } protocol static static1 { ipv4 { table table1; export all; import all; }; route 200.1.1.1/32 via 10.100.1.11; route 200.1.1.2/32 via 10.100.1.11; route 200.1.1.3/32 via 10.100.1.11; route 200.1.1.4/32 via 10.100.1.11; route 200.1.1.5/32 via 10.100.1.11; route 200.1.1.6/32 via 10.100.1.11; route 200.1.1.7/32 via 10.100.1.11; route 200.1.1.8/32 via 10.100.1.11; route 200.1.1.9/32 via 10.100.1.11; route 200.1.1.10/32 via 10.100.1.11; } Regards Prem

1 0

iBGP RR IPv6 link-local next-hop not kept
by Mirai Azayaka 01 Mar '23

01 Mar '23

Hello, I am trying to send routes from my DHCPv6 prefix delegation server to my router using iBGP. Those delegated prefix routes on the DHCPv6 server are installed in its kernel table, such as 2001:db8:db8::/56 via <client's link-local addr>. I want to pass this information to my router, but what the router receive is always 2001:db8:db8::/56 via <global unicast addr of the DHCPv6 server>. Why would next-hop change if it's iBGP? Here is my DHCPv6 server's BIRD configuration: ipv6 table pd; protocol kernel dhcpv6_pd { learn; kernel table 20; scan time 1; ipv6 { table pd; import all; export none; }; } protocol bgp prefix_delegation { local <some global unicast addr> as 65535; neighbor <some global unicast addr> as 65535; direct; ipv6 { table pd; next hop keep; import none; export filter { if ( proto = "dhcpv6_pd" ) then { accept; } else reject; }; }; graceful restart; } Here is my router's BIRD configuration: protocol bgp prefix_delegation { local <some global unicast addr> as 65535; neighbor <some global unicast addr> as 65535; direct; ipv6 { import filter { if net.len = 48 then { accept; } else reject; }; export none; }; graceful restart; } Thanks for any suggestions!

4 4