- Bird-users - Mailing Lists

[PATCH] Force KRT rescan on syncer startup with multi syncer config
by Sergey Popovich 15 Oct '13

15 Oct '13

It seems commit commit c6964c305b425b98aaf0492806a28b578d799d83 Author: Ondrej Zajicek <santiago(a)crfreenet.org> Date: Sat Jun 29 22:55:41 2013 +0200 Makes krt.c much more readable. introduces regression, so in configurations with more than one kernel syncer when kernel protocol added/enabled/or restarted (for example due to filter changes), no KRT scan is performed and BRT remains empty until next scan on regular interval specified scan time option). BIRD config: ------------ # Configure logging log stderr all; log syslog all; router id 172.16.1.1; protocol device devices { scan time 120; } ### KRT 10 table rt_10; protocol kernel kernel10 { table rt_10; debug all; persist no; scan time 120; learn yes; device routes yes; kernel table 10; import all; export none; } ### KRT 20 table rt_20; protocol kernel kernel20 { disabled yes; table rt_20; debug all; persist no; scan time 120; learn yes; device routes yes; kernel table 20; import all; export none; } System configuration: --------------------- # ip -4 addr sh dev lo255 6: lo255: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN inet 192.0.2.1/24 brd 192.0.2.255 scope global lo255 # ip -4 route show table 10 172.16.1.0/24 dev lo255 proto static scope link src 192.0.2.1 # ip -4 route show table 20 172.16.1.0/24 dev lo255 proto static scope link src 192.0.2.1 After BIRD starts: ------------------ # birdc 'show protocols' BIRD 1.3.11 ready. name proto table state since info devices Device master up 10:21 kernel10 Kernel rt_10 up 10:21 kernel20 Kernel rt_20 down 10:21 # birdc 'show route table rt_10' BIRD 1.3.11 ready. 172.16.1.0/24 dev lo255 [kernel10 10:21] * (10) # birdc 'show route table rt_20' BIRD 1.3.11 ready. Now enable kernel20: -------------------- # birdc 'enable kernel20' BIRD 1.3.11 ready. kernel20: enabled 10-10-2013 10:23:11 <INFO> Enabling protocol kernel20 Kicking kernel20 up 10-10-2013 10:23:11 <TRACE> kernel20: Starting Allocating FIB hash of order 10: 1024 entries, 0 low, 4096 high kernel20 reporting state transition HUNGRY/DOWN -> */UP kernel20: Scheduling meal Connecting protocol kernel20 to table rt_20 10-10-2013 10:23:11 <TRACE> kernel20: Connected to table rt_20 10-10-2013 10:23:11 <TRACE> kernel20: State changed to feed Feeding protocol kernel20 Feeding protocol kernel20 continued Announcing routes to new protocol kernel20 10-10-2013 10:23:11 <TRACE> kernel20: State changed to up Protocol kernel20 up and running And see no routes from kernel: ------------------------------ # birdc 'show route table rt_20' BIRD 1.3.11 ready. After less than scan time interval (120 sec in configuration): -------------------------------------------------------------- BIRD 1.3.11 ready. 172.16.1.0/24 dev lo255 [kernel20 10:25] * (10) 10-10-2013 10:25:06 <TRACE> kernel10: 172.16.1.0/24: [alien] seen KRT: Got 172.16.1.0/24, type=1, oif=6, table=20, prid=4, proto=kernel20 10-10-2013 10:25:06 <TRACE> kernel20: 172.16.1.0/24: [alien] created --- sysdep/unix/krt.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)

2 1

BIRD 1.3.11 (ports) on FreeBSD 9.1-p7
by Markus Grundmann 09 Oct '13

09 Oct '13

Good morning! My name is Markus and I have an issue with the BIRD 1.3.11. Since I had switched from Quagga 0.9x.x to BIRD 1.3.11 I have more and more trouble in my network with OSPFv2. After some minutes or hours the ARP resolution doesn't work and tons of messages are logged by BIRD and the "kernel". All FreeBSD 9.1-p7 servers sending messages to their syslog (see below). Virtual servers are no longer reachable. What's the problem? The same messages are generated by OSPFv3 processes. --- Some Logs --- arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 [..] arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.197 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 [..] arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 arpresolve: can't allocate llinfo for 8X.2X.32.211 ### The server with the NFS service is running BIRD 1.3.11 (FreeBSD ports). ### Over 1000 messages will be logged. $ dmesg | grep arpresolve | wc -l 1189 ### After a while some servers are not longer available because ARP resolution failed. Oct 9 00:55:39 clarion kernel: newnfs server trinitron:/archiv/clarion: not responding ### When I restart BIRD the ARP resolution will work again. Custom Kernel: 9.1-RELEASE-p7 FreeBSD 9.1-RELEASE-p7 #4: Tue Sep 10 14:31:40 CEST 2013 amd64 ### All OSPF neighbors sending tons of warnings! :-( Oct 9 08:30:35 j bird: OSPF: LSA disappeared (Type: 0005, Id: 10.82.206.193, Rt: 8X.2X.32.210) Oct 9 08:30:35 j bird: OSPF: LSA disappeared (Type: 0005, Id: 8X.2X.1.33, Rt: 8X.2X.32.210) Oct 9 08:30:35 j bird: OSPF: LSA disappeared (Type: 0005, Id: 8X.2X.32.210, Rt: 8X.2X.32.210) Oct 9 08:30:35 j bird: OSPF: LSA disappeared (Type: 0005, Id: 8X.2X.32.216, Rt: 8X.2X.32.210) Oct 9 08:30:35 j bird: OSPF: LSA disappeared (Type: 0005, Id: 8X.2X.32.217, Rt: 8X.2X.32.210) Oct 9 08:30:35 j bird: OSPF: LSA disappeared (Type: 0002, Id: 8X.2X.1.33, Rt: 8X.2X.32.210) Oct 9 08:30:35 j bird: OSPF: LSA disappeared (Type: 0002, Id: 8X.2X.32.210, Rt: 8X.2X.32.210) Oct 9 08:30:40 j bird: OSPF: LSA disappeared (Type: 0005, Id: 10.82.206.193, Rt: 8X.2X.32.210) Oct 9 08:30:40 j bird: OSPF: LSA disappeared (Type: 0005, Id: 8X.2X.1.33, Rt: 8X.2X.32.210) Oct 9 08:30:40 j bird: OSPF: LSA disappeared (Type: 0005, Id: 8X.2X.32.210, Rt: 8X.2X.32.210) Oct 9 08:30:40 j bird: OSPF: LSA disappeared (Type: 0005, Id: 8X.2X.32.216, Rt: 8X.2X.32.210) Oct 9 08:30:40 j bird: OSPF: LSA disappeared (Type: 0005, Id: 8X.2X.32.217, Rt: 8X.2X.32.210) Oct 9 08:30:40 j bird: OSPF: LSA disappeared (Type: 0002, Id: 82.2X.1.33, Rt: 8X.2X.32.210) Oct 9 08:30:40 j bird: OSPF: LSA disappeared (Type: 0002, Id: 8X.2X.32.210, Rt: 8X.2X.32.210) ### It's a little bit too much ;-) grep "LSA disappeared" /var/log/messages|wc -l 3585 ### /var/log/messages on a other machine :-( [..] Oct 9 05:02:19 clarion bird: OSPF: LSA disappeared (Type: 0005, Id: 0.0.0.0, Rt: 82.2X.32.193) Oct 9 05:02:24 clarion bird: OSPF: LSA disappeared (Type: 0002, Id: 8X.2X.32.193, Rt: 8X.2X.32.193) Oct 9 05:02:24 clarion bird: OSPF: LSA disappeared (Type: 0005, Id: 0.0.0.0, Rt: 82.2X.32.193) Oct 9 05:02:28 clarion bird: OSPF: LSA disappeared (Type: 0002, Id: 8X.2X.32.193, Rt: 8X.2X.32.193) Oct 9 05:02:59 clarion last message repeated 6 times Oct 9 05:05:04 clarion last message repeated 25 times Oct 9 05:15:08 clarion last message repeated 121 times Oct 9 05:25:09 clarion last message repeated 120 times Oct 9 05:35:08 clarion last message repeated 120 times Oct 9 05:45:10 clarion last message repeated 120 times Oct 9 05:55:11 clarion last message repeated 120 times Oct 9 06:05:10 clarion last message repeated 120 times Oct 9 06:15:10 clarion last message repeated 120 times Oct 9 06:25:10 clarion last message repeated 120 times Oct 9 06:35:10 clarion last message repeated 120 times Oct 9 06:45:11 clarion last message repeated 120 times Oct 9 06:55:12 clarion last message repeated 120 times Oct 9 07:05:12 clarion last message repeated 120 times Oct 9 07:15:13 clarion last message repeated 120 times Oct 9 07:25:14 clarion last message repeated 120 times Oct 9 07:35:15 clarion last message repeated 120 times Oct 9 07:45:14 clarion last message repeated 120 times Oct 9 07:55:15 clarion last message repeated 120 times Oct 9 08:05:13 clarion last message repeated 119 times [..]

3 8

BIRD 1.3.11 (ports) on FreeBSD 9.1-p7 :: Additional information
by Markus Grundmann 09 Oct '13

09 Oct '13

Hi! The host is running up to two VirtualBox instances with the IP addresses 8X.2X.32.197 and .195 Both VMs are running BIRD 1.3.11 with OSPFv2. When I use OSPFv3 on all neighbors the trouble is more bigger ("LSA disappeared" messages). The server with IP .211 running BIRD 1.3.11. All OSPF neighbors have a Cisco IOS based OSPF neighbor with OSPFv2 and OSPFv3. I hope this are enough information about my environment. Formerly the servers working with Quagga and I have not any issues with ARP and OSPF. Interface "re0" has two VLANs. VLAN2 has multiple IPs in the same network. --- Host .211 --- re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=820db<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,POLLING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE> ether f4:6d:04:94:0c:30 inet6 fe80::f66d:4ff:fe94:c30%re0 prefixlen 64 scopeid 0x3 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=2049<RXCSUM,VLAN_MTU,POLLING,WOL_MAGIC> ether 00:90:27:8f:d6:08 inet6 fe80::290:27ff:fe8f:d608%fxp0 prefixlen 64 scopeid 0x4 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (none) status: no carrier plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> metric 0 mtu 1500 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> ipfw0: flags=8801<UP,SIMPLEX,MULTICAST> metric 0 mtu 65536 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6> inet6 2001:XXXX:1002:1002::1 prefixlen 128 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 inet 127.0.0.1 netmask 0xff000000 inet 10.255.255.10 netmask 0xffffffff nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> vlan2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=3<RXCSUM,TXCSUM> ether f4:6d:04:94:0c:30 inet6 fe80::f66d:4ff:fe94:c30%vlan2 prefixlen 64 scopeid 0x9 inet 8X.2X.32.210 netmask 0xffffffe0 broadcast 82.2X.32.223 inet6 2001:XXXX:1002:1::2 prefixlen 48 inet 8X.2X.32.216 netmask 0xffffffe0 broadcast 8X.2X.32.223 inet 8X.2X.32.217 netmask 0xffffffe0 broadcast 8X.2X.32.223 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active vlan: 2 parent interface: re0 vlan3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=3<RXCSUM,TXCSUM> ether f4:6d:04:94:0c:30 inet6 fe80::f66d:4ff:fe94:c30%vlan3 prefixlen 64 scopeid 0xa inet 8X.2X.1.33 netmask 0xfffffffc broadcast 8X.2X.1.35 inet 10.8X.2X.193 netmask 0xffffffc0 broadcast 10.8X.2X.255 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active vlan: 3 parent interface: re0 ### All loaded kernel modules (has BIRD trouble with the vbox drivers?) $ kldstat Id Refs Address Size Name 1 48 0xffffffff80200000 135c780 kernel 2 1 0xffffffff8155d000 3008 splash_bmp.ko 3 1 0xffffffff817a1000 4f18 if_gre.ko 4 1 0xffffffff817a6000 77d0 if_tap.ko 5 1 0xffffffff817ae000 f7a8 if_lagg.ko 6 1 0xffffffff817be000 b468 ng_netflow.ko 7 4 0xffffffff817ca000 15330 netgraph.ko 8 1 0xffffffff817e0000 f4d8 aio.ko 9 1 0xffffffff817f0000 a80 accf_data.ko 10 1 0xffffffff817f1000 17d8 accf_http.ko 11 1 0xffffffff817f4000 1a5c0 pefs.ko 12 3 0xffffffff8180f000 2b4a8 crypto.ko 13 2 0xffffffff8183b000 dde0 zlib.ko 14 1 0xffffffff81849000 4a30 aesni.ko 15 1 0xffffffff8184e000 2970 snp.ko 16 3 0xffffffff81851000 59a60 vboxdrv.ko 17 1 0xffffffff81a12000 13436d zfs.ko 18 1 0xffffffff81b47000 2fb1 opensolaris.ko 19 1 0xffffffff81b4a000 a9bb fuse.ko 20 2 0xffffffff81b55000 2b11 vboxnetflt.ko 21 1 0xffffffff81b58000 1579 ng_ether.ko 22 1 0xffffffff81b5a000 3fea vboxnetadp.ko ### Additional options in my custom kernel. All other options are from the GENERIC file. options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=0 options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options IPFIREWALL_FORWARD options IPFIREWALL_NAT options LIBALIAS options DUMMYNET options ROUTETABLES=2 // Configured but not used in production. options DEVICE_POLLING options HZ=1000 Best regards, Markus

1 0

OSPF not advertising tun IPs with OpenVPN
by Thomas Johnson 08 Oct '13

08 Oct '13

I am having some difficulty getting my OSPF configuration to play nicely with OpenVPN tunnels on FreeBSD. I have a number of point-to-point tunnels between sites, with a BIRD instance running on each tunnel endpoint. Endpoint addresses for a tunnel use a logical /31. Initially, the BIRD instances would talk to each other, but the endpoint addresses were not advertised by OSPF, making them unreachable. I remedied this by adding stubnet declarations (/32) for each of the tunnel endpoints. This has the effect of making all of my endpoint addresses reachable, but causes another issue. In this configuration, if I restart one of my OpenVPN tunnels, it fails to set addressing on the tunnel, because the host route already exists in the routing table (due to the stubnet). I have attached my OSPF configuration below. Is there some better way of configuring this, to make my tunnel endpoints advertise properly without declaring them as stubnets? Thanks! protocol ospf { tick 2; area 0 { stub no; stubnet 10.70.0.3/32; stubnet 172.26.26.5/32; stubnet 1.2.3.221/32; interface "re0" { stub; cost 100; hello 2; dead 10; authentication cryptographic; password "password"; }; interface "tun*" { type ptp; hello 2; dead 10; authentication cryptographic; password "password"; }; }; }

2 2

filters: strange protocol restarts
by Sergey Popovich 03 Oct '13

03 Oct '13

Hello community!! And again I need to spread some light on BIRD behavior: why bird restarts protocol instead of just reloading it when no filter changes in configuration when using prefix set constant? There is simple configuration and steps to reproduce this ------------------------------------------------------------------------- # Configure logging log syslog all; log stderr all; router id 172.16.1.1; protocol device devices { scan time 15; } ### KRT 10 table rt_10; # This function does not forces "kernel" protocol to reload. function f1(prefix pfx) { if pfx ~ [ 192.168.0.0/16+ ] then return false; return true; } protocol kernel kernel10 { table rt_10; persist no; scan time 15; learn yes; device routes yes; kernel table 10; import where f1(net); export none; } ### KRT 20 table rt_20; # And this does, "kernel" protocol restarts without changing PS_1. define PS_1 = [ 192.168.0.0/16+ ]; function f2(prefix pfx) { if pfx ~ PS_1 then return false; return true; } There is nothing difficult in config: 2 functions f1() and f2() that do same thing except f2() matches specified as parameter prefix to a defined constant of type prefix set (PS_1). Starting bird, and invoking three times on console command to reconfigure bird (birdc configure) without altering configuration file I get following in my syslog: -------------------------------------------------------------------------------- Aug 21 18:50:54 gw1 bird: Started Aug 21 18:50:59 gw1 bird: Reconfiguring Aug 21 18:50:59 gw1 bird: Reloading protocol kernel20 Aug 21 18:50:59 gw1 bird: Restarting protocol kernel20 Aug 21 18:50:59 gw1 bird: Reconfigured Aug 21 18:51:08 gw1 bird: Reconfiguring Aug 21 18:51:08 gw1 bird: Reloading protocol kernel20 Aug 21 18:51:08 gw1 bird: Restarting protocol kernel20 Aug 21 18:51:08 gw1 bird: Reconfigured Aug 21 18:51:08 gw1 bird: Reconfiguring Aug 21 18:51:08 gw1 bird: Reloading protocol kernel20 Aug 21 18:51:08 gw1 bird: Restarting protocol kernel20 Aug 21 18:51:08 gw1 bird: Reconfigured Same thing can be reproduced with other protocols. This is not wery good to restart protocol when no REAL things changed in its filter, as it purges all routes from kernel table, and reinstalls them again causing flap when huge number of routes needed to be reinstalled. Can some one explain to me this behavior of BIRD? Does this mean that usage of constats with type prefix set is not recommended? Thanks for your support. -- SP5474-RIPE Sergey Popovich

3 27

Redundant / High available BIRD
by Robert Scheck 02 Oct '13

02 Oct '13

Hello list, even I spent some time to BGP and BIRD, I am somehow still a newbie with the goal to set up a redundant/high available BGP using BIRD in the future. Initially I thought about putting BIRD onto a Linux system with Corosync and Pacemaker for high availability. The two machines would be connected also directly for heartbeat communication. This would be an active/standby setup - but I'm not sure if this is a good idea (physical layout): ISP1 ---+ +--- BIRD 1 --- Switch | | | \ / Switch | X | | | / \ ISP2 ---+ +--- BIRD 2 --- Switch Note that the "X" is just intersected not connected. This brings obviously a single point of failure: The first switch. My next idea was doubling the switch which requires of course two physical cables per ISP: ISP 1 --- Switch 1 --- BIRD 1 --- Switch \ / \ / | \ / X X | X / \ / \ | / \ ISP 2 --- Switch 2 --- BIRD 2 --- Switch This seems to be...expensive. Even this idea left me with an active/standby setup at BIRD. So Pacemaker would start BIRD on one of the two servers and stop it on the other. During maintainance of the servers the active/standby would be changed to standby/active - but resets all BGP sessions and seems to be especially disliked by eventually later peering partners. Correct me, if I am wrong here, please. I also thought about this setup: ISP 1 --- BIRD 1 --- Switch | \ / | X | / \ ISP 2 --- BIRD 2 --- Switch This actually requires two running BIRDs but leaves me with the question how to deal with the IP address on the internal side. So in theory I would have two virtual standard gateways for connected internal equipment?! Maybe I'm also totally on the wrong road. The basic plan is two different ISP connections, two Linux systems running BIRD and Corosync with Pacemaker to achive high availability - and later some peering partners. I would like to see a fast automated failover in case a link or a hardware breaks down. Searching on the Internet brings lots of BSD-based setups with CARP/pfsync but only less Linux-based ones, somebody noticed keepalived. So is Corosync and Pacemaker just the wrong attempt? Are there some recommendations or best practices on physical and software structure? Do you run similar setups and how do they look like? What are you using on the software level - except BIRD? And how long does a failover take for you? Are you running active/active or active/standby? I am also looking for hardware recommendations: If I am not completely mis- taken, above requires (depending on the configuration) up to two full BGP tables in memory...how much is that for IPv4 and IPv6? How about the CPU? I can read in various documents that BIRD requires less CPU than others, but what does less mean in a rough absolute value in GiB for above situation? Thank you for reading my long e-mail and sorry for taking your time! Feel also free to just send me some pointers in case I missed some documentation or other useful links. Greetings, Robert

2 1

OSPF dont import routes from LSAdb
by 1 Игорь 30 Sep '13

30 Sep '13

Hi everyone. I have a problem with OSPF. In my topology Core router (Area0) connected to 2 routers (Area1), which intrconnected with their own link. Core redistributes 0/0 and things works normal. Core router ID is 10.0.0.0, R1 - 10.0.1.1, R2 - 10.0.1.2. But, when I drop one of links between Core router and Area1 router, I expect that 0/0 route pass through second Area 1 router and all reveal on first, on wich i drop link to core. In LSA DB I see LSA Type 5, wich generates from core router: bird> show ospf lsadb Global Type LS ID Router Age Sequence Checksum 0005 0.0.0.0 10.0.0.0 616 80000002 72f0 Area 0.0.0.0 Type LS ID Router Age Sequence Checksum 0001 10.0.1.2 10.0.1.2 0 80000002 594e 0003 10.16.0.0 10.0.1.2 29 80000001 e258 Area 0.0.0.1 Type LS ID Router Age Sequence Checksum 0003 10.0.0.0 10.0.1.1 943 80000001 6d75 0004 10.0.0.0 10.0.1.1 943 80000001 5f82 0001 10.0.1.1 10.0.1.1 23 8000000a 2103 0003 10.0.1.1 10.0.1.1 962 80000001 6cd8 0003 10.2.1.3 10.0.1.1 962 80000001 1ac5 0002 10.31.12.1 10.0.1.1 23 80000001 847a 0002 10.31.21.1 10.0.1.1 23 80000001 21d4 0001 10.0.1.2 10.0.1.2 13 80000009 3be5 0003 10.0.1.2 10.0.1.2 29 80000001 5ce6 0003 10.2.1.4 10.0.1.2 29 80000001 0ad3 But in master table I have no this route: bird> show route 10.0.1.2/32 dev lo [C1 11:46] * I (150/0) [10.0.1.2] 10.2.1.4/30 dev bond0.4002 [C1 11:46] * I (150/100) [10.0.1.2] 10.31.21.0/24 dev bond0.4021 [C1 11:47] * I (150/10) [10.0.1.1] 10.31.12.0/24 dev bond0.4012 [C1 11:47] * I (150/10) [10.0.1.1] (bond0.4012 and bond0.4021 - links which interconnect R1 and R2, bond0.4002 - link to Core, which disabled there) Config of R1 and R2 is same (exept Router ID): # Configure logging #log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug }; log stderr all; log "/var/log/bird.log" { info,remote,warning,error,auth,fatal,bug}; #log "/var/log/debug_bird.log" all; filter OSPF_in { if ( net=0.0.0.0/0 || net ~ 10.0.0.0/8 ) then accept; else reject; }; filter OSPF_out { if (net ~ 10.16.0.0/12 ) then accept; else reject; }; # This pseudo-protocol performs synchronization between BIRD's routing # tables and the kernel. If your kernel supports multiple routing tables # (as Linux 2.2.x does), you can run multiple instances of the kernel # protocol and synchronize different kernel tables with different BIRD tables. protocol kernel { # learn; # Learn all alien routes from the kernel debug {states,routes,filters,interfaces}; persist; # Don't remove routes on bird shutdown scan time 20; # Scan kernel routing table every 20 seconds import all; # Default is import all export all; # Default is export none # kernel table 5; # Kernel table to synchronize with (default: main) } # This pseudo-protocol watches all interface up/down events. protocol device { scan time 10; # Scan interfaces every 10 seconds } protocol ospf C1{ # rfc1583compat yes; router id 10.0.1.2; ecmp; import keep filtered yes; # import filter OSPF_in; import all; # export filter OSPF_out; # export none; # debug {states,routes,filters,interfaces}; debug all; area 0{ stub no; interface "bond0.4002"{ type bcast; cost 100; hello 1; dead count 3; retransmit 6; transmit delay 5; wait 30; authentication cryptographic; password "xxx"; }; interface 10.0.1.2/32 { stub 1; }; }; area 1{ stub no; interface "bond0.4012", "bond0.4021" { rx buffer large; type bcast; cost 10; hello 1; dead count 3; retransmit 6; transmit delay 5; wait 30; authentication cryptographic; password "aaa"; }; interface 10.16.0.0/12 { stub 1; cost 10; }; }; } Config of Core router: # Configure logging #log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug }; #log stderr all; #log "tmp" all; filter OSPF_in { if (net ~ 10.0.0.0/8 ) then accept; else reject; }; # Redistribute 0/0 only from BRAS!!! filter OSPF_redistribute { if ( net = 0.0.0.0/0) then { #ospf_metric1=200; ospf_metric2=100; accept; } else reject; }; # This pseudo-protocol performs synchronization between BIRD's routing # tables and the kernel. If your kernel supports multiple routing tables # (as Linux 2.2.x does), you can run multiple instances of the kernel # protocol and synchronize different kernel tables with different BIRD tables. protocol kernel { learn; # Learn all alien routes from the kernel persist; # Don't remove routes on bird shutdown scan time 10; # Scan kernel routing table every 20 seconds import all; # Default is import all export all; # Default is export none # kernel table 5; # Kernel table to synchronize with (default: main) } # This pseudo-protocol watches all interface up/down events. protocol device { scan time 10; # Scan interfaces every 10 seconds } # Static routes (again, there can be multiple instances, so that you # can disable/enable various groups of static routes on the fly). protocol static { # disabled; # Disable by default route 123.123.123.0/24 via "eth0"; } protocol ospf CORE{ tick 2; ecmp; # rfc1583compat yes; router id 10.0.0.0; import filter OSPF_in; export filter OSPF_redistribute; # export none; area 0 { stub no; interface "eth0.4001", "eth0.4002" { # "To corp1"; hello 1; retransmit 6; cost 10; transmit delay 5; dead count 3; wait 50; type broadcast; authentication cryptographic; password "corp1_pass"; }; interface "lo" { stub yes; }; }; }

1 1

"gw" attribute assignment in filter invalidates routes learned via BGP, static, and possibly others?
by Sergey Popovich 27 Sep '13

27 Sep '13

Hello! Another issue I spot last time: assigning value in protocol export filter invalidates route and prevents its from being installed in KRT. Simple config to test this issue: ---------------------------------------- ### SYSTEM # ip link add dev lo255 type dummy # ip link set up dev lo255 # ip -4 addr add 192.0.2.254/24 dev lo255 # ip -4 addr add 172.16.2.254/24 dev lo255 # ip link set up dev eth0 # ip -4 addr add 192.168.1.2/24 dev eth0 ### BIRD router id 10.10.10.10; protocol device devices { scan time 120; } # Main routing table (master), mapped to ipt_main kernel table. # ipt_main == 254 (see /etc/iproute2/rt_tables) protocol kernel kernel254 { persist no; scan time 120; learn no; device routes no; kernel table ipt_main; import none; export all; } protocol direct direct254 { interface "lo255", "eth0"; } protocol static static254_test { # If "via" is one from "lo255" subnets (172.16.2.5 for example: # everything is correct and route installed by "kernel254" route 10.0.0.0/24 via 192.168.1.1; import filter { # This causes route invalidation, "gw" points to 192.0.2.5, # but interface is still "eth0" (see birdc output below). gw = 192.0.2.5; accept; }; export none; }; protocol static static254 { # rs1, rs2 route 192.168.254.1/32 via 192.168.1.1; route 192.168.254.2/32 via 192.168.1.1; } # AS65001, peering with Route Server(s), RS template bgp tl_bgp254_as65001 { start delay time 10; connect retry time 60; startup hold time 30; keepalive time 10; hold time 30; capabilities yes; advertise ipv4 yes; enable route refresh yes; enable as4 yes; gateway recursive; multihop 4; local 192.168.1.2 as 65010; import filter { # This causes route invalidation, "gw" points to 192.0.2.5, but # interface is still "eth0" (see birdc output below). gw = 192.0.2.5; accept; }; export none; } protocol bgp bgp254_as65001_rs1 from tl_bgp254_as65001 { neighbor 192.168.254.1 as 65001; } protocol bgp bgp254_as65001_rs2 from tl_bgp254_as65001 { neighbor 192.168.254.2 as 65001; } Here is output from birdc and ip-route(8): ---------------------------------------------------- ### common ## 192.0.2.0/24, lo255 $ birdc 'show route for 192.0.2.5 all' BIRD 1.3.11 ready. 192.0.2.0/24 dev lo255 [direct254 12:45] * (240) Type: device unicast univ $ ip -4 route show match 192.0.2.5/32 192.0.2.0/24 dev lo255 proto kernel scope link src 192.0.2.254 ## 172.16.2.0/24, lo255 $ birdc 'show route for 172.16.2.5 all' BIRD 1.3.11 ready. 172.16.2.0/24 dev lo255 [direct254 13:00] * (240) Type: device unicast univ $ ip -4 route show match 172.16.2.5/32 172.16.2.0/24 dev lo255 proto kernel scope link src 172.16.2.254 ## 192.168.1.0/24, eth0 $ birdc 'show route for 192.168.1.0/24 all' BIRD 1.3.11 ready. 192.168.1.0/24 dev eth0 [direct254 12:45] * (240) Type: device unicast univ $ ip -4 route show match 192.168.1.2/32 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254 ### static ## 10.0.0.0/24 $ birdc 'show route for 10.0.0.0/24 all' BIRD 1.3.11 ready. 10.0.0.0/24 via 192.0.2.5 on eth0 [static254_test 13:19] ! (200) Type: static unicast univ $ ip -4 route show exact 10.0.0.0/24 ### BGP $ birdc 'show route for 10.0.0.0/8 all' BIRD 1.3.11 ready. 10.0.0.0/8 via 192.0.2.5 on eth0 [bgp254_as65001_rs1 13:00 from 192.168.254.1] ! (100/0) [AS1011i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65001 1011 BGP.next_hop: 192.168.1.1 BGP.local_pref: 100 BGP.community: (1001,65010) (1001,1001) via 192.0.2.5 on eth0 [bgp254_as65001_rs2 13:00 from 192.168.254.2] (100/0) [AS1011i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65001 1011 BGP.next_hop: 192.168.1.1 BGP.local_pref: 100 BGP.community: (1001,65010) (1001,1001) $ ip -4 route show exact 10.0.0.0/8 --------------------------------------------------------------------------------------- This is probably due to not updating iface, nexthops (multihop config) and other fields of "rta" struct. Provided patch in attachment tries to address this issue by calling rta_set_recursive_next_hop() in filter/filter.c to properly assign to "gw" attribute. Special cases for bgp and static protocols was taken to use "igp table" configuration parameter if present (tested, and found working with static protocol, probably some with bgp). Patch tested in my configuration and works wery well for both static and bgp protocols. --------------------------------------------------------------------------------------- Brief explanation why "gw" attribute might be wery important (at least in my case). There is common technique to stop DDoS in large ISP network: blackholing. However implementations of this might wary from vendor to vendor. In BIRD simplest way to implement this is to set "dest" attribute to something like RTD_BLACKHOLE, and all other route attributes gets deleted (gw, iface, ...). Route installed in KRT as blackhole. Everything is ok with this setup, but sometimes searching blackhole route might give some surprises: you trace path to blackholed destination and gets nothing(???) from your gateway, as it drops packets destined to blackhole route without any notification (in case of trace path without sending ICMP Time To Live Exceeded). And what if you trace from some core router? And heres another blackholing technique comes: use looped back interface to drop packets. In this case we setup some system looped back interface (in Linux this is dummy interface type), configure some network on it (say something 192.0.2.0/24), And instead of setting blackholed route type to RTD_BLACKHOLE we change its "gw" to any address within subnet assigned on looped back interface. Thats servers same as route with blackhole type, but behaves differently on trace paths: router sends ICMP Time To Live Exceeded messages from its incoming interface address indicating last hop before dropping blackholed traffic. This has no impact on DDoS traffic, except it transmitted to looped back interface instead of being dropped immediately after matching route and wasting few CPU cycles. -- SP5474-RIPE Sergey Popovich

2 5

filters: Implement "ifname" and "ifindex" route attributes
by Sergey Popovich 27 Sep '13

27 Sep '13

Hello, BIRD developers! Currently there is no way in filter rules to match routes by interface name and interface index. However string comparison (=,!=,>,<,... operations), and pattern matching (using ~ operator) already implemented in filters, so expressions like: if "eth0" ~ "eth*" || "eth1" = "eth1" then print "This pattern matches!"; already works. Only one thing that is really needed is exposing attribute with name to filter which references route outgoing interface name and index. Of course all of these variables must be readonly. Interface indexes are taken from kernel (at least on Linux, and FreeBSD) and represents interface number in system. Matching to indexes is not such reliable as matching with interface names, as indexes might change on interface addition/removal. Currently only sink (blackhole, unreachable and prohibit) routes in BIRD have no interface associated. Return an empty string and index equal to zero (no real index in kernel) for such routes. -- SP5474-RIPE Sergey Popovich

2 2

kernel: BIRD kernel syncer protocol issues on Linux
by Sergey Popovich 26 Sep '13

26 Sep '13

Helo, BIRD developers! I have found few issues with kernel syncer on Linux with enabled route learning. There are few problems in sysdep/linux/rtnetlink.c with netlink code: * Use after free when accessing nl_table_map[] in nl_parse_route(). * Possible race condition between rx buffer allocation nl_async_rx_buffer in for async socket and nl_open_async() and it's usage in nl_async_hook(). * Socket descriptor leakage in error path in nl_open_async() when bind(2) call fails. These problems addressed with patch bird-1.3.11-fix-shutdow~ath-in-rtnetlink.patch Additionaly, patch bird-1.3.11-fix-building-with-DBG-on.patch fixes building when -DGLOBAL_DEBUG or -DLOCAL_DEBUG enabled (enables building lots of debugging code available with DBG() macro). Information to reproduce problem with use after free in nl_parse_route(). ========================================== BIRD configuration ------------------------ # Configure logging log stderr all; # More chances to trigger crash. log syslog all; router id 172.16.1.1; protocol device devices { scan time 120; } protocol kernel kernel10 { debug all; persist no; scan time 120; learn yes; device routes no; kernel table 10; import all; export none; } Start BIRD, compiled with "-DGLOBAL_DEBUG" in debugging mode ------------------------------------------------------------------------------------ # bird -d olock: init Parsing configuration file `/etc/bird.conf' Protocol preconfig: Direct Static Pipe BGP Kernel Device Protocol postconfig: devices kernel10 sysdep_commit global_commit rt_commit rt_commit: master: created Allocating FIB hash of order 10: 1024 entries, 0 low, 4096 high done protos_commit protos_commit: 26-09-2013 10:57:45 <TRACE> kernel10: Initializing done Protocol start ... Kicking kernel10 up 26-09-2013 10:57:45 <TRACE> kernel10: Starting Allocating FIB hash of order 10: 1024 entries, 0 low, 4096 high kernel10 reporting state transition HUNGRY/DOWN -> */UP kernel10: Scheduling meal Connecting protocol kernel10 to table master 26-09-2013 10:57:45 <TRACE> kernel10: Connected to table master 26-09-2013 10:57:45 <TRACE> kernel10: State changed to feed do_commit finished with 0 obstacles remaining 26-09-2013 10:57:45 <INFO> Started Entering I/O loop. Feeding protocol devices Feeding protocol devices continued Announcing routes to new protocol devices Protocol devices up and running Feeding protocol kernel10 Feeding protocol kernel10 continued Announcing routes to new protocol kernel10 26-09-2013 10:57:45 <TRACE> kernel10: State changed to up Protocol kernel10 up and running KRT: Scanning routing table 26-09-2013 10:57:45 <TRACE> kernel10: Scanning routing table KRT: Got 192.168.10.0/24, type=6, oif=-1, table=10, prid=3, proto=kernel10 26-09-2013 10:57:45 <TRACE> kernel10: 192.168.10.0/24: [alien] created KRT: Got 192.168.20.0/24, type=6, oif=-1, table=20, prid=3, proto=(none) ... KRT: Pruning table master 26-09-2013 10:57:45 <TRACE> kernel10: Pruning table master KRT: Pruning inherited routes 26-09-2013 10:57:45 <TRACE> kernel10: Pruning inherited routes 192.168.10.0/24: announcing (metric=0) 26-09-2013 10:57:45 <TRACE> kernel10 > added [best] 192.168.10.0/24 blackhole 26-09-2013 10:57:45 <TRACE> kernel10 < rejected by protocol 192.168.10.0/24 blackhole After startup BIRD learns route from KRT 10 -------------------------------------------------------- # birdc 'show route table master all' BIRD 1.3.11 ready. 192.168.10.0/24 blackhole [kernel10 10:57] * (10) Type: inherit unicast univ Kernel.source: 3 Kernel.metric: 0 Change KRT ID to 10 ("kernel table 10" configuration option) and tell bird about configuration changes ---------------------------------------------------- # birdc configure BIRD 1.3.11 ready. Reading configuration from /etc/bird.conf Reconfiguration in progress Debug output after reconfiguration --------------------------------------------- Parsing configuration file `/etc/bird.conf' Protocol preconfig: Direct Static Pipe BGP Kernel Device Protocol postconfig: devices kernel10 26-09-2013 10:57:54 <INFO> Reconfiguring sysdep_commit global_commit rt_commit rt_commit: master: same done protos_commit protos_commit: devices: same 26-09-2013 10:57:54 <INFO> Restarting protocol kernel10 +++ adding obstacle 1 Kicking kernel10 down 26-09-2013 10:57:54 <TRACE> kernel10: Shutting down KRT: Flushing kernel routes 26-09-2013 10:57:54 <TRACE> kernel10: Flushing kernel routes kernel10 reporting state transition HAPPY/UP -> */DOWN kernel10: Scheduling flush 26-09-2013 10:57:54 <TRACE> kernel10: State changed to flush Pruning neighbors done Protocol start do_commit finished with 1 obstacles remaining Pruning route table master 26-09-2013 10:57:54 <TRACE> kernel10 > removed [sole] 192.168.10.0/24 blackhole Pruning route table master Flushing protocol kernel10 26-09-2013 10:57:54 <TRACE> kernel10: State changed to down Protocol kernel10 down kernel10 has shut down for reconfiguration +++ deleting obstacle 1 26-09-2013 10:57:54 <TRACE> kernel10: Initializing Kicking kernel10 up 26-09-2013 10:57:54 <TRACE> kernel10: Starting Allocating FIB hash of order 10: 1024 entries, 0 low, 4096 high kernel10 reporting state transition HUNGRY/DOWN -> */UP kernel10: Scheduling meal Connecting protocol kernel10 to table master ... KRT: Scanning routing table 26-09-2013 10:57:54 <TRACE> kernel10: Scanning routing table KRT: Got 192.168.10.0/24, type=6, oif=-1, table=10, prid=3, proto=kernel10 26-09-2013 10:57:54 <TRACE> kernel10: 192.168.10.0/24: [alien] created KRT: Got 192.168.20.0/24, type=6, oif=-1, table=20, prid=3, proto=kernel10 26-09-2013 10:57:54 <TRACE> kernel10: 192.168.20.0/24: [alien] created ************************************************************************** And route from KRT ID 10 is seen and accepted in nl_parse_route() at sysdep/linux/rtnetlink.c. ************************************************************************** ... KRT: Pruning table master 26-09-2013 10:57:54 <TRACE> kernel10: Pruning table master KRT: Pruning inherited routes 26-09-2013 10:57:54 <TRACE> kernel10: Pruning inherited routes 192.168.10.0/24: announcing (metric=0) 26-09-2013 10:57:54 <TRACE> kernel10 > added [best] 192.168.10.0/24 blackhole 26-09-2013 10:57:54 <TRACE> kernel10 < rejected by protocol 192.168.10.0/24 blackhole 192.168.20.0/24: announcing (metric=0) 26-09-2013 10:57:54 <TRACE> kernel10 > added [best] 192.168.20.0/24 blackhole 26-09-2013 10:57:54 <TRACE> kernel10 < rejected by protocol 192.168.20.0/24 blackhole 26-09-2013 10:57:54 <INFO> Reconfigured Feeding protocol kernel10 Feeding protocol kernel10 continued Announcing routes to new protocol kernel10 26-09-2013 10:57:54 <TRACE> kernel10 < rejected by protocol 192.168.10.0/24 blackhole 26-09-2013 10:57:54 <TRACE> kernel10 < rejected by protocol 192.168.20.0/24 blackhole 26-09-2013 10:57:54 <TRACE> kernel10: State changed to up Protocol kernel10 up and running After reconfiguration finishes, we see route from KRT ID 10 in BRT "master" table, to which syncer is attached. ------------------------------------------------------------------------------------------------ # birdc 'show route table master all' BIRD 1.3.11 ready. 192.168.10.0/24 blackhole [kernel10 10:57] * (10) Type: inherit unicast univ Kernel.source: 3 Kernel.metric: 0 192.168.20.0/24 blackhole [kernel10 10:57] * (10) Type: inherit unicast univ Kernel.source: 3 Kernel.metric: 0 And adding routes to KRT ID 10 when BIRD uses KRT ID 20 causes them to be stored in "master" table: --------------------------------------------------------------------------------------------------- # ip -4 route add blackhole 192.168.30.0/24 table 10 # birdc 'show route table master all' BIRD 1.3.11 ready. 192.168.10.0/24 blackhole [kernel10 10:57] * (10) Type: inherit unicast univ Kernel.source: 3 Kernel.metric: 0 192.168.20.0/24 blackhole [kernel10 10:57] * (10) Type: inherit unicast univ Kernel.source: 3 Kernel.metric: 0 192.168.30.0/24 blackhole [kernel10 10:58] * (10) Type: inherit unicast univ Kernel.source: 3 Kernel.metric: 0 And debugging output from BIRD ------------------------------------------ KRT: Received async route notification (24) KRT: Got 192.168.30.0/24, type=6, oif=-1, table=10, prid=3, proto=kernel10 26-09-2013 11:15:24 <TRACE> kernel10: 192.168.30.0/24: [alien async] created krt_learn_async: distributing change 26-09-2013 11:15:24 <TRACE> kernel10 > added [best] 192.168.30.0/24 blackhole 26-09-2013 11:15:24 <TRACE> kernel10 < rejected by protocol 192.168.30.0/24 blackhole There also possible to trigger crash, infinite loop (spot on bird 1.3.9 on the other system), but I have no instructions to reproduce this reliable. At least logging to syslog or to a file among with logging to stderr and changing name of the protocol (kernel10->kernel20 etc.) after route learned from other KRT, or wait for periodic KRT scan, possibly followed by protocol name change). -- SP5475-RIPE Sergey Popovich

2 1