- Bird-users - Mailing Lists

bird incorrectly merging next hops
by Bernardo Figueiredo 15 Dec '16

15 Dec '16

Hi, At our network we use bird in all our Linux routers so they talk OSPF. Recently we added a new router appliance(not Linux) to the backbone and most of the bird routers showed wrong next hops for some routes. At first we tought that the problem might be caused by a bug in the appliance making it send bad LSAs, but debugging the ospf packets and looking at other non-bird router appliances made us certain that the fault was in bird. After looking through the code we found that the bug is in function 'ospf_ext_spf' in file 'proto/ospf/rt.c'. The variable 'nfa' of type 'struct orta' is not totally cleaned before each start of the 'WALK_SLIST' loop, and can have a wrong value of 'nfa.nhs_reuse = 1' instead of 'nfa.nhs_reuse = 0', which is what triggers the bug. The fix is to put the declaration of 'orta nfa = {};' inside the loop, so the variable is clean at the start of each loop. Alternatively at the start of each loop you could set 'nfa.nhs_reuse = 0'. The bug only occurs when the following options are in bird.conf: ecmp yes; merge external yes; At least from what I saw the bug affects versions '2.0', '1.6.2' and '1.5'. If some of the explanation is not clear please tell me and I'll try to write it better. I'll provide a more in-depth explanation now: the relevant code is: the code is 'tagged' with 'x->' which are the relevant points for trigerring the bug static void ospf_ext_spf(struct ospf_proto *p) { ort *nf1, *nf2; 0->orta nfa = {}; ip_addr rtid; OSPF_TRACE(D_EVENTS, "Starting routing table calculation for ext routes"); WALK_SLIST(en, p->lsal) { /*not showing LSA validation*/ rtid = ipa_from_rid(en->lsa.rt); 1-> nf1 = fib_find(&atmp->rtr, &rtid, MAX_PREFIX_LENGTH); /*not showing other validations*/ if (!rt.fbit) { nf2 = nf1; 2-> nfa.nhs = nf1->n.nhs; br_metric = nf1->n.metric1; } else { nf2 = ospf_fib_route(&p->rtf, rt.fwaddr, MAX_PREFIX_LENGTH); if (!nf2) { continue; } /*not showing some validations*/ nfa.nhs = nf2->n.nhs; br_metric = nf2->n.metric1; if (has_device_nexthops(nfa.nhs)) { nfa.nhs = fix_device_nexthops(p, nfa.nhs, rt.fwaddr); 3-> nfa.nhs_reuse = 1; } } /*not showing setting other attributes in 'nfa'*/ 4-> ri_install_ext(p, rt.ip, rt.pxlen, &nfa); } } static inline void ri_install_ext(struct ospf_proto *p, ip_addr prefix, int pxlen, const orta *new) { 5->ort *old = (ort *) fib_get(&p->rtf, &prefix, pxlen); int cmp = orta_compare_ext(p, new, &old->n); if (cmp > 0) { ort_replace(old, new); } else if (cmp == 0) { 6-> ort_merge_ext(p, old, new); } } static void ort_merge_ext(struct ospf_proto *p, ort *o, const orta *new) { orta *old = &o->n; if (old->nhs != new->nhs) { 7-> old->nhs = mpnh_merge(old->nhs, new->nhs, old->nhs_reuse, new- >nhs_reuse, p->ecmp, p->nhpool); old->nhs_reuse = 1; } /* not showing code that sets other attributes */ } struct mpnh * mpnh_merge(struct mpnh *x, struct mpnh *y, int rx, int ry, int max, linpool *lp) { struct mpnh *root = NULL; struct mpnh **n = &root; while ((x || y) && max--) { int cmp = mpnh_compare_node(x, y); if (cmp < 0) { *n = rx ? x : mpnh_copy_node(x, lp); x = x->next; } else if (cmp > 0) { 8-> *n = ry ? y : mpnh_copy_node(y, lp); y = y->next; } else { 9-> *n = rx ? x : (ry ? y : mpnh_copy_node(x, lp)); x = x->next; y = y->next; } n = &((*n)->next); } *n = NULL; return root; } conditions to trigger the bug: * while in the loop there must be a LSA that has a forwading address which routes satisfy the conditions to trigger 'has_device_nexthops' so 'nfa.nhs_reuse' is set to 1, this corresponds to '3->'. Afterwards the bug could be trigger in any LSA that has the following properties: * LSA forwarding address equal to 0.0.0.0; so we set 'nfa' to the route to the router that sent the LSA. This last route is the one might be corrupted. This corresponds to '1->' and '2->'; * the route passes the validations to be installed in the OSPF routing table. This corresponds to '4->' * the old route that we had for the destination on the LSA is equally good to the new route that we are installing so we decide to merge them. This corresponds to '5->' and '6->' * The routes aren't the same instance so we decide to merge them. '7->' * While merging the next hop list we must compare at least one next hop from the 'new' route higher than a next hop from the 'old' route so we enter '8->' and wrongly not copy the next hop because 'ry = 1' due to 'nfa.nhs_reuse = 1'. This might also happen in '9->' if the next hops compare equal, but I haven't checked.

2 1

LSA ID collision issue is seen with OSPF stub-networks configured and BIRD is acting as ABR
by naveen chowdary Yerramneni 13 Dec '16

13 Dec '16

Hi, *Issue Description*: LSA ID collision issue is seen with OSPF *stub-networks* configured and BIRD is acting as ABR *BIRD OSPF configuration*: · Part of 2 areas (say, area-0 and area-100) · Stub-networks are configured in area-0 *Code Flow*: 1. Stubnets are advertised to area-0 by generating router LSA ( LSA_T_RT). o ospf_disp() -> ospf_update_topology() -> ospf_originate_rt_lsa()->ospf_ originate_lsa() 2. Now, stubnets are added to top graph table (p->gr) with LSA type LSA_T_RT 3. When creating routing table, these stubnets are added to FIB ( p->rtf). o ospf_disp() -> ospf_rt_spf() -> ospf_rt_spfa() -> spfa_process_rt() -> add_network() -> ri_install_net() 4. When BIRD is acting as ABR then, walk through FIB(p->rtf) and send summary LSA (LSA_T_SUM_NET) with LSA mode as LSA_M_RTCALC. Also, nf pointer is set (stores fib node address) in top_hash_entry. o ospf_disp() -> ospf_rt_abr2() -> check_sum_net_lsa() -> ospf_originate_sum_net_lsa() ->ospf_originate_lsa() 5. Now, stubnets are added to top graph table (p->gr) with LSA type LSA_T_SUM_NET 6. Stubnets are removed from FIB(p->rtf) o ospf_disp() -> rt_sync() -> fib_delete() 7. Now, stubnets entries are still present in top graph table (Note: fib_delte() doesn't free the node, it just moves the fib node to free pool, fib_node pointer is still valid) 8. With any change in network, ospf_rt_spf()is called. In ospf_rt_reset(), LSA mode is updated fromLSA_M_RTCALC to LSA_M_STALE. 9. Again, steps 3-6 are repeated. In step-3, fib node pointer is changed and in step-4, fib node pointer comparison fails in ospf_originate_lsa()which is leading to LSA id collision. *Issue is resolved with below code change. *Please review the change and provide your comments. Also, please let me know if any other information is required. diff -rupN bird/proto/ospf/topology.c bird_modified/proto/ospf/topology.c --- bird/proto/ospf/topology.c 2016-11-28 05:14:19.582761752 -0800 +++ bird_modified/proto/ospf/topology.c 2016-11-28 05:14:01.270761752 -0800 @@ -278,7 +278,7 @@ ospf_originate_lsa(struct ospf_proto *p, if (!SNODE_VALID(en)) s_add_tail(&p->lsal, SNODE en); - if (!en->nf || !en->lsa_body) + if (!en->nf || !en->lsa_body || en->mode == LSA_M_STALE) en->nf = lsa->nf; Thanks, Naveen

2 3

How does BIRD detect the connected network type for ospf neighbor
by Wei Huang 13 Dec '16

13 Dec '16

When I set my ospf interface eth1's address to be 10.2.1.2/30, neighbor router ethernet interface IP address to be 10.2.1.1/30, the neighbor shows it's PTP type: bird> sh ospf neighbors ospf_rdomain_0: Router ID Pri State DTime Interface Router IP 172.16.20.76 1 Full/PtP 00:35 vni-0 10.2.1.1 If I change the interfaces' IP address to be 10.2.1.x/24 or I force interface type to be bcast in Bird's ospf config, it shows as bird> sh ospf neighbors ospf_rdomain_0: Router ID Pri State DTime Interface Router IP 172.16.20.76 1 Full/DR 00:35 vni-0 10.2.1.1 My question is how does Bird detect the connected network type? Thanks, Wei

2 1

Multiple RIBs complexity
by Antonio Modesto 11 Dec '16

11 Dec '16

Hi everyone, How efficient is BIRD to calculate the best paths for multiples routing tables? I'm thinking about doing some PBR in our network to avoid some situations, for example: IX | +---------------+ | | AS100 --------- MYAS ------------TRANSIT What happens here is that I'm supposed to provide transit to AS100 directly. The problem arrises when AS100 announces a more specific route to the IX. At this point MYAS starts delivering the traffic throught the IX infraestructure, bypassing bandwidth control. Having a second FIB assigned to the TRANSIT interface that does not contain IX routes would solve the problem. I'm just worried about the CPU utilization for processing the best paths for two different routing tables. Regards. -- Atenciosamente, Antônio Modesto

3 2

bird6 1.6.2 hangs doing recvmsg on netlink socket
by Israel G. Lugo 09 Dec '16

09 Dec '16

Hello, I am getting some random crashes in bird6, running on Debian, version 1.6.2-1~bpo8+1 from your http://bird.network.cz/debian/ repository. I've got a single OSPF instance with 74 routes, one eBGP session receiving a default route, and one iBGP session with another Bird router, which sends me its own default. What happens is that, from time to time, bird6 becomes stuck in an infinite loop doing recvmsg() on a netlink socket, and IPv6 routes are lost. The interval seems random; it's been 3 days, and it's also been 2 weeks. gk1 # strace -p 11465 recvmsg(7, 0x7ffe8cfecb70, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(7, 0x7ffe8cfecb70, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(7, 0x7ffe8cfecb70, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(7, 0x7ffe8cfecb70, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(7, 0x7ffe8cfecb70, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(7, 0x7ffe8cfecb70, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(7, 0x7ffe8cfecb70, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(7, 0x7ffe8cfecb70, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(7, 0x7ffe8cfecb70, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(7, 0x7ffe8cfecb70, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(7, 0x7ffe8cfecb70, 0) = -1 EAGAIN (Resource temporarily unavailable) [...] File descriptor 7 is a netlink socket: gk1 # lsof -p 11465 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME bird6 11465 bird cwd DIR 253,0 4096 2 / bird6 11465 bird rtd DIR 253,0 4096 2 / bird6 11465 bird txt REG 253,0 540648 787381 /usr/sbin/bird6 bird6 11465 bird mem REG 253,0 47712 659204 /lib/x86_64-linux-gnu/libnss_files-2.19.so bird6 11465 bird mem REG 253,0 43592 659208 /lib/x86_64-linux-gnu/libnss_nis-2.19.so bird6 11465 bird mem REG 253,0 89104 659199 /lib/x86_64-linux-gnu/libnsl-2.19.so bird6 11465 bird mem REG 253,0 31632 659200 /lib/x86_64-linux-gnu/libnss_compat-2.19.so bird6 11465 bird mem REG 253,0 1738176 659160 /lib/x86_64-linux-gnu/libc-2.19.so bird6 11465 bird mem REG 253,0 137440 655379 /lib/x86_64-linux-gnu/libpthread-2.19.so bird6 11465 bird mem REG 253,0 140928 655799 /lib/x86_64-linux-gnu/ld-2.19.so bird6 11465 bird 0u CHR 1,3 0t0 1028 /dev/null bird6 11465 bird 1u CHR 1,3 0t0 1028 /dev/null bird6 11465 bird 2u CHR 1,3 0t0 1028 /dev/null bird6 11465 bird 3u unix 0xffff8803269f7c00 0t0 127941139 socket bird6 11465 bird 4u unix 0xffff8803269f7480 0t0 127941145 /run/bird/bird6.ctl bird6 11465 bird 5u netlink 0t0 127906248 ROUTE bird6 11465 bird 6u netlink 0t0 127906249 ROUTE bird6 11465 bird 7u netlink 0t0 127906250 ROUTE bird6 11465 bird 8u IPv6 127906251 0t0 TCP *:bgp (LISTEN) bird6 11465 bird 9u raw6 0t0 127906252 00000000000000000000000000000000:0059->00000000000000000000000000000000:0000 st=07 bird6 11465 bird 10u IPv6 127994711 0t0 TCP e0.gk1:bgp->e0.gk2:39074 (CLOSE_WAIT) bird6 11465 bird 11u IPv6 127965176 0t0 TCP [2001:w:y:x::133]:58268->[2001:w:y:x::1]:bgp (CLOSE_WAIT) Unfortunately I didn't find any debug symbols for this package, so all I could get from gdb was the following: (gdb) bt #0 0x00007f5ad1705e80 in __recvmsg_nocancel () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f5ad1b90428 in ?? () #2 0x00007f5ad1b8956b in ?? () #3 0x00007f5ad1b8a06b in ?? () #4 0x00007f5ad1b3f0c7 in ?? () #5 0x00007f5ad136db45 in __libc_start_main (main=0x7f5ad1b3eb10, argc=5, argv=0x7ffe8cfece28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe8cfece18) at libc-start.c:287 #6 0x00007f5ad1b3f3ec in ?? () (gdb) info r rax 0xfffffffffffffff5 -11 rbx 0x7f5ad32aefe0 140028066590688 rcx 0xffffffffffffffff -1 rdx 0x0 0 rsi 0x7ffe8cfecb70 140731263929200 rdi 0x7 7 rbp 0x7f5ad1dba270 0x7f5ad1dba270 rsp 0x7ffe8cfecb18 0x7ffe8cfecb18 r8 0x7f5ad32aefe0 140028066590688 r9 0x0 0 r10 0x1 1 r11 0x246 582 r12 0x0 0 r13 0x7f5ad32c7f60 140028066692960 r14 0x100 256 r15 0x0 0 rip 0x7f5ad1705e80 0x7f5ad1705e80 <__recvmsg_nocancel+7> eflags 0x246 [ PF ZF IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 Unfortunately, I did not have debug on when this crashed. I had it on for several days, but either I was "lucky" or the debug prevented the crash somehow. I was having several MB worth of debug logs every day, so I ended up disabling debug. I'm not 100% sure that this was installed from your CZ repository, it may have been from Debian backports. But I'm 95% sure it came from CZ. In any case the MD5 is as follows: 56e48e8e5a1380b384f1758df2077e53 bird_1.6.2-1~bpo8+1_amd64.deb I have now upgraded to 1.6.2-3~bpo8+1, from your CZ repository. I can provide the configuration file off-list, if that helps. Regards, Israel

1 1

problem configuring ptmp
by Maria P 08 Dec '16

08 Dec '16

Hi Everyone, I try to get a mixed network of linux and Mikrotik running, useing ptmp interfaces. It worked with quagga, but I wanna switch due to software instabilities. At least with Mikrotik & quagga I understand that a ptmp area means Hellos are propagated by multicasts to 224.0.0.5, the neighbors form ptp relations with each other after they have found themselfs. with my configuration, Bird doesn't send out multicasts, evenso its logging "ospf1: HELLO packet sent via eth0" what am I doing wrong ? Thanks Maria my config ---- log syslog all; router id 172.20.2.33; debug protocols all; protocol direct { interface "*"; # Restrict network interfaces it works with } protocol kernel { persist; # Don't remove routes on bird shutdown scan time 20; # Scan kernel routin export all; # Default is export none } protocol device { scan time 10; # Scan interfaces every 10 seconds } protocol static { import all; export all; } protocol ospf { import all; export all; area 0.0.0.0 { stub no; networks {192.168.23.0/24;}; interface "eth0" { priority 1; type ptmp; authentication simple; password "***deleted***"; cost 2; }; }; }

2 1

2 BGP sessions to same neighbors ?
by Damien Clabaut 06 Dec '16

06 Dec '16

Hello, For performance reasons that do not deserve to be detailed here, I am trying to set up 2 separate BGP sessions between my Linux server running Bird and an Arista switch. The Linux machines has 2 IPs on loopback, i would like to initiate a connexion from each of them. I have IPs 192.168.0.11 and 192.168.0.12 on the server loopback, and 192.168.0.1 on the switch loopback. These machines are connected with two different bonds, each of which has an OSPF session writing to a different routing table. Thus, I have those routes and rules: [root@bz-perflab-3-vr] ip route show table 1 10.10.50.44/30 via 10.10.50.41 dev bond0.510 proto bird 192.168.0.1 via 10.10.50.41 dev bond0.510 proto bird 192.168.0.12 via 10.10.50.41 dev bond0.510 proto bird [root@bz-perflab-3-vr] ip route show table 2 10.10.50.40/30 via 10.10.50.45 dev bond1.511 proto bird 192.168.0.1 via 10.10.50.45 dev bond1.511 proto bird 192.168.0.11 via 10.10.50.45 dev bond1.511 proto bird [root@bz-perflab-3-vr] ip rule show 0: from all lookup local 32752: from 192.168.0.12 lookup 2 32753: from 192.168.0.11 lookup 1 When I ping 192.168.0.1, the output interface depends on the source I use. So, this works. However, I cannot set up both BGP sessions. One is established and the other is idle, which makes me think there is a limitation somewhere in Bird that prevents opening several sessions with the same neighbour. TCPdump on the interface that has the "idle" BGP session shows absolutely no traffic on port 179. My BGP configuration is as follows: protocol bgp bgp_bond0 { import all; export filter { if proto = "static_bond0" then { bgp_local_pref = 105; accept; } reject; }; local as 16276; neighbor 192.168.0.1 as 16276; source address 192.168.0.11; multihop; advertise ipv4; }; protocol bgp bgp_bond1 { import all; export filter { if proto = "static_bond1" then { bgp_local_pref = 105; accept; } reject; }; local as 16276; neighbor 192.168.0.1 as 16276; source address 192.168.0.12; multihop; advertise ipv4; }; Can you confirm this is a limitation in Bird ? Is there a reason for it, apart from the fact that it is a non-standard case ? Is there a way to bypass it ? Regards, -- Damien Clabaut Network Engineer OVH.pl

2 3

Bird OSPF + Wireguard + Jessie w/kernel 4.8.7-1
by Will van Gulik 05 Dec '16

05 Dec '16

Hi, I just had an interesting case, and I'm not sure it's related to the kernel, bird, or the wireguard tool I'm trying. I'm using wireguard as tunnel device, and asking bird to listen ospf on the related interface (wg2 in this case). My kernel is the following : Linux XXXX 4.8.0-1-amd64 #1 SMP Debian 4.8.7-1 (2016-11-13) x86_64 GNU/Linux I tried two release (1.4.5 and 1.6.2) of Bird, with no change. Here is what I got from the log, without additional debug information from Bird : Dec 4 22:56:18 apu02 bird: ospf1: Socket error on wg2: Required key not available This case doesn't happen with a previous release of kernel : Linux YYYY 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64 GNU/Linux I have to admit I didn't check the change-log between the two version of kernels. Anyone stumbled on that one ? Cheers, Will

3 4

BGP large community duplicates
by Matt Griswold 02 Dec '16

02 Dec '16

>From Pierky's testing [0], Bird isn't removing received duplicates. Is anyone working on a patch for that? Otherwise I can take a look at it when I have time. Cheers [0] https://github.com/pierky/bgp-large-communities-playground/blob/master/test…

2 2

BGP graceful restart and BFD
by Vincent Bernat 02 Dec '16

02 Dec '16

Hey! I am trying to make BGP graceful restart work. First, I noticed that BGP graceful restart can only work if BIRD doesn't close cleanly the BGP session. Otherwise, an administrative shutdown is sent and the other end (also BIRD) cleans all routes and don't consider this as a graceful restart. 2016-12-02 10:09:24 <RMT> R1: Received: Administrative shutdown 2016-12-02 10:09:24 <TRACE> R1: BGP session closed 2016-12-02 10:09:24 <TRACE> R1: State changed to stop 2016-12-02 10:09:24 <TRACE> R1 > removed [sole] 203.0.113.0/24 via 192.0.2.1 on eth0 Is that an expected behavior? The second problem I run into is when using BFD. If I kill -9 bird, BFD will quickly detects the problem and shutdown the BGP session. It will not be considered a graceful restart either. 2016-12-02 10:52:50 <TRACE> R1: Neighbor graceful restart detected 2016-12-02 10:52:50 <TRACE> R1: State changed to start 2016-12-02 10:52:50 <TRACE> R1: BGP session closed 2016-12-02 10:52:50 <TRACE> R1: Connect delayed by 5 seconds 2016-12-02 10:52:51 <TRACE> R1: BFD session down 2016-12-02 10:52:51 <TRACE> R1: State changed to stop 2016-12-02 10:52:51 <TRACE> R1 > removed [sole] 203.0.113.0/24 via 192.0.2.1 on eth0 Therefore, BFD seems incompatible with graceful restart. The Juniper implementation has some provisions to make BFD and BGP graceful restart works together: > So that BFD can maintain its BFD protocol sessions across a BGP > graceful restart, BGP requests that BFD set the C bit to 1 in > transmitted BFD packets. When the C bit is set to 1, BFD can > maintain its session in the forwarding plane in spite of disruptions > in the control plane. Setting the bit to 1 gives BGP neighbors > acting as a graceful restart helper the most accurate information > about whether the forwarding plane is up. > > When BGP is acting as a graceful restart helper and the BFD session > to the BGP peer is lost, one of the following actions takes place: > - If the C bit received in the BFD packets was 1, BGP immediately > flushes all routes, determining that the forwarding plane on the > BGP peer has gone down. > - If the C bit received in the BFD packets was 0, BGP marks all > routes as stale but does not flush them because the forwarding > plane on the BGP peer might be working and only the control plane > has gone down. Unrelated to BGP restart but related to BFD, if one BGP peer has a temporary network issue, BFD will quickly close the session and then require a startup delay for the session. When the network outage is solved and one peer tries to reconnect, the session is rejected because of this startup delay: 2016-12-02 11:03:55 <TRACE> R1: State changed to start 2016-12-02 11:03:55 <TRACE> R1: Startup delayed by 60 seconds due to errors 2016-12-02 11:04:02 <TRACE> R1: Incoming connection from 192.0.2.1 (port 49205) rejected 2016-12-02 11:04:07 <TRACE> R1: Incoming connection from 192.0.2.1 (port 36449) rejected The delay can be configured to a lower value, but is it the expected behavior? The current code is: acc = (p->p.proto_state == PS_START || p->p.proto_state == PS_UP) && (p->start_state >= BSS_CONNECT) && (!p->incoming_conn.sk); Could this be changed to? acc = (p->p.proto_state == PS_START || p->p.proto_state == PS_UP) && (p->start_state >= BSS_DELAY) && (!p->incoming_conn.sk); I have put a more detailed summary of my investigations here: https://github.com/vincentbernat/network-lab/tree/caceb38e8543ec22a7693611b… -- Use uniform input formats. - The Elements of Programming Style (Kernighan & Plauger)

2 3