05:30:35 <anil_rao> #startmeeting taas
05:30:36 <openstack> Meeting started Wed Aug 10 05:30:35 2016 UTC and is due to finish in 60 minutes.  The chair is anil_rao. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:30:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:30:40 <openstack> The meeting name has been set to 'taas'
05:30:45 <anil_rao> Hi
05:30:47 <soichi> hi
05:31:45 <anil_rao> #topic  Bug: not capturing ingress traffic from VM on same host
05:33:04 <anil_rao> Here is an update on this bug...
05:33:52 <soichi> thank you for your discussion on mail
05:34:07 <anil_rao> What I have noticed is that if there are a few VLANs in use (each for a different virtual network), the bug manifests itself for the VLAN id with the lowest number.
05:34:33 <soichi> it seems a bit difficult to solve, but it looks interesting behavior
05:34:46 <anil_rao> For example. If the VLANs in use are 3, 4 and 5, we are unable to capture ingress traffic for VMs associated with VLAN 3.
05:35:08 <anil_rao> soichi: Yes.
05:35:11 <reedip> hi
05:35:22 <anil_rao> Hi Reedip
05:36:18 <anil_rao> The OVS documentation seems to suggest that VLANs used by tagged ports as part of the normal action are not compatible with explicit Open Flow flows.
05:37:27 <soichi> #link: https://github.com/openvswitch/ovs/blob/5cf3edb311ffe6bc4df93cd7b759801c6932d81f/FAQ.md#q-my-openflow-controller-doesnt-see-the-vlans-that-i-expect
05:37:30 <anil_rao> today, I posted an email on the openstack-dev list (neutron) to confirm the fact that Neutron port MAC addresses are unique to a network and not globally unique. Armando confirmed this.
05:38:20 <soichi> #link: http://lists.openstack.org/pipermail/openstack-dev/2016-August/101260.html
05:38:22 <anil_rao> So, simply removing the VLAN tag check in the ingress capture flow won't work in the long run.
05:38:46 <anil_rao> I am still investigating this but at the moment don't have a solution that is general enough to work in all situations.
05:39:08 <yamamot__> hi
05:39:18 <anil_rao> soichi: Thanks for posting the links.
05:39:29 <anil_rao> Hi
05:40:36 <yamamot__> ovs should move away from port-based vlan for long run
05:40:48 <yamamot__> s/ovs/&-agent/
05:40:57 <reedip> hmm, interesting ..
05:41:35 <anil_rao> yamamot__: didn't follow, can you elaborate
05:42:35 <yamamot__> in-port based classification is more flexible than port tag + NORMAL action
05:43:24 <yamamot__> ofagent works that way (no NORMAL action or tags)
05:44:08 <yamamot__> anyway just IMO for longer term.  not a solution for the bug you're working on.
05:44:41 <anil_rao> yamamot__: Agree for the long term.
05:45:07 <anil_rao> At the moment, br-int's default behavior is performed via the normal action.
05:45:52 <yamamot__> i still don't understand why only 1st vlan works that way for you.  i expected every vlans worked that way.
05:46:33 <anil_rao> yamamot__: Yes, I am still puzzled about that. If the VLANs in use are say 3, 4 and 5, I only see the problem for VLAN 3.
05:46:59 <anil_rao> It seems to me that OVS avoids VLAN tags only for the first VLAN in use.
05:47:50 <yamamot__> i expect ovs extract vlan for matching from the packet itself.  in your scenario everything is no-vlan.
05:48:52 <anil_rao> Let's say that we have 3 virtual networks in use and their respective ports are tagged to VLANs 3, 4 and 5.
05:49:22 <anil_rao> I only see the problem for VLAN 3 in this case.
05:50:55 <yamamot__> anyway your should use in-port match instead i guess.
05:51:31 <anil_rao> How would be do an in-port patch for traffic headed toward a VM instances NIC?
05:52:05 <anil_rao> I.e. ingress traffic from the VM's perpective.
05:52:34 <yamamot__> ah, i was confused.  you can't. :-)
05:53:02 <anil_rao> We already use in-port match for traffic egressing the VM. And that works correctly. :-)
05:53:47 <yamamot__> we are talking about this flow? https://github.com/openstack/tap-as-a-service/blob/c612a729e758119c59c56ad7ed1347323033cd4f/neutron_taas/services/taas/drivers/linux/ovs_taas.py#L313
05:54:20 <anil_rao> That is correct.
05:55:03 <anil_rao> Since Neutron port MAC addresses are unique ony within a virtual network (Armando confirmed this today) we had to place a check for dst MAC address + VLAN id.
05:55:03 <yamamot__> can you provide flow dump with your setup (vlan 3,4,5) ?
05:55:38 <anil_rao> yamamot__: I can do that tomorrow. I am at home now and don't have access to my test machine in the offic. Sorry.
05:56:36 <yamamot__> btw i thought it was a todo for you to put your flow diagram somewhere.  is it available now?
05:56:53 <anil_rao> What I need to understand is why OVS doesn't add VLAN tags only for the VLAN with the smallest number. Perhaps, this is an internal optimization for them.
05:57:12 <anil_rao> yamamot__: I'll get that up soon. Again, that is in the office too.
05:58:12 <soichi> anil_rao: +1 for we need to understand is why OVS doesn't add VLAN tags only for the VLAN with the smallest number
05:58:21 <vinay_yadhav> anil_rao: is this VLAN issue reported by to OVS or discussed in OVS forums
05:58:54 <anil_rao> vinay_yadhav: I suppose I will be spending some time on OVS forums now. :-)
05:59:04 <vinay_yadhav> me too
06:00:33 <vinay_yadhav> anil_rao:  Also i guess this is happening across all OVS versions, old and latest
06:01:00 <anil_rao> vinay_yadhav: Yes.
06:01:46 <anil_rao> The intersting thing is that when traffic leaks out of br-int into say br-tun (via the patch port) because the destination isn't on br-int, the VLAN tag gets properly added.
06:02:21 <anil_rao> Its just that you can't catch it via an openflow flow inside br-int.
06:03:06 <yamamot__> it's because tag is added during normal action processing
06:04:09 <anil_rao> yamamot__: That is correct. However, the tags are visiblity for higher numbered VLANs so that seems kind of odd to me.
06:04:32 <anil_rao> Let me post regarding this behavior on the OVS forums and see what kind of response we get.
06:04:48 <yamamot__> i don't understand why they behave inconsistent either
06:04:51 <soichi> +1
06:07:56 <anil_rao> From the OVS FAQ, they seem to suggest that if one is using OpenFlow flows and VLANs, then explicit VLAN handling is necessary.
06:08:25 <yamamot__> right
06:08:56 <anil_rao> However, that seems too heavy handed for our application, especially since TaaS may not be deployed all the time.
06:11:03 <anil_rao> I get the feeling that if anyone else within the OpenStack community has a need for adding dst MAC address checks in br-int they will also run into the same problem.
06:11:41 <anil_rao> Unfortunately, outside of TaaS there is no one else at this time.
06:12:17 <yamamot__> it's a common problem
06:12:35 <yamamot__> #link https://review.openstack.org/#/c/320439
06:12:41 <yamamot__> see INITIAL_TAGGING
06:16:43 <reedip> Have we checked the recent devstack deployment of TaaS? 2 or more ( incl me ) have faced issues in the current  restack of devstack
06:17:13 <anil_rao> yamamot__: Thanks for the link to that spec. I'll go though it in detail.
06:18:16 <yamamot__> reedip: restack?
06:18:39 <reedip> unstacking + stacking devstack
06:18:40 <reedip> :)
06:19:57 <yamamot__> reedip: i haven't tried it with ovs recently
06:20:37 <reedip> yamamot__ ok, I will share the logs after restacking .
06:22:20 <anil_rao> #topic Open Discussion
06:22:45 <soichi> anil_rao, vinay_yadhav: i'd like to ask code review
06:23:07 <anil_rao> soichi: Sure.
06:23:12 <vinay_yadhav> sure
06:24:56 <soichi> i mean a patch subitted by yamamoto to solve a bug in the test
06:26:46 <yamamot__> soichi: i think i just approved it by myself. :-)  thank you for taking care of it anyway.
06:26:53 <yamamot__> #link https://review.openstack.org/#/c/349302/
06:27:08 <soichi> yes, that one
06:27:22 <vinay_yadhav> :) thanks
06:27:50 <soichi> it is not in a hurry, but i guess we need to adjust to rename in the Neutron DB (tenant_id -> project_id)
06:27:57 <soichi> #link: http://lists.openstack.org/pipermail/openstack-dev/2016-August/100822.html
06:29:44 <anil_rao> We are out of time. Let's continue the discussion next week.
06:29:51 <soichi> sure
06:30:03 <yamamot__> soichi: i think Abhishek is interested in it
06:30:28 <soichi> okay, thank you for your information
06:31:11 <anil_rao> #endmeeting