| Message ID | 1478279178-36041-3-git-send-email-dlu998@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com> On Fri, Nov 4, 2016 at 10:06 AM, Darrell Ball <dlu998@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 <dlu998@gmail.com> > Signed-off-by: Ramu Ramamurthy <ramu.ramamurthy@us.ibm.com> > Co-authored-by: Ramu Ramamurthy <ramu.ramamurthy@us.ibm.com> > Acked-by: Han Zhou <zhouhan@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 >
On Fri, Nov 04, 2016 at 10:06:17AM -0700, Darrell Ball 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 <dlu998@gmail.com> > Signed-off-by: Ramu Ramamurthy <ramu.ramamurthy@us.ibm.com> > Co-authored-by: Ramu Ramamurthy <ramu.ramamurthy@us.ibm.com> > Acked-by: Han Zhou <zhouhan@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 +++++++++++++++++++++++++++++++++++++++++---- Thanks, applied to master.
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>