September 2015 - Bird-users

Device protocol not recognizing interface address change
by Bernardo Figueiredo 29 Sep '15

29 Sep '15

Hello, When restarting some routers at the institution I work, sometimes bird doesn't start announcing any routes until we either restart bird or restart the device protocol using birdc. I think this happens due to the init scripts responsible for setting the network up finishing before the interfaces are fully configured(without the ip address set up), which allows for the init scripts dependent of the network init script, like bird, to start running. The problem is that bird detects that the interfaces are there, but doesn't recognize that the machine is configured with ip addresses(because the interfaces aren't fully configured yet) in the networks that it is announcing, so it doesn't announce the routes. When this happens: "bird> show ospf (...) Area networks: 10.3.0.0/16 Advertise 10.0.0.0/16 Advertise (...) " ( The problem is that the Area networks aren't active). After restarting the bird process, the output becomes correct(because now bird is starting with the interfaces fully configured): "bird> show ospf Area networks: 10.3.0.0/16 Advertise Active 10.0.0.0/16 Advertise Active " We have the device protocol to scan every 10 seconds in our bird.conf: "protocol device { scan time 10; }" I think that even though when bird first starts it shouldn't immediately start announcing(because it didn't see that the interfaces ip addresses), it should after 10 seconds when it scans again, because then the interfaces are already fully configured. For example, when radvd starts it complains that the interfaces don't have ip addresses configured, so it checks every second for the interfaces until they are fully configured, and the starts running correctly. Our current working workaround is make the networking init script wait for some time before exiting, meaning that when the init dependents start executing, the interfaces are already fully configured. This might work for the machine startup, but it doesn't solve the problem when we add a new ip address in a new network to an already existing interface and make bird start announcing that network without restarting bird (or the interface). I haven't checked that the same behaviour described above happens in this situation, but it should. If you want me to try it I can. If I haven't explained some parts clearly just ask and I'll try to explain it better. Also, if you need any configuration details just ask. This problems happens in both bird "1.4.5-1~bpo70+1" and "1.5.0-4" distributed by Debian. So, my question is, shouldn't the Device protocol scan update see that the ip addresses of an interface have changed and if so, start announcing the route. Thank you, Bernardo Figueiredo

3 11

Fwd: bird-bug (cpu load 100%)
by Мамонов Павел 24 Sep '15

24 Sep '15

Good afternoon, Faced with the problem of initialization, if the option is: "protocol device {scan time of 10}" the server hangs with 100% CPU-loading, if you remove this option the server boots normally. You could not tell in what could be the problem. Server - 3.18.21-Gentoo, ixgbe - 4.1.2 (10G SFP) -- С уважением, Мамонов Павел, сетевой администратор ООО "Астрателком" тел. (099)2419158 г.Одесса, ул. Бугаевская, 21/23 e-mail: pavel.ma(a)astra.od.ua

1 0

RIP v2 'router id' significance
by Mark Trumpold 22 Sep '15

22 Sep '15

Hello, In a rip domain with multiple routers in a hub/star configuration, is is possible/advisable not to specify a ‘router id’ in the router configs? Thanks in advance, Mark T.

2 1

Bird BGP issue over stringswan
by Ajay Raut ( Tech Ops ) 21 Sep '15

21 Sep '15

Hi, My setup is BGP over a ipsec tunnel. Most of the time it works fine but in between on config soft reload, it goes into a error state. So its intermittent issue where sometime it works. Debug logs show bad BGP as error but same configuration starts working intermittently, otherside of the bird is Juniper SRX endpoint Log error message are: 015-09-21 16:32:22 <TRACE> evpn: Connecting to 10.11.201.1 from local address 10.11.201.13 2015-09-21 16:32:24 <TRACE> evpn: Connected 2015-09-21 16:32:24 <TRACE> evpn: Sending OPEN(ver=4,as=65529,hold=240,id=0a0bc90b) 2015-09-21 16:32:25 <TRACE> evpn: Got OPEN(as=0,hold=90,id=0a54c804) 2015-09-21 16:32:25 <RMT> evpn: Error: Bad peer AS: 0 2015-09-21 16:32:25 <TRACE> evpn: State changed to stop 2015-09-21 16:32:25 <TRACE> evpn: Sending NOTIFICATION(code=2.2) 2015-09-21 16:32:25 <TRACE> evpn: Down 2015-09-21 16:32:25 <TRACE> evpn: State changed to down any help on this will be very useful. Thanks, Ajay

1 0

OSPF export/import default route filter problem
by LU 20 Sep '15

20 Sep '15

Hi, I have 4 routers connected like this. (10.4.4.1/24) (10.4.4.4.2/24) R1 R2 \ / \ / SWITCH / \ / \ R3 R4 (10.4.4.3/24) (10.4.4.4/24) I export a default route (0.0.0.0/0) from R1 and R2 with an ospf_metric1 = 100.. At R3, in an import filter I set the ospf_metric1 of R1's default route to 10. At R4, in an import filter I set the ospf_metric1 of R2's default route to 10. What I expect is that R3's routing table is going to contain 0.0.0.0/0 via R1. and likewise R4's routing table is going to contain 0.0.0.0/0 via R2. Unfortunately it doesn't happen and both R3's and R4's routing table has 0.0.0.0/0 via R2. Here's a config for router R1 (R2 is identical except for router id). router id 10.4.4.1 protocol kernel { export all; } protocol direct { } protocol device { scan time 10; } protocol static { route 0.0.0.0/0 via 123.123.123.1; #vtnet0 } protocol ospf { tick 2; rfc1583compat yes; export filter { if net = 0.0.0.0/0 then { ospf_metric1 = 100; accept; } reject; } area 0.0.0.0 { interface "vtnet1" { dead count 4; type broadcast; } } } Here's a config for router R3 (R4 is identical except for router id and if statement's ospf_router_id) router id 10.4.4.3 protocol kernel { export all; } protocol direct { } protocol device { scan time 10; } protocol static { } protocol ospf { tick 2; rfc1583compat yes; import filter { if ospf_router_id = 10.4.4.1 then { if net = 0.0.0.0/0 then { ospf_metric1 = 10; } } accept; } area 0.0.0.0 { interface "vtnet0" { dead count 4; type broadcast; } interface "ng*" { stub yes; } } } When I place a print statement in the import filter at the very top: import filter { print "router_id: ", ospf_router_id, " net: ", net; if ospf_router_id = 10.4.4.1 then { if net = 0.0.0.0/0 then { ospf_metric1 = 10; } } For R3 I see: router_id: 10.4.4.3 net: 10.4.4.0/24 router_id: 10.4.4.2 net: 0.0.0.0/0 router_id: 10.4.4.2 net: 10.4.4.0/24 For R4 I see: router_id: 10.4.4.4 net: 10.4.4.0/24 router_id: 10.4.4.2 net: 0.0.0.0/0 router_id: 10.4.4.2 net: 10.4.4.0/24 So router R1 (10.4.4.1) is not seen by the import filters, as such R2 is selected as the default route for both R3 and R4. How could i fix it? Thank you..

2 2

pmacct and BIRD on the same box
by Charles van Niman 20 Sep '15

20 Sep '15

Hello, I am looking to feed BGP data into pmacct on a linux router I have running BIRD. Right now, BIRD runs iBGP to five other boxes [quagga/BIRD mix], on one IP [172.22.150.126], assigned to the loopback interface, and a handful of eBGP peers on another IP [172.22.150.127]. I see two practical approaches to this, but I am all ears for more! My original plan was to just put pmacct's BGP peer IP on a separate loopback IP [172.22.150.119], and peer between BIRD 172.22.150.126:179 and pmacct 172.22.150.119:179, however since I am using two different listening IPs in BIRD, it binds to 0.0.0.0. I attempted to use the global listen bgp option, but it seems I am forced to pick between eBGP, iBGP, running multiple BIRD instances, or renumbering sessions, which I want to avoid :( Another way around this seemed to be to use a different TCP port for pmacct to bind to, however BIRD doesn't seem to support per-neighbor port settings. Maybe I have just missed this feature, if so hooray! Please let me know any thoughts or ideas you have on this, I am open to anything, including how I may have worded this better. Regards, Charles

2 2

HA setup (v 1.4.5)
by Jigar Mehta 17 Sep '15

17 Sep '15

I have BIRD installed to test working with a custom forwarding plane. The forwarding plane supports HA in the following way : - Syncs up routing tables - Provides millisecond failover (since routing tables are synced up) - Shared MAC - At any given time only one of the appliance is actively receiving and processing packets. - Both appliances have BIRD running (rte_notify sends route updates to forwarding plane) and a small wrapper that processes forwarding table routing updates (static routes , etc) Problem : At any point of time, the forwarding plane has correct set of routes on both appliances but bird's routing tables are out of sync since only the active appliance is processing packets (eg : OSPF LSA). So when we failover, BIRD running on secondary appliance does not have any routes until it learns them through route updates (since now secondary appliance is processing the LSA's ). This can also result in stale routes in forwarding plane. How do we support failover condition in BIRD ? (both OSPF and BGP (multiple instances)) I would highly appreciate some thoughts on this issue. I did think about BFD but then currently (if I interpreted it correctly supports only a single instance of OSPF or BGP). Graceful recovery is only implemented for BGP so not completely usable. -- Jigar Mehta

2 2

[Patch] Let birdc output errors to stderr
by Christian Tacke 17 Sep '15

17 Sep '15

Hi, We (Knorrie, andi, and me) realized, that birdc outputs server errors to stdout much like normal server output. When scripting birdc, it can be helpful to have those on stderr instead. Simple use case: birdc CMD >/dev/null If everything is fine, no output at all. If something goes wrong, output! There are a few aspects: 1. Is this useful? Hopefully. If you think this is a studpid idea, pleas explain! 2. Should this be the default (in an upcoming version)? I don't know, how many non humans depend on *all* output going to stdout and neglect stderr? Ignoring stderr IMHO is a design flaw. But well, this is a question of backward compatibility. NOTE: Something should be added to the ChangeLog, so people are not too surprised. 3. If the answer to (2) is "Need backward compatibility": Do we need some --enable-stderr then? Cheers Christian -- www.cosmokey.com

2 2

Running Bird bgp through GRE tunnel
by Ajay Raut ( Tech Ops ) 17 Sep '15

17 Sep '15

Hi, I m trying to run BGP through the GRE tunnel, Tunnel is working fine. *Though i am seeing following error logs on bird.* 2015-09-07 20:29:34 <TRACE> vpn: Connecting to 10.200.206.250 from local address 10.200.206.249 2015-09-07 20:29:34 <TRACE> vpn: Connection lost (No route to host) *My bird.conf file has a follwing configuration for BGP through the GRE tunnel.* protocol bgp vpn { local as 65530; source address 10.200.206.249; neighbor 10.200.206.250 as 65531; import all; } *and following is the tunnel config on interface file, Tunnel is verified and working pretty fine.* auto gre-vpn iface gre-vpn inet tunnel address 10.200.206.249 mode gre endpoint 10.200.206.6 dstaddr 10.200.206.250 local 10.200.206.4 ttl 255 netmask 255.255.255.252 *Ping works* root@fk-cloud-none-210121:/home/iaas# ping 10.200.206.250 -I 10.200.206.249 PING 10.200.206.250 (10.200.206.250) from 10.200.206.249 : 56(84) bytes of data. 64 bytes from 10.200.206.250: icmp_seq=1 ttl=64 time=19.5 ms 64 bytes from 10.200.206.250: icmp_seq=2 ttl=64 time=19.4 ms 64 bytes from 10.200.206.250: icmp_seq=3 ttl=64 time=19.4 ms Please let me know what is the issue with the bird.conf here which i might have missed. Thanks, Ajay -- ------------------------------------------------------------------------------------------------------------------------------------------ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although Flipkart has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments

4 6

BGP add-path with Juniper
by Stanislaw Datskevich 10 Sep '15

10 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, list. I'm trying to use BGP add-path feature in BIRD connected my Juniper router, but I have no luck with it. Here is my BIRD (version 1.5.0) config: template bgp probe { multihop; import where avoid_martians(); export none; import keep filtered; add paths rx; } protocol bgp mh1 from probe { local as 65530; neighbor xx.xx.146.2 as 65530; # Juniper's address } Here is Juniper's bgp group config: show configuration protocols bgp group BGP-PROBE type internal; multihop; import DropEverything; family inet { unicast { add-path { send { prefix-policy accept-all; path-count 6; } } } } export accept-all; peer-as 65530; neighbor xx.xx.146.23; In this configuration, BGP sessions establishes without any problem, but Juniper believes that BIRD doesn't support AddPath feature: # show bgp neighbor xx.xx.146.23 | match AddPath Peer does not support Addpath When I try to enable capability advertisement in BIRD config by setting "capabilities on;" switch, Juniper refuses to establish BGP session with log message: Sep 10 16:39:46 mx480 rpd[1632]: bgp_parse_open_options: peer xx.xx.146.23+60740 (proto): Bad capability length 1, when 0 left Sep 10 16:39:46 mx480 rpd[1632]: bgp_get_open:2666: NOTIFICATION sent to xx.xx.146.23+60740 (proto): code 2 (Open Message Error) subcode 7 (unsupported capability) I'll be grateful for any advice. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV8YpUAAoJEIfphUzaztQxpYkP/RbXvsTNU6+MqFmg9SPenr9a xvwh92knJ2AVw8Px0SLlkMjO+5F3nHcK4gxf+LaO/ArMGMlECS5mhbZkbEpI2zAA jkIt5cfOjaqtsBPVLcc3BrCv9zKxKw2GSG9G89ZEwlDuwIgjlub0RjE4cff5jJNr kIffKMQ7yVCKy+bscSj8k7vghDJq3MG/rvI42GyjkVsxMSede2uo9Ah584k/95Vi WElWV/y43v/xiIk3Yy+VsYcjMQszY6PUH7YQSRQ+h6gUVY3YOgK0i4Ef96bEhn+W cmcpfmT9ppR3lUwsnCHLzcle+/u54vvRr1RHdcAQQ4LmVcCRms6a9WLQXUX6mzCd bWm9AwfeYbjKtYixkVLGNxOMkMJfUp2XlJpFMGUE4qv8I7P0quN5G+bH26nrzSfA aabq/qzj3npBrne6xo1zy4DkOnNaO/r4az5tuegYgj3zQo9MkQCCXLYialgz/O0j R2CgjzqbiNlsfxRAJ31qKUWnh1Ka4NlHjB9FKG1NDBX5ygvWuOoR/HsIGRQkNAav uKXyxcTMewTdV3dD13HIN+ia4Ln0gIgRDkMcy/osajX4Yoxu08Wu+yowYXW1+ea8 TLSp0KTtx0nuiQJzlgz6hCP/K9QA5r9L1lCb35NR7P8Y/LQ30eGL/kR7Z+q7Ycgf 5MAiCEFRv3TeJytXCfCf =MX7J -----END PGP SIGNATURE-----

2 2