On Sun, Oct 2, 2016 at 11:27 AM, Han Zhou <zhou...@gmail.com> wrote:
> On Sat, Oct 1, 2016 at 4:34 PM, Darrell Ball <dlu...@gmail.com> wrote:
> >
> > Do not install any potential logical switch "router type"
> > port arp responders. Logical router port arp responders
> > should be sufficient in this respect.
> > It seems a little wierd for a logical switch not proxying
> > for a remote VIF to be responding to arp requests and we
> > are not functionally using this capability in ovn.
> >
> Hi Darrell,
>
> The arp responder for patch port is useful e.g. when a VM pings the
> default gateway IP. Would removing the flow cause the arp request get
> flooded? And what's the benefit of removing it here?
>
1) Modelling: I would expect the L3 gateway arp responder to be associated
with the L3
gateway router datapath, at the very least. That way, the modeling is
correct and we don't have a situation where, for example, a phantom gateway
router is never even downloaded to a HV,
but is "responding" or rather appearing to respond to arp requests.
2) We install an arp responder for the logical routers, including L3
gateway(s) today (see below).
We check for inport in this rule and this inport is only associated with
the L3 gateway HV.
So only the L3 gateway HV should respond. Meaning, if there is a response,
the L3 gateway
datapath is really there.
/* ARP reply. These flows reply to ARP requests for the router's
own
* IP address. */
for (int i = 0; i < op->lrp_networks.n_ipv4_addrs; i++) {
ds_clear(&match);
ds_put_format(&match,
"inport == %s && arp.tpa == %s && arp.op == 1",
op->json_key, op->lrp_networks.ipv4_addrs[i]
.addr_s);
ds_clear(&actions);
ds_put_format(&actions,
"eth.dst = eth.src; "
"eth.src = %s; "
"arp.op = 2; /* ARP reply */ "
"arp.tha = arp.sha; "
"arp.sha = %s; "
"arp.tpa = arp.spa; "
"arp.spa = %s; "
"outport = %s; "
"flags.loopback = 1; "
"output;",
op->lrp_networks.ea_s,
op->lrp_networks.ea_s,
op->lrp_networks.ipv4_addrs[i].addr_s,
op->json_key);
ovn_lflow_add(lflows, op->od, S_ROUTER_IN_IP_INPUT, 90,
ds_cstr(&match), ds_cstr(&actions));
}
3) Usually, there are a limited number of L3 gateways and therefore
associated bindings.
Also, for VMs participating in south<->north traffic, the bindings are less
likely
to timeout since there are multiple uses of the L3 gateway for each VM.
For VM to VM communication, the communication scaling order is higher and
arps are more likely to age out when they are really needed later.
In summary, I am not fully convinced breaking the modeling has much benefit.
This is what I want to discuss. If you have different datapoints, pls relay
them.
>
>
> Han
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
