- Bird-users - Mailing Lists

OSPF over openvpn; adjacency problems
by Thorsten Alteholz 02 Oct '19

02 Oct '19

Hi, I am trying to use OSPF over an openvpn link. tcpdump tells me that both ends send their HELLO packet but bird does not want to recognize them. When looking at ospf_rc_hook() in proto/ospf/packet.c the HELLO packet arrives in bird, but is discarded because of "strange address combinations": src_local is 0: sk->faddr = 10.25.0.26 ifa->addr->prefix = 10.25.0.2 ifa->addr->pxlen = 32 dst_mcast is 1: sk->laddr = 224.0.0.5 ifa->all_routers = 224.0.0.5 ifa->des_routers = 224.0.0.6 dst_mcast = 1 || 0 >From my point of view these values do not look that bad (the tun interface on this server has an address of 10.25.0.1 and on the client it is 10.25.0.26). But of course (dst_mcast && !src_local) is 1 and the HELLO packet is ignored. Does anybody have any idea what went wrong here? Best regards Thorsten The OSPF configuration on the server: protocol ospf { debug all; import all; export none; area 10.10.10.0 { interface "tun1" { type ptp; cost 2000; neighbors { 10.25.0.1; }; }; }; }

3 3

Explicit as-path filtering (with prepending allowed)
by Nigel Kukard 02 Oct '19

02 Oct '19

Hi guys, Is there perhaps an equivalent in BIRD for the following... ^(65000_)+(65101_)+(65253_)+$ The closest I could come was the following, but I am unsure if it would match if any of the networks prepend. if (bgp_path ~ [= 65000 65101 65253 =]) -N

2 2

Resolve a BGP next-hop with another BGP route
by Alarig Le Lay 30 Sep '19

30 Sep '19

Hello, It seems that bird can’t resolve the next-hop in that case. But there is no issue when the next-hop is announced by OSPF. bird> show route all for 45.91.127.1 Table master4: 45.91.127.0/24 unreachable [ibgp_hv02_ipv4 16:16:24.927 from 89.234.186.40] * (100/-) [i] Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 89.234.186.116 BGP.local_pref: 100 unreachable [ibgp_nominoe_ipv4 16:01:40.402 from 89.234.186.33] (100/-) [i] Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 89.234.186.116 BGP.med: 150 BGP.local_pref: 100 BGP.originator_id: 89.234.186.40 BGP.cluster_list: 89.234.186.33 bird> show route all for 89.234.186.116 Table master4: 89.234.186.116/32 unicast [ibgp_hv02_ipv4 16:21:11.352] * (100/0) [i] via 89.234.186.40 on enp3s0f1.33 Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 89.234.186.40 BGP.local_pref: 100 unicast [ibgp_nominoe_ipv4 16:20:22.754 from 89.234.186.33] (100/0) [i] via 89.234.186.40 on enp3s0f1.33 Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 89.234.186.40 BGP.med: 150 BGP.local_pref: 100 BGP.originator_id: 89.234.186.40 BGP.cluster_list: 89.234.186.33 But cisco works well: asbr01#sh ip route 45.91.127.1 Routing entry for 45.91.127.0/24 Known via "bgp 204092", distance 200, metric 150, type internal Last update from 89.234.186.116 00:07:07 ago Routing Descriptor Blocks: * 89.234.186.116, from 89.234.186.40, 00:07:07 ago Route metric is 150, traffic share count is 1 AS Hops 0 MPLS label: none asbr01#ping 45.91.127.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 45.91.127.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms asbr01# asbr01#sh ip route 89.234.186.116 Routing entry for 89.234.186.116/32 Known via "bgp 204092", distance 200, metric 150, type internal Last update from 89.234.186.40 01:13:29 ago Routing Descriptor Blocks: * 89.234.186.40, from 89.234.186.40, 01:13:29 ago Route metric is 150, traffic share count is 1 AS Hops 0 MPLS label: none Am I missing something? Regards, -- Alarig

3 4

BFD neighbor reload issue
by Winston Chen 30 Sep '19

30 Sep '19

Hi, I am using BFD neighbor to config BFD sessions statically. I found that if I add/remove BFD neighbors in bird.conf and ask bird to reload with HUP signal, bird cannot reload the configuration correctly. Here is the BFD config I used to test. If I start bird with this configuration, then comment one of the neighbors and send HUP with kill to bird, bird simply says session reconfigured without remove the commented neighbor. protocol bfd { interface "*" { passive; }; neighbor 172.17.0.2; neighbor 172.17.0.3; } After digging into the code, I found that it looks like there is a bug in function bfd_reconfigure_neighbors. It loops to check neighbor in old and new configuration. There is a return in the block if (bfd_same_neighbor(nn, on)). If there is neighbor existing in both new and old, reconfiguration might be skipped. I tried to modify the code to make it work. And the attached patch is the one I got. Hopefully this is the proper way to solve the issue. Regards. Chen.

2 1

every minute: "I/O loop cycle took .... ms for 2 events"
by Christoph 30 Sep '19

30 Sep '19

Hello, (please keep me in CC the mailing list issues are still not solved) we get the following WARN log entry exactly once a minute: I/O loop cycle took 6343 ms for 2 events Is this something to worry about? Is this related to hard drive I/O or some other kind of I/O? thanks, Christoph

3 3

BIRD on HW ASIC
by Роман Вартичан 28 Sep '19

28 Sep '19

Hello! We are going to implement BIRD on HW ASIC platform. We try to understand how to untie bird from linux kernel and route its netlink or unix socket commands to ASIC driver (we carefully studied mail list, but did not find any info about this). We see that ioctl in BIRD will be deprecated in near future. Could you kindly clarify which is the best way of connecting of BIRD with proprietary hardware driver which runs in user space? -- Roman

2 1

OSPF key expire rules violates RFC 2293?
by Kenth Eriksson 27 Sep '19

27 Sep '19

Hi! When an OSPF key lifetime expires then bird stops using that key. E.g. if the configured parameter "generate from time" expires, then bird reverts to an OSPF interface in unauthenticated mode. Is this intentional? Or is it something that can be configured? I think it is not according to the RFC. In appendix D of RFC 2293, the following is stated; "In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt routing." Thanks, Kenth

2 2

Question for proper RPKI check integration in the bird v2.0.4 with Euro-IX Informational BGP communities
by Irene Lalioti 25 Sep '19

25 Sep '19

Hello all, Can you please let me know where is the syntax error in my snippet , or if it is wrong how else I should integrate it in a way bird doesn't complain? Thanks in advance! #RPKI Check filter bgp_in_AS1234 prefix set allnet; { include "/etc/bird/prefix-lists/AS2589-v4"; if (is_martian4()) then reject; if ! (net ~ allnet) then reject; rpki_result = roa check(r4, net, bgp_path.last_nonaggregated ); if ( rpki_result = ROA_INVALID ) then{ bgp_community.add((1234:1000:4)); reject; print "Invalid ROA ", net, " for ASN ", bgp_path.last_nonaggregated, "from AS1234" ; } if ( rpki_result = ROA_VALID ) then{ bgp_community.add((1234:1000:1)); accept; } if ( rpki_result = ROA_ UNKNOWN ) then{ bgp_community.add((1234:1000:2)); accept; print "Unknown RPKI ", net, "for ASN ", bgp_path.last_nonaggregated, "from AS1234 "; } } -- Irene Lalioti Network Engineer Fondation RESTENA 2, avenue de l'Université L-4365 Esch/Alzette Tel: +352 424409 1 Fax: +352 422473

3 8

Bird v2.0.4 "Can't add/delete non-pair" and "END-OF-RR received prior BEGIN-OF-RR, ignoring" meaning
by Irene Lalioti 25 Sep '19

25 Sep '19

Hello all, I would be grateful if you could direct me, provide me some insight to figure out where those errors/alarms emanate from. In my test environment I did not encounter those errors, only upon the actual live migration , while bringing the BGP sessions with the peers up. Some where coming up some not. The 1st error was : ... filters, line 2208: Can't add/delete non-pair The 2nd error was: ...R15814x2: END-OF-RR received without prior BEGIN-OF-RR, ignoring R35283x1: BEGIN-OF-RR received before END-OF-RIB, ignoring R13002x1: BEGIN-OF-RR received before END-OF-RIB, ignoring filters, line 1645: ~ applied on unknown type pair **** Problem with filters? I found also : * bgp_refresh_begin - start incoming enhanced route refresh sequence * @p: BGP instance * * This function is called when an incoming enhanced route refresh sequence is * started by the neighbor, demarcated by the BoRR packet. The function updates * the load state and starts the routing table refresh cycle. Note that graceful * restart also uses routing table refresh cycle, but RFC 7313 and load states * ensure that these two sequences do not overlap. */ void bgp_refresh_begin(struct bgp_proto *p) { if (p->load_state == BFS_LOADING) { log(L_WARN "%s: BEGIN-OF-RR received before END-OF-RIB, ignoring", p->p.name); return; } p->load_state = BFS_REFRESHING; rt_refresh_begin(p->p.main_ahook->table, p->p.main_ahook); } /** Thanks a lot for your help! Regards, Irène -- Irene Lalioti Network Engineer Fondation RESTENA 2, avenue de l'Université L-4365 Esch/Alzette Tel: +352 424409 1 Fax: +352 422473

1 0

Segfault Showing export table on 2.0.6
by Matt Corallo 24 Sep '19

24 Sep '19

Sometimes showing export table(s) from birdc on 2.0.6 results in a Segfault of the bird daemon. I can try to debug further if this isn't sufficient, but largely the only difference between one protocol and the other is the presence of communities on the exports from PROTO2. birdc -s /root/bird-runtime/bird-3.ctl BIRD 2.0.6 ready. bird> show route export table PROTO1.ipv4 all Table export: 69.59.18.0/24 unicast [v4sta 11:55:59.366] * (1000) dev lo Type: static univ 208.68.4.0/24 unicast [v4sta 11:55:59.366] * (1000) dev lo Type: static univ bird> show route export table PROTO2.ipv4 all ... 2019-09-19 11:45:04.706302 bird-out-3.fifo Segmentation fault Matt

3 5