- Bird-users - Mailing Lists

BGP withdraw update on configuration reload
by Robert Sander 21 Nov '16

21 Nov '16

Hi, I experience the following behaviour with BIRD 1.6.2: 1. Change the config file 2. birdc configure 3. BIRD sends out an UPDATE message to its BGP peer to withdraw all prefixes learned via OSPF (see screenshot) 4. a second UPDATE message then contains all prefixes that should be announced according to the filters Where does this magic in step 3 come from? Why are prefixes getting leaked to the BGP peer that should not (even in a withdraw update)? Regards -- Robert Sander Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin

2 1

bird became slow
by Alexander Shikov 11 Nov '16

11 Nov '16

Hello! My bird handles ~170 BGP peers, ~60000 routes. Every peer is in the separate table, then routes from peers' tables are exported to main table and vice versa. Yesterday bird became very slow, BGP sessions started flapping. If I restart bird, it is stable for 5-10 minutes, and after that problem occurs again. I see following messages in log: Nov 9 09:00:30 rs0 kernel: sonewconn: pcb 0xfffff8005e640620: Listen queue overflow: 13 already in queue awaiting acceptance (637 occurrences) Nov 9 09:01:30 rs0 kernel: sonewconn: pcb 0xfffff8005e640620: Listen queue overflow: 13 already in queue awaiting acceptance (614 occurrences) Nov 9 09:01:56 rs0 bird: I/O loop cycle took 447740 ms for 427 events Nov 9 09:02:30 rs0 kernel: sonewconn: pcb 0xfffff8005e640620: Listen queue overflow: 13 already in queue awaiting acceptance (557 occurrences) I'm still running 1.5.0, FreeBSD 10.3-RELEASE. Is that known issue? Has it been fixed in later releases? Thanks in advance! -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 http://dtel-ix.net/

2 2

Override kernel interface prefix length for OSPF
by Nodar Nutsubidze 11 Nov '16

11 Nov '16

Hello! I need a way to override how the OSPF protocol sees a device interface. I had an interface which had a peer address (/32) but I needed it to be able to communicate with an upstream OSPF router which was set as (/24) communicating via broadcast and expecting a larger mask. While it is of course possible to modify the upstream OSPF router to act as PTP this was not possible in my situation. So essentially I needed to override the /32 on an interface to behave as /24 and for it to communicate in the broadcast type. In my case the interface had to remain /32 so changing it to /24 manually was not a viable option. I looked at *ptp netmask* but all that did was send up /32 instead of /0 as part of the hello packets. Has this ever come up as a request? If not then this is how I got around this issue. Let me know your thoughts. I added a configuration option into the device protocol to support a list of interface patterns which if matched will override the prefix to what is passed in. The sysdep/linux/netlink.c then looks for an interface match and modifies the pxlen to be the real prefix that is configured. This resulted in the OSPF protocol seeing the device as broadcast and /24 instead of p2p. I also have some basic questions: - Where are your bugs/issues maintained? Bugzilla? Mantis? ... - I say this because there is a TODO in the code but would expect this in a issue tracking system. - Is there a list of tests that your team goes through before you release a version and if so where are they defined so that I can run through them before I push up a patch. I've done basic OSPF tests with the associated patch as well as valgrind leak checks. Thank you very much!

1 0

PPA Versions
by Will Dowling 08 Nov '16

08 Nov '16

2 1

Bird stops responding to BFD messages
by Pavlos Parissis 02 Nov '16

02 Nov '16

Hello, We have 1.4.5 running on ~50 CentOS 7 servers and we have observed that Bird daemon stops responding on BFD messages which causes the BGP peering to be stopped and started again. Some details on our setup. Servers have 2 interfaces (north and south) and advertise /32 prefixes to the north and south for IPs assigned to loopback interface. Bird receives 'Received: Other configuration change' message over BGP from both peers, which are 2 different arista switches, at the same time. Tracing on the switches shows that Bird didn't respond on 3 BFD messages and arista informed Bird about it. It is very unlikely that switches or cables are the problem here. Bird will reestablish BGP peering with ~50secs and server will start receive traffic again. So, we have an outage that for about ~50seconds. We have seen these to different servers connecting to different switches. The frequency of the problem is very low, once per 2 days across 50 servers. Furthermore, there is any specific pattern in CPU, traffic, interface/TCP errors and something else which can help us to debug. I have seen in 2-3 cases that CPU usage at system jumps to 70% at the timestamp of the log that says 'BGP1: Received: Other configuration change' but the main software on the servers (HAProxy) which consumes most of the resources doesn't have any spike in CPU. Has anyone seen this behavior? Nov 01 16:23:00 bird[1376]: BGP1: Received: Other configuration change Nov 01 16:23:00 bird[1376]: BGP1: BGP session closed Nov 01 16:23:00 bird[1376]: BGP1: State changed to stop Nov 01 16:23:00 bird[1376]: BGP1: Down Nov 01 16:23:00 bird[1376]: bfd1: Session to 2.2.2.2 removed Nov 01 16:23:00 bird[1376]: BGP1: State changed to down Nov 01 16:23:00 bird[1376]: BGP1: Starting Nov 01 16:23:00 bird[1376]: BGP1: State changed to start Nov 01 16:23:00 bird[1376]: bfd1: Session to 2.2.2.2 added Nov 01 16:23:00 bird[1376]: BGP1: Startup delayed by 60 seconds Nov 01 16:23:00 bird[1376]: BGP2: Received: Other configuration change Nov 01 16:23:00 bird[1376]: BGP2: BGP session closed Nov 01 16:23:00 bird[1376]: BGP2: State changed to stop Nov 01 16:23:00 bird[1376]: BGP2: Down Nov 01 16:23:00 bird[1376]: bfd1: Session to 1.1.1.1 removed Nov 01 16:23:00 bird[1376]: BGP2: State changed to down Nov 01 16:23:00 bird[1376]: BGP2: Starting Nov 01 16:23:00 bird[1376]: BGP2: State changed to start Nov 01 16:23:00 bird[1376]: bfd1: Session to 1.1.1.1 added Nov 01 16:23:00 bird[1376]: BGP2: Startup delayed by 60 seconds Nov 01 16:23:00 bird[1376]: bfd1: Bad packet from 1.1.1.1 - unknown session id (3840383752) Nov 01 16:23:00 bird[1376]: bfd1: Bad packet from 2.2.2.2 - unknown session id (3632088877) Nov 01 16:23:00 bird[1376]: bfd1: Bad packet from 1.1.1.1 - unknown session id (3840383752) Nov 01 16:23:00 bird[1376]: bfd1: Bad packet from 2.2.2.2 - unknown session id (3632088877) Nov 01 16:23:00 bird[1376]: bfd1: Bad packet from 1.1.1.1 - unknown session id (3840383752) Nov 01 16:23:00 bird[1376]: bfd1: Bad packet from 2.2.2.2 - unknown session id (3632088877) Nov 01 16:23:00 bird[1376]: bfd1: Bad packet from 1.1.1.1 - unknown session id (3840383752) Nov 01 16:23:00 bird[1376]: bfd1: Bad packet from 2.2.2.2 - unknown session id (3632088877) Nov 01 16:23:00 bird[1376]: bfd1: Bad packet from 1.1.1.1 - unknown session id (3840383752) bird.conf: log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug }; include "/etc/bird.d/*.conf"; router id 1.1.1.2; protocol device { scan time 10; } protocol static { disabled yes; } protocol direct direct1 { interface "lo"; debug all; export none; import where net ~ ANYCAST_NETWORKS; } protocol bfd bfd1 { debug { states, routes, filters, interfaces, events }; interface "north", "south" { min rx interval 400 ms; min tx interval 400 ms; idle tx interval 1000 ms; multiplier 3; }; } protocol bgp BGP1 { disabled no; description "Peer-BGP1"; neighbor 1.1.1.1 as 64824; source address 1.1.1.2; bfd on; debug all; import none; export where match_route_north(); direct; hold time 10; startup hold time 240; connect retry time 120; keepalive time 3; start delay time 5; error wait time 60, 300; error forget time 300; disable after error off; next hop self; path metric 1; default bgp_med 0; default bgp_local_pref 0; local as 64825; } protocol bgp BGP2 { disabled no; description "Peer-BGP2"; neighbor 2.2.2.2 as 64827; source address 2.2.2.1; bfd on; debug all; import none; export where match_route_south(); direct; hold time 10; startup hold time 240; connect retry time 120; keepalive time 3; start delay time 5; error wait time 60, 300; error forget time 300; disable after error off; next hop self; path metric 1; default bgp_med 0; default bgp_local_pref 0; local as 64825; } Cheers, Pavlos

2 2

Static routes and BFD
by J. Kendzorra 31 Oct '16

31 Oct '16

Hello all, I am trying to make use of BFD for default gateway failover (in my BFD test bed). I used multiple variations, but according to the documentation (if I get it right), I should be fine using something like this: ,-- on client: # empty BFD config protocol bfd { #debug all; } # simple default route with BFD driven failover protocol static { debug all; route 0.0.0.0/0 via 192.168.1.1 { bfd on; }; route 0.0.0.0/0 via 192.168.1.2 { bfd on; }; }; `-- ,-- on gateways: protocol bfd { interface "vlan*" { passive; }; debug all; } `-- Whenever I omit the "passive" statement, I can see "BFDv1 Control State Down" going on the wire; not sure why this appears to be the default on how to change this to "up": ,-- tcpdump: 08:11:41.732031 IP 192.168.1.3.23863 > 192.168.1.2.3784: BFDv1, Control, State Down, Flags: [none], length: 24 08:11:41.732033 ethertype IPv4, IP 192.168.1.3.23863 > 192.168.1.2.3784: BFDv1, Control, State Down, Flags: [none], length: 24 08:11:41.732034 ethertype IPv4, IP 192.168.1.3.23863 > 192.168.1.2.3784: BFDv1, Control, State Down, Flags: [none], length: 24 `-- What puzzles me is that I'd now expect the client to initiate a BFD connection to both gateways, however I do not see a single packet (except when not using passive I see what's pasted above). The config appears to get active however: ,-- 2016-10-26 08:07:37 <INFO> Reconfiguring 2016-10-26 08:07:37 <TRACE> bfd1: Session to 192.168.1.1 reconfigured 2016-10-26 08:07:37 <TRACE> bfd1: Session to 192.168.1.2 reconfigured 2016-10-26 08:07:37 <TRACE> bfd1: Reconfigured 2016-10-26 08:07:37 <TRACE> static1: Reconfigured 2016-10-26 08:07:37 <INFO> Reconfigured `-- This is what I see when BFD is not configured to be passive: ,-- 2016-10-26 08:11:58 <TRACE> bfd1: Sending CTL to 192.168.1.2 [Down] 2016-10-26 08:11:58 <TRACE> bfd1: Sending CTL to 192.168.1.1 [Down] (...) `-- Any clues on how to debug this further? Thanks, J.

2 4

[PATCH] fix syslog corruption when using customized name
by Chris Caputo 31 Oct '16

31 Oct '16

Fix bug with syslog using string passed to openlog() which is later stomped on, resulting in corrupted log messages. This happens when name is specified in a syslog log line, ala: log syslog name "bird-foo" all; Per Linux SYSLOG(3): The argument ident in the call of openlog() is probably stored as-is. Thus, if the string it points to is changed, syslog() may start prepending the changed string, and if the string it points to ceases to exist, the results are undefined. Most portable is to use a string constant. Signed-off-by: : Chris Caputo <ccaputo(a)alt.net> --- sysdep/unix/log.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/sysdep/unix/log.c b/sysdep/unix/log.c index 1fd6442..7086f7d 100644 --- a/sysdep/unix/log.c +++ b/sysdep/unix/log.c @@ -289,17 +289,23 @@ log_switch(int debug, list *l, char *new_syslog_name) #ifdef HAVE_SYSLOG char *old_syslog_name = current_syslog_name; - current_syslog_name = new_syslog_name; if (old_syslog_name && new_syslog_name && !strcmp(old_syslog_name, new_syslog_name)) return; if (old_syslog_name) - closelog(); + { + closelog(); + free(old_syslog_name); + } if (new_syslog_name) - openlog(new_syslog_name, LOG_CONS | LOG_NDELAY, LOG_DAEMON); + { + current_syslog_name = xmalloc(strlen(new_syslog_name) + 1); + strcpy(current_syslog_name, new_syslog_name); + openlog(current_syslog_name, LOG_CONS | LOG_NDELAY, LOG_DAEMON); + } #endif }

2 2

Question about filter with BGP Communities and BGP Extended Communities
by Lucenildo Lins Aquino Júnior 28 Oct '16

28 Oct '16

Hi All, I am run bird for lab and I am with a difficult to create a filter with bgp communities and bgp extended communities. In my filter at first I check if router need go only for peer ASN, note that is a export filter. If not only for peer ASN and have only-community (65001:* or ro:65001:*) drop this route. I was executed troubleshooting and I could determinate that problem is in this operation: "(([(65001,*)] ~ bgp_community) || ([(ro,65001,*)] ~ bgp_ext_community))". I think in this regular expression have a problem, that case create a fault in my if-clause. I operate my bird in mode router-server, to simulate a IXP. In this test my other client announce a router without community 65001:*. and in import filter with ASN 61580 I am accept all routes . Thanks, Lucenildo Lins +++++++ lucenildo@other-client> show route advertising-protocol bgp 187.16.213.253 extensive 168.181.23.0/24 inet.0: 27 destinations, 32 routes (26 active, 0 holddown, 2 hidden) * 168.181.23.0/24 (1 entry, 1 announced) BGP group IX-emulado-v4 type External Nexthop: Self AS path: [61580] I Communities: 61580:5571 65000:11752 65000:14026 +++++++++ define Client_ASN = 65551; filter bgp_out_as65551 { if exp_only(Client_ASN) then { rm_interal_comm(); accept; } if exp_has_only() then { rm_interal_comm(); reject; } rm_interal_comm(); accept; } function exp_has_only() { if !(source = RTS_BGP) then return false; if (([(65001,*)] ~ bgp_community) || ([(ro,65001,*)] ~ bgp_ext_community)) then return true; return false; } function exp_only(int ASNumber) { if ! (source = RTS_BGP) then return false; if ASNumber > 65535 then { if (ro,65001,ASNumber) ~ bgp_ext_community then return true; } else { if (((65001,ASNumber) ~ bgp_community) || ((ro,65001,ASNumber) ~ bgp_ext_community)) then return true; } return false; }

2 1

Bird6 picking up /128 routes from the routing cache
by Tore Anderson 24 Oct '16

24 Oct '16

Hi, I noticed something a bit spooky in my lab. Bird6 appears to pick up and export routes that are added to the Linux kernel's routing cache. That is, with a bird6.conf as shown below, if I fire up bird6 in debug mode, and ping a destination with a reduced MTU (to get an ICMPv6 PTB back to trigger caching of the host route due to its lower PMTU): $ ping6 -M do -s 1452 2a01:79d:1234:: # Norwegian ISP using 6RD PING 2a01:79d:1234::(2a01:79d:1234::) 1452 data bytes >From 2a01:798:0:416::a1b:1 icmp_seq=1 Packet too big: mtu=1480 I see the following show up in bird6's stderr: $ /usr/sbin/bird6 -d -u bird -g bird bird: Started bird: Exporting external route ::/0; next-hop=fe80::e611:5bff:fe9b:90e1; source=kernel1 bird: Exporting external route 2a01:79d:1234::/128; next-hop=fe80::e611:5bff:fe9b:90e1; source=kernel1 This route does however *not* show up in Linux' "main" routing table, only in the cache one: $ ip -6 route show table cache 2a01:79d:1234:: via fe80::e611:5bff:fe9b:90e1 dev eth0 metric 0 cache expires 28sec mtu 1480 hoplimit 64 I've seen this both with bird 1.5.0 and 1.6.2, and on Ubuntu kernels 3.13.0 and 4.4.0. Question is, why does this happen? I certainly wouldn't expect it to and if it means that this router would start attracting traffic destined for the host in question I fear it'll create a blackhole/loop. If I change the kernel table number from 254 ("main") to some other random table number, it doesn't happen anymore. To complicate matters further I only see this in my lab. Even though I have the same versions and config in production I cannot see that the same thing happens there. One difference I can think of is that in production the default route is learned from OSPF while in the lab it is learned from SLAAC (and picked up by bird6 that way as shown in the debug output). Not sure if that makes any difference (and if so why). Tore $ cat /etc/bird/bird6.conf router id 192.0.2.1; protocol device {} protocol kernel { learn; export all; import all; kernel table 254; # "main" } protocol ospf { export filter { printn "Exporting external route "; printn net; if defined(gw) then { printn "; next-hop="; printn gw; } if defined(proto) then { printn "; source="; printn proto; } print ""; accept; }; area 0.0.0.0 { interface "eth0" { type broadcast; }; }; }

2 1

BLACKHOLE community RFC7999
by Alexander Shikov 21 Oct '16

21 Oct '16

Hi! Just FYI: https://www.rfc-editor.org/rfc/rfc7999.txt I guess this feature deserves to be implemented. -- Alexander Shikov Technical Staff, Digital Telecom IX http://dtel-ix.net/

8 10