[OPNFLWPLUG-862] reg matches with a mask causes a flood of "Message deserialization failed" exceptions Created: 03/Mar/17  Updated: 27/Sep/21  Resolved: 16/Mar/17

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

Type: Bug
Reporter: Janki Chhatbar Assignee: Tomas Slusny
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File flowstats1.pcap    
External issue ID: 7897

 Description   

Found in https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-nodl-v2-upstream-stateful-boron/158/archives/odl1_karaf.log.gz

Found in Carbon https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-nodl-v2-upstream-stateful-carbon/152/archives/odl1_karaf.log.gz

Message deserialization failed
java.lang.IllegalStateException: Deserializer for key: msgVersion: 4 objectClass: org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.oxm.rev150225.match.entries.grouping.MatchEntry msgType: 15 oxm_field: 127 experimenterID: null was not found - please verify that all needed deserializers ale loaded correctly



 Comments   
Comment by Koby Aizer [ 09/Mar/17 ]

Attachment flowstats1.pcap has been added with description: flow stats that cause the exception

Comment by Koby Aizer [ 09/Mar/17 ]

I looked into this exception a little bit, and I think it is caused by flow stats received from table=49. This table includes the rules like:
cookie=0x8600000, duration=1.507s, table=49, n_packets=0, n_bytes=0, hard_timeout=10, priority=0,reg1=0x2/0xfffff,dl_src=fa:16:3e:7d:5a:42 actions=load:0x1->NXM_NX_REG4[0..7]

I've tcpdumped the flowstats, and for some reason the REG1 OXM value is 8byte long, while openflowplugin assumes it is 4byte long - and I think this causes the decoder to fail (the exception is just a side effect of the decoder trying to decode the additional 4bytes as the next OXM field) .
Other reg matches (for example, the ones from table=220) are indeed 4byte long.
Not sure why the table=49 reg matches has a different size, the only reason I can think of is that those matches are created by OVS learn action.

Attached a pcap of the problematic flow stats (look for the REG1 OXM match under table=49)

Comment by Koby Aizer [ 13/Mar/17 ]

Updated the bug title to be more informative, and moving bug to openflowplugin.

It seems like the 4byte/8byte difference I noted earlier is because the REG1 match was masked. Therefore, the OXM data is 8byte long (4byte value + 4byte mask). It seems like this wasn't taken into account when decoding the OXM.

Comment by Janki Chhatbar [ 14/Mar/17 ]

Hi Tomas,

Are you working on this? I was working on it. Not sure why I was unassigned from this bug. We can work together if you haven't still submitted the patch. If you have, please share its link.

Comment by Tomas Slusny [ 14/Mar/17 ]

You was assigned to it, but it was not in progress, so I assumed that no one is working on it. Yes, I already made patch for it, and also Guarav made patch for it, so I don't know, I can abandon mine patch.

Anyway, here is link to Guarav's patch: https://git.opendaylight.org/gerrit/#/c/51936/ and here is link to mine: https://git.opendaylight.org/gerrit/#/c/51936/.

Comment by Tomas Slusny [ 14/Mar/17 ]
Comment by Jamo Luhrsen [ 15/Mar/17 ]

(In reply to Tomas Slusny from comment #6)
> * link to my patch: https://git.opendaylight.org/gerrit/#/c/53259

looks to have worked.

here is patch test job's karaf.log without these exceptions
(Note: the karaf log seems to be amost 100k smaller now too)

https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-nodl-v2-gate-stateful-carbon/408/archives/odl1_karaf.log.gz

just go back one job if you want to double check how it was
https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-nodl-v2-gate-stateful-carbon/407/archives/odl1_karaf.log.gz

Much appreciated Tomas!

Comment by Janki Chhatbar [ 15/Mar/17 ]

Works in local CSIT environment too. Thanks Tomas!

Comment by Tomas Slusny [ 16/Mar/17 ]

Patch was merged, so based on comments I think I can close this.

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