- Bird-users - Mailing Lists

[PATCH] Netlink: Propagate ecmp nexthop weight to kernel for inet6 routes
by Daniel Gröber 22 May '22

22 May '22

Previously nl_send_route would use plain nl_add_nexthop for ecmp ipv6 routes instead of adding RTA_MULTIPATH objects via nl_add_multipath. The former lacks support for the rtnexthop.rtnh_hops field need for setting the nexthop weight though. On the kernel side support for nexthop weights was introduced by commit 398958ae48 ("ipv6: Add support for non-equal-cost multipath") which landed in 4.16. Before this the weight will simply be ignored. Support for the ipv6 RTA_MULTIPATH attribute was added in 51ebd31815 ("ipv6: add support of equal cost multipath (ECMP)") which landed in 3.10. If this version bound isn't met installing the route will fail. --- sysdep/linux/netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index 29b744cb..5e0b036d 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -1446,7 +1446,7 @@ dest: { case RTD_UNICAST: r->r.rtm_type = RTN_UNICAST; - if (nh->next && !krt_ecmp6(p)) + if (nh->next) nl_add_multipath(&r->h, rsize, nh, p->af, eattrs); else { -- 2.30.2

1 0

Bird2 and protocol Babel. auto change default gw
by Michele Salerno 16 May '22

16 May '22

Hi, I am new to ML and also to using bird2. I use bird2 with babel protocol for routing the vpn server and openwrt router. The openwrt routers have a mesh wifi interface. My question is, if the wan (default gw) is down, can bird use the better mesh as the default gw? If the wan is restored, can it come back as default gw? Best regards, Michele

2 1

RFT: Babel RTT extension in Bird
by Toke Høiland-Jørgensen 12 May '22

12 May '22

Hi everyone I've implemented the Babel RTT extension specified in draft-ietf-babel-rtt-extension in Bird. I've tested that it talks to babeld on a single link and that the two implementations agree on each others' (smoothed) RTT values. However, I'd like to subject the code to some more tortured testing before submitting it to upstream Bird. So I'm sending this note as a request for testing. The code currently lives here: https://github.com/tohojo/bird/tree/babel-rtt-01 To compile it, do: git clone -b babel-rtt-01 https://github.com/tohojo/bird cd bird && autoreconf && ./configure && make To run it, create a config file enabling the RTT extension; the simplest way to do this is to set the interface type to 'tunnel'. A sample minimal config is included below (just change the interface name from "veth0"). Save this and run Bird in the foreground in debug mode like: ./bird -c sample.conf -d Any feedback (successes or failures) greatly appreciated! -Toke debug protocols all; router id 1.2.3.4; ipv4 table master4; ipv6 table master6; protocol device { scan time 10; } protocol kernel kernel4 { learn; ipv4 { export all; import all; }; } protocol kernel kernel6 { learn; ipv6 { import all; import all; }; } protocol babel { ipv4 { import all; export all; }; ipv6 { import all; export all; }; interface "veth0" { type tunnel; }; }

3 8

OSPF timers
by Kees Meijs | Nefos 12 May '22

12 May '22

Hello fellow birdies, Not a BIRD question per se, but I'll ask it anyway: any advice on changing OSPF (both v2 and v3) timers for faster convergence? Unfortunately I can't use BFD since the other end lacks support. Does it make sense to configure 2/8 for hello/dead or 1/4, or...? The transporting links are all 10G fiber with very low latency. Thanks in advance! Cheers, Kees -- https://nefos.nl/contact Nefos IT bv Ambachtsweg 25 (industrienummer 4217) 5627 BZ Eindhoven Nederland KvK 66494931 /Bereikbaar op werkdagen tussen 09:00u en 17:00u./

1 1

[PATCH 2/2] Babel: Add option to control ecmp nexthop weight
by Daniel Gröber 09 May '22

09 May '22

--- doc/bird.sgml | 21 ++++++++++++++------- proto/babel/babel.c | 1 + proto/babel/babel.h | 2 ++ proto/babel/config.Y | 2 ++ 4 files changed, 19 insertions(+), 7 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 5e85d8ec..1fdda7bc 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -1865,6 +1865,7 @@ protocol babel [<name>] { ipv4 { <channel config> }; ipv6 [sadr] { <channel config> }; randomize router id <switch>; + ecmp <switch> [limit <num>]; interface <interface pattern> { type <wired|wireless>; rxcost <number>; @@ -1879,7 +1880,7 @@ protocol babel [<name>] { check link <switch>; next hop ipv4 <address>; next hop ipv6 <address>; - ecmp <switch> [limit <num>]; + ecmp weight <num>; authentication none|mac [permissive]; password "<text>"; password "<text>" { @@ -1910,6 +1911,13 @@ protocol babel [<name>] { router ID every time it starts up, which avoids this problem at the cost of not having stable router IDs in the network. Default: no. + <tag><label id="babel-ecmp">ecmp <m>switch</m> [limit <m>number</m>]</tag> + + Determines whether babel will emit ECMP (equal-cost multipath) + routes, allowing to load-balancing traffic across multiple paths. If + enabled the maximum number of next-hops to allow can be specified, + defaulting to 16. + <tag><label id="babel-type">type wired|wireless </tag> This option specifies the interface type: Wired or wireless. On wired interfaces a neighbor is considered unreachable after a small number of @@ -1984,12 +1992,11 @@ protocol babel [<name>] { source for Babel packets will be used. In normal operation, it should not be necessary to set this option. - <tag><label id="babel-ecmp">ecmp <m>switch</m> [limit <m>number</m>]</tag> - - Determines whether babel will emit ECMP (equal-cost multipath) - routes, allowing to load-balancing traffic across multiple paths. If - enabled the maximum number of next-hops to allow can be specified, - defaulting to 16. + <tag><label id="babel-ecmp-weight">ecmp weight <m>number</m></tag> + This specifies the relative weight used for nexthops going through + the iface when ECMP is enabled. Larger weight values relative to other + nexthops attract more traffic. Valid values are 1-256. Default value + is 1. <tag><label id="babel-authentication">authentication none|mac [permissive]</tag> Selects authentication method to be used. <cf/none/ means that packets diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 4d9c657c..83d9a1d0 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -639,6 +639,7 @@ babel_nexthop_insert( { nh->gw = r->next_hop; nh->iface = r->neigh->ifa->iface; + nh->weight = r->neigh->ifa->cf->ecmp_weight; /* * If we cannot find a reachable neighbour, set the entry to be onlink. This diff --git a/proto/babel/babel.h b/proto/babel/babel.h index 3868dcb2..2ad1ded0 100644 --- a/proto/babel/babel.h +++ b/proto/babel/babel.h @@ -145,6 +145,8 @@ struct babel_iface_config { int tx_tos; int tx_priority; + u8 ecmp_weight; + ip_addr next_hop_ip4; ip_addr next_hop_ip6; diff --git a/proto/babel/config.Y b/proto/babel/config.Y index 8f18c790..6f03482a 100644 --- a/proto/babel/config.Y +++ b/proto/babel/config.Y @@ -70,6 +70,7 @@ babel_iface_start: BABEL_IFACE->tx_tos = IP_PREC_INTERNET_CONTROL; BABEL_IFACE->tx_priority = sk_priority_control; BABEL_IFACE->check_link = 1; + BABEL_IFACE->ecmp_weight = 0; }; @@ -149,6 +150,7 @@ babel_iface_item: | AUTHENTICATION NONE { BABEL_IFACE->auth_type = BABEL_AUTH_NONE; } | AUTHENTICATION MAC { BABEL_IFACE->auth_type = BABEL_AUTH_MAC; BABEL_IFACE->auth_permissive = 0; } | AUTHENTICATION MAC PERMISSIVE { BABEL_IFACE->auth_type = BABEL_AUTH_MAC; BABEL_IFACE->auth_permissive = 1; } + | ECMP WEIGHT expr { BABEL_IFACE->ecmp_weight = $3 - 1; if (($3<1) || ($3>256)) cf_error("ECMP weight must be in range 1-256"); } | password_list ; -- 2.30.2

3 2

Merging multiple routes into a single multipath route
by Johannes Erwerle 08 May '22

08 May '22

Hello. I am running a setup with 2 uplinks which both have dynamic addresses (via DHCP) and NAT and a Linux router. So I get 2 default routes via DHCP. I would like to use both uplinks via the linux multipath routing and I am searching for a way to "merge" both default routes that I get into one route with multiple next hops. Is there a way to accomplish that with bird? (or any other tool?) All of this is only relevant for IPv4. Greetings Jo

4 6

[PATCH] babel: Send out low-interval hello on shutdown
by Toke Høiland-Jørgensen 04 May '22

04 May '22

When shutting down a Babel instance we send a wildcard retraction to make sure all peers can quickly switch to other route origins. Add another small optimisation borrowed from babeld: sending a Hello message (along with the retraction) with a very low interval. This will cause neighbours to modify their expiry timers for the node's state to quickly time it out, thus conserving resources in the network. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 174fc9e26654..4c7f70c3ff66 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -842,14 +842,14 @@ babel_send_ihus(struct babel_iface *ifa) } static void -babel_send_hello(struct babel_iface *ifa) +babel_send_hello(struct babel_iface *ifa, uint interval) { struct babel_proto *p = ifa->proto; union babel_msg msg = {}; msg.type = BABEL_TLV_HELLO; msg.hello.seqno = ifa->hello_seqno++; - msg.hello.interval = ifa->cf->hello_interval; + msg.hello.interval = interval ?: ifa->cf->hello_interval; TRACE(D_PACKETS, "Sending hello on %s with seqno %d interval %t", ifa->ifname, msg.hello.seqno, (btime) msg.hello.interval); @@ -1557,7 +1557,7 @@ babel_iface_timer(timer *t) if (now_ >= ifa->next_hello) { - babel_send_hello(ifa); + babel_send_hello(ifa, 0); ifa->next_hello += hello_period * (1 + (now_ - ifa->next_hello) / hello_period); } @@ -1604,7 +1604,7 @@ babel_iface_start(struct babel_iface *ifa) tm_start(ifa->timer, 100 MS); ifa->up = 1; - babel_send_hello(ifa); + babel_send_hello(ifa, 0); babel_send_wildcard_retraction(ifa); babel_send_wildcard_request(ifa); babel_send_update(ifa, 0); /* Full update */ @@ -2417,6 +2417,11 @@ babel_iface_shutdown(struct babel_iface *ifa) { if (ifa->sk) { + /* + * Retract all our routes and lower the hello interval so peers' neighbour + * state expires quickly + */ + babel_send_hello(ifa, BABEL_TIME_UNITS); babel_send_wildcard_retraction(ifa); babel_send_queue(ifa); } -- 2.36.0

2 4

BIRD version 2.0.9
by Ondrej Filip 04 May '22

04 May '22

Dears BIRD users, Roughly after a year, I have got fantastic news for you, we just release a news version 2.0.9. I have to thank my great colleagues! Here is the list of the main features: Version 2.0.9 o BGP: Flowspec validation procedure o Babel: MAC authentication support o Routing table configuration blocks o Optional prefix trie in routing table for faster LPM/interval queries o CLI: New 'show route in <prefix>' command o Filter: Faster (16-way) prefix sets o Filter: MPLS label route attribute o Filter: Operators to pick community components o Filter: Operators to find minimum and maximum element of lists o BGP: New 'free bind' option o BGP: Log route updates that were changed to withdraws o BGP: Improved 'invalid next hop' error reporting o OSPF: Allow ifaces with host address as unnumbered PtP or PtMP ifaces o OSPF: All packets on PtP networks should be sent to AllSPFRouters address o Scripts for apkg-powered upstream packaging for deb and rpm o Support for Blake2s and Blake2b hash functions o Security keys / passwords can be entered in hexadecimal digits o Memory statistics split into Effective and Overhead o Linux: New option 'netlink rx buffer' to specify netlink socket buffer size o BSD: Assume onlink flag on ifaces with only host addresses o Many bugfixes Notes: For OSPF on PtP network, BIRD now sends all packets to multicast AllSPFRouters address (as required in RFC 2328 8.1). This likely breaks setups with multiple neighbors on a network configured as PtP, which worked in previous versions. Such links should be configured as PtMP. Since Linux 5.3, netlink socket can be flooded by route cache entries during route table scan. This version mitigates that issue by using strict netlink filtering.

5 4

Add ip rule support
by Huiyuze Zhi 04 May '22

04 May '22

Hi there, I'm having some issues with using bird2 to carry downstream. I have two different types of upstream. One can take downstream and the other cannot. I use bgp_large_community (141011, 3, xxx) to mark every prefix from upstream which can taken downstream and I sent those prefixes to my downstream. But when my upstream(which can take downstream) and upstream(which cannot take downstream) sent the same prefix, bgp_large_community ~ [(141011, 3 *)] then accept would filter both prefixes since they have the same destination. For example,one has BGP.large_community (141011, 3, 27000) and other not.So this prefix would be filtered, but I don't want it happens. 2600:380:180::/41 unicast [AS38008 00:47:10.975 from 2406:4440::1] * (110) [AS20057i] via 2406:4440::ffff:ffff:ffff:ffff on ens192 Type: BGP univ BGP.origin: IGP BGP.as_path: 38008 174 7018 20057 BGP.next_hop: 2406:4440::ffff:ffff:ffff:ffff fe80::b68a:5f00:6456:3005 BGP.local_pref: 100 BGP.aggregator: 107.112.201.68 AS64942 BGP.community: (174,21000) (174,22013) (38008,103) BGP.large_community: (141011, 1, 22000) unicast [HOME_1_ARCH 18:06:21.983] (100) [AS20057i] via 2a02:1218:2475::2 on home_1_arch Type: BGP univ BGP.origin: IGP BGP.as_path: 38136 6939 7018 20057 BGP.next_hop: 2a02:1218:2475::2 BGP.local_pref: 100 BGP.aggregator: 107.112.201.68 AS64942 BGP.originator_id: 103.149.145.104 BGP.cluster_list: 192.168.117.52 BGP.large_community: (38136, 1000, 17) (141011, 3, 27000) unicast [kskb 00:15:16.848] (100) [AS20057i] In addition, if I successfully export the prefixes that come from upstream can take downstream. When packages go through the kernel, they may also go through upstreamthat cannot take downstream. My idea is to let two different types of prefixes in different route tables. Table 100（All routing tables from BGP）and Table 101 (Only from Tier 1 ISP and can carry downstream routing table) and use IP rule command let ever prefixes that my downstream export to me via table 101. But there are so many prefixes so I do it by manual is impossible. and it seems bird2 doesn't support ip rule. [image: graph.png] -- *Huize Team* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter <https://twitter.com/zhihuiyuze> This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.

3 3

IGP Metric to MED
by Corban Johnson 29 Apr '22

29 Apr '22

Hello, I am trying to set MED on a BGP route using the metric value from OSPF, but the attributes of the next-hop route do not seem to be available in filter evolution. Am I missing something? Example Bird 2.0 config: protocol bgp test_peer { bfd on; med metric on; graceful restart on; ipv4 { table test_table; gateway recursive; }; local as 65656; } protocol ospf t1_igp { ipv4 { table test_table; }; } OSPF is distributing loopbacks and link nets only. BGP protocols from ‘test_peer’ will use routes learned from ‘t1_igp’ in ‘test_table’ to resolve next hop information (gateway recursive). So far, so good. However, I also have an eBGP peer (i.e. who is not participating in my IGP above) who is multi homed with AS65656. I would like to use MED to inform the peer about my IGP distances to each exit — something like the ‘metric-out minimum-igp <offset>’ command in Junos (https://www.juniper.net/documentation/en_US/junos/topics/reference/configur…) > You can increase or decrease the variable metric calculated from the IGP metric (either from the igp or minimum-igp statement) by specifying a value for offset. The metric is increased by specifying a positive value for offset, and decreased by specifying a negative value for offset. The problem seems to be that filters may only access attributes of the route currently processed, and the 'gateway recursive’ channel directive only calculates next-hop without passing any route attributes of that next-hop through. Has anyone had any luck trying something similar? Many thanks.

3 5