August 2021 - Bird-users

[BIRD 2.0.x] Netlink: ignore dead routes
by Vincent Bernat 09 Jan '22

09 Jan '22

With net.ipv4.conf.XXX.ignore_routes_with_linkdown sysctl, a user can ensure the kernel does not use a route whose target interface is down. The route is marked with a "dead"/RTNH_F_DEAD flag. Currently, BIRD still uses and distributes this route. This patch just ignores such a route. This patch could be backported to 1.6.x. Signed-off-by: Vincent Bernat <vincent(a)bernat.ch> --- sysdep/linux/netlink.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index f85bcf35685b..c28126510e6e 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -1690,6 +1690,9 @@ nl_parse_route(struct nl_parse_state *s, struct nlmsghdr *h) if (i->rtm_flags & RTNH_F_ONLINK) ra->nh.flags |= RNF_ONLINK; + if (i->rtm_flags & RTNH_F_DEAD) + return; + neighbor *nbr; nbr = neigh_find(&p->p, ra->nh.gw, ra->nh.iface, (ra->nh.flags & RNF_ONLINK) ? NEF_ONLINK : 0); -- 2.28.0

5 15

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

bgp_large_community wildcard in conditional
by Brooks Swinnerton 18 Oct '21

18 Oct '21

Hello, I was wondering if it's possible to create a conditional that matches on a wildcard for a part of a BGP large community. For example: if ([*, 600, 6939]) ~ bgp_large_community then reject; This currently results in a syntax error at the position of the comma after the *.

5 7

Compilation directive LOCAL_DEBUG and DBG()
by Senthil Kumar Nagappan 17 Sep '21

17 Sep '21

Hi, To enable debug outputs using DBG macro, it requires LOCAL_DEBUG or GLOBAL_DEBUG to be defined during compilation. 1. Defined it in the Makefile as below. Is there an option without changing the auto generated Makefile? CFLAGS=$(CPPFLAGS) -g -O2 -pthread -fno-strict-aliasing -fno-strict-overflow -flto -Wall -Wextra -Wstrict-prototypes -Wno-parentheses -Wno-pointer-sign -Wno-missing-field-initializers -DLOCAL_DEBUG 2. If we try to define LOCAL_DEBUG in the code, there are undef directive in the different places of the code, so may not work consistently. 3. If we define this LOCAL_DEBUG or GLOBAL_DEBUG, there are compilation errors that needs to be addressed. Thanks and Regards,Senthil

2 4

default protocol preference values
by Kseniya Blashchuk 07 Sep '21

07 Sep '21

Hello! I could not find any information about default protocol preference values (administrative distance) for bird. Can anybody please help with it? Are there any default values for OSFP, BGP, static, etc.? Or is it better to configure each value explicitly?

3 3

When router becomes ABR, ospf is restarted
by Senthil Kumar Nagappan 06 Sep '21

06 Sep '21

Hi, While adding an area and if the router becomesABR, entire ospf protocol is restarted which deletes all the neighbors and adjacencies. can we not do this gracefully with the minimum disturbance toprotocol, like resending the router lsa with B bit enabled, redoing summary-lsasand route calculation? Thanks and Regards,Senthil

5 8

BFD and Juniper SRX inter-op issue
by Justin Cattle 02 Sep '21

02 Sep '21

Hi, I have encountered what seems to be a bug of sorts in the Juniper implementation of BFD in at least their SRX340. We have no issues with the QFX series, where BFD seems to work as expected with bird. I'm wondering if there is anything we can do to handle this issue on the bird side, or if anyone has any insight that may shed some light on the behaviour we are seeing. Here is the issue summary: - BFD timers are set quite conservatively - interval 4000 ms - multiplier 6 - A BFD session between a bird endpoint and a juniper endpoint is up and running at the start - all fine - If the you stop bird on the server, after the Detection time [ currently 24 secs ], the BFD messages from the Juniper show status as Down with the Diagnostic message Control Detection Time Expired. You can then start bird on the server again, and the two sides will agree session info and BFD status goes Up. - This is expected. - However, if you stop bird, but start it again before the Detection time [ currently 24 secs ], like for a service restart, the BFD messages from the Juniper never show as Down, and the two sides never agree on a BFD session and BFD remains Down on the server but Up on the Juniper. - Should a new session be established at this point ? - Once the Juniper gets stuck in the BFD status Up state, then you can stop the bird for a long time [ over an hour at least ] , and the Juniper never seems to notice [ the BFD packets still show state Up ]. - This seems to be a bug n the juniper end - why should it never go Down in this state ? - If the BFD session info is reset on the Juniper side, then the two sides will agree session info and BFD status goes Up. Does anyone have any thoughts ? Is there a packet bird can send, gratuitous or not, that can make the juniper end realise it MUST reinitialize ? Any config that can be tweaked to help ? Cheers, Just -- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.

3 4

Weird behavior on Bird 2.0.8 with Wireguard PtP links and OSPFv3
by Skyler Mäntysaari 31 Aug '21

31 Aug '21

Hi there, I'm not sure if anyone else has seen this issue but I have been getting this issue repeatably today, where OSPFv3 just stops working due to "bad DBDES packet from nbr", I haven't changed anything and it has been working fine for months. What's the best way to troubleshoot this? The neighbor starting with 193. is a Debian 10 machine, 185 and 192.168.2.1 are EdgeOS running Bird 2.0.8. 2021-08-31 17:23:53 <RMT> ospfv3_v4: Bad DBDES packet from nbr 192.168.2.1 on wg0 - I-bit mismatch (7) 2021-08-31 17:23:53 <RMT> ospfv3_v6: Bad DBDES packet from nbr 193.xxx.xxx.223 on wg1 - I-bit mismatch (7) 2021-08-31 20:38:41 <RMT> ospfv3_v6: Bad DBDES packet from nbr 185.xxx.xxx.130 on wg0 - too late for DD exchange (7) OSPF3 configuration: ------------------------------------------------------------------------------------------------- protocol ospf v3 ospfv3_v4 { ipv4 { import filter internel_prefixes; export filter internel_prefixes; #export where (source = RTS_STATIC) || (source = RTS_DEVICE); }; area 0.0.0.0 { interface "lo*" { stub; }; interface "tun0" { type ptp; cost 10; stub no; }; interface "wg0" { type ptp; cost 20; stub no; }; interface "wg1" { type ptp; cost 30; stub no; }; }; } protocol ospf v3 ospfv3_v6 { ipv6 { import filter internel_prefixes; export filter internel_prefixes; #export where (source = RTS_STATIC) || (source = RTS_DEVICE); }; area 0.0.0.0 { interface "lo*" { stub; }; interface "tun0" { type ptp; cost 10; stub no; }; interface "wg0" { type ptp; cost 20; stub no; }; interface "wg1" { type ptp; cost 30; stub no; }; }; } --------------------------------------------------------------------------------------------------------

1 0

latest blog post on bgp stack performance this time with Internet!
by Justin Pietsch 30 Aug '21

30 Aug '21

my latest blog post, this time playing back MRT data with full internet tables. https://elegantnetwork.github.io/posts/comparing-open-source-bgp-internet-r… . If anybody has suggestions on other bgp performance test tools or test results, I'd love to know about those. thanks, JUstin

1 0

RE: [EXT] Re: Troubleshooting BIRD as flowspec manager
by Noris Rogers 29 Aug '21

29 Aug '21

Sure! r1, r2, and r3 are FRR clients. BGP relationships are successfully formed and BGP routes are exchanged, but no flowspec is seen on the clients. I am currently analyzing packet captures, but still haven’t completely understood where in the packet header the flowspec is/should be. log syslog all; router id 4.4.4.4; protocol device { scan time 10; } flow4 table flowtab4; protocol static flowspec4{ flow4 { import all; export all; }; route flow4 { dst 172.16.0.1/32; }{ bgp_ext_community.add((generic, 0x80060000, 0x0)); }; } template bgp bgp_fs_temp { local as 4; ipv4 { import all; export all; }; flow4 { table flowtab4; import none; export all; }; } protocol bgp r1 from bgp_fs_temp { neighbor 172.16.4.2 as 1; } protocol bgp r2 from bgp_fs_temp { neighbor 172.16.4.6 as 2; } protocol bgp r3 from bgp_fs_temp { neighbor 172.16.4.10 as 3; Thank you! Noris From: 彭勇 <ppyy(a)pubyun.com> Sent: Thursday, August 26, 2021 11:17 PM To: Noris Rogers <nrogers(a)mitre.org> Cc: bird-users(a)network.cz Subject: [EXT] Re: Troubleshooting BIRD as flowspec manager can you share your config file to let us check? On Wed, Aug 25, 2021 at 4:23 AM Noris Rogers <nrogers(a)mitre.org<mailto:nrogers@mitre.org>> wrote: Hello, I am seeking to setup BIRD as a flowspec manager to send messages to FRR acting as a flowspec client. However, upon successful configuration of BGP relationships and advertising BGP routes, FRR is not able to see any flowspec rules. Is there a way to check to make sure BIRD is actually sending the flowspec rules with the BGP advertisements? Thanks! Noris -- 彭勇 (Peng Yong) 江苏网擎信息技术有限公司地址：常州市关河西路119号银苑大厦1406室电话：+86.519.68887168 传真：+86.519.68887169 手机：+86.18915883399 邮箱：ppyy@pubyun.com<mailto:ppyy@pubyun.com>

1 0