[openstack-dev] [neutron][taas] neutron ovs-agent deletes taas flows

Kyle Mestery mestery at mestery.com
Tue Dec 15 15:34:17 UTC 2015


On Tue, Dec 15, 2015 at 9:11 AM, Assaf Muller <amuller at redhat.com> wrote:

> SFC are going to hit this issue as well. Really any out of tree
> Neutron project that extends the OVS agent and expects things to work
> :)
>
>
Yes, this is the case.


> On Tue, Dec 15, 2015 at 9:30 AM, Ihar Hrachyshka <ihrachys at redhat.com>
> wrote:
> > Soichi Shigeta <shigeta.soichi at jp.fujitsu.com> wrote:
> >
> >>
> >>  Hi,
> >>
> >>   We find a problem that neutron ovs-agent deletes taas flows.
> >>
> >>   o) Problem description:
> >>
> >>      Background:
> >>       At Liberty, a bug fix to drop only old flows was merged
> >>       to Neutron.
> >>       When ovs-agent is restarted, the cleanup logic drops flow
> >>       entries unless they are stamped by agent_uuid (recorded as
> >>       a cookie).
> >>
> >>       bug: #1383674
> >>            "Restarting neutron openvswitch agent causes network
> >>             hiccup by throwing away all flows"
> >>            https://bugs.launchpad.net/neutron/+bug/1383674
> >>
> >>       commit: 73673beacd75a2d9f51f15b284f1b458d32e992e (patch)
> >>
> >>
> https://git.openstack.org/cgit/openstack/neutron/commit/?id=73673beacd75a2d9f51f15b284f1b458d32e992e
> >>
> >>
> >>      Problem:
> >>       Cleanup will be done only once, but it seems not to work
> >>       until port configuration is changed.
> >>
> >>       Therefore, taas flows will be deleted as follows:
> >>        1. Start a new compute node or restart an existing compute node.
> >>        2. Start taas agent on the compute node.
> >>           --> taas agent creates flows
> >>               (these flows are not stamped by using ovs-agent's uuid)
> >>        3. Deploy a vm on the compute node.
> >>           --> 1. neutron changes port configuration
> >>               2. subsequently, the cleanup logic is invoked
> >>               3. ovs-agent drops taas flows
> >>
> >>      Specifically, following taas flows in br_tun are dropped:
> >>      -----
> >>       table=35, priority=2,reg0=0x0 actions=resubmit(,36)
> >>       table=35, priority=1,reg0=0x1 actions=resubmit(,36)
> >>       table=35, priority=1,reg0=0x2 actions=resubmit(,37)
> >>      -----
> >>
> >>      log in q-agt.log
> >>      -----
> >>
> neutron.plugins.ml2.drivers.openvswitch.agent.openflow.ovs_ofctl.ofswitch
> >>         req-e5739280-7116-4802-b5ba-d6964b4c5557 Deleting flow
> >>         cookie=0x0, duration=434.59s, table=35, n_packets=0, n_bytes=0,
> >>         idle_age=434, priority=2,reg0=0x0 actions=resubmit(,36)
> >>
> neutron.plugins.ml2.drivers.openvswitch.agent.openflow.ovs_ofctl.ofswitch
> >>         req-e5739280-7116-4802-b5ba-d6964b4c5557 Deleting flow
> >>         cookie=0x0, duration=434.587s, table=35, n_packets=0, n_bytes=0,
> >>         idle_age=434, priority=1,reg0=0x1 actions=resubmit(,36)
> >>
> neutron.plugins.ml2.drivers.openvswitch.agent.openflow.ovs_ofctl.ofswitch
> >>         req-e5739280-7116-4802-b5ba-d6964b4c5557 Deleting flow
> >>         cookie=0x0, duration=434.583s, table=35, n_packets=0, n_bytes=0,
> >>         idle_age=434, priority=1,reg0=0x2 actions=resubmit(,37)
> >>      -----
> >>
> >>
> >>   o) Impact for TaaS:
> >>
> >>      Because flows in br_tun are dropped by the cleanup logic, mirrored
> >>      packets will not send to a monitoring vm running on another host.
> >>
> >>      Note: Mirrored packets are sent in case of both source vm and
> >>            monitoring vm are running on the same host. (not affected by
> >>            flows in br_tun)
> >>
> >>
> >>   o) How to reproduce:
> >>
> >>      1. Start a new compute node or restart an existing compute node.
> >>         (Actually, restarting ovs-agent is enough.)
> >>      2. Start (or restart) taas agent on the compute node.
> >>      3. Deploy a vm on the compute node.
> >>         --> The cleanup logic drops taas flows.
> >>
> >>
> >>   o) Workaround:
> >>
> >>      After a vm is deployed on a (re)started compute node, restart taas
> >>      agent before creating a tap-service or tap-flow.
> >>      That is, create taas flows after cleanup has been done.
> >>
> >>      Note that cleanup will be done only once during an ovs-agent is
> >>      running.
> >>
> >>
> >>   o) An idea to fix:
> >>
> >>      1. Set "taas" stamp(*) to taas flows.
> >>      2. Modify the cleanup logic in ovs-agent not to delete entries
> >>         stamped as "taas".
> >>
> >>      * Maybe a static string.
> >>        If we need to use a string which generated dynamically
> >>        (e.g. uuid), API to interact with ovs-agent is required.
> >
> >
> > API proposal with some consideration for flow cleanup not dropping flows
> for
> > external code is covered in the following email thread:
> >
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html
> >
> > I believe you would need to adopt the extensions API once it’s in, moving
> > from setup with a separate agent for your feature to l2 agent extension
> for
> > taas that will run inside OVS agent.
> >
>

This is really the right approach here as well. Anything modifying flow
tables and expecting to work with the OVS L2 agent should in fact reside in
the OVS L2 agent or use this extension API. Ihar, is this currently planned
for Mitaka?


> > Ihar
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151215/5e10d7af/attachment.html>


More information about the OpenStack-dev mailing list