[OPNFLWPLUG-22] Number of flows in a switch reported incorrectly when controller connects to a switch with existing flows. Created: 12/Jan/14  Updated: 27/Sep/21  Due: 20/Jan/14  Resolved: 30/Jan/14

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

Type: Bug
Reporter: Jan Medved Assignee: Anil Vishnoi
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: 286

 Description   

Controller connects to a switch with pre-existing flows (2 flows). When the operational state for a Table is issued, he Controller SHOULD report 2 flows, and display detailed statistics for both flows.

1. Retrieve operational data for a table:

http://192.168.4.1:8080/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/table/2

2. The controller shows:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<table
xmlns="urn:opendaylight:flow:inventory">
<aggregate-flow-statistics
xmlns="urn:opendaylight:flow:statistics">
<byte-count>0</byte-count>
<packet-count>0</packet-count>
<flow-count>1</flow-count>
</aggregate-flow-statistics>
<id>2</id>
<flow-table-statistics
xmlns="urn:opendaylight:flow:table:statistics">
<packets-looked-up>0</packets-looked-up>
<packets-matched>0</packets-matched>
<active-flows>1</active-flows>
</flow-table-statistics>
</table>

Whereas it should show 2 flows and details for each flow.

3. check the flows with OVS in mininet:
mininet@mininet-vm:~$ sudo ovs-ofctl -O OpenFlow13 dump-flows s1
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0xa, duration=963.729s, table=0, n_packets=0, n_bytes=0, idle_timeout=3400, hard_timeout=1200, priority=2,ip,nw_dst=10.0.0.0/24 actions=dec_mpls_ttl
cookie=0x14, duration=1013.893s, table=2, n_packets=0, n_bytes=0, idle_timeout=3400, hard_timeout=1200, send_flow_rem priority=2,metadata=0x3039 actions=dec_ttl

Mininet's OVS shows both flows active.

Note that the REALLY correct behavior would be for the controller to detect the two flows and then reconcile them with its config space. Since the config space is empty, the controller SHOULD delete both flows upon reconnection. But, in order to be able to delete the flows, the controller MUST detect them properly, which is not happening.

 Comments   
Comment by Ed Warnicke [ 15/Jan/14 ]

Should check to see what's coming on the wire to make sure OVS is not misreporting.

Also check to make sure stats sweep has occurred.

Comment by Anil Vishnoi [ 17/Jan/14 ]

Hi Jan,

To me these flow stats looks correct. If you see the flows dumped by ovs-ofctl

3. check the flows with OVS in mininet:
mininet@mininet-vm:~$ sudo ovs-ofctl -O OpenFlow13 dump-flows s1
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0xa, duration=963.729s, table=0, n_packets=0, n_bytes=0, idle_timeout=3400, hard_timeout=1200, priority=2,ip,nw_dst=10.0.0.0/24 actions=dec_mpls_ttl
cookie=0x14, duration=1013.893s, table=2, n_packets=0, n_bytes=0, idle_timeout=3400, hard_timeout=1200, send_flow_rem priority=2,metadata=0x3039 actions=dec_ttl

Table 2 only contains 1 flow (look at table=2 in the second flow), another flow is from table 0 (table=0). Thats the reason stats shows only 1 flow for table 2. If you dump stats for table 0, you will see stats of the other flow.

Let me know if you have any other query, else i will close this bug.

Thanks
Anil

Comment by Jan Medved [ 18/Jan/14 ]

Hi Anil,

I re-ran the test with two flows in Table 2, and the problem is still there.

If you start both the controller and mininet, and then program both flows, everything is ok.

But then restart the controller, and leave the flows on the switch in mininet. When the controller comes back, it will not read the flows correctly - it will read only one flow.

This bug describes the restart use case. Moreover, when I delete a flow from RESTCONF, stats collection stops and existing flows are not updated anymore. I think that’s another bug - if it's not related to this one, I can open a new bug.

Thanks,
Jan

Comment by Ed Warnicke [ 20/Jan/14 ]

Tried this yesterday with mininet and pingall

If I run pingall, I will initially see all the flows. But if I then stop and restart the controller, I will not.

Comment by Anil Vishnoi [ 22/Jan/14 ]

Hi Ed/Jan,

I pushed gerrit [4583] that contains fix for bug-284, as well as some clean-up code.
https://git.opendaylight.org/gerrit/#/c/4583/

Can you please re-test it once this gerrit get merge to the controller repo. I locally verified it and things looks fine to me.

Thanks
Anil

Comment by Anil Vishnoi [ 26/Jan/14 ]

Hi Jan,

I pushed gerrit http://git.opendaylight.org/gerrit/4822.

I locally verified it and it shows me correct stats.

**I installed two flows flow-135 and flow-140 in table 2.
**I can see both the flows in config data store and their statistics in operational data store. Also aggregate and flow statistics were showing 2 flows.

    • I stopped controller and restarted it (while mininet is running)
    • I dumped operational data of table 2 and i can see that both aggregate and flow statistics shows 2 flows.

If you still see problem in your setup, we can get into web-ex session to sort it out.

Thanks
Anil

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