[BUG] SR Linux: BGP-in-VRF test scenarios fail

[ipspace]

Based on https://netlab-cicd.pages.dev/_html/srlinux-clab-vrf it looks like every test scenario that uses BGP in a VRF fails.

According to one validation log (https://netlab-cicd.pages.dev/srlinux/clab/vrf/12-multi-vrf-bgp.yml-validate.log) the BGP sessions are established, but the IPv4 routes are never propagated between the CE-routers

Lab topology @ https://github.com/ipspace/netlab/blob/dev/tests/integration/vrf/12-multi-vrf-bgp.yml

[jbemmel]

vrfs:
  blue:
    af:
      ipv4: true
    bgp:
      neighbors:
      - as: 65103
        ifindex: 3
        ipv4: 10.1.0.10
        name: r3
        type: ebgp
      - as: 65104
        ifindex: 4
        ipv4: 10.1.0.14
        name: r4
        type: ebgp
    export:
    - '65000:2'
    id: 2
    import:
    - '65000:2'
    rd: '65000:2'
    vrfidx: 101

Based on the topology file, the BGP policies are importing routes with community 65000:2. The FRR instances are not sending any communities, so no routes are imported

[jbemmel]

I'm thinking this may be a misunderstanding of semantics - it's a mismatch between VRF leaking and EBGP routes sent from a peer without VRFs

See https://github.com/ipspace/netlab/blob/dev/docs/module/vrf.md: "Missing import and export route targets become a list with the VRF RD being the sole element"

[ipspace]

The 'import' and 'export' thingies are Route Target extended BGP communities (introduced in MPLS/VPN, now also used in EVPN), not the standard BGP communities set by BGP peers.

The CE routers (R1 through R4) have no idea they're connected to a VRF, and you wouldn't want your customers to specify in which VRF they want to be anyway.

The "Missing import and export route targets become a list with the VRF RD being the sole element" bit specifies what happens if you don't specify the import/export RT. In that case, each VRF gets its own RT, which means they're effectively isolated.