- Bird-users - Mailing Lists

Re: 100% CPU load with device scanning enabled
by Saso Tavcar 07 May '19

07 May '19

Hi, this is an OVS issue, already discussed: https://mail.openvswitch.org/pipermail/ovs-discuss/2016-November/043007.html <https://mail.openvswitch.org/pipermail/ovs-discuss/2016-November/043007.html> ... https://mail.openvswitch.org/pipermail/ovs-discuss/2016-November/043063.html <https://mail.openvswitch.org/pipermail/ovs-discuss/2016-November/043063.html> Official OVS quote: > We'd accept patches to improve OVS's routing table code. It's not > designed to scale to 1,800,000 routes. We'd also take code to suppress > the routing table code in cases where it isn't actually needed, since > it's not always needed. But we can't take a patch to just delete it; > I'm sure you understand. I tried to apply this patch at that time, but was already useless for newer versions: https://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20161123/537… <https://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20161123/537…> Our workaround was to scale VM with 3 vCPU-s, since our average system load is 1.5 for BGP. You can see what is happening: [root@bgp1 ~]# top ... PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 654 root 10 -10 1284492 1.0g 20276 R 98.0 27.0 2513:01 ovs-vswitchd 16 root 20 0 0 0 0 S 2.0 0.0 24:45.60 ksoftirqd/1 [root@bgp1 ~]# ip route show ... 1.0.0.0/24 via 89.212.47.185 dev t2-v24-ha proto bird 1.0.4.0/24 via 89.212.47.185 dev t2-v24-ha proto bird 1.0.4.0/22 via 89.212.47.185 dev t2-v24-ha proto bird 1.0.5.0/24 via 89.212.47.185 dev t2-v24-ha proto bird Routes being constantly added and deleted: [root@bgp1 ~]# ip monitor ... Deleted 2620:11d:6000::/42 via 2a01:260:1021::1 dev t2-v26-ha proto bird metric 1024 pref medium 2620:11d:6000::/42 via 2a01:260:1021::1 dev t2-v26-ha proto bird metric 1024 pref medium Deleted 2620:11d:6000::/42 via 2a01:260:1021::1 dev t2-v26-ha proto bird metric 1024 pref medium 2620:11d:6000::/42 via 2a01:260:1021::1 dev t2-v26-ha proto bird metric 1024 pref medium Deleted 2620:11d:6000::/42 via 2a01:260:1021::1 dev t2-v26-ha proto bird metric 1024 pref medium 2620:11d:6000::/42 via 2a01:260:1021::1 dev t2-v26-ha proto bird metric 1024 pref medium Deleted 68.69.37.0/24 via 89.212.47.185 dev t2-v24-ha proto bird 68.69.37.0/24 via 89.212.47.185 dev t2-v24-ha proto bird Deleted 103.115.180.0/22 via 89.212.47.185 dev t2-v24-ha proto bird 103.115.180.0/22 via 89.212.47.185 dev t2-v24-ha proto bird Deleted 103.115.180.0/22 via 89.212.47.185 dev t2-v24-ha proto bird 103.115.180.0/22 via 89.212.47.185 dev t2-v24-ha proto bird Deleted 2.16.70.0/23 via 89.212.47.185 dev t2-v24-ha proto bird Deleted 88.221.28.0/22 via 89.212.47.185 dev t2-v24-ha proto bird Deleted 23.50.188.0/22 via 89.212.47.185 dev t2-v24-ha proto bird Deleted 92.122.68.0/22 via 89.212.47.185 dev t2-v24-ha proto bird Deleted 88.221.100.0/22 via 89.212.47.185 dev t2-v24-ha proto bird Deleted 92.123.208.0/22 via 89.212.47.185 dev t2-v24-ha proto bird ..... Regards, saso > On 6 May 2019, at 19:30, Kees Meijs <kees(a)nefos.nl <mailto:kees@nefos.nl>> wrote: > > Hi list, > > We're in the process of replacing Quagga with BIRD but stumble upon a > little problem. > > When device scanning is on (obviously default) our testing machine > completely fills up a CPU core. The culprit isn't BIRD itself but an > Open vSwitch daemon. > > After disabling the device protocol and restarting BIRD, everything goes > back to it's quiet state. > > BIRD (1.6.3-2) and Open vSwitch (2.6.2~pre+git20161223-3) both were > installed as Debian stable packages. > > The configuration is as simple as: > >> # This is a minimal configuration file, which allows the bird daemon >> to start >> # but will not cause anything else to happen. >> # >> # Please refer to the documentation in the bird-doc package or BIRD User's >> # Guide on http://bird.network.cz/ <http://bird.network.cz/> for more information on configuring >> BIRD and >> # adding routing protocols. >> >> # Change this into your BIRD router ID. It's a world-wide unique >> identification >> # of your router, usually one of router's IPv4 addresses. >> router id 1.2.3.4; >> >> # The Device protocol is not a real routing protocol. It doesn't >> generate any >> # routes and it only serves as a module for getting information about >> network >> # interfaces from the kernel. >> protocol device { >> } >> >> # The Kernel protocol is not a real routing protocol. Instead of >> communicating >> # with other routers in the network, it performs synchronization of BIRD's >> # routing tables with the OS kernel. >> protocol kernel { >> metric 64; # Use explicit kernel route metric to avoid collisions >> # with non-BIRD routes in the kernel routing table >> import none; >> export all; # Actually insert routes into the kernel routing table >> } >> >> protocol bgp test { >> description "BGP test"; >> local as REDACTED; >> neighbor 1.2.3.4 as REDACTED; >> direct; >> next hop self; >> deterministic med on; >> export none; >> import all; >> } > > Meanwhile log messages such as below arise: > >> bird: Kernel dropped some netlink messages, will resync on next scan. > > For a test I deleted all existing Open vSwitch bridges and the load > dropped again. After adding an empty new bridge, the load spikes again > in an instant. > > This is unexpected behaviour. Maybe it's an implementation problem in > Open vSwitch or maybe in BIRD. Anyway, it should happen I guess. > > Any clues? > > Thanks in advance! > > Regards, > Kees > >

5 9

100% CPU load with device scanning enabled
by Kees Meijs 06 May '19

06 May '19

Hi list, We're in the process of replacing Quagga with BIRD but stumble upon a little problem. When device scanning is on (obviously default) our testing machine completely fills up a CPU core. The culprit isn't BIRD itself but an Open vSwitch daemon. After disabling the device protocol and restarting BIRD, everything goes back to it's quiet state. BIRD (1.6.3-2) and Open vSwitch (2.6.2~pre+git20161223-3) both were installed as Debian stable packages. The configuration is as simple as: > # This is a minimal configuration file, which allows the bird daemon > to start > # but will not cause anything else to happen. > # > # Please refer to the documentation in the bird-doc package or BIRD User's > # Guide on http://bird.network.cz/ for more information on configuring > BIRD and > # adding routing protocols. > > # Change this into your BIRD router ID. It's a world-wide unique > identification > # of your router, usually one of router's IPv4 addresses. > router id 1.2.3.4; > > # The Device protocol is not a real routing protocol. It doesn't > generate any > # routes and it only serves as a module for getting information about > network > # interfaces from the kernel. > protocol device { > } > > # The Kernel protocol is not a real routing protocol. Instead of > communicating > # with other routers in the network, it performs synchronization of BIRD's > # routing tables with the OS kernel. > protocol kernel { > metric 64; # Use explicit kernel route metric to avoid collisions > # with non-BIRD routes in the kernel routing table > import none; > export all; # Actually insert routes into the kernel routing table > } > > protocol bgp test { > description "BGP test"; > local as REDACTED; > neighbor 1.2.3.4 as REDACTED; > direct; > next hop self; > deterministic med on; > export none; > import all; > } Meanwhile log messages such as below arise: > bird: Kernel dropped some netlink messages, will resync on next scan. For a test I deleted all existing Open vSwitch bridges and the load dropped again. After adding an empty new bridge, the load spikes again in an instant. This is unexpected behaviour. Maybe it's an implementation problem in Open vSwitch or maybe in BIRD. Anyway, it should happen I guess. Any clues? Thanks in advance! Regards, Kees

1 2

Full (regression) test suite?
by Robert Scheck 04 May '19

04 May '19

Hello all, is there something like a full (regression) test suite for BIRD that one could run after building BIRD 2.0.x? Regards, Robert

4 10

Nested filters
by amphineko 02 May '19

02 May '19

Hello there, I'm a newbie to BIRD, using BIRD 1.6.3 and setting up my first router. I have multiple filters which filter different subnets and apply different attribute modifications. Currently I put my subnet checks in a function which returns true if a subnet matches, and invoke the function in a filter like this: function is_asxxxx() { if net ~ [114.51.4.0/24] then return true; return false; } function is_asyyyy() { if net ~ [19.19.81.0/24] then return true; return false; } filter f_customers { if is_asxxxx() then accept; if is_asyyyy() then { bgp_community.add((114514, 191981)); accept; } reject; } I'm wondering if I can invoke other filters inside a filter, so the is_asxxx can also used as an filter. I can't find an example to achieve this. Regards, Naoki Kobayashi

3 2

ibgp bird 1.6 vs 2.0
by Matěj Grégr 30 Apr '19

30 Apr '19

Hello, we have encountered a different ibgp behavior between bird 1.6 and bird2, and I am not sure if it's an intentional change in bird2 or a bug. Let's consider the following topology: 192.168.1.0/24 192.168.2.0/24 R1 ------- ebgp ------- R2 ------- ibgp ------- R3 .2 .1 .1 .2 R1 uses AS 65001, R2 and R3 uses AS 65000. R1 propagates some routes (e.g. 10.10.10.0/24) via eBGP to R2, which sends them to R3 via iBGP. bird2 config on R3: template bgp IBGP { local as 65000; direct; ipv4 { next hop self; import keep filtered on; import all; }; } protocol bgp from IBGP { neighbor 192.168.2.1 as 65000; } Now there are two issues: 1) the bird on R3 reports "Invalid NEXT_HOP attribute" and doesn't learn any R1 routes from R2. If the "direct" option is removed from the config, R3 will learn R1 routes. However, if R3 runs bird1.6, it learns all routes even with the direct option. According to the docs, "direct" is a check for directly connected neighbors. The neighbor 192.168.2.1 is directly connected and in the same subnet, so I don't understand, why there is an issue with NEXT_HOP and why are routes silently dropped on R3? 2) If direct is removed from the config, bird2 on R3 learns R1 routes, but with status unreachable. Even if I send 192.168.1.0/24 from R2 to R3 so the route 192.168.1.0/24 is in R3's routing table and ping from R3 to the NEXT_HOP IP address is successful. bird1.6 works without a problem with or without direct option and all routes are learned and reachable. According to the docs, iBGP should find route to NEXT_HOP IP address in its routing table, so why are the routes marked as unreachable in bird2, if the route is there? Thank you and best regards, M.

2 4

[PATCH] Nest: "Last route change" timestamp for routing tables
by Tom Petty 30 Apr '19

30 Apr '19

I¹ve written a patch which adds a ³last route change² timestamp to the routing table statistics. This diff is against the Œmaarten¹ branch, where the code adding the ³show table statistics² command is currently located. diff --git a/nest/route.h b/nest/route.h index c7c44ecc..8472b432 100644 --- a/nest/route.h +++ b/nest/route.h @@ -166,6 +166,7 @@ typedef struct rtable { uint route_count; /* Number of routes in the table */ uint route_updates; /* Number of accepted route updates */ uint route_withdraws; /* Number of accepted route withdraws */ + btime last_route_change; /* Time of last route change */ struct hostcache *hostcache; struct rtable_config *config; /* Configuration of this table */ struct config *deleted; /* Table doesn't exist in current configuration, diff --git a/nest/rt-table.c b/nest/rt-table.c index efc1f1d7..116e8756 100644 --- a/nest/rt-table.c +++ b/nest/rt-table.c @@ -1143,9 +1143,9 @@ rte_recalculate(struct channel *c, net *net, rte *new, struct rte_src *src) skip_stats1: if (new_ok) - table->route_count++; + { table->route_count++; table->last_route_change = current_time(); } if (old_ok) - table->route_count--; + { table->route_count--; table->last_route_change = current_time(); } if (new) rte_is_filtered(new) ? stats->filt_routes++ : stats->imp_routes++; @@ -1668,6 +1668,7 @@ rt_setup(pool *p, rtable *t, struct rtable_config *cf) t->rt_event->hook = rt_event; t->rt_event->data = t; t->gc_time = current_time(); + t->last_route_change = current_time(); } /** @@ -2299,7 +2300,7 @@ rte_update_in(struct channel *c, const net_addr *n, rte *new, struct rte_src *sr *pos = old->next; rte_free_quick(old); tab->route_count--; - + tab->last_route_change = current_time(); break; } @@ -2333,6 +2334,7 @@ rte_update_in(struct channel *c, const net_addr *n, rte *new, struct rte_src *sr e->next = *pos; *pos = e; tab->route_count++; + tab->last_route_change = current_time(); return 1; drop_update: @@ -2406,6 +2408,7 @@ rt_prune_sync(rtable *t, int all) *ee = e->next; rte_free_quick(e); t->route_count--; + t->last_route_change = current_time(); } else ee = &e->next; @@ -2711,6 +2714,9 @@ rt_get_hostentry(rtable *tab, ip_addr a, ip_addr ll, rtable *dep) static void rt_show_table_stats(rtable *tab) { + byte tm[TM_DATETIME_BUFFER_SIZE]; + tm_format_time(tm, &config->tf_route, tab->last_route_change); + cli_msg(-1026, "%s:", tab->name); cli_msg(-1026, "Table type:\t\t%s", net_label[tab->addr_type]); cli_msg(-1026, "Hash table size:\t%u", tab->fib.hash_size); @@ -2718,6 +2724,7 @@ rt_show_table_stats(rtable *tab) cli_msg(-1026, "Total route count:\t%u", tab->route_count); cli_msg(-1026, "Route updates:\t\t%u", tab->route_updates); cli_msg(-1026, "Route withdraws:\t%u", tab->route_withdraws); + cli_msg(-1026, "Last route update:\t%s", tm); cli_msg(-1026, ""); cli_msg(-1026, "%-16s %10s %10s %10s %10s", "Protocol", "Routes", "Preferred", "Updates", "Withdraws"); Thanks, Tom P

2 2

RFC8203bis
by Alexander Azimov 30 Apr '19

30 Apr '19

Hi all, I've just submitted a two-line patch to make BIRD compliant with RFC8203bis <https://datatracker.ietf.org/doc/draft-ietf-idr-rfc8203bis/>: https://github.com/BIRD/bird/pull/5 Please let me know if you have any questions. -- Best regards, Alexander Azimov

2 1

Static dormant routes not shown
by Kenth Eriksson 29 Apr '19

29 Apr '19

Hi! Why does not static routes in dormant state show of up in the routing table? I expexted all routes to be visible in 'show route'. If the route is not installed into the kernel, then that should be some way (in bird case I believe that is the exclamation mark). Thanks, Kenth

2 2

RFC7772 Unicast RAdv Replies
by Martin Weinelt 29 Apr '19

29 Apr '19

Hi all, we're users of Birds RAdv implementation in a mesh networking project with many opportunistic WiFi users on mobile devices. We and our users would likely profit from a reduced rate of router advertisments that we see as a result from high client turnover. RFC7772¹ describes in 5.1: Router manufacturers SHOULD allow network administrators to configure the routers to respond to Router Solicitations with unicast Router Advertisements if: * The Router Solicitation's source address is not the unspecified address, and: * The solicitation contains a valid Source Link-Layer Address option. 2. Administrators of networks that serve large numbers (tens or hundreds) of battery-powered devices SHOULD enable this behavior. 3. Networks that serve battery-powered devices SHOULD NOT send multicast RAs too frequently (see Section 4) unless the information in the RA packet has substantially changed. If there is a desire to ensure that hosts pick up configuration changes quickly, those networks MAY send frequent Router Advertisements for a limited period of time (e.g., not more than one minute) immediately after a configuration change. There is already an implementation for this behaviour in radvd² with the peculiarity that they ignore missing SLLA, because little to no clients actually sent them back in 2017. Note that the RFC does not make SLLA a MUST. They justify unicast responses in absence of SLLA as follows: However, testing shows that many clients do not set the SLLA option: https://github.com/reubenhwk/radvd/issues/63#issuecomment-287172252 As of 2017/03/16: - macOS 10.12.3 sierra - sends SLLA 2 times out of 4 - iOS 10.2.1 (iPhone 5s) - no SLLA - Android 7.0 (sony xperia phone) - sends SLLA - Android 5.1 (nexus 7 tablet) - sends SLLA - Ubuntu 16.04.2 LTS w/ Network Manager, running 4.9 kernel (dell laptop) - no SLLA - Windows 10 (dell laptop) - no SLLA We decide to ignore the SLLA option for now, and only require the unspecified address check. Clients that did not set the SLLA option will trigger a neighbour solicit to the solicited-node address trying to resolve the link-local address to, this would still be less traffic than the all-nodes multicast. I'd be very happy if you would consider implementing this BCP and would especially appreciate it if there were a knob to make Bird reply with unicast radv replies to router solications and only use multicast advertisments in larger intervals. Thanks for your consideration! Martin Weinelt [1] https://tools.ietf.org/html/rfc7772 [2] https://github.com/reubenhwk/radvd/commit/30328bdbfc1f08ea100de9a6011f981cc…

2 1

[PATCH] BGP: Output Local AS number in show protocol
by Jan-Philipp Litza 29 Apr '19

29 Apr '19

This eases the implementation of agents implementing the SNMP-BGP MIB, which requires the local AS of a session to be specified. --- proto/bgp/bgp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/proto/bgp/bgp.c b/proto/bgp/bgp.c index c332a836..9013e8ea 100644 --- a/proto/bgp/bgp.c +++ b/proto/bgp/bgp.c @@ -2259,6 +2259,7 @@ bgp_show_proto_info(struct proto *P) cli_msg(-1006, " BGP state: %s", bgp_state_dsc(p)); cli_msg(-1006, " Neighbor address: %I%J", p->cf->remote_ip, p->cf->iface); cli_msg(-1006, " Neighbor AS: %u", p->cf->remote_as ?: p->remote_as); + cli_msg(-1006, " Local AS: %u", p->cf->local_as ?: p->local_as); if (p->gr_active_num) cli_msg(-1006, " Neighbor graceful restart active"); -- 2.17.1

2 1