- Bird-users - Mailing Lists

[RFC PATCH 01/20] add NET_ANY
by Asbjørn Sloth Tønnesen 30 Dec '19

30 Dec '19

--- lib/net.c | 1 + lib/net.h | 1 + 2 files changed, 2 insertions(+) diff --git a/lib/net.c b/lib/net.c index 976ddbcc..2440506e 100644 --- a/lib/net.c +++ b/lib/net.c @@ -6,6 +6,7 @@ const char * const net_label[] = { + [NET_ANY] = "any", [NET_IP4] = "ipv4", [NET_IP6] = "ipv6", [NET_VPN4] = "vpn4", diff --git a/lib/net.h b/lib/net.h index 0cd5f735..fe55d1b5 100644 --- a/lib/net.h +++ b/lib/net.h @@ -13,6 +13,7 @@ #include "lib/ip.h" +#define NET_ANY 0 #define NET_IP4 1 #define NET_IP6 2 #define NET_VPN4 3 -- 2.24.0

1 0

[PATCH] use net_*_match consistently
by Asbjørn Sloth Tønnesen 30 Dec '19

30 Dec '19

--- lib/net.h | 9 +++++---- nest/rt-table.c | 2 +- proto/mrt/mrt.c | 3 +-- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/lib/net.h b/lib/net.h index 0cd5f735..102cbfb0 100644 --- a/lib/net.h +++ b/lib/net.h @@ -38,6 +38,7 @@ #define NB_IP (NB_IP4 | NB_IP6) #define NB_VPN (NB_VPN4 | NB_VPN6) +#define NB_ROA (NB_ROA4 | NB_ROA6) #define NB_FLOW (NB_FLOW4 | NB_FLOW6) #define NB_DEST (NB_IP | NB_IP6_SADR | NB_VPN | NB_MPLS) #define NB_ANY 0xffffffff @@ -257,16 +258,16 @@ static inline int net_type_match(const net_addr *a, u32 mask) { return net_val_match(a->type, mask); } static inline int net_is_ip(const net_addr *a) -{ return (a->type == NET_IP4) || (a->type == NET_IP6); } +{ return net_type_match(a, NB_IP); } static inline int net_is_vpn(const net_addr *a) -{ return (a->type == NET_VPN4) || (a->type == NET_VPN6); } +{ return net_type_match(a, NB_VPN); } static inline int net_is_roa(const net_addr *a) -{ return (a->type == NET_ROA4) || (a->type == NET_ROA6); } +{ return net_type_match(a, NB_ROA); } static inline int net_is_flow(const net_addr *a) -{ return (a->type == NET_FLOW4) || (a->type == NET_FLOW6); } +{ return net_type_match(a, NB_FLOW); } static inline int net_is_sadr(const net_addr *a) { return (a->type == NET_IP6_SADR); } diff --git a/nest/rt-table.c b/nest/rt-table.c index 4adc278e..d2800584 100644 --- a/nest/rt-table.c +++ b/nest/rt-table.c @@ -2186,7 +2186,7 @@ rt_new_table(struct symbol *s, uint addr_type) /* Hack that allows to 'redefine' the master table */ if ((s->class == SYM_TABLE) && (s->table == new_config->def_tables[addr_type]) && - ((addr_type == NET_IP4) || (addr_type == NET_IP6))) + net_val_match(addr_type, NB_IP)) return s->table; struct rtable_config *c = cfg_allocz(sizeof(struct rtable_config)); diff --git a/proto/mrt/mrt.c b/proto/mrt/mrt.c index 7a396a84..258f8470 100644 --- a/proto/mrt/mrt.c +++ b/proto/mrt/mrt.c @@ -227,8 +227,7 @@ mrt_next_table_(rtable *tab, rtable *tab_ptr, const char *pattern) for (tab = !tab ? HEAD(routing_tables) : NODE_NEXT(tab); NODE_VALID(tab); tab = NODE_NEXT(tab)) - if (patmatch(pattern, tab->name) && - ((tab->addr_type == NET_IP4) || (tab->addr_type == NET_IP6))) + if (patmatch(pattern, tab->name) && net_val_match(tab->addr_type, NB_IP)) return tab; return NULL; -- 2.24.0

1 0

Redistribution of BGP path via OSPF
by Nico Schottelius 29 Dec '19

29 Dec '19

Good morning, we have setup OSPF internally to redistribute all of our routes and it seems that we lose the as path on the way: BGP OSPF BGP upstream1 -- router1.place6 --- router2.place5 --- upstream2 | | BGP internal peer The routes that are announced by router2.place5 do not contain the AS path of the "internal peer" anymore, as shows the output of router2.place5: bird> show route all XX::/48 Table master6: XX::/48 unicast [ospf_v6 12:01:06.457] E2 (150/5/10000) [147.78.195.251] via fe80::21b:21ff:febc:7c80 on bond0.8 Type: OSPF-E2 univ OSPF.metric1: 5 OSPF.metric2: 10000 OSPF.tag: 0x00000000 OSPF.router_id: 147.78.195.251 This way, when we re-announce XX::/48 to upstream2, it looks like as if we announce that from our ASN, instead of the ASN from the internal peer. At the moment we export all routes via OSPF, internal and external. How do I tell ospf to forward (tag?) the externally received bgp routes and use that information on the other site? Best regards, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

2 2

Socket error: TCP_MD5SIG: Cannot allocate memory
by 穴澤正恒 26 Dec '19

26 Dec '19

Dear all, My name is Masatsune Anazawa, an affiliate of JPIX. We are verifying the root server that is being considered for installation on JPIX. When MD5 authentication is performed on bird and 1000 peers are set, the following error occurs and only 150 to 300 peers can be established. Please let me know if there is a solution. I’m looking forward to your reply. /var/log/messages ------------------------------------------------------------------------------------------- Dec 18 16:23:28 rs-bird bird: AS2855_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2854_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2853_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2852_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2851_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2850_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2849_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2848_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2847_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2846_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2845_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2844_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2843_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2842_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2841_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2840_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2839_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory Dec 18 16:23:28 rs-bird bird: AS2838_IPv6: Socket error: TCP_MD5SIG: Cannot allocate memory ------------------------------------------------------------------------------------------- -- ----------------------------------------- 株式会社 Hoster-JP (HJP) Masatsune Anazawa (穴澤　正恒) http://www.hoster.jp Mail: ma-anazawa(a)hoster.jp TEL: 03-5977-0888 FAX：03-5977-0887 113-0021 東京都文京区本駒込6-5-3 ビューネ本駒込3F -----------------------------------------

2 2

Bgp: gr_time in configure file can change gr_flag
by cjt 24 Dec '19

24 Dec '19

Hello I find that the graceful restart time number configuration can accept 32bits. bgp_proto GRACEFUL RESTART TIME expr ';' { BGP_CFG->gr_time = $5; } While in the RFC 4724 section 3 it says the graceful restart time is 12bits and restart flags is 4bits. +--------------------------------------------------+ | Restart Flags (4 bits) | +--------------------------------------------------+ | Restart Time in seconds (12 bits) | +--------------------------------------------------+ | Address Family Identifier (16 bits) | +--------------------------------------------------+ | Subsequent Address Family Identifier (8 bits) | +--------------------------------------------------+ | Flags for Address Family (8 bits) | +--------------------------------------------------+ so ,when I set the graceful restart time like 32768.，it will cover the gr_flag. Becasue ,in the bgp_write_capabilites() function ，it first put the gr_time in. Then use "|" to put gr_flags. This will casue the value in gr_time first four bits keep in the gr_flags。 put_u16(buf, caps->gr_time); buf[0] |= caps->gr_flags; Also ，I have find in RFC 4724，it required gr_flag expect the first bit ,the remaining bits are reserved and MUST be set to zero by the sender and ignored by the receiver. gr_time in the configure also can change the remaining bits. Meanwhile, in the bgp_read_capabilites() function, it use "& 0xf0" will remain the wrong 4 bits. caps->gr_flags = pos[2] & 0xf0; caps->gr_time = get_u16(pos + 2) & 0x0fff; I try this on the bird 2.0.7 Thanks Jingting Chen

1 0

Long io loop / missing netlink messages
by Nico Schottelius 22 Dec '19

22 Dec '19

Good morning, on a fresh new router running the full routing table, with Alpine, Linux 4.19.80-0-vanilla, bird-2.0.7 I see a lot of these messages: Dec 21 12:37:15 router1 daemon.warn bird: Kernel dropped some netlink messages, will resync on next scan. Dec 21 12:37:34 router1 daemon.warn bird: I/O loop cycle took 5000 ms for 1 events Dec 21 12:38:14 router1 daemon.warn bird: Kernel dropped some netlink messages, will resync on next scan. Dec 21 12:38:35 router1 daemon.warn bird: I/O loop cycle took 5328 ms for 1 events Dec 21 12:38:54 router1 daemon.warn bird: I/O loop cycle took 5013 ms for 1 events Dec 21 12:39:07 router1 daemon.warn bird: Kernel dropped some netlink messages, will resync on next scan. Dec 21 12:39:14 router1 daemon.warn bird: I/O loop cycle took 5053 ms for 1 events Dec 21 12:39:34 router1 daemon.warn bird: Kernel dropped some netlink messages, will resync on next scan. Dec 21 12:40:14 router1 daemon.warn bird: I/O loop cycle took 5041 ms for 1 events [12:49] router1.place6:~# ip -6 r | wc -l; ip r | wc -l 78212 779342 With "debug latency;" I get the following additional messages: Dec 21 12:54:31 router1 daemon.warn bird: Event 0x000055a21afb8144 0x0000000000000000 took 4449 ms Dec 21 12:54:52 router1 daemon.warn bird: Event 0x000055a21afb8144 0x0000000000000000 took 5608 ms The system is overall idle with bird spiking to 50-100% cpu usage every couple of seconds. I first thougt they are only logged after stating bird (where it might make sense), but the events continue to be logged around every 30s: Dec 21 13:04:11 router1 daemon.warn bird: Event 0x000055a21afb8144 0x0000000000000000 took 4596 ms Dec 21 13:04:32 router1 daemon.warn bird: Event 0x000055a21afb8144 0x0000000000000000 took 5096 ms Dec 21 13:04:52 router1 daemon.warn bird: Event 0x000055a21afb8144 0x0000000000000000 took 5102 ms Dec 21 13:05:11 router1 daemon.warn bird: Event 0x000055a21afb8144 0x0000000000000000 took 4676 ms Dec 21 13:05:31 router1 daemon.warn bird: Event 0x000055a21afb8144 0x0000000000000000 took 4645 ms Which might loosely correlate to the scan time "20" that is setup for device and kernel protocols. How do I best debug this issue? Best, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

2 2

bird2 package for debian broken
by Christoph 19 Dec '19

19 Dec '19

Hello, the bird2 package from bird.network.cz for debian buster appears to be broken: > apt install bird2 > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following NEW packages will be installed: > bird2 > 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. > Need to get 0 B/640 kB of archives. > After this operation, 1,327 kB of additional disk space will be used. > Selecting previously unselected package bird2. > (Reading database ... 35407 files and directories currently installed.) > Preparing to unpack .../bird2_2.0.6-1+0~20190916.13+debian10~1.gbp14a7a6_amd64.deb ... > Unpacking bird2 (2.0.6-1+0~20190916.13+debian10~1.gbp14a7a6) ... > Setting up bird2 (2.0.6-1+0~20190916.13+debian10~1.gbp14a7a6) ... > Error: The new file /usr/share/doc/bird2/examples/bird.conf does not exist! > dpkg: error processing package bird2 (--configure): > installed bird2 package post-installation script subprocess returned error exit status 1 > Processing triggers for man-db (2.8.5-2) ... > Processing triggers for systemd (241-7~deb10u1) ... > Errors were encountered while processing: > bird2 > E: Sub-process /usr/bin/dpkg returned an error code (1)

3 4

Route preference for one address
by kc atgb 17 Dec '19

17 Dec '19

Hello, I started using bird some days ago from zero knowledge. With the different docs I found all around I understand a little bit more how that works. My configuration is made of 2 sites connected by 2 seperated links. Each link have a dedicated vpn connection for internal routing. One nominal link and one backup. In case of failure, the switch from one link to the other is working. What I want to do now, is to force the routing for one specific address (/32) via the backup link whereas the rest of the /24 is using the first one. And in case of failure of the backup link, the /32 should use the first one. I tried different things and from what I have found, my configuration is working partially. I mean there is no fallback to the first link if the second is in failed state. I tried with static routing and export filter. With static: protocol static s_special { import all; route 192.168.1.78/32 via 10.194.11.2 { preference = 250; }; } The route stays active when the link is down so the traffic can not go back to source. With filter: filter export2kernel { if net = 192.168.1.78/32 then ifname = "tun1"; accept; } The same thing happens. I took a look also to preference/cost/... but I am unable to achieve what I am looking to do. So my question, what should I look for to have this working like explained ? What information should I provide if it is not clear ? Thanks in advance, Kay

2 5

Best practices for redundant iBGP/eBGP route distribution? [bird 2.0.7]
by Nico Schottelius 16 Dec '19

16 Dec '19

Good morning, I was wondering, what is the best practice is for running 2 data centers, each with one uplink and a dark fiber in between them? I think it's pretty much a standard situation, but will show our setup and assumptions as well: upstream 1 upstream 2 | | dc1--darkfiber----dc 2 Additional each DC has 2 routers: dc1: dc2: |---router1 ------- router 1 | / | / | /--------/ | router2---------router2 | | |---------------------| (both routers are connected to each other and both routers are connected to each upstream) The objective is to stay online in each DC as long as possible, so in theory: - upstream 1 can die or - upstream 2 can die or - the darkfiber can die And in each of the situations, both DCs should still be reachable from outside and both be reaching itself. Question 1: Is "direct;" is the right protocol for all links? As all links are layer 2 connections, we have configured all links to be direct. However this causes the "Invalid NEXT_HOP attribute" in various situations. Question 2: Is "next hop self ebgp;" the correct answer to the Invalid NEXT_HOP attribute? This way we rewrote routes from upstreams and generally speaking it seems to work. However, this still fails iBGP routes: router1.dc1 cannot reach a network in dc2 that is configured to be statically routed to another host in dc2. My assumption is that this is the problem of the "gateway direct" resolution, even though the documentation kind of indicates that this should be resolved via the next hop of the dc2. Originally I'd have thought that not even "next hop self ebgp" is required, as the next hop attribute is coming from the peering router, so the route should be directly reachable. Question 3: Is "not direct" (aka multiphop) the right thing for iBGP? So our dcs are directly connected vi layer 2, but the default for iBGP is multihop. If we omit the "direct" keyword, the result is that no routes are in the end imported from the other DC and that we get various warnings like the following in syslog: Dec 16 00:58:35 router2 daemon.warn bird: Next hop address 2a0a:e5c0:1:8::5 resolvable through recursive route for 2a0a:e5c0:1:8::/64 So at this stage it's a bit unclear to me, how proper iBGP redistribution / next hop resolution should work with bird. Question 4: How to (not) announce umbrella networks? So both data centers are reachable within the 2a0a:e5c0::/29 prefix and all routers have a statement route 2a0a:e5c0::/29 unreachable; in the static protocol. However if the dark fiber goes down, it is not clear that / how the upstreams should / will propagate the smaller (per DC) /48s. If we remove the full /29 announcement, we might run into the problem that a packet is being sent out through one upstream and returns back to us and thus creates a routing loop. While the last question is eBGP specific, the main question of this thread still is: how do you correctly distribute internal and external routes via iBGP in your DCs? Thanks for any hints in the right direction. Best regards, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

2 10

Prefix not making it through two iBGP sessions
by Brooks Swinnerton 14 Dec '19

14 Dec '19

Hello, I'm having trouble understanding why certain routes aren't making it through to an iBGP session on BIRD 2.0.7. My network layout looks something like below. I have three BIRD instances running, *Router 1* is connected to *Upstream 1*, *Router 2* is connected to *Upstream 2*, and *Router 1* and *Router 2* are connected to each other via iBGP. This all works great. Upstream 1 Upstream 2 ▲ ▲ | | eBGP eBGP | | Router 1 ◀--iBGP--▶ Router 2 | iBGP | ▼ Router 3 The problem comes with *Router 3* not receiving routes from *Router 2*. The iBGP export filter on router1 looks like this: export filter { if is_v4_bogon() then reject; if is_v4_default() then reject; if is_v4_peering_net() then reject; if is_v4_own_net() then accept; if source = RTS_BGP then accept; reject; }; And if I test each of these functions out manually I can see the prefix should be allowed through: bird> show route filter { if is_v4_bogon() then reject; } 174.202.0.0/16 bird> show route filter { if is_v4_default() then reject; } 174.202.0.0/16 bird> show route filter { if is_v4_peering_net() then reject; } 174.202.0.0/16 bird> show route filter { if is_v4_own_net() then accept; } 174.202.0.0/16 bird> show route filter { if source = RTS_BGP then accept; } 174.202.0.0/16 Table master4: 174.202.0.0/16 unicast [cologuard4 21:17:56.850 from 169.254.3.3] * (100) [AS22394?] dev bdr-cologuard Unfortunately if I look at the session from *Router 1* to *Router 3* (core_nyiix_14), it is not let through: bird> show route export core_nyiix_14 174.202.0.0/16 bird> I've added all of the relevant configuration in this Gist <https://gist.github.com/bswinnerton/6b7527bc9d78215275c1ae75e64d34cd>. Any help would be much appreciated.

1 1