There are two steps to how this information is used:
Step 1: create a network - the type driver config on the neutron-server
host will determine which physnet and VLAN ID to use when you create it.
It gets stored in the DB. No networking is actually done, we're just
making a reservation here. The network_vlan_ranges are used to work out
which VLANs can be used automatically for tenant networks (and if you
specify a provider network then the infrormation in the Neutron call is
just copied into the DB).
Step 2: bind a port - we look up the network in the DB to find all that
information out, then tell the OVS agent to attach a port to a specific
physnet and VLAN on a specific host. The OVS agent on that host uses the
bridge_mappings to work out how to do that. And note, we don't care
whether the network was created as a tenant or provider network at this
point - it's just a network.
On 12 May 2017 at 06:26, wrote:
> [ml2_type_vlan]
> network_vlan_ranges = provider0,provider1,tenant-vla
> n2:200:299,tenant-vlan3:300:399
>
So here you're telling the controller (neutron-server) that two physical
networks, provider0 and provider1, exist that can only be used for VLAN
provider networks (because you haven't granted any ranges to neutron-server
for it to use automatically), and you've set up two physical networks with
VLAN ranges that Neutron may consume automatically for its tenant networks
(it will use VLANs out of the ranges you gave) *or* you can use for
provider networks (by specifying a VLAN using the provider network
properties when you create the Neutron network). This tells Neutron
information it can use in step 1 above, at allocation time.
A side note: different physical networks *should* be wired to entirely
independent physical switches that are not connected to each other; that's
what they're designed for, networks that are physically separated. That
said, I've seen cases where people do actually wire them together for
various reasons, like getting separate bandwidth through a different
interface for external networks. If you do that you have to be careful
which VLANs you use for provider networks on your provider physnets -
Neutron will not be able to work out that provider0 vlan 200 and
tenant-vlan2 vlan 200 are actually the same network, for instance, if you
connect both uplinks to the same switch.
[ovs]
> bridge_mappings = provider0:br-ext0,provider1:br
> -ext1,tenant-vlan2:br-vlan2,tenant-vlan3:br-vlan3
>
The 'bridge_mappings' setting is for compute and network nodes, where you
plan on connecting things to the network. It tells the OVS agent how to
get packets to and from a specific physical network. It gets used for port
binding - step 2 - and *not* when networks are created. You've specified a
means to get packets from all four of your physnets, which is normal. It
doesn't say anything about how those physnets are used - it doesn't even
say they're used for VLANs, I could put a flat network on there if I wanted
- and it certainly doesn't say why those VLANs might have been chosen.
How can neutron decide on choosing correct vlan mapping for tenant? Will it
> try to pick provider0 if normal user creates a tenant network?
>
Neutron-server will choose VLANs for itself, when you create a network, and
when you don't hand over provider network properties. And it will only
choose VLANs from the ranges you specified - so it will never choose a VLAN
automatically from the providerX physnets, given your configuration.
--
Ian.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
