- Bird-users - Mailing Lists

OSPF HELLO wrong mask
by Slawa Olhovchenkov 15 May '13

15 May '13

BIRD 1.3.9 running on FreeBSD 9.1 with next interfaces (not all showed): em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO> ether 68:05:ca:0e:d3:e1 inet 10.254.0.2 netmask 0xffff0000 broadcast 10.254.255.255 vlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=3<RXCSUM,TXCSUM> ether 50:46:5d:b1:98:6c inet 10.90.90.91 netmask 0xfffffff8 broadcast 10.90.90.95 inet6 2a03:e2c0::1 prefixlen 64 nd6 options=1<PERFORMNUD> media: Ethernet autoselect (1000baseT <full-duplex>) status: active vlan: 1 parent interface: re0 ospf configuration: protocol ospf { area 0 { interface "em0" ; }; } Bird send HELLO packet with wrong mask (and Designated Router also): tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes 20:04:06.186362 IP (tos 0xc0, ttl 1, id 29198, offset 0, flags [none], proto OSPF (89), length 64) 10.254.0.2 > 224.0.0.5: OSPFv2, Hello, length 44 Router-ID 185.17.0.1, Backbone Area, Authentication Type: none (0) Options [External] Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.240, Priority 1 Designated Router 10.90.90.1

2 2

BIRD support programme
by Ondrej Filip 15 May '13

15 May '13

Dear BIRD users, please excuse me for one non-technical e-mail. But in order to increase the speed and the quality of BIRD development we have launched a support programme. The funds raised from this programme will serve on one hand to support BIRD users that need quicker response times, consultancy etc. and also on the other hand to finance BIRD development, travel costs of BIRD developers, equipment etc. So if you need BIRD support or you just want to help BIRD development, please consider joining this programme. http://bird.network.cz/?support Kind regards Ondrej

2 2

HOWTO: Learning recursive routes from kernel protocol
by Сергей Попович 15 May '13

15 May '13

Deploying VLAN per user with IP unnumbered schema using Linux as access server we face with following problem: BIRD's kernel protocol does not learn routes with nexthop, that resolves trought another route (recursive routes). This is reproducable for both IPv4 and IPv6. ---------------------------------------------------------- While for IPv4 this has minimal impact, as typically customer gets its /32 ip address and entire LAN part of the customer connection uses addresses from RFC1918 and NAT. For IPv6 this becomes more complicated: - there is no NAT in such view as with IPv4, (ok) - as with IPv4 customer gets one IPv6 address on its WAN interface (ok) - customer gets additional IPv6 block with 64 long prefix for its LAN interface (fail) So for typical IPv6 deplyment with IP unnumbered schema we need: # ip -6 route add fd11::2/128 dev vlan10 proto static src fd11::1 # ip -6 route add fd22::/64 dev vlan10 via fd11::2 proto static src fd11::1 # birdc 'show route filter { if proto = kernel254 then accept; reject; }' BIRD 1.3.9 ready. fd11::2/128 dev qinq22.226 [kernel254 12:57] * (10) Last route MUST be advertised using dynamic routing protocol (BGP in our case). Example of such routes for both IPv4 and IPv6 is: ------------------------------------------------------------------ # ip -4 route add 192.168.1.2/32 dev vlan10 proto static src 192.168.1.1 # ip -4 route add 10.0.1.0/24 dev vlan10 via 192.168.1.1 proto static src 192.168.1.1 # birdc 'show route filter { if net = 10.0.1.0/24 then accept; reject; }' BIRD 1.3.9 ready. # ip -6 route add fd8e:579a:623c:826a::2/128 dev vlan10 proto static src fd8e:579a:623c:826a::1 # ip -6 route add fd8e:579a:623c:ffff::/64 dev vlan10 # birdc 'show route filter { if net = fd8e:579a:623c:ffff::/64 then accept; reject; }' Kernel protocol configuration --------------------------------------- protocol kernel kernel254 { persist no; scan time 120; learn yes; device routes no; kernel table ipt_main; import filter { # Import only 'static' routes if krt_source != ipp_static then reject; accept; }; export all; } Workaround ----------------- Use static protocol with routes not learned from kernel. protocol static static254 { route fd8e:579a:623c:ffff::/64 drop; } Any ideas about solution/other workarouns for this problem are welcome. -- SP5474-RIPE Sergey Popovich

3 4

Bird RIP does not send some packages
by Aleksey Chudov 13 May '13

13 May '13

Hello, I ran into a situation that Bird RIP does not send some packages. Bird configuration file /etc/bird.conf log syslog all; debug protocols all; protocol device { scan time 5; } protocol direct { interface "*"; } protocol kernel { persist; scan time 5; export filter { if source = RTS_RIP then { if rip_metric > 15 then reject; if net ~ 10.0.0.0/8 then accept; if net ~ 192.168.0.0/16 then accept; } reject; }; } protocol rip { period 5; timeout time 20; garbage time 30; interface "gre*" { mode multicast; }; export filter { if net ~ 10.64.0.0/20 then accept; reject; }; } Log messages from Bird daemon Feb 19 18:25:00 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:03 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:06 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:12 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:13 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:15 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:20 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:26 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:28 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:33 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:36 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:38 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:44 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:48 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:50 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:56 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:58 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:00 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:03 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:05 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:06 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:07 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:13 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:16 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:19 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:21 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:25 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:31 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:33 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:39 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:42 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:45 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:46 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:49 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:51 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:52 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:57 srvc1 bird: rip1: Broadcasting routing table to gre1 And tcpdump for the same period 18:25:00.479028 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:25:03.482132 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:25:15.639027 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:25:26.478329 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:25:48.476297 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:05.639030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:13.473560 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:16.639029 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:21.473055 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:31.473049 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:33.472083 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 44 18:26:39.638030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:45.471432 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:57.637236 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 Are there any ideas why this is happening? Best regards, Aleksey

3 14

show route filter & static routes
by Dan Rimal 13 May '13

13 May '13

Hello, I've found confused behaviour "show route filter". I have basic test setup with some filters, see attachment. With this setup, i've got this result: bird> show route export test 1.0.0.0/20 blackhole [static_bgp 18:22] * (1200) bird> show route filter upstream_out bird> and error log shows: 12-05-2013 18:23:24 <ERR> filters, line 28: Prefix or path expected When i commented out line "if bgp_path.len > 64 then return false;" in "function rt_export_ebgp()", i've got expected result: bird> show route export test 1.0.0.0/20 blackhole [static_bgp 18:22] * (1200) bird> bird> show route filter upstream_out 1.0.0.0/20 blackhole [static_bgp 18:22] * (1200) Unexpected behaviour (for me) arrive when filter contain whatever with BGP PATH and exported routes are static, without bgp path. For example, if i add "bgp_path.prepend(65001);" to "filter usptream_out", i've got same bad result again: bird> show route export test 1.0.0.0/20 blackhole [static_bgp 18:22] * (1200) bird> show route filter upstream_out bird> Is this correct behaviour? Thank you, Regards, Daniel

3 2

[PATCH] Locking in BGP proto generates deadlocks with link-local addresses
by Fritz Grimpen 09 May '13

09 May '13

Hi. Today I have figured out that BIRD will generate a deadlock if you are using the same remote address on multiple BGP protocols: protocol bgp { neighbor fe80::1%tun1 as 1; local fe80::2 as 2; } protocol bgp { neighbor fe80::1%tun2 as 1; local fe80::2 as 3; } In this case, only one of these protocols will change it's state and the other will stuck in Idle state forever. Here is my patch: cat <<PATCH diff --git a/proto/bgp/bgp.c b/proto/bgp/bgp.c index 0f351b4..b1594b9 100644 --- a/proto/bgp/bgp.c +++ b/proto/bgp/bgp.c @@ -840,7 +840,6 @@ bgp_start(struct proto *P) lock->iface = p->cf->iface; lock->type = OBJLOCK_TCP; lock->port = BGP_PORT; - lock->iface = NULL; lock->hook = bgp_start_locked; lock->data = p; olock_acquire(lock); PATCH Fritz.

2 1

ECMP on 2 x 1ge Linux hosts
by Bao Nguyen 08 May '13

08 May '13

I'm trying out OSPF ECMP on BIRD (with ECMP set and enabled on kernel) and on hosts A and host B are configured as below and connected via a switch, the dummy0 interface is used as the loopback address for two physical nics. host A eth1 - /30 - OSPF eth0 - /30 - OSPF dummy0 - /32 host B eth1 - /30 - OSPF eth0 - /30 - OSPF dummy0 - /32

2 2

JUNOS and BIRD OSPF ptp netmask 0.0.0.0 mismatch problem
by Bao Nguyen 07 May '13

07 May '13

Hello all, I'm running BIRD 1.3.4 with JUNOS and I ran into the issue of "netmask 0.0.0.0" was seen by JUNOS as it's not being sent by BIRD on a OSPF point-to-point link per RFC spec but JUNOS perform strict check on it. There seemed to be quite a bit of discussions about this online [1][2] and I'm wondering if anyone got a better alternatives then switching to link broadcast mode? I also looked at BIRD code, it seemed like someone have applied a patch for a "ptp netmask" option on in April 17 to work around this issue but upgrading BIRD is not an option at this point. [1] https://kb.juniper.net/InfoCenter/index?page=content&enablesaml=yes&id=KB23… [2] http://forums.juniper.net/t5/Junos-and-Junosphere/ospf-point-to-point-inter… thanks, -bn 0216331C

3 5

unnecessary and frequency kernel routing update
by Slawa Olhovchenkov 02 May '13

02 May '13

bird router got from BGP peer update don't change routing table: 26-04-2013 15:49:55 <TRACE> le2 > added [best] 209.142.140.0/24 via 10.90.90.92 on vlan1 and send unneeded routing update to kernel (old route is same): 26-04-2013 15:49:55 <TRACE> kernel1 < replaced 209.142.140.0/24 via 10.90.90.92 on vlan1

2 5

BGP is not coming up: Error: Invalid next hop
by Timur Irmatov 01 May '13

01 May '13

Hi. We have a pretty simple BGP configuration with bird: protocol static static_isp { import all; route <net1>/22 via <gw>; route <net2>/23 via <gw>; } protocol bgp isp { disabled on; import none; export where proto = "static_isp"; local as <X>; neighbor <nei> as <Y>; } Initially, we configured network interface with wrong ip address, then after fixing this, bird gives us this error after reconfiguration (Error: Invalid next hop). What's the problem? We could tried restarting bird but this is production router (we have replaced Cisco router with this Linux box) and we woudn't want to do that unless this is really needed. -- Timur Irmatov

2 2