[not-really-a-bug] VXLAN/EVPN misbehaviour?

[ssasso]

Feel free to insult or blame on me if I am wrong ;)

IN THEORY I could use VXLAN+EVPN with L3VNI only (and without VLANs - pure type5), to "replicate" a pure L3 VPN scenario (no L2 services).

However, this is not easily doable with netlab, because:

• VXLAN requires VLAN module
• When there are no vlans defined, the vxlan module does not create the vtep data

vxlan:
  domain: global
  flooding: evpn

instead of:

vxlan:
  domain: global
  flooding: evpn
  vlans:
  - fake
  vtep: 10.100.0.1
  vtep_interface: loopback 0

A workaround for it is to define a fake vlan at node level:

    vlans:
      fake:
        mode: bridge

I also tried to add:

vxlan.vlans: []

but the fake vlan is still inserted on the vxlan enabled ones (see above post-transformation extract).

[ipspace]

Just to be on the safe side, can you give me the (simplest possible) full topology?

I guess we have to improve the check whether there's a reason to use VXLAN, and it has to include "is there any VRF that has EVPN L3VNI"

[ssasso]

Here's the simplest topology:

provider: clab

addressing:
  loopback:
    ipv4: 10.100.0.0/24
    prefix: 32
  router_id:
    ipv4: 10.100.0.0/24
    prefix: 32

defaults.vxlan.start_vni: 20000
defaults.evpn.start_transit_vni: 10000

defaults.devices.arubacx:
  clab:
    image: vrnetlab/vr-aoscx:20231110145644

vrfs:
  tenant:
    ospf: false
    evpn.transit_vni: True

groups:
  ext:
    members: [ ext1, ext2 ]
    device: vyos
    module: [ bgp ]
  evpn:
    members: [ sw1, sw2 ]
    device: arubacx
    module: [ vlan, vrf, vxlan, ospf, bgp, evpn ]
    vlans:
      fake:
        mode: bridge
    vxlan.vlans: []
    bgp:
      as: 65000
      advertise_loopback: false
      activate:
        ipv4: [ ebgp ]

nodes:
  sw1:
    id: 1
  sw2:
    id: 2
  ext1:
    id: 11
    loopback:
      ipv4: 10.99.99.1/32
    bgp:
      as: 11
      originate: [ 100.100.11.0/24 ]
  ext2:
    id: 12
    loopback:
      ipv4: 10.99.99.2/32
    bgp:
      as: 12
      originate: [ 100.100.12.0/24 ]

links:
- sw1:
  sw2:

- sw1:
    vrf: tenant
  ext1:

- sw2:
    vrf: tenant
  ext2:

[ipspace]

As expected, the trigger is evpn.transit_vni within a VRF. That's exactly how I fixed it ;) Thanks for the confirmation!