On Tue, Sep 25, 2018 at 10:22 PM Limaye, Namrata
<namrata.lim...@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,@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@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,id=0/0),eth(src=00:e8:ca:11:bc:02,dst=00:e8:ca:11:bb:02),eth_type(0x0800),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,flags(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),packet_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),packet_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.hur...@netronome.com]
> Sent: Friday, September 21, 2018 6:20 AM
> To: Simon Horman <simon.hor...@netronome.com>
> Cc: Ben Pfaff <b...@ovn.org>; ovs-dev@openvswitch.org; b...@openvswitch.org;
> Saha, Gargi <gargi.s...@intel.com>; Choi, James <james.c...@intel.com>;
> Limaye, Namrata <namrata.lim...@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.hor...@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 <b...@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' <b...@ovn.org>
> > > > >> Cc: b...@openvswitch.org; ovs-dev@openvswitch.org; Saha, Gargi
> > > > >> <gargi.s...@intel.com>; Choi, James <james.c...@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,@p
> > > > >> output-port=@eth0.129 -- set Bridge br0 mirrors=@m
> > > > >>
> > > > >> Thanks
> > > > >> Namrata
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: Ben Pfaff [mailto:b...@ovn.org]
> > > > >> Sent: Tuesday, August 21, 2018 11:15 AM
> > > > >> To: Limaye, Namrata <namrata.lim...@intel.com>
> > > > >> Cc: b...@openvswitch.org; ovs-dev@openvswitch.org; Saha, Gargi
> > > > >> <gargi.s...@intel.com>; Choi, James <james.c...@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,@p<mailto:select-src-port=@eth0.128,@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
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
