Acked-by: Mickey Spiegel <mickeys....@gmail.com>
On Fri, Nov 4, 2016 at 10:06 AM, Darrell Ball <dlu...@gmail.com> wrote: > There has been enough confusion regarding logical switch datapath > arp responders in ovn to warrant some additional comments; > hence add a general description regarding why they exist and > document the special cases. > > Signed-off-by: Darrell Ball <dlu...@gmail.com> > Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> > Co-authored-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> > Acked-by: Han Zhou <zhou...@gmail.com> > --- > > v5->v6: Rewording based on review feedback including designating > peer logical router port correctly. > > v4->v5: Splice in some rewording from review from multiple sources. > > v3->v4: Capitalization fixes. > Reinstate comment regarding L2 learning confusion. > > v2->v3: Reword and further elaborate. > > v1->v2: Dropped RFC code change for logical switch router > type ports. > > ovn/northd/ovn-northd.8.xml | 67 ++++++++++++++++++++++++++++++ > +++++++++++---- > 1 file changed, 61 insertions(+), 6 deletions(-) > > diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml > index df53d4c..9c61f66 100644 > --- a/ovn/northd/ovn-northd.8.xml > +++ b/ovn/northd/ovn-northd.8.xml > @@ -435,20 +435,75 @@ > <h3>Ingress Table 10: ARP/ND responder</h3> > > <p> > - This table implements ARP/ND responder for known IPs. It contains > these > - logical flows: > + This table implements ARP/ND responder in a logical switch for known > + IPs. The advantage of the ARP responder flow is to limit ARP > + broadcasts by locally responding to ARP requests without the need to > + send to other hypervisors. One common case is when the inport is a > + logical port associated with a VIF and the broadcast is responded to > + on the local hypervisor rather than broadcast across the whole > + network and responded to by the destination VM. This behavior is > + proxy ARP. > </p> > > + <p> > + ARP requests arrive from VMs from a logical switch inport of type > + default. For this case, the logical switch proxy ARP rules can be > + for other VMs or logical router ports. Logical switch proxy ARP > + rules may be programmed both for mac binding of IP addresses on > + other logical switch VIF ports (which are of the default logical > + switch port type, representing connectivity to VMs or containers), > + and for mac binding of IP addresses on logical switch router type > + ports, representing their logical router port peers. In order to > + support proxy ARP for logical router ports, an IP address must be > + configured on the logical switch router type port, with the same > + value as the peer logical router port. The configured MAC addresses > + must match as well. When a VM sends an ARP request for a > distributed > + logical router port and if the peer router type port of the attached > + logical switch does not have an IP address configured, the ARP > request > + will be broadcast on the logical switch. One of the copies of the > ARP > + request will go through the logical switch router type port to the > + logical router datapath, where the logical router ARP responder will > + generate a reply. The MAC binding of a distributed logical router, > + once learned by an associated VM, is used for all that VM's > + communication needing routing. Hence, the action of a VM re-arping > for > + the mac binding of the logical router port should be rare. > + </p> > + > + <p> > + Logical switch ARP responder proxy ARP rules can also be hit when > + receiving ARP requests externally on a L2 gateway port. In this > case, > + the hypervisor acting as an L2 gateway, responds to the ARP request > on > + behalf of a destination VM. > + </p> > + > + <p> > + Note that ARP requests received from <code>localnet</code> or > + <code>vtep</code> logical inports can either go directly to VMs, in > + which case the VM responds or can hit an ARP responder for a logical > + router port if the packet is used to resolve a logical router port > + next hop address. In either case, logical switch ARP responder > rules > + will not be hit. It contains these logical flows: > + </p> > + > <ul> > <li> > - Priority-100 flows to skip ARP responder if inport is of type > - <code>localnet</code>, and advances directly to the next table. > + Priority-100 flows to skip the ARP responder if inport is of type > + <code>localnet</code> or <code>vtep</code> and advances directly > + to the next table. ARP requests sent to <code>localnet</code> or > + <code>vtep</code> ports can be received by multiple hypervisors. > + Now, because the same mac binding rules are downloaded to all > + hypervisors, each of the multiple hypervisors will respond. This > + will confuse L2 learning on the source of the ARP requests. ARP > + requests received on an inport of type <code>router</code> are not > + expected to hit any logical switch ARP responder flows. However, > + no skip flows are installed for these packets, as there would be > + some additional flow cost for this and the value appears limited. > </li> > > <li> > <p> > Priority-50 flows that match ARP requests to each known IP > address > - <var>A</var> of every logical router port, and respond with ARP > + <var>A</var> of every logical switch port, and respond with ARP > replies directly with corresponding Ethernet address > <var>E</var>: > </p> > > @@ -475,7 +530,7 @@ output; > <p> > Priority-50 flows that match IPv6 ND neighbor solicitations to > each known IP address <var>A</var> (and <var>A</var>'s > - solicited node address) of every logical router port, and > + solicited node address) of every logical switch port, and > respond with neighbor advertisements directly with > corresponding Ethernet address <var>E</var>: > </p> > -- > 1.9.1 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
