December 2018 - Bird-users

ospf with bfd ecmp conf
by Alon Dotan 11 Dec '18

11 Dec '18

Hey All, Im trying to configure the folowing topology: lns box (multiple ppp devices that connect and disconnect) -> multiple default gw (gw load balance) the issue is if one of the multiple gw crash I got routing blackhole... Im trying to configurefd to delete dead peers from the osp routing table, this is my conf: debug protocols all; log "/var/log/bird.log" all; router id 10.10.11.10; protocol device { scan time 1; # Scan interfaces every 10 seconds export all; } protocol direct { interface "ppp*"; export all; } protocol kernel { scan time 1; # Scan kernel routing table every 20 seconds export all; # Default is export none import all; kernel table 100; learn; persist; } protocol bfd { interface "eth1" { min rx interval 20 ms; min tx interval 50 ms; idle tx interval 300 ms; }; } protocol ospf MyOSPF { ecmp yes; export filter { if (net ~ 10.10.11.0/24) then reject; accept;}; # export all; import all; merge external; area 0 { interface "eth1" { hello 5; bfd yes; }; }; } protocol static { import all; } routs learned by ospf: [root@lns-testing-01 centos]# ip r show table 100 default proto bird nexthop via 10.10.11.11 dev eth1 weight 1 nexthop via 10.10.11.12 dev eth1 weight 1 [root@lns-testing-01 centos]# bfd status: [root@lns-testing-01 centos]# birdc show bfd sessions BIRD 1.4.5 ready. bfd1: IP address Interface State Since Interval Timeout 10.10.11.11 eth1 Up 08:09:55 0.050 0.250 10.10.11.12 eth1 Down 08:10:41 0.300 0.000 what Im missing? Thanks,

1 0

segfault when adding OSPF virtual link on Bird 1.6.4
by Cybertinus 10 Dec '18

10 Dec '18

Hello everybody, Today I was experimenting with a Bird setup. All the Bird machines are CentOS 7.6 VMs running in Virtualbox on my laptop. When I add an OSPF virtual link to hook up two area 0's together I get a segfault of Bird 1.6.4 itself. All the links between the VMs are defined as "Internal Network" links. Each connection between routers got it's own internal network, so there should be no overlap between those connections. Steps to reproduce: 1. Create a bird.conf with the following contents specified in the attached bird.conf 2. Start Bird 3. Add the following line to the area 1 config: virtual link 2.2.2.2; 4. Run `birdc configure` 5. Observe the following error in your syslog: Dec 8 21:01:35 r3 kernel: bird[3469]: segfault at 32 ip 0000000000429fe0 sp 00007fff599d3350 error 4 in bird[400000+73 I've ran Bird 1.6.4 in a gdb session with the debug symbols installed and I created a stack trace after the crash. This gives the output which can be found in the attached gdb.txt. What is interesting to note is that the segfault only occurs when I reconfigure Bird. I can start it just fine right after the crash and the OSPF sessions come back online and everything. I hope this gives some useful information about what is happening. If you need any more information please don't hesitate to ask. It is a test network, so I can tell you absolutely everything about it, nothing is a company secret or something like that :). Kind regards, Cybertinus

2 3

FLAPPING PEER
by Rwakagabo Janvier 10 Dec '18

10 Dec '18

Hello bird user I am using bird 1.4.0 version on route server (RS) to peer on IXP players, One of the peer is flapping with this error Can you help to understand the cause. Regards, Janvier R.

1 0

Recommended way to shutdown a working BGP session -- ordered bgp session stop -- bgp session shutdown
by Francis Brosnan Blázquez 10 Dec '18

10 Dec '18

Hello. We are using bird with several upstream providers, all of them with a share of traffic. We are in the process of shutting down one of them but we are unsure how to proceed to minimize loss of traffic. We have been reading and looking for general recommendations but it is not clear (besides using graceful shutdown which is not supported by the upstream we want to shutdown). We have been looking at mailing list but we haven't found anything treating this matter. So far, solutions we have come up are: 1) Use AS-path prepend to increase metric on the uptstream to be shutted down and once nearly no traffic comes in through that link, shutdown BGP and unplug. Something like: export filter { if source = RTS_STATIC then { # Export only static routes # Assign our community bgp_community.add((65000,64501)); # Artificially increase path length # by advertising local AS number twice if bgp_path ~ [= 65000 =] then bgp_path.prepend(65000); bgp_path.prepend(65000); accept; } reject; }; 2) Another solution is to just shutdown BGP session but leave upstream connected and configured (so outdated routers we still reach us...). 3) And the obvious, just shutdown BGP session and unplug the cable. It would be great to know your opinion and what's the recommended way to proceed. What do you think? Many thanks Best Regards. -- Francis Brosnan Blázquez <francis.brosnan(a)aspl.es> ASPL -- Advanced Software Production Line, S.L.

2 2

iBGP stuck in connect state
by Brooks Swinnerton 06 Dec '18

06 Dec '18

Hello, I'm having trouble configuring two BIRD instances to talk to one another over a wireguard tunnel with iBGP. They both stay in a `Connect` state. With debug <protocol> all, I only see: ``` Dec 05 23:31:32 border bird[3460]: foo: Connecting to 169.254.2.2 from local address 169.254.3.3 Dec 05 23:33:19 border bird[3460]: foo: Connecting to 169.254.2.2 from local address 169.254.3.3 Dec 05 23:35:13 border bird[3460]: foo: Connecting to 169.254.2.2 from local address 169.254.3.3 ``` The wireguard tunnel is up, and each side can ping the other: ``` PING 169.254.2.2 (169.254.2.2) 56(84) bytes of data. 64 bytes from 169.254.2.2: icmp_seq=1 ttl=64 time=66.7 ms 64 bytes from 169.254.2.2: icmp_seq=2 ttl=64 time=66.6 ms 64 bytes from 169.254.2.2: icmp_seq=3 ttl=64 time=66.8 ms ``` ``` PING 169.254.3.3 (169.254.3.3) 56(84) bytes of data. 64 bytes from 169.254.3.3: icmp_seq=1 ttl=64 time=66.5 ms 64 bytes from 169.254.3.3: icmp_seq=2 ttl=64 time=66.2 ms 64 bytes from 169.254.3.3: icmp_seq=3 ttl=64 time=66.3 ms ``` I can even see some BGP traffic when doing a tcpdump: ``` 23:44:16.487852 ip: (tos 0xc0, ttl 64, id 40780, offset 0, flags [DF], proto TCP (6), length 60) 169.254.3.3.53585 > 169.254.2.2.179: Flags [S], cksum 0x5930 (incorrect -> 0x61e7), seq 4023371188, win 27600, options [mss 1380,sackOK,TS val 891392 ecr 0,nop,wscale 7], length 0 23:44:16.989732 ip: (tos 0xc0, ttl 64, id 29307, offset 0, flags [DF], proto TCP (6), length 60) 169.254.2.2.46081 > 169.254.3.3.179: Flags [S], cksum 0x3ae5 (correct), seq 156366469, win 27600, options [mss 1380,sackOK,TS val 889856 ecr 0,nop,wscale 7], length 0 23:44:18.535863 ip: (class 0xc0, flowlabel 0xe9696, hlim 64, next-header TCP (6) payload length: 40) fd00:169:254:3::3.47019 > fd00:169:254:2::2.179: Flags [S], cksum 0x01b4 (incorrect -> 0x5b17), seq 1562824692, win 27200, options [mss 1360,sackOK,TS val 891904 ecr 0,nop,wscale 7], length 0 23:44:33.117481 ip: (tos 0xc0, ttl 64, id 29308, offset 0, flags [DF], proto TCP (6), length 60) 169.254.2.2.46081 > 169.254.3.3.179: Flags [S], cksum 0x2b25 (correct), seq 156366469, win 27600, options [mss 1380,sackOK,TS val 893888 ecr 0,nop,wscale 7], length 0 23:44:37.610488 ip: (class 0xc0, flowlabel 0xeaf06, hlim 64, next-header TCP (6) payload length: 40) fd00:169:254:2::2.36355 > fd00:169:254:3::3.179: Flags [S], cksum 0x243b (correct), seq 476210459, win 27200, options [mss 1360,sackOK,TS val 895010 ecr 0,nop,wscale 7], length 0 23:44:38.621468 ip: (class 0xc0, flowlabel 0xd3b4f, hlim 64, next-header TCP (6) payload length: 40) fd00:169:254:2::2.36355 > fd00:169:254:3::3.179: Flags [S], cksum 0x233d (correct), seq 476210459, win 27200, options [mss 1360,sackOK,TS val 895264 ecr 0,nop,wscale 7], length 0 23:44:40.637418 ip: (class 0xc0, flowlabel 0xd41b0, hlim 64, next-header TCP (6) payload length: 40) fd00:169:254:2::2.36355 > fd00:169:254:3::3.179: Flags [S], cksum 0x2145 (correct), seq 476210459, win 27200, options [mss 1360,sackOK,TS val 895768 ecr 0,nop,wscale 7], length 0 23:44:44.893305 ip: (class 0xc0, flowlabel 0xcc08e, hlim 64, next-header TCP (6) payload length: 40) fd00:169:254:2::2.36355 > fd00:169:254:3::3.179: Flags [S], cksum 0x1d1d (correct), seq 476210459, win 27200, options [mss 1360,sackOK,TS val 896832 ecr 0,nop,wscale 7], length 0 ``` The bird.conf file is identical between hosts can be found in: https://gist.github.com/bswinnerton/9ffa236a55f120ba9491658ae74a841a. Does anything seem amiss? What's odd is that I can establish iBGP connections with other BGP routers that are not running BIRD with the exact same iBGP peer configuration. $ sudo birdc -v 0001 BIRD 2.0.2 ready.

2 2

Static routes after `configure` CLI command
by Vladimir Osmolovskiy 04 Dec '18

04 Dec '18

Hello! In CLI command line, after 'configure' command, pointer to static routes in neighbor structure not valid. This patch delete heighbors. Perhaps there is a better solution. diff --git a/nest/neighbor.c b/nest/neighbor.c index f8159d3..7fc449a 100644 --- a/nest/neighbor.c +++ b/nest/neighbor.c @@ -379,6 +379,37 @@ neigh_prune_one(neighbor *n) sl_free(neigh_slab, n); } . + +void +neigh_prune_proto(struct proto *p) +{ + neighbor *n; + node *m; + int i; + + for(i=0; i<NEIGH_HASH_SIZE; i++) + WALK_LIST_DELSAFE(n, m, neigh_hash_table[i]) + if (n->proto == p ) + { + rem_node(&n->n); + if (n->scope >= 0) + rem_node(&n->if_n); + sl_free(neigh_slab, n); + } + WALK_LIST_DELSAFE(n, m, sticky_neigh_list) + if (n->proto == p ) + { + rem_node(&n->n); + if (n->scope >= 0) + rem_node(&n->if_n); + sl_free(neigh_slab, n); + } +} + + + + + /** * neigh_prune - prune neighbor cache * diff --git a/proto/static/static.c b/proto/static/static.c index 849067b..8a7d1a0 100644 --- a/proto/static/static.c +++ b/proto/static/static.c @@ -559,6 +559,8 @@ static_reconfigure(struct proto *p, struct proto_config *new) WALK_LIST(r, o->other_routes) static_match(p, r, n); . + neigh_prune_proto(p); + /* Now add all new routes, those not changed will be ignored by static_install() */ WALK_LIST(r, n->iface_routes) {

2 4

Help: BGP neighbor
by Arvin Gan 04 Dec '18

04 Dec '18

Hello All, I notice that if BGP is directly connected, when BGP started, the bgp_start_locked() is called and using neigh_find2() to lookup the neighbor. In neigh_find2(), bird will loop iface_list and comparing the remote IP address with the IP prefix of interface, checking whether is the subnet. Now, I have a question that why not using route table to find the neighbor ? Since I have one case that make me have some confusion. Test Case: DUT1 DUT2 DUT3 lo interface 2000::1111/128 , interface3 3000:1::8/112 <-----------------------> interface4 3000:1::9/112, lo interface: 2000::2222/128 interface1 2000::2/112 <------>interface2: 2000::1/112 suppose that the route table configuration are all reachable. 1. Anyone known the topology connection is normal or correct ? 2. If yes, when create BGP peer with loopback interface 2000::1111, remote IP 2000::2222. 3. BGP peer will use 2000::2222 to compare with interface prefix list on DUT2, find the neighbor interface2 with prefix 2000::1/112 [interface2 on DUT2], and consider as directly connected. BUT, actually, BGP peer TCP connection is not directly connected, and TCP connection don't using interface2 on DUT2, but using interface3 on DUT2 to connect interface4 of DUT3. Best Regards, Arvin Gan

1 0

OSPF in VRF stuck in Alone
by James Oakley 03 Dec '18

03 Dec '18

I am trying to get OSPF working via OSPF and it looks like BIRD is ignoring OSPF packets coming in on the VRF interfaces. As far as I can tell from the documentation, I have all of the pieces in place, but the protocol is stuck in "Alone". The kernel version is 4.18.12, and I have the "vrf" parameter set on the kernel and ospf protocols. Here is my config: ipv4 table foo_ipv4; protocol kernel kernel_foo { vrf "foo"; kernel table 8194; learn; scan time 10; ipv4 { import all; export all; preference 1100; table foo_ipv4; }; } protocol direct direct_foo { vrf "foo"; ipv4 { table foo_ipv4; }; interface "foo"; interface "vl-foo"; interface "vx-foo"; } protocol ospf ospf_foo { vrf "foo"; router id 100.63.16.4; area 0.0.0.0 { interface "vl-foo"{ cost 10; }; interface "vx-foo" { cost 100; }; }; ipv4 { preference 1000; import all; export all; table foo_ipv4; }; } Here are my interfaces: 21: foo: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 6a:f0:2c:ae:69:48 brd ff:ff:ff:ff:ff:ff promiscuity 0 vrf table 8194 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 22: vl-foo@host0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master foo state UP mode DEFAULT group default qlen 1000 link/ether 06:d8:07:73:68:b6 brd ff:ff:ff:ff:ff:ff promiscuity 0 vlan protocol 802.1Q id 2018 <REORDER_HDR> vrf_slave table 8194 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 23: vx-foo: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1432 qdisc noqueue master foo state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 32:08:91:57:b9:0b brd ff:ff:ff:ff:ff:ff promiscuity 0 vxlan id 2 srcport 0 0 dstport 4789 ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx vrf_slave table 8194 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 If I debug the protocol, I only see it sending the HELLO packets: >>> ospf_foo: HELLO packet sent via vl-foo >>> ospf_foo: HELLO packet sent via vx-foo >>> ospf_foo: HELLO packet sent via vl-foo >>> ospf_foo: HELLO packet sent via vl-foo >>> ospf_foo: HELLO packet sent via vx-foo >>> ospf_foo: HELLO packet sent via vl-foo >>> ospf_foo: HELLO packet sent via vl-foo However, I am seeing packets from the other router on the interface: # tcpdump -nei vl-foo proto 89 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vl-foo, link-type EN10MB (Ethernet), capture size 262144 bytes 08:17:22.583387 56:0f:a7:16:64:e2 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 82: 100.63.16.1 > 224.0.0.5: OSPFv2, Hello, length 48 08:17:28.364546 06:d8:07:73:68:b6 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 78: 192.168.1.5 > 224.0.0.5: OSPFv2, Hello, length 44 08:17:28.364682 06:d8:07:73:68:b6 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 78: 100.63.16.4 > 224.0.0.5: OSPFv2, Hello, length 44 08:17:32.583848 56:0f:a7:16:64:e2 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 82: 100.63.16.1 > 224.0.0.5: OSPFv2, Hello, length 48 08:17:38.364541 06:d8:07:73:68:b6 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 78: 100.63.16.4 > 224.0.0.5: OSPFv2, Hello, length 44 08:17:38.364645 06:d8:07:73:68:b6 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 78: 192.168.1.5 > 224.0.0.5: OSPFv2, Hello, length 44 Can anybody tell me what I am missing here? -- James Oakley james.oakley(a)multapplied.net

2 2

Doubt in file config
by Elder Costa 03 Dec '18

03 Dec '18

Sorry my english and my nescience with Bird...I'm starting Bird now, and my new job we use it... Analyzing config file stay with doubt in section... protocol static aggregated_nets_v4 { ipv4; route XXX.XXX.XXX.XXX/22 reject; route AAA.AAA.AAA.AAA/22 reject; route BBB.BBB.BBB.BBB/22 reject; route CCC.CCC.CCC.CCC/22 reject; } What would be the meaning of block ? Is it creating a static entry and rejecting the routes inside the block? Elder Costa Network Analyst / Analista de Redes

2 1

ospf graceful restart
by Derek Pan 03 Dec '18

03 Dec '18

Hi developer, Does BIRD support graceful restart feature for OSPF? Thanks.

2 1