Limit OSPF interface pattern matching to VRFs

2023-01-22 Thread Marcel Menzel via Bird-users

Hello list,

Is there a way to instruct BIRD to only match OSPF interfaces that are 
enslaved to a certain VRF (or only the main VRF / not enslaved to any VRF)?


Trying to set 'vrf default;' or 'vrf "vrf-as207781";' in an OSPF 
protocol block does not generate any error message at all, but seems to 
be ignored completely.


Looking at "show ospf int" show BIRD picking up all interfaces (in my 
case xfrm and veth interfaces, because I match for "xfrm*" and "veth*") 
not belonging to the VRF specified.


The config block for running OSPF in the main VRF looks like this:

protocol ospf v3 o_home_ipv6 {
    vrf default;

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

    area 0 {
    interface "xfrm0", "xfrm2" {
    #interface "xfrm*" {
    hello 1;
    type pointopoint;
    };
    interface "br0" {
    #interface "br*" {
    stub;
    };
    };
}

The config block for running OSPF in one VRF looks like this:

protocol ospf v3 o_as207781_ipv6 {
    vrf "vrf-as207781";

    ipv6 {
    table t_as207781_ipv6;
    import all;
    export where source ~ [ RTS_DEVICE ];
    };

    area 0 {
    #interface "xfrm1", "xfrm3" {
    interface "xfrm*" {
    hello 1;
    type pointopoint;
    };
    #interface "veth0", "veth2", "dummy0" {
    interface "veth*", "dummy*" {
    stub;
    };
    };
}

Yet BIRD picks up all interfaces in all VRFs, although xfrm0 & xfrm2 are 
not enslaved, and xfrm1 & xfrm3 are VRF enslaved:


root@r1-fra ~ # birdc sh ospf int o_home_ipv6 | grep xfrm
Interface xfrm0 (IID 0)
Interface xfrm2 (IID 0)
Interface xfrm1 (IID 0)
Interface xfrm3 (IID 0)
root@r1-fra ~ # birdc sh ospf int o_as207781_ipv6 | grep xfrm
Interface xfrm1 (IID 0)
Interface xfrm3 (IID 0)
Interface xfrm0 (IID 0)
Interface xfrm2 (IID 0)

I am running BIRD 2.0.11 on Kernel 6.1.7. My current workaround is to 
specify each interface directly in the OSPF blocks without using any 
globbing/patterns at all, but this is getting uncomfortable for an 
increasing amount of interfaces (as I am planning to move to LXD routed 
mode and match it's veth interfaces automatically).



Thanks & kind regards,

Marcel Menzel


Re: Limit OSPF interface pattern matching to VRFs

2023-01-22 Thread Marcel Menzel via Bird-users

Hello Ondrej,


Here is a fix:

https://gitlab.nic.cz/labs/bird/-/commit/a82683694da23799f247b3392a00efdd342afdfc


Can confirm, that fix seems to work. Thaks for the quick response & fix 
on a sunday!


 - Marcel


Re: Question about MPLS L3VPN

2024-01-27 Thread Marcel Menzel via Bird-users

Ondrej,

You can try attached patch.


Yes, that resolves it for me. Thank you for the very quick fix!

Question about MPLS L3VPN

2024-01-27 Thread Marcel Menzel via Bird-users

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


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

L3VPN and BGP add-path

2024-02-25 Thread Marcel Menzel via Bird-users

Hello List,


I am running the new MPLS L3VPN feature for quite a while now, and it's 
working without issues so far for me, but I have one question:


I set "add paths on;" on my iBGP peer template in all SAFIs and while it 
was running successfully before the migration to L3VPN, the additional 
routes in the RIB are now gone, but the capabilities are still exchanged 
between peers.
Furthermore, I can't set "add paths on;" property for any SAFI in the 
L3VPN protocol, this might be the reason why those additional routes are 
missing?


My only question now is if this just hasn't been implemented yet with 
BIRD (I am just being curious hence I'm asking), my config is something 
missing or this being the general fact that add-path with MPLS L3VPN 
simply is not a thing with other vendors aswell (to be fair, I've never 
seen an L3VPN network with add-path enabled in production so far).



Thanks for the heads-up in advance,

Marcel