[ovs-dev] [PATCH v7 4/7] ovn: add egress loopback capability

Mickey Spiegel mickeys.dev at gmail.com
Mon Jan 9 21:11:37 UTC 2017


On Fri, Jan 6, 2017 at 4:28 PM, Mickey Spiegel <mickeys.dev at gmail.com>
wrote:

>
> On Fri, Jan 6, 2017 at 3:57 PM, Ben Pfaff <blp at 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.dev at 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
>
>


More information about the dev mailing list