Details
-
Bug
-
Status: Resolved
-
Resolution: Done
-
Boron
-
None
-
None
-
Operating System: All
Platform: All
-
6940
Description
Netvirt is mapping each neutron subnet to a genius ITM transport zone subnet.
This subnet configuration:
{
"subnets": {
"subnet": [
,
{ "uuid": "7a843d7f-de78-4a01-b62e-c103ee90afb7", "network-id": "177bef73-514e-4922-990f-d7aba0f3b0f4", "name": "dovs-net-1", "tenant-id": "5d806f0e-e197-4a72-88e6-72b024fa5c97", "ip-version": "neutron-constants:ip-version-v4", "cidr": "10.0.1.0/24" } ]
}
}
Results in this transport zone configuration (when each of two computes holds neutron ports belonging to each of the two neutron subnets):
{
"transport-zone": [
{
"zone-name": "177bef73-514e-4922-990f-d7aba0f3b0f4",
"tunnel-type": "odl-interface:tunnel-type-vxlan",
"subnets": [
{
"prefix": "10.0.1.0/24",
"vteps": [
,
{ "dpn-id": 180904321929475, "portname": "tunnel_port", "ip-address": "172.17.0.2" } ],
"gateway-ip": "0.0.0.0",
"vlan-id": 0
},
{
"prefix": "10.0.0.0/24",
"vteps": [
,
{ "dpn-id": 180904321929475, "portname": "tunnel_port", "ip-address": "172.17.0.2" } ],
"gateway-ip": "0.0.0.0",
"vlan-id": 0
}
]
}
]
}
This is incorrect configuration, as the transport zone subnet relate to the provider subnets the TEPs belong to, and not to the any overlay subnet. As observed, the problem is that the same TEP could be configured multiple
times on different transport zone subnets. This results on ITM
getting confused and thinking that some TEPs are not longer needed and
removing them, losing connectivity required between the computes.