October 2019 - Bird-users

[PATCH] nest/config.Y: fix build without babel, bgp, ospf, radv, rip or static
by Fabrice Fontaine 19 Oct '19

19 Oct '19

Build without babel, bgp, ospf, radv, rip or static fails on: bison -Dparse.lac=full -Dparse.error=verbose -dv -pcf_ -b obj/conf/cf-parse obj/conf/cf-parse.y nest/config.Y:381.20-23: error: symbol LINK is used, but is not defined as a token and has no rules 381 | | dev_proto CHECK LINK bool ';' { DIRECT_CFG->check_link = $4; } | ^~~~ make[1]: *** [obj/conf/cf-parse.tab.c] Error 1 This error is raised because of the following commit: https://gitlab.labs.nic.cz/labs/bird/commit/e90dd656cc9126e1fbcc45fb77a10bf… This commit assumes that LINK is defined which is not always the case. Indeed, it seems that LINK is not defined by BFD, MRT, PERF, PIPE, RPKI To fix this issue, add CF_KEYWORDS(LINK) in nest/config.py Fixes: - http://autobuild.buildroot.org/results/0b00948eed9bb8405b70f3f9112ecce99b36… Signed-off-by: Fabrice Fontaine <fontaine.fabrice(a)gmail.com> --- nest/config.Y | 1 + 1 file changed, 1 insertion(+) diff --git a/nest/config.Y b/nest/config.Y index c62501a3..44f392dd 100644 --- a/nest/config.Y +++ b/nest/config.Y @@ -75,6 +75,7 @@ CF_KEYWORDS(BGP, PASSWORDS, DESCRIPTION, SORTED) CF_KEYWORDS(RELOAD, IN, OUT, MRTDUMP, MESSAGES, RESTRICT, MEMORY, IGP_METRIC, CLASS, DSCP) CF_KEYWORDS(TIMEFORMAT, ISO, SHORT, LONG, ROUTE, PROTOCOL, BASE, LOG, S, MS, US) CF_KEYWORDS(GRACEFUL, RESTART, WAIT, MAX, FLUSH, AS) +CF_KEYWORDS(LINK) /* For r_args_channel */ CF_KEYWORDS(IPV4, IPV4_MC, IPV4_MPLS, IPV6, IPV6_MC, IPV6_MPLS, IPV6_SADR, VPN4, VPN4_MC, VPN4_MPLS, VPN6, VPN6_MC, VPN6_MPLS, ROA4, ROA6, FLOW4, FLOW6, MPLS, PRI, SEC) -- 2.23.0

2 1

BGP graceful restart for software update only?
by Neil Jerram 18 Oct '19

18 Oct '19

In my setup, an instance of BIRD runs all the time, except for when it needs to be restarted for a software update. For that update scenario, I'd like BGP graceful restart to apply, so that the stop-update-restart process does not cause the routes advertised by this BIRD to be withdrawn from the rest of the BGP network. For all other scenarios, however, I don't want any graceful restart. Specifically, if there's a break in connectivity to a BGP peer, I want to detect that as quickly as possible (with BFD), locally to remove the routes learned from that peer, and for that peer to remove routes learned from me, all immediately. Is there some combination of configuration and procedure that can provide both of those desires? Many thanks, Neil

3 4

next-hop-self for non-reflected routes only?
by Neil Jerram 17 Oct '19

17 Oct '19

Hi - I have a topology like this, using BIRD 1.6.7: -------------------+ +---------------------- AS 65001 | | AS 65002 | | +--------+ | | +--------+ iBGP ----| Router |---------------| Router |------- Router B ----| BIRD-A | | eBGP | | BIRD-B |------- Router C +--------+ | | +--------+ . . | | . . | | -------------------+ +---------------------- I want BIRD-B to reflect routes within its own AS, but also propagate routes to and from AS 65001. So for the eBGP peering I have protocol bgp ra1 { description "Connection to BGP peer"; local as 65002; gateway recursive; import all; export all; add paths on; connect delay time 2; connect retry time 5; error wait time 5,30; neighbor 172.31.1.2 as 65001; } and for the iBGP peerings template bgp nodes { description "Connection to BGP peer"; local as 65001; direct; gateway recursive; import all; export all; add paths on; graceful restart; connect delay time 2; connect retry time 5; error wait time 5,30; #next hop self; } protocol bgp node1 from nodes { neighbor 172.31.11.3 as 65001; rr client; } My question is how to get the ideal next-hop-self behaviour, which I think is - Do next-hop-self for routes from AS 65001 that are being passed on to Router B, C etc. Otherwise those routes will be unreachable. - Don't do next-hop-self for reflected routes. Next-hop-self isn't needed here, because the downstream Router B, C etc are already directly connected. Thanks in advance for any advice! Neil

2 4

verify bgp advertise route
by Twana Othman 16 Oct '19

16 Oct '19

Dears, I am new in BIRD route server and I configured a bgp with upstream and I want to verify the prefixes that I am send to my peer. So, anyone can guide me how to do this verification ? -- Regards Twana

2 1

BIRD 2.0.7
by Ondrej Filip 16 Oct '19

16 Oct '19

Dear BIRD users, we just released a new version - 2.0.7. Version 2.0.7 o BGP: Accumulated IGP metric (RFC 7311) o Important filter reconfiguration bugfix o Several other bugfixes Cheers! Ondrej

1 0

Bird 1.6.3 removing IPv6 device routes on Linux (3.10.0)
by Ben Arblaster 12 Oct '19

12 Oct '19

Hi, I’m seeing an issue with bird 1.6.3 where IPv6 device routes are unexpectedly removed from the kernel table on Linux (3.10.0, CentOS 7) when bird removes a matching route learned via another protocol (in this case OSPF). To reproduce, I’ve rigged up a very simple test with two bird6 instances running OSPF in a single area 0 over a ptp tunnel. Configs are here - https://gist.github.com/andatche/ca5b5ac120e09b6b8171ec5ca95d2e25 If I add an address/network (e.g. fd00::1/64) to an interface (dummy0) on host A, the route is flooded by A, learned by B and correctly installed in the kernel table on B: fd00::/64 via fe80::5efe:ae2:b006 dev tun0 proto bird metric 1024 If I then add the same address/network (e.g. fd00::1/64) to an interface (dummy0) on host B, at that instant a device route is installed in the kernel table alongside the existing route on host B and it now looks like this: fd00::/64 dev dummy0 proto kernel metric 256 fd00::/64 via fe80::5efe:ae2:b006 dev tun0 proto bird metric 1024 Shortly after, bird picks up the new address/network on dummy0, recalculates the area and correctly selects the connected route as the new best. It then removes the old route via host A from the kernel table, as expected: kernel1 < removed fd00::/64 via fe80::5efe:ae2:b006 on tun0 However, this causes both the route via host A *and* the device route to be removed from the kernel table, leaving the kernel table on host B with no route to fd00::/64 at all. # ip -6 route show fd00::/64 # This is a change in behaviour from 1.4.5 and seems like a bug, rather than the expected behaviour? Regards, Ben -- Ben Arblaster e: ben(a)andatche.com t: +447943860840 w: https://andatche.com

3 3

Basel?
by Mike Mazarick 11 Oct '19

11 Oct '19

Google has open sourced a build tool called Basel. It is early on and it may not work with bird. It would be great if the invocation of this build system would be "bezel build bird". I don't know if it is possible or practical at this time. Mike Mazarick --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 3

CentOS 8 Repo
by Christian K 08 Oct '19

08 Oct '19

Hi, I was wondering if there are plans to provide packages for CentOS 8 that was released last month. And if so, when? Best, Christian

2 1

OSPF stuck in 2-way state
by Kenth Eriksson 08 Oct '19

08 Oct '19

Hi! We are having a problem were sometimes bird ospf neighbor state machine becomes stuck in a 2-way state. This happens when two broadcast interfaces are connected, one of them is running quagga and the other end is running bird. The quagga router has prio 0 and bird prio 5, i.e. quagga is not eligible to become DR. Why does not bird transition from 2-way to ExStart? I believe the following lines causes me.dr to become 0.0.0.0. Bird adds itself as an eligible router as described in section 10.4, but with the address of zero? me.dr = ospf_is_v2(p) ? ipa_to_u32(ifa->drip) : ifa->drid; me.bdr = ospf_is_v2(p) ? ipa_to_u32(ifa->bdrip) : ifa->bdrid; me.iface_id = ifa->iface_id; add_tail(&ifa->neigh_list, NODE & me); nbdr = elect_bdr(p, ifa->neigh_list); ndr = elect_dr(p, ifa->neigh_list); Due to the above, I believe later in "can_do_adj" the following will not become true; case OSPF_IS_DROTHER: if (((n->rid == ifa->drid) || (n->rid == ifa->bdrid)) && (n->state >= NEIGHBOR_2WAY)) i = 1; The quagga router says that bird is the DR, see tcpdump below and bird logs below; bird> show ospf interface ospfv2_1: Interface eth1 (10.210.138.68/30) Type: broadcast Area: 2.2.2.2 (33686018) State: DROther Priority: 5 Cost: 10 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Designated router (ID): 0.0.0.0 Designated router (IP): 0.0.0.0 Backup designated router (ID): 0.0.0.0 Backup designated router (IP): 0.0.0.0 bird> show ospf neighbors ospfv2_1: Router ID Pri State DTime Interface Router IP 10.210.138.70 0 2-Way/Other 35.744 eth1 10.210.138.7 0 A tcpdump showing the OSPF hellos between the two routers. 10.210.138.69 is running bird and 10.210.138.70 is running quagga. # tcpdump -r ospf_bird.pcap -Z root -v reading from file ospf_bird.pcap, link-type EN10MB (Ethernet) 09:16:31.311431 IP (tos 0xc0, ttl 1, id 44687, offset 0, flags [none], proto OSPF (89), length 52) 10.210.138.70 > 10.210.138.69: OSPFv2, Database Description, length: 32 Router-ID: 10.210.138.70, Area 2.2.2.2, Authentication Type: none (0) Options: [External], DD Flags: [Init, More, Master] 09:16:34.705820 IP (tos 0xc0, ttl 1, id 55304, offset 0, flags [none], proto OSPF (89), length 68) 10.210.138.69 > 224.0.0.5: OSPFv2, Hello, length: 48 Router-ID: 10.210.138.69, Area 2.2.2.2, Authentication Type: none (0) Options: [External] Hello Timer: 10s, Dead Timer 40s, Mask: 255.255.255.252, Priority: 5 Neighbor List: 10.210.138.70 09:16:36.292044 IP (tos 0xc0, ttl 1, id 44688, offset 0, flags [none], proto OSPF (89), length 68) 10.210.138.70 > 224.0.0.5: OSPFv2, Hello, length: 48 Router-ID: 10.210.138.70, Area 2.2.2.2, Authentication Type: none (0) Options: [External] Hello Timer: 10s, Dead Timer 40s, Mask: 255.255.255.252, Priority: 0 Designated Router 10.210.138.69, Backup Designated Router 10.210.138.69 Neighbor List: 10.210.138.69 09:16:36.311317 IP (tos 0xc0, ttl 1, id 44689, offset 0, flags [none], proto OSPF (89), length 52) 10.210.138.70 > 10.210.138.69: OSPFv2, Database Description, length: 32 Router-ID: 10.210.138.70, Area 2.2.2.2, Authentication Type: none (0) Options: [External], DD Flags: [Init, More, Master] #

2 15

BIRD2 munin plugin + BIRD2-RPKI munin plugin
by Christoph 05 Oct '19

05 Oct '19

Hi Alarig, while searching a munin plugin for BIRD 2 I stumbled on your previous thread on this mailing list: https://bird.network.cz/pipermail/bird-users/2018-November/012894.html as you probably know by now the counters are back: > Version 2.0.4 (2019-02-27) [...] > o Preferred route counters are back We use your munin plugin with BIRD2 and made a tiny modification to it to only include BGP: https://github.com/appliedprivacy/bird2-munin/commit/8953db5b238544e31ee037… We also used you plugin as the basis for this quick'n dirty BIRD2 RPKI munin plugin graphing ROA4 and ROA6 entries: https://github.com/appliedprivacy/bird2-rpki-munin We have seen some routes per second graphs here that would also be interesting but we did not look into that yet: https://stats.tbspace.de/munin/AS203478/router.fsn1.as203478.net/index.html… regards, Christoph

2 1