Giters

kytos-ng / sdntrace_cp

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

sdntrace_cp can end up matching a lower priority flow depending on `/stored_flows`

viniarck opened this issue · comments

commented

This is to capture a problem that @jab1982 reported recently, sdntrace_cp should run its matching algo for highest entries first (this should come sorted/ordered by from /stored_flows)

For instance if you have these two flows installed, if port 1 were to receive a packet with dl_vlan 105 then it'll be forwarded to port 2, but since we haven't enforced a sort by priority on /stored_flows it's undefined the order, but most of the time it'll be based on installation order, so, sdntrace_cp can end up with a wrong trace result:

 cookie=0x64, duration=149.429s, table=0, n_packets=9, n_bytes=1170, send_flow_rem priority=101,in_port="s1-eth1",dl_vlan=105 actions=output:"s1-eth2"
 cookie=0x65, duration=149.431s, table=0, n_packets=1, n_bytes=70, send_flow_rem priority=100,in_port="s1-eth1" actions=output:"s1-eth3"

{
    "trace": {
        "switchx": {
            "dpid": "{{dpid}}",
            "in_port": 1
        },
        "eth": {
            "dl_vlan": 105
        }
    }
}

The output here should be port 2:

{
    "result": [
        {
            "dpid": "00:00:00:00:00:00:00:01",
            "out": {
                "port": 3,
                "vlan": 105
            },
            "port": 1,
            "time": "2023-02-28 12:33:03.058279",
            "type": "starting",
            "vlan": 105
        }
    ]
}

Points to be aware from OF1.3:

If there are multiple matching flow entries
with the same highest priority, the selected flow entry is explicitly undefined

^ so, we also can't ensure defined behavior in that case, so we should explicitly mention that in the changelog that it's not recommended to have flows that can have multiple matches with same priority.

cc'ing @gretelliz