EVE-NG流量洞察系列做到第7期终于轮到STP了。前面几篇拆ARP、ICMP、DHCP都有很明显的业务流量特征测试时抓包结果一目了然。STP不一样它平时安安静静在后台跑二层用户流量看不到它但一旦物理环路出现广播风暴能把整个交换网打瘫。更麻烦的是很多人只背得出“STP能防环”真问根桥是谁、哪个端口在阻塞、收敛要多久就开始含糊。这期我用EVE-NG搭一个三台交换机的环形拓扑从BPDU抓包入手把根桥选举、端口角色、状态机迁移和拓扑变更通知完整过一遍。适合正在学交换、准备认证或者想真正搞懂环路故障的网工。1. STP在EVE-NG里为什么值得单独抓一次包1.1 二层环路被禁止后BPDU成了唯一“语言”日常说STP防环其实说得太抽象。二层交换机本身不具备“知道全网拓扑”的能力它只需要回答一个问题每个端口到底能不能转发用户数据。STP就是靠BPDU不停交换、不停竞争得出的结果。每台交换机把自己当前认为的根桥、自己到根桥的cost、自己的Bridge ID全部塞进BPDU里默认2秒发一次收到更优的BPDU就放弃发言收到次优的BPDU就保持原状或者改端口状态。整个过程就像一群交换机在开会BPDU是唯一的表决单。过去我们验证STP最常见的方式是配置完之后执行show spanning-tree看几行状态。但那只看到本机视角看不到报文交互过程。在EVE-NG里观察STP等于直接去旁听这场会。物理环境里你很难同时监听多段链路的BPDU因为BPDU是二层组播帧普通笔记本接上去未必能抓到而在EVE-NG里任何两台设备之间的连线都能直接出pcap想在哪段链路上看就在哪段链路上看。这就是“流量洞察”这个系列的核心价值把协议行为变成可以反复回放的报文。1.2 虚拟环境和物理环境观察STP的差异有人会担心EVE-NG是虚拟环境跑STP不准。其实不用太担心。EVE-NG里的IOL镜像跑的是真实IOS代码BPDU是从虚拟网卡真实发出来的协议状态机、Hello计时器、Forward Delay这些都由IOS自己在维护不是模拟器“画”出来的效果。所以你在物理交换机上看到的行为在这里基本都能复现。差异主要体现在二层链路本身。EVE-NG的虚拟线缆没有传输时延BPDU里的Message Age不会像真实网络那样随着物理跳数明显增加另外如果宿主机CPU忙Hello时间可能出现微小抖动。这些都不影响你学习STP的核心逻辑。还有一点要注意EVE-NG里如果加的是普通Linux主机镜像它默认不跑STP要看STP必须用支持交换功能的设备镜像。最方便的是Cisco IOL L2镜像其次是带交换能力的QEMU镜像别选成纯路由镜像。2. 一个三角环拓扑把根桥选举和端口角色一次讲清2.1 拓扑设计三条链路制造一个物理环路我搭的拓扑很简单三台交换机S1、S2、S3链路如下表。链路两端接口预期端口角色S1 — S2S1 E0/0 : S2 E0/0S1指定端口S2根端口S1 — S3S1 E0/1 : S3 E0/0S1指定端口S3根端口S2 — S3S2 E0/1 : S3 E0/1S2指定端口S3阻塞端口S1-S2-S3-S1形成一个物理上的三角环。如果不跑STP广播帧会在这个环里无限循环交换机的MAC表也会疯狂抖动。选三角而不是两交换机互联是因为两点一线的拓扑只能看到“一个根端口和一个指定端口”的简单状态看不到真正的阻塞端口更看不到后续“阻塞端口被激活”的过程。三角环既有根端口、指定端口又有阻塞端口三种角色齐全适合一次学明白。为了让收敛过程可观察我还会在S1下挂PC1、S3下挂PC2断链时用连续ping来量化中断时间。不过前期学BPDU时这两个主机不是必需的它们只会增加抓包里的广播噪音。2.2 优先级规划决定谁是根桥、谁阻塞为了让结果可控我先把VLAN控制在VLAN1。PVST里每个VLAN各自是一棵生成树如果你同时放行VLAN10、VLAN20抓包里BPDU数量会成倍增加新手容易看花眼。先用一个VLAN把STP本身吃透后面要学多实例再往上加VLAN。三台交换机都配置为trunk互联然后显式设置根优先级。! S1 hostname S1 spanning-tree vlan 1 priority 4096 interface Ethernet0/0 switchport mode trunk no shutdown interface Ethernet0/1 switchport mode trunk no shutdown! S2 hostname S2 spanning-tree vlan 1 priority 8192 interface Ethernet0/0 switchport mode trunk no shutdown interface Ethernet0/1 switchport mode trunk no shutdown! S3 hostname S3 spanning-tree vlan 1 priority 12288 interface Ethernet0/0 switchport mode trunk no shutdown interface Ethernet0/1 switchport mode trunk no shutdown优先级从低到高排列S1必然是根桥。S2和S3都有一条直连根桥的链路端口cost按100M以太网算都是19所以在S2-S3这段链路上S2的Bridge ID优先级更低成为指定端口S3对应端口进入阻塞。如果让三台设备都用默认优先级32768最终根桥会由MAC地址大小决定结果不够直观。我现在把角色“预定”好了后面抓包验证时不会出现歧义。2.3 上线验证先让STP收敛再开始抓包配置完成后不要立刻抓包。三台交换机从启动到选举稳定需要一段时间建议等30到40秒先看一遍各设备的状态。S3# show spanning-tree vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 4097 Address aabb.cc00.0100 Cost 19 Port 5 (Ethernet0/0) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 12289 (priority 12288 sys-id-ext 1) Address aabb.cc00.0300 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Interface Role Sts Cost Prio.Nbr Type E0/0 Root FWD 19 128.5 Shr E0/1 Altn BLK 19 128.6 Shr注意Root ID的Priority显示为4097不是4096。很多第一次做实验的人在这里会愣一下4096怎么变成了4097因为PVST在BPDU里把VLAN号作为sys-id-ext加进了优先级字段4096 VLAN1 4097。这完全正常。此时S3的E0/0是根端口ForwardingE0/1是Alternate端口Blocking。如果你看到E0/1显示为Forwarding说明STP没收敛或者模式不对先检查优先级配置再检查端口是否都在trunk模式下。确认无误后才开始下一节的抓包。3. 从抓包里读出STP的“潜台词”Root ID、Cost、Port ID3.1 在EVE-NG起抓包的正确姿势在EVE-NG拓扑界面里右键点击S3和S2之间的连线选择Capture会弹出选择节点或接口的窗口选S3的Ethernet0/1Wireshark就会开始收包。如果你的EVE-NG没有弹出Wireshark通常是本机缺少desktop integration组件装好关联工具再试。打开Wireshark后第一步不是看包先把显示过滤器设为stp。BPDU是组播的二层帧不走TCP/UDP用tcp过滤肯定什么都看不到。我也建议不要在抓包前的Capture Filter里直接写stp因为BPDU走的是802.3/LLC封装BPF语法容易误伤直接抓全量再显示过滤最省事。抓包要持续多久至少10秒。STP收敛完成后S3的E0/1是阻塞端口它只管收、不主动发BPDU所以这端抓到的其实是S2周期性发来的Hello BPDU每2秒一条。看到这种规律性的BPDU流说明端口确实处于被动的阻塞状态。3.2 BPDU关键字段逐个过Wireshark里展开一条STP报文会看到很多字段。新手没必要全部背下来但下面这张表里的字段必须会看。字段典型值含义Destination MAC01:80:c2:00:00:00或PVST组播地址二层BPDU专用组播地址LLC DSAP/SSAP0x42SNAP封装标识Protocol Identifier0x0000802.1D STPBPDU Type0x00配置BPDU0x80 TCNBPDU的种类Root Identifier优先级VLAN根桥MAC全网唯一的根桥身份Root Path Cost0或19等发送者到根桥的路径开销Bridge Identifier优先级本机MAC这条BPDU是谁发出的Port Identifier端口优先级端口号从哪个端口发出Message Age0~20秒从根桥生成后经过的时间Max Age20秒BPDU多久没收到视为过期Hello Time2秒配置BPDU发送周期Forward Delay15秒Listening/Learning持续时间看包的核心方法是三连问。一问Root Identifier是不是同一个全网必须只有一个根桥如果S2发给S3的BPDU里Root ID和S1发给S3的Root ID不一样说明选举还没稳定。二问Root Path Cost是多少S2发给S3的BPDU里Root Path Cost是19表示S2到根桥要经过一条100M链路如果S3收到的成本变成38则说明根桥又远了一个网段。三问Bridge Identifier是自己还是别人一条BPDU里Bridge ID等于Root ID说明这条BPDU来自根桥本身否则就是中间交换机在转述根桥的信息。3.3 用显示过滤器快速定位异常信息单纯看几十条BPDU不累但真实网络里BPDU数量很大需要会过滤。Wireshark里双击展开某个STP字段左下角会提示对应的过滤语法。比如你想只看某类BPDU可以按stp.bpdutype或类似字段过滤想对比不同发送者就按stp.bridge_*系列字段分组。不同Wireshark版本字段名称略有差异鼠标点字段看提示是最稳的不要硬背语法。再提供一个偏工程师口味的做法用Python直接读pcap把BPDU的Root MAC、Path Cost、Bridge MAC提出来打印。Scapy里STP层字段名在不同版本略有不同跑之前先ls(STP())确认一下。from scapy.all import rdpcap from scapy.layers.l2 import STP pkts rdpcap(s3-e0-1.pcap) for pkt in pkts: if STP in pkt: stp pkt[STP] print(stp.rootmac, stp.rootpathcost, stp.bridgemac, stp.portid)输出里Root MAC和Bridge MAC对比一下谁在说自己是根桥谁在复述别人一目了然。这个思路在处理几百MB的pcap时比Wireshark图形界面高效得多。4. 断一条链路把状态机和TCN的完整过程看一遍4.1 断链前的静态验证show spanning-tree和抓包的数据要能对上在动手断链之前先建立“本机视角”和“邻居视角”的双重基线。本机视角是S3上的show spanning-tree vlan 1看到E0/0是Root端口、ForwardingE0/1是Altn、Blocking。邻居视角是Wireshark里S3-E0/1端口的抓包这条链路上只能看到S2发来的BPDU源MAC是S2Root ID是S1Root Path Cost是19而且每2秒一条。S3自己在这条链路上一言不发因为它不是指定端口。这时候从PC2去ping PC1ICMP能通但流量不会经过S2-S3链路因为S3的E0/1还在阻塞。链路是通的业务流量跟STP路径完全一致这就是一个健康的二层环路场景。4.2 断链后S3端口从Blocking走到Forwarding的30秒现在在S3上把直连根桥的E0/0关掉。S3(config)# interface Ethernet0/0 S3(config-if)# shutdown连通性变化很直观PC2到PC1的ping开始大量丢包等大约30秒后恢复。这30秒就是经典STP的收敛时间由两个15秒的Forward Delay组成。具体过程在抓包里是这样体现的。S3失去E0/0这根根端口后它只剩E0/1这一条候选路径。而E0/1之前虽然是阻塞状态但一直在接收S2发来的BPDU里面包含的信息是“根桥S1可达路径开销19”。这条信息比S3自己宣称的“我是根桥”要优所以S3立刻判断E0/1可以成为新根端口。端口从Blocking进入Listening此时Wireshark上最明显的变化是S3开始主动从E0/1发出BPDU了。之前只收不发现在两边都有包说明S3在这个网段获得了发言权。按802.1D的计时器Listening持续15秒之后进入Learning再15秒然后才Forwarding。我用连续ping测试丢包窗口大约是30秒和理论值一致。如果你实验里看到端口秒开、ping只断了一两秒十有八九把STP模式开成了Rapid PVST或RSTP那就要回到模式设置上检查。4.3 TCN/TCA和配置BPDU的TC标志拓扑变化的连锁反应单纯看端口状态迁移还不够STP里更有意思的是拓扑变化通知。当S3检测到端口角色变化它会通过根端口向外发一条TCN BPDU告诉根桥“网络拓扑变了”。这个根端口恰好也是刚变成Forwarding的E0/1所以抓包里会看到大致时间帧方向BPDU类型解读0秒左右S3 → S2TCNS3通知上游有拓扑变化0秒左右S2 → S3TCAS2确认收到TCN0秒左右S2 → S1TCNS2向根桥转告0秒左右S1 → S2TCA根桥确认随后35秒S1 → 全网带TC标志的配置BPDU根桥要求大家缩短MAC表老化时间TC标志的作用很多人理解不到位。正常情况下交换机MAC表条目老化时间是300秒拓扑变了以后如果还用300秒老化交换机很可能继续把帧发往已经失效的端口造成长时间丢包。根桥收到TCN后会在配置BPDU里置位TC标志并持续Max Age加Forward Delay的时间即大约35秒。这段时间内所有交换机临时把MAC老化时间缩短为15秒快速清掉老旧条目。Wireshark里你不需要猜测直接看根桥发出的配置BPDU里的Topology Change字段是1就是正在通知全网刷新。这一连串动作下来你会清楚看到STP不只是“把某个端口堵住”而是一套完整的状态同步机制。抓包把TCN、TCA、TC标志全部摆出来比背十遍理论知识都管用。5. EVE-NG里观察STP容易踩的三个坑5.1 默认模式可能不是你想看的经典STP这个坑我在好几台IOL镜像上都遇到过。你以为自己在看经典802.1D的30秒收敛结果端口从阻塞到转发只用了两秒因为你没确认当前STP模式而镜像默认跑的是Rapid PVST。配置完成后先在所有交换机上执行show spanning-tree vlan 1看输出里的“Spanning tree enabled protocol”这一行。显示ieee是PVST/802.1D显示rstp就是Rapid PVST。想复现经典STP全过程在三台设备上都执行spanning-tree mode pvst然后再测。混用模式也是个麻烦。如果S2是Rapid PVST、S3是PVST两台设备在BPDU版本和协商flag上不一致抓包里的字段会变得很奇怪比如配置BPDU里出现不明的Proposal/Agreement位。排障逻辑也会被带偏。统一模式再做实验省得怀疑自己拓扑搭错了。5.2 复制粘贴节点带来的MAC重复问题EVE-NG里搭建实验时很多人习惯从已有点上右键复制节点再粘贴出一个新交换机。复制出来的节点如果继承了原节点的虚拟MAC问题就来了Wireshark里你会看到两台不同交换机发出的BPDUBridge Identifier完全相同。STP选举遇到完全相同的Bridge ID优先级和MAC都无法比较运气成分就上来了你没法预料谁会成为根桥。遇到这种诡异情况先别怀疑Wireshark去检查两个节点的网卡MAC是否重复。最简单的办法是删掉出问题的节点重新拖一个出来也能直接看节点配置里MAC地址段能否修改。保持全网Bridge ID唯一是STP实验能够复现的前提。5.3 别用删连线代替接口shutdown抓包会断断链时的一个低级错误是在EVE-NG画布里直接右键删除S3-S1之间的连线。这样确实模拟了“链路断开”但你会立刻失去这段链路的抓包入口后续想复盘BPDU流就没了。更稳的做法是在设备console里执行shutdown/no shutdown让IOS自己经历link down和link up事件抓包继续保留还能顺便观察恢复后的BPDU交互。同理如果你需要反复测试收敛建议不要频繁重启节点。重启节点会让整个交换机的STP状态清零重新经历根桥选举和端口角色竞争干扰你对单一链路故障的判断。还有个小提醒抓BPDU时如果一直开着Wireshark但没看到任何STP帧先检查是不是交换机节点根本没起来或者端口被shutdown了。EVE-NG里节点启动是个异步过程刚开机时IOS还没跑到STP等二三十秒再抓包是正常的。6. 把流量洞察变成真实排障能力6.1 拿到一份陌生网络的BPDU怎么反推根桥和阻塞点从抓包文件反推网络结构和根桥方法其实固定。先按Root Identifier排序所有BPDU里Root ID一致说明生成树已经收敛。然后找“Root ID等于Bridge ID”的那些BPDU发件人就是根桥。根桥通常会在所有活跃端口上都发配置BPDU而且Root Path Cost是0。再看每一段链路上谁在发配置BPDU。同一段网段里持续发BPDU的是指定端口只接收但不发的是根端口或阻塞端口。区分根端口和阻塞端口需要结合交换机本机的状态如果这个端口是到达根桥路径里最优的那个就是根端口否则就是被阻塞的Alternate端口。你不需要认识网络里的每一台交换机只要把BPDU里的Port ID和Bridge ID记下来再对照show mac address-table找出这些MAC对应哪台设备整个STP拓扑就拼出来了。6.2 实际网络里抓STP包的“黄金时机”在物理网络里抓BPDU比EVE-NG麻烦不少但思路完全一样。以下几个时间点最值得抓。第一加新交换机之前。此时抓一段已有链路的BPDU看Root ID是否稳定把新交换机接进去后再次抓依然稳定说明选举没有被打乱如果换成了新交换机的MAC说明新设备优先级更高它正在抢根桥。第二广播风暴刚发生时。多数人的第一反应是看哪个端口流量最大但STP视角能看得更准如果各端口的BPDU还在正常流动且Root ID一致说明根桥还在风暴大概率来自某个不支持STP的设备被接进了网络如果BPDU里出现多个不同的Root ID说明网络被切成多个互不知情的“岛屿”每个岛都以为自己是根桥。第三业务中断恢复之后。这时别急着下班把抓包打开复盘TCN的流向。如果中断30秒以上通常能看到经典STP的Listening/Learning过程如果不到一秒就恢复则要确认是不是RSTP或者有PortFast参与。下次再故障你就有基线数据可以对比。物理网络中抓BPDU的常用手段是交换机SPAN口把镜像流量引到笔记本上。和EVE-NG抓包一样过滤条件依然只用stp不要加多余的tcp或port条件。6.3 一点个人体会Wireshark和Console需要配合看最后说一个我从这套实验里得到的实际体会抓包和console一定要同时开着看。Wireshark告诉你设备在“说什么”console告诉你设备在“做什么”。比如S3的E0/1开始主动发BPDUWireshark已经能看到包了但如果不同步看S3的show spanning-tree vlan 1你没法确定这个端口当前正处于Listening还是Learning。两边一对照端口状态和报文方向立刻对应上。后来我在真实网络排障里也用这个习惯。先抓一段pcap再从交换机上确认本机认为根桥是谁、端口角色是什么。报文会说谎的情况很少但人对协议的误读很常见抓包加命令行交叉验证能过滤掉大部分错误判断。这套EVE-NG里的STP实验做完你以后再碰到环路故障至少能指着抓包软件说根桥在这里阻塞端口在这里收敛时间就是这么长。