[ovs-dev] [PATCH v3 9/9] ofproto-dpif-xlate: Translate timeout policy in ct action

Darrell Ball dlu998 at gmail.com
Tue Aug 13 18:42:56 UTC 2019


On Tue, Aug 13, 2019 at 11:01 AM Yi-Hung Wei <yihung.wei at gmail.com> wrote:

> On Mon, Aug 12, 2019 at 7:35 PM Darrell Ball <dlu998 at gmail.com> wrote:
> >
> > Thanks for the patch
> >
> > Not a full review; I just did a quick run of the test using a more
> recent kernel version
> >
> > dball at ubuntu:~/ovs$ uname -r
> > 5.0.0-23-generic
> > dball at ubuntu:~/ovs$ lsb_release -a
> > No LSB modules are available.
> > Distributor ID: Ubuntu
> > Description: Ubuntu 18.04.3 LTS
> > Release: 18.04
> > Codename: bionic
> >
> > The test is no longer blocked on subsequent runs, at least with this
> kernel version (others: TBD) - cool !
> >
> > However
> >
> > ## ------------------------------- ##
> > ## openvswitch 2.12.90 test suite. ##
> > ## ------------------------------- ##
> >  75: conntrack - zone-based timeout policy           FAILED (
> system-traffic.at:3228)
> >
> > .
> > .
> > .
> > VSCTL_ADD_ZONE_TIMEOUT_POLICY([zone=5 udp_single=3 icmp_first=3])
> >
> > dnl Send ICMP and UDP traffic
> > NS_CHECK_EXEC([at_ns0], [ping -q -c 3 -i 0.3 -w 2 10.1.1.2 |
> FORMAT_PING], [0], [dnl   <<<<<<<<<<<<<<<<<<<<< FAILS HERE
> > 3 packets transmitted, 3 received, 0% packet loss, time 0ms
> > ])
> > .
> > .
> > .
> >
> > -3 packets transmitted, 3 received, 0% packet loss, time 0ms
> > +7 packets transmitted, 0 received, 100% packet loss, time 0ms
> >
> > warnings:
> >
> > > 2019-08-13T02:19:06.674Z|00001|dpif(handler1)|WARN|system at ovs-system:
> failed to put[create] (Invalid argument)
> ufid:55d8603a-729c-43d7-9612-b54553e46299
> recirc_id(0x2),dp_hash(0/0),skb_priority(0/0),in_port(2),skb_mark(0/0),ct_state(0x21/0x23),ct_zone(0x5/0),ct_mark(0/0),ct_label(0/0),ct_tuple4(src=
> 10.1.1.1/0.0.0.0,dst=10.1.1.2/0.0.0.0,proto=1/0,tp_src=8/0,tp_dst=0/0
> ),eth(src=8a:ea:c3:02:6f:94/00:00:00:00:00:00,dst=92:48:5b:47:e2:63/00:00:00:00:00:00),eth_type(0x0800),ipv4(src=
> 10.1.1.1/0.0.0.0,dst=10.1.1.2/0.0.0.0,proto=1,tos=0/0,ttl=64/0,frag=no),icmp(type=8/0,code=0/0),
> actions:ct(commit,zone=5,timeout=ovs_tp_0_icmp4),3
> > > 2019-08-13T02:19:06.674Z|00002|dpif(handler1)|WARN|system at ovs-system:
> execute ct(commit,zone=5,timeout=ovs_tp_0_icmp4),3 failed (Invalid
> argument) on packet
> icmp,vlan_tci=0x0000,dl_src=8a:ea:c3:02:6f:94,dl_dst=92:48:5b:47:e2:63,nw_src=10.1.1.1,nw_dst=10.1.1.2,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
> icmp_csum:4d0a
> > >  with metadata
> skb_priority(0),skb_mark(0),ct_state(0x21),ct_zone(0x5),ct_tuple4(src=10.1.1.1,dst=10.1.1.2,proto=1,tp_src=8,tp_dst=0),in_port(2)
> mtu 0
> > > 2019-08-13T02:19:06.999Z|00003|dpif(handler1)|WARN|system at ovs-system:
> failed to put[create] (Invalid argument)
> ufid:55d8603a-729c-43d7-9612-b54553e46299
> recirc_id(0x2),dp_hash(0/0),skb_priority(0/0),in_port(2),skb_mark(0/0),ct_state(0x21/0x23),ct_zone(0x5/0),ct_mark(0/0),ct_label(0/0),ct_tuple4(src=
> 10.1.1.1/0.0.0.0,dst=10.1.1.2/0.0.0.0,proto=1/0,tp_src=8/0,tp_dst=0/0
> ),eth(src=8a:ea:c3:02:6f:94/00:00:00:00:00:00,dst=92:48:5b:47:e2:63/00:00:00:00:00:00),eth_type(0x0800),ipv4(src=
> 10.1.1.1/0.0.0.0,dst=10.1.1.2/0.0.0.0,proto=1,tos=0/0,ttl=64/0,frag=no),icmp(type=8/0,code=0/0),
> actions:ct(commit,zone=5,timeout=ovs_tp_0_icmp4),3
> > > 2019-08-13T02:19:06.999Z|00004|dpif(handler1)|WARN|system at ovs-system:
> execute ct(commit,zone=5,timeout=ovs_tp_0_icmp4),3 failed (Invalid
> argument) on packet
> icmp,vlan_tci=0x0000,dl_src=8a:ea:c3:02:6f:94,dl_dst=92:48:5b:47:e2:63,nw_src=10.1.1.1,nw_dst=10.1.1.2,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
> icmp_csum:2f10
> > >  with metadata
> skb_priority(0),skb_mark(0),ct_state(0x21),ct_zone(0x5),ct_tuple4(src=10.1.1.1,dst=10.1.1.2,proto=1,tp_src=8,tp_dst=0),in_port(2)
> mtu 0
>
> Thanks for trying this test out on the other setup.
>
> The warning messages indicate that the kernel module does not
> understand the new added ct timeout action attribute.  I am wondering
> if the system used the correct kernel module?  Can you check 'modinfo
> openvswitch' and 'dmesg' to make sure the correct kernel module is
> loaded in the system?
>
> Thanks,
>
> -Yi-Hung
>

Sure, circling back to this part....

yep, it is the Linux In-tree kernel module rather than OVS tree module

dball at ubuntu:~/ovs$ modinfo openvswitch
filename:
/lib/modules/5.0.0-23-generic/kernel/net/openvswitch/openvswitch.ko
alias:          net-pf-16-proto-16-family-ovs_ct_limit
alias:          net-pf-16-proto-16-family-ovs_meter
alias:          net-pf-16-proto-16-family-ovs_packet
alias:          net-pf-16-proto-16-family-ovs_flow
alias:          net-pf-16-proto-16-family-ovs_vport
alias:          net-pf-16-proto-16-family-ovs_datapath
license:        GPL
description:    Open vSwitch switching datapath
srcversion:     12850657561FB87D174A001
depends:
 nf_conntrack,nf_nat,nf_conncount,libcrc32c,nf_nat_ipv6,nf_nat_ipv4,nf_defrag_ipv6,nsh
retpoline:      Y
intree:         Y
name:           openvswitch
vermagic:       5.0.0-23-generic SMP mod_unload
signat:         PKCS#7
signer:
sig_key:
sig_hashalgo:   md4

btw, similarly
make 'check-kernel' fails for the same reasons.

Ostensibly, I would have expected 5.0 to be ok.
I can dig more on this part later if you wish.

btw, I think a timeout policy not being applied should not result in packet
blackholing.
I think we need to make this better.
A timeout policy is just a nice to have 'thingy' after all.

That being said, I would like to see Xenial working (with OVS in-tree
module) with higher priority.

Thanks Darrell


More information about the dev mailing list