基于最新代码搭建OpenStack，实现VLAN与租户型多网络类型需求问询

Got it, let's walk through how to set up these two network types on the latest OpenStack release. I've implemented this exact setup a couple of times, so here's a practical, step-by-step breakdown that should work for you:

This network type lets instances pull IPs directly from your existing physical LAN—no NAT, no extra routing hoops. Here's how to get it running:

• Create the provider network
  Use the OpenStack CLI (or Horizon dashboard) to map an OpenStack network to your physical VLAN. Swap out the placeholders with your actual LAN details:

  openstack network create --share --provider-physical-network physnet1 --provider-network-type vlan --provider-segment <YOUR_VLAN_ID> provider-vlan-network
  

  • --share: Makes the network accessible to all tenants (remove this if you want it restricted to a specific tenant)
  • physnet1: This matches the physical network name defined in your Neutron ml2_conf.ini file—double-check it’s consistent across your network and compute nodes
  • <YOUR_VLAN_ID>: The VLAN tag used by your existing LAN (e.g., 100)

• Create a subnet using your existing LAN IP pool
  Don’t spin up a new private subnet—reuse your LAN’s existing IP range. Disable DHCP if your LAN already has a DHCP server running, or leave it enabled if you want OpenStack to handle IP assignments:

  openstack subnet create --network provider-vlan-network --subnet-range <YOUR_LAN_CIDR> --gateway <YOUR_LAN_GATEWAY> --no-dhcp provider-vlan-subnet
  

  • Replace <YOUR_LAN_CIDR> (e.g., 192.168.5.0/24) and <YOUR_LAN_GATEWAY> (e.g., 192.168.5.1) with your actual LAN values
  • Drop the --no-dhcp flag if you want OpenStack to manage DHCP for this network (just make sure it doesn’t conflict with your LAN’s existing DHCP)

• Validate compute node setup
  Ensure every compute node has a physical NIC connected to a switch port tagged with your target VLAN. On each compute node, confirm the Neutron agent (e.g., linuxbridge or ovs) is configured to map physnet1 to the correct physical NIC (check /etc/neutron/plugins/ml2/linuxbridge_agent.ini or equivalent).

When launching an instance, select this provider-vlan-network—it’ll grab an IP directly from your LAN, be reachable like any other device on the network, and skip any NAT layers.

This is the standard tenant-isolated setup, where instances use private IPs and can optionally access the internet via a router with NAT.

• Create a tenant private network
  This network is isolated to your tenant by default—no other tenants can access it unless you explicitly share it:

  openstack network create tenant-private-network
  

• Create a private subnet
  Define a private IP range for your VPC (pick any RFC1918 range that doesn’t conflict with your existing networks):

  openstack subnet create --network tenant-private-network --subnet-range 10.10.0.0/24 --gateway 10.10.0.1 tenant-private-subnet
  

• Set up a router for internet access (optional)
  If you want instances to reach the outside world, create a router that links your private subnet to an external public network (could be a dedicated public network or even the provider network from type 1, with NAT enabled):

  # Create the router
  openstack router create tenant-router
  # Attach the private subnet to the router
  openstack router add subnet tenant-router tenant-private-subnet
  # Connect the router to your external public network
  openstack router set --external-gateway <PUBLIC_NETWORK_NAME> tenant-router
  

  This enables SNAT, so instances can access the internet while their private IPs stay hidden from the public network. You can also assign floating IPs to specific instances if you need external access to them.

• Launch instances with this network
  When spinning up an instance, select tenant-private-network—it’ll get a private IP from your defined subnet (e.g., 10.10.0.x).

• Neutron ML2 Config: Make sure ml2_conf.ini has vlan listed in type_drivers and tenant_network_types (for type 2 networks), and that physical_network_mappings correctly links physnet1 to your physical NIC.
• Security Groups: Don’t skip configuring security groups—allow essential traffic like SSH or ICMP to your instances, regardless of which network type you’re using.
• Validation: After setup, launch test instances on each network. Use openstack server show <INSTANCE_ID> to verify IP assignment, and ping instances from your LAN (type 1) or test internet connectivity (type 2) to confirm everything works.

内容的提问来源于stack exchange，提问作者Satish