Description
Implementing MEP-18 (Autonomous Control Plane) involves setting up a network where the seed k3s-cluster can communicate with the shoot cluster that will host the metal-stack (and gardener) control plane. Since the k3s workers cannot themselves be managed by metal-stack we have to statically configure the VRF for this communication on the leaf-switches.
A VRF that is shared via EVPN includes configuring the following ConfigDB fields on a SONiC switch:
- VRF
- VLAN
- VLAN_INTERFACE
- INTERFACE
- VXLAN_TUNNEL_MAP
- VLAN_SUPPRESS_NEIGH
- VLAN_MEMBER
There are two options:
- either allow passing the metal-core some predefined VRFs including members, VNI and VLAN
- or configure all of those fields without metal-core and tell metal-core to ignore the static VRFs
One question is, how do we prevent the VNIs from colliding with metal-api provided VNIs? Should the VNI-pool in the metal-api be configurable?
Description
Implementing MEP-18 (Autonomous Control Plane) involves setting up a network where the seed k3s-cluster can communicate with the shoot cluster that will host the metal-stack (and gardener) control plane. Since the k3s workers cannot themselves be managed by metal-stack we have to statically configure the VRF for this communication on the leaf-switches.
A VRF that is shared via EVPN includes configuring the following ConfigDB fields on a SONiC switch:
There are two options:
One question is, how do we prevent the VNIs from colliding with metal-api provided VNIs? Should the VNI-pool in the metal-api be configurable?