On Fri, Jan 6, 2017 at 4:28 PM, Mickey Spiegel <mickeys....@gmail.com> wrote:
> > On Fri, Jan 6, 2017 at 3:57 PM, Ben Pfaff <b...@ovn.org> wrote: > >> On Fri, Jan 06, 2017 at 12:00:31PM -0800, Mickey Spiegel wrote: >> > This patch adds the capability to force loopback at the end of the >> > egress pipeline. A new flags.force_egress_loopback symbol is defined, >> > along with corresponding flags bits. When flags.force_egress_loopback >> > is set, at OFTABLE_LOG_TO_PHY, instead of the packet being sent out to >> > the peer patch port or out the outport, the packet is forced back to >> > the beginning of the ingress pipeline with inport = outport. All >> > other registers are cleared, as if the packet just arrived on that >> > inport. >> > >> > This capability is needed in order to implement some of the east/west >> > distributed NAT flows. >> > >> > Note: The existing flags.loopback allows a packet to go from the end >> > of the ingress pipeline to the beginning of the egress pipeline with >> > outport = inport, which is different. >> > >> > Initially, there are no tests incorporated in this patch. This >> > functionality is tested in a subsequent distributed NAT flows patch. >> > Tests specific to egress loopback may be added once the capability >> > to inject a packet with one of the flags bits set is added. >> > >> > Signed-off-by: Mickey Spiegel <mickeys....@gmail.com> >> >> I don't really understand this yet. >> >> Does this need to be a flag or can it be an action, i.e. one that >> immediately jumps back to the beginning of the ingress pipeline. Then >> we don't need hard-coded flags, we can just have used-defined register >> bits, etc. >> > > Since I am figuring out whether to do egress loopback at the end of > the egress pipeline, I could get rid of the FORCE_EGRESS_LOOPBACK > flag and use an action instead. > > I think I still need the EGRESS_LOOPBACK_OCCURRED bit to avoid > the packet getting dropped in table 1 because the logical router receives > a packet with its own IP address as source. > The alternative to the EGRESS_LOOPBACK_OCCURRED bit is to avoid programming router port IP addresses that match an SNAT address in the ingress router table 1 "ip4.src == " flow. There is already similar logic for the ingress router table 1 "ip4.dst == " flow. Some background on the use of egress loopback with NAT. The intention is to use egress loopback only with NAT, for east/west traffic destined to a NAT address. The packet flow is: - router ingress pipeline on source hypervisor GW_REDIRECT pipeline stage near the end changes outport to distributed gateway port and forces the traffic to the "redirect-chassis" (either replacing outport with type "chassisredirect" port, or setting force_chassis_redirect flag, whichever mechanism we decide on). - router egress pipeline on the "redirect-chassis" applies SNAT or UNDNAT which changes ip4.src, then triggers egress loopback. - router ingress pipeline on the "redirect-chassis" receives a packet with inport = distributed gateway port, and ip4.src = a SNAT or DNAT external IP address, which could be the same as that router port's IP address. Without some change, either EGRESS_LOOPBACK_OCCURRED bit or relaxing which router port IP addresses are programmed in the drop flow, the packet would be dropped at ingress router table 1. - router ingress pipeline on the "redirect-chassis" applies DNAT or UNSNAT which changes ip4.dst, which is then used for the IP Routing lookup. - router egress pipeline on the "redirect-chassis" forwards to the outport in the normal manner to the destination logical switch. Mickey >> This needs real documentation in ovn-sb.xml instead of just being added >> to a list. >> >> Mickey > > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev