[ovs-dev] [PATCH v7 3/3] ovn: Add "localnet" logical port type.

Russell Bryant rbryant at redhat.com
Tue Sep 1 21:38:41 UTC 2015


On 09/01/2015 04:55 PM, Ben Pfaff wrote:
> On Wed, Aug 26, 2015 at 11:07:54AM -0400, Russell Bryant wrote:
>> Introduce a new logical port type called "localnet".  A logical port
>> with this type also has an option called "network_name".  A "localnet"
>> logical port represents a connection to a network that is locally
>> accessible from each chassis running ovn-controller.  ovn-controller
>> will use the ovn-bridge-mappings configuration to figure out which
>> patch port on br-int should be used for this port.
> 
> [...]
> 
>>        <p>
>> +        It's possible that a single ingress physical port maps to multiple
>> +        logical ports with a type of <code>localnet</code>.  In that case, an
>> +        OVN flag is set to indicate that this packet arrived on a <code>localnet</code>
>> +        port.  This flag is used later to help determine what type of output is
>> +        appropriate.  The logical datapath and logical input port fields will be
>> +        reset and the packet will be resubmitted to table 16 multiple times.
>> +      </p>
> 
> I'm not sure why this is a likely problem that needs to be avoided,
> since the structure of logical networks that contain localnet ports is
> so simple.  Can you explain?

Continuing with the example from the commit message:

Hypervisors A and B with VMs A1, A2, B1, B2.  Each port is on a lswitch
with a localnet port associated with the same network.

Consider an ethernet broadcast packet arriving at hypervisor A.  It will
get delivered to VMs A1 and A2.  The flag is used to skip sending it to
hypervisor B for B1 and B2.  We expect it to get delivered to B1 and B2
via B's own connection to that network.

For that specific example, we could accomplish the same thing in a
simpler way.  We could only process the packet in table 0 for logical
switches that have a local logical port (so, the lswitches for A1 and A2
only).  This is probably a good idea no matter what.  I'll do that for
rev 8.

The catch is if localnet ports support more complex configurations.
Imagine adding several logical ports to the same logical switch with a
localnet port.  In that case, I think we still need the flag to ensure
that we deliver the packet to local outputs, but don't send it over any
tunnels.

An alternative is to document (and maybe enforce in code?) that localnet
ports are *only* supported for this simple 1 localnet port and 1 regular
port scenario.  I personally don't care about other scenarios, but
technically it's possible right now.  I'm not sure if it's valuable or
not, though.

-- 
Russell Bryant



More information about the dev mailing list