- Bird-users - Mailing Lists

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

misunderstanding or incorrectly implemented filter?
by Christoph 05 Oct '19

05 Oct '19

Hello, (please keep me in CC) we use filters from https://bgpfilterguide.nlnog.net/ One of the first functions checks for bogon ASNs way before the RPKI ROA check: > filter transit_in { > > reject_bogon_asns(); [...] > if (net.type = NET_IP4) then { > if (roa_check(r4, net, bgp_path.last) = ROA_INVALID) then > { > print "Reject RPKI INVALID announcement ", net, " by AS", bgp_path.last; > reject; > } > } [...] My assumption was that an announcement from AS0 would never end up at the RPKI ROA check since it is already tested and rejected earlier at the reject_bogon_asns() function but then I found log entries suggesting otherwise: > Reject RPKI INVALID announcement 200.124.231.0/24 by AS0 So I was wondering: - Did I incorrectly assume first match wins? - Is the reject_bogon_asns() function not working as intended? > define BOGON_ASNS = [ 0, # RFC 7607 > 23456, # RFC 4893 AS_TRANS > 64496..64511, # RFC 5398 and documentation/example ASNs > 64512..65534, # RFC 6996 Private ASNs > 65535, # RFC 7300 Last 16 bit ASN > 65536..65551, # RFC 5398 and documentation/example ASNs > 65552..131071, # RFC IANA reserved ASNs > 4200000000..4294967294, # RFC 6996 Private ASNs > 4294967295 # RFC 7300 Last 32 bit ASN > ]; > function reject_bogon_asns() > int set bogon_asns; > { > bogon_asns = BOGON_ASNS; > if ( bgp_path ~ bogon_asns ) then { > print "Reject: bogon AS_PATH: ", net, " ", bgp_path; > reject; > } > } thanks, Christoph

2 4

IP version independent RPKI filter
by Christoph 04 Oct '19

04 Oct '19

Hello, the RPKI documentation section has a RPKI ROV example using an IPv4 specific filter: https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.13 > roa4 table r4; > roa6 table r6; > > protocol rpki { > debug all; > > roa4 { table r4; }; > roa6 { table r6; }; > > # Please, do not use rpki-validator.realmv6.org in production > remote "rpki-validator.realmv6.org" port 8282; > > retry keep 5; > refresh keep 30; > expire 600; > } > > filter peer_in_v4 { > if (roa_check(r4, net, bgp_path.last) = ROA_INVALID) then > { > print "Ignore invalid ROA ", net, " for ASN ", bgp_path.last; > reject; > } > accept; > } > > protocol bgp { > debug all; > local as 65000; > neighbor 192.168.2.1 as 65001; > ipv4 { > import filter peer_in_v4; > export none; > }; > } We use a transit_in filter that checks the net.type to decide which roa_check parameter to use: > filter transit_in { > > reject_bogon_asns(); > reject_small_prefixes(); > reject_bogon_prefixes(); > reject_long_aspaths(); > reject_default_route(); > enforce_neighbor_asn(); > reject_our_networks(); > > if (net.type = NET_IP4) then { > if (roa_check(r4, net, bgp_path.last) = ROA_INVALID) then > { > print "Reject RPKI INVALID announcement ", net, " by AS", bgp_path.last; > reject; > } > } else { > if (roa_check(r6, net, bgp_path.last) = ROA_INVALID) then > { > print "Reject RPKI INVALID announcement ", net, " by AS", bgp_path.last; > reject; > } > } > > accept; > > } Is this significantly less efficient than having separate IPv4/6 filters that do not need that additional if (net.type = .. ) check? Or does it not really matter? If possible I'd prefer a single filter that can be applied to IPv4 and IPv6 BGP sessions. thanks, Christoph

2 1