OpenStack Neutron网络服务部署与排错实战指南 1. 项目概述这不是第七次练习而是OpenStack网络服务的临门一脚“云计算实训 七”这个标题看起来平平无奇像极了高校实验课手册里被翻得卷了边的一页。但如果你正卡在Neutron服务启动失败、虚拟机ping不通网关、或者Keystone token总提示过期的深夜就会明白——这“第七”不是序号是压垮骆驼的最后一根稻草也是真正看懂OpenStack网络脉络的转折点。我带过三届云计算方向的学生也给五家中小企业的运维团队做过OpenStack落地支持几乎所有人都是在“实训七”前后突然开窍原来Neutron不是一堆配置文件的堆砌而是一张可编程的逻辑网络Keystone不只是登录框背后的密码校验器而是整个云平台的身份中枢神经MariaDB也不仅是存点表的数据库它是所有服务状态同步的唯一真相源。本项目核心就是围绕Neutron服务的完整部署与排错闭环以CentOS 7.9为基线环境这是当前企业生产环境中最稳定、兼容性最好的OpenStack Queens/Train版本载体串联Keystone认证流、MariaDB高可用存储、以及Neutron L2/L3代理的协同工作机制。它不教你怎么点鼠标装图形界面而是让你亲手敲出neutron-server启动日志里那行关键的INFO neutron.server.wsgi [req-...] Starting neutron-server并真正理解每个字符背后的服务依赖关系。适合两类人一是正在备考山东大学云计算期末、需要把“手把手教你搭建OpenStack”从口号变成肌肉记忆的在校生二是刚接手公司OpenStack私有云、面对openstack server list返回空列表却不知从何查起的初级运维工程师。你不需要背下所有API参数但必须能看懂journalctl -u neutron-server -n 50输出里哪一行暴露了Keystone endpoint配置错误哪一行暗示了MariaDB连接池耗尽——这才是“实训七”的真实价值。2. 整体设计思路为什么必须用NeutronKeystoneMariaDB铁三角组合2.1 不选Nova-network不碰OVS-DPDK回归OpenStack网络本质很多人一上来就想搞“高大上”直接上OVS-DPDK加速、玩Neutron SR-IOV直通、甚至折腾OVN替代Neutron。这就像学骑自行车先研究碳纤维车架力学——方向错了。OpenStack官方早在2016年就将Nova-network标记为Deprecated2018年彻底移除。而DPDK和SR-IOV属于性能优化层建立在Neutron基础网络功能完全跑通的前提下。我们坚持用最经典的“Linux Bridge Neutron Server ML2 Plugin”组合原因很实在第一故障面最小。Linux Bridge是内核原生模块没有额外依赖brctl show命令就能直观看到网桥、端口、MAC表排查qbr-xxx网桥缺失比调试DPDK用户态驱动快十倍第二教学穿透力最强。当你在/etc/neutron/plugins/ml2/ml2_conf.ini里把type_drivers flat,vlan改成type_drivers flat,vlan,gre,vxlan再重启服务neutron net-list输出里立刻多出vxlan网络类型——这种即时反馈是理解SDN抽象层最有效的路径第三企业环境适配度最高。据我参与的12个私有云项目统计73%的生产环境仍采用ML2Linux Bridge或OVS而非激进的新技术栈。所以“实训七”的设计底线是所有操作必须能在一台8G内存、4核CPU的物理服务器上完成不依赖GPU、不强制要求万兆网卡用最朴素的硬件验证最核心的逻辑。2.2 Keystone不是摆设而是Neutron服务调用的“数字身份证”校验站很多初学者把Keystone当成登录OpenStack Dashboard的“大门”装完就扔在脑后。但Neutron服务启动时第一件事就是向Keystone申请一个admin token用于后续所有API调用。如果Keystone的[token]段配置了provider fernet而你没运行keystone-manage fernet_setup --keystone-user keystone --keystone-group keystoneneutron-server会卡在Loading identity configuration阶段日志里反复出现Unable to establish connection to http://controller:5000/v3。这不是网络不通是Keystone根本没生成有效的token密钥环。更隐蔽的是endpoint配置openstack endpoint create --region RegionOne network public http://controller:9696这条命令表面看只是注册一个URL实则在MariaDB的endpoint表里插入一条记录Neutron客户端通过openstack network list发起请求时会先查这张表获取服务地址再用Keystone颁发的token去访问。如果endpoint的interface字段填错比如public写成internal或者url协议写成https而Keystone实际只监听http整个网络服务就变成一座孤岛。我在山东大学带实训时有学生花三天调试Neutron最后发现只是openstack endpoint create命令少敲了一个--interface public参数——这就是Keystone作为身份中枢不可绕过的铁律。2.3 MariaDB不是数据仓库而是Neutron状态同步的“单点真相源”把MariaDB当成普通数据库是个致命误区。在OpenStack中MariaDB承担着远超存储的功能它是所有服务状态的唯一权威来源。举个典型场景当执行openstack router add subnet router1 subnet1时Neutron-server进程会先在MariaDB的routers表里更新status ACTIVE再调用L3 agent在计算节点创建qrouter-xxx命名空间。如果此时L3 agent因网络问题未收到消息neutron router-show router1仍会显示ACTIVE因为状态以数据库为准。但若你手动修改MariaDB里routers.status为ERROR再重启Neutron-server服务会自动触发状态修复流程尝试重新同步。这就是为什么“实训七”必须包含MariaDB的等保测评级加固mysql_secure_installation不能跳过GRANT ALL PRIVILEGES ON neutron.* TO neutronlocalhost IDENTIFIED BY NEUTRON_DBPASS;里的localhost必须严格匹配Neutron配置文件中的connection mysqlpymysql://neutron:NEUTRON_DBPASScontroller/neutron否则会出现Access denied for user neutron127.0.0.1——注意localhost和127.0.0.1在MariaDB权限体系里是两个完全不同的主机名。我见过最离谱的案例某企业运维为图省事在my.cnf里加了bind-address 0.0.0.0结果Neutron连库时解析controller主机名得到的是服务器外网IPMariaDB权限表里只有neutronlocalhost导致所有网络操作全部失败。所以“实训七”的MariaDB环节核心不是“能不能连上”而是“连上的方式是否符合OpenStack服务间通信的精确语义”。3. 核心细节解析Neutron服务启动失败的五大高频死穴3.1 死穴一ML2插件配置中mechanism_drivers与type_drivers的隐式耦合/etc/neutron/plugins/ml2/ml2_conf.ini是Neutron的“心脏起搏器”但其中mechanism_drivers和type_drivers的配置存在强耦合官方文档却语焉不详。例如当你设置type_drivers flat,vlan,gre就必须在mechanism_drivers中至少包含一个能处理GRE的驱动如openvswitch或linuxbridge。如果只写mechanism_drivers linuxbridge而type_drivers里有greNeutron-server启动时会报错Mechanism driver linuxbridge does not support type gre。更隐蔽的是flat网络的flat_networks参数flat_networks *表示允许所有物理网卡作为flat网络载体但若你的服务器网卡名是ens33而非eth0而linuxbridge插件默认只认eth*前缀就必须在/etc/neutron/plugins/ml2/linuxbridge_agent.ini里显式配置physical_interface_mappings physnet1:ens33。我实测过漏掉这个映射创建flat网络时看似成功但虚拟机启动后根本无法获取IP因为DHCP请求发到了不存在的br-eth0网桥上。解决方案是启动前用ip link show确认物理网卡名再严格对应配置。这个细节在“手把手教你搭建OpenStack”类教程里常被忽略却是导致“虚拟机挂起后无法恢复网络”的根源之一——挂起时网桥状态被冻结恢复时因映射缺失无法重建。3.2 死穴二Keystone认证配置中auth_url与auth_type的版本陷阱Neutron服务端neutron-server和客户端openstack命令的Keystone认证配置必须严格对齐否则会出现“服务端能启客户端调不通”的诡异现象。关键在/etc/neutron/neutron.conf的[DEFAULT]段auth_strategy keystone只是声明启用Keystone认证真正的连接参数在[keystone_authtoken]段。这里有个经典坑auth_url http://controller:5000/v3必须带/v3后缀如果写成http://controller:5000Neutron会尝试用v2 API而现代OpenStack默认只启用v3。更致命的是auth_type参数——在Queens及以后版本必须显式设置auth_type password否则会报No auth_type found in config。这个参数在旧版教程里不存在但新版本已成强制项。我帮一家物流公司排查时发现他们沿用CentOS 6.5脚本安装的OpenStackneutron.conf里完全没有auth_type导致所有neutron net-create命令返回HTTP 401 Unauthorized而journalctl -u neutron-server日志里只有一行模糊的Invalid credentials。解决方法是先用openstack --os-identity-api-version 3 --os-auth-url http://controller:5000/v3 token issue手动测试Keystone连通性确认token能正常颁发再将该命令中的参数精准复制到neutron.conf对应位置。记住openstack客户端的--os-*参数就是neutron.conf里[keystone_authtoken]段的映射字典。3.3 死穴三L3代理配置中interface_driver与external_network_bridge的物理网卡绑定Neutron L3 agent负责实现路由器、浮动IP、SNAT/DNAT等功能其配置文件/etc/neutron/l3_agent.ini有两个参数极易出错。首先是interface_driver如果使用Linux Bridge必须设为neutron.agent.linux.interface.BridgeInterfaceDriver如果用OVS则是neutron.agent.linux.interface.OVSInterfaceDriver。设错会导致neutron-l3-agent服务启动失败日志报No module named neutron.agent.linux.interface.OVSInterfaceDriver。其次是external_network_bridge这个参数值不是网桥名而是物理网卡名。例如你的服务器外网接口是ens33那么这里必须写external_network_bridge ens33留空则表示使用默认网桥br-ex。很多教程写成external_network_bridge br-ex这是错误的——br-ex是L3 agent自己创建的网桥external_network_bridge的作用是指定哪个物理接口要接入这个网桥。如果填错创建外部网络时会提示No valid host was found因为L3 agent找不到可绑定的物理出口。我在龙溪的一次现场支持中客户服务器有两块网卡ens33(内网)和ens34(外网)他们把external_network_bridge设为ens33结果所有浮动IP都绑到了内网公有云业务全瘫。修正后ip addr show br-ex立刻显示出ens34的IP问题迎刃而解。3.4 死穴四DHCP代理配置中dnsmasq_config_file的权限与路径硬编码Neutron DHCP agent通过dnsmasq为租户网络提供DHCP服务其配置文件/etc/neutron/dhcp_agent.ini中的dnsmasq_config_file参数指向自定义dnsmasq配置。常见错误是第一路径写成绝对路径/etc/neutron/dnsmasq-neutron.conf但实际文件放在/var/lib/neutron/dhcp/下由agent动态生成第二忘记给/var/lib/neutron目录赋予neutron用户读写权限导致agent无法创建dnsmasq.conf文件日志报Permission denied: /var/lib/neutron/dhcp/...。更隐蔽的是dnsmasq本身的配置默认/etc/dnsmasq.conf可能启用了bind-interfaces这会让dnsmasq只监听lo回环接口拒绝来自qdhcp-xxx命名空间的DHCP请求。解决方案是创建/etc/neutron/dnsmasq-neutron.conf内容仅两行dhcp-option-force26,1400设置MTU和no-hosts禁用hosts文件然后在dhcp_agent.ini中指定dnsmasq_config_file /etc/neutron/dnsmasq-neutron.conf并确保/etc/neutron/目录属主为neutron:neutron。这个细节直接决定虚拟机能否自动获取IP——我经手的案例中35%的“虚拟机无法上网”问题根源都在dnsmasq配置的权限或绑定策略上。3.5 死穴五防火墙与SELinux对Neutron服务端口的静默拦截CentOS 7默认启用firewalld和SELinux它们对Neutron是“温柔的杀手”。firewalld会拦截neutron-server监听的9696端口导致curl http://controller:9696返回Connection refused但systemctl status neutron-server却显示active (running)。这是因为服务进程在本地启动成功但外部请求被防火墙丢弃。解决方案不是关闭firewalld而是精准放行firewall-cmd --permanent --add-port9696/tcp firewall-cmd --reload。SELinux的问题更隐蔽它会阻止neutron-server进程连接MariaDB的socket文件。现象是neutron-server启动后立即退出journalctl -u neutron-server显示Permission denied但mysql -u neutron -pNEUTRON_DBPASS -h localhost neutron命令却能连上。这是因为SELinux的mysqld_connect_any布尔值默认为off。执行setsebool -P mysqld_connect_any on即可修复。我在山东大学云计算期末考前辅导时专门用sestatus -v命令演示SELinux如何拦截Neutron让学生亲眼看到avc: denied日志比讲一百遍理论都管用。记住OpenStack不是在裸机上跑而是在一个安全加固的操作系统上跑忽视firewalld和SELinux等于在防弹衣上剪了个洞。4. 实操过程详解从零部署Neutron服务的十二步血泪清单4.1 第一步环境初始化——用packstack快速构建OpenStack基座别被“手把手教你搭建OpenStack”的标题吓住生产环境不用从零编译。packstack是RDO项目提供的自动化部署工具专为CentOS/RHEL设计能一键生成answer-file.txt并完成Keystone、Glance、Nova等核心服务安装。“实训七”的起点不是空白服务器而是packstack --allinone后的半成品环境。执行packstack --gen-answer-fileanswers.txt生成应答文件然后编辑answers.txt重点修改三处CONFIG_NEUTRON_INSTALLy启用Neutron、CONFIG_NEUTRON_SERVER_HOST192.168.1.10设为controller IP、CONFIG_NEUTRON_L3_HOSTS192.168.1.10L3 agent也部署在controller。保存后运行packstack --answer-fileanswers.txt。整个过程约25分钟期间你会看到Installing:后面跟着keystone,glance,nova,neutron等服务名滚动。packstack的妙处在于它自动处理了90%的依赖冲突比如自动安装python2-neutronclient、配置/etc/httpd/conf.d/15-neutron_v2_0.conf、甚至生成fernet密钥环。我对比过纯手工部署packstack节省的时间足够你把Neutron网络模型画三遍拓扑图。但注意packstack生成的配置是“能用”不是“最优”后续所有Neutron深度配置都要基于它生成的文件进行二次精调。4.2 第二步Keystone深度加固——从fernet密钥轮转到endpoint精准注册packstack安装后Keystone虽已运行但fernet密钥是临时生成的必须手动轮转以满足等保要求。首先停止Keystone服务systemctl stop openstack-keystone。然后执行密钥轮转keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone keystone-manage credential_setup --keystone-user keystone --keystone-group keystone。这两条命令会在/etc/keystone/fernet-keys/下生成密钥文件并在MariaDB的credential表里存入加密凭据。接着用keystone-manage db_sync同步数据库模式。最关键的一步是endpoint注册openstack endpoint create --region RegionOne identity public http://controller:5000/v3openstack endpoint create --region RegionOne identity internal http://controller:5000/v3openstack endpoint create --region RegionOne identity admin http://controller:35357/v3。注意adminendpoint必须用35357端口旧版或5000/v3新版且interface必须区分public/internal/admin。我见过最惨的案例某学生把三个endpoint的interface全设为public结果openstack token issue能成功但neutron net-list始终报The request you have made requires authentication——因为Neutron客户端默认用internal接口访问Keystone而数据库里没有对应的endpoint记录。4.3 第三步MariaDB等保级配置——从root密码到max_connections调优packstack安装的MariaDB默认配置过于宽松必须按等保三级要求加固。第一步运行mysql_secure_installation全程按提示操作设置root密码、删除匿名用户、禁止root远程登录、删除test数据库、重载权限表。第二步创建Neutron专用数据库mysql -u root -p -e CREATE DATABASE neutron CHARACTER SET utf8。第三步创建neutron用户并授权mysql -u root -p -e GRANT ALL PRIVILEGES ON neutron.* TO neutronlocalhost IDENTIFIED BY NEUTRON_DBPASS; FLUSH PRIVILEGES;。这里localhost必须与neutron.conf中connection参数的host部分完全一致。第四步调优/etc/my.cnf.d/openstack.cnf在[mysqld]段添加max_connections 1024默认151Neutron高并发时易耗尽、innodb_buffer_pool_size 512M提升InnoDB性能、wait_timeout 28800避免连接超时断开。最后重启MariaDBsystemctl restart mariadb。这个配置能让Neutron在100个并发租户网络下保持稳定是我在线上环境实测得出的黄金参数。4.4 第四步Neutron Server核心配置——ml2_conf.ini的十二处必改参数/etc/neutron/plugins/ml2/ml2_conf.ini是Neutron的“宪法”以下十二处参数必须逐一手动核对[ml2]段type_drivers flat,vlan初学者禁用gre/vxlan[ml2]段tenant_network_types vlan租户网络类型[ml2]段mechanism_drivers linuxbridge与type_drivers匹配[ml2_type_flat]段flat_networks physnet1flat网络映射名[ml2_type_vlan]段network_vlan_ranges physnet1:1000:2000VLAN ID范围[securitygroup]段enable_security_group true启用安全组[database]段connection mysqlpymysql://neutron:NEUTRON_DBPASScontroller/neutron数据库连接串[keystone_authtoken]段auth_url http://controller:5000/v3Keystone v3地址[keystone_authtoken]段auth_type password认证类型新版强制[oslo_concurrency]段lock_path /var/lib/neutron/tmp锁文件路径[DEFAULT]段core_plugin ml2核心插件[DEFAULT]段service_plugins router启用路由服务改完后执行su -s /bin/sh -c neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head neutron同步数据库。这一步失败90%是因为MariaDB连接参数错误或neutron用户权限不足。4.5 第五步Linux Bridge Agent配置——linuxbridge_agent.ini的物理网卡绑定/etc/neutron/plugins/ml2/linuxbridge_agent.ini是Neutron网络的“物理接口”重点配置[linux_bridge]段physical_interface_mappings physnet1:ens33physnet1必须与ml2_conf.ini中flat_networks值一致ens33替换成你的物理网卡名[vxlan]段enable_vxlan false初学者禁用[securitygroup]段firewall_driver neutron.agent.linux.iptables_firewall.IptablesFirewallDriveriptables防火墙驱动[securitygroup]段enable_security_group true与server端保持一致配置后检查/var/log/neutron/linuxbridge-agent.log应看到Bridge br-ens33 for physical network physnet1 created。如果报Cannot find device ens33说明网卡名填错用ip link show确认。4.6 第六步L3 Agent配置——l3_agent.ini的外部网络出口定义/etc/neutron/l3_agent.ini配置L3路由功能[DEFAULT]段interface_driver neutron.agent.linux.interface.BridgeInterfaceDriverLinux Bridge驱动[DEFAULT]段external_network_bridge ens34ens34是你的外网物理网卡非网桥名[DEFAULT]段router_delete_namespaces true删除命名空间便于调试启动服务systemctl enable neutron-l3-agent systemctl start neutron-l3-agent。检查ip netns应看到qrouter-xxx命名空间ip netns exec qrouter-xxx ip a能看到qg-xxx网关接口和qr-xxx内部接口。4.7 第七步DHCP Agent配置——dhcp_agent.ini的dnsmasq精准控制/etc/neutron/dhcp_agent.ini配置DHCP服务[DEFAULT]段interface_driver neutron.agent.linux.interface.BridgeInterfaceDriver[DEFAULT]段dhcp_driver neutron.agent.linux.dhcp.Dnsmasq[DEFAULT]段enable_isolated_metadata true启用元数据服务[DEFAULT]段dnsmasq_config_file /etc/neutron/dnsmasq-neutron.conf创建/etc/neutron/dnsmasq-neutron.conf内容dhcp-option-force26,1400 no-hosts设置权限chown neutron:neutron /etc/neutron/dnsmasq-neutron.conf。启动服务systemctl enable neutron-dhcp-agent systemctl start neutron-dhcp-agent。4.8 第八步Metadata Agent配置——metadata_agent.ini的Nova密钥注入/etc/neutron/metadata_agent.ini让虚拟机获取实例元数据如SSH密钥[DEFAULT]段nova_metadata_host controller[DEFAULT]段metadata_proxy_shared_secret METADATA_SECRET与nova.conf中metadata_proxy_shared_secret值一致[DEFAULT]段metadata_workers 4启动服务systemctl enable neutron-metadata-agent systemctl start neutron-metadata-agent。4.9 第九步服务启动与状态验证——用systemctl和openstack双重确认按顺序启动服务systemctl enable neutron-server neutron-linuxbridge-agent neutron-l3-agent neutron-dhcp-agent neutron-metadata-agent systemctl start neutron-server neutron-linuxbridge-agent neutron-l3-agent neutron-dhcp-agent neutron-metadata-agent验证状态systemctl status neutron-server必须active (running)openstack extension list --network应列出router,security-group等扩展openstack network list应返回空列表表示服务正常只是还没建网络neutron agent-list应看到linuxbridge,l3,dhcp,metadataagent状态均为:-)alive如果neutron agent-list显示XXXdown用journalctl -u neutron-xxx-agent -n 50查日志90%是配置文件参数错误。4.10 第十步创建第一个网络——provider网络与self-service网络的实操区别创建flat provider网络直连物理网络openstack network create --share --provider-physical-network physnet1 --provider-network-type flat provider openstack subnet create --network provider --allocation-pool start192.168.1.100,end192.168.1.200 --dns-nameserver 114.114.114.114 --gateway 192.168.1.1 provider-subnet创建vlan self-service网络租户隔离网络openstack network create selfservice openstack subnet create --network selfservice --dns-nameserver 114.114.114.114 --gateway 172.16.1.1 --subnet-range 172.16.1.0/24 selfservice-subnet openstack router create router openstack router add subnet router selfservice-subnet openstack router set --external-gateway provider router关键区别provider网络的--provider-physical-network参数必须与linuxbridge_agent.ini中physical_interface_mappings的键名一致self-service网络必须通过router关联到provider网络才能访问外网。4.11 第十一步虚拟机网络验证——从ping到tcpdump的三层诊断法启动虚拟机后网络验证分三层L1物理层ip link show qbr-xxx确认网桥存在、brctl show确认qvb-xxx和qvo-xxx端口连接正确L2数据链路层ip netns exec qdhcp-xxx ip a查看DHCP命名空间IP、tcpdump -i qg-xxx icmp在router命名空间抓包确认浮动IP ping请求到达L3网络层openstack console log-show instance-name查看cloud-init日志确认DHCP获取IP成功、ping -c 4 8.8.8.8测试外网连通性我总结的黄金命令组合openstack port list --device-id instance-id找到port id →neutron port-show port-id看binding:vif_type和binding:host_id→ip netns exec qrouter-xxx ip r看路由表 →tcpdump -i qr-xxx -nn icmp抓内部流量。这套组合拳能定位95%的网络问题。4.12 第十二步故障注入与恢复演练——模拟neutron-server崩溃后的服务自愈真正的“实训七”必须包含故障演练。手动杀死neutron-serverkill -9 $(pgrep -f neutron-server)。观察systemctl status neutron-server变为failedopenstack network list返回Unable to establish connection但已运行的虚拟机网络不受影响因为数据平面独立然后执行恢复systemctl start neutron-server # 等待30秒检查日志journalctl -u neutron-server -n 20 | grep Starting neutron-server openstack network list # 应恢复正常这个过程验证了OpenStack的“控制平面与数据平面分离”设计哲学——服务中断不影响已有业务。我在给某银行做容灾方案时就是用这套方法说服他们接受OpenStack的高可用架构。5. 常见问题与排查技巧实录来自十二个真实项目的血泪经验5.1 问题速查表Neutron服务异常的TOP5现象与根因现象日志关键词根本原因解决方案neutron-server启动后立即退出ImportError: No module named neutron.plugins.ml2.drivers.linuxbridgePython路径错误或包未安装pip install python-neutronclient检查/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/是否存在linuxbridge目录neutron agent-list显示XXXdownAMQP server on controller:5672 is unreachableRabbitMQ服务未启动或防火墙拦截systemctl start rabbitmq-serverfirewall-cmd --add-port5672/tcp --permanent创建网络后neutron net-list为空DatabaseException: (pymysql.err.OperationalError) (1045, Access denied for user neutron127.0.0.1)MariaDB权限中neutronlocalhost与neutron.conf中connection的host不匹配mysql -u root -p -e GRANT ALL ON neutron.* TO neutron127.0.0.1 IDENTIFIED BY NEUTRON_DBPASS;虚拟机获取不到IPdnsmasq: failed to create listening socket for 172.16.1.1: Cannot assign requested addressdnsmasq绑定的IP与subnet gateway不一致检查/var/lib/neutron/dhcp/network-id/dnsmasq.conf中dhcp-range和dhcp-option是否匹配subnet配置浮动IP ping不通ip netns exec qrouter-xxx ip r显示缺默认路由router未设置external-gatewayopenstack router set --external-gateway provider router5.2 独家避坑技巧那些文档里不会写的实战心得提示neutron-server日志里INFO级别日志全是废话WARNING和ERROR才是关键。但真正的高手会看DEBUG日志——在neutron.conf中设置debug true然后tail -f /var/log/neutron/server.log \| grep ML2你能看到ML2插件如何解析ml2_conf.ini、如何加载linuxbridge驱动、如何查询networks表。这比任何文档都直观。注意openstack客户端命令的--debug参数是神器。执行openstack --debug network list它会打印完整的HTTP请求头、响应体、以及调用的Keystone endpoint URL。当neutron net-list失败时这个输出能直接告诉你请求发到了哪个IP和端口从而判断是DNS解析问题、网络路由问题还是Keystone endpoint配置错误。提示brctl show和ip netns是Neutron网络的“X光机”。brctl show能看到所有网桥及其端口ip netns能看到所有命名空间。如果brctl show里没有br-int说明OVS agent没启动如果ip netns里没有qrouter-xxx说明L3 agent没创建router。这两个命令应该成为你排查网络问题的第一反应。注意不要迷信openstack命令的返回。openstack router create router返回success不代表router真的工作了。必须执行ip netns确认命名空间存在再ip netns exec qrouter-xxx ip a确认接口配置正确。我见过太多人被“命令成功”的假象迷惑结果虚拟机一直无法上网。提示tcpdump是网络问题的终极审判者。在qg-xxx接口抓包能看到浮动IP的ICMP请求在qr-xxx接口抓包能看到虚拟机发出的ARP请求。如果qg-xxx有请求但qr-xxx没有说明L3 agent的iptables规则阻断了流量如果qr-xxx有ARP但没回复说明DHCP agent没工作