macvlan and vr-based nodes

[hellt]

It has been reported that vr-based nodes have datapath connectivity issue when using the macvlan mode.

Considering the following topology:

name: mvlantest


topology:
  kinds:
    vr-sros:
      image: vrnetlab/vr-sros:22.5.R1
      license: license-vsr-i-22.txt
 
  nodes:
    pe1:
      kind: vr-sros

  links:
    - endpoints: ["pe1:eth1", "macvlan:ens33"]

the following has been observed:

The ping replies initiated from vr node to an IP reachable from the macvlan segment do not propagate to the macvlan interface from the parent interface:

I think this might be related to the tc mirred redirect rules, which might require some tuning for macvlan interfaces?

[hellt]

setting the macvlan mode to passthru solved this
need to check if our default bridge mode must be switched to passthru

[steiler]

Passthru: allows a single VM to be connected directly to the physical interface.

I don't think this is what we want?!
I exposed the mode in the extensive version of the MacVlan link definition. So simply set it that way.
https://containerlab.dev/manual/topo-def-file/#macvlan

[hellt]

the question is why in bridge mode connectivity breaks, and what passthru does differently

[marcosfsch]

I was testing this scenario and confirm that connectiviy works only with passthru mode, but LLDP doesn't. I fixed the issue setting the corresponding ethX contaner interface to promiscuous mode.
I believe the reason why bridge mode doesn't work is because the interface insede QEMU is using a different mac address than tha macvlan interface. Probably if it uses the same one it should work transparently.