1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
diff --git a/NEWS b/NEWS
index 3006f77..89bb026 100644
--- a/NEWS
+++ b/NEWS
@@ -20,6 +20,16 @@ v2.7.0 - xx xxx xxxx
        information regarding remote connection configuration.
      * New appctl "inject-pkt" command in ovn-controller that allows
        packets to be injected into the connected OVS instance.
+     * Distributed logical routers may now be connected directly to
+       logical switches with localnet ports, by specifying a
+       "redirect-chassis" on the distributed gateway port of the
+       logical router.  NAT rules may be specified directly on the
+       distributed logical router, and are handled either centrally on
+       the "redirect-chassis", or in many cases are handled locally on
+       the hypervisor where the corresponding logical port resides.
+       Gratuitous ARP for NAT addresses on a distributed logical
+       router is not yet supported, but will be added in a future
+       version.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
commit ec29ac9c2a44cf809ddd8716d7b4f209c8970385
Author: Mickey Spiegel <mickeys.dev@gmail.com>
Date:   Thu Jan 26 17:31:08 2017 -0800

    ovn: distributed NAT flows

    This patch implements the flows required in the ingress and egress
    pipeline stages in order to support NAT on a distributed logical router.

    NAT functionality is associated with the logical router gateway port.
    The flows that carry out NAT functionality all have match conditions on
    inport or outport equal to the logical router gateway port.  There are
    additional flows that are used to redirect traffic when necessary,
    using the tunnel key of a "chassisredirect" SB port binding in order to
    redirect traffic to the instance of the logical router gateway port on
    the centralized "redirect-chassis".

    North/south traffic subject to one-to-one "dnat_and_snat" is handled
    in a distributed manner, with south-to-north traffic going to the
    local instance of the logical router gateway port.  North/south
    traffic subject to (possibly one-to-many) "snat" is handled in a
    centralized manner, with south-to-north traffic going to the instance
    of the logical router gateway port on the "redirect-chassis".
    North-to-south traffic is directed to the corresponding chassis by
    limiting ARP responses to the appropriate instance of the logical
    router gateway port on one chassis.  For centralized NAT rules, this
    is the instance on the "redirect-chassis".  For distributed NAT rules,
    this is the chassis where the corresponding logical port resides, using
    an ethernet address specified in the NB NAT rule to trigger upstream
    MAC learning.

    East/west NAT traffic is all handled in a centralized manner.  While it
    is certainly possible to handle some of this traffic in a distributed
    manner, the centralized approach keeps the NAT flows simpler and
    cleaner.  The expectation is that east/west NAT traffic is not as
    important to optimize as north/south NAT traffic, with most east/west
    traffic not requiring NAT.

    Automated tests are currently limited to only a single node.  The
    single node automated tests cover both north/south and east/west
    traffic flows.

    Signed-off-by: Mickey Spiegel <mickeys.dev@gmail.com>
    Signed-off-by: Gurucharan Shetty <guru@ovn.org>

1
2
3
4
5
6
    This is very useful for a specific use case of Kubernetes.
    When traffic is initiated inside a container heading to outside world,
    we want to be able to send such traffic outside the gateway router
    residing in the same host as that of the container. Since each
    host gets a specific subnet, we can use source IP address based
    policy routing to decide on the gateway router.

1
2
3
4
5
6
7
8
9
10
11
12
13
    - DPDK:
      * New option 'n_rxq_desc' and 'n_txq_desc' fields for DPDK interfaces
        which set the number of rx and tx descriptors to use for the given port.
      * Support for DPDK v16.11.
      * Support for rx checksum offload. Refer DPDK HOWTO for details.
      * Port Hotplug is now supported.
      * DPDK physical ports can now have arbitrary names. The PCI address of
        the device must be set using the 'dpdk-devargs' option. Compatibility
        with the old dpdk<portid> naming scheme is broken, and as such a
        device will not be available for use until a valid dpdk-devargs is
        specified.
      * Virtual DPDK Poll Mode Driver (vdev PMD) support.
      * Removed experimental tag.