On Mon, Dec 21, 2015 at 1:59 PM, Ben Pfaff <b...@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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
