Mirantis Container Cloud (MCC) becomes part of Mirantis OpenStack for Kubernetes (MOSK)!
Starting with MOSK 25.2, the MOSK documentation set will cover all product layers, including MOSK management (formerly MCC). This means everything you need will be in one place. The separate MCC documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.
Tungsten Fabric known limitations¶
This section describes the known limitations of Tungsten Fabric and OpenSDN.
Feature availability and limitations¶
This section contains a list of the Tungsten Fabric upstream features and use cases not supported in MOSK and features and use cases offered as Technology Preview in the current product release, if any.
Feature or use case |
Status |
Description |
|---|---|---|
Tungsten Fabric web UI |
Provided as is |
MOSK provides the TF web UI as is and does not include this service in the support Service Level Agreement. |
Automatic generation of network port records in DNSaaS (Designate) |
Not supported |
As a workaround, you can use the Tungsten Fabric built-in DNS service that enables virtual machines to resolve each other names. |
Secret management (Barbican) |
Not supported |
It is not possible to use the certificates stored in Barbican to terminate HTTPs on a load balancer in a Tungsten Fabric deployment. |
Role Based Access Control (RBAC) for Neutron objects |
Not supported |
|
Advanced Tungsten Fabric features |
Provided as is |
MOSK provides the following advanced Tungsten Fabric features as is and does not include them in the support Service Level Agreement:
|
Deprecated |
DPDK. For the deprecation note, refer to DPDK. |
|
Tungsten Fabric and OpenStack Octavia Amphora integration |
Technical Preview |
Due to Tungsten Fabric Simple Virtual Gateway restriction, each virtual
network can have only one VGW interface. As a result,
MOSK should be limited to a single compute node
with the |
Restriction to 256 addresses for Allowed Address Pairs¶
Tungsten Fabric enforces a maximum Allowed Address Pair (AAP) network size of 256 addresses — equivalent to a prefix of /24 — for both IPv4 and IPv6 tenant networks.
AAPs let a port use additional IP addresses beyond its primary one, enabling features like virtual IPs, load balancers, and network appliances that require multiple addresses. They are mainly used for high availability, failover, and advanced network services, providing flexibility while preserving the default port-level security model.
The vRouter agent on each compute node monitors AAP subnets by sending unicast ARP requests to every address in the subnet once per minute, and sends additional ARP requests when an AAP is added, modified, or during failover events. This behavior increases with network size and can result in higher resource usage and potential network disruptions.
This restriction is inherent to the Tungsten Fabric architecture and not expected to change. For details, see the upstream #1720118 bug description.
Warning
Mirantis cannot be held liable for any issues caused by using AAPs with network sizes greater than 256 addresses (/24 for IPv4 or /120 for IPv6). If degraded performance, instability, or service impact is observed in a MOSK cloud, the only supported resolution is to remove oversized AAPs.