Bug 1867769

Hi Matt,

Can you get me the following info to continue the investigation:

- Get a capture of the actual VRRP packet not making it trough. This was you can determine the src/dst MAC and IPs. 
- Save this packet to a pcap file so I can take a look at the details also
- With this capture convert the specific packet for use with ofproto trace doing "ovs-pcap out.pcap"
- Now use this packet to do the ofproto trace, for example (make sure to use your port and packet data):

 ovs-appctl ofproto/trace ovs_pvp_br0 in_port=<your port> <your hex packet output from ovs-pcap> 

- Get me an openvswitch only SOS report right after the above so I can compare the data and do a replication.

Thanks,

Eelco

Any update on #20? Asking as this is marked as an urgent BZ, and escalated as PM high but got no input for 2 days.

Thanks for the info, I'll try to replicate the behavior on my dev setup.

So the issue is clear, connection tracking for the userspace datapath only supports TCP/UDP/ICMPv4/ICMPv6, all other protocols are NOT supported. For connection tracking this results for the state to be set to +inv.

Not sure how OSP rules are build but looking at the current OVS ruleset in the SOS report it can be solved by adding the following rules:

ovs-ofctl add-flow br-int "table=72 priority=77,ct_state=+inv,ip,reg5=0x9,nw_proto=112 actions=resubmit(,73)"
ovs-ofctl add-flow br-int "table=73 priority=90,ct_state=+inv,ip,reg5=0x9 actions=resubmit(,91)"

At least this worked in my replication setup:

ovs-ofctl del-flows ovs_pvp_br0
ovs-ofctl add-flow ovs_pvp_br0 "in_port=dpdk0,actions=goto_table:60"

ovs-ofctl add-flow ovs_pvp_br0 "table=60,priority=100,in_port=dpdk0,actions=set_field:0x9->reg5,set_field:0x2->reg6,resubmit(,71)"

ovs-ofctl add-flow ovs_pvp_br0 "table=71,priority=65,ip,reg5=0x9,in_port=dpdk0,dl_src=00:00:5e:00:01:01,nw_src=192.168.0.30,actions=ct(table=72,zone=NXM_NX_REG6[0..15])"
ovs-ofctl add-flow ovs_pvp_br0 "table=71 priority=0 actions=drop"

ovs-ofctl add-flow ovs_pvp_br0 "table=72 priority=77,ct_state=+est-rel-rpl,ip,reg5=0x9,nw_dst=192.168.0.0/24,nw_proto=112 actions=resubmit(,73)"
ovs-ofctl add-flow ovs_pvp_br0 "table=72 priority=77,ct_state=+new-est,ip,reg5=0x9,nw_dst=192.168.0.0/24,nw_proto=112 actions=resubmit(,73)"
ovs-ofctl add-flow ovs_pvp_br0 "table=72 priority=77,ct_state=+est-rel-rpl,ip,reg5=0x9,nw_proto=112 actions=resubmit(,73)"
ovs-ofctl add-flow ovs_pvp_br0 "table=72 priority=77,ct_state=+new-est,ip,reg5=0x9,nw_proto=112 actions=resubmit(,73)"
ovs-ofctl add-flow ovs_pvp_br0 "table=72 priority=77,ct_state=+inv,ip,reg5=0x9,nw_proto=112 actions=resubmit(,73)"
ovs-ofctl add-flow ovs_pvp_br0 "table=72 priority=0 actions=drop"

ovs-ofctl add-flow ovs_pvp_br0 "table=73 priority=90,ct_state=+inv,ip,reg5=0x9 actions=resubmit(,91)"
ovs-ofctl add-flow ovs_pvp_br0 "table=73 priority=90,ct_state=+new-est,ip,reg5=0x9 actions=ct(commit,zone=NXM_NX_REG6[0..15]),resubmit(,91)"
ovs-ofctl add-flow ovs_pvp_br0 "table=73 priority=80,reg5=0x9 actions=resubmit(,91)"

ovs-ofctl add-flow ovs_pvp_br0 "table=91 actions=dpdk1"

Hi Matt:

According to Eelco's reply (thanks for the analysis) and further conversations out of this BZ, this is not going to be solved in the next months. Then the customer could decide to:
1) Use kernel OVS. VRRP protocol packets are correctly tracked and forwarded and OVS firewall can be used.
2) For those systems transmitting/receiving VRRP traffic, disable the OVS firewall. That will disable security groups in this system but will allow VRRP traffic to be transmitted.

Regards.

(In reply to Rodolfo Alonso from comment #28)
> Hi Matt:
> 
> According to Eelco's reply (thanks for the analysis) and further
> conversations out of this BZ, this is not going to be solved in the next
> months. 

I'm referring here to the OVS-DPDK connection tracking implementation, however, I do think the workaround above with the additional (or replacing of) the CT rules could fix this. However, this requires a Neutron change. 

> Then the customer could decide to:
> 1) Use kernel OVS. VRRP protocol packets are correctly tracked and forwarded
> and OVS firewall can be used.
> 2) For those systems transmitting/receiving VRRP traffic, disable the OVS
> firewall. That will disable security groups in this system but will allow
> VRRP traffic to be transmitted.

These can be short term workarounds.

Also, I guess this BZ should go back to the neutron team to investigate the neutron change.

Hi Eelco:

This is highly unlikely that we implement this kind of workaround just for a specific protocol and a specific backend.

Regards.

(In reply to Rodolfo Alonso from comment #31)
> Hi Eelco:
> 
> This is highly unlikely that we implement this kind of workaround just for a
> specific protocol and a specific backend.

Ok, will leave this to the Neutron team to decide, will assign this BZ back to them for now.

I'll create an RFE BZ for OVS to see if this can ever be added in the future ;)

> (In reply to Rodolfo Alonso from comment #31)
> This is highly unlikely that we implement this kind of workaround just for a
> specific protocol and a specific backend.

I think you could say for this specific datapath you need it for any protocol not being UDP/TCP/ICMPv4/ICMPv6.