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. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
