[NETVIRT-655] New netvirt classifier handling already classified packets on egress Created: 05/May/17  Updated: 19/May/17  Resolved: 19/May/17

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

Type: Bug
Reporter: Jaime Caamaño Ruiz Assignee: Jaime Caamaño Ruiz
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: 8388

 Description   

New netvirt classifier is intercepting packets meant for a SF on egress. The problem is on table 221, where supposedly any packet that has not just being classified should return to the egress dispatcher:

New netvirt classifier not setting tun id to 0 when egressing to SFF

cookie=0xf005ba1100000003, duration=1214.452s, table=221, n_packets=256, n_bytes=28672, priority=260,nsh_mdtype=1 actions=goto_table:222
cookie=0xf005ba1100000003, duration=1214.452s, table=221, n_packets=1, n_bytes=42, priority=250 actions=resubmit(,220)

nsh_mdtype=1 is being used as a flag of recently classified packet but it is not an appropiate one, as packets being handled by SFF logic will also have that set.

An alternate option is to set a magic value into CX on the ACL flow, like 0xFFFFFFFF. This will flag a just-classified packet, and reset it afterwards.



 Comments   
Comment by Jaime Caamaño Ruiz [ 05/May/17 ]

Please ignore "New netvirt classifier not setting tun id to 0 when egressing to SFF" on the above comment as that was pasted by mistake.

Comment by Jaime Caamaño Ruiz [ 05/May/17 ]

One first proposal is to set C1 to 0xFFFFFF on the ACL flow. Then on beguinning of egress pipeline, if C1 does not have that value we assumed thats a packet bound for the SF and already classified so it is resubmitteed to dispatcher. Otherwise, C1 is reset to 0 and handling continues:

cookie=0xf005ba1100000002, duration=3129.696s, table=101, n_packets=0, n_bytes=0, priority=500,tcp,in_port=1,nw_src=10.0.0.0/24,tp_dst=80 actions=push_nsh,load:0x1->NXM_NX_NSH_MDTYPE[],load:0x3->NXM_NX_NSH_NP[],load:0x13->NXM_NX_NSP[0..23],load:0xff->NXM_NX_NSI[],load:0xffffff->NXM_NX_NSH_C1[],load:0->NXM_NX_NSH_C2[],load:0xac130002->NXM_NX_REG0[],resubmit(,17)

...

cookie=0xf005ba1100000003, duration=3157.512s, table=221, n_packets=0, n_bytes=0, priority=260,nshc1=16777215 actions=load:0->NXM_NX_NSH_C1[],goto_table:222

Comment by Jaime Caamaño Ruiz [ 08/May/17 ]

Patches submitted for carbon [1] and Nitrogen [2].

[1] https://git.opendaylight.org/gerrit/#/c/56667/
[2] https://git.opendaylight.org/gerrit/#/c/56610/

Comment by A H [ 17/May/17 ]

We are looking to build Carbon RC2 tomorrow 5/18 at 23:59 UTC time assuming there are no blocker bugs. Is there an ETA for when a fix can be merged and this bug resolved for stable/carbon branch?

Comment by Sam Hague [ 18/May/17 ]

(In reply to A H from comment #4)
> We are looking to build Carbon RC2 tomorrow 5/18 at 23:59 UTC time assuming
> there are no blocker bugs. Is there an ETA for when a fix can be merged and
> this bug resolved for stable/carbon branch?

The patches are ready and listed in the previous comment

Comment by Jamo Luhrsen [ 18/May/17 ]

earlier carbon patch noted was abandoned. this carbon patch is here:

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

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