[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