- Bird-users - Mailing Lists

Reconfiguring problem while having a lot of static routes
by Vasily Oleynikov 26 Aug '19

26 Aug '19

Hello I have a bird 1.6.3 installation where is over 500k static routes. From some moment service reconfiguring occupies significant time (over 20 minutes). Is there some method to reduce time needed to reconfigure? My config is below log syslog all; router id X.X.X.X; filter BGW_WAN_import { if net ~ [0.0.0.0/0] then accept; reject; } filter BGW_LAN_import { reject; } filter BGW_LAN_export { if dest = RTD_UNREACHABLE then reject; accept; } filter DROP_STATIC { if dest = RTD_BLACKHOLE then { bgp_community.add((65535, 65282)); bgp_community.add((X, 666)); accept; } if source = RTS_STATIC then reject; if source = RTS_BGP then accept; reject; } protocol bgp BGW1_WAN { local as 65511; neighbor Y.Y.Y.X as X; import filter BGW_WAN_import; export filter DROP_STATIC; } protocol bgp BGW0_WAN { local as 65511; neighbor Y.Y.Y.Z as X; import filter BGW_WAN_import; export filter DROP_STATIC; } protocol device { scan time 10; } protocol kernel { scan time 10; export filter DROP_STATIC; } protocol static { include "/opt/etc/bird/static_null.conf"; } in /opt/etc/bird/static_null.conf there is routes like this: route 13.59.179.106/32 drop; WBR, Vasily

2 1

Bird 2 OSPF Authentication Type unknown (256) issue
by James Swineson 24 Aug '19

24 Aug '19

Hi, I have a Linux server and a Cisco IOS XE device connected with GRE/IPSec and then can ping each other. Today I installed Bird 2.0.5 on the Linux server and enabled OSPFv2 on both of them. Although they receive HELLO packets from each other, they refuse to establish a connection. A packet capture shows Bird is sending packets with auth type = 256 which is not something I would expect everyday: 05:38:06.129722 IP (tos 0xc0, ttl 1, id 48901, offset 0, flags [none], proto OSPF (89), length 64) 192.168.1.2 > ospf-all.mcast.net: OSPFv2, Hello, length 44 Router-ID 192.168.1.2, Backbone Area, Authentication Type: unknown (256) As a test I changed authentication type from none to simple; this time Bird gave me 257: 05:40:36.129411 IP (tos 0xc0, ttl 1, id 3669, offset 0, flags [none], proto OSPF (89), length 64) 192.168.1.2 > ospf-all.mcast.net: OSPFv2, Hello, length 44 Router-ID 192.168.1.2, Backbone Area, Authentication Type: unknown (257) Is there something wrong with my config or there is a bug in Bird2? Is there any workaround I can use right now? I've already checked on both sides their interface type is set to ptp and all timers match. My environment: * Cisco IOS XE 16.9.3, CSR1000v in Hyper-V VM * Debian 10 in KVM, Bird 2.0.5 via official unstable repo, IPSec done with strongswan Thanks ahead, James Swineson

2 2

Re: IPv6 routes inserted into the kernel with 'route' end up with invalid type
by Toke Høiland-Jørgensen 23 Aug '19

23 Aug '19

David Ahern <dsahern(a)gmail.com> writes: > On 8/23/19 8:43 AM, Toke Høiland-Jørgensen wrote: >> Hi David >> >> Tom noticed[0] that on newer kernels, the Bird routing daemon rejects IPv6 >> routes received from the kernel if those routes were inserted with the >> old 'route' utility (i.e., when they're inserted through the ioctl >> interface). >> >> We tracked it down to the routes having an rtm_type of RTN_UNKNOWN, and >> a bit of git archaeology points suggestively at this commit: >> >> e8478e80e5a ("net/ipv6: Save route type in rt6_info") >> >> The same setup works with older kernels, so this seems like it's a >> regression, the age of 'route' notwithstanding. Any good ideas for the >> proper way to fix this? >> > > Should be fixed by: > > commit c7036d97acd2527cef145b5ef9ad1a37ed21bbe6 > Author: David Ahern <dsahern(a)gmail.com> > Date: Wed Jun 19 10:50:24 2019 -0700 > > ipv6: Default fib6_type to RTN_UNICAST when not set > > A user reported that routes are getting installed with type 0 > (RTN_UNSPEC) > where before the routes were RTN_UNICAST. One example is from accel-ppp > which apparently still uses the ioctl interface and does not set > rtmsg_type. Another is the netlink interface where ipv6 does not require > rtm_type to be set (v4 does). Prior to the commit in the Fixes tag the > ipv6 stack converted type 0 to RTN_UNICAST, so restore that behavior. > > Fixes: e8478e80e5a7 ("net/ipv6: Save route type in rt6_info") > Signed-off-by: David Ahern <dsahern(a)gmail.com> > Signed-off-by: David S. Miller <davem(a)davemloft.net> Ah, great! Guess that hasn't made its way to the stable and distribution kernels yet. Thanks for the pointer! :) -Toke

1 0

bird 1.6 seems to ignore ipv6 kernel routes on 4.19
by Tom Bird 23 Aug '19

23 Aug '19

Hi, I recently updated some virtual machine hosting nodes to Debian Buster from Stretch, and I'm having an interesting problem with IPv6 kernel routes. My example uses 1.6.6 but 1.6.7 shows the same behaviour, so I'm just wondering what I am missing. v4 is all working as expected. I tried a bird6.conf from a machine still running Debian Stretch, and that also did not import the kernel routes. I've tried this on a test VM with bird 1.6.3 and kernel 4.9.0 and it imports the routes as expected. I've set up a test VM in the lab with the following bird6.conf: -------------------------------------- root@os-test:~# grep -v ^# /etc/bird/bird6.conf router id 198.51.100.1; protocol kernel { scan time 60; learn; device routes; #import none; import all; } protocol device { scan time 60; } -------------------------------------- This is just the sample file with "learn", "import all" and "device routes" added to the kernel protocol. I have added a test kernel route: root@os-test:~# route -6 add 2a03:9804::/64 gw 2a03:9802:1000:aa::1 I would expect to see this in a "show route" output from birdc6, but I don't. I only see the default: root@os-test:~# birdc6 BIRD 1.6.6 ready. bird> show route ::/0 via 2a03:9802:1000:aa::1 on ens2 [kernel1 21:14:40] * (10) bird> If I add a protocol direct section, then I get device routes but still not indirect kernel routes. Some other stuff about the system, sorry if this hasn't pasted so well. root@os-test:~# uname -a Linux os-test.portfast.net 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux root@os-test:~# netstat -rn6 Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If ::1/128 :: U 256 2 0 lo 2a03:9802:1000:aa::/64 :: U 256 3 0 ens2 2a03:9804::/64 2a03:9802:1000:aa::1 UG 1 1 0 ens2 fe80::/64 :: U 256 1 0 ens2 ::/0 2a03:9802:1000:aa::1 UGH 1024 2 0 ens2 ::1/128 :: Un 0 4 0 lo 2a03:9802:1000:aa::2/128 :: Un 0 3 0 ens2 fe80::5054:ff:fe10:d040/128 :: Un 0 3 0 ens2 ff00::/8 :: U 256 2 0 ens2 ::/0 :: !n -1 1 0 lo Thanks, -- Tom Bird http://www.portfast.co.uk/ : AS8916 UK Limited company #6061075 : +44 1777 29 28 27

4 6

IPsec (OSPFv3)
by Kenth Eriksson 19 Aug '19

19 Aug '19

Hi! What is the plan for IPsec with regards to OSPFv3? Is it part of roadmap? If not a roadmap item, what is the recommended way to get IPsec support for OSPFv3 with bird? libreswan? Thanks, Kenth

3 4

Support for setting Aggregator IP/ASN in BGP Updates
by Clemens Mosig 19 Aug '19

19 Aug '19

Hi all, we are manually announcing and withdrawing prefixes by disabling and enabling a static protocol: E.g: protocol static prefix{ ipv4; route 1.2.3.0/24 blackhole; } Is there a way to manually set the BGP AGGREGATOR IP address or ASN for the resulting announcements or withdraws? Cheers, Clemens

2 1

iBGP problem with full meshed routers
by Martin Bosner 19 Aug '19

19 Aug '19

Hello, i'm a little desperate and helpless because i can't get any further with my current problem: My current setup (all same AS only physical): router A ---- router B --- router C ------- router E --- router G (has full \ | | | table uplink) \ | | | \ | | | router D ------- router F --- router H Router ABCD and router EFGH are each at the same location in a L2 network. There are no additional static routing information but the one from the interfaces and they are all connected via BGP using the same AS. All routers can ping each other and no router has a default gw. All BGP sessions are using the same table and are up and alive. All direct connected routers have a "direct" connection and all non direct connected routers use multihop. The problem is that router G and router H only have invalid global routes learned from router A while E and F are fine: (using 223.230.128.0/22 is just a random pick for demonstration) router G and H (PROBLEM): BIRD SHOW ROUTE birdc show route 223.230.128.0/22 all BIRD 2.0.5 ready. Table master4: 223.230.128.0/22 unreachable [routerG_to_routerA 03:15:02.410 from 153.92.124.4] * (100/-) [AS45609?] Type: BGP univ BGP.origin: Incomplete BGP.as_path: 15943 9498 45609 BGP.next_hop: 153.92.124.4 BGP.local_pref: 100 KERNEL route -n | grep 223.230.128.0 223.230.128.0 - 255.255.252.0 ! 32 - 0 - CONFIG protocol bgp routerG_to_routerA{ local as 60664; neighbor 153.92.124.4 as 60664; source address 185.27.180.133; enable route refresh yes; multihop; allow local as 60664; ipv4 { import all; export all; next hop self; }; } router E and F (VALID): BIRD SHOW ROUTE birdc show route 223.230.128.0/22 all BIRD 2.0.5 ready. Table master4: 223.230.128.0/22 unicast [routerE_to_routerA 02:42:58.878 from 153.92.124.4] * (100/?) [AS45609?] via 192.168.0.1 on external Type: BGP univ BGP.origin: Incomplete BGP.as_path: 15943 9498 45609 BGP.next_hop: 153.92.124.4 BGP.local_pref: 100 KERNEL route -n | grep 204.34.123.0 204.34.123.0 192.168.0.1 255.255.255.0 UG 32 0 0 external CONFIG protocol bgp routerE_to_routerA{ local as 60664; neighbor 153.92.124.4 as 60664; source address 192.168.0.2; multihop; allow local as 60664; ipv4 { import all; export all; next hop self; }; } router A BIRD SHOW ROUTE birdc show route 223.230.128.0/22 all BIRD 2.0.5 ready. Table master4: 223.230.128.0/22 unicast [routerA_to_external 23:01:24.661] * (100) [AS45609?] via 84.44.0.210 on xge1 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 15943 9498 45609 BGP.next_hop: 84.44.0.210 BGP.local_pref: 100 KERNEL route -n | grep 204.34.123.0 204.34.123.0 84.44.0.210 255.255.255.0 UG 32 0 0 xge1 CONFIG E (valid) protocol bgp routerA_to_routerE{ local as 60664; neighbor 153.92.124.2 as 60664; source address 153.92.124.4; direct; allow local as 60664; ipv4 { import all; export all; next hop self; }; } CONFIG G (problem) protocol bgp routerA_to_routerG{ local as 60664; neighbor 185.27.180.133 as 60664; source address 153.92.124.4; multihop; allow local as 60664; ipv4 { import all; export all; gateway recursive; next hop self; }; } I am using bird 2.0.5 and ubuntu 18.04 with 4.15.0-54-generic and already played around with and without "next hop self" etc. but without luck. There seems to be a problem with my configuration or with the next hop calculation, right? Or did i miss something else? Thank you in advance Martin Bosner

3 3

Segmentation fault on 2.0.5
by Radu Anghel 14 Aug '19

14 Aug '19

Hello, I recently upgraded BIRD from 2.0.4 to 2.0.5 and with the same (pretty large) .conf I got Segmentation fault. Until today I didn't have time to debug it, but here it goes: With this simple .conf I get seg fault on 2.0.5 while 2.0.4 works as expected. (if I define myvar = true it doesn't crash on 2.0.5) log syslog all; define myvar = false; function something () { if myvar then { return false; } return true; } protocol device DEVICE { } Could this be because of the new filter code or something else? Radu

3 3

BGP table size
by Emerson Barea 13 Aug '19

13 Aug '19

Hi. Anyone knows if Bird documentation has any information about BGP table size vs. number of routes? Thanks. Emerson

7 13

Some patches for FreeBSD
by Vincent Bernat 12 Aug '19

12 Aug '19

Hey! Here are a few patches for FreeBSD. They are targeted to the "legacy" branch, but the two last ones can be applied to the master branch as well.

3 5