[ovs-discuss] [ovs-dev] RX Mirroing issue with Decap in vxlan case

John Hurley john.hurley at netronome.com
Tue Nov 6 17:34:09 UTC 2018


On Wed, Oct 17, 2018 at 10:24 PM Limaye, Namrata
<namrata.limaye at intel.com> wrote:
>
> Thanks John,
>
> I agree with you that this configuration is between vxlan0 and VF port and we will see only decap packets from vxlan0.
>
> So, I created another config on bridge br1 instead of br0 to mirror all traffic between eth0.101 and tep0 port.  How will this get mapped into the offloaded flow. Shouldn't this enable RX-mirroring? Since we offload from br0, Can we get the mirror ports from br1 and apply them onto the output ports for br0? I see the mirror port been added to the flow that is offloaded to the kernel - eth1.129.tep0. Output is below.
>
> ovs-vsctl -- --id=@eth1.101 get Port eth1.101 -- --id=@eth1.129 get Port eth1.129 -- --id=@m create Mirror name=mirror1 select-src-port=@eth1.101 output-port=@eth1.129 -- set Bridge br1 mirrors=@m
>
> Offloaded flows to OVS kernel and TC -
>
> # ovs-appctl dpctl/dump-flows -m type=offloaded
> ufid:c74465c0-1d96-4863-b01d-0b4f3d851de1, skb_priority(0/0),skb_mark(0/0),in_port(eth1.190),packet_type(ns=0/0,id=0/0),eth(src=78:94:56:ab:cd:f0,dst=00:e8:ca:11:ba:40),eth_type(0x0800),ipv4(src=1.1.1.63,dst=1.1.2.63,proto=1,tos=0/0,ttl=0/0),icmp(type=0/0,code=0/0), packets:3, bytes:294, used:0.500s, actions:set(tunnel(tun_id=0x1388,dst=40.1.1.2,tp_dst=4789,flags(key))),vxlan_sys_4789
> ufid:31165e07-1c16-4559-8837-0cd91669dd00, skb_priority(0/0),tunnel(tun_id=0x1388,src=40.1.1.2,dst=40.1.1.1,ttl=0/0,tp_dst=4789,flags(+key)),skb_mark(0/0),in_port(vxlan_sys_4789),packet_type(ns=0/0,id=0/0),eth(src=00:e8:ca:11:ba:40,dst=78:94:56:ab:cd:f0),eth_type(0x0800),ipv4(src=1.1.2.63,dst=1.1.1.63,proto=1,tos=0/0,ttl=0/0),icmp(type=0/0,code=0/0), packets:3, bytes:444, used:0.500s, actions:eth1.190
>

Hi Namrata,
I'm not sure I fully understand your setup and what you are trying to
achieve with the information available but the offloaded rules above
seem fine.
These do not include eth1.101 as the mirror source port so we wouldn't
expect the mirror to be offloaded here.
i.e. I do not thing there is a problem with the TC conversion code here.

Below I see the expected datapath rule for the mirroring (rules
matching on eth1.101).
Do you expect these to be offloaded?
Does port eth1.101 support offload (if not then the datapath rule will
stay in kernel)?
What are the TC rules generated here?
It would also be a good idea to test this without the TC datapath - if
it still doesn't work as expected then the issue is likely the
bridge/rules/mirror setup and not an offload bug (as originally
suggested).

> #ovs-appctl dpctl/dump-flows -m
> ufid:c74465c0-1d96-4863-b01d-0b4f3d851de1, skb_priority(0/0),skb_mark(0/0),in_port(eth1.190),packet_type(ns=0/0,id=0/0),eth(src=78:94:56:ab:cd:f0,dst=00:e8:ca:11:ba:40),eth_type(0x0800),ipv4(src=1.1.1.63,dst=1.1.2.63,proto=1,tos=0/0,ttl=0/0),icmp(type=0/0,code=0/0), packets:6, bytes:588, used:0.850s, offloaded:yes, actions:set(tunnel(tun_id=0x1388,dst=40.1.1.2,tp_dst=4789,flags(key))),vxlan_sys_4789
> ufid:31165e07-1c16-4559-8837-0cd91669dd00, skb_priority(0/0),tunnel(tun_id=0x1388,src=40.1.1.2,dst=40.1.1.1,ttl=0/0,tp_dst=4789,flags(+key)),skb_mark(0/0),in_port(vxlan_sys_4789),packet_type(ns=0/0,id=0/0),eth(src=00:e8:ca:11:ba:40,dst=78:94:56:ab:cd:f0),eth_type(0x0800),ipv4(src=1.1.2.63,dst=1.1.1.63,proto=1,tos=0/0,ttl=0/0),icmp(type=0/0,code=0/0), packets:6, bytes:888, used:0.840s, offloaded:yes, actions:eth1.190
> ufid:7b8aa742-d765-4614-96ad-7892ac034b04, recirc_id(0),dp_hash(0),skb_priority(0),in_port(tep0),skb_mark(0),ct_state(0x21/0xff),ct_zone(0),ct_mark(0),ct_label(0),ct_tuple4(src=40.1.1.1,dst=40.1.1.2,proto=17,tp_src=50386,tp_dst=4789),eth(src=ea:85:f2:0b:f5:4b,dst=2e:bd:c5:98:6b:51),eth_type(0x0800),ipv4(src=40.1.1.1,dst=40.1.1.2,proto=17,tos=0,ttl=64,frag=no),udp(src=50386,dst=4789), packets:0, bytes:0, used:never, actions:eth1.101
> ufid:0e787372-fda9-47ae-958d-494c59607bf6, recirc_id(0),dp_hash(0),skb_priority(0),tunnel(tun_id=0x1388,src=40.1.1.2,dst=40.1.1.1,ttl=64,tp_src=39601,tp_dst=4789,flags(+key)),in_port(vxlan_sys_4789),skb_mark(0),ct_state(0/0xff),ct_zone(0),ct_mark(0),ct_label(0),eth(src=00:e8:ca:11:ba:40,dst=78:94:56:ab:cd:f0),eth_type(0x0806),arp(sip=1.1.2.63,tip=1.1.1.63,op=2/0xff,sha=00:e8:ca:11:ba:40,tha=78:94:56:ab:cd:f0), packets:0, bytes:0, used:never, actions:eth1.190
> ufid:ee94c743-30aa-4f72-8d57-bf4a60dd5ccb, recirc_id(0),dp_hash(0),skb_priority(0),in_port(eth1.101),skb_mark(0),ct_state(0/0xff),ct_zone(0),ct_mark(0),ct_label(0),eth(src=2e:bd:c5:98:6b:51,dst=ea:85:f2:0b:f5:4b),eth_type(0x0800),ipv4(src=40.1.1.2,dst=40.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=39601,dst=4789), packets:0, bytes:0, used:never, actions:eth1.129,tep0
> ufid:e80c2c22-7191-4da8-94dc-21d4bde77872, recirc_id(0),dp_hash(0),skb_priority(0),in_port(tep0),skb_mark(0),ct_state(0/0xff),ct_zone(0),ct_mark(0),ct_label(0),eth(src=ea:85:f2:0b:f5:4b,dst=2e:bd:c5:98:6b:51),eth_type(0x0806),arp(sip=40.1.1.1,tip=40.1.1.2,op=1/0xff,sha=ea:85:f2:0b:f5:4b,tha=00:00:00:00:00:00), packets:0, bytes:0, used:never, actions:eth1.101
> ufid:48d82bcf-ebc3-486d-ad59-d525860082b7, recirc_id(0),dp_hash(0),skb_priority(0),in_port(eth1.101),skb_mark(0),ct_state(0/0xff),ct_zone(0),ct_mark(0),ct_label(0),eth(src=2e:bd:c5:98:6b:51,dst=ea:85:f2:0b:f5:4b),eth_type(0x0806),arp(sip=40.1.1.2,tip=40.1.1.1,op=2/0xff,sha=2e:bd:c5:98:6b:51,tha=ea:85:f2:0b:f5:4b), packets:0, bytes:0, used:never, actions:eth1.129,tep0
> ufid:8a1f5c21-feca-462a-8885-b21dd2a58076, recirc_id(0),dp_hash(0),skb_priority(0),in_port(eth1.101),skb_mark(0),ct_state(0/0xff),ct_zone(0),ct_mark(0),ct_label(0),eth(src=2e:bd:c5:98:6b:51,dst=ea:85:f2:0b:f5:4b),eth_type(0x0800),ipv4(src=40.1.1.2,dst=40.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=39016,dst=4789), packets:0, bytes:0, used:never, actions:eth1.129,tep0
> ufid:d998ffb9-1646-48ce-b97a-48b35eaf40c1, recirc_id(0),dp_hash(0),skb_priority(0),in_port(tep0),skb_mark(0),ct_state(0x21/0xff),ct_zone(0),ct_mark(0),ct_label(0),ct_tuple4(src=40.1.1.1,dst=40.1.1.2,proto=17,tp_src=50053,tp_dst=4789),eth(src=ea:85:f2:0b:f5:4b,dst=2e:bd:c5:98:6b:51),eth_type(0x0800),ipv4(src=40.1.1.1,dst=40.1.1.2,proto=17,tos=0,ttl=64,frag=no),udp(src=50053,dst=4789), packets:0, bytes:0, used:never, actions:eth1.101
> ufid:5a932c98-8e3a-4d96-a9b8-18916a3d0844, recirc_id(0),dp_hash(0),skb_priority(0),in_port(eth1.190),skb_mark(0),ct_state(0/0xff),ct_zone(0),ct_mark(0),ct_label(0),eth(src=78:94:56:ab:cd:f0,dst=00:e8:ca:11:ba:40),eth_type(0x0806),arp(sip=1.1.1.63,tip=1.1.2.63,op=1/0xff,sha=78:94:56:ab:cd:f0,tha=00:00:00:00:00:00), packets:0, bytes:0, used:never, actions:set(tunnel(tun_id=0x1388,dst=40.1.1.2,ttl=64,tp_dst=4789,flags(df|key))),vxlan_sys_4789
>
> Thanks
> Namrata
>
> -----Original Message-----
> From: John Hurley [mailto:john.hurley at netronome.com]
> Sent: Wednesday, September 26, 2018 7:09 AM
> To: Limaye, Namrata <namrata.limaye at intel.com>
> Cc: Simon Horman <simon.horman at netronome.com>; Ben Pfaff <blp at ovn.org>; ovs-dev at openvswitch.org; bugs at openvswitch.org; Saha, Gargi <gargi.saha at intel.com>; Choi, James <james.choi at intel.com>
> Subject: Re: [ovs-discuss] [ovs-dev] RX Mirroing issue with Decap in vxlan case
>
> On Tue, Sep 25, 2018 at 10:22 PM Limaye, Namrata <namrata.limaye at intel.com> wrote:
> >
> > Hi John,
> >
> > Here's the answer to your questions -
> >
>
> Thanks for the info.
>
> > 1. Can you give more information on your setup?
> > ===Nam) I have back to back connected hosts with OVS running and 2 VMs on each side. VxLan is configured on both sides. Port 101 carries tunneled traffic. This is the configuration. The traffic is tunneled between eth0.128  and eth0.101 and mirrored to non-vxlan port eth0.129 connected to Host 2.
> >
> > VM1 - -- Host 1  ---------- (eth0.101) Host 2 (OVS) ---- VM3 (eth0.128),
> > VM2 ---                                            ---- VM4 (eth0.129 - mirror)
> >
> > Mirroring config is on Host 2. Tep is configured on Br1. And vxlan0
> > port + eth0.128 and eth0.129 are on br0
> >
> > Following is the config -
> > ovs-vsctl -- --id=@p get port vxlan0 -- --id=@eth0.128 get Port
> > eth0.128 -- --id=@eth0.129 get Port eth0.129 -- --id=@m create Mirror
> > name=mirror1 select-src-port=@eth0.128, at p output-port=@eth0.129 -- set
> > Bridge br0 mirrors=@m
> >
> > VXLAN config for HOST2 -
> >
> > HOST 2:
> > ovs-vsctl add-br br1
> > ovs-vsctl add-port br1 eth0.101 -- set interface eth0.101
> > ofport_request=101 ovs-vsctl add-port br1 tep0 -- set interface tep0
> > type=internal ip addr add 30.1.1.2/24 dev tep0 ip link set tep0 up
> > ovs-vsctl add-port br0 vxlan0 -- set interface vxlan0 type=vxlan
> > options:remote_ip=30.1.1.1 options:key=5000 options:dest_port=4789
> > ovs-vsctl add-port br0 eth0.128 -- set interface eth0.101
> > ofport_request=128 ovs-vsctl add-port br0 eth0.129 -- set interface
> > eth0.101 ofport_request=129
> >
> > 2. Above you mention that you are expecting a decap (suggesting we will hit a vxlan port on the bridge) but the port mirroring is on a non vxlan netdev (eth0.128) - is this correct?
> > With this, I'm not sure how we get a TC action on a single port that includes both the mirror and the decap (1, 2, 3 above)?
> > ====Nam)
> > For RX mirroring the final Encap flow that is offloaded to hardware is
> > below which is correct order - root at FPA1066GX-DA2:~# ovs-appctl
> > dpctl/dump-flows -m type=offloaded
> > ufid:157aa38b-3f13-41b8-8dac-a83ba44729c2,
> > skb_priority(0/0),skb_mark(0/0),in_port(eth0.128),packet_type(ns=0/0,i
> > d=0/0),eth(src=00:e8:ca:11:bc:02,dst=00:e8:ca:11:bb:02),eth_type(0x080
> > 0),ipv4(src=1.1.3.1,dst=1.1.2.1,proto=1,tos=0/0,ttl=0/0),icmp(type=0/0
> > ,code=0/0), packets:3, bytes:294, used:1.360s,
> > actions:eth0.129,set(tunnel(tun_id=0x1388,dst=40.1.1.2,tp_dst=4789,fla
> > gs(key))),vxlan_sys_4789 <==== CORRECT
> >
>
> I agree that this looks correct.
>
> > The Decap flow that gets offloaded is -
> > ufid:03b34739-c02e-4258-9162-997e4b365aad,
> > skb_priority(0/0),tunnel(tun_id=0x1388,src=40.1.1.2,dst=40.1.1.1,ttl=0
> > /0,tp_dst=4789,flags(+key)),skb_mark(0/0),in_port(vxlan_sys_4789),pack
> > et_type(ns=0/0,id=0/0),eth(src=00:e8:ca:11:bb:02,dst=00:e8:ca:11:bc:02
> > ),eth_type(0x0800),ipv4(src=1.1.2.1,dst=1.1.3.1,proto=1,tos=0/0,ttl=0/
> > 0),icmp(type=0/0,code=0/0), packets:3, bytes:444, used:1.360s,
> > actions:eth0.129,eth0.128
> >
> > As you see it does not show the decap action in the above flow, but if
> > you look at the TC code in function 'nl_msg_put_flower_acts' it does
> > add the decap action netlink attribute to the flow and send it down to
> > TC -
>
> I think this issue here is that a decap is implied in this rule without being stated.
> If we receive data on an ingress port of type vxlan, then it must match the vxlan params and the first thing that will happen is a decap.
> To put it another way, the RX traffic on a vxlan port can be thought of as the decapped packets, not the vxlan encapped packets.
> With this in mind, I would expect the mirrored packets to be decapped......
>
> I ran a test similar to this, mirroring packets on a vxlan dev:
>
> recirc_id(0),tunnel(tun_id=0x7b,src=10.0.0.2,dst=10.0.0.1,flags(-df-csum+key)),in_port(4),eth(),eth_type(0x0800),ipv4(proto=6,frag=no),
> packets:266, bytes:35623, used:451.124s, flags:SFPR., actions:3,2
>
> Where port 4 is of type vxlan, 3 is the mirrored output and 2 is a standard output port.
> I ran this both on TC and without TC (OvS kernel datapath).
> In both tests decapped packets are on the mirrored port (implying decap as a first action).
>
> > if (flower->tunnel.tunnel) {
> >             act_offset = nl_msg_start_nested(request, act_index++);
> >             nl_msg_put_act_tunnel_key_release(request);
> >             nl_msg_end_nested(request, act_offset); } So, the final
> > flow for RX case that goes down to TC looks like -
> > ufid:03b34739-c02e-4258-9162-997e4b365aad,
> > skb_priority(0/0),tunnel(tun_id=0x1388,src=40.1.1.2,dst=40.1.1.1,ttl=0
> > /0,tp_dst=4789,flags(+key)),skb_mark(0/0),in_port(vxlan_sys_4789),pack
> > et_type(ns=0/0,id=0/0),eth(src=00:e8:ca:11:bb:02,dst=00:e8:ca:11:bc:02
> > ),eth_type(0x0800),ipv4(src=1.1.2.1,dst=1.1.3.1,proto=1,tos=0/0,ttl=0/
> > 0),icmp(type=0/0,code=0/0), packets:3, bytes:444, used:1.360s,
> > actions:(decap_tunnel_key_release), eth0.129, eth0.128 <==== INCORRECT
> >
>
> As stated above, I do not think this is incorrect.
> TC has a decap action (which does not exist in kernel datapath) - I agree that this is confusing.
> The TC offload adds this decap (or unset) action as the first action if the match rules contain tunnel data (a dst IP iirc).
> This is essentially what the kernel datapath does, only it does not have an explicit action to say so.
>
> John
>
> > The order of the other actions in case of RX mirroring should be -
> > eth0.129, (decap_tunnel_key_release), eth0.128
> >
> > 3. I ran a test mirroring traffic on a vxlan port on the bridge.
> > I get the same result (decapped traffic) for both TC datapath and pure OvS kernel space rules.
> > Could you try using kernel datapath only in your setup?
> > Looking at the code, you are correct that the 'release' action is always first.
> > The code assumes that if we matched on tunnel fields correctly then the first action should be to decap the packet before continuing.
> > To account for the 'right order' case above it seems we would need to create a decap action in enum tc_action_type and then process the decap in order within the actions array.
> > ==== Nam) I tried this but it is not working. The only way to do it I am thinking is to get the mirroring config information in tc.c to find out which is mirror port and in decap case just switch the ports. However, all mirroring information is in ofproto.
> >
> > However, first we need to decide if this is really a bug.
> >
> > Thanks,
> > John
> >
> >
> > -----Original Message-----
> > From: John Hurley [mailto:john.hurley at netronome.com]
> > Sent: Friday, September 21, 2018 6:20 AM
> > To: Simon Horman <simon.horman at netronome.com>
> > Cc: Ben Pfaff <blp at ovn.org>; ovs-dev at openvswitch.org;
> > bugs at openvswitch.org; Saha, Gargi <gargi.saha at intel.com>; Choi, James
> > <james.choi at intel.com>; Limaye, Namrata <namrata.limaye at intel.com>
> > Subject: Re: [ovs-discuss] [ovs-dev] RX Mirroing issue with Decap in
> > vxlan case
> >
> > On Wed, Aug 22, 2018 at 1:55 PM Simon Horman <simon.horman at netronome.com> wrote:
> > >
> > > Hi Ben,
> > >
> > > given the history of the offload code where output to more than one
> > > port is a relatively new feature it does seem entirely possible to
> > > me that there is a bug in the offload code as described below.
> > >
> > > I will look into getting this investigated and if necessary fixed.
> > >
> > > On Tue, Aug 21, 2018 at 02:13:50PM -0700, Ben Pfaff wrote:
> > > > Ah.  In that case, probably I'm not the right person to handle this.
> > > >
> > > > Simon, does this make sense to you?
> > > >
> > > > On Tue, Aug 21, 2018 at 08:17:23PM +0000, Limaye, Namrata wrote:
> > > > > I haven’t tested it with openvswitch kernel and code that is issue is in tc.c so I am guessing it is only hw offload.
> > > > >
> > > > > Thanks
> > > > > Namrata
> > > > >
> > > > > > On Aug 21, 2018, at 12:37 PM, Ben Pfaff <blp at ovn.org> wrote:
> > > > > >
> > > > > > Is this problem only for hardware offload?
> > > > > >
> > > > > >> On Tue, Aug 21, 2018 at 06:26:03PM +0000, Limaye, Namrata wrote:
> > > > > >> Sorry missed the release part -
> > > > > >>
> > > > > >> Release action is added first in this function before any other action is processed which is used in decap case in our solution.
> > > > > >>
> > > > > >> 'nl_msg_put_flower_acts'
> > > > > >>
> > > > > >> if (flower->tunnel.tunnel) {
> > > > > >>            act_offset = nl_msg_start_nested(request, act_index++);
> > > > > >>            nl_msg_put_act_tunnel_key_release(request);
> > > > > >>            nl_msg_end_nested(request, act_offset);
> > > > > >>        }
> > > > > >>
> > > > > >> The ENCAP action is added fine in order within ' case TC_ACT_ENCAP:'
> > > > > >>
> > > > > >> Thanks
> > > > > >> Namrata
> > > > > >>
> > > > > >>
> > > > > >> -----Original Message-----
> > > > > >> From: Limaye, Namrata
> > > > > >> Sent: Tuesday, August 21, 2018 11:22 AM
> > > > > >> To: 'Ben Pfaff' <blp at ovn.org>
> > > > > >> Cc: bugs at openvswitch.org; ovs-dev at openvswitch.org; Saha,
> > > > > >> Gargi <gargi.saha at intel.com>; Choi, James
> > > > > >> <james.choi at intel.com>
> > > > > >> Subject: RE: [ovs-dev] RX Mirroing issue with Decap in vxlan
> > > > > >> case
> > > > > >>
> > > > > >> Hi Ben,
> > > > > >>
> > > > > >> This is the configuration -
> > > > > >>
> > > > > >> ovs-vsctl -- --id=@p get port vxlan0 -- --id=@eth0.128 get
> > > > > >> Port
> > > > > >> eth0.128 -- --id=@eth0.129 get Port eth0.129 -- --id=@m
> > > > > >> create Mirror name=mirror1 select-src-port=@eth0.128, at p
> > > > > >> output-port=@eth0.129 -- set Bridge br0 mirrors=@m
> > > > > >>
> > > > > >> Thanks
> > > > > >> Namrata
> > > > > >>
> > > > > >> -----Original Message-----
> > > > > >> From: Ben Pfaff [mailto:blp at ovn.org]
> > > > > >> Sent: Tuesday, August 21, 2018 11:15 AM
> > > > > >> To: Limaye, Namrata <namrata.limaye at intel.com>
> > > > > >> Cc: bugs at openvswitch.org; ovs-dev at openvswitch.org; Saha,
> > > > > >> Gargi <gargi.saha at intel.com>; Choi, James
> > > > > >> <james.choi at intel.com>
> > > > > >> Subject: Re: [ovs-dev] RX Mirroing issue with Decap in vxlan
> > > > > >> case
> > > > > >>
> > > > > >>> On Fri, Aug 17, 2018 at 06:55:39PM +0000, Limaye, Namrata wrote:
> > > > > >>>
> > > > > >>> Hi,
> > > > > >>>
> > > > > >>> I am facing an issue with Decap in RX Mirroring case
> > > > > >>> (select_src_port) for Vxlan. With the following config –
> > > > > >>>
> > > > > >>> ovs-vsctl -- --id=@p get port vxlan0 -- --id=@eth0.128<mailto:--id=@eth0.128> get Port eth0.128 -- --id=@eth0.129<mailto:--id=@eth0.129> get Port eth0.129 -- --id=@m create Mirror name=mirror1 select-src-port=@eth0.128, at p<mailto:select-src-port=@eth0.128, at p> output-port=@eth0.129<mailto:output-port=@eth0.129> -- set Bridge br0 mirrors=@m”.
> > > > > >>>
> > > > > >>> The order of action and ports is wrong. This is the order –
> > > > > >>>
> > > > > >>>
> > > > > >>> 1.       Release action
> > > > > >>>
> > > > > >>> 2.       Mirror port (Non vxlan)
> > > > > >>>
> > > > > >>> 3.       Output port (VXlan)
> > > > > >>>
> > > > > >>> For actions to be applied in the right order – the order
> > > > > >>> should be –
> > > > > >>>
> > > > > >>> 1.       Mirror port (non vxlan)
> > > > > >>>
> > > > > >>> 2.       Release action
> > > > > >>>
> > > > > >>> 3.       Output port (VXlan)
> >
> > Hi Namrata,
> >
> > Simon asked me to take a look at this issue.
> > Can you give more information on your setup?
> > Above you mention that you are expecting a decap (suggesting we will hit a vxlan port on the bridge) but the port mirroring is on a non vxlan netdev (eth0.128) - is this correct?
> > With this, I'm not sure how we get a TC action on a single port that includes both the mirror and the decap (1, 2, 3 above)?
> >
> > I ran a test mirroring traffic on a vxlan port on the bridge.
> > I get the same result (decapped traffic) for both TC datapath and pure OvS kernel space rules.
> > Could you try using kernel datapath only in your setup?
> >
> > Looking at the code, you are correct that the 'release' action is always first.
> > The code assumes that if we matched on tunnel fields correctly then the first action should be to decap the packet before continuing.
> > To account for the 'right order' case above it seems we would need to create a decap action in enum tc_action_type and then process the decap in order within the actions array.
> > However, first we need to decide if this is really a bug.
> >
> > Thanks,
> > John
> >
> > > > > >>
> > > > > >> What's a release action?
> > > > > >>
> > > > > >> Can you provide your configuration without corrupting it with <mailto:...>?
> > > > > >>
> > > > > >> Thanks,
> > > > > >>
> > > > > >> Ben.
> > > _______________________________________________
> > > discuss mailing list
> > > discuss at openvswitch.org
> > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


More information about the discuss mailing list