This ticket is to track the design of the target vxlan-based network setup for Cloud VPS.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T270694 CloudVPS: introduce tenant networks | |||
| Resolved | • aborrero | T364725 Migrate Cloud VPS instances to VXLAN based networks | |||
| Resolved | • aborrero | T373869 Cloud VPS: design target vxlan setup |
Event Timeline
Comment Actions
This is a preliminary plan / idea.
The target setup is as follows:
- we have no vlan-based network in the system.
- we have a single, flat vxlan-based network which can be used in a similar fashion as the vlan-based one we have today (legacy). We call this network cloud-flat, for example.
- the network has a different addressing than the legacy one.
- tenant VMs be directly connected to this cloud-flat network.
- the main neutron router as a port in this cloud-flat network.
- this network can also serve as a "trunk" network for future tenant networks. This is, a tenant router will connect to this subnet for it to have external connectivity.
- the CIDR can be 172.16.8.0/22 (1k addresses) or 172.16.8.0/21 (2k addresses)
In order to reach this target, we will have an intermediary setup, in which both the legacy vlan-based subnet and the new cloud-flat one will co-exists.
- VMs connected to any of the two subnets will have full connectivity network-wise (but firewalling may happen as usual, via neutron security groups)
- at some point, we will disable creation of new VMs connected to the old network
A diagram to illustrate the different stages:
Comment Actions
How do we allow users to create VMs on a different subnet? The horizon 'new vm' panel doesn't show the option. Having a default one is also fine, maybe.
Any idea @Andrew ?
Comment Actions
in a meeting, I shared this design today with @cmooney @dcaro and @fnegri with no major objections and a few comments:
- We need to double check that the VXLAN tunnels are actually circulating using cloud-private.
- We need to double check the MTU settings on the affected interfaces and subnets.
- We will need to revisit the tenant network bits when we get there. Having the single flat subnet in between the routers may not be what we want after all. But this doesn't invalidate the rest of the plan.
Comment Actions
To keep with the pattern in netbox, we will attach the deployment suffix to the network name:
- cloud-flat-eqiad1
- cloud-flat-codfw1dev