[ovs-dev] [PATCH] Do not add ARP replies in the lswitch pipeline to all the lports

Han Zhou zhouhan at gmail.com
Mon Dec 21 22:38:16 UTC 2015


On Mon, Dec 21, 2015 at 1:59 PM, Ben Pfaff <blp at ovn.org> wrote:

> On Mon, Dec 21, 2015 at 03:03:42PM -0500, Russell Bryant wrote:
> > On 12/21/2015 02:52 PM, Ben Pfaff wrote:
> > > On Mon, Dec 21, 2015 at 10:39:29AM -0500, Russell Bryant wrote:
> > >> On 12/21/2015 09:55 AM, Numan Siddique wrote:
> > >>> On 12/21/2015 08:13 PM, Russell Bryant wrote:
> > >>>> On 12/21/2015 09:27 AM, Numan Siddique wrote:
> > >>>> What problem are you addressing here?  It seems we would want the
> flows
> > >>>> created, even when the port is not up yet.  Otherwise, when the port
> > >>>> does come up, ovn-controller has an incomplete logical flow table.
> I
> > >>>> think the logical flow table should be independent of port state and
> > >>>> location.
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>> Presently when I create a port (neutron port-create) , i can get
> response to arping for the port ip,
> > >>> even if it is not bound to any VM.
> > >>> I thought of addressing this trivial problem. As soon as the port
> does come up, northd would
> > >>> add the necessary ARP reply logical flow. But I get your point now.
> > >>
> > >> Got it.  Thanks for clarifying the issue.
> > >>
> > >> I wonder what the desired behavior should be here ... I'm tempted to
> > >> just say the existing behavior is OK.  I wonder what others think.
> > >
> > > It is surprising behavior to get an ARP response from a port that is
> not
> > > up.  I think that it will confuse users and administrators trying to
> > > troubleshoot.
> > >
> > > I don't know the best way to handle this, but this seems like a
> > > reasonable place to start.
> > >
> >
> > OK, thanks for the feedback Ben.  If you're good with this patch, it's
> > fine with me.  I don't have any better ideas for how to handle it if we
> > don't want the ARP response when ports aren't up.
> >
> > The main downside is the increase in churn of the logical flow table.
> > For every new port, we now update the logical flow table twice instead
> > of just once.
> >
> > Just brainstorming here ...
> >
> > We could have logical flow pre-requisites, where we could say to only
> > process this logical flow if a given logical port is bound to a chassis
> > (is up).  That way the logical flows don't change and ovn-controller
> > handles the change based on port state.
> >
> > That's a good bit more complicated than this patch, so maybe we should
> > just merge this and keep it as something that could be revisited later
> > if optimizing here seems worthwhile.
>
> That's roughly my thought process too.  First get stuff correct, then
> worry about making it faster where it is necessary.
>
>
I don't think it is strictly incorrect behavior to respond ARP before the
port is up, because ARP is just to do the address resolving.
Yes, it would confuse admin when doing trouble-shooting in the beginning,
but I am not sure if people can get used to it and accept it as how virtual
network works.

Nevertheless, if for any reason we decide to avoid this, I would suggest to
drop the ARP request in this case, instead of letting it flood on all
existing ports, because it is not suppose to get any response before the
port is up.


-- 
Best regards,
Han



More information about the dev mailing list