- Bird-users - Mailing Lists

BGP multipath support
by Alexander Frolkin 08 Jun '15

08 Jun '15

Hello, I was wondering how hard it would be to add BGP multipath support to BIRD, or if anyone was working on it already? I'm not a C guru, but I could maybe have a look at doing this, especially if someone who knows the code could point me in the right direction... :-) Thanks! Alex

5 10

BGP extented communities checks
by Arnaud Fenioux 08 Jun '15

08 Jun '15

Hi folks! I have played with extended communities with some of my peers, and have written this function below to facilitate my checks. On the examples found on github (https://gitlab.labs.nic.cz/labs/bird/wikis/Route_server_with_community_base… and https://gitlab.labs.nic.cz/labs/bird/wikis/Route_server_with_community_base…) I have noticed that RO are used : if (ro,myas,peeras) ~ bgp_ext_community then return true; bgp_ext_community.delete([(ro,0,*)]); But according to my tests, RT should be used. Did anybody made the same ascertainment? ----- ### Chek if the community or ext_community is present function is_community(int left; int right) { if right > 65535 then { #Check of the extended community for 32b ASN if (rt,left,right) ~ bgp_ext_community then return true; } else { #Check of the extended (and not ext) community for 16b ASN if ((left,right) ~ bgp_community) || ((rt,left,right) ~ bgp_ext_community) then return true; } return false; } ---- Cheers, -- Arnaud Fenioux Network Engineer - FranceIX

2 4

OSPFv3 and stub interfaces without lladdr
by Christian Tacke 04 Jun '15

04 Jun '15

Hi, I am trying to get ipv6 routes to openvpn server into ospf. if have an interface "tun*" { stub; }; in my bird6.conf. openvpn does not add link level addrs to its interfaces. That's why ospf ignores this interface. Ignoring it for doing ospf on it is okay, as ospf really wants to run over lladdrs. But do stub networks require a lladdr to be used in ospf? This is at least confusing to me. bird> sh int tun2 up (index=20) PtP Multicast AdminUp LinkUp MTU=1500 fdxx:xxxx:xxxx:4000::1/64 (Primary, scope site) bird> show ospf interface "tun2" ospf1: A workaround is to add fe80::1/64 to tun2 in some "up" script in openvpn, so that bird6 sees the interface. But that does not feel right, really. Cheers Christian -- www.cosmokey.com

3 4

Bird4 ospf not learning/distributing p2p links routes
by daniele 03 Jun '15

03 Jun '15

Hi all, Is it normal that routes flagged as H, ie. /32 routes in p2p links in linux routing table, are not learnt and distributed by ospf? In my ospf area I need all the routers to know about the different p2p endpoint addresses which are not distributed by ospf in bird4. The only networks that are distributed are non-p2p subnets. Currently the only way to make this happen is to manually set some /32 static routes.. not really flexible. thanks daniele

2 2

IS-IS
by kveri new 01 Jun '15

01 Jun '15

Hello, I would like to implement IS-IS as a part of my master thesis. Are there any apparent problems which would prevent successful implementation, political and/or technical? Also I would like to hear opinions of the authors. Implementation timeframe is 2013 (if we live past 21th). Regards, Martin Čechvala Faculty of Informatics and Information Technologies Slovak Technical University

7 8

[PATCH] Fix typo: OSPF designated router
by Hans van Kranenburg 01 Jun '15

01 Jun '15

Hi, attached a small patch to correct the naming of the OSPF designated router in the output of show ospf interface. Have fun, -- Hans van Kranenburg - System / Network Engineer T +31 (0)10 2760434 | hans.van.kranenburg(a)mendix.com | www.mendix.com

2 1

Bird 1.5.0 with BFD on Linux 2.6.32 crashes
by Thomas King 26 May '15

26 May '15

Hi all, I am using Linux 2.6.32 kernel and Bird 1.5.0. I configured a BFD session in order to cover my BGP session as this: protocol bfd mybfd { neighbor fec0::a:cf:0:2 dev "tking"; } If I start bird with this config it crashes with the following error message: 2015-05-26 19:15:50 <ERR> mybfd: Socket error: SO_PRIORITY: Operation not permitted After applying a hotfix to the SO_PRIORITY handling BFD works. tking@h2216609:~/bird/bird-1.5.0/sysdep/unix# diff io.c_old io.c 1220c1220 < return -1; --- > return 0; Best regards, Thomas and Eric

1 0

Routes disappear after reloading BIRD configuration
by Robert Brockbank 22 May '15

22 May '15

Hi, I've got two hosts each running BIRD within a docker container. If I restart BIRD on one of the hosts, I drop routes. I have the kernel option "persist" set, running bird with the -R option and set kernel and bgp to have graceful restart. Restarting the service, sending in a SIGHUP or entering "configure" on birdc all cause routes to be dropped temporarily. Any thoughts on what might be causing this? Is this just a configuration issue? I've outlined my set up below, including config files etc. One other question, are there any plans to allow dynamic reconfiguration (e.g. adding and removing a peer) without restarting the protocols? Any help or advice you could give would be most welcome. Thanks, Rob Brockbank Set up is as follows: HOST A: ======= **** IP: 172.17.8.101 **** **** Output from routing table **** root@core-01:/# ip route default via 10.0.2.2 dev eth0 proto dhcp src 10.0.2.15 metric 1024 10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 10.0.2.2 dev eth0 proto dhcp scope link src 10.0.2.15 metric 1024 10.1.0.0/16 dev docker0 proto kernel scope link src 10.1.42.1 172.17.8.0/24 dev eth1 proto kernel scope link src 172.17.8.101 192.168.1.1 dev cali1fb91036fff scope link 192.168.1.2 dev cali1ff66dc8fff scope link 192.168.1.3 dev cali2078697cfff scope link 192.168.1.4 via 172.17.8.102 dev eth1 proto bird 192.168.1.5 via 172.17.8.102 dev eth1 proto bird **** Bird command line **** bird -R -s bird.ctl -d -c /config/bird.cfg **** Bird config **** router id 172.17.8.101; log "/var/log/calico/bird.log" all; filter calico_pools { if ( net ~ 192.168.0.0/16 ) then { accept; } else { reject; } } protocol kernel { learn; # Learn all alien routes from the kernel persist; # Don't remove routes on bird shutdown scan time 2; # Scan kernel routing table every 2 seconds import all; device routes; export all; # Default is export none graceful restart; } protocol device { scan time 2; # Scan interfaces every 2 seconds } protocol direct { debug all; interface -"cali*", "*"; # Exclude cali* but include everything else. } # Template for all BGP clients template bgp bgp_template { debug all; description "Connection to BGP peer"; local as 64511; multihop; gateway recursive; import all; export filter calico_pools; next hop self; source address 172.17.8.101; add paths on; graceful restart; } protocol bgp from bgp_template { neighbor 172.17.8.102 as 64511; } HOST B (pretty much identical to HOST A with IPs swapped): ======= **** IP: 172.17.8.102 **** **** Output from routing table **** root@core-02:/# ip route default via 10.0.2.2 dev eth0 proto dhcp src 10.0.2.15 metric 1024 10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 10.0.2.2 dev eth0 proto dhcp scope link src 10.0.2.15 metric 1024 10.1.0.0/16 dev docker0 proto kernel scope link src 10.1.42.1 172.17.8.0/24 dev eth1 proto kernel scope link src 172.17.8.102 192.168.1.1 via 172.17.8.101 dev eth1 proto bird 192.168.1.2 via 172.17.8.101 dev eth1 proto bird 192.168.1.3 via 172.17.8.101 dev eth1 proto bird 192.168.1.4 dev cali32d26ef6fff scope link 192.168.1.5 dev cali333fbba0fff scope link **** Bird command line **** bird -R -s bird.ctl -d -c /config/bird.cfg **** Bird config **** router id 172.17.8.102; log "/var/log/calico/bird.log" all; filter calico_pools { if ( net ~ 192.168.0.0/16 ) then { accept; } else { reject; } } protocol kernel { debug all; learn; # Learn all alien routes from the kernel persist; # Don't remove routes on bird shutdown scan time 2; # Scan kernel routing table every 2 seconds import all; device routes; export all; # Default is export none graceful restart; } protocol device { scan time 2; # Scan interfaces every 2 seconds } protocol direct { debug all; interface -"cali*", "*"; # Exclude cali* but include everything else. } template bgp bgp_template { debug all; description "Connection to BGP peer"; local as 64511; multihop; gateway recursive; import all; export filter calico_pools; next hop self; source address 172.17.8.102; # The local address we use for the TCP connection add paths on; graceful restart; } protocol bgp from bgp_template { neighbor 172.17.8.101 as 64511; } LOG FILE ======== If I send in a SIGHUP to bird on HOST B, I lose the routes to the 192.168.1.4 and .5 on HOST A, and the routes to 192.168.1.1, .2 and .3 on HOST B. Output from the logs on HOST B indicates that these routes are being explicitly removed. Given we have GR turned on, and are persisting kernel routes, I would not have expected this. Logs from HOST B as follow: 2015-05-21 22:52:54 <INFO> Reconfiguration requested by SIGHUP 2015-05-21 22:52:54 <INFO> Reconfiguring 2015-05-21 22:52:54 <TRACE> kernel1: Reconfigured 2015-05-21 22:52:54 <TRACE> direct1: Reconfigured 2015-05-21 22:52:54 <INFO> Removing protocol bgp1 2015-05-21 22:52:54 <TRACE> bgp1: Shutting down 2015-05-21 22:52:54 <TRACE> bgp1: Shutdown requested 2015-05-21 22:52:54 <TRACE> bgp1: State changed to stop 2015-05-21 22:52:54 <TRACE> bgp1: BGP session closed 2015-05-21 22:52:54 <INFO> Adding protocol bgp1 2015-05-21 22:52:54 <TRACE> bgp1: Initializing 2015-05-21 22:52:54 <TRACE> bgp1: Starting 2015-05-21 22:52:54 <TRACE> bgp1: State changed to start 2015-05-21 22:52:54 <TRACE> bgp1 > removed [sole] 192.168.1.1/32 via 172.17.8.101 on eth1 2015-05-21 22:52:54 <TRACE> kernel1 < removed 192.168.1.1/32 via 172.17.8.101 on eth1 2015-05-21 22:52:54 <TRACE> bgp1 > removed [sole] 192.168.1.2/32 via 172.17.8.101 on eth1 2015-05-21 22:52:54 <TRACE> kernel1 < removed 192.168.1.2/32 via 172.17.8.101 on eth1 2015-05-21 22:52:54 <TRACE> bgp1 > removed [sole] 192.168.1.3/32 via 172.17.8.101 on eth1 2015-05-21 22:52:54 <TRACE> kernel1 < removed 192.168.1.3/32 via 172.17.8.101 on eth1 2015-05-21 22:52:54 <TRACE> bgp1: Sending NOTIFICATION(code=6.3) 2015-05-21 22:52:54 <TRACE> bgp1: Down 2015-05-21 22:52:54 <TRACE> bgp1: State changed to down 2015-05-21 22:52:54 <TRACE> bgp1: Started 2015-05-21 22:52:54 <TRACE> bgp1: Connect delayed by 5 seconds 2015-05-21 22:52:54 <INFO> Reconfigured 2015-05-21 22:52:56 <TRACE> kernel1: Scanning routing table 2015-05-21 22:52:56 <TRACE> kernel1: 0.0.0.0/0: [alien] seen 2015-05-21 22:52:56 <TRACE> kernel1: 10.0.2.2/32: [alien] seen 2015-05-21 22:52:56 <TRACE> ... 2015-05-21 22:52:56 <TRACE> kernel1: Pruning table master 2015-05-21 22:52:56 <TRACE> kernel1: 10.0.2.0/24: reinstalling 2015-05-21 22:52:56 <WARN> Netlink: File exists 2015-05-21 22:52:56 <TRACE> kernel1: 10.1.0.0/16: reinstalling 2015-05-21 22:52:56 <WARN> Netlink: File exists 2015-05-21 22:52:56 <TRACE> kernel1: 172.17.8.0/24: reinstalling 2015-05-21 22:52:56 <WARN> ... 2015-05-21 22:52:56 <TRACE> kernel1: Pruning inherited routes 2015-05-21 22:52:58 <TRACE> kernel1: Scanning routing table 2015-05-21 22:52:58 <TRACE> kernel1: 0.0.0.0/0: [alien] seen 2015-05-21 22:52:58 <TRACE> kernel1: 10.0.2.2/32: [alien] seen 2015-05-21 22:52:58 <TRACE> ... 2015-05-21 22:52:58 <TRACE> kernel1: Pruning table master 2015-05-21 22:52:58 <TRACE> kernel1: 10.0.2.0/24: reinstalling 2015-05-21 22:52:58 <WARN> Netlink: File exists 2015-05-21 22:52:58 <TRACE> kernel1: 10.1.0.0/16: reinstalling 2015-05-21 22:52:58 <WARN> Netlink: File exists 2015-05-21 22:52:58 <TRACE> kernel1: 172.17.8.0/24: reinstalling 2015-05-21 22:52:58 <WARN> ... 2015-05-21 22:52:58 <TRACE> kernel1: Pruning inherited routes 2015-05-21 22:52:59 <TRACE> bgp1: Incoming connection from 172.17.8.101 (port 59189) accepted 2015-05-21 22:52:59 <TRACE> bgp1: Sending OPEN(ver=4,as=64511,hold=240,id=ac110866) 2015-05-21 22:52:59 <TRACE> bgp1: Got OPEN(as=64511,hold=240,id=ac110865) 2015-05-21 22:52:59 <TRACE> bgp1: Sending KEEPALIVE 2015-05-21 22:52:59 <TRACE> bgp1: Got KEEPALIVE 2015-05-21 22:52:59 <TRACE> bgp1: BGP session established 2015-05-21 22:52:59 <TRACE> bgp1: Connected to table master 2015-05-21 22:52:59 <TRACE> bgp1: State changed to feed 2015-05-21 22:52:59 <TRACE> bgp1 < filtered out 0.0.0.0/0 via 10.0.2.2 on eth0 2015-05-21 22:52:59 <TRACE> bgp1 < filtered out 10.0.2.2/32 dev eth0 2015-05-21 22:52:59 <TRACE> bgp1 < filtered out 10.0.2.0/24 dev eth0 2015-05-21 22:52:59 <TRACE> bgp1 < filtered out 10.1.0.0/16 dev docker0 2015-05-21 22:52:59 <TRACE> bgp1 < added 192.168.1.4/32 dev cali32d26ef6fff 2015-05-21 22:52:59 <TRACE> bgp1 < added 192.168.1.5/32 dev cali333fbba0fff 2015-05-21 22:52:59 <TRACE> bgp1 < filtered out 172.17.8.0/24 dev eth1 2015-05-21 22:52:59 <TRACE> bgp1: State changed to up 2015-05-21 22:52:59 <TRACE> bgp1: Sending UPDATE 2015-05-21 22:52:59 <TRACE> bgp1: Sending END-OF-RIB 2015-05-21 22:52:59 <TRACE> bgp1: Got UPDATE 2015-05-21 22:52:59 <TRACE> bgp1 > added [best] 192.168.1.1/32 via 172.17.8.101 on eth1 2015-05-21 22:52:59 <TRACE> bgp1 < rejected by protocol 192.168.1.1/32 via 172.17.8.101 on eth1 2015-05-21 22:52:59 <TRACE> kernel1 < added 192.168.1.1/32 via 172.17.8.101 on eth1 2015-05-21 22:52:59 <TRACE> bgp1 > added [best] 192.168.1.2/32 via 172.17.8.101 on eth1 2015-05-21 22:52:59 <TRACE> bgp1 < rejected by protocol 192.168.1.2/32 via 172.17.8.101 on eth1 2015-05-21 22:52:59 <TRACE> kernel1 < added 192.168.1.2/32 via 172.17.8.101 on eth1 2015-05-21 22:52:59 <TRACE> bgp1 > added [best] 192.168.1.3/32 via 172.17.8.101 on eth1 2015-05-21 22:52:59 <TRACE> bgp1 < rejected by protocol 192.168.1.3/32 via 172.17.8.101 on eth1 2015-05-21 22:52:59 <TRACE> kernel1 < added 192.168.1.3/32 via 172.17.8.101 on eth1 2015-05-21 22:52:59 <TRACE> bgp1: Got UPDATE 2015-05-21 22:52:59 <TRACE> bgp1: Got END-OF-RIB 2015-05-21 22:53:00 <TRACE> kernel1: Scanning routing table 2015-05-21 22:53:00 <TRACE> kernel1: 0.0.0.0/0: [alien] seen 2015-05-21 22:53:00 <TRACE> kernel1: 10.0.2.2/32: [alien] seen 2015-05-21 22:53:00 <TRACE> kernel1: 192.168.1.1/32: seen 2015-05-21 22:53:00 <TRACE> kernel1: 192.168.1.2/32: seen 2015-05-21 22:53:00 <TRACE> kernel1: 192.168.1.3/32: seen 2015-05-21 22:53:00 <TRACE> ... 2015-05-21 22:53:00 <TRACE> kernel1: Pruning table master 2015-05-21 22:53:00 <TRACE> kernel1: 10.0.2.0/24: reinstalling 2015-05-21 22:53:00 <WARN> Netlink: File exists 2015-05-21 22:53:00 <TRACE> kernel1: 10.1.0.0/16: reinstalling 2015-05-21 22:53:00 <WARN> Netlink: File exists 2015-05-21 22:53:00 <TRACE> kernel1: 172.17.8.0/24: reinstalling 2015-05-21 22:53:00 <WARN> ... 2015-05-21 22:53:00 <TRACE> kernel1: Pruning inherited routes 2015-05-21 22:53:02 <TRACE> kernel1: Scanning routing table 2015-05-21 22:53:02 <TRACE> kernel1: 0.0.0.0/0: [alien] seen 2015-05-21 22:53:02 <TRACE> kernel1: 10.0.2.2/32: [alien] seen 2015-05-21 22:53:02 <TRACE> kernel1: 192.168.1.1/32: seen 2015-05-21 22:53:02 <TRACE> kernel1: 192.168.1.2/32: seen 2015-05-21 22:53:02 <TRACE> kernel1: 192.168.1.3/32: seen 2015-05-21 22:53:02 <TRACE> ... 2015-05-21 22:53:02 <TRACE> kernel1: Pruning table master 2015-05-21 22:53:02 <TRACE> kernel1: 10.0.2.0/24: reinstalling 2015-05-21 22:53:02 <WARN> Netlink: File exists 2015-05-21 22:53:02 <TRACE> kernel1: 10.1.0.0/16: reinstalling 2015-05-21 22:53:02 <WARN> Netlink: File exists 2015-05-21 22:53:02 <TRACE> kernel1: 172.17.8.0/24: reinstalling 2015-05-21 22:53:02 <WARN> ... 2015-05-21 22:53:02 <TRACE> kernel1: Pruning inherited routes 2015-05-21 22:53:04 <TRACE> kernel1: Scanning routing table 2015-05-21 22:53:04 <TRACE> kernel1: 0.0.0.0/0: [alien] seen 2015-05-21 22:53:04 <TRACE> kernel1: 10.0.2.2/32: [alien] seen 2015-05-21 22:53:04 <TRACE> kernel1: 192.168.1.1/32: seen 2015-05-21 22:53:04 <TRACE> kernel1: 192.168.1.2/32: seen 2015-05-21 22:53:04 <TRACE> kernel1: 192.168.1.3/32: seen 2015-05-21 22:53:04 <TRACE> ... 2015-05-21 22:53:04 <TRACE> kernel1: Pruning table master 2015-05-21 22:53:04 <TRACE> kernel1: 10.0.2.0/24: reinstalling 2015-05-21 22:53:04 <WARN> Netlink: File exists 2015-05-21 22:53:04 <TRACE> kernel1: 10.1.0.0/16: reinstalling 2015-05-21 22:53:04 <WARN> Netlink: File exists 2015-05-21 22:53:04 <TRACE> kernel1: 172.17.8.0/24: reinstalling 2015-05-21 22:53:04 <WARN> ... 2015-05-21 22:53:04 <TRACE> kernel1: Pruning inherited routes 2015-05-21 22:53:06 <TRACE> kernel1: Scanning routing table 2015-05-21 22:53:06 <TRACE> kernel1: 0.0.0.0/0: [alien] seen 2015-05-21 22:53:06 <TRACE> kernel1: 10.0.2.2/32: [alien] seen 2015-05-21 22:53:06 <TRACE> kernel1: 192.168.1.1/32: seen 2015-05-21 22:53:06 <TRACE> kernel1: 192.168.1.2/32: seen 2015-05-21 22:53:06 <TRACE> kernel1: 192.168.1.3/32: seen 2015-05-21 22:53:06 <TRACE> ... 2015-05-21 22:53:06 <TRACE> kernel1: Pruning table master 2015-05-21 22:53:06 <TRACE> kernel1: 10.0.2.0/24: reinstalling 2015-05-21 22:53:06 <WARN> Netlink: File exists 2015-05-21 22:53:06 <TRACE> kernel1: 10.1.0.0/16: reinstalling 2015-05-21 22:53:06 <WARN> Netlink: File exists 2015-05-21 22:53:06 <TRACE> kernel1: 172.17.8.0/24: reinstalling 2015-05-21 22:53:06 <WARN> ... 2015-05-21 22:53:06 <TRACE> kernel1: Pruning inherited routes 2015-05-21 22:53:08 <TRACE> kernel1: Scanning routing table 2015-05-21 22:53:08 <TRACE> kernel1: 0.0.0.0/0: [alien] seen 2015-05-21 22:53:08 <TRACE> kernel1: 10.0.2.2/32: [alien] seen 2015-05-21 22:53:08 <TRACE> kernel1: 192.168.1.1/32: seen 2015-05-21 22:53:08 <TRACE> kernel1: 192.168.1.2/32: seen 2015-05-21 22:53:08 <TRACE> kernel1: 192.168.1.3/32: seen 2015-05-21 22:53:08 <TRACE> ... 2015-05-21 22:53:08 <TRACE> kernel1: Pruning table master 2015-05-21 22:53:08 <TRACE> kernel1: 10.0.2.0/24: reinstalling 2015-05-21 22:53:08 <WARN> Netlink: File exists 2015-05-21 22:53:08 <TRACE> kernel1: 10.1.0.0/16: reinstalling 2015-05-21 22:53:08 <WARN> Netlink: File exists 2015-05-21 22:53:08 <TRACE> kernel1: 172.17.8.0/24: reinstalling 2015-05-21 22:53:08 <WARN> ... 2015-05-21 22:53:08 <TRACE> kernel1: Pruning inherited routes

2 2

OSPF: how distance parameter is calculated ?
by Piotr 22 May '15

22 May '15

Hi, I have two ospf routers in the same vlan and subnet but with different metrics (20 vs 50). I'd like to prefer router with metric=20 but distance parameter is more prefered. How can i change distance parameter or just ? thanks for help bird> show ospf state area 0.0.0.133 router 10.10.10.252 distance 10 network 8.8.2.0/28 metric 1 network 20.20.20.240/28 metric 1 nssa-ext 0.0.0.0/0 metric 50 router 10.10.10.254 distance 11 network 20.20.20.240/28 metric 1 stubnet 8.8.2.0/28 metric 1 nssa-ext 0.0.0.0/0 metric 20 server config: protocol ospf MyOSPF { tick 2; rfc1583compat yes; area 0.0.0.133 { nssa; interface "bond0" { hello 10; priority 0; type nbma; neighbors { 10.10.10.252 eligible; 10.10.10.254 eligible; }; }

1 0

OSPF route selection
by Thomas Goldberg 22 May '15

22 May '15

Hello, we're using OSPF for anycast routing and came across a small problem. We've a BIRD v1.4.4 router which sits in area 0 and 16. Here's the relevant state information (10.236.144.144/32 is announced from two different routers in two areas): area 0.0.0.0 router 10.236.144.241 distance 33 external 10.236.144.144/32 metric 1 area 0.0.0.16 router 10.17.224.253 distance 111 external 10.236.144.144/32 metric 1 The route via area 16 is considered best: 10.236.144.144/32 via 10.176.3.29 on vlan542 [o_internal 2014-10-07 16:49:56] * E1 (150/112) [10.17.224.253] Given that both E1 routes are reachable via intra-area paths. We're wondering why the path via area 16 (higher costs than area 0) is chosen. Is this the intended behavior? Is there any way to make bird prefer routes via a specific/backbone area in a situation like this? Best Regards, Freddy

4 4