[NETVIRT-205] Incorrect handling of ITM transport zones Created: 14/Oct/16  Updated: 19/Oct/17  Resolved: 22/Nov/16

Status: Resolved
Project: netvirt
Component/s: General
Affects Version/s: Boron
Fix Version/s: None

Type: Bug
Reporter: Jaime Caamaño Ruiz Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 6940

 Description   

Netvirt is mapping each neutron subnet to a genius ITM transport zone subnet.

This subnet configuration:

{
"subnets": {
"subnet": [

{ "uuid": "b4cfc309-f9dc-4b0b-9943-306252265d35", "network-id": "177bef73-514e-4922-990f-d7aba0f3b0f4", "name": "dovs-net-2", "tenant-id": "5d806f0e-e197-4a72-88e6-72b024fa5c97", "ip-version": "neutron-constants:ip-version-v4", "cidr": "10.0.0.0/24" }

,

{ "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": 66551191337378, "portname": "tunnel_port", "ip-address": "172.17.0.3" }

,

{ "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": 66551191337378, "portname": "tunnel_port", "ip-address": "172.17.0.3" }

,

{ "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.

 Comments   
Comment by Alon Kochba [ 22/Nov/16 ]

https://git.opendaylight.org/gerrit/#/c/46949/

Generated at Wed Feb 07 20:20:58 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.