August 2023 - Bird-users

BGP: connect delay timer vs connect retry timer
by Bala Sajja 29 Aug '23

29 Aug '23

Hi, It seems where BGP connect retry timer to be kicked in use cases also, connect delay timer gets kicked in. In the below function, though bgp_setup_conn(p, conn) sets connect_timer to connect retry timer, later it's over written by bgp_start_timer(conn->connect_timer, delay) which sets connect_timer to connect delay timer. Is this right ? Could we make the connect retry timer work properly ? bgp_active(struct bgp_proto *p) { int delay = MAX(1, p->cf->connect_delay_time); struct bgp_conn *conn = &p->outgoing_conn; BGP_TRACE(D_EVENTS, "Connect delayed by %d seconds", delay); bgp_setup_conn(p, conn); bgp_conn_set_state(conn, BS_ACTIVE); bgp_start_timer(conn->connect_timer, delay); } Regards, Bala.

2 3

Bird is bringing down bgp connection upon receiving Admin Down
by Sunnat Samadov 29 Aug '23

29 Aug '23

Hi birds, This is the detailed explanation of the previously raised issue. We are using BIRD https://gitlab.nic.cz/labs/bird/-/tags/v2.0.11. And there is an issue with respect to BFD + BGP as described below. When Peer device ( Cisco ASR router) sends an BFD admin down, Bird is bringing down the BGP connection which is using BFD mode ON, which is not correct. The expected behavior is upon receiving BFD admin down from peer device, Bird should fall back to the Normal BGP mode of working. As per the comment mentioned on Bird forum, We could see the same (expected behavior) is to be claimed as ways of working for Bird: That is expected. Only a BFD transition from Up to Down is supposed to shutdown the BGP or OSPF session, while general unavailability of BFD (or permanent AdminDown state) on the neighbor is not an obstacle for BGP or OSPF. See RFC 5882 for details. BFD implementation in 1.4.0 (narkive.com)<https://bird-users.network.narkive.com/3REbA0Wz/bfd-implementation-in-1-4-0…> Steps: 1. Setup Bird config as (single hop / directly connected to router): [protocol device { } protocol bgp { local 10.0.10.22 as 64512; neighbor 10.0.10.6 as 65001; hold time 3; graceful restart off; setkey off; ipv4 { import all; export filter { if proto = "static1" then reject; accept; }; }; bfd on; } protocol bfd { interface "eth0" { min rx interval 100 ms; min tx interval 100 ms; idle tx interval 300 ms; multiplier 3; }; neighbor 10.0.10.6; neighbor 10.0.10.8; neighbor 10.0.10.10; }] 1. Make sure BGP and BFD session are up between bird and DCGW/router. 2. From router bring down the BFD session alone. 3. On Bird end we observe BGP session was brought down upon receiving BFD admin down. Which is not expected behaviour as per RFC. As per rfc5882#section-3.2<https://datatracker.ietf.org/doc/html/rfc5882#section-3.2> Therefore, a system SHOULD NOT indicate a connectivity failure to a client if either the local session state or the remote session state (if known) transitions to AdminDown, so long as that client has independent means of liveness detection (typically, control protocols). Attached PCAP : 128.0.0.3 is the router IP address and 128.0.0.53 is the Bird IP. Br, Sunnat Samadov

2 3

Pending bird patches and discussions for proto/babel
by Daniel Gröber 28 Aug '23

28 Aug '23

Hello birds, I just thought I'd put together an overview of as yet unresolved proto/babel patches and discussions to stimulate some activity :) Toke's RTT series: - lib/timer: Add current_time_now() function for immediate timestamp - babel: Add support for the RTT extension - babel: Add route metric smoothing My route selection revamp: - [v5] Babel: Replace internal route selection by bird's nest - [DRAFT] Babel: Implement route daming with fixed delay (s/daming/damping/) Toke's first two patches are ready for merging, but the third (metric smoothing) is contested since it conflicts with my route selection patch in its current form and if adapted it conflicts with my scalability goals for babel instead. Possibly premature optimization admittedly ;) Initially Toke was playing with the idea of exposing the smoothed metric to route filters in a followup patch. Me and Juliusz oppose this, for different reasons and the consensus is to not do that. My stance is that we could choose to merge smoothing as long as we don't expose it's implementation internals (the smoothed metric) to users. This way we can replace it with a more performant approach later. That being said since RTT metric is a new feature anyway I would prefer we just go with my route damping approach, mark RTT as experimental and get some more wider testing through a released version. Lastly my v5 route selection patch should also be ready, all threads of discussion should be resolved and there are no known bugs. However I've not received any testing reports, hint, hint peeps °>° --Daniel

4 8

hardware preference
by Ömür Yavuz 25 Aug '23

25 Aug '23

Hello community, I don't know if there is any obstacle for me to ask this kind of question. Everything is fine in terms of software, but can I get a hardware suggestion that millions of packages will pass through live with the servant? Do you have experience with an intel cpu and chelsio t4 nic or intel x5xx series? Which enterprise level devices can I use as hardware? ____________________________________________ Ömür Yavuz

4 3

[PATCH] adding custom options in radv protocol, strict ipv6 regex
by Alexander Zubkov 25 Aug '23

25 Aug '23

Hi, Currently one can use only a predefined set of advertised options in radv protocol, that are supported by bird's configuration. It would be convenient to be able to specify other possible options at least manually as a blob so one should not wait until it is supported in the code, released, etc. This idea is inspired by presentation by Ondřej Caletka at CSNOG, in which he noticed the lack of either PREF64 option or possibility to add custom options in various software. Attached patch [radv-custom.patch] makes it possible to define such options with the syntax: other type <num> <bytestring> I can also prepare a patch for documentation if it is to be merged. But it does solve the question with PREF64 completely. Because currently bytestring minimal length is 16 bytes, but for PREF64 we need to provide a 14-byte blob. And for minimal RA option, it have to be as short as 6 bytes. So another patch [bytestring-short.patch] allows bytestrings to be as short as 6 bytes, when colon-notation is used: "01:02:03:04:05:06". And I kept the minimum size of 16 bytes without colons, because it can conflict with some symbol names. The main concern is that a 6-byte bytestring conflicts with the MAC address representation. Bird does not have the type for it currently, but who knows, it might need it in the future. So we might need some new syntax for bytestring in that case. Or it can be postponed to later time. In this case introduction of MAC-address lexems would break configs that use 6-byte bytestrings (if we want to care much about those). It is also not possible to define a 8-byte bytestring, because it conflicts with IPv6 address, but we are introducing short bytestrings for RA here, and 8-byte bytestrings are not strictly required for that, because possible option sizes are 8, 16, ... with payloads 2 bytes less: 6, 14, ... So if one needs a 8-byte payload, he can easily pad it with extra zeroes ":00" with the same on-the-wire result. But still, this gives one more reason for an additional syntax for bytestrings. There also was possbility to explicitly allow only 6, 7, 9 and greater lengths of bytestrings. Or to move IPv6 regex definition before bytestring definition to make it more preferrable. I choose the second variant, but IPv6 regex is too loose now and match many things far from IPv6 notation. So I decided to provide a more strict regex definition for IPv6 addresses. Of course it is ugly, but I think it could be helpful anyway, because it does not conflict with other similar lexems, including MAC addresses. As a downside for this, in case of some typo in IPv6 address, there will not be a meaningful error about bad IPv6 address. So I added an additional regex there, to catch lexems with hex digits and at least 2 colons to show more meaningful error for that. But I'm not sure about it. If those changes for bytestrings are OK too, I also can prepare further patch for documentation. Have a nice day, Alexander Zubkov

4 44

Bird considers the VRF interface to be outside the VRF
by Erin Shepherd 24 Aug '23

24 Aug '23

Bird only treats the interfaces enslaved to the VRF as part of the VRF, but not the VRF virtual interface itself. This means that e.g. OSPF won't pick up loopback addresses defined on the VRF interface itself. You have to additionally add a dummy interfaces with the IPs attached, which seems to cause some confusion of its own on the kernel side. Ideally the VRF interfaces would be considered to be in the VRF. I've attached a patch which fixes this; I don't think the design is quite right, and its possible I introduced some bugs, but in testing it seems to work fine - Erin

2 1

ospf3 and bird interface in non-default FIB
by Eugene M. Zheganin 21 Aug '23

21 Aug '23

Hello, I'm running Bird 2.0.11 on FreeBSD 13.2, I also have a number of bird 2.0.x in local network. For a number of reasons I need the interface the OSPF is bound to to be in non-default FIB. As soon as I put it there, I'm starting to get the periodic errors like ===Cut=== ospfv4: Socket error on igb0: Network is unreachable ===Cut=== (v4 here stands for IPv4) and the bird is also unable to establish the neighborship with 2 of 7 it's neighbors: ===Cut=== # birdc BIRD 2.0.11 ready. bird> show ospf neighbors ospfv4: Router ID Pri State DTime Interface Router IP 192.168.57.35 1 Full/BDR 36.075 igb0 192.168.57.35 192.168.57.37 1 Full/DR 31.771 igb0 192.168.57.147 192.168.57.23 1 2-Way/Other 31.771 igb0 192.168.57.23 192.168.57.13 1 2-Way/Other 31.894 igb0 192.168.57.13 192.168.100.254 1 Full/PtP 37.138 gre1 172.16.0.7 178.161.174.72 128 Full/PtP 39.563 gre4 172.16.0.24 192.9.200.5 1 Full/PtP 33.227 ipsec0 172.16.0.13 192.168.55.254 1 Full/PtP 36.256 ipsec1 172.16.0.80 178.161.174.72 128 Full/PtP 34.665 ipsec2 172.16.0.22 89.108.123.58 1 Full/PtP 33.138 ipsec3 172.16.0.28 192.168.52.1 1 Full/PtP 32.505 ipsec4 172.16.0.30 ===Cut=== For instance, 192.168.57.35 and 192.168.57.37 are stuck in ExtStart. Why ? My config looks like this: ===Cut=== protocol ospf ospfv4 { ipv4 { table master4; export filter exportospfv4; import filter importospfv4; }; #debug all; area 0.0.0.0 { interface "igb0" { cost 111; }; interface "tun0" { cost 111; }; }; area 0.0.0.1 { interface "gif1" { cost 4111; }; interface "ipsec0" { cost 7111; }; }; area 0.0.0.2 { interface "gre1" { cost 1211; }; interface "gre2" { cost 1111; }; interface "gre6"; }; area 0.0.0.3 { interface "gif5"; interface "ipsec1"; }; area 0.0.0.4 { interface "ipsec2"; interface "gre4"; interface "gre5"; }; area 0.0.0.5 { interface "ipsec3"; }; area 0.0.0.6 { interface "ipsec4"; }; } ===Cut=== I've also tried to put ospfv4 protocol in the same FIB the interface is in (adding the "table fib1" statement), but got the same error about network unreachability. Restarting bird does not clear this state also. Running ospf with full debug gives this: ===Cut=== Aug 21 11:23:12 ronin bird[59670]: ospfv4: DBDES packet received from nbr 192.168.57.35 on igb0 Aug 21 11:23:12 ronin bird[59670]: ospfv4: length 32 Aug 21 11:23:12 ronin bird[59670]: ospfv4: router 192.168.57.35 Aug 21 11:23:12 ronin bird[59670]: ospfv4: mtu 1500 Aug 21 11:23:12 ronin bird[59670]: ospfv4: imms I M MS Aug 21 11:23:12 ronin bird[59670]: ospfv4: ddseq 1977563332 Aug 21 11:23:12 ronin bird[59670]: ospfv4: HELLO packet received from nbr 192.168.100.254 on gre1 Aug 21 11:23:15 ronin bird[59670]: ospfv4: HELLO packet received from nbr 178.161.174.72 on gre4 Aug 21 11:23:16 ronin bird[59670]: ospfv4: DBDES packet sent to nbr 192.168.57.35 on igb0 Aug 21 11:23:16 ronin bird[59670]: ospfv4: length 32 Aug 21 11:23:16 ronin bird[59670]: ospfv4: router 192.168.57.254 Aug 21 11:23:16 ronin bird[59670]: ospfv4: mtu 1500 Aug 21 11:23:16 ronin bird[59670]: ospfv4: imms I M MS Aug 21 11:23:16 ronin bird[59670]: ospfv4: ddseq 3625460956 Aug 21 11:23:16 ronin bird[59670]: ospfv4: Socket error on igb0: Network is unreachable ===Cut=== Right now I have no idea how to fix this. Thanks. Eugene.

1 0

Re: [Babel-users] [RFC] Replace WireGuard AllowedIPs with IP route attribute
by Daniel Gröber 19 Aug '23

19 Aug '23

Hi Steffen, from the questions you ask I fear you've misunderstood my intention to "replace" AllowedIPs. I'm strictly talking of the _implementation_ (allowedips.c) in Linux particular. The netlink interface would naturally stay unchanged. On Sat, Aug 19, 2023 at 10:00:17PM +0200, Steffen Vogel wrote: > Interesting ideas! I am wondering if this complexity is really necessary? I think so, right now wg's behaviour just prevents a number of advanced use-cases which is a pitty. > My biggest concern about the introduction of a route attribute is that > this adds complexity for users. WireGuard's simplicity (and portability) > have been important factors for its success. Nothing would change for users that don't use this feature. > A route attribute would introduce another source for the crypto-routing > peer selection process. What happens if the two mechanisms select > different peers? Which one would have precedence? If you read my previous mail carefully you'll find I specified how this would shake out. The rt approach will necessarily have to override AllowedIPs to be useful. > Similarly also for incoming packets. WireGuard's current principle is > really easy to understand. If the source address in in the peers > AllowedIP list, we will accept the packet. If not its discarded. This is > a central part of WireGuard's crypto-key routing feature which would > become more complex. Having read Kyle's use-case I'm thinking my original plan to extend the wg internal source-address filtering to use a rt lookup with our new attribute would not be maximally useful so now my thinking is we should just have a boolean toggle to disable it explicitly per device. Then users can do whatever fancy rt (reverse-path) lookups they want with nft. I'm particularly happy that nft rt lookups will actually do the right thing with multipath/ECMP routes (any of the involved devices satisfies the lookup) so this should actually work out fine in my case at least. Mmore prototyping is required here though. > A second concern I have with the use of route attributes is limited > portability. Not all platforms support them. How do we handle WireGuard > userspace implementations? No need. The Linux's rt table is Linux specific I have no plans to introduce this on other platforms, that's for other intersted souls to tackle. Again "replace" was referring to implementation concerns. > - Networks which are found in a Peers AllowedIP list will be installed as a kernel route That's configurable. I always turn this off when dealing with rt daemons. > - Kernel routes with the peers unique IP address as next-hop will be added to the Peers AllowedIPs list. > > This rather simple feature allows user to pair cunicu with a software > routing daemon like Bird2 while using a single WireGuard interface with > multiple peer-to-peer links. Sounds like you do what I want to do at kernel level in userspace, then at least we can agree this is a useful thing :) > In my setup a periodic synchronization worked fine. But I agree that it > would be nice if we could have a Netlink multicast group for subscribing > to changes like we also have for other parts of the Linux network stack > like routing tables, or link states. This feature was already discussed > on the WireGuard mailing list [7]. But unfortunately the patch was never > accepted. Maybe we can revisit this patch? Sounds like a plan, I'll have a look at it. > [1] Others planned features are: > - IP-autoconfiguration by deriving link-local addresses from peers public keys That's been discussed so many times before on the ML and someone always realises Jason is right and there's no point to this in the end. Key distribution is the crux of the problem. --Daniel

1 0

[RFC] Replace WireGuard AllowedIPs with IP route attribute
by Daniel Gröber 19 Aug '23

19 Aug '23

Hi wireguard, birds, and babelers, tl;dr I want to add a new Linux route attribute (think "via $wgpeer") to supplement wireguard's internal AllowedIPs logic for both routing and source address filtering. I've been pondering how to better integrate wireguard into dynamic routing daemons, particularly BIRD and babeld. Essentially we want to be able to dynamically add/remove AllowedIPs depending on current reachability and/or link quality stats. Looking at the wg netlink API I see two major efficiency/scalability problems: 1) there is no way to be notified of changes in AllowedIPs made by other processes meaning we have to do periodic scans and 2) a peer's AllowedIPs set can only be replaced wholesale, not modified incrementally. This is problematic as "someone" might, in the worst case, want to install an entire internet routing table's worth of AllowedIPs and the set will likely change frequently. FYI: The IPv4 table has ~1M entries at present, yikes. Assuming external AllowedIPs changes are infrequent occationally dumping them all to keep a consistent view of the state shouldn't be too much of an issue as long as the netlink interface is performant enoug, so I'm going to concentrate on the add/remove API for now. Instead of doing the obvious thing and adding a more efficient incremental AllowedIPs netlink interface I figure why not just add a route attribute to select a target wg peer on a device. That way we could not only save memory (no separate AllowedIPs trie) but also simplify routing daemon implementation considerably. This would mirror how on ethernet you can have `dev eth0 via $router_ip`. I'm still reviewing the net/ code to find the best way to do this, but I'm thinking either a new RTA_WGPEER, like: `default dev wg0 via-wgpeer $peer_pubkey` or perhaps re-using RTA_VIA and keying off a statically configured AllowedIP addresses. To start I'd make this an opt-in replacement for our usual AllowedIPs logic, making sure to only activate it if any via* RTAs are active on a particular device, but if it proves to work well I don't see why we couldn't adapt the netlink code to maintain AllowedIPs using this RTA (but invisible to userspace) to re-use the same code and get rid of allowedips.c altogether. That's assuming this ends up being less code overall or perhaps more performant. Happy to hear your thoughts, --Daniel

2 2

Recursive nexthop via kernel route in proto static not working
by Daniel Gröber 15 Aug '23

15 Aug '23

Hi, I'm trying to configure a static route that uses the system's default router. The default router is out of my control and is announced via IPv6 RA. Since the MAC might not be stable I'd prefer not to hardcode the router's link-local address. So I tried: protocol static static_export_kernel2 { ipv6; igp table master6; route 2001:db8::/48 recursive ::; } The thinking being that :: ought to be resolvable through the default route imported from proto kernel: birdc show route for :: all Table master6: ::/0 unicast [kernel1 2023-03-22] * (10) via fe80::fc00:3ff:fec7:cd05 on enp1s0 Type: inherit univ Kernel.source: 9 Kernel.metric: 1024 Kernel.hoplimit: 64 However the static route ends up being "unreachable": 2a0d:f302:114::/48 unreachable [static_export_kernel2 13:59:32.819] * (200) Type: static univ Any ideas why this isn't working? Thanks, --Daniel PS: The reason I have to create this static route when it's already covered by the default route has to do with an esoteric policy routing setup and multiple routing daemons ask for details at your own peril :)

3 6