[OPNFLWPLUG-722] Some Flows not found in DeviceFlowRegistry Created: 04/Jul/16  Updated: 27/Sep/21  Resolved: 01/Jun/17

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

Type: Bug
Reporter: Josh Hershberg Assignee: Josh Hershberg
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: 6146

 Description   

This was noticed with netvirt's TunnelFloodOut_ flows.

1) Create the flow. It gets written to the DeviceFlowRegistry
2) When the OFPST_FLOW comes the hash of the match object is different and therefor it is written with an "alien" Flow ID.

The following are some stuff I logged and then run through a pretty printer to format the yang nesting for easier reading. What you can see is that the FlowRegistryKey changes because the hash of the Match object changes. The augmentations in the two log lines seem functionally equivalent but very structurally different.

I will continue to dig on this and keep you updated but wanted to throw this out in case you have any relevant input already.

1) When the flow is written to config and inserted into the DeviceFlowRegistry the following log statement is issued:

LOG.trace("Storing flowDescriptor with table ID : {} and flow ID : {} for flow hash : {} {} {}",
flowDescriptor.getTableKey().getId(), flowDescriptor.getFlowId().getValue(),
flowRegistryKey.hashCode(), flowRegistryKey, flowRegistryKey.getMatch());

Which produces the following output (Pretty printed):
Storing flowDescriptor with table ID : 110 and flow ID : TunnelFloodOut_101 for flow hash : -1920448894 FlowRegistryKeyDto: org.opendaylight.openflowplugin.impl.registry.flow.FlowRegistryKeyFactory$FlowRegistryKeyDto@8d884682,
tableId: 110,
priority: 16383,
cookie: 0,
match (hash): -1921062477 Match{
getEthernetMatch=EthernetMatch{
getEthernetDestination=EthernetDestination{
getAddress=MacAddress [
_value=01:00:00:00:00:00
],
getMask=MacAddress [
_value=01:00:00:00:00:00
],
augmentations={}
} /* getEthernetDestination=EthernetDestination */,
augmentations={}
} /* getEthernetMatch=EthernetMatch */,
getTunnel=Tunnel{
getTunnelId=101,
augmentations={}
},
augmentations={
interface org.opendaylight.yang.gen.v1.urn.opendaylight.openflowplugin.extension.general.rev140714.GeneralAugMatchNodesNodeTableFlow=GeneralAugMatchNodesNodeTableFlow{
getExtensionList=[
ExtensionList{
getExtension=Extension{
augmentations={
interface org.opendaylight.yang.gen.v1.urn.opendaylight.openflowplugin.extension.nicira.match.rev140714.NxAugMatchNodesNodeTableFlow=NxAugMatchNodesNodeTableFlow{
getNxmNxReg=NxmNxReg{
getReg=class org.opendaylight.yang.gen.v1.urn.opendaylight.openflowjava.nx.match.rev140421.NxmNxReg0,
getValue=1,
augmentations={}
}
} /* interface org.opendaylight.yang.gen.v1.urn.opendaylight.openflowplugin.extension.nicira.match.rev140714.NxAugMatchNodesNodeTableFlow=NxAugMatchNodesNodeTableFlow */
} /* augmentations= */
} /* getExtension=Extension */,
getExtensionKey=class org.opendaylight.yang.gen.v1.urn.opendaylight.openflowplugin.extension.nicira.match.rev140714.NxmNxReg0Key,
augmentations={}
} /* ExtensionList */
] /* getExtensionList= */
} /* interface org.opendaylight.yang.gen.v1.urn.opendaylight.openflowplugin.extension.general.rev140714.GeneralAugMatchNodesNodeTableFlow=GeneralAugMatchNodesNodeTableFlow */
} /* augmentations= */
} /* match (hash): -1921062477 Match */

2) When the OFPST_FLOW message comes in the following is logged from the DeviceFlowRegistry:

LOG.trace("Created alien flow id {} for flow hash {} {} {}",
flowDescriptor.getFlowId().getValue(), flowRegistryKey.hashCode(), flowRegistryKey,
flowRegistryKey.getMatch());
Which logs (pretty printed):
Created alien flow id #UF$TABLE*110-2 for flow hash 1557777654 FlowRegistryKeyDto: org.opendaylight.openflowplugin.impl.registry.flow.FlowRegistryKeyFactory$FlowRegistryKeyDto@5cd9ccf6,
tableId: 110,
priority: 16383,
cookie: 0,
match (hash): 1557164071 Match [
_ethernetMatch=EthernetMatch [
_ethernetDestination=EthernetDestination [
_address=MacAddress [
_value=01:00:00:00:00:00
],
_mask=MacAddress [
_value=01:00:00:00:00:00
],
augmentation=[]
] /* _ethernetDestination=EthernetDestination */,
augmentation=[]
] /* _ethernetMatch=EthernetMatch */,
_tunnel=Tunnel [
_tunnelId=101,
augmentation=[]
],
augmentation=[
GeneralAugMatchNotifUpdateFlowStats [
_extensionList=[
ExtensionList [
_extension=Extension [
augmentation=[
NxAugMatchNotifUpdateFlowStats [
_nxmNxReg=NxmNxReg [
_reg=class org.opendaylight.yang.gen.v1.urn.opendaylight.openflowjava.nx.match.rev140421.NxmNxReg0,
_value=1,
augmentation=[]
]
] /* NxAugMatchNotifUpdateFlowStats */
] /* augmentation= */
] /* _extension=Extension */,
_extensionKey=class org.opendaylight.yang.gen.v1.urn.opendaylight.openflowplugin.extension.nicira.match.rev140714.NxmNxReg0Key,
_key=ExtensionListKey [
_extensionKey=class org.opendaylight.yang.gen.v1.urn.opendaylight.openflowplugin.extension.nicira.match.rev140714.NxmNxReg0Key
],
augmentation=[]
] /* ExtensionList */
] /* _extensionList= */
] /* GeneralAugMatchNotifUpdateFlowStats */
] /* augmentation= */
] /* match (hash): 1557164071 Match */



 Comments   
Comment by Andrej Leitner [ 19/Jul/16 ]

gerrit: https://git.opendaylight.org/gerrit/#/c/41542

Comment by Andrej Leitner [ 04/Aug/16 ]

Hi guys, is this still an issue?
Previous gerrit patch was abandoned but another one by Anil was merged:
https://git.opendaylight.org/gerrit/#/c/42510/

Comment by Sam Hague [ 05/Aug/16 ]

(In reply to Andrej Leitner from comment #2)
> Hi guys, is this still an issue?
> Previous gerrit patch was abandoned but another one by Anil was merged:
> https://git.opendaylight.org/gerrit/#/c/42510/

Andrej, we put a workaround in so we need to back that out and check if this patch fixes the issue.

Comment by Andrej Leitner [ 05/Aug/16 ]

Ok, will wait for updates from you.

Comment by Andrej Leitner [ 15/Aug/16 ]

Hi Sam,
any updates? Can we close the bug?

Comment by Sam Hague [ 20/Aug/16 ]

Andrej, looks like some of the flows are being found but this one is not:

cookie=0x0, duration=33.467s, table=110, n_packets=0, n_bytes=0, priority=8192,tun_id=0x65 actions=drop

Comment by Shuva Jyoti Kar [ 20/Aug/16 ]

(In reply to Sam Hague from comment #6)
> Andrej, looks like some of the flows are being found but this one is not:
>
> cookie=0x0, duration=33.467s, table=110, n_packets=0, n_bytes=0,
> priority=8192,tun_id=0x65 actions=drop

So Sam how do we write this flow, using restconf or install any application that writes this flow?

Comment by Sam Hague [ 22/Aug/16 ]

Our netvirt application writes this flow to mdsal in response to OpenStack port updates. In the course of a simple test of creating a single network with two instances, this flows gets written five or 6 times. That seems to be the trigger - writing the same flow to config a few times and eventually end up with an alien flow id.

Comment by Shuva Jyoti Kar [ 22/Aug/16 ]

(In reply to Sam Hague from comment #8)
> Our netvirt application writes this flow to mdsal in response to OpenStack
> port updates. In the course of a simple test of creating a single network
> with two instances, this flows gets written five or 6 times. That seems to
> be the trigger - writing the same flow to config a few times and eventually
> end up with an alien flow id.

So in details, what exactly does the application do –
a)repeated add of the same flow
b)add once, update all other times
c)update always

Repeated add of the same flow will result in the alien flow id because adding multiple flows with the same flow-id for the same table is not correct.

There has been a patch pushed for updates failing due to BUG6458 last Friday, so it would be great if you could test and let us know if you still see the problem

Comment by Shuva Jyoti Kar [ 24/Aug/16 ]

Sam/Josh,

Did you get a chance to go through? any updates on it ?

Comment by Andrej Leitner [ 25/Aug/16 ]

Since we believe the issue is fixed changing the priority to normal for now.

Comment by Jozef Bacigal [ 01/Jun/17 ]

No response long time, assume the issue is already fixed.

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