On 06/23/2015 04:17 PM, Ben Pfaff wrote: > 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? >
Yes, all of that matches my understanding of things. I worry that not being able to explain it well might mean I don't have it all right, so I hope some other Neutron devs chime in to confirm, as well. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
