[GENIUS-125] TEP with UNKNOWN state not cleared from ietf-interfaces-state on br-int delete and add Created: 13/Apr/18  Updated: 28/Aug/19

Status: In Progress
Project: genius
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Medium
Reporter: Tarun Thakur Assignee: Edwin Anthony
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File karaf.log     Text File tep_show_state_issue_debug.txt    

 Description   

Scenario:

  1. Two switches connected to ODL.
  2. Tunnels created among them by genius-auto-tunnel feature and they are in UP state.
  3. Bridge br-int is deleted on one switch and TEP corresponding to switch is also deleted from transport-zone.
  4. Bridge br-int is created again.
  5. TEP interface which was present on old br-int (that was deleted) is still present with UNKNOWN state in tep:show-state CLI and also in REST output of URL: http://localhost:8181/restconf/operational/ietf-interfaces:interfaces-state/

 Output:

No Title

{

                "name": "tun9a610ac5fb8",

                "lower-layer-if": [

                    "openflow:205394741551683:1"

                ],

                "type": "iana-if-type:tunnel",

                "if-index": 4,

                "statistics":

{                     "discontinuity-time": "2018-04-12T10:05:13.738Z"                 }

,

                "phys-address": "0a:9b:ca:40:1e:a9",

                "admin-status": "up",

                "oper-status": "unknown"

            },

            {

                "name": "tun920ad5df93c",

                "lower-layer-if": [

                    "openflow:249401263927879:1"

                ],

                "type": "iana-if-type:tunnel",

                "if-index": 6,

                "statistics":

{                     "discontinuity-time": "2018-04-12T10:06:39.240Z"                 }

,

                "phys-address": "3e:3e:2c:c3:0a:75",

                "admin-status": "up",

                "oper-status": "unknown"

            },

 

 CLI output::

opendaylight-user@root>tep:show-state

Tunnel Name       Source-DPN        Destination-DPN   Source-IP         Destination-IP    Trunk-State  Transport Type

-------------------------------------------------------------------------------------------------------------------------------------

tun5e4fcc86a6b    266566598320975   11993393404231    192.168.56.251    192.168.56.250    UP          VXLAN

tun9a4e266ac54    11993393404231    266566598320975   192.168.56.250    192.168.56.251    UP          VXLAN

tun920ad5df93c    249401263927879   266566598320975   192.168.56.250    192.168.56.251    UNKNOWN     VXLAN

tun9a610ac5fb8    205394741551683   266566598320975   192.168.56.250    192.168.56.251    UNKNOWN     VXLAN

opendaylight-user@root>

 

opendaylight-user@root>tep:show

Tunnel Monitoring (for VXLAN tunnels): On

Tunnel Monitoring Interval (for VXLAN tunnels): 10000

 

 

TransportZone     TunnelType        SubnetMask        GatewayIP     VlanID       DpnID        IPAddress        PortName

------------------------------------------------------------------------------------------------------------------------------

default-transport-zone  VXLAN             255.255.255.255/32  0.0.0.0       0            11993393404231 192.168.56.250

default-transport-zone  VXLAN             255.255.255.255/32  0.0.0.0       0            266566598320975 192.168.56.251

opendaylight-user@root>

 Comments   
Comment by Edwin Anthony [ 10/May/18 ]

the issue could not be reproduced locally, although the issue you see could be because of timing issues.
[https://git.opendaylight.org/gerrit/#/c/71912/
]please pull these changes and try it out.

Comment by Edwin Anthony [ 18/May/18 ]

The issue is being seen because auto tunnels is deleting ifm's config DS, which is in contrast with the use-cases mentioned in the feature spec.

recent changes in the auto tunnel logic, have to be reconsidered.

Comment by Faseela K [ 07/Aug/18 ]

tarunODLF : Could you please confirm if the issue exists even now? If so, could you please supply the TRACE logs for interfacemanager and itm, when you reproduce the issue. We are not hitting the issue when we are locally executing the steps you have mentioned.

Comment by Faseela K [ 16/Nov/18 ]

If there is no update on this Jira before the next weekly call, I am going to abandon this.

Comment by Hema Gopalakrishnan [ 28/Aug/19 ]

Abandoning this as there is no traction on this bug

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