Sahid Orentino Ferdjaoui
The proposed spec is to extend the current feature routed provider networks 0 to allow provisioning more than one segment per physical network.
There is currently a limitation for a compute node to only have an interface on one segment in a multisegment network. Operators that want to extend IP range will have to provision new networks which degrade user experience, or increase the broadcast domain which does not scale.
As an operator I want to extend IP pool without creating multiple networks. I also want to limit the brodcast domain.
The change is limited to
OVS agent, it will be still possible to
implement it for
linux-bridge. That is said, this implementation
is out of the scope of the proposed spec.
The main purpose is to add the support for an interface of a compute node to be attached to more than one segment of a given network.
This implies changes on different components. The DHCP agent currently only supports one interface per network. It will be necessary to extend it to support more domains per network. The VLAN manager that maintains details of VLAN ports for OVS by using network id will have to be updated to use segment id instead. The agent will have to be updated to support the feature and finally the limitation that rejects such case will have to be removed.
The current implementation for
VLAN manager that maintains
internal VLAN mapping to external network segmentation ids is using
network ids as principal identifier 1. This will have to
be updated to use a combination of
This should not implies upgrade impact as they are in-memory and
recalculated after restarts.
Using multiple segments per network implies more than one network domain. The current DHCP agent supports one domain per network 2.
A DHCP port is plugged to the internal bridge using the local VLAN
provided by the VLAN manager for a given network. This means that the
DHPC Process running can address reauest for one domain. To reflect
the current desire of multiple domains per network, a DHCP port should
be plugged to br-int per combination of
network id / segmentation
The proposed implementation is to avoid changing
logic to make it supporting more than one interface per VLAN as it
will add complexity and may imply upgrade impact. Instead, it has
been considered to keep the well trusted logic of the
to use one per segmentation id. One may in future consider to revisit
The benefit of having one
DHCP Process running per local VLAN will
limit the changes and avoid upgrade impact. For a deployment already
running routed network provider, two
DHCP process will be
running. One considered as legacy running under
an other running at
/seg-id/net-id/pid. It will involve the
operator to remove the legacy port using opentack API.
The proposed spec only implies OVS support but it should be possible to provide the same kind of support for
linux-bridge. A change has been proposed with 3 with related spec 5 It implies an upgrade impact which can be mitigated like for this proposed OVS implementation. Also that the
linux-bridgeimplementation can take benefit of the change in DHCP agent which is missed in the proposed change for
For a given fixed ip, during scheduling Nova will not be able creating a port a the segment related to the subnet of the fixed ip. It’s an already known limitation. Bug 1979959 9 has been reported to address the issue.
A regression has been noted since the bug 1952730 8, with routed provider segments created are not taken into account. Bug 1979958 7.
In its process Nova needs to retrieve network details 4. In case of a given network with multiple segments the process will use the first segment that it discovers with a
physcal_network. This is a design issue that is already known. The process change is not expected to fix it.
To have Nova schedule instances on hosts based on segments where ports are attached to. Aggregates are created per segment 6. The process is using segment ids as names. It is still expected to continue creating aggregates with the new segment created for a given network. This should not bring any issue.
Sahid Orentino Ferdjaoui
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.