- Bird-users - Mailing Lists

BIRD, Route Source and BSD
by Jean-Baptiste COUPIAC 30 Nov '16

30 Nov '16

Hello list, I'm a new in Bird word :). I'm working on a Bird mock-up. I'm actually blocked on OSPF filters. OSPF conf for First Router: *protocol ospf OSPF {* * import filter NFRANCE_OSPF_IN;* * export filter NFRANCE_OSPF_OUT;* * rfc1583compat yes;* * area 0 {* * interface "xn1" {* * type broadcast;* * };* * interface "xn2" {* * stub;* * };* * };* *};* OSPF conf for Second Router: *protocol ospf OSPF {* * import filter NFRANCE_OSPF_IN;* * export filter NFRANCE_OSPF_OUT;* * rfc1583compat yes;* * area 0 {* * interface "xn1" {* * type broadcast;* * };* * interface "xn2" {* * stub;* * };* * };* *};* Filters: *filter NFRANCE_OSPF_IN {* * if net ~ [80.247.224.0/20{24,32} <http://80.247.224.0/20{24,32}>] && (source ~ [ RTS_OSPF_EXT1, RTS_OSPF_EXT2 ])* * then* * {* * print net, " is accepted => OSPF_IN Public Nfrance";* * accept;* * }* * if net ~ [0.0.0.0/0{30,30} <http://0.0.0.0/0{30,30}>] && (source ~ [ RTS_OSPF_EXT1, RTS_OSPF_EXT2 ])* * then* * {* * print net, " is accepted => OSPF_IN Interco /30";* * accept;* * }* * else* * {* * print net, " is rejected => non OSPF_IN compliant";* * reject;* * }* * }* 80.247.227.2/24 is installed on Router 1, xn2 interface, Export network 80.247.227.0/24 on router 1 is ok but Import on the another router is KO. Indeed, If I use the condition: *if net ~ [80.247.224.0/20{24,32} <http://80.247.224.0/20{24,32}>] && (source ~ [ RTS_OSPF_EXT1, RTS_OSPF_EXT2 ])* 80.247.227.0/24 is rejected by the OSPF neighbor filter rule* NFRANCE_OSPF_IN* 2016-11-25 16:31:28 <INFO> 80.247.227.0/24 is rejected => non OSPF_IN compliant If I use the condition: *if net ~ [80.247.224.0/20{24,32} <http://80.247.224.0/20{24,32}>] *without *&& (source ~ [ RTS_OSPF_EXT1, RTS_OSPF_EXT2 ])* 80.247.227.0/24 is accepted by the OSPF neighbor filter rule* NFRANCE_OSPF_IN* 2016-11-25 16:42:18 <INFO> 80.247.227.0/24 is accepted => OSPF_IN Public Nfrance And when I check the bird route when network is accepted, I can see "OSPF" bird> show route 0.0.0.0/0 via 192.168.0.254 on xn0 [kernel1 16:35:00] * (10) 192.168.0.221/32 dev lo0 [kernel1 16:35:00] * (10) *80.247.227.0/24 <http://80.247.227.0/24> via 172.16.51.4 on xn1 [OSPF 16:42:18] * I (150/20) [192.168.0.223]* 172.16.51.1/32 dev lo0 [kernel1 16:35:00] * (10) bird> So I don't understand why *&& (source ~ [ RTS_OSPF_EXT1, RTS_OSPF_EXT2 ]) *does not match when the rule is added to my filter ? I use FreeBSD 10, Is there an issue on FBSD regarding RTS_* ? __ *Jean-Baptiste COUPIAC*

2 2

IS-IS ?
by Damien Clabaut 29 Nov '16

29 Nov '16

Hello, Do you have any future plans to implement the IS-IS routing protocol in Bird ? Regards, -- Damien Clabaut Network Engineer OVH.pl

3 2

Linux 'local' table (255) import into BIRD?
by Eric Vyncke (evyncke) 25 Nov '16

25 Nov '16

Hello, I am trying to import 'local' routes from the kernel into Bird without any success... The route is installed as: "/sbin/ip -6 route add local 2001:db8:cafe:babe::/64 dev lo" (it allows the host to reply/answer to any address in this prefix :-)) My bird6.conf is: protocol direct { interface "lo"; } # Table main is 254 # Table local is 255 protocol kernel { debug all; learn; persist; scan time 10; import all; export all; kernel table 255; } The log shows an attempt to import a connected route but not the 'local' one 2016-11-25 11:37:59 <TRACE> kernel1 < interface lo goes up 2016-11-25 11:37:59 <TRACE> kernel1 < interface eth0 goes up 2016-11-25 11:37:59 <TRACE> kernel1 < interface eth1 goes up 2016-11-25 11:37:59 <TRACE> kernel1: State changed to up 2016-11-25 11:37:59 <TRACE> kernel1: Scanning routing table 2016-11-25 11:37:59 <TRACE> kernel1: Pruning table master 2016-11-25 11:37:59 <TRACE> kernel1: Pruning inherited routes 2016-11-25 11:38:00 <TRACE> kernel1 < rejected by protocol 2001:db8:f00:beef::/64 dev eth1 2016-11-25 11:38:05 <TRACE> kernel1 < rejected by protocol 2001:db8:f00:beef::/64 dev eth1 2016-11-25 11:38:09 <TRACE> kernel1: Scanning routing table 2016-11-25 11:38:09 <TRACE> kernel1: Pruning table master 2016-11-25 11:38:09 <TRACE> kernel1: Pruning inherited routes Assistance will be welcome (and I did google a lot) -éric

4 6

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