April 2022 - Bird-users - Mailing Lists

[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

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

Re: [babel] RFT: Babel RTT extension in Bird
by Ondrej Zajicek 26 Apr '22

26 Apr '22

On Fri, Apr 22, 2022 at 08:06:24PM +0200, Juliusz Chroboczek wrote: > > Did not yet checked the code how smoothing is done here, but seems to me > > that considering: > > > > 1) There is baseline RTT from distance / speed of propagation > > 2) There is one-side noise from congestion > > 3) The metric should be based on 1) and suppress effects of 2) > > > > It would make sense to use something like running minimum instead of > > running average. > > Yes, it would make sense. The reason why we calculate an exponential > average is that it is cheaper to compute, and works quite well in > practice. The goal here is not to compute an accurate metric, it is to > reliably choose the best route: the metric only needs to be accurate > enough to ensure that the right route is being picked. I guess that how much that works in practice depends on many circumstances. For example, consider this case: a mobile device connected by wifi to local AP, with VPNs to two endpoints, one local (< 1ms base latency), one in different town (~10ms base latency), but the communication is subject to wifi latency, which is noisy (mostly ~1ms, but in <5% cases there is 100-1000ms spike). Then both exponencial running averages are random variables with expected value shifted by 10 ms, but with big enough variance than it may often come out in reverse. (that is, btw, the real use case how i would use it) It is true that exponential running average is nice and elegant algorithm, so perhaps instead of using running minimum over many values, one could just use minimum over small number of latest values (say 8-16) as a pre-filter and use exponential average on result. I think that computational cost is negligible for such change and it would suppress effect of latency spikes common in wifi networks. > > But RTT-based cost have applications that are unrelated to tunnels. > > I'd be very interested if you could give me some examples, in case > I decide to revive the paper above. IMHO base-RTT-based cost make sense as a reasonable initial choice for regular IGP on regular (wired) links for a geographically spread out network (e.g. ISP backbone) in the absence of an explicit policy. Also, it would make sense to use RTT as an AIGP metric in public BGP, as it does not require coordination on metric scale and would eliminate some routing oddities. But in both these case one would probably suffice with static rtt measurement during adjacency establishment instead of continuous measurement. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago(a)crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

1 0

BGP selection
by Alexandre Corso 26 Apr '22

26 Apr '22

Hello, I found a strange behaviour on my BIRD route reflector: BIRD version: 2.0.7 Topology: ------ vrr01_ny2_nyc RR1 || ------ vrr01_pa4_par ---- CORE1 I have one route A.A.A.A received via two other Router reflector (vrr01_ny2_nyc / vrr01_pa4_par) The origin of the route is 185.x.x.x $ birdc show route A.A.A.A/32 table ipv4_rr all BIRD 2.0.7 ready. Table ipv4_rr: A.A.A.A/32 unicast [ipv4_vrr01_ny2_nyc 00:54:45.006 from 100.100.254.133] * (100/67955) [AS65030?] via 100.99.0.120 on eth2.666 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 64655 65030 BGP.next_hop: 185.x.x.x BGP.local_pref: 100 BGP.community: (35280,843) (35280,844) (35280,1010) (35280,2060) (35280,3070) BGP.originator_id: 185.x.x.x BGP.cluster_list: 0.0.0.21 0.0.0.11 unicast [ipv4_vrr01_pa4_par 2022-04-14 from 100.100.254.134] (100/68045) [AS65030?] via 100.99.0.120 on eth2.666 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 64655 65030 BGP.next_hop: 185.x.x.x BGP.local_pref: 100 BGP.community: (35280,843) (35280,844) (35280,1010) (35280,2060) (35280,3070) BGP.originator_id: 185.x.x.x BGP.cluster_list: 0.0.0.11 I check the metric to 185.x.x.x and I see 67955, but on my second route (learned via vrr01_pa4_par), I see another value (68045) $ birdc show route 185.x.x.x BIRD 2.0.7 ready. Table master4: 185.x.x.x /32 unicast [ospfv2 23:56:36.331] I (150/67955) [185.x.x.x] via 100.99.0.120 on eth2.666 Can you help me to understand the behaviour? I don’t understand why the second route is not preferred as the cluster_list is smaller (probably the BGP algorithm in BIRD). More information $ birdc show route 100.100.254.133/32 BIRD 2.0.7 ready. Table master4: 100.100.254.133/32 unicast [ospfv2 2022-04-20] I (150/133525) [100.100.254.133] via 100.99.0.120 on eth2.666 $ birdc show route 100.100.254.134/32 BIRD 2.0.7 ready. Table master4: 100.100.254.134/32 unicast [ospfv2 2022-04-20] I (150/132615) [100.100.254.134] via 100.99.0.120 on eth2.666 Part of the configuration (same for the 2 peers) protocol bgp ipv4_vrr01_ny2_nyc from IPV4_RR_PEER { description "IPv4 vrr01.ny2.nyc"; neighbor 100.100.254.133; ipv4 { import filter bgp_in_rr_v4; export filter bgp_full_view_v4; }; } protocol bgp ipv4_vrr01_pa4_par from IPV4_RR_PEER { description "IPv4 vrr01.pa4.par"; neighbor 100.100.254.134; ipv4 { import filter bgp_in_rr_v4; export filter bgp_full_view_v4; }; } Does somebody have the full BGP algorithm? Alexandre Corso AS35280

3 2

Re: [babel] RFT: Babel RTT extension in Bird
by Toke Høiland-Jørgensen 23 Apr '22

23 Apr '22

Juliusz Chroboczek <jch(a)irif.fr> writes: >> That seems like an interesting idea, especially for things like >> automatically switching between multiple Wireguard tunnel concentrators. > > That's exactly the application that it was designed for. For some > background, please see > > https://arxiv.org/pdf/1403.3488.pdf > > (I never managed to publish this paper, and rightly so -- it's not a very > good paper, since I don't fully understand why the smoothing+hysteresis > works as well as it does.) I'd be delighted to hear the (real?) explanation for that! >> Did not yet checked the code how smoothing is done here, but seems to me >> that considering: >> >> 1) There is baseline RTT from distance / speed of propagation >> 2) There is one-side noise from congestion >> 3) The metric should be based on 1) and suppress effects of 2) >> >> It would make sense to use something like running minimum instead of >> running average. > > Yes, it would make sense. The reason why we calculate an exponential > average is that it is cheaper to compute, and works quite well in > practice. The goal here is not to compute an accurate metric, it is to > reliably choose the best route: the metric only needs to be accurate > enough to ensure that the right route is being picked. Juliusz, I also seem to recall you mentioning to me at some point that the RTT increasing due to congestion actually makes the RTT extension useful as a way of picking the least-congested route as well (as a kind of unintentional side effect due to exactly what Ondrej mentioned above). Or am I misremembering? > I agree that we should compare with a running average. I might do so if > I ever decide to revive that paper. I assume you meant 'running minimum' here? >> There is one thing that is IMHO a bit strange, type wired/wireless/tunnel >> option is just an indirect way of set k-from-j / ETX / RTT-based cost >> algorithm. Note that the RTT-based cost algorithm doesn't replace the ETX/k-from-j, it just adds an additional configurable penalty on top. >> But RTT-based cost have applications that are unrelated to tunnels. > > I'd be very interested if you could give me some examples, in case > I decide to revive the paper above. > >> Seems to me that it would make sense to have a direct option to set the >> cost algorithm (and just that), while the 'type' option would provide >> reasonable default for that (and possibly other options). > > In babeld (the standalone implementation of Babel, the interface type is > a macro that sets both the base metric and the metric algorithm; the two > can be set separately if desired by the user. However, we have found that > the "interface type" abstraction is easier to get right for our users. I implemented the RTT extension the same way in Bird: The 'tunnel' interface type just sets a default RTT cost or 96 (and is otherwise identical to 'wired'), and there's a separate config option to explicitly set the RTT cost. In fact, I just mirrored all the babeld config options related to RTT, just adapted to Bird syntax :) However, there is no explicit config option in Bird for the metric computation algorithm (i.e., ETX/k-from-j). I guess we should add one :) BTW, I'm also planning to add some infrastructure to Bird to automatically guess the interface type, and have Babel use that to set a reasonable default. I believe babeld has something similar (although I seem to recall something about the wireless detection having bitrotted slightly? Or was that only the channel information?). -Toke

1 0

Fwd: Re: [babel] RFT: Babel RTT extension in Bird
by Toke Høiland-Jørgensen 22 Apr '22

22 Apr '22

Forwarding on behalf of Juliusz since he's not subscribed to bird-users. -Toke -------- Original Message -------- From: Juliusz Chroboczek <jch(a)irif.fr> Sent: 22 April 2022 20:06:24 CEST To: Ondrej Zajicek <santiago(a)crfreenet.org> Cc: "Toke Høiland-Jørgensen" <toke(a)toke.dk>, bird-users(a)network.cz, babel-users(a)alioth-lists.debian.net, babel(a)ietf.org Subject: Re: [babel] RFT: Babel RTT extension in Bird > That seems like an interesting idea, especially for things like > automatically switching between multiple Wireguard tunnel concentrators. That's exactly the application that it was designed for. For some background, please see https://arxiv.org/pdf/1403.3488.pdf (I never managed to publish this paper, and rightly so -- it's not a very good paper, since I don't fully understand why the smoothing+hysteresis works as well as it does.) > Did not yet checked the code how smoothing is done here, but seems to me > that considering: > > 1) There is baseline RTT from distance / speed of propagation > 2) There is one-side noise from congestion > 3) The metric should be based on 1) and suppress effects of 2) > > It would make sense to use something like running minimum instead of > running average. Yes, it would make sense. The reason why we calculate an exponential average is that it is cheaper to compute, and works quite well in practice. The goal here is not to compute an accurate metric, it is to reliably choose the best route: the metric only needs to be accurate enough to ensure that the right route is being picked. I agree that we should compare with a running average. I might do so if I ever decide to revive that paper. > There is one thing that is IMHO a bit strange, type wired/wireless/tunnel > option is just an indirect way of set k-from-j / ETX / RTT-based cost > algorithm. [...] > But RTT-based cost have applications that are unrelated to tunnels. I'd be very interested if you could give me some examples, in case I decide to revive the paper above. > Seems to me that it would make sense to have a direct option to set the > cost algorithm (and just that), while the 'type' option would provide > reasonable default for that (and possibly other options). In babeld (the standalone implementation of Babel, the interface type is a macro that sets both the base metric and the metric algorithm; the two can be set separately if desired by the user. However, we have found that the "interface type" abstraction is easier to get right for our users. -- Juliusz

1 0

[PATCH] Doc: fix mating -> matching in flowspec section
by Vincent Bernat 22 Apr '22

22 Apr '22

--- doc/bird.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 9c4a6f68a447..1580facd8155 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -5251,7 +5251,7 @@ Note that for negated matches, value must be either zero or equal to bitmask <cf>port 1..1023,1194,3306</cf>). <tag><label id="flow-dport">dport <m/numbers-match/</tag> - Set a mating destination port numbers (e.g. <cf>dport 49151</cf>). + Set a matching destination port numbers (e.g. <cf>dport 49151</cf>). <tag><label id="flow-sport">sport <m/numbers-match/</tag> Set a matching source port numbers (e.g. <cf>sport = 0</cf>). -- 2.35.2

2 1

advertise ipv4 prefixes over ipv6 ibgp session
by gautham devalapalli 22 Apr '22

22 Apr '22

Hello, I am trying to advertise an ipv4 host/prefix over an ipv6 ibgp session. But I keep seeing a withdrawn message on the bgp update message for the ipv4 routes. The same works with ixia traffic generator.(the router-id is picked up as the next hop in ixia's case). Can you please point me in the right direction? bgp update packet: 0000 00 de fb d4 89 c7 00 00 10 00 10 02 81 00 00 65 ...............e 0010 86 dd 6c 00 00 00 00 40 06 40 20 01 0d b8 00 10 ..l....@.@ ..... 0020 00 00 00 00 00 00 00 00 00 02 20 01 0d b8 00 10 .......... ..... 0030 00 00 00 00 00 00 00 00 00 01 e7 1f 00 b3 76 3c ..............v< 0040 8e 81 0f 3b 59 6e 80 18 00 e1 6d 83 00 00 01 01 ...;Yn....m..... 0050 08 0a 20 e1 8b 5d 46 08 2b ba ff ff ff ff ff ff .. ..]F.+....... 0060 ff ff ff ff ff ff ff ff ff ff 00 20 02 00 09 20 ........... ... 0070 14 01 01 01 18 1e 01 01 00 00 .......... bird config. protocol bgp ibgp_phy1_node01 { local 2001:db8:10::2 as 100; neighbor 2001:db8:10::1 as 100; ipv4 { import all; export filter { if net ~[20.1.1.1/32] || net ~[30.1.1.0/24] then { bgp_ext_community.add((unknown 0x4004,100,0x447a0000)); accept; } reject; }; }; ipv6 { import all; export filter { if net ~[2000:1:1::1/128] || net ~[3000:1:1::0/96] then { bgp_ext_community.add((unknown 0x4004,100,0x447a0000)); accept; } reject; }; }; } protocol static staticv4 { ipv4 { import all; export all; }; route 20.1.1.1/32 via 2001:db8:10::2; route 30.1.1.0/24 via 2001:db8:10::2; } protocol static staticv6 { ipv6 { import all; export all; }; route 2000:1:1::1/128 via 2001:db8:10::2; route 3000:1:1::0/96 via 2001:db8:10::2; } Sincerely Gautham

2 2

bgp keepalive & hold timers
by Alexander Zubkov 19 Apr '22

19 Apr '22

Hi, Found interesting thing. If I set "keepalive time" for a BGP session, this values is not modified after the hold time negotiations and as a result I can get a BGP session with hold timer less than keepalive timer and it will die due to hold timer expired after some time. https://gitlab.nic.cz/labs/bird/-/blob/692055e3df6cc9f0d428d3b0dd8cdd8e825e… I think more correct bahivour would be to close the BGP session with unacceptable hold timer error in such case.

2 3