简介《OpenStack网络实战精讲》是一份面向云计算工程师与网络架构师的PDF电子书系统讲解Neutron在OpenStack云平台中的核心作用。内容覆盖虚拟网络架构、SDN原理、ML2插件、Open vSwitch、安全组与分布式路由并延伸至VLAN感知虚拟机、BGP动态路由等高级场景适合需要加深网络组件协同理解、提升云网络排障与性能优化能力的进阶读者。资源为单个PDF文件压缩包约75.94MB共1个文件便于直接阅读和章节检索章节按基础架构、核心插件与高级功能展开可快速定位所需知识。目前已有57人学习下载。书中结合Packt原版第三版内容既有理论框架也有实践案例可帮助读者理解如何通过编程方式控制网络资源、借助ML2实现网络抽象以及在实际部署中应用OVS与分布式路由来提高网络可靠性和效率同时还能从安全组与BGP/VLAN高级配置案例中收获排障思路与部署技巧是一份兼顾讲解与操作参考的技术资料。1. OpenStack网络实战为什么网络层是运维翻车重灾区“OpenStack网络实战”这几个字初看是教程真在环境里跌过跟头的人才会明白它更接近一门排错的手艺。我见过不少团队搭完 OpenStack 云平台建好云主机后内网不通、外网也不通查来查去只是新建的子网没有挂到路由器上——这种入门级翻车几乎都出在 Neutron 这个黑匣子里。这篇文章要讲的就是从网络、子网、路由器三大抽象开始把命令行建网、安全组、浮动IP、故障排查一路做到位。适合正在维护私有云环境或者刚把业务迁上 OpenStack 的运维工程师也适合想从零理清 Neutron 网络模型的开发。2. 理解 Neutron 的三大核心抽象网络、子网、路由器2.1 L2 网络与 L3 路由VLAN 与 VXLAN 的选型权衡Neutron 管理的是二层到四层的网络资源。对外提供三个最常用的对象network 对应一个二层广播域subnet 是绑在上面的 IP 地址池与三层路由入口router 则负责把不同的 subnet 接起来并连接外部网络。很多新手一上来就创建云主机很少先理解这三者的关系结果 provider 参数、网关选项全成了玄学出了问题只能到处翻日志。网络域隔离这块最传统的是 VLAN。VLAN 划分在物理交换机上每个租户网络对应一个 VLAN ID天然跟网络域隔离 - VLAN划分与ACL配置 的思路一致。但 VLAN 最多 4096 个大规模多租户环境很快会耗尽。VXLAN 用 24 位 VNI 做二层封装在三层 IP 网络上跑 UDP 隧道VNI 数量远多于 VLAN而且不需要每台交换机都拆出独立物理口。常见做法是测试环境用 VXLAN省去物理交换机频繁改配生产环境如果网络设备够用VLAN 的排错路径更短物理网络拓扑也更清晰。我一般这样选型计算节点之间二层可达、规模在几十台以内用 VLAN 或 flat 都能接受一旦租户数量多、需要跨三层网段通信或者物理网络不支持统一改造就把 VXLAN 作为默认。下面这张表列出关键差异方便你按自己的环境做取舍项目VLANVXLAN二层标识12 位 VID4096 个24 位 VNI约 1677 万个封装协议802.1Q直接改以太网头UDP 隧道外层是普通 IP对物理网络需要交换机配置 trunk、处理 VLAN只需要三层可达组播或 EVPN 做控制面排错难度抓包直观tcpdump 直接看 VID需要看内层 IP稍微绕选型之后还要理解 Neutron 的架构。控制节点上的 neutron-server 接收 API通过消息队列通知各个 agent。计算节点上的 neutron-openvswitch-agent 或 linuxbridge-agent 负责创建虚拟网卡和 VLAN/VXLAN 桥接网络节点上的 L3 agent 负责路由、浮动 IP 和 SNAT/DNATDHCP agent 负责给虚拟机分配 IP。这个模型是你动手之前必须刻在脑子里的否则后面排查时你连该在哪个命名空间里抓包都不知道。2.2 从 CLI 看数据模型openstack network create 背后的参数理解了抽象就可以用命令行把模型落地。这里我不建议一上来就用 Horizon 页面页面会隐藏大量字段出了问题很难对应到 API 层。用 CLI 创建网络的通用做法是这样# 创建租户网络类型选择 VXLANVNI 设为 1000 openstack network create --project admin \ --provider-network-type vxlan \ --provider-segment 1000 \ demo-net # 在网络下创建子网启用 DHCP网关留在后续接路由器时处理 openstack subnet create --network demo-net \ --subnet-range 10.10.0.0/24 \ --dns-nameserver 114.114.114.114 \ --dhcp \ demo-subnet第一段里的 --provider-network-type 和 --provider-segment 是给物理网络打标记用的。VXLAN 时--provider-segment 设的就是 VNIVLAN 时它表示 VID。两个参数必须和你在 agent 配置里定义的 provider 映射一致否则数据包根本不知道应该走哪块网卡。--project 指定资源归属不指定的话会落到当前用户的项目下容易引起权限混乱。我习惯显式写出来。第二段里 --dhcp 启动 DHCP 分配能力配合 --dns-nameserver 给客户机下发 DNS。注意这只是租约配置真正执行分配的是网络节点上的 DHCP agent。如果 agent 没起端口会一直处于 down 状态。检查后端状态可以这样openstack network agent list看到 neutron-dhcp-agent 状态为 Alive 才算正常。CLI 创建出的对象最终都会在数据库里落一条记录并且在命名空间里表现为一组虚拟设备。记住这一点排错的时候你就能理解为什么 ip netns list 会看到那么多没头没脑的 qdhcp 和 qrouter 命名空间。创建成功以后强烈建议用openstack network list --project admin和openstack subnet list复查一遍。注意看 Provider Network 那一列如果显示为 none说明你创建的是普通租户网络没有绑定物理网络无法直接访问外部如果显示 vxlan:1000 或 vlan:xxx说明绑定成功。绑定关系在 Horizon 上很隐晦在 CLI 里则一目了然。2.3 为什么先规划网络拓扑再动手创建网络之前最好先画一张网络拓扑图。这不只是文档要求更是为了让你在 CLI 一条条敲的时候心里有数。常见的拓扑就三类单租户单网段适合跑测试多网段加路由器模拟传统三层架构所有业务共用一个外部网络靠浮动IP暴露服务。开建之前先把下面几个问题想清楚业务需要几个网段管理网、业务网、存储网是否要分开各网段的网关设在路由器上还是直接接外部网络需要几个外部网络外部网络的物理连接是 flat 还是 VLAN安全组要放行哪些端口默认全拒的内网环境是否满足需求我见过最典型的失败案例是规划时把所有实例放进一个 /24回头要加隔离网段时却发现每个网段都想走同一个路由器结果路由表互相覆盖。OpenStack 的 router 支持多接口但每个接口的子网 CIDR 不能重叠规划时就要避免。还有一点规划时要确认物理网络对 VXLAN 组播或 EVPN 的支持情况。如果你的物理交换机禁用了组播VXLAN 上报的 BUM广播、未知单播、组播流量会全丢二层容易通但广播不通。这种问题在网络拓扑图上完全看不出来必须提前和网络团队确认交换机配置。没有这个确认后面动态 DHCP 时你会发现只有部分云主机能拿到地址而另一部分一直处于获取失败状态。这一节没有贴太多命令因为真正要落地的是思路。有了拓扑规划后面的命令行操作就只是按图施工。接下来我们就按一张最简单但完整的拓扑来做一个租户网络、一个子网、一台路由器接到外部网络。3. 用命令行创建隔离网络与路由器从零搭建一套可通信环境3.1 最小操作创建网络、子网、路由器的完整命令序列假设你已经有了一个可用的外部网络名字叫 public-net并且 Keystone、Neutron 服务都正常。先创建租户网络和子网沿用上一章的命令然后创建路由器并接上子网和外部网关# 创建租户网络VNI 只在本环境内唯一 openstack network create --project admin \ --provider-network-type vxlan \ --provider-segment 1000 \ demo-net # 创建子网网关地址留给路由器 openstack subnet create --network demo-net \ --subnet-range 10.10.0.0/24 \ --allocation-pool start10.10.0.100,end10.10.0.200 \ --dns-nameserver 114.114.114.114 \ --dhcp \ demo-subnet # 创建路由器并把它接入租户子网作为网关 openstack router create demo-router openstack router add subnet demo-router demo-subnet # 把路由器接上外部网络作为租户网络的出口 openstack router set --external-gateway public-net注意--allocation-pool限定了 DHCP 分配区间剩余地址留给路由器接口和浮动 IP避免地址冲突。这是生产环境里很重要的细节如果你把整个子网都丢进分配池之后想手工指定一个静态 IP 做测试会发现总被 DHCP 抢先占用。路由器接入子网后OpenStack 会为它创建多个逻辑接口一个接租户子网一个接外部网络还有一个是路由器自身的管理口。接口名称在命名空间里对应 qr-xxx租户侧和 qg-xxx外部侧。可以用下面的命令查看路由器端口openstack port list --router demo-router如果输出里只有两个端口说明你还没设置好外部网关或者外部网络类型不匹配。常见做法是先查openstack network show public-net确认它是 external 类型再执行 router set。很多翻车现场就是这一步顺序反了——先想让路由器出外网结果发现没有 external 网络只能临时创建一个然后所有配置都推倒重来。另外如果你执行openstack router create时遇到Multiple possible values之类的提示多半是 Keystone 里有多个同名项目。解决办法是在命令上补--os-project-name admin --os-project-domain-name default这类认证参数。这不算网络问题却是命令行操作最常见的拦路虎。3.2 验证租户网络互通登录云主机 ping 与 icmp 检查网络拓扑建好后拉起两台云主机。这里我用最小规格的 Ubuntu 镜像不绑定浮动 IP先验证内网互通# 创建两台云主机接入 demo-net openstack server create --image ubuntu-20.04 --flavor m1.small \ --network demo-net --key-name mykey \ --wait vm-a openstack server create --image ubuntu-20.04 --flavor m1.small \ --network demo-net --key-name mykey \ --wait vm-b # 查看分配到的内网 IP openstack server list -c Name -c Networks假设 vm-a 拿到 10.10.0.101vm-b 拿到 10.10.0.102。直接登录 vm-aping 一下 vm-bping -c 3 10.10.0.102能通则证明二层同网段没问题。不同网段之间的通信需要走路由器。你可以在子网 10.11.0.0/24 里再建一个子网把第二个子网加到同一台路由器上然后从 vm-a ping 第二个子网里的机器。如果 ping 不通多半是路由器没有启用或者云主机没有配置默认路由。检查云主机里的ip route应该能看到 default via 10.10.0.1这个 10.10.0.1 是路由器在子网里的网关接口。如果云主机自身的路由没问题就要去命名空间里看路由器是否真的在转发。这里给一条最常用的命令ip netns exec qrouter-demo-router ping 10.10.0.102 -c 3用路由器命名空间去 ping 云主机能通说明 L3 agent 正常问题在云主机侧不通则问题在网络节点侧。这个定位思路比我见过的任何监控面板都可靠。还有一个容易被忽略的小细节如果云主机镜像里启用了 iptables 防火墙要在云主机里手动放行 ICMPsudo iptables -I INPUT -p icmp --icmp-type echo-request -j ACCEPT。不然你在网络节点怎么抓包都看到回包但云主机就是 ping 不通。如果多次拉取镜像都很慢且云主机状态一直处于 ERROR先别查网络先查openstack server show vm-a的 fault 信息很多是镜像或规格问题不是网络问题。3.3 把外部网络接进来的常用做法外部网络External Network与租户网络不同它代表物理网络中已经存在的二层/三层网段。管理员创建外部网络时必须绑定物理接口或状态为 flat 的 provider比如openstack network create --provider-network-type flat \ --provider-physical-network physnet1 \ --external \ public-net openstack subnet create --network public-net \ --subnet-range 192.168.200.0/24 \ --no-dhcp \ --gateway 192.168.200.1 \ public-subnet注意 --external 标记是外部网络的门票没有这个标记L3 agent 不会允许路由器绑定它。--no-dhcp 是常见做法外部网络通常由物理路由器管理地址分配不需要 OpenStack 再派一个 DHCP agent。把租户路由器接上外部网络后默认会启用 SNAT内网云主机访问外网时源 IP 被转换成外部网络上的路由器接口 IP。这个转换对无状态服务很方便但外部主动访问内网仍然做不到需要浮动 IP。这一块放在下一章展开因为它的坑比 SNAT 多得多。如果你打算让租户子网直接绑定外部网络的 CIDR而不做 NAT可以采用--provider-network-type vlan加 --no-dhcp 的方式但这种模式下租户云主机的安全组将无法控制外部流量一般不建议在生产环境使用。最稳妥的做法还是租户网络加路由器加浮动 IP 的三层模型。现在你已经拥有一个可以内网互通、能出外网访问的租户环境了。这个最小网络就是所有 OpenStack 业务网络的基础。4. 安全组与浮动IP外网访问的配置顺序与常见坑4.1 安全组规则的默认行为与放行顺序安全组是 Neutron 在云主机网卡层面的防火墙。默认安全组规则是放行所有出站流量拒绝所有入站流量。所以创建云主机后你能从云主机主动 curl 外部但外部不能主动连回来。很多人第一次绑定浮动 IP 后就急着 ping发现不通其实就是没放行 ICMP 入站。安全组的判定逻辑是白名单只要有一条规则匹配并允许流量就通过了。规则顺序不重要但必须注意协议、端口、源地址的范围。常用命令# 放行 ICMP ping方便排错 openstack security group rule create --project admin \ --protocol icmp --ingress --ethertype IPv4 \ default # 放行 SSH 22 端口 openstack security group rule create --project admin \ --protocol tcp --dst-port 22 --ingress \ default注意 --dst-port 对入站规则而言是指目标端口如果漏掉 --ingress规则会被创建为出站放行的是云主机主动去访问 22 端口完全不是你想要的效果。我见过有人把出站规则当入站规则配了一晚上最后才发现参数写反。安全组还有项目归属问题。如果你用 admin 身份创建规则却加到了 default 组而云主机属于 demo 项目那这条规则根本不生效。所以创建云主机时显式指定--security-group优先于依赖默认组openstack server create ... --security-group default另外安全组规则的源地址也可以限制到特定网段实现类似 ACL 的效果。比如只允许办公网访问 22 端口openstack security group rule create --protocol tcp --dst-port 22 \ --remote-ip 192.168.1.0/24 --ingress default这样即使放行了 SSH其他源地址依然会被丢弃。这个方式比在云主机里配 iptables 更直观而且随网卡迁移自动生效是网络域隔离里很实用的一种补充手段。4.2 浮动IP绑定与 NAT 映射的底层逻辑浮动 IP 的本质是把外部网络地址池里的一个地址通过 NAT 一对一映射到云主机的私有地址。绑定动作发生在 Neutron 的 L3 agent 里它会在路由器命名空间建立 DNAT 规则外部来的包目的地如果是浮动 IP就改写为云主机私有 IP云主机发出的包源地址被改写为浮动 IP。这个过程完全透明。查看绑定细节的命令# 分配一个浮动 IP openstack floating ip create public-net # 绑定到云主机 vm-a openstack server add floating ip vm-a 浮动IP地址 # 查看路由器命名空间里的 NAT 规则 ip netns exec qrouter-demo-router iptables -t nat -L -v -n在 iptables 输出里你会看到 DNAT 和 SNAT 两条链。DNAT 链出现在 PREROUTINGSNAT 出现在 POSTROUTING。如果只看到 DNAT 没有 SNAT说明回程流量可能走的是默认路由浮动 IP 的映射会出奇怪的问题比如云主机可以收到包但自己发的包源地址仍是私有 IP。这时候检查云主机路由确保默认路由的网关是路由器接口 IP。想快速知道浮动IP到底绑在哪台实例上用openstack floating ip list会显示 Fixed IP Address 列。如果那列是空的说明浮动IP处于未绑定状态对应的 DNAT 规则还不存在。此时即使虚拟机内部防火墙全开外部也进不来。我经常看到有人在生产环境里分配了浮动IP结果忘了绑定业务方一直报“IP 不通”其实就是这一步。有一个冷门但真实的场景浮动 IP 绑定后云主机里ip addr看不到浮动 IP 地址。很多人以为失败了其实这是正常现象NAT 模式下浮动 IP 永远在路由器上云主机只感知私有 IP。如果你在云主机里直接配置浮动 IP反而会造成路由环路让它变成一台彻底断连的机器。4.3 典型配置顺序先绑定浮动IP还是先放安全组不少人问先绑定浮动 IP 还是先放安全组我的做法是先绑定再放安全组最后测试。理由是绑定操作只影响 NAT 层不会因为安全组没放行而回滚而先放安全组的话如果绑定后发现还是不通你又得怀疑是不是绑定有问题排错半径无谓变大。一整套可复现的顺序如下# 1. 确定外部网络 openstack network show public-net # 2. 分配并绑定浮动 IP FIP$(openstack floating ip create public-net -f value -c ip) openstack server add floating ip vm-a $FIP # 3. 放行 ICMP 和 SSH openstack security group rule create --protocol icmp --ingress default openstack security group rule create --protocol tcp --dst-port 22 --ingress default # 4. 测试外网访问 ping -c 3 $FIP第 4 步如果通了说明 NAT 和安全组两条链路都正常。如果你用 SSH 连接失败优先看云主机内部的 sshd 是否监听在 0.0.0.0因为有些镜像默认只监听内网 IP浮动 IP 转发过来的包会被系统拒绝。这种问题不在 Neutron却在云主机系统配置里容易让网络排查白忙一场。经验上遇到“浮动IP通了业务端口不通”的案子一半是安全组没放行一半是 sshd/应用监听地址错误。所以配置顺序只是基础最终判断还要靠nc -zv和抓包。5. Neutron 网络排错实战从网络命名空间到 tcpdump 抓包5.1 网络命名空间打开运维的第三只眼排错的第一原则确定流量在哪一跳断掉。OpenStack 的网络功能跑在内核的命名空间里每个租户路由器、每个 DHCP 服务都有独立命名空间。如果你的控制节点和网络节点没有隔离直接登录网络节点执行以下命令# 列出所有命名空间 ip netns list # 进入路由器命名空间查看路由表 ip netns exec qrouter-demo-router ip route # 进入 DHCP 命名空间查看地址池 ip netns exec qdhcp-demo-net ip addr命名空间里的 qr 接口是租户侧网关qg 是外部侧。进入命名空间后你等于站在路由器内部。这里最常见的问题是租户路由器的路由表里没有到外部网络的默认路由。原因是外部网关没有配置或者路由器没有 set --external-gateway。这时你可以在命名空间里补一条默认路由做临时验证ip netns exec qrouter-demo-router ip route add default via 192.168.200.1但这只是临时验证手段重启后失效。正确做法是重新执行openstack router set --external-gateway public-net。很多人临时改了之后物理环境一刷新又恢复原状就开始怀疑是 Agent 没同步其实只是没做持久化配置。除了路由表还要检查命名空间内的 ARP 表。如果 qr 接口没有学到云主机网卡的 MAC说明二层不通。这时候去云主机侧抓包看有没有 ARP request 和 reply。二层问题在 VXLAN 环境里尤其隐蔽因为外层封装会掩盖真正丢包的位置。另外如果你用的是 Open vSwitch 作为二层驱动命名空间里的接口可能不在 qrouter-xxx 里而是桥接到一个叫 br-int 的虚拟交换机上。这时需要ovs-vsctl show查看流表。流表内容晦涩但当你看到dl_dst或nw_dst出现异常时基本可以断定是同步问题。5.2 用 tcpdump 和 nc 快速定位丢包与不通判断丢包点最直接的方法是抓包。先确定流量要走通的关键节点云主机tap 接口→ 网桥 → 物理网卡或者云主机 → 路由器命名空间 → 外部网络。tcpdump 命令如下# 在路由器命名空间抓 ICMP 流量-n 不解析主机名 ip netns exec qrouter-demo-router tcpdump -i qr-demo-net icmp -n # 在 DHCP 命名空间抓 DHCP 请求 ip netns exec qdhcp-demo-net tcpdump -i tap-xxx port 67 or port 68 -n # 在计算节点抓云主机网卡的流量 tcpdump -i tap-另一侧端口 icmp -n如果你在路由器命名空间能看到入站的 ICMP 请求但看不到出站的 echo reply说明回程路由有问题多半是子网路由表缺失或路由器没有启用 IP forwarding。检查 /proc/sys/net/ipv4/ip_forward 是否为 1。除了 ICMP端口连通性用网络调试工具 nc 更快。比如要测试云主机 10.10.0.101 的 8080 端口通不通nc -zv 10.10.0.101 8080如果端口不通再用 tcpdump 看 SYN 包有没有到以及有没有回 RST。注意nc 测的是 TCP 握手如果你的服务监听在 127.0.0.1外部无论如何也连不上这不属于 Neutron 的问题。还有一个细节tcpdump 默认只显示外层 VXLAN 封装的包看不到里面的内层包。想看内层 IP需要加-v或者-e选项并用port 4789过滤。很多人在 VXLAN 环境里抓包发现全是 UDP 报文看不到 ICMP就以为丢了其实是滤镜不对。这是一个很容易被忽略的坑。tcpdump 还有一个实用技巧在 DHCP 排错时tcpdump -e -n可以打印出 MAC 地址方便你核对 DHCP 请求是否广播到了正确的物理网卡。MAC 对不上时往往是 dnsmasq 配置里忽略了某块网卡而不是报文丢失。网络协议分析的核心就在这里定位到具体命名空间、具体接口比对收到的包和发出的包就能把问题从“黑匣子”变成“看得见的路径”。我自己的习惯是每次排错先问自己三个问题源 IP 发出来了没有中间节点转发了没有目的主机回应了没有一个问题对应一段抓包很快就能缩小范围。5.3 避坑记录五个让网络工程师崩溃的现场现象一同一个 VXLAN 网络下两台云主机完全不通DHCP 也获取不到地址。原因创建网络时用了同样的 provider-segment 值但这个 VNI 在另一台计算节点的 agent 配置里对应了不同的物理网卡。解决确认所有计算节点的 /etc/neutron/plugins/ml2/openvswitch_agent.ini 中 bridge-mapping 一致VNI 分配用 Neutron 自动分配别手工硬编码。现象二浮动 IP 能 ping 通但 SSH 连接超时。原因安全组只放行了 ICMP没放行 TCP 22而 ICMP 和 TCP 是两套规则。解决补放行 22 端口用 nc -zv 验证。现象三删除网络时提示 Subnet in use。原因子网还被路由器接口占用OpenStack 不允许删除被引用的资源。解决先执行openstack router remove subnet demo-router demo-subnet再删除子网和网络。现象四云主机能拿到 IP但无法上网。原因路由器虽然绑定了外部网关但外部网络的子网没有设置网关导致 SNAT 找不到下一跳。解决在外部子网上设置 --gateway 192.168.200.1或检查物理路由器是否有到达外部网段的静态路由。现象五创建实例卡在 spawn state网络端口一直是 down。原因计算节点上的 neutron agent 没起来或者和消息队列断了连接。解决在计算节点执行systemctl status neutron-openvswitch-agent和openstack network agent list确认 agent 状态重启 agent 后端口通常立即恢复。这五条踩坑记录几乎覆盖了中性环境里 80% 的“网络玄学”。剩下的 20%往往要回到物理网络检查交换机的 trunk、VLAN 和网线。记得在动手之前先记录现场信息不然你找不到后悔药。我自己的习惯是每条排查至少保留openstack port list、ip netns list、ip route三个输出后续核对起来相当省时。6. 用 iperf 验证网络性能带宽测试与拓扑检查6.1 iperf 客户端与服务端的基本用法性能验证不是只有“通不通”还要看速率。iperf 是最常用的网络测速工具。在网络节点或一台云主机上启动服务端另一台跑客户端# 在云主机 vm-a 上启动服务端 iperf3 -s # 在云主机 vm-b 上跑客户端打流 30 秒4 条并发流 iperf3 -c 10.10.0.101 -t 30 -P 4输出里会显示实时的速率曲线以及最终的聚合带宽。如果测试结果远低于物理网卡速率先看是不是走了路由器做转发——同子网内 ping 是二层直通iperf 也应该是二层流量应该接近物理上限如果带宽腰斩多半是虚拟机宿主机上的虚拟网卡中断或网桥队列问题。改用 SSH 隧道测的话还要考虑加密开销。6.2 通过拓扑信息反查瓶颈带宽测试与网络域隔离测完速最好把拓扑信息一起留档。openstack network topology在较新版本里可以用命令行生成 JSON 格式的拓扑但更常见的是用openstack port list配合openstack server list反查每台实例的端口和网络归属openstack port list --server vm-a -f json结合 iperf 的结果你可以判断瓶颈在宿主机、物理链路还是网络节点。如果多个租户共享同一物理网络带宽被占满也属于网络域隔离设计不充分。合理的做法是把大流量业务放在独立 VLAN或者用 VXLAN 加 QoS 策略限制单租户带宽。6.3 最后的习惯每次变更前先拍快照最后分享一个我自己的习惯每次修改网络配置之前先保留一份可恢复的现场。用openstack network list -f json和openstack port list -f json导出当前状态并记录关键 agent 的版本和日志位置。遇到诡异问题优先看日志而不是猜。我吃过最大的亏是一次安全组规则变更后忘了导出原有规则导致服务大面积断连最后只能凭记忆慢慢补。从那以后所有变更都先备份再用最小范围验证。希望帮到你。本文还有配套的精品资源点击获取