[NETVIRT-760] Sometimes vxlan port with remote_ip set to the node itself was created when adding new L2GW Node to Open vSwitch HWVTEP Emulator Created: 04/Jul/17  Updated: 19/Oct/17  Resolved: 18/Jul/17

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

Type: Bug
Reporter: Ran Xiao 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: 8796

 Description   

Issue：
Sometimes vxlan port with remote_ip set to the node itself was created when adding new L2GW Node to Open vSwitch HWVTEP Emulator.

Additional Info：
This issue was found while we executing HWVTEP Emulator HA node addition. But not sure whether it's related to HA node addition or not.
Once this issue happened in l2gw connection creation, it will happen every time even deleted the created l2gw connection to create a new one.
But by creating a new virtual network to create a new l2gw connection, the result may changes.

Environment details:
OpenStack Version：stable/ocata
ODL Version：Carbon-FR + patch
patch: https://git.opendaylight.org/gerrit/#/c/56773/
https://git.opendaylight.org/gerrit/#/c/56710/
https://git.opendaylight.org/gerrit/#/c/58787/
https://git.opendaylight.org/gerrit/#/c/59598/
HWVTEP: Open vSwitch 2.6.1 HWVTEP Emulator
: HA Cluster

What we did (Steps):
1. Create a L2GW Node with Open vSwitch HWVTEP Emulator
Set 'other_config:ha_enabled=true' and 'other_config:ha_id=0123456789' when creating.
2. Create gateway and connection
Confirmed the communication via L2GW Node was OK
3. Create a new L2GW Node with Open vSwitch HWVTEP Emulator
Create a HA Cluster with node created in step1
Set 'other_config:ha_enabled=true', and 'other_config:ha_id=0123456789'
VTEP and MAC were also set to the same vaule of the first node

Below are ovs information:
------------------------------
When this issue not occurred:
------------------------------

Bridge "ocata-l2gw1_vtep_ls1"
Port "vx1"
Interface "vx1"
type: vxlan
options:

{key="100", remote_ip="10.0.0.10"}

Port "ocata-l2gw1_vtep_ls1"
Interface "ocata-l2gw1_vtep_ls1"
type: internal
Port "2222-patch-vlan-l"
Interface "2222-patch-vlan-l"
type: patch
options:

{peer="2222-patch-vlan-p"}

Mcast_Macs_Local table
MAC _uuid ipaddr locator_set logical_switch
----------- ------------------------------------ ------ ------------------------------------ ------------------------------------
unknown-dst 667cbc44-a44f-4074-8978-b832249442c6 "" 45c85fa4-5014-408d-b82d-12121fb189d7 40c1ae3d-3ee8-412f-84df-dd7157fb700a

Mcast_Macs_Remote table
MAC _uuid ipaddr locator_set logical_switch
----------- ------------------------------------ ------ ------------------------------------ ------------------------------------
unknown-dst c7e3ab8f-219d-4e5d-84ed-36475bfa1705 "" 4df98102-7cc0-4286-a286-ecb597943f1d 40c1ae3d-3ee8-412f-84df-dd7157fb700a

Physical_Locator table
_uuid dst_ip encapsulation_type tunnel_key
------------------------------------ ----------- ------------------ ----------
d405d20d-c40f-4770-8b99-9f08f2610a9b "10.0.0.10" "vxlan_over_ipv4" []
c2e3fb86-440b-4dd0-8509-6eb77d448c53 "10.0.0.50" "vxlan_over_ipv4" []

Physical_Locator_Set table
_uuid locators
------------------------------------ --------------------------------------
45c85fa4-5014-408d-b82d-12121fb189d7 [c2e3fb86-440b-4dd0-8509-6eb77d448c53]
4df98102-7cc0-4286-a286-ecb597943f1d [d405d20d-c40f-4770-8b99-9f08f2610a9b]



---------------------------
When this issue occurred:
---------------------------

Bridge "ocata-l2gw1_vtep_ls1"
Port "2222-patch-vlan-l"
Interface "2222-patch-vlan-l"
type: patch
options: {peer="2222-patch-vlan-p"}

Port "vx1"
Interface "vx1"
type: vxlan
options:

{key="48", remote_ip="10.0.0.50"}

Port "vx2"
Interface "vx2"
type: vxlan
options:

{key="48", remote_ip="10.0.0.10"}

Port "ocata-l2gw1_vtep_ls1"
Interface "ocata-l2gw1_vtep_ls1"
type: internal

Mcast_Macs_Local table
MAC _uuid ipaddr locator_set logical_switch
----------- ------------------------------------ ------ ------------------------------------ ------------------------------------
unknown-dst b841e569-0c2e-4d77-b4a3-240416a5f481 "" 024e56e7-f56b-4fa0-9201-65ac6930e113 567bb87c-d5d9-4292-8eff-9dc04dccec1a

Mcast_Macs_Remote table
MAC _uuid ipaddr locator_set logical_switch
----------- ------------------------------------ ------ ------------------------------------ ------------------------------------
unknown-dst f4a9f429-5be3-49d9-8f35-d1b21a96ad10 "" 5603ff4c-4a46-4a70-adc9-32d2ee8b66b5 567bb87c-d5d9-4292-8eff-9dc04dccec1a
Physical_Locator table
_uuid dst_ip encapsulation_type tunnel_key
------------------------------------ ----------- ------------------ ----------
f8da2d44-e8d3-4a14-94b4-9549546aa4bf "10.0.0.10" "vxlan_over_ipv4" []
d804bff8-6922-4b28-93af-8ca650f203fb "10.0.0.50" "vxlan_over_ipv4" []

Physical_Locator_Set table
_uuid locators
------------------------------------ ----------------------------------------------------------------------------
024e56e7-f56b-4fa0-9201-65ac6930e113 [d804bff8-6922-4b28-93af-8ca650f203fb]
5603ff4c-4a46-4a70-adc9-32d2ee8b66b5 [d804bff8-6922-4b28-93af-8ca650f203fb, f8da2d44-e8d3-4a14-94b4-9549546aa4bf]

 Comments   
Comment by Ran Xiao [ 13/Jul/17 ]
  • Reproduction Steps
    1. Start L2GW Node without setting HA configuration (ha_id and ha_enabled are no set)
    2. Create L2GW GATEWAY and L2GW CONNECTION
    3. Set HA configuration for L2GW Node (set ha_id and ha_enabled)
    LogicalSwitch is re-created here
    VTEP Tunnel I/F of its own is created
    if it is not created, go to the next step
    4. Stop all OVS processes on L2GW Node, and initialize OVSDB
    5. Repeat steps 1 and 2 again
    It will be reproduced 100% at this point
  • Cause of this issue
    a. When creating L2GW GATEWAY and L2GW CONNECTION
    L2 Gateway device information is registered in ElanL2GwCacheUtils treated as "a L2GW Node without HA setting"
    b. When setting HA configuration for L2GW Node
    L2 Gateway device information is registered in ElanL2GwCacheUtils treated as "a L2GW Node with HA setting"
    At this point, the L2Gateway device information having the same VTEP is registered as another entry
    c. When updating RemoteMcastMac for "L2GW Node with HA setting", all TEP information is queried from L2 gateway device
    There are 2 VTEPs in TEP information queried from ElanL2GwCacheUtils
    There is an exclusion processing logic to exclude its own VTEP from all TEP information, but only one can be excluded.
    Therefore, there is still one VTEP of its own remains, which will be registered as its own VTEP.
  • Proposal
    Change the getting all VTEP method (org.opendaylight.netvirt.elan.l2gw.utils.ElanL2GatewayMulticastUtils#getAllTepIpsOfL2GwDevices())
    logic to NOT to add to the list when the same VTEP exists.
Comment by Ran Xiao [ 14/Jul/17 ]

Pushed the following patch. Waiting for review.
<https://git.opendaylight.org/gerrit/#/c/60318/>

Comment by Ran Xiao [ 18/Jul/17 ]

Close this bug ticket as the fix patch has been merged.
<https://git.opendaylight.org/gerrit/#/c/60318/2>

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