Multiple logical ports on the same chassis that were connected to the
same physical network via localnet ports were not able to send packets
to each other. This was because ovn-controller created a single patch
port between br-int and the physical network access bridge and used it
for all localnet ports.
The fix implemented here is to create a separate patch port for every
logical port of type=localnet. An optimization is included where these
ports are only created if the localnet port is on a logical switch with
another logical port with an associated local VIF.
A nice side effect of this fix is that the code in physical.c got a lot
simpler, as localnet ports are now handled mostly like local VIFs.
Fixes: c02819293d52 ("ovn: Add "localnet" logical port type.")
Reported-by: Han Zhou <zhouhan@gmail.com>
Reported-at: http://openvswitch.org/pipermail/dev/2016-January/064413.html
Signed-off-by: Russell Bryant <russell@ovn.org>
Tested-by: Kyle Mestery <mestery@mestery.com
Acked-By: Kyle Mestery <mestery@mestery.com>
Tested-by: Han Zhou <zhouhan@gmail.com>
Tested-by: Michael Arnaldi <michael.arnaldi@mymoneyex.com>
Acked-by: Ben Pfaff <blp@ovn.org>
This implementation is suboptimal for several reasons. First, it
creates an OVS port for every OVN logical patch port, not just for the
ones that are actually useful on this hypervisor. Second, it's
wasteful to create an OVS patch port per OVN logical patch port, when
really there's no benefit to them beyond a way to identify how a
packet ingressed into a logical datapath.
There are two obvious ways to improve the situation here, by modifying
OVS:
1. Add a way to configure in OVS which fields are preserved on a
hop across an OVS patch port. If MFF_LOG_DATAPATH and
MFF_LOG_INPORT were preserved, then only a single pair of OVS
patch ports would be required regardless of the number of OVN
logical patch ports.
2. Add a new OpenFlow extension action modeled on "resubmit" that
also saves and restores the packet data and metadata (the
inability to do this is the only reason that "resubmit" can't
be used already). Or add OpenFlow extension actions to
otherwise save and restore packet data and metadata.
We should probably choose one of those in the medium to long term, but
I don't know which one.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Justin Pettit <jpettit@nicira.com>
An upcoming patch will introduce a different use for patch ports, so
ovn-patch-port would become an ambiguous name.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Justin Pettit <jpettit@nicira.com>
Calculating the patch port names from the bridge names makes sense when
there's only one pair of patch ports between a pair of bridges, but that
won't be the case for an upcoming use of patch ports.
This changes makes it easy to check for existing patch ports in
create_patch_port(), instead of in its caller, and since that seems like a
more sensible place this change also moves it there.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Justin Pettit <jpettit@nicira.com>
Until now, the code here lumped together what was necessary to create and
destroy patch ports, with what was necessary to identify the patch ports
that were needed. An upcoming patch will add new reasons to create patch
ports, so this commit more cleanly separates those two functions.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Justin Pettit <jpettit@nicira.com>
The whole point of this module is side effects on the Open vSwitch
database, so the whole thing can be skipped if those are impossible.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Justin Pettit <jpettit@nicira.com>
Upcoming patches will introduce new extensive use of patch ports and it
seems reasonable to put it into its own file.
This is mostly code motion. Code changes are limited to those necessary
to make the separated code compile, except for renaming
init_bridge_mappings() to patch_run().
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Justin Pettit <jpettit@nicira.com>
