ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

基于EVE-NG抓包分析STP BPDU:从原理到故障排查实践

基于EVE-NG抓包分析STP BPDU:从原理到故障排查实践 1. 实验目标为什么STP适合放进EVE-NG做流量洞察1.1 这期实验解决什么问题STPSpanning Tree Protocol生成树协议是二层网络里无论如何都绕不开的协议也是很多工程师觉得“原理背得挺熟一到排障就发懵”的典型场景。这期《EVE-NG流量洞察》系列不打算再搬教科书而是直接在EVE-NG里用三台交换机搭一个三角形环路把STP的BPDU报文抓出来逐字段看根桥是谁选出来的、哪个端口会被阻塞、断了一条链路之后全网到底要等多久才能重新转发。如果你正在学交换协议或者想用EVE-NG验证STP行为这篇文章可以直接照着做。这套实验最大的价值不是“跑通”而是让你亲眼见到STP在网络里是怎么一点点收敛的。文档里只说“选出根桥、阻塞冗余端口”但真正在设备上跑起来端口状态时间线长什么样抓包里Root Identifier、Root Path Cost这些字段怎么变拔一根线以后中间那几十秒端口在干什么——这些光靠背是背不出来的。做一遍流量洞察之后你会发现STP不再是一个抽象概念而是一套可以用眼睛逐帧跟踪的机制。1.2 EVE-NG做这个实验的优势真实环境里想搭一个物理环路来测试STP光是风险就劝退很多人。物理交换机一旦误配置或者STP没起来广播风暴直接殃及整个办公网老板的脸色你懂的。EVE-NG这类虚拟化网络平台就没有这个顾虑环网随便搭链路随便断改优先级就像打字一样快实验做完一键删除不会留下任何后遗症。更关键的是EVE-NG可以对任意一条链路抓包相当于给每根虚拟网线都插了一个Wireshark探针。STP是典型的控制平面流量BPDU每2秒发一次量不大但信息密度极高。真实交换机上想抓BPDU不是所有端口都方便做镜像EVE-NG里右键链路线抓包就开始了。再加上节点、连线、抓包一体化操作比传统模拟器省非常多事。下面我用Cisco IOL也就是常说的IOU/IOL L2镜像来做思路同样适用于IOSv-L2或者其他支持STP的节点类型。2. 动手前先把STP的关键机制过一遍2.1 BPDU是STP的“心跳包”STP的所有决策都靠BPDUBridge Protocol Data Unit桥协议数据单元来传递。交换机默认每2秒通过所有端口发送配置BPDU里面封装了它当前“认知”的根桥ID、根路径开销、自身桥ID、端口ID等信息。可以把它理解成交换机之间打招呼的暗号我告诉大家我现在认为谁是老大、我离老大有多远、我自己的身份是什么。当交换机从某个端口收到更优的BPDU它就会放弃自己原来的根桥认知改认对方认知的根桥并继续转发这条更优的BPDU。反过来如果收到的BPDU比自己发出的要差它就把自己的BPDU继续发出去。这种“不断交换、不断择优”的过程让整个二层网络里的每台设备最终形成一致视图。BPDU还有一类是TCN BPDU拓扑变更通知当链路发生变化时交换机用它通知根桥更新MAC地址表这个在后面的故障实验里也能抓到。2.2 根桥、根端口、指定端口是怎么选出来的STP选主这件事本质上是在全网选一个“根”然后围绕根来规划哪些端口能转发、哪些端口必须堵死。三个核心角色要知道根桥Root Bridge全网桥ID最小的交换机。桥ID 优先级 MAC地址优先级默认32768优先看优先级再看MAC地址。根端口Root Port非根桥上离根桥最近的端口依据是收到BPDU的根路径开销最小。指定端口Designated Port每条链路上离根桥最近的端口负责往该链路转发BPDU。每台交换机的每个端口最终要么是根端口要么是指定端口要么被阻塞。整个STP决策按这个顺序比较根桥ID最小 → 根路径开销最小 → 发送者桥ID最小 → 发送者端口ID最小。这串比较逻辑在抓包里能一一对应看到实验时遇到端口角色和自己预想不一致多半就是这条优先级链路没理清。2.3 STP收敛时间为什么这么慢传统STP的端口状态要经过Blocking、Listening、Learning、Forwarding这几步。链路正常时阻塞端口一直处于Blocking状态一旦拓扑变化阻塞端口要先等Max Age超时默认20秒之后进入Listening15秒学习BPDU、确认拓扑然后Learning15秒学习MAC地址最后才Forwarding。最坏情况下全网要等50秒左右才能恢复转发。这个“慢”不是设备性能问题而是设计上故意留出足够时间防止旧数据帧造成环路。后面实验里我会带着你实际掐表看这个收敛过程感受一下什么叫“网络断了一会儿又自己活了”。3. 搭建STP实验拓扑EVE-NG实操3.1 准备镜像和基础环境做这个实验之前先确保EVE-NG服务器能正常打开Web界面并且已经准备好了交换机镜像。我这边用的是Cisco IOL的L2镜像也就是名字里带l2-upk9的那类它可以当纯二层交换用STP行为非常接近真实交换机。如果服务器上还没有镜像推荐用EVE-NG镜像管理工具一键导入它能直接把本地镜像传到服务器并生成节点模板省去手动SCP、改yml、调权限这些琐碎步骤。添加节点时注意选择Switch模板再选对应的IOL镜像如果模板类型选成Router后面做L2交换实验会别扭。硬件方面不需要多高配置三台IOL交换机和两台VPCS给2GB内存都绰绰有余。实验前留意一下EVE-NG服务器版本和浏览器兼容性我用Chrome一直很稳定Edge也没问题IE系浏览器不建议试。3.2 创建拓扑并连线在EVE-NG里新建一个实验名字随意比如stp-lab。然后从左边的设备栏分别拖出三个Switch节点命名SW1、SW2、SW3再拖出两个VPCS节点命名PC1、PC2。连线方式很简单点工具栏上的Link图标依次点两台设备在弹出的接口选择里确认端口就行。我用的连接关系如下SW1 Gi0/0 连接 SW2 Gi0/0SW2 Gi0/1 连接 SW3 Gi0/0SW3 Gi0/1 连接 SW1 Gi0/1PC1 连接 SW1 Gi0/2PC2 连接 SW3 Gi0/2这就是一个标准三角形环路STP不起作用的话广播帧会在这里无限循环。注意实际接口名要看你镜像的显示IOL镜像常见的是Ethernet0/xIOSv-L2常见的是GigabitEthernet0/x连完线后可以通过点击节点查看接口名称确认。全部连接好之后启动所有节点等待设备进入命令行。3.3 三台交换机的初始配置交换机默认就开启了STP所以实验前的配置其实非常少。主要是设置主机名、关掉DNS解析、确认接口都处于no shutdown状态。以SW1为例hostname SW1 no ip domain-lookup ! interface GigabitEthernet0/0 no shutdown ! interface GigabitEthernet0/1 no shutdownSW2、SW3同理。这里有个小细节IOL镜像在生成时MAC地址通常是自动分配的所以最开始谁是根桥取决于三台交换机里哪个桥ID最小。我经常看到新手一上来就猜“SW1肯定是根桥”其实未必。正确的做法是配置完以后执行show spanning-tree看输出里Root ID那一栏到底指向谁这才是“流量洞察”该有的思路——不猜直接看数据。如果Root ID下面的Address显示的是本机MAC说明这台设备目前认为自己是根桥。4. 抓BPDU流量逐字段解读STP报文4.1 开启抓包的方式EVE-NG里抓包最直观的方式是在拓扑图上右键点击某条链路菜单里选择Capture然后选择要抓的接口系统会自动调用本机的Wireshark开始实时抓包。第一次使用如果弹不出来多半是Wireshark路径没有在EVE-NG的Preferences里配置好设置一下本地Wireshark可执行文件路径就好。如果你更喜欢在服务器底层操作也可以SSH登录EVE-NG先执行ip link show | grep vunl0找到节点对应的虚拟接口再用tcpdump抓包ip link show tcpdump -i vunl0_1_0 -nn -vvv -w /tmp/stp.cap抓完把pcap文件拷出来用Wireshark分析。EVE-NG为每个网络设备分配的虚拟接口名通常是vunl0_节点ID_接口序号多试几次就能对应上。我个人的习惯是小实验直接用Web界面抓包快如果想长时间后台抓就tcpdump到文件不占浏览器资源。4.2 用Wireshark分析配置BPDU抓包开始后在Wireshark过滤栏输入stp就能看到周期性出现的配置BPDU基本上每2秒就来一条。点开任意一条BPDU重点看这几个字段Root Identifier当前根桥的优先级加MAC地址。Bridge Identifier发送这条BPDU的交换机自身桥ID。Root Path Cost发送端口到根桥的路径开销。Port Identifier发送这条BPDU的源端口ID。Message Age、Max Age、Hello Time、Forward DelaySTP的计时器参数。有一类帧大家可能也会抓到的是Cisco私有的PVST BPDU目的MAC通常是01:00:0C:CC:CC:CD。标准STP BPDU的目的MAC是组播地址01:80:C2:00:00:00看到这个目的MAC就可以基本确认是STP在打招呼。Cisco的PVST里每个VLAN都有独立生成树实例报文结构主体和标准BPDU差不多但会带上VLAN信息不用被它吓到。4.3 验证当前拓扑中各端口角色回到交换机上反复执行show spanning-tree把端口角色和抓包结果对应起来。稳定状态下根桥上的端口基本都是Desg FWD指定端口转发状态非根桥上有一个Root FWD根端口转发状态剩下的冗余端口会变成Altn BLK替代端口阻塞状态。在三角形拓扑里必然有一个端口被阻塞从逻辑上打破环。我当时做这个实验时用三条链路分别抓包对比同一个时刻三条链路里的BPDU内容非常直观地看到了“同一条BPDU从根桥出发经过下一跳被改写后再转发”的过程。Root Path Cost会随着跳数增加而累加这不是故障而是STP正常记录路径开销的方式。如果抓包时机够早还能看到交换机刚启动、端口还处于Listening状态时的BPDU交换过程那是最容易理解STP收敛的黄金窗口。5. 故障与调整验证STP收敛过程5.1 shutdown链路观察重新收敛拓扑稳定之后进入SW2把连到SW3的那个端口shutdowninterface GigabitEthernet0/1 shutdown此时因为拓扑发生变化原来被阻塞的端口会开始苏醒。在SW3上反复执行show spanning-tree隔几秒刷新一次你会看到端口状态从Blocking变成Listening再变成Learning最后变成Forwarding。我实测最明显的感受就是端口状态真的是一步一步爬过去的不是瞬间切换。整个过程大概要30到50秒具体取决于镜像模拟的速度。在Wireshark里也能看到变化。拓扑变化时BPDU的Flags字段会带上TC标记Topology Change交换机收到后会把MAC地址表老化时间临时缩短避免回环。抓到TC标志的那一刻再结合端口状态变化STP的收敛逻辑就串起来了。5.2 修改优先级触发根桥选举想让根桥切换最温和的方式是改桥优先级。比如让SW3成为新根桥执行SW3(config)# spanning-tree vlan 1 priority 4096几秒后看show spanning-treeSW3会变成根桥所有BPDU里的Root Identifier会指向SW3。各交换机的端口角色也会重新洗牌原来被阻塞的端口可能会变成指定端口某些交换机的根端口也可能从Gi0/0换到Gi0/1。这里我说一个小心得改优先级导致的收敛比直接拔线温和得多也更好观察适合做“主备切换”演练。真实网络里如果要做STP流量切换测试我一般也优先用调优先级的方式而不是物理拔线因为拔线不可控因素多调参至少你知道触发点在哪儿。5.3 看RSTP对比如果镜像支持顺手做个RSTP对比会非常有意思。在三台交换机上执行spanning-tree mode rapid-pvst全部切换成RSTP之后再次shutdown一条链路观察收敛。你会发现端口状态从Blocking变成Forwarding只需要几秒钟完全没有传统STP那种数几十秒的等待。这就是RSTP的Proposal/Agreement握手机制在起作用端口不再依赖计时器傻等而是通过快速握手确认拓扑安全后立即转发。跑完这个对比再回头看标准STP的设计初衷和痛点理解会深得多。6. 常见问题与实操技巧实录6.1 在EVE-NG里抓不到STP报文怎么办初次抓包抓不到STP十有八九是下面这几个原因。第一链路抓错了接口。IOL节点有多个接口右键抓包时选到了一个没接线的接口自然什么都没有。确认一下该端口对端有没有设备以及是否真的在拓扑图里连了线。第二过滤条件设置有问题。Wireshark过滤栏里输入的是stp但有些桥设备发出来的可能是带VLAN的PVST帧显示名称未必直接叫STP。抓包时可以先把过滤条件清空看看有没有周期性的组播帧再逐步筛选。第三EVE-NG底层抓包时接口没认对。这里有个笨办法SSH进服务器执行top或者ifconfig然后把某个节点shutdown再no shutdown看哪个vunl接口的状态跟着变那个接口就对应这台设备绝对不会抓错。6.2 用镜像管理工具快速准备EVE-NG镜像很多实验室里没有现成的IOL交换镜像手动SCP传递加写模板又容易踩权限坑。现在社区里常见的EVE-NG镜像管理工具基本能解决这个问题下载好镜像文件后用工具一键导入服务器自动识别类型、生成节点模板省去很多手改配置的步骤。用工具时留意一下不同版本EVE-NG的模板路径和镜像目录结构会有差异导入时选择正确的版本不然可能上传成功但节点列表里看不到。6.3 让每台设备在独立的Putty窗口打开STP实验经常要在三台交换机之间来回切命令网页自带的终端就比较难受了。我更习惯把设备全部弹到本地Putty的独立窗口里同时开着三个窗口左边选根桥右边看端口状态效率高很多。设置方法不复杂Windows本机装好PuTTY然后在EVE-NG Web界面进入Tools → User Preferences → Console把Console Type改成putty。之后双击拓扑上的节点系统会自动调用本地Putty连接点几台设备就会弹出几个独立窗口互不干扰。如果点了设备没反应先检查EVE-NG官方客户端集成组件有没有装好再看Windows里telnet/ssh协议是不是默认关联到了Putty。这两个地方只要有一个没配置对本地Putty就不会被正常唤起。做STP流量洞察实验整体的体会是不要贪心搭大型拓扑三台交换机的三角形环路加上两台终端已经是“麻雀虽小五脏俱全”的最小闭环了。多抓几次BPDU对照show spanning-tree里的端口角色反复验证比死记端口状态表有用得多。下一期流量洞察如果想继续往下走拿RSTP快速收敛和故障注入做组合对比是个不错的思路如果你有想看的协议欢迎一起交流。
返回列表