[ovs-dev] OVN and OpenStack Provider Networks

Russell Bryant rbryant at redhat.com
Mon Jun 22 18:34:07 UTC 2015


(Apologies for the slow follow-up to the responses on this thread.  I've
been on vacation.)

On 06/15/2015 08:00 PM, Ben Pfaff wrote:
> On Wed, Jun 10, 2015 at 03:13:54PM -0400, Russell Bryant wrote:
>> Provider Networks
>> =================
>>
>> OpenStack Neutron currently has a feature referred to as "provider
>> networks".  This is used as a way to define existing physical networks
>> that you would like to integrate into your environment.
>>
>> In the simplest case, it can be used in environments where they have no
>> interest in tenant networks.  Instead, they want all VMs hooked up
>> directly to a pre-defined network in their environment.  This use case
>> is actually popular for private OpenStack deployments.
>>
>> Neutron's current OVS agent that runs on network nodes and hypervisors
>> has this configuration entry:
>>
>>     bridge_mappings = physnet1:br-eth1,physnet2:br-eth2[...]
>>
>> This is used to name your physical networks and the bridge used to
>> access that physical network from the local node.
>>
>> Defining a provider network via the Neutron API via the neutron
>> command looks like this:
>>
>>     $ neutron net-create physnet1 --shared \
>>     > --provider:physical_network external \
>>     > --provider:network_type flat
>>
>> A provider network can also be defined with a VLAN id:
>>
>>     $ neutron net-create physnet1-101 --shared \
>>     > --provider:physical_network external \
>>     > --provider:network_type vlan \
>>     > --provider:segmentation_id 101
> 
> I'm trying to understand what degree of sophistication these provider
> networks have.  Are they just an interface to a MAC-learning switch
> (possibly VLAN-tagged)?  Or do provider networks go beyond that, with
> the features that one would expect from an OVN logical network
> (e.g. port security, ACLs, distributed routing and firewalling, ...)?

(Kyle and Salvatore, please sanity check me on this.)

AFAIK, it is simply an interface to a MAC-learning switch, possibly VLAN
tagged.

It is not expected that a provider network would provide port security
or ACLs (security groups).  Those would still be the responsibility of
OVN in this case.

A provider network *may* (but usually does) handle routing and SNAT/DNAT
if necessary.  In that case it is managed externally to Neutron.  The
only knowledge Neutron has is about the address space on the provider
network, since Neutron provides IPAM.  Continuing with the example
above, we can define a subnet on that provider network with:

  $ neutron subnet-create provider-101 203.0.113.0/24 \
  > --enable-dhcp --gateway 203.0.113.1

Neutron would do address assignment and provide the DHCP server for this
network.  203.0.113.1 would be the router.

Neutron (and thus, OVN) would provide port-level firewalls (Neutron
security groups) using OVN ACLs.  Additional firewalls (such as at the
router) may exist, but Neutron doesn't need to know about it as it's
expected to be managed externally.

-- 
Russell Bryant



More information about the dev mailing list