February 2023 - Bird-users

https://github.com/CZ-NIC/bird repo sync
by Alexander Chernikov 21 Feb '23

21 Feb '23

Dear bird team, The GitHub cz-nic/bird repository mirror looks stale - the last commit there is from October 5, 2020? Is this intentional? If not, would it be possible to make it track the current bird git repo? One of the big benefits of GitHub (for me) is an easy standard mechanism of tracking the changes - everyone with GitHub account can subscribe for the commits notification with a single click. /Alexander

2 2

Binding to some interfaces only for multihop bgp
by Sebastian Hahn 20 Feb '23

20 Feb '23

Hi, I would like bird to bind to some interfaces only, but use some multihop neighbours. Is there any easy way to achieve such a configuration? The strict bind option is incompatible with multihop, and I haven't seen anything where i can give a positive or negative list of interfaces to bind to / not to bind to. Thanks Sebastian

3 5

BIRD BGP Local pref control
by Shun Murayama 17 Feb '23

17 Feb '23

Hello bird users, I'm testing BIRD in my test environment. I have two problems and would you please share your knowledge. 1. Don't you know the regex to control as_path in the BGP BIRD? I'd like to set if as-path much "^neighborAS_Tier1AS", then set the higher local preference. BIRD's bgp_path attribute appears to support bgp_path.first and bgp_path.last. 2. Someone use the previous computer to run the BIRD BGP? I'll try to performance receive BGP Full-Route, advertise few route and sent 10G+ traffic. If you run BIRD BGP using the previous Xeon CPU(like E5 series) in the Linux servers and Linux kernel, let me know how much traffic can control. I hope you have any knowledge. Best reguard, Shun ----------------------------- Shun Murayama Internet Initiative Japan Inc. Mail:shun-m@iij.ad.jp

1 0

BGP config causing "Socket: Permission denied"
by Nico Schottelius 17 Feb '23

17 Feb '23

Hello fellow bird users, with bird 2.0.12 I am currently getting an "Socket: Permission denied" error messages when trying to establish a specific IPv6 iBGP session. The funny thing is that another connection works perfectly. The BGP block that fails is: -------------------------------------------------------------------------------- protocol bgp serverXX { local as xx; neighbor 2a0a:...::44 as xx; direct; ipv6 { import all; export all; }; ipv4 { import all; export all; }; } -------------------------------------------------------------------------------- Resulting into: bird> show protocols all serverXX Name Proto Table State Since Info serverXX BGP --- start 12:18:52.466 Active Socket: Permission denied BGP state: Active Neighbor address: 2a0a:..::44 Neighbor AS: xx Local AS: xx Connect delay: 2.961/5 Last error: Socket: Permission denied Channel ipv6 State: DOWN Table: master6 Preference: 100 Input filter: ACCEPT Output filter: ACCEPT Channel ipv4 State: DOWN Table: master4 Preference: 100 Input filter: ACCEPT Output filter: ACCEPT -------------------------------------------------------------------------------- An almost identical iBGP session is established without problems: -------------------------------------------------------------------------------- protocol bgp routerZZ { local as xx; neighbor 2a0a:..::6 as xx; direct; ipv6 { import all; export all; }; ipv4 { import all; export all; }; } -------------------------------------------------------------------------------- Obviously the IPs are different, but I am really puzzled at to what causes this. It's bird 2.0.12 running on Linux, iptables/ip6tables are not having any rules. Interestingly the peer on the other side has exactly the same error. Does anyone have a hint on what might be wrong here? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

1 1

Some news about Babel
by Juliusz Chroboczek 16 Feb '23

16 Feb '23

Hi, Discussions related to Babel are currently distributed across three distrinct mailing-lists (babel-users@alioth, babel@ietf, bird-users), and I'm a little concerned that those of you who are subscribed to just one of them are missing out on the whole picture. Since I'm on strike today, and have some time before I go demonstrating, I've decided to to write up the current activity. 1. IETF activity ================ We've managed to publish as RFCs almost all that's used in production. The exceptions are: - relaxed MAC verification (draft-ietf-babel-mac-relaxed), which is stuck in limbo for reasons that I don't understand; - RTT-based routing (draft-ietf-babel-rtt-extension), which I keep wanting to rewrite, but keep getting sidetracked by things like student examinations and the French government implementing "reforms". 2. Babeld activity ================== I've just released babeld-1.12.2, which is a pure bugfix release. Babeld is in a fairly stable state, which is good. The master branch removes diversity routing (Babel-Z), which seemed like a good idea at the time, but we never managed to show that it improves performance over ETX. There's work going on in a side branch to make redistribution more efficient, I'm planning to release 1.13 when that is done. No new user-visible features are currently planned, sorry to everyone who requested. 3. BIRD activity ================ The implementation of Babel in BIRD has received a number of bug fixes and new features, and it's slowly getting to feature parity with babeld. This is excellent news, since BIRD is an outstanding routing platform, and there are a number of commercial routers that use BIRD as their control plane. If you're running a production Babel network, I urge you to try out the current master branch of BIRD (a version dated 2023-01-31 or later, earlier versions have known bugs). If BIRD works in your network, great, you now have two independent implementations to choose from, and the bus factor of your network has increased. If BIRD is missing features that you need, please contact the developers (most seem to subscribe to both bird-users and babel-users), and I'm confident somebody will look at your use case. Just to be clear: the good state of the BIRD implementation does not mean that I have any plans to abandon babeld. It is important to have two independent implementations of a protocol, it keeps the developers honest. 4. Major failures ================= The big disappointment is that Microtik have still not implemented Babel in their products (I was under the mistaken impression that they were planning to do so when it became a standards-track RFC), and have instead opted to implement yet another proprietary link-layer meshing protocol. The other disappointment is FRR, whose implementation of Babel is based on an old, buggy version of babeld. The developers have accepted to fix some of the bugs that I reported to them, then got bored and told me that I could go fix the bugs myself. I cannot currently recommend the use of FRR for Babel. The IETF Homenet working group has defined a protocol stack for home networks based on Babel. The Homenet protocols have been a technical success, but a commercial failure, with no vendors that we know of planning to implement the Homenet stack. The Homenet working group is now closed, and has been replaced by the SNAC working group, which has way more modest ambitions. SNAC does not mandate the use of a routing protocol, which dramatically restricts what it can do (it is essentially designed to connect a single Zigbee link to a home network). Followups restricted to babel-users, but feel free to override my choice. -- Juliusz

1 0

OSPF NSSA
by Konrad Kręciwilk 16 Feb '23

16 Feb '23

Hello Team, I encountered a weird problem with OSPF. I attache scheme.png. R1 and R2 has configured area0 via vlan1000, both has also area1 NSSA to R3. Simply: ------------------------- config R1: protocol ospf CORE_OSPF { tick 1; ipv4 { import all; export none; }; area 0.0.0.0 { interface "vlan1000" { cost 2; type ptp; bfd; }; }; area 0.0.0.1 { nssa; interface "vlan4001" { type ptp; bfd yes; }; }; }; R1: Bird 2.0.10 ------------------------- config R2: protocol ospf CORE_OSPF { tick 1; ipv4 { import all; export none; }; area 0.0.0.0 { interface "vlan1000" { cost 2; type ptp; bfd; }; }; area 0.0.0.1 { nssa; interface "vlan4011" { type ptp; bfd yes; }; }; }; R2: Bird 2.0.11 ------------------------- config R3: function allow_network() prefix set localnet; { localnet = [ 10.0.0.0/8{24,30}]; ospf_metric1 = 20; if net ~ localnet then return true; else return false; } filter out_connected { if allow_network() then accept; else reject; } protocol ospf CORE_OSPF { tick 1; ipv4 { import all; export filter out_connected; }; area 0.0.0.1 { nssa; interface "vlan4001" { cost 100; type ptp; bfd yes; }; interface "vlan4011" { cost 100; type ptp; bfd yes; }; }; }; conntected interface with 10.7.100.254/24: # ifconfig vlan91 vlan91: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=4600703<RXCSUM,TXCSUM,TSO4,TSO6,LRO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP> ether a0:36:9f:9d:4a:4c inet 10.7.100.254 netmask 0xffffff00 broadcast 10.7.100.255 groups: vlan vlan: 91 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> R3: Bird 2.0.11 ------------------------- In normale state, every looks good. R1 and R2 see connected subnets from R3 as OSPF E1 via local vlan (R1->4001, R2->4011), R3 recevied default route (nssa): from R1: BIRD 2.0.10 ready. bird> show route for 10.7.100.254 Table master4: 10.7.100.0/24 unicast [CORE_OSPF 23:08:09.064] * E1 (150/30) [xx.xx.xx.xx] via xx.xx.92.141 on vlan4001 bird> from R2: BIRD 2.0.11 ready. bird> show route for 10.7.100.254 Table master4: 10.7.100.0/24 unicast [CORE_OSPF 23:21:35.334] * E1 (150/30) [xx.xx.xx.xx] via xx.xx.92.137 on vlan4011 bird> but when on the switch remove e.g. vlan4001 to R3 (broken L2 connectivity), R1 still see via vlan4001 (all dead times have expired - configured bfd). When I set ifconfig vlan4001 down on R3 the announcement disappears, R1 and R2 to do not see 10.7.100.0/24. if in this state (vlan4001 - broken connectivity, R3: vlan4001 state down), I restart bird process the situation is getting better - R2 see 10.7.100.254 via vlan4011 and R1 see 10.7.100.254 via vlan1000 (area0). I rewrite R3 config from Bird to Quagga and there is no such things. I have also R4 (mikrotik) connected in a similar way (AREA2 NSSA) and also works fine when I emulate L2 connectivity interrupt. I can provide all the logs from the devices, All nodes are FreeBSD. Regards, Konrad Kręciwilk

2 5

[PATCH] babel: Keep separate auth PC counters for unicast and multicast
by Toke Høiland-Jørgensen 14 Feb '23

14 Feb '23

The babel protocol normally sends all its messages as multicast packets, but the protocol specification allows most messages to be sent as either unicast or multicast, and the two can be mixed freely. In particular, the babeld implementation can be configured to unicast updates to all peers instead of sending them as unicast. Daniel discovered that this can cause problems with the packet counter checks in the MAC extension due to packet reordering. This happens on WiFi networks where clients have power save enabled (which is quite common in infrastructure networks): in this case, the access point will buffer all multicast traffic and only send it out along with its beacons, leading to a maximum buffering in default Linux-based access point configuration of up to 200 ms. This means that a Babel sender that mixes unicast and multicast messages can have the unicast messages overtake the multicast messages because of this buffering; when authentication is enabled, this causes the receiver to discard the multicast message when it does arrive because it now has a packet counter value less than the unicast message that arrived before it. Daniel observed that this happens frequently enough that Babel ceases to work entirely when runner over a WiFi network. The issue has been described in draft-ietf-babel-mac-relaxed, which is currently pending RFC publication. That also describes two mitigation mechanisms: Keeping separate PC counters for unicast and multicast, and using a reorder window for PC values. This patch implements the former as that is the simplest, and resolves the particular issue seen on WiFi. Reported-by: Daniel Gröber <dxld(a)darkboxed.org> Tested-by: Daniel Gröber <dxld(a)darkboxed.org> Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 28 ++++++++++++++++++++++------ proto/babel/babel.h | 4 +++- proto/babel/packets.c | 1 + 3 files changed, 26 insertions(+), 7 deletions(-) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index ff8b6b52ef4a..499b45b5f18f 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -1543,7 +1543,8 @@ babel_auth_check_pc(struct babel_iface *ifa, struct babel_msg_auth *msg) n->auth_index_len = msg->index_len; memcpy(n->auth_index, msg->index, msg->index_len); - n->auth_pc = msg->pc; + n->auth_pc_unicast = msg->pc; + n->auth_pc_multicast = msg->pc; n->auth_passed = 1; return 1; @@ -1562,16 +1563,31 @@ babel_auth_check_pc(struct babel_iface *ifa, struct babel_msg_auth *msg) return 0; } - /* (6) Index matches; only accept if PC is greater than last */ - if (n->auth_pc >= msg->pc) + /* + * (6) Index matches; only accept if PC is greater than last. We keep separate + * counters for unicast and multicast because multicast packets can be delayed + * significantly on wireless networks (enough to be received out of order). + * Separate counters are safe because the packet destination address is part + * of the MAC pseudo-header (so unicast packets can't be replayed as multicast + * and vice versa). + */ + if ((msg->unicast && n->auth_pc_unicast >= msg->pc) || + (!msg->unicast && n->auth_pc_multicast >= msg->pc)) { LOG_PKT_AUTH("Authentication failed for %I on %s - " - "lower packet counter (rcv %u, old %u)", - msg->sender, ifa->ifname, msg->pc, n->auth_pc); + "lower %s packet counter (rcv %u, old %u)", + msg->sender, ifa->ifname, + msg->unicast ? "unicast" : "multicast", + msg->pc, + msg->unicast ? n->auth_pc_unicast : n->auth_pc_multicast); return 0; } - n->auth_pc = msg->pc; + if (msg->unicast) + n->auth_pc_unicast = msg->pc; + else + n->auth_pc_multicast = msg->pc; + n->auth_passed = 1; return 1; diff --git a/proto/babel/babel.h b/proto/babel/babel.h index da8386b3b76a..c76c82a63ef1 100644 --- a/proto/babel/babel.h +++ b/proto/babel/babel.h @@ -227,7 +227,8 @@ struct babel_neighbor { u16 next_hello_seqno; uint last_hello_int; - u32 auth_pc; + u32 auth_pc_unicast; + u32 auth_pc_multicast; u8 auth_passed; u8 auth_index_len; u8 auth_index[BABEL_AUTH_INDEX_LEN]; @@ -405,6 +406,7 @@ struct babel_msg_auth { u8 challenge_seen; u8 challenge_len; u8 challenge[BABEL_AUTH_MAX_NONCE_LEN]; + u8 unicast; }; static inline int babel_sadr_enabled(struct babel_proto *p) diff --git a/proto/babel/packets.c b/proto/babel/packets.c index d4acc17042d2..027da4429e4d 100644 --- a/proto/babel/packets.c +++ b/proto/babel/packets.c @@ -1655,6 +1655,7 @@ babel_read_pc(struct babel_tlv *hdr, union babel_msg *m UNUSED, state->auth.pc_seen = 1; state->auth.index_len = index_len; state->auth.index = tlv->index; + state->auth.unicast = state->is_unicast; state->current_tlv_endpos += index_len; return PARSE_SUCCESS; -- 2.39.1

3 7

BIRD 2.0.{7,10} MED not actually send for learned routes if export table on is set
by Inrin 04 Feb '23

04 Feb '23

Greetings, I noticed during setting up a peering that the MED is not actually send to my peer, although bird shows it in the export. We confirmed this via tcpdump on both ends. After debugging a bit, I noticed that this only affects “learned” routes but routes from the static protocol worked just fine. After disabling the “export table” feature, the MED was send out just fine. Is this behaviour expected? This behaviour is reproducible in BIRD 2.0.7 and 2.0.10 with the following scenario (Configs to test are attached): R0 is connected to R1 and R2 R0, R1 and R2 send each one route R0 sets the MED to 300 R1 sets the MED to 100 R2 sets the MED to 200 Setting “export table on;” yields the following results: # Bird shows the MED in the export R0 $ ./birdc s r all export R1 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [static1 02:05:56.604] * (200) Type: static univ BGP.med: 300 198.18.2.0/24 unicast [R2 02:11:51.132 from 198.19.0.2] * (100) [AS4242420002i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420002 BGP.next_hop: 198.19.0.2 BGP.med: 300 BGP.local_pref: 100 R0 $ ./birdc s r all export R2 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [static1 02:05:56.604] * (200) Type: static univ BGP.med: 300 198.18.1.0/24 unicast [R1 02:11:51.133 from 198.19.0.1] * (100) [AS4242420001i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420001 BGP.next_hop: 198.19.0.1 BGP.med: 300 BGP.local_pref: 100 R0 # But on R1, R2 it does not appear for learned routes: R1 $ ./birdc s r all protocol R0 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [R0 02:11:51.133 from 198.19.0.0] * (100) [AS4242420000i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 198.18.2.0/24 unicast [R0 02:11:51.133 from 198.19.0.0] * (100) [AS4242420002i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 4242420002 BGP.next_hop: 198.19.0.0 BGP.local_pref: 100 R1 $ R2 $ ./birdc s r all protocol R0 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [R0 02:11:51.132 from 198.19.0.0] * (100) [AS4242420000i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 198.18.1.0/24 unicast [R0 02:11:51.133 from 198.19.0.0] * (100) [AS4242420001i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 4242420001 BGP.next_hop: 198.19.0.0 BGP.local_pref: 100 R2 $ Setting “export table off;” yield the expected result: R1 $ ./birdc s r all protocol R0 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [R0 03:15:47.147 from 198.19.0.0] * (100) [AS4242420000i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 198.18.2.0/24 unicast [R0 03:15:50.635 from 198.19.0.0] * (100) [AS4242420002i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 4242420002 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 R1 $ R2 $ ./birdc s r all protocol R0 BIRD 2.0.10 ready. Table master4: 198.18.0.0/24 unicast [R0 03:15:50.635 from 198.19.0.0] * (100) [AS4242420000i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 198.18.1.0/24 unicast [R0 03:15:50.635 from 198.19.0.0] * (100) [AS4242420001i] Type: BGP univ BGP.origin: IGP BGP.as_path: 4242420000 4242420001 BGP.next_hop: 198.19.0.0 BGP.med: 300 BGP.local_pref: 100 R2 $

6 11

[PATCH] babel: Initialise source seqno from incoming message
by Toke Høiland-Jørgensen 01 Feb '23

01 Feb '23

When creating a new babel_source object we initialise the seqno to 0. The caller will update the source object with the right metric and seqno value, for both newly created and old source objects. However if we initialise the source object seqno to 0 that may actually turn out to be a valid (higher) seqno than the one in the routing table, because of seqno wrapping. In this case the source metric will not be set properly, which breaks feasibility tracking for subsequent updates. To fix this, add a new initial_seqno argument to babel_get_source() which is used when allocating a new object, and set that to the seqno value of the update we're sending. Reported-by: Juliusz Chroboczek <jch(a)irif.fr> Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 25081c3bde2f..b7bb374206dc 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -105,7 +105,8 @@ babel_find_source(struct babel_entry *e, u64 router_id) } static struct babel_source * -babel_get_source(struct babel_proto *p, struct babel_entry *e, u64 router_id) +babel_get_source(struct babel_proto *p, struct babel_entry *e, u64 router_id, + u16 initial_seqno) { struct babel_source *s = babel_find_source(e, router_id); @@ -115,7 +116,7 @@ babel_get_source(struct babel_proto *p, struct babel_entry *e, u64 router_id) s = sl_allocz(p->source_slab); s->router_id = router_id; s->expires = current_time() + BABEL_GARBAGE_INTERVAL; - s->seqno = 0; + s->seqno = initial_seqno; s->metric = BABEL_INFINITY; add_tail(&e->sources, NODE s); @@ -1014,7 +1015,7 @@ babel_send_update_(struct babel_iface *ifa, btime changed, struct fib *rtable) /* Update feasibility distance for redistributed routes */ if (e->router_id != p->router_id) { - struct babel_source *s = babel_get_source(p, e, e->router_id); + struct babel_source *s = babel_get_source(p, e, e->router_id, msg.update.seqno); s->expires = current_time() + BABEL_GARBAGE_INTERVAL; if (gt_mod64k(msg.update.seqno, s->seqno) || -- 2.39.1

3 5