[GENIUS-92] TEP info in ITM config datastore can not be deleted Created: 10/Oct/17  Updated: 17/May/18  Resolved: 17/May/18

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

Type: Bug
Reporter: Ran Xiao Assignee: Tarun Thakur
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Attachments: File genius-itm-config.xml     File itm-transportzone.config     File karaf.tar.gz     File network-topology.config     File network-topology.operational     File ocata-compute.ovsdb-client_dump     File ocata-controller.ovsdb-client_dump    
External issue ID: 9259

 Description   

TEP info in ITM config datastore can not be deleted by following the procedure of the ODL document.

  • : where we expect to be deleted
    {
    "transport-zones": {
    "transport-zone": [
    {
    "zone-name": "e383ab7e-a92c-4c7c-84cf-e797270799c2",
    "tunnel-type": "odl-interface:tunnel-type-vxlan",
    "subnets": [
    {
    "vteps": [
  • { "dpn-id": 229274253668002, "portname": "tunnel_port", "option-of-tunnel": false, "ip-address": "10.0.0.20" }

    ,

    { "dpn-id": 118908811792816, "portname": "tunnel_port", "option-of-tunnel": false, "ip-address": "10.0.0.10" }

    ],
    "gateway-ip": "0.0.0.0",
    "vlan-id": 0
    }
    ]
    }
    ]
    }
    }

Procedure in ODL document::
ITM Tunnel Auto-Configuration
http://docs.opendaylight.org/en/stable-carbon/submodules/genius/docs/specs/itm-tunnel-auto-config.html
　TEP Deletion
When an openvswitch:external_ids:tep-ip parameter gets deleted through ovs-vsctl command, then network topology Operational
DS gets updated via OVSB update notification. ITM which has registered for the network-topology DTCNs, gets notified and this
deletes the TEP from Transport zone or tepsNotHostedInTransportZone stored in ITM config DS based on external_ids:tzname
parameter configured for TEP.

Environment Details
OpenStack Version: stable/ocata
ODL Version: carbon-FR

Reproduction steps:
1. Initialize ODL
2. Connect (Set up) ControllerNode, ComputeNode with ODL
3. Create NW, router, VM
4. Confirm data is created in MD-SAL
restconf/config/itm:transport-zones
5. Delete NW, router, VM
6. Execute the following command in compute node

  1. ovs-vsctl remove Open_vSwitch <UUID> external_ids tep-ip="10.0.0.20"

Attachment List:
genius-itm-config.xml
karaf.tar.gz
itm-transportzone.config
network-topology.config
network-topology.operational
controller.ovsdb-client_dump
compute.ovsdb-client_dump

Possible cause:
Unable to get the TransportZone which contains the TEP should be removed.
Karaf log:
2017-09-26 19:26:37,350 | TRACE | nPool-1-worker-3 | OvsdbTepRemoveConfigHelper | 353 - org.opendaylight.genius.itm-impl - 0.2.0.Carbon | Remove TEP: TEP-IP: 10.0.0.20, TZ name: TZA, DPID: 00:00:d0:86:12:72:2e:a2
2017-09-26 19:26:37,351 | TRACE | nPool-1-worker-3 | OvsdbTepRemoveConfigHelper | 353 - org.opendaylight.genius.itm-impl - 0.2.0.Carbon | Removing TEP from unknown TZ into teps-not-hosted-in-transport-zone.
2017-09-26 19:26:37,351 | TRACE | nPool-1-worker-3 | OvsdbTepRemoveConfigHelper | 353 - org.opendaylight.genius.itm-impl - 0.2.0.Carbon | Unhosted TransportZone does not exist. Nothing to do for TEP removal.

 Comments   
Comment by Ran Xiao [ 10/Oct/17 ]

Attachment genius-itm-config.xml has been added with description: genius-itm-config.xml

Comment by Ran Xiao [ 10/Oct/17 ]

Attachment itm-transportzone.config has been added with description: itm-transportzone.config

Comment by Ran Xiao [ 10/Oct/17 ]

Attachment karaf.tar.gz has been added with description: karaf.tar.gz

Comment by Ran Xiao [ 10/Oct/17 ]

Attachment network-topology.config has been added with description: network-topology.config

Comment by Ran Xiao [ 10/Oct/17 ]

Attachment network-topology.operational has been added with description: network-topology.operational

Comment by Ran Xiao [ 10/Oct/17 ]

Attachment ocata-compute.ovsdb-client_dump has been added with description: ocata-compute.ovsdb-client_dump

Comment by Ran Xiao [ 10/Oct/17 ]

Attachment ocata-controller.ovsdb-client_dump has been added with description: ocata-controller.ovsdb-client_dump

Comment by Faseela K [ 10/May/18 ]

Hematg Could you please share your observations on this, and assign it to the right person?

Comment by Hema Gopalakrishnan [ 11/May/18 ]

 Tarun, Can you please take a look at this issue as its related to ITM auto tunnel deletion.

Comment by Tarun Thakur [ 11/May/18 ]

You rightly said the possible cause.

As per configuration, it seems, auto-tunnel feature from netvirt is enabled that is why,

below transport-zone is created.

 "zone-name": "e383ab7e-a92c-4c7c-84cf-e797270799c2",

 

But, when tep is tried to be removed as per ITM auto-tunnel feature, then

it tries to delete tep from TZA transport-zone which is configured in the external_ids column of openvswitch ovsdb table:

as per nw-topo-operationa file:

 "ovsdb:openvswitch-external-ids": [
             

{                 "external-id-key": "tzname",                 "external-id-value": "TZA"               }

,
             

{                 "external-id-key": "tep-ip",                 "external-id-value": "10.0.0.10"               }

,

also as per ovsdb table dump of compute node:

#Conclusion

We can see tep from southbound is configured for TZA transport-zone, but TZA is not present in transport-zones list, but some other TZ is present.

As per ITM tep auto-config spec, there is dependency section which states below:

Dependencies

This feature should be used when configuration flag i.e. use-transport-zone in netvirt-neutronvpn-config.xml for automatic tunnel configuration in transport-zone is disabled in Netvirt’s NeutronVpn,

So, auto-tunnel feature from genius and netvirt are working in parallel and causing such issue.

Kindly confirm if it is true.

 

Comment by Faseela K [ 17/May/18 ]

In Carbon, itm auto-tunnels is enabled by default, and we no longer use netvirt auto-tz. Please try to reproduce the issue with the same, and let us know if you hit the issue again

Generated at Wed Feb 07 19:59:53 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.