OpenStack Neutron Networking Basics Explained

Neutron is the part of OpenStack that most people learn last and need most: it turns a pool of hypervisors into a programmable L2/L3 fabric with per-tenant isolation, floating IPs and security groups. The abstraction is not complicated once the object model is clear, but debugging is where time disappears, because a packet can be dropped by a security group, a missing NAT rule, a bad OVS flow or a routing table you forgot existed. This guide maps the object model to the underlying implementation and gives the command sequence that localises a fault quickly.

The object model

Network    a virtual L2 segment (isolated by VLAN, VXLAN or GRE)
Subnet     the CIDR + gateway + DHCP pool on a network
Port       the attachment point (a VM NIC, a router interface, a VIP)
Router     an L3 device that connects subnets, optionally to an external net
Security group  stateful filtering applied per port
Floating IP     a public address NATed to a VM's fixed private address
RBAC/QoS policies  who may attach, and how the port is shaped

The important mental shift is that a VM never gets an IP directly — it gets a port, and the port carries the addressing. Troubleshooting therefore starts with "which port is this traffic using?"

The path of a packet in a classic ML2/OVS deployment

VM tap device
  -> Linux bridge (qbr-*)        security groups applied here by iptables
  -> OVS integration bridge (br-int)   VLAN tag = internal segmentation id
  -> OVS tunnel bridge (br-tun)        VXLAN encapsulation to the peer host
  -> physical network
On the way out to the internet:
  -> br-int -> router namespace -> qg-* interface -> snat rules -> external network

Every namespace, bridge and interface name above is real and visible with ip and ovs-vsctl on the node running the VM. Debugging Neutron is mostly about following that chain in order.

ML2, OVS and OVN

ML2        the modular plugin framework (type drivers + mechanism drivers)
OVS driver traditional: per-host br-int / br-tun / namespaces
OVN driver modern:      distributed control plane, no per-router namespaces,
                        northbound/southbound DB, better scale and failover
Choose OVN for new deployments: fewer moving parts, native HA for L3.
Legacy OVS deployments still dominate existing clouds.

For a self-managed lab, Neutron over OVN is now the sensible default; the operational complexity of the OVS driver only makes sense if you are inheriting it.

Creating a working tenant network

openstack network create private-a
openstack subnet create private-a-subnet --network private-a \
    --subnet-range 10.20.0.0/24 --gateway 10.20.0.1 --dns-nameserver 10.20.0.2
openstack router create r1
openstack router add subnet r1 private-a-subnet
openstack network set --external public
openstack router set --external-gateway public r1
openstack floating ip create public
openstack server add floating ip web-01 203.0.113.77
openstack security group rule create --proto tcp --dst-port 443 default

Two things trip people up: the external gateway is set on the router (not the tenant network), and security groups are applied at the port, so a rule on the project's default group affects every VM in it.

The debugging sequence

# 1. is the port where you think it is?
openstack port list --server web-01 -c ID -c "Fixed IP Addresses" -c "MAC Address"
openstack port show 

# 2. on the compute node: does the port exist in the data path?
ip netns list
ovs-vsctl show | grep -A3 
sudo ip netns exec qrouter- ip addr     # classic OVS driver only

# 3. is the namespace doing NAT?
sudo ip netns exec qrouter- iptables -t nat -L -n -v
sudo ip netns exec qrouter- ip route

# 4. tunnel health
ovs-appctl ofproto/trace br-tun 

# 5. flows at the integration bridge
ovs-ofctl dump-flows br-int | grep 

# 6. agent state
openstack network agent list
openstack network agent show 

Symptom                             First place to look
VM gets IP, cannot ping gateway      br-int flows / port VLAN tag mismatch
Ping works, TCP blocked              security groups (stateful, applied on qbr)
No floating IP reachability          router external gateway / SNAT rules
Same host works, cross-host fails    VXLAN tunnel + MTU
Only some tenants affected           per-tenant network type id collision

MTU: the recurring theme

VM MTU must allow for the overlay header:
  path MTU 1500 - VXLAN (50) - inner overhead  -> guest MTU 1450 typical
Set the MTU on the neutron network, not per VM, or DHCP hands out the wrong
value and large packets vanish while ping keeps working.

Pitfalls worth documenting

Extending the overlay over a WAN      tunnel endpoints must be reachable
                                      and MTU-consistent end to end
Security group + local firewall       both apply; disable one to isolate
DHCP agent down                       IP assignment fails silently per host
L3 agent HA without proper config     floating IPs flap on failover
Provider network without a VLAN range tenant VLANs fail to allocate

The underlay matters as much as Neutron itself: the KVM layer is described in KVM/libvirt management, the storage leg in LVM thin provisioning, and if you are running containers instead, Swarm overlay networking is the analogous model.

FAQ

Q: Which is more production-ready, OVS or OVN? OVN today — it removes the per-router namespaces and gives distributed L3 with native HA.
Q: Can Neutron integrate with a physical switch fabric? Yes, via the ML2 drivers for your vendor and provider networks mapped to VLANs; the switch side is plain 802.1Q trunking.
Q: How do I see what the tenant actually changed? openstack network trunk list, openstack port show and the Neutron server log; there is no "show config" equivalent to a switch CLI, so log aggregation is essential.

原文链接：https://docs.openstack.org/neutron/latest/