[OPNFLWPLUG-602] He Plugin - Bulk delete of flows does not clear all flows Created: 25/Jan/16  Updated: 27/Sep/21  Resolved: 16/Jun/17

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

Type: Bug
Reporter: Jan Medved Assignee: Jan Medved
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS
Platform: Macintosh


External issue ID: 5073

 Description   

In this use case, 100k flows are programmed into a simulated network (mininet) with 15 nodes. Then, all 100k flows are deleting by clearing out the confi space. 20-30k flows are left in the network.

To reproduce, use the following steps:

1. Start mininet using the following command:

"sudo mn --controller=remote,ip=192.168.162.1:6633 --topo tree,4 --switch ovsk,protocols=OpenFlow13"

Let mininet connect to the controller

2. From another shell, use the flow_config_blaster script (located in the integration test project under 'test/tools/odl-mdsal-clustering-tests/clustering-performance-test') to program 100k flows into the controller:

./flow_config_blaster.py --threads 8 --flows 12500 --auth --no-delete --fpr 200

3. In the mininet test VM, use a script to make sure that all 100k flows have been programmed into the network:

/bin/get-total-found.sh

(or something similar); make sure all 100k flows have been injected into mininet. You may also check the controller's REST API, but collecting all the 100k flows takes a long time (> 10 minutes).

4. Use the config_cleanup script (alos located in 'test/tools/odl-mdsal-clustering-tests/clustering-performance-test') to delete all 100k flows at once:

./config_cleanup.py --auth

5. In the mininet test VM, use a script to check whether all flows have been deleted from the switches:

/bin/get-total-found.sh

The flow counts should now be 0 on all switches. Dangling flows can found, however.



 Comments   
Comment by Jan Medved [ 26/Jan/16 ]

This bug is related to the number of flows per switch - I was able to reproduce for 40k flows in a network of 7 nodes. Basically, when the number of flows per switch gets to about 4k, this problem occurs.

Comment by Abhijit Kumbhare [ 01/Feb/16 ]

Solved in Lithium design

Comment by Andrej Leitner [ 03/Oct/16 ]

Decreasing priority since no activity for more than 8 months.

Jan, do you think we still need to fix this even though helium design is not the default design already in Boron (and lithium design is ok)?

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