OpenStack多租户网络隔离实战：从VLAN到VXLAN的架构演进

简介：面向云计算研究人员、系统管理员及OpenStack开发运维人员，这份PDF资料系统论述了多租户网络隔离的关键技术与落地方法。内容从OpenStack平台架构与Neutron、Nova等核心组件切入，对比分析VLAN、VXLAN、GRE在二层与三层场景中的隔离原理与选型思路，进而提出面向多租户的综合设计方案。文中详细记录了虚拟网络、子网、路由器等资源的创建方法，租户网络连接与安全访问控制策略的实施流程，并通过连通性测试、性能分析及异常模拟，对隔离方案的有效性和可靠性进行了完整验证。资源为单份PDF文件，压缩包大小136KB，体量精炼、重点突出，适合在云平台网络规划与运维中快速查阅。当前已有91人学习下载，对于正在设计多租户隔离方案、需要排查网络隔离问题的技术人员，具有直接的实践参考价值。

1. OpenStack多租户网络隔离为什么难做

OpenStack里多租户不难，难的是把“隔离”做到既彻底又灵活。同一台物理机上可能跑着几十家租户的虚拟机，有的租户要求私网IP互不可见，有的租户要求广播域彻底分开，还有的租户需要跨节点通信。传统VLAN方案用12位VLAN ID，满打满算4096个，放到公有云或大规模私有云里根本不够分。这时候再看OpenStack里的网络隔离，本质是三个层面的问题叠加：二层隔离保证租户的虚拟网络互不可达，三层隔离保证路由和地址空间不冲突，安全策略隔离保证即使网络通了、流量也被规则挡住。

很多人上手OpenStack时会犯一个判断错误：以为创建了两个租户网络就算“隔离”了。实际跑起来发现租户A的虚拟机竟然能ping通租户B的浮动IP，或者租户A建了一个CIDR重叠的子网，直接把租户B的路由搞乱了。这就是因为隔离不只是“建网络”，而是靠Neutron里一整套机制协同生效。本文要讲的，就是这套机制从原理到落地的完整路径。适合三类人看：正在搭OpenStack云平台、被多租户网络问题卡住的同学；已经在用OpenStack但说不清隔离边界、排错靠重启的运维；以及准备把多租户能力写进方案里的架构师。

2. OpenStack多租户网络隔离的技术原理与选型理由

2.1 隔离的本质：从VLAN到Overlay的必然迁移

OpenStack环境下的网络隔离，首选方案已经很明确了：二层用VXLAN或GRE这类Overlay隧道协议，取代传统的VLAN。这不是追新，是被规模逼出来的。VLAN只有12位标识符，4096个可用ID里还要去掉保留号，实际能用的不到4000个。在Neutron里每个租户网络都要占一个VLAN ID，网络一多立刻见底。更麻烦的是，VLAN隔离依赖物理交换机上的Trunk和VLAN配置，租户网络变更是要改交换机的，这在多云或大规模虚拟化场景下根本没法自动化。

VXLAN把二层帧封装进UDP包，用24位的VNI（VXLAN Network Identifier）标识虚拟网络。24位意味着理论上支持1600万个隔离网络，对绝大多数OpenStack部署来说和无限没有区别。GRE方案类似，用GRE Key字段区分租户，但GRE不带UDP头，没有等价多路径（ECMP）的负载均衡能力，所以现在主流部署基本都选VXLAN。从管理和运维角度看，VXLAN网络不需要在物理交换机上为每个租户单独配VLAN，IP网段规划也灵活得多。

2.1.1 Neutron的ML2插件如何支撑多租户隔离

Neutron的模块化第2层插件（ML2）是理解隔离机制的钥匙。ML2把网络类型和物理实现解耦了：类型驱动负责定义网络类型（如VLAN、VXLAN、GRE），机制驱动负责在网络节点或计算节点上实现对应的转发逻辑。核心是每个租户网络在ML2里会被映射到一个唯一的segmentation ID，这个ID就是隔离的凭证。

在VXLAN模式下，计算节点上的Open vSwitch（OVS）会为每个租户网络建立一个VXLAN隧道端点（VTEP），VNI就是这个网络唯一标识。当租户A的虚机发一个ARP请求时，OVS会把它封装进VXLAN包，带上租户A的VNI，发给对端VTEP。对端收到后，只有同属这个VNI的虚拟机才会收到广播。二层广播域就在VNI这个维度上被切开了，物理网络里其他租户看不到也收不到。

2.2 路由与地址空间的隔离机制

二层隔离解决了“同一个物理网络里互不可见”的问题，但OpenStack里租户还要能上网、要能访问外部、要能通过浮动IP对外提供服务。这就到了三层的隔离范畴。Neutron用虚拟路由器（Virtual Router）做租户网络的网关，每个租户路由器实质上是网络命名空间（Network Namespace）里的一个独立路由实例。

这里有点要转个弯：路由隔离不是“把路由表分开”这么简单，而是整个协议栈和路由表都在命名空间里独立运行。租户A的路由器命名空间里有一套完整的iptables、路由表和接口，租户B也有一套，两套之间互不可见。关键的是SNAT和浮动IP规则都挂在各自的命名空间里，所以哪怕两个租户内部用了完全相同的CIDR（比如都用192.168.1.0/24），在它们各自的命名空间里路由和NAT不会冲突。这种地址空间的重叠容忍能力，正是靠命名空间隔离托底的。

# 在网络节点上查看租户路由器的命名空间 ip netns list # 输出示例（每个qrouter-前缀都是一个租户路由器） qrouter-3c1a2b4e-8f2a-4b1e-9c3d-7e8a9b0c1d2e qrouter-8e7d6c5b-4a3f-4e2d-9c1b-6a5f4e3d2c1a # 查看某个租户路由器内部的完整路由表 ip netns exec qrouter-3c1a2b4e-8f2a-4b1e-9c3d-7e8a9b0c1d2e ip route

注意看输出的细节：每个qrouter命名空间里会有默认路由指向外部网关，也会有直连路由指向它挂载的每个子网。如果看到两个租户的命名空间里出现了完全相同的CIDR，不要慌，这是正常的。隔离的保障在于它们是不同的命名空间，Linux内核的网络栈天然保证它们互不干扰。判断隔离是否生效，要看的是命名空间之间的路由表是否完全独立，而不是CIDR是否重复。

2.3 隔离的层次划分：租户平面、管理平面与外部平面

生产环境部署OpenStack时，物理网络上通常会划分三个平面：租户平面承载VXLAN隧道封装后的流量，管理平面承载OpenStack组件之间的API通信，外部平面承载虚机访问外网的流量。这三个平面在网络层面必须严格隔离，否则租户流量可能绕开隧道和管理API流量混在一起，既危险又难以排错。

常见做法是三个平面各用独立的物理网口或VLAN来承载。比如控制节点用双网口，一个跑管理API，一个跑外部流量；计算节点也用双网口，一个跑管理面，一个跑VXLAN隧道流量。有些大集群会把VXLAN隧道流量也用独立物理网络跑，避免UDP封装后的流量占用管理带宽。多租户隔离首先从物理机自身的网络规划开始，如果底层物理网络就不分层，那上层VXLAN隔离再干净，也防不住物理链路上管理面和数据面的互相干扰。

3. OpenStack多租户网络隔离环境准备与基础配置

3.1 控制节点与计算节点的网络角色分配

在动手配置之前，先把环境里每个节点的角色和网络接口规划清楚。以下是我在部署OpenStack时比较常用的一套接口分配方案，适用性比较广，也便于后续排查问题：

节点角色	管理网口	数据网口（隧道）	外部网口	用途
控制节点	eth0	不需要(或eth1)	eth2	API服务、数据库、消息队列
网络节点	eth0	eth1	eth2	L3路由、DHCP、隧道终结
计算节点	eth0	eth1	不需要	虚机计算、VXLAN转发

管理网口跑的是OpenStack各服务之间的API通信，比如Nova到Neutron、Neutron到数据库。数据网口跑的是VXLAN封装后的租户流量，网关和VTEP地址都要在这个网络上可达。外部网口用来做浮动IP和SNAT的出入口，一般只在网络节点上需要。如果你用的是计算节点和控制节点融合的小规模部署，那就把管理口和数据口分开，别混在一起，这是底线。

提示：接口命名在不同的Linux发行版里可能不同（比如ens160、eno1、em1），不要死记名字，配置前先用ip link show看清楚实际网口名。

3.2 Neutron配置多租户隔离的核心参数说明

Neutron的配置集中在/etc/neutron/plugins/ml2/ml2_conf.ini，这里决定了网络隔离的底层行为。下面是一份最简可用的VXLAN配置，逐行解释每个参数为什么这么设：

[DEFAULT] # 指定Neutron的API服务和ML2插件的传输方式 core_plugin = ml2 service_plugins = router [ml2] # 支持的抽象网络类型：flat用于外部网络，vxlan用于租户网络 type_drivers = flat,vxlan # 租户可自服务的网络类型，不能包含flat（flat是管理员专属的） tenant_network_types = vxlan # 启用的机制驱动：linuxbridge或openvswitch二选一 mechanism_drivers = openvswitch [ml2_type_flat] # 平坦外部网络的物理网络名称 flat_networks = external [ml2_type_vxlan] # VNI分配范围，即租户网络可用的隔离ID池 vni_ranges = 1001:2000 [securitygroup] # 启用iptables驱动的安全组功能 enable_security_group = True firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver enable_ipset = True

最关键的三个点：tenant_network_types决定了租户能自服务创建哪种网络，值设成vxlan就表示租户建的私有网络都跑在VXLAN隧道上；vni_ranges是VNI的分配池，租户每建一个新网络，Neutron就会从这个池子里取出一个未使用的VNI分配给它；mechanism_drivers选择OVS还是linuxbridge，常见部署里openvswitch更主流一些，功能也更全。

配置完成后必须重启Neutron的服务让配置生效，同时要把网络节点上的openvswitch-agent和计算节点上的openvswitch-agent都重启。很多隔离问题出在配置改完了却只重启了server没重启agent，导致API层面已经更新了，但数据平面还是旧配置。

# 控制节点重启Neutron服务 systemctl restart neutron-server # 网络节点和计算节点重启OVS agent systemctl restart neutron-openvswitch-agent

3.3 创建初始多租户网络环境的命令流程

环境就绪后，需要在使用OpenStack命令行进行网络创建之前，先完成租户、用户和角色的初始化。通常用admin账号创建两个测试租户，比如叫project-a和project-b，然后分别创建各自的网络环境。

# 加载admin凭据环境变量 source admin-openrc # 创建两个测试租户 openstack project create project-a openstack project create project-b # 创建测试用户并分配租户角色 openstack user create --password userpass123 user-a openstack user create --password userpass123 user-b openstack role add --project project-a --user user-a member openstack role add --project project-b --user user-b member

这一步看起来只是账号管理，但它是网络隔离验证的前提。接下来要为每个租户单独创建网络和子网。下面以project-a为例：

# 以project-a的租户视角操作 source user-a-openrc # 创建租户A的私有网络 openstack network create net-a # 在net-a上创建子网 openstack subnet create --network net-a --subnet-range 192.168.1.0/24 --dhcp subnet-a

project-b也做同样操作，但把CIDR换成192.168.1.0/24也可以——这正是检验三层隔离的好机会。两个租户用完全相同的网段但只要它们都起了各自的虚拟路由器，就不会冲突。你可以先用admin账号确认每个租户网络拿到的VNI不同：

source admin-openrc # 查看租户网络的VNI和物理网络信息 openstack network show net-a -f json | grep segmentation_id openstack network show net-b -f json | grep segmentation_id

如果配置正确，两个网络的segmentation_id（即VNI）会不同。如果得到了相同ID或者为空，说明ML2的type driver配置有问题，回到ml2_conf.ini检查tenant_network_types和vni_ranges。

4. OpenStack多租户网络隔离配置实战与验证策略

4.1 租户网络的完整创建流程与要点

在第3章的创建基础上继续深入。租户网络建好后，需要创建路由器和外部网络才能让租户的虚机访问外部。这里的操作顺序有个讲究：先创建外部网络、再创建租户路由器、最后把两个子网接入路由器，顺序反了会导致网关配置不进去。

# 在admin租户下创建外部网络 source admin-openrc openstack network create --external --provider-physical-network external --provider-network-type flat ext-net openstack subnet create --network ext-net --subnet-range 203.0.113.0/24 --gateway 203.0.113.1 --no-dhcp ext-subnet # 在project-a下创建路由器，并同时连接外部网络和租户子网 source user-a-openrc openstack router create router-a openstack router set --external-gateway ext-net router-a openstack router add subnet router-a subnet-a

外部网络是全局共享的，浮动IP地址池就在里面。租户需要把虚拟机的私有IP映射成浮动IP才能从外部访问。注意租户不能自己创建外部网络，这是管理员才能做的操作。

4.2 安全组规则配置中的隔离落地

安全组是网络隔离的最后一层防线。Neutron默认会给每个租户创建一个默认安全组，这个组的初始策略是拒绝所有入站、放行所有出站。你要是用这个默认组，虚机被创建出来后是ping不通外部的，必须显式添加规则。

# 查看project-a的默认安全组 source user-a-openrc openstack security group list # 允许SSH入站 openstack security group rule create --proto tcp --dst-port 22 $(openstack security group list -f value -c ID | head -n 1) # 允许ICMP（ping）入站 openstack security group rule create --proto icmp $(openstack security group list -f value -c ID | head -n 1)

这里容易踩坑的地方：安全组规则里的方向区分“入站”和“出站”是相对于挂载了安全组的虚拟机的。你要允许外部访问虚机，必须显式加入站规则；如果你改了出站规则导致虚机无法访问外部，也要从出站方向检查。很多多租户环境里的“网络通了但业务不通”问题，排查到最后都是安全组规则少了某一条，而网络层本身是通的。

4.3 验证隔离效果的命令与抓包方法

4.3.1 用ping和traceroute验证二层三层隔离

验证分两步做。第一步，分别向project-a和project-b各创建一台测试虚机，确认虚机IP分别为192.168.1.10和192.168.1.10——如果两边的CIDR都是192.168.1.0/24，那它们拿到的IP相同才说明隔离生效：

# 在project-a创建测试虚机并获取IP source user-a-openrc openstack server create --flavor m1.tiny --image cirros --network net-a --key-name mykey vm-a openstack server list # 登录vm-a确认IP为192.168.1.10 ssh cirros@192.168.1.10 # 在vm-a内试图ping project-b的虚机IP（从admin账号查到project-b的虚机IP也是192.168.1.10） ping 192.168.1.10

这个测试很魔幻：ping的目标IP和自己的IP一模一样。如果隔离真正生效，ping会超时或者报错——因为目标IP虽然相同，但它属于另一个租户的网络命名空间，从vm-a的路由表看这个IP是它自己的IP，流量不会出网卡。如果ping通了，那就是路由或命名空间层面出了严重的隔离故障，要立刻检查路由器的命名空间是否被错误共享。

第二步，验证不同网段的租户网络不可互访。给project-a和project-b分别建不同的CIDR（比如a用192.168.1.0/24、b用192.168.2.0/24），从vm-a ping vm-b的IP。这时候ping不通才是正确的。

4.3.2 在计算节点上抓包验证VXLAN与VNI隔离

# 在计算节点上面查看VXLAN隧道接口和VNI ovs-vsctl show # 在数据网口上抓VXLAN包，过滤VNI=1001的流量 tcpdump -i eth1 -nn -s 0 udp port 4789 -vv -c 100 | grep -i "vni 1001"

日志里能清楚看到每个VXLAN包的VNI字段。如果从vm-a的ARP广播在VNI=1001里传输，而vm-b所在的VNI=1002里完全没有vm-a的MAC信息，说明二层隔离完美生效。这也是判断广播域是否正常切分的直接证据。

5. 多租户网络隔离架构规划与安全组加固策略

5.1 设计多租户网络架构时的选型决策

隔离方案能跑通只是第一步，把它设计成能长期稳定运行的生产架构才是正事。我参与过的项目中，网络隔离架构规划通常考虑三个决策点：

第一个决策：用VXLAN还是VLAN混合模式。有些系统对性能敏感——比如NFV场景或者对时延容忍度极低的业务，VXLAN封装解封装带来的CPU开销确实存在。常见做法是把高性能需求的裸机或特殊虚机放进VLAN网络段，把常规租户放进VXLAN网络段，两者通过一个虚拟路由器做互通。但注意VLAN段的数量上限就摆在那，别一次把4000个VLAN用掉大半。

第二个决策：租户路由器是共享还是独享。独享路由器隔离最彻底，但每多一个租户就多消耗网络节点的资源（每个路由器都占用一个qrouter命名空间）。共享路由器省资源但租户之间的路由策略会互相影响。如果租户数量少于100，我倾向于独享；超过100就要做资源评估或考虑引入DVR（分布式虚拟路由）把路由压力分散到计算节点。

第三个决策：浮动IP池和外部网络的规划方式。一个共享外部网络池还是每个租户独立外部网络段？共享池的好处是IP利用率高，坏处是租户之间可能因为看到同类IP而产生安全联想。独立外部段隔离更彻底，但IP规划成本高。大部分私有云环境用共享池加安全组限制就够了。

5.2 安全组加固的具体配置策略

安全组是实现网络隔离的有效补充，不是安全边界本身。在多租户场景里，安全组要做到从“默认拒绝”起步而不是“默认放行”：

# 管理安全组规则时应遵循的最小权限顺序 openstack security group rule list --long # 查看安全组规则统计信息 openstack security group rule list --long -f json | python3 -c " import json,sys data=json.load(sys.stdin) print('total rules:', len(data)) print('ingress rules:', len([r for r in data if r['Direction']=='ingress'])) print('egress rules:', len([r for r in data if r['Direction']=='egress'])) "

安全组规则的管理建议分组进行：每个业务组件一个安全组，比如web-sg放行80/443入站、db-sg只放行特定CIDR的3306入站。安全组之间引用时用“远程安全组ID”而不是IP段，这样当虚机IP变化时规则不用改。这个习惯的价值在处理跨租户访问时特别明显——两个租户之间有业务往来时，可以在租户A的安全组里引用租户B指定的安全组ID，而不是写死租户B某个虚机的临时IP。

提示：Neutron安全组的iptables规则是在计算节点上通过iptables-save命令持久化的，但OpenStack的规则管理会自动写入libvirt的配置文件里，虚机迁移后规则会随虚机移动到新节点。

5.3 多租户网络隔离的安全加固清单

结合实战经验，给出一份可供参考的安全加固清单：

加固项	具体操作	验证方式
地址空间重叠容忍	两个租户使用完全相同的CIDR	从两个租户各自的虚机互ping对方IP，确认不通
广播域隔离	查看计算节点OVS的流表，确认不同VNI的ARP不跨租户转发	在一个租户的虚机里发ARP广播，另一个租户的虚机看不到
路由器隔离	确认每个租户有独立的路由器命名空间	ip netns list查看qrouter数量与租户数量一致
安全组默认拒绝	新租户默认安全组不包含任何入站规则	openstack security group rule list确认空
元数据服务隔离	租户虚机只能访问自己的元数据	curl http://169.254.169.254/ 返回该租户专属的元数据内容

5.4 混合Overlay与VLAN的架构实践

生产中不只有纯VXLAN这一种姿势。我见过不少OpenStack私有云解决方案里会在架构上混合使用both类型：性能敏感型租户走VLAN网络，普通租户走VXLAN。这时候的隔离边界切换发生在虚拟路由器上。VLAN网络交由物理交换机终结，VXLAN由计算节点终结，两类流量在虚拟路由器或物理路由器上汇合。

这种混合架构下的隔离要注意一点：VLAN段里的广播域隔离依赖物理交换机的VLAN配置，如果交换机配置出错，VLAN间就会互相泄露。所以在这种架构里，交换机的配置文件必须纳入配置管理，并定期和Neutron数据库里的VLAN分配情况做比对。

# 检查某个VLAN网络的配置是否和物理交换机一致 # 在Neutron数据库中查看VLAN分配情况 mysql -u neutron -p -e "use neutron; SELECT id, vlan_id FROM networksegments WHERE network_type='vlan';"

5.5 跨节点通信时VXLAN的架构与排错

多节点部署时，VXLAN隔离的难点转移到了“隧道是否按预期建立”。计算节点之间必须建立VXLAN隧道才能让不同节点上同租户的虚机通信。这个隧道是自动协商的，但排错时要从底层查起：

# 在计算节点上查看已经建立的VXLAN隧道的VTEP地址和隧道名称 ovs-vsctl show | grep -A 10 "Bridge br-tun" # 查看br-tun上的所有隧道接口 ovs-vsctl list-ports br-tun # 查看特定隧道接口采用的远程IP地址 ovs-vsctl get interface vxlan-0a00010b options

如果发现隧道的remote_ip不对，多半是配置了错误的hostname解析或Neutron的agent配置里tunnel_type和local_ip不匹配。检查/etc/neutron/plugins/ml2/openvswitch_agent.ini里的tunnel_type=vxlan和local_ip是否为计算节点数据网口的正确IP。

5.6 安全隔离与性能的平衡策略

多租户隔离并不是“越彻底越好”。我把这个平衡点总结为三条原则：

开销控制原则。每个租户路由器都是一个命名空间，命名空间里的路由表、iptables规则、SNAT连接跟踪都要占内存。一个网络节点跑30个路由器就有点重了，超过50个就要考虑横向扩展网络节点或换用DVR架构。

排查复杂度控制原则。隔离层越多，出问题时越难判断是哪一层出了问题。生产环境中建议保留清晰的隔离层次：物理网络分平面 → VXLAN隧道隔离租户 → 路由器命名空间隔离三层 → 安全组控制应用访问。四层各司其职，排错时自上而下逐层排查，效率最高。

可用性优先原则。不要为了隔离效果引入单点。比如把某个租户的全部流量都集中到一台网络节点上，隔离是彻底了，但这台节点一挂，整个租户就断网了。所以生产架构里通常会为每个租户建两个路由器分布在不同的网络节点上，用VRRP做高可用。

6. 网络隔离压测验证与Linux命名空间隔离的验证技巧

6.1 用netns手动验证隔离效果的技巧

这个方法是很多人不知道的终极大招。利用Linux网络命名空间手动复现Neutron的隔离行为，不需要完整跑OpenStack环境，一根网线加两个命名空间就能验证底层隔离原理：

# 创建两个网络命名空间并连接veth对 ip netns add ns1 ip netns add ns2 ip link add veth1 type veth peer name veth1-peer ip link add veth2 type veth peer name veth2-peer # 把veth设备分别放入命名空间 ip link set veth1 netns ns1 ip link set veth2 netns ns2 # 给两个命名空间的接口配置相同IP，模拟地址重叠场景 ip netns exec ns1 ip addr add 192.168.1.10/24 dev veth1 ip netns exec ns2 ip addr add 192.168.1.10/24 dev veth2 # 启用接口 ip netns exec ns1 ip link set veth1 up ip netns exec ns2 ip link set veth2 up # 两个命名空间各自ping自己，验证隔离 ip netns exec ns1 ping 192.168.1.10 ip netns exec ns2 ping 192.168.1.10

两个命名空间里的“自己”IP地址完全相同，但各自ping通的是各自的接口。这个实验直观展示了为什么OpenStack里两个租户可以用相同的CIDR而不会产生路由冲突——内核栈在命名空间维度上做了完全的隔离。

6.2 抓包验证隔离的进阶技巧

生产环境验证VXLAN隔离是否生效前，先确认隧道状态正常。我常用的验证顺序是：先看VNI是否分配正确，再看计算节点的流表是否正常工作：

# 查看br-tun上的OpenFlow流表 ovs-ofctl dump-flows br-tun # 过滤和特定VNI相关的流表项 ovs-ofctl dump-flows br-tun | grep "tun_id=0x3e9" | head -20

0x3e9是1001的十六进制表示。如果看到流表行动作是load:0x3e9->NXM_NX_TUN_ID[]或者push_vxlan相关动作，说明这个VNI对应的虚拟网络处理链是通的。如果只剩默认drop流表项，说明该租户的网络上没有虚机或者agent没同步到流表。

6.3 用iperf3验证隔离对性能的实际影响

隔离和性能之间的权衡是绕不开的课题。给租户加上VXLAN封装后，虚机之间的吞吐量有一定下降是正常的，但下降幅度有范围。正常VXLAN封装的开销在5%10%左右，如果超过这个数，说明底层隧道处理有问题。

# 在租户A的虚机上运行iperf3服务端 iperf3 -s -p 5201 # 在租户B的同网段虚机上运行iperf3客户端测试跨节点吞吐 iperf3 -c <租户A虚机IP> -p 5201 -t 30

如果两个虚机在不同计算节点，iperf结果能直接反映VXLAN隧道封装的网络吞吐。如果两个虚机在同一节点，结果反映的是OVS的本地交换性能。两者对比就能判断隧道封装的开销是否过大。如果跨节点吞吐远低于物理网卡理论速率，优先检查数据网口的协商速率和是否有丢包：

# 在计算节点数据网口上检查丢包统计 ethtool -S eth1 | grep error ethtool -S eth1 | grep drop

丢包集中在rx_errors或tx_dropped上时，多半是环形缓冲区太小或CPU中断不均衡。VXLAN封装需要消耗额外的CPU，建议给OVS的处理线程绑定独立CPU核心。

6.4 云平台搭建过程中的网络隔离最终验收清单

最后给出一个可直接拿去用的验收清单，适合OpenStack云平台搭建完成后对多租户隔离做系统性验证：

验证项	操作命令	预期结果
租户间二层隔离	租户A虚机ping租户B虚机同网段IP	超时
租户间三层隔离	租户A虚机ping租户B虚机不同网段IP	超时
地址重叠容忍	两个租户创建相同CIDR子网	都能正常工作，互不影响
广播域隔离	一个租户发ARP广播，另一租户抓包	另一方抓不到任何ARP包
跨节点通信	不同计算节点上的同租户虚机互ping	延时正常、无丢包
隧道封装备份	抓数据网口UDP 4789报文	VNI字段与网络配置一致
安全组生效	删除安全组入站规则后ping虚机	超时，恢复规则后正常
网络节点故障切换	停掉网络节点的L3服务	租户流量在备用节点接管后恢复

这份清单在每次升级Neutron或修改网络配置后都值得跑一遍，所有操作都可以通过OpenStack CLI远程完成，不需要登录到虚机里操作。本文的完整思路是：从VLAN到VXLAN的隔离演进理解了为什么、从ML2到命名空间知道了靠什么、从命令落实到验证掌握了怎么办、从架构规划到加固策略清楚怎么优化。把这四层都理顺，OpenStack环境下的多租户网络隔离就既拦不住你，也坑不了你。

本文还有配套的精品资源，点击获取