简介这份 PDF 是《Learning OpenStack Networking第三版》的电子文档定位为 OpenStack 网络核心组件 Neutron 的实战精讲适合云计算工程师、网络架构师以及希望深入虚拟网络技术的进阶读者。资源以虚拟网络架构为主线系统讲解 SDN 原理、ML2 插件与 Open vSwitch 的集成应用并解读安全组规则设置、分布式路由工作机制以及 VLAN 感知虚拟机、BGP 动态路由等高阶功能。书中结合配置案例展示从网络模型规划、流量过滤到动态路由策略下发的完整路径帮助读者理解 Neutron 与底层网络技术的协同方式并能在实际部署中排查网络故障、优化性能。包体为 1 个 PDF 文件压缩包约 75.94MB便于离线阅读与检索已有 52 人参与学习。依托原书完整章节和目录结构读者可对照学习分布式路由与高级网络功能的实现细节也可将其中思路用于 OpenStack 云网络的建设与运维参考。 做OpenStack的人早晚会意识到整个平台里最复杂、最容易翻车的部分不是Nova的调度策略也不是Cinder的存储后端而是网络。Neutron的架构设计得足够抽象组件多、命名空间多、虚拟网桥也多任何一个环节没对齐表现就是虚拟机起不来、租户网络不通、浮动IP怎么都ping不出去。这篇“OpenStack网络实战精讲”我按自己在生产环境里排查和配置的经验来写从Neutron的核心组件讲起把Provider Network和Self-service Network的区别、VLAN与VXLAN的选型逻辑、MTU和命名空间的坑、常见故障的排查思路和命令都过一遍。适合已经会搭建OpenStack但网络部分一直靠“照着文档抄作业”的人也适合正准备做网络规划、想在动手之前把原理补上的运维同事。1. 从一张网络拓扑看懂OpenStack网络全景1.1 Neutron到底在管什么很多人把Neutron简单理解成“给虚拟机分配IP地址的组件”这个理解太浅了。Neutron管的是整个云平台里虚拟网络的完整生命周期租户能创建多少个网络、子网这些网络之间怎么隔离虚拟机通过哪个路由器到达外部网络安全组规则在哪里下发甚至DHCP服务、DNS和元数据服务也都是Neutron在背后用命名空间里的进程来干的。从实际流量角度理解会更清楚。一个虚拟机发给同网段另一个虚拟机的包会从计算节点的虚拟网卡tap设备进入Linux Bridge或者OVS网桥然后根据网桥上的VLAN或VXLAN规则封装在物理网络上传输。跨越网段的包会先被送到命名空间qrouter里的虚拟路由器Nova实例发出去的流量看默认网关实际上这个网关就是qrouter命名空间里的IP地址。而每个租户网络的DHCP服务是qdhcp命名空间里跑的dnsmasq进程在提供。所以说Neutron不是一个简单代理而是一套由网络节点或控制节点、计算节点、DHCP代理、L3代理、元数据代理、安全组驱动共同组成的分布式网络系统。理解了这个背景排障的时候才能知道问题出在哪一层是二层不通三层路由没起来还是DHCP没有响应1.2 Provider Network 与 Self-service Network 怎么选OpenStack里创建网络时最常见的迷惑点就是到底选Provider Network还是Self-service Network也叫项目网络或租户网络。我一直跟新人说这两个不是谁替代谁的关系而是使用场景和隔离级别的差异。Provider Network直接绑定物理网络把物理交换机上的VLAN或扁平网络直接映射给虚拟机。虚拟机的流量不经过虚拟路由器直接通过计算节点的物理网卡出去。优点是性能好、结构简单、排障容易缺点是它与物理网络的耦合太深IP地址和VLAN资源都得由网络管理员统一分配无法让租户自助创建。一般云平台里把公网段、业务物理段做成Provider Network供浮动IP和外部网络使用。Self-service Network则是租户可以自助创建的二层网络底层用VXLAN或GRE隧道实现隔离。租户创建的虚拟网络通过虚拟路由器连接到Provider Network从而访问外部网络。这种模式的灵活性很大一个租户可以建好几个完全隔离的子网不同租户之间即使使用相同的CIDR段隧道ID不同也不会串网。代价就是多了一层VXLAN封装对MTU要求高了性能比纯VLAN模式稍差。对比下来我的选择逻辑很直接只要允许租户自助创建网络就必须用Self-service Network内部测试环境没有多租户需求直接用Provider Network最省事。两者也可以共存外部网络走Provider租户内部网络走Self-service然后用路由器打通。1.3 Linux Bridge 与 OVS 如何取舍Neutron的mechanism driver主要就两种Linux Bridge和Open vSwitchOVS。网上很多教程默认用的Linux Bridge因为简单、稳定、好排查生产环境尤其是NFV或大规模虚拟化场景更多人倾向OVS。Linux Bridge的优势在于它没有引入额外的数据库和复杂逻辑就是内核自带的网桥功能。每个虚拟机的tap设备直接挂在网桥上VLAN用网桥的vlan filtering功能实现VXLAN则跑一个linuxbridge-agent来建立隧道。排障时用brctl或ip link命令就能看得很清楚出问题概率低。缺点是功能少很多高级流表能力、流量镜像、QoS策略做起来麻烦。OVS则是一个完整的虚拟交换机支持OpenFlow流表、细粒度QoS、sFlow/NetFlow流量监控、DPDK加速等。它的转发性能上限更高适合大规模场景和需要精细化流量控制的业务。但OVS的复杂度和故障排查成本明显更高一个流表乱了问题就非常隐蔽需要看ovs-vsctl和ovs-ofctl的输出。我个人的建议是如果你的团队刚接手OpenStack计算节点规模在几十台以内用途是内部研发或测试环境选Linux Bridge足够。如果要做高密度生产集群、有DPDK高性能网络需求或者要接SDN控制器优先OVS。两个驱动都有成熟的生产案例真正影响体验的是你对它们的熟练程度。2. 网络规划与配置文件里的关键参数2.1 控制节点和计算节点各管什么活儿很多人排障效率低是因为没搞清网络功能到底散落在哪些节点上。OpenStack中Neutron的各个Agent分布在控制节点和计算节点职责划分很明确。控制节点上跑的主要是neutron-server、neutron-l3-agent、neutron-metadata-agent、neutron-dhcp-agent根据部署形态可能是独立的网络节点。其中neutron-server是所有API请求的入口负责数据库交互和调度l3-agent负责虚拟路由器的创建和外部网络的路由dhcp-agent负责给每个租户网络分配qdhcp命名空间并启动dnsmasqmetadata-agent用来给虚拟机提供http://169.254.169.254的元数据服务。计算节点上跑的是二层代理如果你用linuxbridge机制那是neutron-linuxbridge-agent如果用OVS那是neutron-openvswitch-agent。另外每台计算节点上还运行着neutron-metering-agent之类的可选组件。安全组功能也由计算节点上的代理去调用底层iptables或OpenFlow规则实现。所以遇到网络不通的问题第一步一定是确认这个包在哪个节点上丢了。比如“虚拟机A ping网关不通”优先去计算节点上看qrouter命名空间是否存在再抓包看ARP有没有回应。如果直接在控制节点上找问题很可能白忙活。2.2 核心配置文件逐条解析以Linux Bridge VXLAN的典型配置为例有三份配置文件是必须吃透的。第一份是/etc/neutron/plugins/ml2/ml2_conf.ini全局的二层驱动和类型驱动都在这里[ml2] type_drivers flat,vlan,vxlan tenant_network_types vxlan mechanism_drivers linuxbridge [ml2_type_flat] flat_networks physnet1 [ml2_type_vlan] network_vlan_ranges physnet1:100:200 [ml2_type_vxlan] vni_ranges 1:1000这里tenant_network_types vxlan的意思是租户网络默认用VXLAN如果改成vlan租户网络会消耗物理交换机的VLAN资源一般不建议在大规模场景中这么干。flat_networks和network_vlan_ranges里的physnet1是物理网络名称必须和agent里的映射名称一致否则创建的网络会一直处于DOWN状态。第二份是/etc/neutron/plugins/ml2/linuxbridge_agent.ini[linux_bridge] physical_interface_mappings physnet1:eth0 [vxlan] enable_vxlan True local_ip 192.168.200.12 vxlan_group 239.1.1.1 [securitygroup] enable_security_group True firewall_driver neutron.agent.linux.iptables_firewall.NeutronIptablesFirewallDriverphysical_interface_mappings定义了网桥上的物理网络ens映射到哪个物理网卡必须和真实网卡一致。local_ip是隧道通信用的本机IP必须填写管理网或专用于VXLAN的IP。vxlan_group是组播地址如果底层交换机不支持组播可以去掉这个参数Neutron会通过L2 population机制在Agent之间同步MAC表一样能跑只是在网络规模很大时需要逻辑上的优化。第三份是控制节点上的/etc/neutron/l3_agent.ini和/etc/neutron/dhcp_agent.ini其中interface_driver要指定为linuxbridge或openvswitch必须与ml2里的mechanism_drivers保持一致否则路由和DHCP都起不来。配置完这些之后我还习惯检查一下/etc/sysctl.conf确保开启了内核IP转发net.ipv4.ip_forward1。很多新手在控制节点上配好了路由器但虚拟机还是不通外网查下来是IP转发没开。2.3 参数选择背后的原因VLAN、VXLAN与MTU的三角关系选择VLAN还是VXLAN不只是看功能列表更关键的是容量和传输限制。VLAN的理论数量上限是4096扣除保留的VLAN实际可用的大约在3000多个。而一个中型云平台的租户数量可能远超这个数字。VXLAN的VNI范围是1600万天然适合多租户隔离并且可以通过UDP/IP封装跨越三层网络不用依赖交换机上大范围的VLAN配置。所以只要底层的网络带宽和MTU支持生产环境我首选VXLAN。但是VXLAN有一个绕不开的问题隧道封装开销大。VXLAN的报文在原始二层帧外面加了一个50字节左右的UDP/IP头如果物理网络MTU是1500那虚拟机网卡上如果设置1500的MTU经过VXLAN封装后就会超过物理链路MTU导致需要分片很多协议栈处理里会表现成“能通但很慢”或者“大包不通、小包通”。因此配置VXLAN之前我通常会先设计好整条链路的MTU物理交换机到计算节点之间建议MTU调成1600或9000OpenStack虚拟机内部网卡MTU一般设置1450VXLAN场景或1500VLAN/Flat场景DHCP下发的MTU需要和网卡一致否则跨网段的TCP大包分段就会出问题。这个MTU不一致的问题是我在生产环境里遇到最多的“隐蔽故障”之一后面专门用一节讲排查方法。3. 实战从创建网络到虚拟机上网的全流程3.1 用命令创建一个可用的Provider网络在已经部署好的OpenStack环境里创建网络建议用OpenStack CLI一步步验证。先创建一个Provider网络供外部浮动IP使用openstack network create --provider-network-type flat --provider-physical-network physnet1 --external external_net openstack subnet create --network external_net --subnet-range 192.168.100.0/24 --gateway 192.168.100.1 --allocation-pool start192.168.100.100,end192.168.100.200 --ip-version 4 external_subnet这里有两个容易忽略的细节。第一--provider-physical-network physnet1不是随便填的它必须与linuxbridge_agent.ini中的physical_interface_mappings里的名称一致否则网络状态会显示为DOWN虚拟机无法接入。第二外部网络的子网不要和任何内部网络重叠否则路由器的下一跳会冲突这里出过的生产事故不在少数。创建之后用openstack network list去看状态如果ACTIVE说明二层通了。此时我建议在计算节点上执行ip link show可以看到对应的物理网卡被挂到了类似brqxxxxx的网桥上这个网桥名称和网络ID是关联的。3.2 租户网络、路由器和浮动IP的完整链路接下来创建一个租户用的Self-service网络。我一般用VXLAN类型CIDR用比较常见的10.0.1.0/24这种openstack network create tenant_net openstack subnet create --network tenant_net --subnet-range 10.0.1.0/24 --gateway 10.0.1.1 --dns-nameserver 8.8.8.8 tenant_subnet openstack router create router1 openstack router add subnet router1 tenant_subnet openstack router set router1 --external-gateway external_net这条链路创建完后云平台实际上做了这些事情在控制节点上创建了qrouter命名空间里面配了虚拟路由器的网关IP和到外部网络的路径在命名空间里设置了默认路由把租户子网的流量转发到外部网络DHCP代理针对tenant_net启动了dnsmasq进程给虚拟机分配IP。计算节点上的虚拟机和宿主机上会看到对应的qbr网桥和qvo/qvb虚拟网线。从Linux Bridge的内部视角看流量路径大致是虚拟机tap设备 - qbr - qvb/qvo对 - brq绑定物理网卡的网桥。这一步看不懂没关系后面排查时只要能根据ip netns list和brctl show来定位就够用。给虚拟机绑定浮动IP命令也非常简单openstack server add floating ip test_vm 192.168.100.100但要理解它干的事Neutron在外部网络子网中分配一个IP然后在qrouter命名空间里添加一条DNAT规则把外部目的地址192.168.100.100的流量转发到租户虚拟机10.0.1.x。所以排障时可以进入命名空间里看iptables规则ip netns exec qrouter-xxxx iptables -t nat -L -n3.3 三层网络连通性验证与抓包思路创建完网络之后我一般不做花哨的验证就是老老实实按三层来先确认命名空间存在ip netns list在控制节点上测试宿主机的连通性ping 10.0.1.1进入qrouter命名空间ping虚拟机IPip netns exec qrouter-xxxx ping 10.0.1.10从计算节点ping虚拟机的tap设备IP验证二层转发最后进入虚拟机ping外网看能通到哪个位置。如果中间某个环节断了用tcpdump定向抓包是效率最高的手段。比如虚拟机访问外部不通在计算节点上抓tcpdump -i brqXXXX icmp -nn -c 20可以看到ICMP请求有没有从虚拟机出来、有没有进入qrouter命名空间的路由。如果包到了brq但没有转发到物理网卡大概率是本机路由或命名空间内的iptables规则有问题如果包出了物理网卡但回包不进虚拟机就要看浮动IP对应的DNAT规则是否生效。4. 常见故障排查与经验4.1 虚拟机通但宿主机不通先查MTU这是我在生产集群里踩过最深的坑之一。现象很典型虚拟机ping网关通、ping同网段另一台虚拟机通但ping宿主机管理IP或外网大包时不通或者频繁丢包。用ping -M do -s 1472 外网IP测一下如果报“Frag needed”基本就是MTU问题。原因前面分析过VXLAN封装产生额外50字节如果物理网络MTU设为1500虚拟机网卡MTU也保持1500那么超过1450字节的数据包就会在物理链路上被分片部分网络设备直接丢弃。解决思路有三个调整层次物理交换机端口和计算节点网卡的MTU调成1600或9000VM网卡和DHCP下发的MTU调成1450确认OpenStack没有强制覆盖MTU参数dhcp_agent.ini里的dnsmasq_config_file或专用MTU配置。以后凡是遇到“大包不通、小包通”我的第一反应就是MTU而不是去看防火墙或路由表。这个问题在纯VLAN模式里几乎不会出现凡是用了VXLAN必须把MTU一致性刻在脑子里。4.2 dnsmasq和命名空间的小毛病OpenStack的DHCP服务通过dnsmasq实现每个租户网络一个qdhcp命名空间里面跑一个dnsmasq进程。常见问题主要有两个。一个是网络删不掉提示“has active DHCP port”这种现象其实是命名空间里还存有旧的进程或旧的port记录DHCP端口被lease占住。重启neutron-dhcp-agent并清理残留命名空间问题一般就能解决openstack network delete xxx ip netns del qdhcp-xxx systemctl restart neutron-dhcp-agent另一个是虚拟机启动后分配不到IP。先在控制节点上确认dnsmasq进程“ps aux | grep dnsmasq”再查看日志/var/log/neutron/dhcp-agent.log。很多时候是子网的--dhcp-option或自定义DNS配置格式错误导致dnsmasq启动失败。临时可以直接在qdhcp命名空间里手动启动一个dnsmasq来验证是否是配置问题ip netns exec qdhcp-xxx dnsmasq --no-daemon --log-queries如果想快速看某个子网实际下发的DHCP地址还可以查看/var/lib/neutron/dhcp/目录下的租约文件这个比查数据库更直观。4.3 安全组规则不生效大概率不是Neutron的问题安全组是Neutron在计算节点用iptables或OpenFlow规则实现的。如果你给虚拟机放行端口后还是不通先别急着怀疑安全组API很可能是计算节点的iptables规则没刷新或者链的顺序有问题。先看虚拟机对应的链nova list neutron port-show port_id拿到port_id之后在计算节点上执行iptables -L -n | grep port_id前缀安全组规则也是分层实现的有neutron-openvswi-i、neutron-openvswi-o这样的链。如果发现规则已经存在但流量还是不通行检查物理网络里是否有额外防火墙以及OVS/Linux Bridge的流表规则是否需要重定向。我曾经遇到过一次虚拟机安全组是空列表即全放行但业务端口依然不通最后发现是云平台外部的硬件防火墙拦截了VXLAN隧道的UDP端口默认8472/4789所以流量根本到不了计算节点。这种时候在租户网络内部怎么折腾都没有用还是得回到物理网络去验证。4.4 常用排查命令速查表把平时用得最频繁的几条命令整理一下关键时刻照着敲场景命令查看所有命名空间ip netns list查看路由和网桥brctl show、ip link show进入命名空间调试ip netns exec qrouter-xxx bash查看租户DHCP租约cat /var/lib/neutron/dhcp/*.conf抓虚拟机流量tcpdump -i tapXXXX -nn icmp查L3 agent状态openstack network agent list查VXLAN隧道状态ip -d link show vxlan-*查安全组规则iptables -L -n -v | grep port_id重启neutron组件systemctl restart neutron-linuxbridge-agent排障的时候我习惯从最远的地方往虚拟机方向查先确认物理网络通不通再查隧道通不通再查命名空间里的路由最后查虚拟机内部。每过一层就缩小一半范围比满世界找报错日志要快得多。另外一定要记住OpenStack网络层的问题不代表一定是Neutron配置的问题底层物理交换机和宿主机网卡的故障很难直接反映在OpenStack告警里最好一开始就建立宿主机的网络监控把丢包、重传、带宽占用这些基础指标盯起来。最后再分享一个很微小的经验给网络组件做任何变更之前先截一下openstack network agent list的状态记录下当前所有Agent是up还是down。很多“改完配置后网络彻底不通”的问题其实就是agent状态异常后所有请求都堆积在队列里重启后规则才逐渐补上。养成先看agent状态、再看日志、最后动手的习惯能帮你省下大量晚上值班的时间。本文还有配套的精品资源点击获取 OpenStack网络实战：Neutron架构、VXLAN与MTU排查指南
简介这份 PDF 是《Learning OpenStack Networking第三版》的电子文档定位为 OpenStack 网络核心组件 Neutron 的实战精讲适合云计算工程师、网络架构师以及希望深入虚拟网络技术的进阶读者。资源以虚拟网络架构为主线系统讲解 SDN 原理、ML2 插件与 Open vSwitch 的集成应用并解读安全组规则设置、分布式路由工作机制以及 VLAN 感知虚拟机、BGP 动态路由等高阶功能。书中结合配置案例展示从网络模型规划、流量过滤到动态路由策略下发的完整路径帮助读者理解 Neutron 与底层网络技术的协同方式并能在实际部署中排查网络故障、优化性能。包体为 1 个 PDF 文件压缩包约 75.94MB便于离线阅读与检索已有 52 人参与学习。依托原书完整章节和目录结构读者可对照学习分布式路由与高级网络功能的实现细节也可将其中思路用于 OpenStack 云网络的建设与运维参考。 做OpenStack的人早晚会意识到整个平台里最复杂、最容易翻车的部分不是Nova的调度策略也不是Cinder的存储后端而是网络。Neutron的架构设计得足够抽象组件多、命名空间多、虚拟网桥也多任何一个环节没对齐表现就是虚拟机起不来、租户网络不通、浮动IP怎么都ping不出去。这篇“OpenStack网络实战精讲”我按自己在生产环境里排查和配置的经验来写从Neutron的核心组件讲起把Provider Network和Self-service Network的区别、VLAN与VXLAN的选型逻辑、MTU和命名空间的坑、常见故障的排查思路和命令都过一遍。适合已经会搭建OpenStack但网络部分一直靠“照着文档抄作业”的人也适合正准备做网络规划、想在动手之前把原理补上的运维同事。1. 从一张网络拓扑看懂OpenStack网络全景1.1 Neutron到底在管什么很多人把Neutron简单理解成“给虚拟机分配IP地址的组件”这个理解太浅了。Neutron管的是整个云平台里虚拟网络的完整生命周期租户能创建多少个网络、子网这些网络之间怎么隔离虚拟机通过哪个路由器到达外部网络安全组规则在哪里下发甚至DHCP服务、DNS和元数据服务也都是Neutron在背后用命名空间里的进程来干的。从实际流量角度理解会更清楚。一个虚拟机发给同网段另一个虚拟机的包会从计算节点的虚拟网卡tap设备进入Linux Bridge或者OVS网桥然后根据网桥上的VLAN或VXLAN规则封装在物理网络上传输。跨越网段的包会先被送到命名空间qrouter里的虚拟路由器Nova实例发出去的流量看默认网关实际上这个网关就是qrouter命名空间里的IP地址。而每个租户网络的DHCP服务是qdhcp命名空间里跑的dnsmasq进程在提供。所以说Neutron不是一个简单代理而是一套由网络节点或控制节点、计算节点、DHCP代理、L3代理、元数据代理、安全组驱动共同组成的分布式网络系统。理解了这个背景排障的时候才能知道问题出在哪一层是二层不通三层路由没起来还是DHCP没有响应1.2 Provider Network 与 Self-service Network 怎么选OpenStack里创建网络时最常见的迷惑点就是到底选Provider Network还是Self-service Network也叫项目网络或租户网络。我一直跟新人说这两个不是谁替代谁的关系而是使用场景和隔离级别的差异。Provider Network直接绑定物理网络把物理交换机上的VLAN或扁平网络直接映射给虚拟机。虚拟机的流量不经过虚拟路由器直接通过计算节点的物理网卡出去。优点是性能好、结构简单、排障容易缺点是它与物理网络的耦合太深IP地址和VLAN资源都得由网络管理员统一分配无法让租户自助创建。一般云平台里把公网段、业务物理段做成Provider Network供浮动IP和外部网络使用。Self-service Network则是租户可以自助创建的二层网络底层用VXLAN或GRE隧道实现隔离。租户创建的虚拟网络通过虚拟路由器连接到Provider Network从而访问外部网络。这种模式的灵活性很大一个租户可以建好几个完全隔离的子网不同租户之间即使使用相同的CIDR段隧道ID不同也不会串网。代价就是多了一层VXLAN封装对MTU要求高了性能比纯VLAN模式稍差。对比下来我的选择逻辑很直接只要允许租户自助创建网络就必须用Self-service Network内部测试环境没有多租户需求直接用Provider Network最省事。两者也可以共存外部网络走Provider租户内部网络走Self-service然后用路由器打通。1.3 Linux Bridge 与 OVS 如何取舍Neutron的mechanism driver主要就两种Linux Bridge和Open vSwitchOVS。网上很多教程默认用的Linux Bridge因为简单、稳定、好排查生产环境尤其是NFV或大规模虚拟化场景更多人倾向OVS。Linux Bridge的优势在于它没有引入额外的数据库和复杂逻辑就是内核自带的网桥功能。每个虚拟机的tap设备直接挂在网桥上VLAN用网桥的vlan filtering功能实现VXLAN则跑一个linuxbridge-agent来建立隧道。排障时用brctl或ip link命令就能看得很清楚出问题概率低。缺点是功能少很多高级流表能力、流量镜像、QoS策略做起来麻烦。OVS则是一个完整的虚拟交换机支持OpenFlow流表、细粒度QoS、sFlow/NetFlow流量监控、DPDK加速等。它的转发性能上限更高适合大规模场景和需要精细化流量控制的业务。但OVS的复杂度和故障排查成本明显更高一个流表乱了问题就非常隐蔽需要看ovs-vsctl和ovs-ofctl的输出。我个人的建议是如果你的团队刚接手OpenStack计算节点规模在几十台以内用途是内部研发或测试环境选Linux Bridge足够。如果要做高密度生产集群、有DPDK高性能网络需求或者要接SDN控制器优先OVS。两个驱动都有成熟的生产案例真正影响体验的是你对它们的熟练程度。2. 网络规划与配置文件里的关键参数2.1 控制节点和计算节点各管什么活儿很多人排障效率低是因为没搞清网络功能到底散落在哪些节点上。OpenStack中Neutron的各个Agent分布在控制节点和计算节点职责划分很明确。控制节点上跑的主要是neutron-server、neutron-l3-agent、neutron-metadata-agent、neutron-dhcp-agent根据部署形态可能是独立的网络节点。其中neutron-server是所有API请求的入口负责数据库交互和调度l3-agent负责虚拟路由器的创建和外部网络的路由dhcp-agent负责给每个租户网络分配qdhcp命名空间并启动dnsmasqmetadata-agent用来给虚拟机提供http://169.254.169.254的元数据服务。计算节点上跑的是二层代理如果你用linuxbridge机制那是neutron-linuxbridge-agent如果用OVS那是neutron-openvswitch-agent。另外每台计算节点上还运行着neutron-metering-agent之类的可选组件。安全组功能也由计算节点上的代理去调用底层iptables或OpenFlow规则实现。所以遇到网络不通的问题第一步一定是确认这个包在哪个节点上丢了。比如“虚拟机A ping网关不通”优先去计算节点上看qrouter命名空间是否存在再抓包看ARP有没有回应。如果直接在控制节点上找问题很可能白忙活。2.2 核心配置文件逐条解析以Linux Bridge VXLAN的典型配置为例有三份配置文件是必须吃透的。第一份是/etc/neutron/plugins/ml2/ml2_conf.ini全局的二层驱动和类型驱动都在这里[ml2] type_drivers flat,vlan,vxlan tenant_network_types vxlan mechanism_drivers linuxbridge [ml2_type_flat] flat_networks physnet1 [ml2_type_vlan] network_vlan_ranges physnet1:100:200 [ml2_type_vxlan] vni_ranges 1:1000这里tenant_network_types vxlan的意思是租户网络默认用VXLAN如果改成vlan租户网络会消耗物理交换机的VLAN资源一般不建议在大规模场景中这么干。flat_networks和network_vlan_ranges里的physnet1是物理网络名称必须和agent里的映射名称一致否则创建的网络会一直处于DOWN状态。第二份是/etc/neutron/plugins/ml2/linuxbridge_agent.ini[linux_bridge] physical_interface_mappings physnet1:eth0 [vxlan] enable_vxlan True local_ip 192.168.200.12 vxlan_group 239.1.1.1 [securitygroup] enable_security_group True firewall_driver neutron.agent.linux.iptables_firewall.NeutronIptablesFirewallDriverphysical_interface_mappings定义了网桥上的物理网络ens映射到哪个物理网卡必须和真实网卡一致。local_ip是隧道通信用的本机IP必须填写管理网或专用于VXLAN的IP。vxlan_group是组播地址如果底层交换机不支持组播可以去掉这个参数Neutron会通过L2 population机制在Agent之间同步MAC表一样能跑只是在网络规模很大时需要逻辑上的优化。第三份是控制节点上的/etc/neutron/l3_agent.ini和/etc/neutron/dhcp_agent.ini其中interface_driver要指定为linuxbridge或openvswitch必须与ml2里的mechanism_drivers保持一致否则路由和DHCP都起不来。配置完这些之后我还习惯检查一下/etc/sysctl.conf确保开启了内核IP转发net.ipv4.ip_forward1。很多新手在控制节点上配好了路由器但虚拟机还是不通外网查下来是IP转发没开。2.3 参数选择背后的原因VLAN、VXLAN与MTU的三角关系选择VLAN还是VXLAN不只是看功能列表更关键的是容量和传输限制。VLAN的理论数量上限是4096扣除保留的VLAN实际可用的大约在3000多个。而一个中型云平台的租户数量可能远超这个数字。VXLAN的VNI范围是1600万天然适合多租户隔离并且可以通过UDP/IP封装跨越三层网络不用依赖交换机上大范围的VLAN配置。所以只要底层的网络带宽和MTU支持生产环境我首选VXLAN。但是VXLAN有一个绕不开的问题隧道封装开销大。VXLAN的报文在原始二层帧外面加了一个50字节左右的UDP/IP头如果物理网络MTU是1500那虚拟机网卡上如果设置1500的MTU经过VXLAN封装后就会超过物理链路MTU导致需要分片很多协议栈处理里会表现成“能通但很慢”或者“大包不通、小包通”。因此配置VXLAN之前我通常会先设计好整条链路的MTU物理交换机到计算节点之间建议MTU调成1600或9000OpenStack虚拟机内部网卡MTU一般设置1450VXLAN场景或1500VLAN/Flat场景DHCP下发的MTU需要和网卡一致否则跨网段的TCP大包分段就会出问题。这个MTU不一致的问题是我在生产环境里遇到最多的“隐蔽故障”之一后面专门用一节讲排查方法。3. 实战从创建网络到虚拟机上网的全流程3.1 用命令创建一个可用的Provider网络在已经部署好的OpenStack环境里创建网络建议用OpenStack CLI一步步验证。先创建一个Provider网络供外部浮动IP使用openstack network create --provider-network-type flat --provider-physical-network physnet1 --external external_net openstack subnet create --network external_net --subnet-range 192.168.100.0/24 --gateway 192.168.100.1 --allocation-pool start192.168.100.100,end192.168.100.200 --ip-version 4 external_subnet这里有两个容易忽略的细节。第一--provider-physical-network physnet1不是随便填的它必须与linuxbridge_agent.ini中的physical_interface_mappings里的名称一致否则网络状态会显示为DOWN虚拟机无法接入。第二外部网络的子网不要和任何内部网络重叠否则路由器的下一跳会冲突这里出过的生产事故不在少数。创建之后用openstack network list去看状态如果ACTIVE说明二层通了。此时我建议在计算节点上执行ip link show可以看到对应的物理网卡被挂到了类似brqxxxxx的网桥上这个网桥名称和网络ID是关联的。3.2 租户网络、路由器和浮动IP的完整链路接下来创建一个租户用的Self-service网络。我一般用VXLAN类型CIDR用比较常见的10.0.1.0/24这种openstack network create tenant_net openstack subnet create --network tenant_net --subnet-range 10.0.1.0/24 --gateway 10.0.1.1 --dns-nameserver 8.8.8.8 tenant_subnet openstack router create router1 openstack router add subnet router1 tenant_subnet openstack router set router1 --external-gateway external_net这条链路创建完后云平台实际上做了这些事情在控制节点上创建了qrouter命名空间里面配了虚拟路由器的网关IP和到外部网络的路径在命名空间里设置了默认路由把租户子网的流量转发到外部网络DHCP代理针对tenant_net启动了dnsmasq进程给虚拟机分配IP。计算节点上的虚拟机和宿主机上会看到对应的qbr网桥和qvo/qvb虚拟网线。从Linux Bridge的内部视角看流量路径大致是虚拟机tap设备 - qbr - qvb/qvo对 - brq绑定物理网卡的网桥。这一步看不懂没关系后面排查时只要能根据ip netns list和brctl show来定位就够用。给虚拟机绑定浮动IP命令也非常简单openstack server add floating ip test_vm 192.168.100.100但要理解它干的事Neutron在外部网络子网中分配一个IP然后在qrouter命名空间里添加一条DNAT规则把外部目的地址192.168.100.100的流量转发到租户虚拟机10.0.1.x。所以排障时可以进入命名空间里看iptables规则ip netns exec qrouter-xxxx iptables -t nat -L -n3.3 三层网络连通性验证与抓包思路创建完网络之后我一般不做花哨的验证就是老老实实按三层来先确认命名空间存在ip netns list在控制节点上测试宿主机的连通性ping 10.0.1.1进入qrouter命名空间ping虚拟机IPip netns exec qrouter-xxxx ping 10.0.1.10从计算节点ping虚拟机的tap设备IP验证二层转发最后进入虚拟机ping外网看能通到哪个位置。如果中间某个环节断了用tcpdump定向抓包是效率最高的手段。比如虚拟机访问外部不通在计算节点上抓tcpdump -i brqXXXX icmp -nn -c 20可以看到ICMP请求有没有从虚拟机出来、有没有进入qrouter命名空间的路由。如果包到了brq但没有转发到物理网卡大概率是本机路由或命名空间内的iptables规则有问题如果包出了物理网卡但回包不进虚拟机就要看浮动IP对应的DNAT规则是否生效。4. 常见故障排查与经验4.1 虚拟机通但宿主机不通先查MTU这是我在生产集群里踩过最深的坑之一。现象很典型虚拟机ping网关通、ping同网段另一台虚拟机通但ping宿主机管理IP或外网大包时不通或者频繁丢包。用ping -M do -s 1472 外网IP测一下如果报“Frag needed”基本就是MTU问题。原因前面分析过VXLAN封装产生额外50字节如果物理网络MTU设为1500虚拟机网卡MTU也保持1500那么超过1450字节的数据包就会在物理链路上被分片部分网络设备直接丢弃。解决思路有三个调整层次物理交换机端口和计算节点网卡的MTU调成1600或9000VM网卡和DHCP下发的MTU调成1450确认OpenStack没有强制覆盖MTU参数dhcp_agent.ini里的dnsmasq_config_file或专用MTU配置。以后凡是遇到“大包不通、小包通”我的第一反应就是MTU而不是去看防火墙或路由表。这个问题在纯VLAN模式里几乎不会出现凡是用了VXLAN必须把MTU一致性刻在脑子里。4.2 dnsmasq和命名空间的小毛病OpenStack的DHCP服务通过dnsmasq实现每个租户网络一个qdhcp命名空间里面跑一个dnsmasq进程。常见问题主要有两个。一个是网络删不掉提示“has active DHCP port”这种现象其实是命名空间里还存有旧的进程或旧的port记录DHCP端口被lease占住。重启neutron-dhcp-agent并清理残留命名空间问题一般就能解决openstack network delete xxx ip netns del qdhcp-xxx systemctl restart neutron-dhcp-agent另一个是虚拟机启动后分配不到IP。先在控制节点上确认dnsmasq进程“ps aux | grep dnsmasq”再查看日志/var/log/neutron/dhcp-agent.log。很多时候是子网的--dhcp-option或自定义DNS配置格式错误导致dnsmasq启动失败。临时可以直接在qdhcp命名空间里手动启动一个dnsmasq来验证是否是配置问题ip netns exec qdhcp-xxx dnsmasq --no-daemon --log-queries如果想快速看某个子网实际下发的DHCP地址还可以查看/var/lib/neutron/dhcp/目录下的租约文件这个比查数据库更直观。4.3 安全组规则不生效大概率不是Neutron的问题安全组是Neutron在计算节点用iptables或OpenFlow规则实现的。如果你给虚拟机放行端口后还是不通先别急着怀疑安全组API很可能是计算节点的iptables规则没刷新或者链的顺序有问题。先看虚拟机对应的链nova list neutron port-show port_id拿到port_id之后在计算节点上执行iptables -L -n | grep port_id前缀安全组规则也是分层实现的有neutron-openvswi-i、neutron-openvswi-o这样的链。如果发现规则已经存在但流量还是不通行检查物理网络里是否有额外防火墙以及OVS/Linux Bridge的流表规则是否需要重定向。我曾经遇到过一次虚拟机安全组是空列表即全放行但业务端口依然不通最后发现是云平台外部的硬件防火墙拦截了VXLAN隧道的UDP端口默认8472/4789所以流量根本到不了计算节点。这种时候在租户网络内部怎么折腾都没有用还是得回到物理网络去验证。4.4 常用排查命令速查表把平时用得最频繁的几条命令整理一下关键时刻照着敲场景命令查看所有命名空间ip netns list查看路由和网桥brctl show、ip link show进入命名空间调试ip netns exec qrouter-xxx bash查看租户DHCP租约cat /var/lib/neutron/dhcp/*.conf抓虚拟机流量tcpdump -i tapXXXX -nn icmp查L3 agent状态openstack network agent list查VXLAN隧道状态ip -d link show vxlan-*查安全组规则iptables -L -n -v | grep port_id重启neutron组件systemctl restart neutron-linuxbridge-agent排障的时候我习惯从最远的地方往虚拟机方向查先确认物理网络通不通再查隧道通不通再查命名空间里的路由最后查虚拟机内部。每过一层就缩小一半范围比满世界找报错日志要快得多。另外一定要记住OpenStack网络层的问题不代表一定是Neutron配置的问题底层物理交换机和宿主机网卡的故障很难直接反映在OpenStack告警里最好一开始就建立宿主机的网络监控把丢包、重传、带宽占用这些基础指标盯起来。最后再分享一个很微小的经验给网络组件做任何变更之前先截一下openstack network agent list的状态记录下当前所有Agent是up还是down。很多“改完配置后网络彻底不通”的问题其实就是agent状态异常后所有请求都堆积在队列里重启后规则才逐渐补上。养成先看agent状态、再看日志、最后动手的习惯能帮你省下大量晚上值班的时间。本文还有配套的精品资源点击获取