Hi John,
Here's the answer to your questions -
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 -- [email protected] get Port eth0.128 --
[email protected] get Port eth0.129 -- --id=@m create
Mirror name=mirror1 [email protected],@p [email protected] -- 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
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 -
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
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:[email protected]]
Sent: Friday, September 21, 2018 6:20 AM
To: Simon Horman <[email protected]>
Cc: Ben Pfaff <[email protected]>; [email protected]; [email protected];
Saha, Gargi <[email protected]>; Choi, James <[email protected]>; Limaye,
Namrata <[email protected]>
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 <[email protected]> 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 <[email protected]> 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' <[email protected]>
> > > >> Cc: [email protected]; [email protected]; Saha, Gargi
> > > >> <[email protected]>; Choi, James <[email protected]>
> > > >> 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 -- [email protected] get Port
> > > >> eth0.128 -- [email protected] get Port eth0.129 -- --id=@m create
> > > >> Mirror name=mirror1 [email protected],@p
> > > >> [email protected] -- set Bridge br0 mirrors=@m
> > > >>
> > > >> Thanks
> > > >> Namrata
> > > >>
> > > >> -----Original Message-----
> > > >> From: Ben Pfaff [mailto:[email protected]]
> > > >> Sent: Tuesday, August 21, 2018 11:15 AM
> > > >> To: Limaye, Namrata <[email protected]>
> > > >> Cc: [email protected]; [email protected]; Saha, Gargi
> > > >> <[email protected]>; Choi, James <[email protected]>
> > > >> 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 --
> > > >>> [email protected]<mailto:[email protected]> get Port eth0.128 --
> > > >>> [email protected]<mailto:[email protected]> get Port eth0.129 -- --id=@m
> > > >>> create Mirror name=mirror1
> > > >>> [email protected],@p<mailto:[email protected],@p>
> > > >>> [email protected]<mailto:[email protected]> -- 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
> [email protected]
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
