The new cage in codfw cannot support direct layer-2 adjacency to our LVS servers, meaning we can only support services behind LVS there which use IPIP encapsulation.
(NOTE) I've edited this description based on feedback to list out the hosts we should avoid putting there for now.
**Background**
The new switches for {T380240} were ordered without the VXLAN license for Juniper, and the cage will be a hybrid of Juniper/Nokia (due to needing the racks online sooner than we would be able to support a full Nokia setup). This rules our using VXLAN for layer-2 extension in the new cage.
That decision was made after discussions at the SRE Summit which suggested that by the time the racks went live we would no longer have any services dependent on the layer-2 connectivity from LVS load-balancers. But I think we need to assess exactly where we are with that.
**Hostname List**
The main hosts we need to avoid racking in the new cage for now are the Kubernetes hosts (work to move them to IPIP is tracked in T352956). Additionally the cirrussearch hosts should be avoided (see T373020).
The full list of hostname prefixes we cannot rack in the new cage right away are:
```
aux-k8s-ctrl
aux-k8s-worker
cirrussearch
dse-k8s-ctrl
dse-k8s-worker
elastic
kubestage
kubestagemaster
ml-serve
ml-serve-ctrl
ml-staging
ml-staging-ctrl
wikikube-ctrl
wikikube-worker
```