RSS networking configuration is easy to get wrong

When setting up a BGP configuration involving VLANs there are a few places to supply VLAN ids

• The peer: means that routes that are learned through the peer have a VLAN tag applied
• The address: means a VLAN device is created for the address to live on, so the subnet route associated with that address is tagged. This means the peer connection is on a tagged VLAN segment.

For simple (most?) deployments, the BGP control plane traffic (peering traffic) and learned routes are on the same VLAN. However it is valid for these to be different:

• BGP control plane may be untagged and data plane may be tagged or vice versa.
• BGP control plane and data plane may be on different VLANs.
• Different peers may be on different VLANs which may be coupled or distinct from their BGP control plane traffic.

This makes writing useful validators hard to do. To solve that we should update our RSS configuration interface to be explicit about whether BGP control plane and data plane VLANs are coupled. Either users provide a single VLAN per peer/address combination for a coupled configuration, or they explicitly specify things are decoupled.

Start by locating the RSS configuration interface and its validation logic. Read the peer and address VLAN semantics described here, then determine how the interface can explicitly represent coupled versus decoupled BGP control-plane and data-plane VLANs. Done means the configuration makes that relationship explicit and supports the listed valid combinations.