[ovs-dev] [patch_v2] ovn: Fix receive from vxlan in ovn-controller.

Ryan Moats rmoats at us.ibm.com
Tue Jun 14 15:28:49 UTC 2016


"dev" <dev-bounces at openvswitch.org> wrote on 06/08/2016 04:30:34 PM:

> From: Darrell Ball <dlu998 at gmail.com>
> To: dlu998 at gmail.com, dev at openvswitch.com
> Date: 06/08/2016 04:31 PM
> Subject: [ovs-dev] [patch_v2] ovn: Fix receive from vxlan in
ovn-controller.
> Sent by: "dev" <dev-bounces at openvswitch.org>
>
> OVN only supports source_node replication and previously vtep
interaction,
> which used service node replication by default for
multicast/broadcast/unknown
> unicast traffic worked by happenstance.  Because of limited vxlan
> encapsulation metadata, received packets were resubmitted to find the
egress
> port(s). This is not correct for multicast, broadcast and unknown
> unicast traffic
> as traffic will get resent on the tunnel mesh. ovn-controller is
> changed not to
> send traffic received from vxlan tunnels out the tunnel mesh again.
Traffic
> received from vxlan tunnels is now only sent locally as intended.
>
> To support keeping state for receipt from a vxlan tunnel a MFF logical
> register is allocated for general scratchpad purposes and one bit is used
for
> receipt from vxlan.  The new register usage is documented in a new
> OVN-DESIGN.md document and a table is added to track MFF logical metadata
> and register usage.
>
> Some micro-details (e.g.) register assignments) that may change over time
> were moved from the ovn-architecture.7.xml document to the OVN-DESIGN.md
> document.  The OVN-DESIGN.md file was tested using the following markdown
> parsers:
>
> https://jbt.github.io/markdown-editor/
> http://dillinger.io/
>
> As part of this change ovn-controller-vtep is hard-coded to set the
> replication
> mode of each logical switch to source node as OVN will only support
source
> node replication.
>
> Signed-off-by: Darrell Ball <dlu998 at gmail.com>
> ---
>
>  v1->v2:  Rebased after recent conflicting commit.  Converted some xml
>  comments ported from the ovn-architecture document. Removed redundant
>  register initialization and unnecessary bit declaration.
>
>  ovn/OVN-DESIGN.md          | 180 +++++++++++++++++++++++++++++++++++++++
++++
>  ovn/automake.mk            |   1 +
>  ovn/controller-vtep/vtep.c |   4 +
>  ovn/controller/physical.c  |  25 ++++--
>  ovn/lib/logical-fields.h   |  13 +++-
>  ovn/ovn-architecture.7.xml | 188
> ---------------------------------------------
>  tests/ovn.at               |   3 +
>  7 files changed, 219 insertions(+), 195 deletions(-)
>  create mode 100644 ovn/OVN-DESIGN.md
>
> diff --git a/ovn/OVN-DESIGN.md b/ovn/OVN-DESIGN.md
> new file mode 100644
> index 0000000..6676de5
> --- /dev/null
> +++ b/ovn/OVN-DESIGN.md
> @@ -0,0 +1,180 @@
> +OVN register and metadata usage:
> +-------------------------------
> +
> +logical datapath field:
> +
> +A field that denotes the logical datapath through which a packet is
being
> +processed.
> +_Keep the following in sync with MFF_LOG_DATAPATH in_
> +_ovn/lib/logical-fields.h._
> +OVN uses the field that OpenFlow 1.1+ simply (and confusingly) calls
> +'metadata' to store the logical datapath.  (This field is passed across
> +tunnels as part of the tunnel key.)
> +
> +
> +logical input port field:
> +
> +A field that denotes the logical port from which the packet entered the
> +logical datapath.
> +_Keep the following in sync with MFF_LOG_INPORT in_
> +_ovn/lib/logical-fields.h._
> +OVN stores this in Nicira extension register number 6.
> +
> +Geneve and STT tunnels pass this field as part of the tunnel key.
> +Although VXLAN tunnels do not explicitly carry a logical input port,
> +OVN only uses VXLAN to communicate with gateways that from OVN's
> +perspective consist of only a single logical port, so that OVN can set
> +the logical input port field to this one on ingress to the OVN logical
> +pipeline.
> +
> +
> +logical output port field:
> +
> +A field that denotes the logical port from which the packet will leave
> +the logical datapath.  This is initialized to 0 at the beginning of the
> +logical ingress pipeline.
> +_Keep the following in sync with MFF_LOG_OUTPORT in_
> +_ovn/lib/logical-fields.h._
> +OVN stores this in Nicira extension register number 7.
> +
> +Geneve and STT tunnels pass this field as part of the tunnel key.  VXLAN
> +tunnels do not transmit the logical output port field.
> +
> +
> +conntrack zone field for logical ports:
> +
> +A field that denotes the connection tracking zone for logical ports.
> +The value only has local significance and is not meaningful between
> +chassis.  This is initialized to 0 at the beginning of the logical
> +ingress pipeline.  OVN stores this in Nicira extension register number
5.
> +
> +
> +conntrack zone fields for Gateway router:
> +
> +Fields that denote the connection tracking zones for Gateway routers.
> +These values only have local significance (only on chassis that have
> +Gateway routers instantiated) and is not meaningful between
> +chassis.  OVN stores the zone information for DNATting in Nicira
> +extension register number 3 and zone information for SNATing in Nicira
> +extension register number 4.
> +
> +
> +flags field:
> +
> +Scratchpad flags that denote the pipeline state between tables.  The
> +values only have local significance and are not meaningful between
> +chassis.  This is initialized to 0 at the beginning of the logical
> +ingress pipeline.
> +_Keep the following in sync with MFF_LOG_FLAGS in_
> +_ovn/lib/logical-fields.h._
> +OVN stores this in Nicira extension register number 2.
> +
> +
> +VLAN ID:
> +
> +The VLAN ID is used as an interface between OVN and containers nested
> +inside a VM (see Life Cycle of a container interface inside a VM, in
> +ovn-architecture.7.xml, for more information).
> +
> +
> +The following table summarizes the register and metadata usage for OVN:
> +
> +```
> +  Register/Metadata         Usage                      Bits (Used/Total)
> +  ----------------        ---------                    --------------
> +  MFF_METADATA         logical datapath                      24/64
> +  MFF_REG0             ipv4 address                          32/32
> +  MFF_REG1             ipv4 address                          32/32
> +  MFF_REG2             flags                                  1/32
> +  MFF_REG3             conntrack dnat zone gateway           16/32
> +  MFF_REG4             conntrack snat zone gateway           16/32
> +  MFF_REG5             conntrack zone logical ports          16/32
> +  MFF_REG6             logical input port                    15/32
> +  MFF_REG7             logical output port                   16/32
> +```

Yes, this is pedantic, but it's jarring to a reader to have REG0 and REG1
introduced in the summary table and not discussed in previous paragraphs -
especially with the usage being just "ipv4 address" - do we mean to imply
that REG0 and REG1 carry the same data?

Ryan Moats

Ryan Moats



More information about the dev mailing list