[OPNFLWPLUG-82] Flow Entries from Switch and Controller are not same. Might affect Bug375 Created: 12/Mar/14  Updated: 27/Sep/21  Resolved: 16/Aug/16

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

Type: Improvement
Reporter: Praveen Darshanam Assignee: Anil Vishnoi
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


 Description   

When I pushed a particular flow entry using "addMDFlow openflow:1 f4" and request the flow using readConfigurationData() API, readOperationalData() API both the Flows are not matching. The fields like Flow id/values, FlowKey, _barrier=false, _cookieMask=10, _flowName=Bar etc. are either malformed or not present. This bug might affect VTN-2 as suggested by Michal Rehak.

I am using latest openflowplugin and OVSK switch with OF1.3

getAllControllerFlows: tableId= 4
getAllControllerFlows: flow= Flow [_id=Uri [_value=127], _key=FlowKey [_id=Uri [_value=127]], _barrier=false, _cookieMask=10, _flags=FlowModFlags [_cHECKOVERLAP=false, _rESETCOUNTS=false, _nOPKTCOUNTS=false, _nOBYTCOUNTS=false, _sENDFLOWREM=true], _flowName=Bar, _installHw=false, _instructions=Instructions [_instruction=[Instruction [_key=InstructionKey [], _instruction=ApplyActionsCase [_applyActions=ApplyActions [_action=[Action [_key=ActionKey [], _action=DropActionCase [_dropAction=DropAction [augmentation=[]], augmentation=[]], augmentation=[]]], augmentation=[]], augmentation=[]], augmentation=[]]], augmentation=[]], _match=Match [_ethernetMatch=EthernetMatch [_ethernetDestination=EthernetDestination [_address=MacAddress [_value=ff:ff:ff:ff:ff:ff], _mask=MacAddress [_value=ff:ff:ff:00:00:00], augmentation=[]], _ethernetSource=EthernetSource [_address=MacAddress [_value=00:00:00:00:23:ae], _mask=MacAddress [_value=ff:ff:00:00:00:00], augmentation=[]], _ethernetType=EthernetType [_type=EtherType [_value=2048], augmentation=[]], augmentation=[]], augmentation=[]], _strict=false, _cookie=10, _hardTimeout=0, _idleTimeout=0, _priority=2, _tableId=4, augmentation=[]]

getAllSwitchFlows: tableId= 4
getAllSwitchFlows: flow= Flow [_id=Uri _value=#UF$TABLE*4*2, _key=FlowKey _id=Uri [_value=#UF$TABLE*4*2], augmentation=[FlowStatisticsData [_flowStatistics=FlowStatistics [_byteCount=Counter64 [_value=0], _packetCount=Counter64 [_value=0], _duration=Duration [_nanosecond=Counter32 [_value=707000000], _second=Counter32 [_value=722], augmentation=[]], _flags=FlowModFlags [_cHECKOVERLAP=false, _rESETCOUNTS=false, _nOPKTCOUNTS=false, _nOBYTCOUNTS=false, _sENDFLOWREM=true], _instructions=Instructions [_instruction=[], augmentation=[]], _match=Match [_ethernetMatch=EthernetMatch [_ethernetDestination=EthernetDestination [_address=MacAddress [_value=FF:FF:FF:00:00:00], augmentation=[]], _ethernetSource=EthernetSource [_address=MacAddress [_value=00:00:00:00:00:00], augmentation=[]], _ethernetType=EthernetType [_type=EtherType [_value=2048], augmentation=[]], augmentation=[]], augmentation=[]], _cookie=10, _hardTimeout=0, _idleTimeout=0, _priority=2, _tableId=4, augmentation=[]]]]]

 Comments   
Comment by Praveen Darshanam [ 12/Mar/14 ]

Sorry, it is OPNFLWPLUG-56 not 385

Comment by Anil Vishnoi [ 12/Mar/14 ]

Investigating

Comment by Michal Rehak [ 13/Mar/14 ]

For better flow identification we should use the cookie field.

Comment by Anil Vishnoi [ 23/Apr/14 ]

Hi Praveen,
Contents of the flow stored in the operational data store seems fine to me. Here is what actually happening.
You are installing flow with
source _mac = ff:ff:ff:ff:ff:ff src_mac_mask = ff:ff:ff:00:00:00
dest_mac = 00:00:00:00:23:ae dest_mac_mask = ff:ff:00:00:00:00

When you install flow with above mac address and their respective mask values, switch installs flow with following src and dst mac.

src_mac = (ff:ff:ff:ff:ff:ff & ff:ff:ff:00:00:00 = ff:ff:ff:00:00:00)
dst_mac = (00:00:00:00:23:ae & ff:ff:00:00:00:00 = 00:00:00:00:00:00)

So in actual flow rule gets install to the switch has src_mac = ff:ff:ff:00:00:00 & dst_mac = 00:00:00:00:00:00 because of the mask, and this is what operational data store flow reports. When controller fetch flow details from switch, switch don't send cookie mask value with the details, and that why its missing.

FlowName is something thats being used for controller bookkeeping purpose and never goes down to the switch, so its also not there in the details we fetch from switch.

When we fetch flow statistics from switch, we compare each flow retrieved from the switch with the flows stored in config data store to find the matching flow, and if we find the matching flow, we augment the statistics respectively in operational data store under the matching flow key. If we don't find any matching flow in config data store, we consider those flow as unaccounted flows and we augment details of those flows to operational data store using specific key value. The key (_value=#UF$TABLE*4*2) you see in the operational data store flow is a key of an unaccounted flow. You can decode this key in following way
#UF - Unaccounted flow
$TABLE*4 – Table = 4
*2, this is second unaccounted flow in this table on switch.

Matching between the flow fetched from switch and flows stored in config data store is done through custom match functions ( comparison based on each element of the flow construct ), because flow is the only construct in openflow spec that don't have unique ID associated with it. If we can find some alternate mechanism of providing unique id to the flow, we can avoid this custom matching and directly augment the flow stats to the flow associated with that unique key in the operational data store.

Now the question is why controller is considering this flow as unaccounted flow given that its respective flow is already there in the config data store?
I feel this is a bug in the custom matching functions where we compare ethernet address for match, we probably are ignoring the mask based comparison. The reason this custom comparison gets more tricky is because when we fetch flow stats from switch, it doesn't provide the mask values, it just provide the final executed details of flow, rather then what user sent to it.

For short term i will try to fix it in the existing implementation and will push patch sometime next week. For the long term solution we are looking at alternate mechanism of assigning unique identifier to the flow using "cookies".

Thanks
Anil

Comment by Andrej Leitner [ 16/Aug/16 ]

Closing bug since the main issue here was the alien flow id which was fixed in OPNFLWPLUG-722 and OPNFLWPLUG-736.

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