TOR path not deleted in multicast (ff:ff:ff:ff:ff:ff) route
Bug #1416808 reported by
Manish Singh
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Juniper Openstack | Status tracked in Trunk | |||||
R2.1 |
Fix Committed
|
Critical
|
Manish Singh | |||
Trunk |
Fix Committed
|
Critical
|
Manish Singh |
Bug Description
When VRF was deleted before VN or VN getting re-added before VRF was deleted, TOR path used to remain in TSN agent.
This results in DeleteTimeOut for mentioned VRF.
Further observation that multicast handler didnt acted correctly in case VN is present with no VRF.
information type: | Proprietary → Public |
To post a comment you must log in.
Reviewed: https:/ /review. opencontrail. org/6864 github. org/Juniper/ contrail- controller/ commit/ 84347759dde36c7 58f37f4d12a7540 de97786dbd
Committed: http://
Submitter: Zuul
Branch: R2.1
commit 84347759dde36c7 58f37f4d12a7540 de97786dbd
Author: manishsingh <email address hidden>
Date: Sun Feb 1 13:31:20 2015 +0530
Problem: TOR path not deleted on VRF delete.
When VRF is deleted in TSN mode, notification is received for physical_device_vn
entry.This entry contain vn_entry which can in turn can be used to extract VRF.
Multicast handler on adding the entry puts a state where it adds the VRF
entry name so that it can be used at the time of deletion because when VRF is
deleted vn_entry from physical_device_vn may not contain any VRF.
Issue was that search for multicast object was being done using vrf from VN
at time of delete. This should be done using the vrf_name stored in state.
Fixed the same here. Along with this fix also added a check to verify VRF is
in deleted state when IsTorDeleted being calculated.
Closes-bug: #1416808
Change-Id: Ica526b736a0772 3db40c6bb31a2f9 1f756cb1373