April 2020 - Bird-users - Mailing Lists

RFC 5575 question: is Destination Prefix mendatory?
by Alarig Le Lay 22 Apr '20

22 Apr '20

Hi, it seems that for bird, the flowspec destination prefix is mentatory. I have a session with an exabgp and if I send this echo 'announce flow route { match { source 213.167.241.55/32; destination 0.0.0.0/0; } then { discard; } }' > /var/run/exabgp.cmd It works, I have the route: bird> show route all table flowtab4 Table flowtab4: flow4 { dst 0.0.0.0/0; src 213.167.241.55/32; } [bgp_wfiltr1_ipv4 15:44:14.440 from 217.70.176.118] * (100) [i] Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.local_pref: 100 BGP.ext_community: (generic, 0x80060000, 0x0) But, if I send this: echo 'announce flow route { match { source 213.167.241.55/32; } then { discard; } }' > /var/run/exabgp.cmd It doesn’t work, the session is in error state (BGP Error: Malformed attribute list) and the log says "Invalid flow route: Destination prefix is missing". However, https://tools.ietf.org/html/rfc5575#section-4 says We define a "Flow Specification" NLRI type that may include several components such as destination prefix, source prefix, protocol, ports, etc. This NLRI is treated as an opaque bit string prefix by BGP. Each bit string identifies a key to a database entry with which a set of attributes can be associated. As it’s “may”, I would say that it’s not mendatory. The sessions toward ASR9K routers accept the annoucement. Regards, -- Alarig

2 2

BIRD mailing list issue - root cause found: BIRD MTA fails to resend after being greylisted
by Christoph 21 Apr '20

21 Apr '20

Hi, the root cause for the mailing list issues have been found. trubka.network.cz gets greylisted by never tries to delivery the emails again. {{ Oct 4 13:17:46 mx2 postgrey[1652]: action=greylist, reason=new, client_name=trubka.network.cz, client_address=2001:1568:b:145::1 Could you look into your MTA configuration to resolve this issue? thanks, Christoph

2 3

Handling AGGREGATOR in v2.0.7
by Nasato Goto 15 Apr '20

15 Apr '20

Hi all, I found a bit strange behavior of handling AGGREGATOR attributes in BIRD v2.0.7 route server. When BIRD receives a route containing AGGREGATOR attribute from 4byte-AS capable peer, it sends the route with strange AGGREGATOR to 4byte-AS incapable peer. On the other hand, BIRD can sends AS4_AGGREGATOR attribute correctly. Here is a scenario what I did. In the following simple topology, Peer1 and BIRD RS are 4byte-AS capable and Peer2 is 2byte-AS support only. Peer1 --(r1)--> BIRD RS --(r1’)--> Peer2 Peer1 advertise a route r1 which contains AGGREGATOR attribute. (omitting ATOMIC_AGGREGATE here) ------ r1: AGGREGATOR: - Aggregator AS: 650001 (in 4byte) - Aggregator Origin: x.x.x.x ------ Then, the expected route r1’ advertised from RS to Peer2 should be like: ------ r1’: AGGREGATOR: - Aggregator AS: 23456 (AS_TRANS, in 2byte) - Aggregator Origin: x.x.x.x AS4_AGGREGATOR: - Aggregator AS: 650001 (in 4byte) - Aggregator Origin: x.x.x.x ------ But as far as I see, BIRD sends the route including AGGREGATOR like: ------ r1’: AGGREGATOR: - Aggregator AS: 0 (in 2byte) #here - Aggregator Origin: y.y.y.y #and here, not match to original origin x.x.x.x AS4_AGGREGATOR: - Aggregator AS: 650001 (in 4byte) - Aggregator Origin: x.x.x.x ------ This may not confirm to the section 4.2.2 in https://tools.ietf.org/html/rfc6793. And also, when the AS number in original AGGREGATOR is a “mappable” 4byte-AS number, I see that the AS number in AGGREGATOR advertised from BIRD is set as 65535 (0xFFFF). Then I tried a small patch, this fixed my problem. But I’m not sure if it’s appropriate. ------------------------------------------ diff --git a/nest/attrs.h b/nest/attrs.h index 6fb0a8fa..e0399708 100644 --- a/nest/attrs.h +++ b/nest/attrs.h @@ -111,7 +111,7 @@ static inline struct adata * aggregator_to_old(struct linpool *pool, const struct adata *a) { struct adata *d = lp_alloc_adata(pool, 8); - put_u32(d->data, 0xFFFF); + put_u32(d->data, AS_TRANS); memcpy(d->data + 4, a->data + 4, 4); return d; } diff --git a/proto/bgp/attrs.c b/proto/bgp/attrs.c index b8921363..f2a4d5b2 100644 --- a/proto/bgp/attrs.c +++ b/proto/bgp/attrs.c @@ -562,6 +562,7 @@ bgp_encode_aggregator(struct bgp_write_state *s, eattr *a, byte *buf, uint size) /* Prepare 16-bit AGGREGATOR (from 32-bit one) in a temporary buffer */ byte *dst = alloca(6); len = aggregator_32to16(dst, data); + data = dst; } return bgp_put_attr(buf, size, BA_AGGREGATOR, a->flags, data, len); ------------------------------------------ If further information is needed I will be happy to provide it. Best regards, ----- Nasato Goto JPNAP / INTERNET MULTIFEED CO. goto(a)mfeed.ad.jp -----

2 4

High CPU usage with 5.x Linux kernel
by Alarig Le Lay 14 Apr '20

14 Apr '20

Hi, I recently upgraded from 4.19.97 to 5.4.28 and I noticed that bird was using a lot more CPU (about three times). On those two graphs you can see the CPU usage and when I rebooted: https://pix.milkywan.fr/gallery#ugO0qVvx.png,ncr9kHfi.png I rebooted to 4.19.113 and now I’m back to the ~10 % average CPU. My router has 5 dual-stack fullviews (2 are from RRs), a dual-stack OSPF and BFD on OSPF and on the RR sessions. I also upgraded my RRs, but I don’t see any change on them, so the usage might be related to FIB/kernel route insertion. I don’t have other BGP implementation on my network, so it might be a kernel bug and not a bird one. But on the other hand, I was clearly seeing the bird process using a whole CPU core with htop. I can share my .conf for each kernel if it’s helpful. Regards, -- Alarig

1 0

[PATCH] babel: Set onlink flag for IPv4 routes with unreachable next hop
by Toke Høiland-Jørgensen 14 Apr '20

14 Apr '20

If the next hop of a route is not a reachable address, the route should be installed as onlink. This enables a configuration common in mesh networks where the mesh interface is assigned a /32 and babel handles the routing by installing onlink routes. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 88c4711e..4fd88042 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -640,6 +640,13 @@ babel_announce_rte(struct babel_proto *p, struct babel_entry *e) .nh.iface = r->neigh->ifa->iface, }; + /* If we cannot find a reachable neighbour, set the entry to be onlink. This + * makes it possible to, e.g., assign /32 addresses on a mesh interface and + * have routing work. + */ + if (!neigh_find2(&p->p, &r->next_hop, r->neigh->ifa->iface, 0)) + a0.nh.flags = RNF_ONLINK; + rta *a = rta_lookup(&a0); rte *rte = rte_get_temp(a); rte->u.babel.seqno = r->seqno; -- 2.17.0

3 4

Filtering on Export-Protocol
by Michael Rack 09 Apr '20

09 Apr '20

Hi Guys, if i am in the EXPORT-Routine, how can i access the "protocol-name" of that instance that is currently using my function? If I rely on "proto" I get the protocol-name where the route comes from. That is not what I want. *protocol bgp *'peer-neo' { > ipv4 { export filter *filter_common_ipv4_out*; }; > } > *filter * filter_common_ipv4_out() { > if proto = 'peer-neo' then .....; > } How can I match for 'peer-neo' ? Thank you. Michael.

3 6

Fwd: Re: Changing Filters and "reload out" will not work // Version 2.0.2
by Vasil Bakalov 08 Apr '20

08 Apr '20

I'm pretty sure you should be using just birdc configure to re-read the config and apply it without dropping connections. On 4/8/20 6:10 PM, Michael Rack wrote: > Hi Guys, > > I run v2.0.2 of BIRD-Daemon. If i change something on the filters i > try to reload my changes with /birdcl reload out > "'edge-at-sbg-v4-2221'//"/ but the changes do not go into effect. > > *All what i see in debug-mode:* > > 2020-04-08 15:05:24.163 <INFO> Reloading protocol edge-at-sbg-v4-2221 > 2020-04-08 15:05:24.163 <DBG> Assertion 'c->channel_state == > CS_UP' failed at nest/proto.c:405 > > > Is there anyone out there that can help, what is going wrong here? > > Thank you. > Michael.

3 3

Changing Filters and "reload out" will not work // Version 2.0.2
by Michael Rack 08 Apr '20

08 Apr '20

Hi Guys, I run v2.0.2 of BIRD-Daemon. If i change something on the filters i try to reload my changes with *birdcl reload out "'edge-at-sbg-v4-2221'**"* but the changes do not go into effect. *All what i see in debug-mode:* 2020-04-08 15:05:24.163 <INFO> Reloading protocol edge-at-sbg-v4-2221 > 2020-04-08 15:05:24.163 <DBG> Assertion 'c->channel_state == CS_UP' > failed at nest/proto.c:405 Is there anyone out there that can help, what is going wrong here? Thank you. Michael.

1 0

Export clause in Pipe protocol
by Fabiano D'Agostino 08 Apr '20

08 Apr '20

Good evening, I have this kind of bird.conf: https://pastebin.com/6pMkJFix I understand that in the Pipe protocol I need the 'import' clause to import in master table routes learn by BGP. But I don't understand why in the Pipe protocol in combination with BGP is useful to have the 'export' clause and why having an 'export' clause in the Pipe protocol based on communities, I mean I will filter routes based on communities on BGP 'import/export' clauses, not in the Pipe protocol. Thanks, Fabiano

1 0

IPv4 route via IPv6 next hop: Netlink: Network unreachable
by Nico Schottelius 07 Apr '20

07 Apr '20

Hello, I'm running 2.0.7 on Linux 5.4.18-0-lts (Alpine) and I receive the route 193.228.143.0/24 from 2a0a:e5c0:1:9::2. However it is never set into the kernel, with the error message "Netlink: Network unreachable" in syslog. Has anyone seen this problem recently? I'm not sure if this is really a bird2 problem or not, to be honest: The kernel reports many messages like this in dmesg: [4541983.369058] netlink: 'bird': attribute type 5 has an invalid length. However, I am also puzzled that manually adding the route seems to fail: [14:44] router1.place6:/var/log# ip route add 193.228.143.0/24 via inet6 2a0a:e5c0:1:9::2 RTNETLINK answers: Invalid argument [14:45] router1.place6:/var/log# ip route add 193.228.143.0/24 nexthop via inet6 2a0a:e5c0:1:9::2 RTNETLINK answers: Invalid argument [14:45] router1.place6:/var/log# ip route add 193.228.143.0/24 nexthop via inet6 2a0a:e5c0:1:9::2 dev bond0.25 RTNETLINK answers: Invalid argument [14:45] router1.place6:/var/log# bird status: bird> show route all protocol bluecmd_v6 Table master4: 193.228.143.0/24 unicast [bluecmd_v6 14:31:15.880] ! (100) [AS206858i] via 2a0a:e5c0:1:9::2 on bond0.25 Type: BGP univ BGP.origin: IGP BGP.as_path: 206858 BGP.next_hop: 2a0a:e5c0:1:9::2 BGP.local_pref: 100 Table master6: 2a10:11c0:114::/48 unicast [bluecmd_v6 14:31:15.880] * (100) [AS206858?] via 2a0a:e5c0:1:9::2 on bond0.25 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 206858 BGP.next_hop: 2a0a:e5c0:1:9::2 fe80::21c:73ff:fe2c:6eca BGP.local_pref: 100 bird> bird2 config: protocol bgp bluecmd_v6 { local as 209898; neighbor 2a0a:e5c0:1:9::2 as 206858; direct; ipv4 { extended next hop; import filter from_inside_customer; export filter only_default_route; }; ipv6 { import filter from_inside_customer; export filter only_default_route; }; default bgp_local_pref pref_normal; } syslog: Apr 1 14:31:15 router1 daemon.warn bird: Netlink: Network unreachable Apr 1 14:31:22 router1 daemon.warn bird: Netlink: Network unreachable Apr 1 14:31:42 router1 daemon.warn bird: Netlink: Network unreachable ... Bird / Kernel / etc.: [14:33] router1.place6:/var/log# bird --version BIRD version 2.0.7 [14:35] router1.place6:/var/log# uname -a Linux router1 5.4.18-0-lts #1-Alpine SMP Thu, 06 Feb 2020 09:27:36 UTC x86_64 GNU/Linux [14:36] router1.place6:/var/log# For reference is also attached the configuration of the opposite side (Arista 7050): router bgp 206858 vrf PUBLIC router-id 193.228.143.0 neighbor 2a0a:e5c0:1:9::5 remote-as 209898 neighbor 2a0a:e5c0:1:9::5 next-hop-self neighbor 2a0a:e5c0:1:9::5 maximum-routes 0 ! address-family ipv4 bgp next-hop address-family ipv6 neighbor 2a0a:e5c0:1:9::5 activate neighbor 2a0a:e5c0:1:9::5 next-hop address-family ipv6 originate network 193.228.143.0/24 ! address-family ipv6 neighbor 2a0a:e5c0:1:9::5 activate network 2a10:11c0:114::/48 linthal-core(vrf:PUBLIC)(config-router-bgp-vrf-PUBLIC)#show ipv6 bgp neighbors 2a0a:e5c0:1:9::5 advertised-routes detail BGP routing table information for VRF PUBLIC Router identifier 193.228.143.0, local AS number 206858 Update wait-install is disabled BGP routing table entry for 2a10:11c0:114::/48 Paths: 1 available 206858 2a0a:e5c0:1:9::2 from - (193.228.143.0) Origin INCOMPLETE, metric -, localpref -, weight -, valid, local, best Rx SAFI: Unicast BGP routing table entry for 193.228.143.0/24 Paths: 1 available 206858 - from - (193.228.143.0) Origin IGP, metric -, localpref -, weight -, valid, local, best Rx SAFI: Unicast Any pointer in the right direction would be appreciated! Cheers, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

5 7