[NETVIRT-347] Using same subnets/IPs for different VMs in different tenants causes rules to be overwritten in table 28 Created: 11/Dec/16  Updated: 07/Jan/17  Resolved: 07/Jan/17

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

Type: Bug
Reporter: Mickael Strock-Vidal Assignee: Olga Schukin
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: 7340

 Description   

Overview:
---------
During tests I did in multi-tenanted environment (2 or 3 tenants), using same subnets/IPs for different VMs in different tenants causes rules to be overwritten in table 28

Steps:
------
1) Created 1 network, subnet, router, VM, Floating IP x.x.x.x (from public network) allocated to VM internal IP - in tenant 1
Details:
Network: type: vxlan, segmentation ID: 1111, not external, subnet - 1.1.1.0/24
VM: IP: 1.1.1.11

2) Connectivity check to floating ip x.x.x.x

3) Created 1 network, subnet, router, VM, Floating IP x.x.x.y (from public network) allocated to VM internal IP - in tenant 2
Details:
Network: type: vxlan, segmentation ID: 111, not external, subnet - 1.1.1.0/24
VM: IP: 1.1.1.11

4) Connectivity check to floating ip x.x.x.x and x.x.x.y

Expected results:
-----------------

  • Connectivity to both floating IPs exist

Actual result:
--------------

  • Connectivity to 1st floating IP do not longer exist

Investigation:
--------------

  • We observed that the flows in table 28 for the floating IP x.x.x.y (2nd) overwrite the flows that were there for floating IP x.x.x.x (1st) instead of appending new flows.
    This was caused because the key used in the model was including the internal IP (which is common to the two VMs in the multi-tenanted environment) instead of the floating IP which is unique.


 Comments   
Comment by Olga Schukin [ 14/Dec/16 ]

Review: https://git.opendaylight.org/gerrit/49333

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