- Bird-users - Mailing Lists

Start BIRD automatically
by Fabiano D'Agostino 02 Jun '20

02 Jun '20

Hi, how can BIRD automatically start after a reboot or a crash? Should I use systemd? I am using BIRD v2 on Ubuntu 20.04. Fabiano

3 5

Multiple Kernel Tables on one BIRD Table
by Matt Corallo 01 Jun '20

01 Jun '20

When trying to sync a BIRD routing table to multiple kernel routing tables (with different export filters, obviously), BIRD refuses with, eg, "Kernel syncer (v6kern) already attached to table master6". Is this something that is fundamental or would be it easy to address this by allowing it if the "kernel table" field has a different value? Thanks, Matt

3 2

Pointers please - OSPFv3 vs Cisco IOS XR
by Elmar K. Bins 01 Jun '20

01 Jun '20

Hi everybody, I am very certain somebody has experienced similar issues and solved them; I did not find any pointers - please throw them at me. If this is new or unsolved, please help me forward, I can get more output, naturally. Thank you for your interest already! Elmar. The setup: - Pair of Cisco ASR9K running IOS XR trunked to a Juniper EX. - FreeBSD 12.1-RELEASE-p3 with bird 2.07, on an access port of that switch. - Straightforward OSPF setup on the XR, simple BIRD setup on the BSD. The issue: - BIRD connects nicely on OSPFv2 (for IPv4), all's good. - BIRD stays "alone" on OSPFv3 (for IPv6), the Cisco box stays in state EXSTART/DROTHER The awkwardness: - OSPF for IPv4 works just fine. XR config is identical. - Quagga ospf3d does the job just fine. The XR config: router ospfv3 <instance> router-id <router-1> default-information originate area 0 interface TenGigE0/1/0/23.4 The BIRD config (snippets): === v4 config === protocol ospf v2 { area 0 { interface "lo0" { stub; }; interface "*" { }; }; ipv4 { import filter ospf_v4_in; export filter ospf_v4_out; }; } === v6 config === protocol ospf v3 { area 0 { interface "lo0" { stub; }; interface "*" { }; }; ipv6 { import filter ospf_v6_in; export filter ospf_v6_out; }; } The BIRD outputs: ospf1 OSPF master4 up 2020-05-27 Running ospf2 OSPF master6 up 2020-05-27 Alone Name Proto Table State Since Info ospf2 OSPF master6 up 2020-05-27 Alone Channel ipv6 State: UP Table: master6 Preference: 150 Input filter: ospf_v6_in Output filter: ospf_v6_out Routes: 0 imported, 0 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 1 0 1 0 0 Import withdraws: 0 0 --- 1 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 The relevant *ahem* BIRD debug log output (yes, I googled) 2020-05-31 13:08:15.080 <RMT> ospf2: Bad DBDES packet from nbr <router-1> on igb0 - I-bit mismatch (7) The Cisco side of things (debug ipv6 ospf <instance> adj) May 31 13:09:16.278 UTC: ospfv3[1021]: ADJ: Send DBD to <server> on TenGigE0/1/0/23.4 seq 0x8ce5d69 opt R/E/V6 flag I/M/MS len 28 mtu 1500 May 31 13:09:16.278 UTC: ospfv3[1021]: ADJ: Retransmitting DBD to <server> on TenGigE0/1/0/23.4 [1] May 31 13:09:16.278 UTC: ospfv3[1021]: ADJ: Recv DBD fr <server> on TenGigE0/1/0/23.4 seq 0x8ce5d69 opt R/E/V6 flag NONE len 108 mtu 1500 state EXSTART May 31 13:09:16.278 UTC: ospfv3[1021]: ADJ: Build DBD summary list for <server> May 31 13:09:16.279 UTC: ospfv3[1021]: ADJ: Built DBD summary list in 0 ms for <server>, 65 entries May 31 13:09:16.279 UTC: ospfv3[1021]: ADJ: new: type 2001 lsid 0x0 adv <server> seq 0x800000af age 612 May 31 13:09:16.279 UTC: ospfv3[1021]: ADJ: new: type 2009 lsid 0x0 adv <server> seq 0x800000af age 612 May 31 13:09:16.279 UTC: ospfv3[1021]: ADJ: new: type 0008 lsid 0x1 adv <server> seq 0x800000af age 612 May 31 13:09:16.279 UTC: ospfv3[1021]: ADJ: Send DBD to <server> on TenGigE0/1/0/23.4 seq 0x8ce5d6a opt R/E/V6 flag M/MS len 1228 mtu 1500 May 31 13:09:16.279 UTC: ospfv3[1021]: ADJ: Build REQ packet for <server> May 31 13:09:16.279 UTC: ospfv3[1021]: ADJ: type 2001 lsid 0x0 adv <server> May 31 13:09:16.279 UTC: ospfv3[1021]: ADJ: type 2009 lsid 0x0 adv <server> May 31 13:09:16.279 UTC: ospfv3[1021]: ADJ: type 0008 lsid 0x1 adv <server> May 31 13:09:16.279 UTC: ospfv3[1021]: ADJ: Send REQ packet to <server>, length 36 May 31 13:09:16.280 UTC: ospfv3[1021]: ADJ: Recv DBD fr <server> on TenGigE0/1/0/23.4 seq 0x8ce5d6a opt R/E/V6 flag NONE len 28 mtu 1500 state EXCHANGE May 31 13:09:16.280 UTC: ospfv3[1021]: ADJ: Send DBD to <server> on TenGigE0/1/0/23.4 seq 0x8ce5d6b opt R/E/V6 flag I/M/MS len 28 mtu 1500 May 31 13:09:16.281 UTC: ospfv3[1021]: ADJ: Recv DBD fr <server> on TenGigE0/1/0/23.4 seq 0x8ce5d6b opt R/E/V6 flag I/M/MS len 28 mtu 1500 state EXSTART

2 1

OSPF: incorrect path computation for v2.0.5+?
by Kenth Eriksson 27 May '20

27 May '20

Upgraded from 2.0.4 to 2.0.7 and observed strange OSPF path computation. Re-tested against v2.0.5, same result. Any known issues in this area? Setup when observing issue; 5 nodes connected in a ring with PPP links (some redundant links). /----------------------------------------------------------------\ ,------------. ,------------. ,------------. ,------------. ,------------. |10.210.139.1| |10.210.139.2| |10.210.139.3| |10.210.139.4| |10.210.139.5| | |---| |---| |---| |---| | | |---| |---| | | | | | `------------' `------------' `------------' `------------' `------------' With 2.0.4 node 10.210.139.1 finds shortest path to 10.210.139.5 via directly connected interface. With 2.0.5+ the OSPF computation results via hop-by-hop thru 10.210.139.2. Result with 2.0.4 ----------------- node_1 ~ # birdc BIRD v2.0.4-16-g1528cec5 ready. bird> show ospf interface ospfv2_1 ospfv2_1: Interface p1-1-3-1-4 (peer 10.210.139.5) Type: ptp Area: 0.0.0.0 (0) State: PtP Priority: 0 Cost: 10 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Interface p1-1-1-1-2 (peer 10.210.139.2) Type: ptp Area: 0.0.0.0 (0) State: PtP Priority: 0 Cost: 10 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Interface p1-1-5-1-6 (peer 10.210.139.2) Type: ptp Area: 0.0.0.0 (0) State: PtP Priority: 0 Cost: 10 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 bird> show ospf topology ospfv2_1 area 0.0.0.0 router 0.0.139.1 distance 0 router 0.0.139.5 metric 10 router 0.0.139.2 metric 10 router 0.0.139.2 metric 10 router 0.0.139.2 distance 10 router 0.0.139.3 metric 10 router 0.0.139.3 metric 10 router 0.0.139.1 metric 10 router 0.0.139.1 metric 10 router 0.0.139.3 distance 20 router 0.0.139.4 metric 10 router 0.0.139.2 metric 10 router 0.0.139.2 metric 10 router 0.0.139.4 distance 20 router 0.0.139.3 metric 10 router 0.0.139.5 metric 10 router 0.0.139.5 distance 10 router 0.0.139.4 metric 10 router 0.0.139.1 metric 10 bird> show route table master4 Table master4: 0.0.0.0/0 unicast [static1 14:11:45.720] * (254) via 10.210.129.1 on eth1 10.210.139.2/32 unicast [direct1 14:15:57.283] * (255) dev p1-1-1-1-2 unicast [ospfv2_1 14:16:12.888] E1 (145/10) [0.0.139.2] via 10.210.139.2 on p1-1-1-1-2 unicast [direct1 14:16:01.143] (255) dev p1-1-5-1-6 10.210.139.5/32 unicast [direct1 14:18:20.315] * (255) dev p1-1-3-1-4 unicast [ospfv2_1 14:18:34.888] E1 (145/10) [0.0.139.5] via 10.210.139.5 on p1-1-3-1-4 10.210.139.1/32 unicast [direct1 14:11:37.896] * (255) dev lo 10.210.139.4/32 unicast [ospfv2_1 14:18:34.888] * E1 (145/20) [0.0.139.4] via 10.210.139.5 on p1-1-3-1-4 10.210.129.0/24 unicast [direct1 14:11:45.720] * (255) dev eth1 10.210.139.3/32 unicast [ospfv2_1 14:17:58.888] * E1 (145/20) [0.0.139.3] via 10.210.139.2 on p1-1-1-1-2 10.0.0.0/20 unicast [direct1 14:11:21.625] * (255) dev eth0 bird> show route Table master4: 0.0.0.0/0 unicast [static1 14:23:07.805] * (254) via 10.210.129.1 on eth1 10.210.139.2/32 unicast [direct1 14:23:07.763] * (255) dev p1-1-1-1-2 unicast [ospfv2_1 14:23:22.813] E1 (145/10) [0.0.139.2] via 10.210.139.2 on p1-1-1-1-2 10.210.139.5/32 unicast [direct1 14:23:08.613] * (255) dev p1-1-3-1-4 unicast [ospfv2_1 14:23:22.813] E1 (145/40) [0.0.139.5] via 10.210.139.2 on p1-1-1-1-2 10.210.139.1/32 unicast [direct1 14:23:02.820] * (255) dev lo 10.210.139.4/32 unicast [ospfv2_1 14:23:22.813] * E1 (145/30) [0.0.139.4] via 10.210.139.2 on p1-1-1-1-2 10.210.129.0/24 unicast [direct1 14:23:07.805] * (255) dev eth1 10.210.139.3/32 unicast [ospfv2_1 14:23:22.813] * E1 (145/20) [0.0.139.3] via 10.210.139.2 on p1-1-1-1-2 10.0.0.0/20 unicast [direct1 14:22:38.675] * (255) dev eth0 Result with 2.0.5 and 2.0.7 --------------------------- node_1 ~ # birdc BIRD v2.0.5-1-gd383d5ba ready. bird> show ospf interface ospfv2_1 ospfv2_1: Interface p1-1-1-1-2 (peer 10.210.139.2) Type: ptp Area: 0.0.0.0 (0) State: PtP Priority: 0 Cost: 10 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Interface p1-1-5-1-6 (peer 10.210.139.2) Type: ptp Area: 0.0.0.0 (0) State: PtP Priority: 0 Cost: 10 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Interface p1-1-3-1-4 (peer 10.210.139.5) Type: ptp Area: 0.0.0.0 (0) State: PtP Priority: 0 Cost: 10 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 bird> bird> show ospf topology ospfv2_1 area 0.0.0.0 router 0.0.139.1 distance 0 router 0.0.139.2 metric 10 router 0.0.139.2 metric 10 router 0.0.139.5 metric 10 router 0.0.139.2 distance 10 router 0.0.139.3 metric 10 router 0.0.139.3 metric 10 router 0.0.139.1 metric 10 router 0.0.139.1 metric 10 router 0.0.139.3 distance 20 router 0.0.139.4 metric 10 router 0.0.139.2 metric 10 router 0.0.139.2 metric 10 router 0.0.139.4 distance 30 router 0.0.139.3 metric 10 router 0.0.139.5 metric 10 router 0.0.139.5 distance 40 router 0.0.139.4 metric 10 router 0.0.139.1 metric 10 bird> bird> show route table master4 Table master4: 0.0.0.0/0 unicast [static1 14:41:12.689] * (254) via 10.210.129.1 on eth1 10.210.139.2/32 unicast [direct1 14:41:06.967] * (255) dev p1-1-1-1-2 unicast [ospfv2_1 14:41:22.924] E1 (145/10) [0.0.139.2] via 10.210.139.2 on p1-1-1-1-2 unicast [direct1 14:41:08.739] (255) dev p1-1-5-1-6 10.210.139.5/32 unicast [direct1 14:41:41.577] * (255) dev p1-1-3-1-4 unicast [ospfv2_1 14:41:22.924] E1 (145/40) [0.0.139.5] via 10.210.139.2 on p1-1-1-1-2 10.210.139.1/32 unicast [direct1 14:41:04.950] * (255) dev lo 10.210.139.4/32 unicast [ospfv2_1 14:41:22.924] E1 (145/30) [0.0.139.4] via 10.210.139.2 on p1-1-1-1-2 10.210.129.0/24 unicast [direct1 14:41:12.689] * (255) dev eth1 10.210.139.3/32 unicast [ospfv2_1 14:41:22.924] E1 (145/20) [0.0.139.3] via 10.210.139.2 on p1-1-1-1-2 10.0.0.0/20 unicast [direct1 14:40:48.586] * (255) dev eth0 bird> bird> show ospf neighbors ospfv2_1 ospfv2_1: Router ID Pri State DTime Interface Router IP 0.0.139.2 0 Full/PtP 38.373 p1-1-1-1-2 10.210.139.2 0.0.139.2 0 Full/PtP 30.144 p1-1-5-1-6 10.210.139.2 0.0.139.5 0 Full/PtP 32.983 p1-1-3-1-4 10.210.139.5 bird>

3 24

Protection from link flap in OSPF/BFD
by Baptiste Jonglez 27 May '20

27 May '20

Hi, We are running an OSPF/BFD setup with Bird, with several links that look like this: Bird/Debian -- switch -- fiber -- switch -- Bird/Debian We had a situation where a fiber link was flapping hard between two switches because of a hardware issue. In turn, the BFD sessions were flapping, which is expected. My question: is there any way to limit the amount of flapping in either OSPF or BFD? I was specifically looking for a "prefer older" option in OSPF but it only exists in BGP. Alternatively, BFD could disable a session for some time if it flaps too much. In our setup, routers often have several paths with the same OSPF cost to/from the BGP gateway. We don't use ECMP: only one path is used at a time, other paths are used as backup (in case of fiber cut or hardware issue). So, in our case, a "prefer older" option for OSPF would make a lot of sense and would naturally avoid using flapping links. Is it something that could be implemented? Thanks, Baptiste PS: we are using Bird 1.6.3 which is quite old

1 0

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

26 May '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. This patch has been carried in the OpenWrt package for Bird since the v1 submission two years ago. The behaviour introduced here is essential for common deployments of Babel and matches the behaviour of babeld. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- v2: - Rebase to current master (using neigh_find() instead of neigh_find2()) proto/babel/babel.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index ebd5f7cc4..b75392d97 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_find(&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.26.2

2 1

[BGP] bird and RFD
by Mattia Milani 26 May '20

26 May '20

Hello all, I was wondering if bird implements the RFD procedure, route flap damping. I was looking online on the user guide 2.0 but i didn't find any reference to it. I know it is a controversial point, it was presented in the RFC 2439 and then RIPE-378 recommends disabling it thanks to a paper presented in 2002 (Route Flap Damping Exacerbates Internet RoutingConvergence). In 2015 IETF publishes BCP 194 with RFD recommendations. I think could be an interesting parameter for some experiments, so is in the future plans of bird to implement it? What do you think about it? Thanks, Mattia

2 1

IPv6 RPKI for 2.0.7
by Irene Lalioti 22 May '20

22 May '20

Hello! I am running BIRD v2.0.7 and the other day I migrated the management network to only IPv6 addresses, so I had to change the RPKI address to the new ipv6 one. Result was that was not working. Is it known that for the ipv6 the RPKI channeling is not compatible, you guys? Thanks a lot in advance! Cheers! Irene -- Irene Lalioti Network Engineer Fondation RESTENA 2, avenue de l'Université L-4365 Esch/Alzette Tel: +352 424409 1 Fax: +352 422473

2 1

BGP password
by Fabiano D'Agostino 21 May '20

21 May '20

Hi everyone, when I try to set up a password for a BGP peering the connection state is Connect and not Established, so BGP is not importing prefixes. The neighbor which is doing a peering is a Cisco router and I set up the password with neighbor ip-address password string command. Thanks, Fabiano

2 4

BFD bind port to IP
by Justin Cattle 13 May '20

13 May '20

Hi, Is it possible to bind BFD listen ports to a particular IP ? I've tried a few different BFD procol configs, tried specify different neighbor options, but I always see this: udp UNCONN 0 0 0.0.0.0:3784 0.0.0.0:* users:(("bird",pid=7219,fd=12)) udp UNCONN 0 0 0.0.0.0:4784 0.0.0.0:* users:(("bird",pid=7219,fd=13)) I would like to bind it to the IP for each p2p interface, so it's not reachable on any other IPs. Is what I'm trying to acheive even possible ? Thanks! Cheers, Just -- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.

3 4