[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
Platform: 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:
neutron net-create ext-net --router:external --provider:physical_network public --provider:network_type flat

3) The VPNInterface is created in the Operational DS
{
"vpn-interfaces": {
"vpn-interface": [

{ "dpn-id": 259602484679796, "name": "259602484679796:eth2:trunk", "scheduled-for-remove": false, "vpn-instance-name": "78cdc60a-1e9d-4f0b-8cf3-c51700f5e67e" }

]
}
}

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": {
"vpn-interface": [

{ "dpn-id": 259602484679796, "name": "259602484679796:eth2:trunk", "scheduled-for-remove": true, "vpn-instance-name": "78cdc60a-1e9d-4f0b-8cf3-c51700f5e67e" }

}

This issue is similar to the NETVIRT-452 (which had been fixed) except for in this case the VPN interface belongs to the external network.

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());
if (opVpnInterface != null) {
String opVpnName = opVpnInterface.getVpnInstanceName();
String primaryInterfaceIp = null;
if (opVpnName.equals(vpnName)) {
// Please check if the primary VRF Entry does not exist for VPNInterface
// If so, we have to process ADD, as this might be a DPN Restart with Remove and Add triggered
// back to back
// However, if the primary VRF Entry for this VPNInterface exists, please continue bailing out !
List<Adjacency> adjs = VpnUtil.getAdjacenciesForVpnInterfaceFromConfig(dataBroker, interfaceName);
if (adjs == null) {
LOG.error(
"VPN Interface {} addition failed as adjacencies for this vpn interface could not be "
+ "obtained", interfaceName);
return;
}
~



 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
https://git.opendaylight.org/gerrit/61512

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