1. 为什么我要把端口镜像和链路聚合放在一起讲刚入行那会儿我一直觉得端口镜像和链路聚合是两码事一个用来抓包分析一个用来增加带宽和冗余八竿子打不着。直到有一次在机房里排查一个时通时断的故障我才发现这两个技术经常需要在同一台设备、同一组端口上配合使用而且配置顺序和参数选择稍有不慎就会互相干扰。从那以后我就习惯把这两个知识点放在一起梳理因为它们共同构成了以太网数据转发层面的可观测性和可靠性两块基石。这篇文章面向的是刚接触数通设备、正在准备实验或者刚上手的网络运维人员。我会从实际配置的角度出发把端口镜像和链路聚合的原理、配置步骤、参数计算、常见坑点全部拆开讲清楚。你不需要有很深的协议栈基础只要能看懂基本的交换转发逻辑就能跟着把实验做出来。文中涉及的命令以主流厂商的通用语法为参考不同设备的具体命令可能有差异但思路是通用的。先说结论端口镜像解决的是我怎么看到流量的问题链路聚合解决的是我怎么让多条链路像一条一样工作的问题。前者是观测手段后者是转发手段。把这两个搞明白你在排查环路、广播风暴、带宽瓶颈、丢包抖动这些问题时手里就有了趁手的工具。2. 端口镜像把流量复制出来看清楚2.1 端口镜像到底在做什么端口镜像Port Mirroring有些厂商叫SPANSwitched Port Analyzer核心动作就一句话把指定端口上进出的报文复制一份送到另一个端口上去。这个另一个端口通常连接一台装了抓包软件的分析设备。你可以把它想象成在一条水管上接了一个三通主管道的水照常流支管把水引出来给你观察。主管道的流量不受影响你看到的也是真实流量的副本。这个类比里有个关键点镜像口只负责送出去它不会把分析设备发回来的包再注入原链路所以不会造成流量回环。为什么需要这个功能因为交换机是二层转发设备正常情况下你没法像在共享式集线器时代那样听到所有流量。每个端口只收到发给自己的帧其他端口的流量对你不可见。要做故障定位、协议分析、安全审计就必须有一个手段把流量引出来端口镜像就是最直接的手段。2.2 镜像的几种常见类型和选型逻辑实际设备上端口镜像通常分这么几类选哪种取决于你的观测需求基于端口的镜像指定某个物理端口作为源复制它所有进出的流量。这是最常用的方式适合排查单个用户或单条上联的问题。基于流的镜像通过ACL匹配特定五元组只复制符合条件的流量。适合流量很大、你只关心某类业务报文的场景能大幅降低分析设备的压力。基于VLAN的镜像复制整个VLAN的流量。适合排查某个业务网段的整体行为但流量可能非常大要评估分析设备的接收能力。入方向/出方向/双向镜像只复制进入的、只复制发出的或者两者都复制。方向选错是新手最常见的错误之一。选型的时候我一般遵循一个原则能用基于流就不用基于端口能用单向就不用双向。原因很简单镜像流量会占用带宽和处理资源范围越小越精准对生产环境的影响就越小。曾经有个案例某位同事为了排查一个偶发丢包直接对一个万兆上联口做了双向镜像结果分析设备的千兆抓包口瞬间被打满大量丢包反而什么也没抓到。后来改成只镜像特定源IP的入方向流量问题很快就定位了。2.3 配置端口镜像的关键参数与实操下面以通用语法演示一个典型的本地端口镜像配置。假设我们要把端口G1/0/1入方向的流量镜像到G1/0/24G1/0/24连接分析设备。# 进入配置模式 configure terminal # 定义镜像源 monitor session 1 source interface GigabitEthernet1/0/1 rx # 定义镜像目的 monitor session 1 destination interface GigabitEthernet1/0/24 # 保存配置 write memory这里有几个参数需要重点解释session 1镜像会话编号一台设备可以配置多个会话但目的端口通常不能复用。source interface ... rxrx表示只镜像接收方向tx表示发送方向不写则默认双向。这个方向选择直接决定了你抓到的是什么流量。destination interface ...目的端口。这个端口在作为镜像目的期间通常不能再承载普通业务转发配置前要确认它是空闲的。注意目的端口如果之前有业务配置务必先清理干净。很多设备不允许一个端口同时作为镜像目的和普通接入端口强行配置会报错或者导致业务中断。还有一个容易被忽略的点镜像目的端口的带宽必须大于等于源端口的镜像流量峰值。如果你镜像的是一个千兆口的双向流量理论上峰值可能接近2Gbps而目的口如果也是千兆就会丢包。这种情况下要么改用基于流的镜像缩小范围要么把目的口换成更高带宽的端口。2.4 远程镜像与VLAN标签的处理当分析设备不在同一台交换机上时就需要用到远程镜像RSPAN。做法是定义一个专用的镜像VLAN把镜像流量打上这个VLAN的标签通过中继链路送到远端交换机再由远端交换机剥离标签送到分析口。这里有个实操细节镜像VLAN必须在中继链路上放通且沿途所有交换机都要配置。我踩过的坑是只配了源端和目的端中间经过的一台接入交换机没放通镜像VLAN结果流量在中间就被丢弃了排查了半天才想起来查中继的允许列表。另外如果源端口本身是Trunk口镜像出来的报文会带原有的VLAN标签。分析设备如果直接接在目的口上需要能识别这些标签否则抓包软件可能解析异常。必要时可以在目的口配置剥离标签或者让分析设备的网卡工作在混杂模式并正确解析802.1Q。3. 链路聚合让多条线拧成一股绳3.1 链路聚合解决的核心问题链路聚合Link Aggregation标准叫法是IEEE 802.3ad厂商私有实现里常叫EtherChannel、Eth-Trunk、Bond等。它把多条物理链路捆绑成一条逻辑链路带来两个直接好处第一是带宽叠加。两条千兆链路聚合逻辑上就是一条两千兆的链路。注意这里是逻辑上的叠加实际单条流的带宽仍然受限于单条物理链路因为流量是按某种哈希算法分配到各成员口的同一条流通常走同一条物理链路。第二是冗余备份。成员口中任意一条断开流量会自动切换到剩余链路业务不中断。这个切换速度通常很快因为聚合组内部有状态检测机制。为什么不用生成树协议STP来做冗余因为STP是阻断式的备用链路平时不转发流量只有主链路断了才启用带宽利用率低切换时间也相对较长。链路聚合是并行式的所有成员同时工作既利用了带宽又实现了冗余这是它最大的价值。3.2 聚合的两种模式静态与动态链路聚合分静态聚合和动态聚合两大类选哪种是个关键决策。静态聚合就是手工把几个端口加进聚合组不跑协商协议。配置简单但有个致命问题如果一端配置了聚合、另一端没配或者两端成员口数量不一致可能导致流量黑洞或环路。因为静态聚合没有协商机制设备无法感知对端的状态。动态聚合使用LACP链路聚合控制协议进行协商。两端通过LACPDU报文交换信息确认哪些端口可以加入聚合组。如果对端不支持或配置错误端口不会加入聚合避免了黑洞。生产环境我强烈建议用动态聚合多一层协商就多一层保障。LACP还有主动和被动两种模式主动模式会主动发LACPDU被动模式只在收到对方的LACPDU后才回应。一般两端至少有一端配主动否则可能协商不起来。我通常两端都配主动省心。3.3 成员口的同质性要求这是链路聚合里最容易出错的地方。要成功聚合成员口必须满足一系列同质条件要求项说明速率所有成员口速率必须一致千兆和百兆不能混聚双工必须都是全双工VLAN模式Access/Trunk模式要一致允许的VLAN列表要相同MTU最大传输单元要一致流控流控配置要一致我遇到过最典型的问题就是两条链路一条是光口、一条是电口速率协商结果不同结果聚合组起不来或者起来了但只有一个成员口在工作。所以配置前一定要用show interface之类的命令确认每个成员口的实际速率和双工状态别只看标称值。提示有些设备对成员口的物理位置有要求比如必须连续编号或者在同一块板卡上。做方案设计时要查清楚设备的硬件限制别等配置的时候才发现端口选错了。3.4 负载分担算法决定流量怎么分聚合组起来了流量怎么分配到各成员口这由哈希算法决定。常见的有基于源MAC、目的MAC、源IP、目的IP、源目IP组合、源目端口组合等。选算法的逻辑是让你的流量特征尽可能分散到不同成员口。举个例子如果你的网络里主要是多个客户端访问同一个服务器那么基于源IP的哈希能把不同客户端分到不同链路效果较好如果基于目的IP所有流量都指向同一个服务器IP哈希结果相同全压在一个成员口上聚合就白做了。# 查看当前负载分担算法 show etherchannel load-balance # 修改为基于源目IP的哈希 port-channel load-balance src-dst-ip这里有个经验聚合带宽不等于单流带宽。很多人以为做了聚合单个大文件传输就能跑到两倍速其实不然。单条TCP流经过哈希后只会走一条物理链路带宽还是单链路的上限。要真正利用聚合带宽需要多条并发流。这是做容量规划时必须清楚的。4. 两者配合使用的实战场景4.1 场景还原上联聚合链路的流量分析回到开头提到的那个故障。拓扑是这样的一台接入交换机通过两条千兆链路聚合上联到核心交换机用户反映业务时通时断。我要抓包分析但流量跑在聚合链路上怎么抓如果直接对聚合口做镜像有些设备支持有些不支持。更稳妥的做法是对聚合组的每个成员口分别做镜像把两条成员口的流量都送到同一个分析口。这样能完整还原聚合链路上的所有流量还能顺便观察流量在两条成员口上的分布是否均衡。配置思路如下# 对成员口1做入方向镜像 monitor session 1 source interface GigabitEthernet1/0/23 rx monitor session 1 destination interface GigabitEthernet1/0/24 # 对成员口2做入方向镜像使用另一个会话 monitor session 2 source interface GigabitEthernet1/0/24 rx monitor session 2 destination interface GigabitEthernet1/0/25注意这里目的口不能复用所以用了两个分析口或者用支持多源单目的的设备把两个源指向同一个目的。抓到的两份数据在分析时按时间戳合并就能看到完整的聚合链路流量。那次故障最后定位到的是两条成员口的负载分担算法配置不一致一条基于源MAC、一条基于目的MAC导致部分流的往返路径不对称触发了上游设备的某种保护机制。把算法统一后问题消失。这个案例说明聚合组的配置一致性不仅体现在成员口参数上连负载分担算法这种软配置也要对齐。4.2 镜像流量对聚合链路的影响评估做镜像的时候要评估对生产流量的影响。镜像动作本身会消耗设备的CPU和背板带宽。如果在一台已经满负荷的交换机上对聚合口做双向镜像可能成为压垮骆驼的最后一根稻草。我的做法是先估算镜像流量的大小再决定镜像范围。可以用设备自带的流量统计命令查看源端口的实际速率如果峰值已经接近端口带宽的70%就要谨慎优先考虑基于流的镜像。另外镜像最好在业务低峰期配置和调试避免影响生产。还有一个细节如果聚合链路上跑的是存储流量或者语音流量对时延和抖动敏感镜像带来的额外处理开销可能引入微小的时延变化。虽然通常影响很小但在极端敏感的场景下要纳入考虑。5. 常见问题与排查技巧实录5.1 端口镜像常见问题速查现象可能原因排查方法抓不到任何包源端口选错、方向选错、目的口未up检查session配置确认目的口link状态只能抓到单向流量只配了rx或tx改为双向或补配另一方向抓包大量丢包目的口带宽不足换高速口或缩小镜像范围镜像口业务中断目的口被占用清理目的口原有配置远程镜像无流量中间设备未放通镜像VLAN逐跳检查中继允许列表5.2 链路聚合常见问题速查现象可能原因排查方法聚合组起不来成员口参数不一致逐项比对速率、双工、VLAN、MTU只有一个成员口转发哈希算法导致或对端配置问题检查算法检查对端聚合配置聚合后丢包成员口质量差或负载不均查看各成员口错包计数和流量分布切换慢用了静态聚合或检测机制慢改用LACP调整超时时间聚合后环路一端聚合一端未聚合统一两端配置启用LACP5.3 几个我踩过的坑坑一镜像目的口配了生成树。目的口如果参与了STP可能因为收到镜像流量里的BPDU而进入阻塞状态导致镜像失效。解决办法是在目的口关闭STP或者配置BPDU过滤。坑二聚合成员口跨板卡。有些设备跨板卡的端口做聚合流量在板卡间转发会消耗背板带宽性能反而不如单板卡内聚合。如果设备支持堆叠跨设备的聚合还要考虑堆叠链路的带宽瓶颈。坑三LACP超时时间用默认值。默认是慢速30秒链路故障后切换较慢。对切换时间敏感的场景可以改成快速1秒但要注意快速模式下如果链路质量差、频繁抖动可能导致端口反复加入退出聚合组反而更不稳定。坑四镜像和聚合配置顺序。如果先配了聚合再对成员口做镜像有些设备会提示端口已被聚合组占用。正确顺序是先做镜像配置或者对聚合逻辑口做镜像如果设备支持。这个顺序问题在实验环境里不明显但在生产设备上可能直接报错。6. 参数计算与容量规划的实际操作6.1 聚合带宽的估算假设你有4条千兆链路做聚合理论总带宽是4Gbps。但实际可用带宽要打折扣哈希不均导致的浪费如果流量特征单一可能只有1到2条链路在工作实际带宽远低于4Gbps。协议开销LACPDU报文占用少量带宽可忽略。单流上限单条TCP流最大约1Gbps受单链路限制。所以做容量规划时我一般按**理论带宽的60%到70%**来估算实际可用带宽除非能确认流量特征足够分散。6.2 镜像流量的带宽需求镜像流量 源端口流量 × 镜像方向数。双向镜像就是源端口双向流量之和。如果源端口是千兆口双向峰值接近2Gbps目的口至少要2Gbps以上否则丢包。实际配置中如果目的口只有千兆就必须缩小镜像范围。可以用基于流的镜像只抓特定业务或者只抓单向。我通常先用show interface看源端口的实际速率再决定镜像策略。6.3 一个完整的配置示例下面是一个把端口镜像和链路聚合结合起来的完整配置示例场景是接入交换机通过两条千兆链路聚合上联同时要对聚合成员口做入方向镜像用于分析。# 第一步配置链路聚合 configure terminal interface range GigabitEthernet1/0/23-24 channel-group 1 mode active no shutdown exit interface Port-Channel1 switchport mode trunk switchport trunk allowed vlan 10,20,30 exit # 第二步配置端口镜像 monitor session 1 source interface GigabitEthernet1/0/23 rx monitor session 1 destination interface GigabitEthernet1/0/24 monitor session 2 source interface GigabitEthernet1/0/24 rx monitor session 2 destination interface GigabitEthernet1/0/25 # 第三步验证 show etherchannel 1 summary show monitor session 1 show monitor session 2 write memory配置完成后用show etherchannel 1 summary确认聚合组状态是SUsuspended表示有问题用show monitor session确认镜像会话正常。然后在分析设备上抓包验证能否看到预期的流量。注意不同厂商对镜像会话数量和目的口复用的支持不同。有的设备支持多个源指向同一个目的口有的不支持。配置前查一下设备的规格说明别想当然。7. 我个人的几点实操体会做网络这行配置命令本身不难难的是理解每个参数背后的取舍以及在生产环境里控制风险。端口镜像和链路聚合这两个技术我用了这么多年最大的体会是先想清楚你要解决什么问题再决定怎么配。镜像的时候永远先问自己我要看什么流量而不是我把所有流量都抓下来再说。范围越小对生产影响越小分析效率越高。聚合的时候永远先确认两端配置是否对称不对称的聚合比不聚合还危险。还有一点实验环境和生产环境差别很大。实验里随便配都能通生产里一个参数不对可能就是业务中断。所以任何配置变更前先在实验环境验证变更时准备好回滚方案变更后立即验证业务。这个习惯比任何技术细节都重要。最后分享一个小技巧如果你不确定镜像方向选rx还是tx可以先两个方向都配上抓一次包看看流量特征确认后再精简。虽然多抓一点流量但比反复试错效率高。聚合的负载分担算法也一样先用默认的观察各成员口流量分布不均衡再调整算法用数据说话而不是凭感觉。
