[NETVIRT-821] VPN Interface for external network remains in Operational DS after network is deleted Created: 04/Aug/17 Updated: 25/Sep/17 Resolved: 25/Sep/17 |
|
| Status: | Resolved |
| Project: | netvirt |
| Component/s: | General |
| Affects Version/s: | Carbon |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Vinh Nguyen | Assignee: | Vinh Nguyen |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 8930 |
| Description |
|
When deleting the external network, the VPNInterface isn't removed from the Operational DS. The VPNInterface is deleted in Config DS though. Steps: 1) Stack fresh both Opendaylight and ODL 2) Create external network: 3) The VPNInterface is created in the Operational DS ] 4) delete external network: neutron net-delete ext-net 5) The VPNInterface remains in the Operational DS with attribute "scheduled-for-remove" is set to "true". It should be removed as well: "vpn-interfaces": { } This issue is similar to the The Op VPNInterface is cleaned up in the VRFEntryListener when the VRFEntry is removed from the Config DS. However, for external network is created without any router, there is no VRFEntry to be removed. Hence the OP VPNInterface is not removed. Consequently, if we recreate the same external network, in VPNInterfaceManager::processVpnInterfaceUp, the stale Op VPN interface is retrieved when checking if the associated VRFEntries have been removed. The stale OpVPNInterface doesn't have any adjacencies, and the error is thrown as in the below code snippets: VpnInterface opVpnInterface = VpnUtil.getOperationalVpnInterface(dataBroker, vpnInterface.getName()); |
| Comments |
| Comment by Vinh Nguyen [ 04/Aug/17 ] |
|
Also note that for the recreated external network, the L3 flows in table 17 is missing for the external port because L3 service is not bound for the export port because the error described above table=17, n_packets=1, n_bytes=113, priority=10,metadata=0xa0000000000/0xffffff0000000000 actions=load:0x186a9->NXM_NX_REG3[0..24],write_metadata:0x90000a0000030d52/0xfffffffffffffffe,goto_table:19 |
| Comment by Vinh Nguyen [ 10/Aug/17 ] |
|
Patch submitted for code review |