Hello List,

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) 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.

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:

root@sendak ~ # ip monitor | grep --line-buffered 2001:1568::/33 | gawk '{ print strftime(), $0 }' 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 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 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 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 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 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 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

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:
root@lotor ~ # ip monitor | grep --line-buffered 2001:1568::/33
<empty>

I set different timers on the kernel protocols because trying to debug these was just too much noise in my logs.

As I don't think that this is desired behavior, has anyone else noticed this? 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), 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. 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.


The (I think) relevant parts for the config on the 2nd router with the tunnel are:

ipv4 table master4;
ipv6 table master6;

mpls table mtab;
mpls domain mdom {
    label range bgprange { start 2000; length 1000; };
}
vpn4 table vpntab4;
vpn6 table vpntab6;

ipv4 table t_as207781_ipv4;
ipv6 table t_as207781_ipv6;

protocol device
{
    scan time 5;
}

protocol kernel
{
    scan time 60;
    mpls { table mtab; export all; };
}

protocol kernel
{
    scan time 30; <- this timer causes BIRD to re-export the whole table over and over again
    learn;

    vrf "vrf-as207781";
    kernel table 1;

    ipv6 {
        table t_as207781_ipv6;
        import none;
        export accept;
    };
}

protocol ospf v3 o_mclnet_ipv6 {
    vrf default;

    ipv6 {
        import all;
        export where source ~ [ RTS_DEVICE, RTS_STATIC ];
    };

    area 0 {
        interface "l2tp*" {
            hello 1;
            type pointopoint;
        };
        interface "br*", "dummy*" {
            stub;
        };
    };
}

protocol l3vpn m_as207781 {
        vrf "vrf-as207781";
        ipv4 { table t_as207781_ipv4;  };
        ipv6 { table t_as207781_ipv6;  };
        vpn4 { table vpntab4; };
        vpn6 { table vpntab6; };
        mpls { label policy vrf; };

        rd 64512:1;
        import target [(rt, 64512, 1)];
        export target [(rt, 64512, 1)];
}

protocol bgp i_lotor {

        mpls { label policy aggregate; };
        vpn4 mpls { table vpntab4; import all; export all; extended next hop on; next hop self on; };         vpn6 mpls { table vpntab6; import all; export all; extended next hop on; next hop self on; };
        local fd00::3 as 64512;
        neighbor fd00::2 as 64512;
}

Kind regards,

Marcel Menzel

Reply via email to