- Bird-users - Mailing Lists

bird bug: can not parse the full-length IPv6 address
by Alexander Zubkov 01 Jan '22

01 Jan '22

Hi, I found a funny bug, when made some tests. I found out that if you try to give bird a full-length IPv6-address, like: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 1111:2222:3333:4444:5555:6666:7777:8888 You will get an error: "syntax error, unexpected BYTESTRING". I find it happens in conf/cf-lex.l because of how BYTESTRING is defined before IP6, it is too liberal to the forms of bytestrings, allowing almost arbitrary mix of ':' and digits. I suspect the idea was it allow 32-digit strings without delimters or with groups of 2 digits delimited by ':'. See proposed changes in the patch. By the way, that possibility for string literals is not documented. :) IP6 definition is also too permissive and allows some really weird things. It might have been done so intentionally to catch IPv6 typos. But in that case, it probably could be silmlified.

2 2

Re: BIRD 2.0 on FreeBSD, multihop with multiple fibs
by Dominic Blais 01 Jan '22

01 Jan '22

Hi, I've had my load of issues with bird 2 on FreeBSD. I used BSDRP like 3 years ago and after an update I started having big issues related to bird. I think BSDRP released version 1.98 with a fix for that.. don't know if it's ok in 1.99. https://sourceforge.net/projects/bsdrp/files/BSD_Router_Project/1.98/ "bird2: Fix multi-FIB usage by reverting bird commit 318acb0f6cb77a32aad5d7f79e06f3c5065ac702" Maybe it's not related but just in case... please tell me if it worked! In reponse to: Hi everyone, I hope this is not too specific... I'm running into a bit of a pickle here. This is FreeBSD 12.2 with multi-fib enabled; BIRD exporting all its received routes to fib 1, basic kernel routing in fib 0. (The service on the box is in fib 1, of course). I need to configure a multihop session where the BGP partner is not on the same interface as the box's default, but on a pni, which is behind a VLAN-tagged subinterface (i.e., bge0.300) down on a switch somewhere. Also, I can only BGP connect to the partner via the PNI. The interface has no fib tags, so it "exists" in both fibs. Let's say we are bge0.300 5.6.7.7. The other side of the PNI is at 5.6.7.8. Our BGP partner is at 1.2.3.4, reachable through 5.6.7.8. protocol static { ipv4; route 1.2.3.4/32 via 5.6.7.8; } Now, netstat tells me that 1.2.3.4/32 shows up in fib 1, but not in fib 0. BIRD only puts it in fib 1. In this setup, BIRD does not connect to 1.2.3.4 unless I manually add that host route to fib 0. Adding a % 'bge0.300' to the static route line doesn't change a thing, route still only appears in fib 1. Two questions: - why does BIRD put the route in fib 1 when no fib is specified, and the interface is not bound to a fib? - Is there a canonical way of solving this? I have the fib 0 static route configured in the system setup now, which makes it work. It would be nicer to have it thrown in there by BIRD, so the config is self-contained. Any guidance would be highly appreciated. Elmar.

2 1

[PATCH] Filter: picking community elements and finding min/max element
by Alexander Zubkov 28 Dec '21

28 Dec '21

Hi everyone! I made a couple of patches to do some interesting stuff with communities. The first patch allows to pick a component from a standard or a large community: (10, 20, 30) @ 2 --> 20 And the second patch allows to search for minimum or maximum element in a community list. This combined allows to do some cool stuff with communities like this: bgp_local_pref = filter(bgp_large_community, [(<as>, <localpref_val>, *)]).min @ 3 This will find us the minimum from our "localpref" communities and get that number as integer, ready to assign it where we need. Now we use a series of if's to check all the possible variants and that is not very convenient. I think this features will greatly boost the possibilities of working with communities in bird.

2 9

Possibility to treat /32 and /128 non-gateway routes as onlink on BSD?
by Stefan Haller 27 Dec '21

27 Dec '21

Hi everyone, In a recent change in the FreeBSD Wireguard kernel module the POINTTOPOINT interface flag is dropped for wg interfaces[1]. This behaviour will probably not change, because Wireguard is not peer-to-peer or a broadcast domain, but peer-to-multipoint. Hence my previous configuration of setting peer addresses on the interface is not working anymore: ifconfig wg0 inet 192.168.0.10/32 192.168.0.4 The above syntax is for POINTTOPOINT interfaces. In this case 192.168.0.10 is the local address of the interface and 192.168.0.4 is the address of the remote peer. So if one does not want to add a dedicated subnet to every tunnel device, one has to add static host routes similar to these ones: ifconfig wg0 192.168.0.10/32 route add 192.168.0.4 -iface wg0 Note that this actually models the real world better, because Wireguard is not point-to-point but point-to-multipoint. So multiple peers can be done in the following way: ifconfig wg0 192.168.0.10/32 route add 192.168.0.4 -iface wg0 route add 192.168.0.8 -iface wg0 However, this does not work with bird 2.0.8: bird will not recognize the p2p peer addresses as gateways and it will log on kernel table rescan: KRT: Received route 192.168.42.0/24 with strange next-hop 192.168.0.4 KRT: Error sending route 192.168.42.0/24 to kernel: File exists I did have a look why this is happening: bird discards the route, because the gateway does not belong to any of its interface's addresses (the peer address is configured as a static host route and not on the interface). At the same time it forgets that it was bird itself who added the route (because the route is discarded on kernel table rescan, it thinks it is absent in the kernel table but present in bird's internal routing table -> "add" logic triggers) and tries to add the route again (instead of replacing/keeping the route). This explains the cascade of error messages above. While the Linux netlink code allows to handle onlink routes, this functionality is absent in the BSD code path. Unfortunately, on BSD there is no dedicated flag to mark routes as being directly connected onlink routes. On Linux one could add an onlink route like so: ip route add 192.168.0.4 via 192.168.0.4 dev wg0 onlink The command looks quite odd, but it is working. The via clause is necessary in conjunction with onlink. Afterwards a `birdc dump neighbors` verifies that the peer is recognized: 000055db793035c0 192.168.0.4 wg0 wg0 kernel1 000000000000000000000000 scope univ ONLINK (Also the "strange next-hop" message will go away.) I created a patch that emulates the behaviour on FreeBSD. In this patch the onlink setting is heuristically determined by inspecting the RTF_GATEWAY flag (which must be absent) and checking for a /32 or /128 prefix length. I do not see how to handle cases where the destination is a subnet. The patch was tested on FreeBSD 13.0-RELEASE and 14.0-CURRENT. During rescan of the kernel table the above route is now not dropped because the gateway is recognized to be onlink. While in the Linux route the gateway is still set, on FreeBSD it is unset (~RTF_GATEWAY). So I actually use the destination address of the route, because that's the address of the peer. While I tested the functionality on my machines and also checked the output of `birdc dump neighbors`, the patch might be faulty. Please be kind with me and treat it more as a proof of concept. As I am not experienced with bird's code base I do not fully understand how the neighbor cache is working in detail, so the suggested patch might have unexpected side effects. I would appreciate feedback. In case you think the whole idea is not sensible, I would also love to hear suggestions how to get the above setup working. Kind regards, Stefan [1]: https://git.zx2c4.com/wireguard-freebsd/commit/?id=8801509656e955c27ebf4b9b… sysdep/bsd/krt-sock.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sysdep/bsd/krt-sock.c b/sysdep/bsd/krt-sock.c index ea0cc4d9..4a0f3a7a 100644 --- a/sysdep/bsd/krt-sock.c +++ b/sysdep/bsd/krt-sock.c @@ -547,6 +547,12 @@ krt_read_route(struct ks_msg *msg, struct krt_proto *p, int scan) net->n.addr, a.nh.gw); return; } + } else if ((!ipv6 && pxlen == 32) || (ipv6 && pxlen == 128)) { + /* Treat non gateway /32 and /128 routes as onlink routes and inject this + information into neighbor cache. */ + if (!neigh_find(&p->p, idst, a.nh.iface, NEF_ONLINK)) + log(L_ERR, "KRT: Failed to inject onlink neighbor %I for interface %s", + idst, a.nh.iface->name); } done: -- 2.31.1

2 5

[patch] Add contextual out-of-bound checks in RTR Prefix PDU handler
by Job Snijders 18 Dec '21

18 Dec '21

Hi, A broken RPKI Cache could contextually underflow or overflow the Max Length value in RTR IPv4 / IPv6 Prefix PDUs. Below is a changeset proposal which adds specific out-of-bounds checks and schedules a reconnect for a later moment. This aligns BIRD's behavior with other COTS BGP implementations. RFC 6810 and RFC 8210 specify that the "Max Length" value MUST NOT be less than the Prefix Length element (underflow). On the other side overflow of the Max Length element also is possible, it being an 8-bit unsigned integer allows for values larger than 32 or 128. When a PDU is received where the Max Length field is corrputed, the RTR client (BIRD) should immediately terminate the session, flush all data learned from that cache, and log an error for the operator. If this condition is hit, it seems better to follow the same approach as for RPKI_CS_ERROR_TRANSPORT, because rpki_force_restart_proto() causes an "as fast as possible" reconnect loop between BIRD and the RPKI Cache server, which increases resource consumption on both sides. Kind regards, Job diff --git proto/rpki/packets.c proto/rpki/packets.c index dd11f997..09e20f38 100644 --- proto/rpki/packets.c +++ proto/rpki/packets.c @@ -737,6 +737,22 @@ rpki_handle_prefix_pdu(struct rpki_cache *cache, const struct pdu_header *pdu) net_addr_union addr = {}; rpki_prefix_pdu_2_net_addr(pdu, &addr); + if (type == IPV4_PREFIX) { + if (addr.roa4.max_pxlen > IP4_MAX_PREFIX_LENGTH || addr.roa4.max_pxlen < addr.roa4.pxlen) { + RPKI_WARN(cache->p, "Received a corrupted packet from cache server"); + rpki_send_error_pdu(cache, CORRUPT_DATA, pdu->len, pdu, "Corrupted PDU"); + rpki_cache_change_state(cache, RPKI_CS_ERROR_FATAL); + return RPKI_ERROR; + } + } else { + if (addr.roa6.max_pxlen > IP6_MAX_PREFIX_LENGTH || addr.roa6.max_pxlen < addr.roa6.pxlen) { + RPKI_WARN(cache->p, "Received a corrupted packet from cache server"); + rpki_send_error_pdu(cache, CORRUPT_DATA, pdu->len, pdu, "Corrupted PDU"); + rpki_cache_change_state(cache, RPKI_CS_ERROR_FATAL); + return RPKI_ERROR; + } + } + if (cf->ignore_max_length) { if (type == IPV4_PREFIX) diff --git proto/rpki/rpki.c proto/rpki/rpki.c index ab0837f3..91b69da0 100644 --- proto/rpki/rpki.c +++ proto/rpki/rpki.c @@ -288,9 +288,6 @@ rpki_cache_change_state(struct rpki_cache *cache, const enum rpki_cache_state ne case RPKI_CS_ERROR_FATAL: /* Fatal protocol error occurred. */ - rpki_force_restart_proto(cache->p); - break; - case RPKI_CS_ERROR_TRANSPORT: /* Error on the transport socket occurred. */ rpki_close_connection(cache);

2 5

Incorrect handling of primary/secondary IP address status.
by Alexander 18 Dec '21

18 Dec '21

Hi, Looks like bird (2.0.8 on Linux) incorrectly handles primary/secondary IP address status. For example, this is initial state (output from "show interfaces"): enp6s20 up (index=2 master=switch) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 192.168.111.1/24 (Preferred, scope site) 192.168.111.2/24 (Secondary, scope site) Then I remove 192.168.1.2/24, 192.168.111.2/24 promoted to primary (promote_secondaries is enabled on interface), but bird does not get it: enp6s20 up (index=2 master=switch) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 192.168.111.2/24 (Secondary, scope site) ... while it is actually primary now: 2: enp6s20: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master switch state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:68 brd ff:ff:ff:ff:ff:ff permaddr xx:xx:xx:xx:xx:30 inet 192.168.111.2/24 scope global enp6s20 valid_lft forever preferred_lft forever From now on, no address within same network will ever get "primary" status until and unless all addresses within this network will be deleted. Looks like it remembers "secondary" status once seen and never updates it. "reload", "configure" and "enable"/"disable" on do not help either. I hit this issue after noticing that OSPF couldn't see neighbors after few changes in IP configuration (as it ignores all secondaries). Best regards, Alexander.

2 3

Invalid NEXT_HOP attribute for OSPF known route
by Nico Schottelius 16 Dec '21

16 Dec '21

Hello, every year or then bird is putting me into the Invalid NEXT_HOP message. TL;DR: Why does bird on router1+router2 refuse the route 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122 via 2a0a:e5c0::225:90ff:fe1e:3e62 even though router1+router2 know how to reach 2a0a:e5c0::/64 via fe80::20d:b9ff:fe57:2f91 by means of ospf? In detail: router1, router2 are peered to apu-router1,apu-router2 via OSPF + BGP. apu-router1,apu-router2 are peered to a set of kubernetes hosts. The goal is to have router1 + router2 import the routes sent by the kubernetes hosts: router1 router2---------| | \ | | | \ | | | \ | | apu-router1 apu-router2 | . | . | |-------------------------- . . [ kubernetes cluster via apu-routers ] The problem: router1+router reject the routes with: Dec 14 20:33:51 router1 daemon.err bird: apu_router1_place5_ungleich_ch_v6: Invalid NEXT_HOP attribute The setup: router1, router2, apu-router1, apu-router2 = ASN209898 kubernetes hosts = ASN65533 kubernetes peers with apu-routers only. The routes: Kubernetes announces parts of 2a0a:e5c0:0:12::/64 and 2a0a:e5c0:0:13::/64, for instance the route 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122. Kubernetes nodes live in 2a0a:e5c0::/64. apu-routers have a leg in 2a0a:e5c0::/64, via eth1.2. They reach the cluster directly. They have the routes. routers1+2 receive the route for 2a0a:e5c0::/64 via ospf: bird> show route 2a0a:e5c0::/64 Table master6: 2a0a:e5c0::/64 unicast [ospf6 17:08:18.515] * I (150/20) [0.0.0.47] via fe80::20d:b9ff:fe57:2f91 on bond0.8 Thus routers *can* reach the kubernetes cluster. The apu-routers: - They import the route [0] - They export the route to the routers [1] The routers: - print 4x the Invalid NEXT_HOP attribute, once per exported kubernetes network - They ignore the 4 routes [2] Question: why does bird on the routers not accept the routes? Or is there a different problem I am not seeing? Aside from that, shouldn't bird on the apu-routers set itself as nexthop for the kubernetes routes? Any help appreciated. Best regards, Nico [0] [20:29] apu-router2.place5:~# birdc show route 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122 BIRD 2.0.8 ready. Table master6: 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122 unicast [k8s_p5_1_4 19:16:10.910 from 2a0a:e5c0::225:90ff:fe1e:3e74] * (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 unicast [k8s_p5_1_3 19:16:10.910 from 2a0a:e5c0::225:90ff:fe1a:d680] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 unicast [k8s_p5_1_5 19:16:10.909] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 unicast [k8s_p5_1_1 19:16:10.910 from 2a0a:e5c0::225:90ff:fe1a:d682] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 unicast [k8s_p5_1_2 19:16:10.910 from 2a0a:e5c0::225:90ff:fe1e:3e64] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 unicast [k8s_p5_1_6 19:16:10.910 from 2a0a:e5c0::225:90ff:fe1e:62d6] (100) [AS65533i] via 2a0a:e5c0::225:90ff:fe1e:3e62 on eth1.2 [20:42] apu-router2.place5:~# [1] [20:43] apu-router2.place5:~# birdc show protocol all router1_place5_ungleich_ch_v6 BIRD 2.0.8 ready. Name Proto Table State Since Info router1_place5_ungleich_ch_v6 BGP --- up 20:29:06.203 Established BGP state: Established Neighbor address: 2a0a:e5c0:1:8::3 Neighbor AS: 209898 Local AS: 209898 Neighbor ID: 147.78.195.249 Local capabilities Multiprotocol AF announced: ipv6 Route refresh Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Neighbor capabilities Multiprotocol AF announced: ipv6 Route refresh Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Session: internal AS4 Source address: 2a0a:e5c0:1:8::47 Hold timer: 175.206/240 Keepalive timer: 53.629/80 Channel ipv6 State: UP Table: master6 Preference: 100 Input filter: REJECT Output filter: ungleich_networks_no_igp Routes: 0 imported, 6 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 98 0 98 0 0 Import withdraws: 3 0 --- 3 0 Export updates: 35 0 29 --- 6 Export withdraws: 0 --- --- --- 0 BGP Next hop: 2a0a:e5c0:1:8::47 fe80::20d:b9ff:fe49:a705 [2] bird> show protocol all apu_router2_place5_ungleich_ch_v6 Name Proto Table State Since Info apu_router2_place5_ungleich_ch_v6 BGP --- up 20:29:06.189 Established BGP state: Established Neighbor address: 2a0a:e5c0:1:8::47 Neighbor AS: 209898 Local AS: 209898 Neighbor ID: 0.0.0.47 Local capabilities Multiprotocol AF announced: ipv6 Route refresh Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Neighbor capabilities Multiprotocol AF announced: ipv6 Route refresh Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Session: internal AS4 Source address: 2a0a:e5c0:1:8::1 Hold timer: 157.409/240 Keepalive timer: 45.770/80 Channel ipv6 State: UP Table: master6 Preference: 100 Input filter: ungleich_networks Output filter: ungleich_networks_no_igp Routes: 2 imported, 101 exported, 1 preferred Route change stats: received rejected filtered ignored accepted Import updates: 2 0 0 0 2 Import withdraws: 4 0 --- 4 0 Export updates: 140674 8 140565 --- 101 Export withdraws: 334 --- --- --- 0 BGP Next hop: 2a0a:e5c0:1:8::1 fe80::a236:9fff:fe08:a780 -- Sustainable and modern Infrastructures by ungleich.ch

2 5

using BIRD as route reflector - add paths option not working?
by mike＠routerpro.ca 15 Dec '21

15 Dec '21

Hello, I am using bird as a RR and have set the add paths tx; option, however I am still only seeing best path being advertised. ==== protocol bgp RR_Client_IPv4 { local my_ip as my_as; neighbor range rr_ipv4_range internal; rr client; rr cluster id cluster_id; capabilities on; dynamic name "RR_Client_IPv4_"; dynamic name digits 2; ipv4 { add paths tx; import filter Internal_In_Route_Reflector; export filter Internal_Out_Route_Reflector_default; }; } ==== show protocols all shows that ADD-PATH is enabled. I also have it enabled RX on the RR clients ADD-PATH RX: TX: ipv4 === 3 routes present , with one marked as BEST: bird> show route x.x.x.x/32 Table master4: x.x.x.x/32 unreachable [RR_Client_IPv4_03 2021-12-15 21:05:36 from y.y.y.y] * (100) [AS4200001111?] unreachable [RR_Client_IPv4_05 2021-12-15 21:05:35 from y.y.y.x] (100) [AS4200001111?] unreachable [RR_Client_IPv4_01 2021-12-15 21:05:16 from y.y.y.z] (100) [AS4200000110?] === 1 BEST route advertised to RR client: bird> show route export RR_Client_IPv4_01 x.x.x.x/32 Table master4: x.x.x.x/32 unreachable [RR_Client_IPv4_03 2021-12-15 21:05:36 from y.y.y.y] (100) [AS4200001111?] Is this expected behavior even with add paths enabled? I was expecting all 3 routes to be advertised to RR client.

2 1

[PATCH] BGP: Log value of invalid NEXT_HOP in bgp_apply_next_hop()
by Simon Ruderich 15 Dec '21

15 Dec '21

--- Hello, while debugging "Invalid NEXT_HOP attribute" messages in my setup I had to recompile bird2 with additional debug output to determine which BAD_NEXT_HOP line was triggered and with which NEXT_HOP value. After adding this patch determining the problem was very easy. I also looked at the other BAD_NEXT_HOP in the file but I'm not sure how to properly print their values. Regards Simon proto/bgp/packets.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proto/bgp/packets.c b/proto/bgp/packets.c index 99b5d5b4..830a2060 100644 --- a/proto/bgp/packets.c +++ b/proto/bgp/packets.c @@ -955,7 +955,7 @@ bgp_apply_next_hop(struct bgp_parse_state *s, rta *a, ip_addr gw, ip_addr ll) nbr = neigh_find(&p->p, ll, p->neigh->iface, 0); if (!nbr || (nbr->scope == SCOPE_HOST)) - WITHDRAW(BAD_NEXT_HOP); + WITHDRAW(BAD_NEXT_HOP " %I (direct)", gw); a->dest = RTD_UNICAST; a->nh.gw = nbr->addr; @@ -965,7 +965,7 @@ bgp_apply_next_hop(struct bgp_parse_state *s, rta *a, ip_addr gw, ip_addr ll) else /* GW_RECURSIVE */ { if (ipa_zero(gw)) - WITHDRAW(BAD_NEXT_HOP); + WITHDRAW(BAD_NEXT_HOP " %I (recursive)", gw); rtable *tab = ipa_is_ip4(gw) ? c->igp_table_ip4 : c->igp_table_ip6; s->hostentry = rt_get_hostentry(tab, gw, ll, c->c.table); -- 2.34.1 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9

2 1

OSPF/general question: Using v6 next-hop for v4 routes
by Sebastian Hahn 10 Dec '21

10 Dec '21

Hi there, I've been trying to remove v4 transit nets from my setup. This seems to work well for BGP (both eBGP and iBGP) - I have routes for all external v4 addresses with the appropriate next hop set. For my internal routing, I'm using OSPF, but it seems OSPF does not allow v6 next hops for v4 routes. Checking RFC 5838 seems to imply that this is a general design choice for OSPF, but I am not sure if my reading is correct. Also, are there any practical drawbacks for this kind of setup that I may have missed when choosing it for BGP? Thanks, also for any pointers how to achieve the intended setup! Sebastian

2 2