On Mon, Jun 22, 2015 at 02:34:07PM -0400, Russell Bryant wrote: > 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.
I had to read this several times, but maybe I understand it now. Let me recap for verification. A "tenant network" is what OVN calls a logical network. OVN can construct it as an L2-over-L3 overlay with STT or Geneve or whatever. Tenant networks can be connected to physical networks via OVN gateways. A "provider network" is just a physical L2 network (possibly VLAN-tagged). In such a network, on the sending side, OVN would rely on normal L2 switching for packets to reach their destinations, and on the receiving side, OVN would not have a reliable way to determine the source of a packet (it would have to infer it from the source MAC). Is that accurate? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
