05:30:09 <anil_rao> #startmeeting taas
05:30:09 <openstack> Meeting started Wed Aug  3 05:30:09 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:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:30:12 <openstack> The meeting name has been set to 'taas'
05:30:16 <anil_rao> Hi
05:30:18 <soichi> hi
05:30:19 <yamamoto_> hi
05:30:43 <anil_rao> got kaz's note that he won't be here today.
05:31:03 <soichi> yes
05:31:45 <anil_rao> I have an update on the 'can't capture packet if two VMs on the same host' bug
05:34:11 <anil_rao> It turns out that the problem stems from the fact that VLAN 1, which is the first VLAN id used for a virtual network on a host, is the native vlan for OVS.
05:35:33 <anil_rao> for the native VLAN, OVS doesn't tag the packets as long as it is inside the bridge (br-int) and with normal processing.
05:36:01 <anil_rao> When it exits br-int to br-tun (via the int-tun patch port) it gets properly tagged
05:36:44 <anil_rao> This is the reason our TaaS flow in br-int isn't able to catch (mirror) packets as described in the bug.
05:37:08 <anil_rao> I have verified that this problem isn't there for other subnets, because they have VLAN ids > 1.
05:37:31 <anil_rao> I am working on a fix and will submit a patch for review shortly.
05:37:50 <soichi> thank you, i didn't know the behavior
05:38:30 <anil_rao> Yes, it took me by surprise too. I guess I had always been testing using a subnet I would create (which was different from the DevStack default subnet for demo.
05:38:47 <anil_rao> The first subnet gets VLAN id == 1.
05:40:01 <anil_rao> One way to fix the problem, which wouldn't need any code change in TaaS is to have the Neutron ML2 agent not use vlan == 1 at all. However, I am not sure if getting such a change in will be easy.
05:40:29 <anil_rao> So I have a minor code change to the TaaS driver which should get the job done.
05:41:46 <soichi> i see
05:42:50 <anil_rao> I will complete the fix tomorrow and then test it out to ensure that all is fine before submitting a patch.
05:44:16 <soichi> okay, we will also test after the patch is submitted
05:44:33 <anil_rao> Thanks Soichi.
05:44:57 <anil_rao> There is also this issue other issue as I had mentioned in the email
05:45:07 <anil_rao> #link https://bugs.launchpad.net/tap-as-a-service/+bug/1599351
05:45:07 <openstack> Launchpad bug 1599351 in tap-as-a-service "taas agent doesn't work with of_interface=native" [Undecided,New]
05:46:56 <anil_rao> I can take a stab at that after submitting the patch for the br-int / vlan == 1 problem.
05:47:17 <soichi> thank you
05:48:20 <soichi> yamamoto_ mentioned a workaround, but i think we need to fix it
05:49:05 <anil_rao> yamamoto_: Thanks for the workaround. Yes, we can use that until I get the proper native support done.
05:49:44 <anil_rao> There is another problem that is also very annoying.
05:50:58 <soichi> what's that?
05:50:58 <anil_rao> I find that sometimes the TaaS flows are not properly installed in br-tun. I believe it is because the ml2 driver cleans up stuff after a reset.
05:51:07 <yamamoto_> anil_rao: i guess it's a matter of specifying an openflow version.  native vs ofctl flows are not that different.
05:51:45 <yamamoto_> (about bug 1599351)
05:51:45 <openstack> bug 1599351 in tap-as-a-service "taas agent doesn't work with of_interface=native" [Undecided,New] https://launchpad.net/bugs/1599351
05:51:54 <anil_rao> yamamoto_: Yes.
05:53:49 <soichi> it seems problem in "version negotiation"
05:54:18 <anil_rao> For my debugging, I find that I need to add "-O OpenFlow13" when using ovs-ofctl in br-int and br-tun.
05:54:48 <yamamoto_> anil_rao: yes. or configure switch to accept 1.0 as well
05:56:45 <anil_rao> br-tap works correctly with the current code. Looks like the version is per-bridge.
05:59:29 <anil_rao> Any other topics?
05:59:41 <soichi> yamamoto_: thank you for adding TaaS related URL
05:59:47 <soichi> #link: https://review.openstack.org/#/c/344716/
05:59:52 <soichi> I missed the presentation at Austin.
06:00:56 <yamamoto_> soichi: i haven't noticed it either
06:02:07 <anil_rao> We did a demo with snort too. :-)
06:02:20 <soichi> yes
06:04:46 <reedip> Hi
06:04:56 <soichi> reedip: hi
06:05:02 <anil_rao> Hi Reedip
06:06:22 <soichi> it's very good news for us that TaaS users are increasing.
06:06:43 <anil_rao> +1
06:08:47 <soichi> i found a presentation "Traffic Visibility with Virtual TAP and physical Devices" was submitted for Barcelona Summit.
06:09:43 <soichi> It may be a competitor of TaaS.
06:11:19 <anil_rao> With TaaS we are essentially trying to standardize the API and have multiple backend implementations to support different use cases and platforms. So I don't see why one would try and build a separate solution unless they think our API is not good enough.
06:12:32 <anil_rao> It would be interesting nonetheless to learn more about their approach.
06:12:53 <soichi> yes, i think so
06:13:19 <soichi> he says, "these tools have some limitation (e.g, performance, deployment restriction)"
06:14:56 <soichi> i guess it is very important to show the performance charasteristics of TaaS in the Barcelona Summit
06:15:06 <anil_rao> Agree.
06:16:13 <anil_rao> Let me get these 2 bugs addressed and then I'll get busy with the performance measurements.
06:16:38 <soichi> okay, thank you
06:18:33 <anil_rao> Any other topics?
06:19:05 <soichi> nothing for me
06:19:16 <yamamoto_> nothing
06:19:32 <anil_rao> I guess we can end early then.
06:19:45 <soichi> yes
06:20:12 <anil_rao> #endmeeting