<!DOCTYPE html>
<html data-lt-installed="true">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body style="padding-bottom: 1px;">
<font size="4">Hello List,<br>
<br>
I am doing a test setup with the new MPLS L3VPN feature (for
background information: I am running IPsec with L2TP on top, with
OSPF as IGP and iBGP between loopbacks)<br>
with one router receiving an IPv6 fulltable via eBGP and the other
one establishing the BGP session through a tunnel described above,
and I noticed periodic high CPU usage on the router receiving the
routes at the end of the tunnel.<br>
<br>
It seems, that BIRD keeps exporting the whole table to the kernel
every 30 seconds, as it is configured in the kernel protocol scan
time with the "vrf" directive set:<br>
<br>
root@sendak ~ # ip monitor | grep --line-buffered 2001:1568::/33 |
gawk '{ print strftime(), $0 }'<br>
Sat Jan 27 13:21:10 CET 2024 2001:1568::/33 encap mpls 1000 via
fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32
pref medium<br>
Sat Jan 27 13:21:40 CET 2024 2001:1568::/33 encap mpls 1000 via
fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32
pref medium<br>
Sat Jan 27 13:22:09 CET 2024 2001:1568::/33 encap mpls 1000 via
fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32
pref medium<br>
Sat Jan 27 13:22:37 CET 2024 2001:1568::/33 encap mpls 1000 via
fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32
pref medium<br>
Sat Jan 27 13:23:04 CET 2024 2001:1568::/33 encap mpls 1000 via
fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32
pref medium<br>
Sat Jan 27 13:23:30 CET 2024 2001:1568::/33 encap mpls 1000 via
fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32
pref medium<br>
Sat Jan 27 13:23:57 CET 2024 2001:1568::/33 encap mpls 1000 via
fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32
pref medium<br>
<br>
although there's no update for that route (I'm taking here the
prefix to monitor where the bird webserver lies in) received from
upstream:<br>
root@lotor ~ # ip monitor | grep --line-buffered 2001:1568::/33<br>
<empty><br>
<br>
I set different timers on the kernel protocols because trying to
debug these was just too much noise in my logs.<br>
<br>
As I don't think that this is desired behavior, has anyone else
noticed this?<br>
It might also be that systemd-networkd or strongswan keeps
interfering here (at least systemd-networkd shows high CPU usage
when the kernel RIB changes, strongswan did this aswell but I
tweaked config for it to ignore BIRD routes),<br>
but I don't see the reason why.
"ManageForeignRoutingPolicyRules=no" and "ManageForeignRoutes=no"
is set in networkd.conf and the ip monitor above only shows
inserts.<br>
The setup without MPLS but with separate XFRM tunnels per VRF
(that's why I want to use L3VPN, to just have 1 Tunnel with MPLS
on top) works flawlessly.<br>
<br>
<br>
The (I think) relevant parts for the config on the 2nd router with
the tunnel are:<br>
<br>
ipv4 table master4;<br>
ipv6 table master6;<br>
<br>
mpls table mtab;<br>
mpls domain mdom {<br>
label range bgprange { start 2000; length 1000; };<br>
}<br>
vpn4 table vpntab4;<br>
vpn6 table vpntab6;<br>
<br>
ipv4 table t_as207781_ipv4;<br>
ipv6 table t_as207781_ipv6;<br>
<br>
protocol device<br>
{<br>
scan time 5;<br>
}<br>
<br>
protocol kernel<br>
{<br>
scan time 60;<br>
mpls { table mtab; export all; };<br>
}<br>
<br>
protocol kernel<br>
{<br>
scan time 30; <- this timer causes BIRD to re-export the
whole table over and over again<br>
learn;<br>
<br>
vrf "vrf-as207781";<br>
kernel table 1;<br>
<br>
ipv6 {<br>
table t_as207781_ipv6;<br>
import none;<br>
export accept;<br>
};<br>
}<br>
<br>
protocol ospf v3 o_mclnet_ipv6 {<br>
vrf default;<br>
<br>
ipv6 {<br>
import all;<br>
export where source ~ [ RTS_DEVICE, RTS_STATIC ];<br>
}; <br>
<br>
area 0 {<br>
interface "l2tp*" {<br>
hello 1;<br>
type pointopoint;<br>
};<br>
interface "br*", "dummy*" {<br>
stub;<br>
};<br>
};<br>
}<br>
<br>
protocol l3vpn m_as207781 {<br>
vrf "vrf-as207781";<br>
ipv4 { table t_as207781_ipv4; };<br>
ipv6 { table t_as207781_ipv6; };<br>
vpn4 { table vpntab4; };<br>
vpn6 { table vpntab6; };<br>
mpls { label policy vrf; };<br>
<br>
rd 64512:1;<br>
import target [(rt, 64512, 1)];<br>
export target [(rt, 64512, 1)];<br>
}<br>
<br>
protocol bgp i_lotor {<br>
<br>
mpls { label policy aggregate; };<br>
vpn4 mpls { table vpntab4; import all; export all;
extended next hop on; next hop self on; };<br>
vpn6 mpls { table vpntab6; import all; export all;
extended next hop on; next hop self on; };<br>
local fd00::3 as 64512;<br>
neighbor fd00::2 as 64512;<br>
}<br>
<br>
Kind regards,<br>
<br>
Marcel Menzel</font>
</body>
<lt-container></lt-container>
</html>