1. 为什么以太网端口镜像和链路聚合是数通基本功的分水岭
刚入行做网络运维那几年，我总觉得端口镜像和链路聚合这两个东西没什么技术含量——一个就是把流量复制一份给分析工具，另一个就是把几根网线捆在一起用。直到有一次在客户现场，一台核心交换机上做了端口镜像，结果分析仪抓到的包全是重复的，排查了整整一个下午才发现是镜像源端口配置了双向流量复制，而分析仪接的口又恰好和另一个镜像目的口在同一个广播域里形成了环路。那次之后我才真正意识到，这两个看似简单的功能，背后涉及的是对以太网转发平面最底层的理解。
端口镜像和链路聚合，在数通领域属于那种“考试必考、工作必用、但很少有人真正吃透”的知识点。端口镜像解决的是“我怎么在不影响业务的前提下看到流量”这个问题，链路聚合解决的是“我怎么在增加带宽的同时保证可靠性”这个问题。前者是排障的眼睛，后者是架构的骨架。你要是连这两个都玩不转，后面谈什么VLAN、STP、OSPF都是空中楼阁。
这篇文章我打算把这两个技术点彻底拆开揉碎，从设计思路到配置细节，从常见坑到排查技巧，全部用我在实际项目中踩过的经验来讲。不管你是刚考完HCIA的新人，还是做了几年运维但一直没系统梳理过的老手，看完都能直接上手配、上手排。文章里涉及的命令行我会尽量用通用格式，不同厂商的设备在细节上会有差异，但底层逻辑是通的。
2. 端口镜像的核心逻辑与方案选型
2.1 端口镜像到底在做什么
端口镜像的本质，是在交换芯片的转发流水线里开了一个“分叉口”。正常情况下一份数据帧进入交换机，查表、转发、出端口，流程就结束了。做了镜像之后，交换芯片会在转发的同时，把这份数据帧复制一份送到你指定的镜像目的端口。注意，是复制，不是分流——原始流量该怎么走还怎么走，镜像流量是额外的一份拷贝。
这个“复制”动作发生在芯片内部，不占用额外的物理链路带宽，但会消耗交换芯片的背板资源。所以你在做大规模镜像的时候，比如一次性镜像十几个端口的流量到一个目的口，就要考虑目的口的带宽够不够、芯片的镜像资源够不够。我见过有人在接入交换机上把24个百兆口全部镜像到一个千兆口，结果目的口直接被打满，分析仪丢包严重，抓到的数据根本不完整。
端口镜像按方向分，有入方向镜像、出方向镜像和双向镜像。入方向镜像复制的是从源端口进入交换机的流量，出方向镜像复制的是从交换机发往源端口的流量。双向镜像就是两者都复制。这里有个细节很多人会搞混：当你镜像一个端口的入方向流量时，你看到的是“别人发给这个端口所连设备的包”；当你镜像出方向流量时，你看到的是“这个端口所连设备发出去的包”。方向搞反了，抓包分析的方向就全错了。
2.2 本地镜像和远程镜像怎么选
端口镜像按目的端口的位置，分为本地镜像和远程镜像。本地镜像就是源端口和目的端口在同一台交换机上，配置简单，延迟低，不依赖其他设备。远程镜像则是源端口和目的端口在不同设备上，需要把镜像流量封装之后通过上行链路送到远端设备。远程镜像又分两种常见实现方式：一种是基于VLAN的镜像，把镜像流量打上特定VLAN标签后泛洪到远端；另一种是基于隧道的镜像，把镜像流量封装在GRE或者类似隧道里送到远端。
选哪种方案，核心看你的分析设备放在哪里。如果分析仪就在同一机房，直接本地镜像最省事。如果分析设备在另一个机房，或者你需要把多个接入交换机的流量汇总到一台分析仪上，那就得用远程镜像。远程镜像的配置复杂度明显更高，而且对中间网络的MTU有要求——封装之后包会变大，如果中间链路MTU不够，镜像包会被分片甚至丢弃。
我个人的经验是：能本地就本地，实在不行再远程。远程镜像的故障点太多，中间任何一跳出问题，你抓到的数据就不完整。而且远程镜像的流量会占用上行带宽，如果你上行链路本来就紧张，做远程镜像就是雪上加霜。
2.3 镜像资源限制与性能考量
不同厂商的交换机对镜像会话数量、镜像源端口数量都有限制。低端交换机可能只支持一个镜像会话，源端口最多四五个。中高端交换机支持多个镜像会话，每个会话可以指定不同的源端口和目的端口。这些限制在设备手册里都有，但很多人不看手册直接配，配到一半发现资源不够，只能删了重来。
还有一个容易被忽略的点：镜像目的端口不能再参与正常业务转发。你把它配成镜像目的口之后，它就不能再作为普通接入端口用了。有些交换机甚至要求目的端口不能和源端口在同一个VLAN里，否则会产生环路。这个坑我在前面提到的那个客户现场就踩过，当时目的口和源口都在默认VLAN 1里，结果镜像流量在VLAN内泛洪，分析仪收到了大量重复包。
性能方面，你要算一笔账：如果源端口是千兆口，满速跑满1000Mbps，镜像到另一个千兆口，那目的口就被镜像流量占满了，分析仪自己的管理流量都过不去。所以实际做镜像的时候，要么限制源端口的镜像流量速率，要么给目的口留够余量。有些交换机支持镜像流量限速，可以设置只复制一定百分比或者一定速率的流量，这个功能在源端口流量很大的时候特别有用。
3. 链路聚合的技术原理与模式选择
3.1 链路聚合解决的是什么问题
链路聚合，英文叫Link Aggregation，是把多条物理链路捆绑成一条逻辑链路来用。它解决两个核心问题：一是带宽叠加，两条千兆链路聚合之后，逻辑链路带宽变成两千兆；二是链路冗余，其中一条物理链路断了，流量自动切换到剩下的链路上，业务不中断。
但这里有个误区要澄清：链路聚合的带宽叠加，不是简单地把两条千兆变成一条两千兆的管道。具体怎么分配流量，取决于你用的负载分担算法。常见的算法有基于源MAC、基于目的MAC、基于源IP、基于目的IP、基于源目IP组合、基于源目端口号组合等等。算法决定了哪些流量走哪条物理链路。如果算法选得不好，可能出现一条链路跑满、另一条链路空闲的情况，带宽叠加就名存实亡了。
举个例子，如果你用基于源MAC的负载分担，而你的流量大部分来自同一个源MAC（比如一台服务器），那所有流量都会走同一条物理链路，另一条链路完全用不上。这时候你就得换成基于源目IP或者基于源目端口号的算法，让不同会话的流量分散到不同链路上。所以负载分担算法的选择，必须结合你的实际流量特征来定。
3.2 静态聚合和动态聚合的取舍
链路聚合按协商方式分，有静态聚合和动态聚合。静态聚合就是两边手工配置，不跑协商协议，配好了就生效。动态聚合则是跑LACP协议，两边通过LACPDU报文协商，协商成功才建立聚合。
静态聚合的优点是配置简单、不依赖协议、兼容性好。缺点是如果一边配了另一边没配，或者两边配置不一致，可能出现环路或者流量黑洞。动态聚合的优点是可靠性高，协议能检测到链路故障和配置错误，自动调整聚合状态。缺点是配置稍复杂，而且需要两边都支持LACP。
我个人的建议是：如果两边设备都支持LACP，优先用动态聚合。动态聚合能帮你避免很多手工配置错误导致的问题。只有在对接一些老旧设备或者不支持LACP的设备时，才用静态聚合。用静态聚合的时候一定要仔细检查两边的配置是否完全一致，包括聚合模式、成员端口、VLAN配置等等。
3.3 聚合模式对业务的影响
链路聚合还有二层聚合和三层聚合之分。二层聚合是把多个物理口聚合成一个逻辑的二层口，这个逻辑口可以配VLAN、可以配Trunk。三层聚合是把多个物理口聚合成一个逻辑的三层口，可以直接配IP地址，作为路由口使用。
二层聚合通常用在交换机之间的互联，或者交换机到服务器的连接。三层聚合通常用在需要跑路由协议的场景，比如两台核心交换机之间跑OSPF，用三层聚合口作为互联接口。三层聚合的好处是，如果一条物理链路断了，路由协议感知不到，因为逻辑口还是UP的，流量自动切换到剩余链路，路由邻居不会中断。
这里有个细节：三层聚合口的MAC地址怎么定？不同厂商实现不一样，有的用第一个成员口的MAC，有的用系统MAC。如果聚合口MAC变了，可能会影响ARP表项和路由表项。所以在做三层聚合的时候，最好手工指定一个固定的MAC地址，避免成员口变化导致MAC变化。
4. 端口镜像实操配置与关键细节
4.1 本地端口镜像的完整配置流程
以通用命令行格式为例，本地端口镜像的配置分三步：第一步指定镜像源端口和方向，第二步指定镜像目的端口，第三步确认配置生效。
假设我们要把端口GigabitEthernet0/1的入方向流量镜像到GigabitEthernet0/24，配置大概是这样的：
# 进入配置模式 configure terminal # 创建镜像会话，指定源端口和方向 monitor session 1 source interface GigabitEthernet0/1 rx # 指定目的端口 monitor session 1 destination interface GigabitEthernet0/24 # 退出保存 end write memory这里的关键参数是rx，表示只镜像入方向。如果要镜像出方向就用tx，双向就用both。有些厂商的设备不支持both关键字，需要分两条命令分别配rx和tx。
配置完成之后，用show monitor session 1查看会话状态。输出里会显示源端口、目的端口、方向、状态是否active。如果状态不是active，检查目的端口是不是已经被其他会话占用了，或者目的端口是不是配了其他业务。
注意：目的端口配置成镜像口之后，该端口原有的VLAN配置、STP配置都会失效，它只负责往外复制流量。所以千万不要把正在用的业务口配成镜像目的口。
4.2 远程端口镜像的封装与传输
远程端口镜像的配置要复杂一些。以基于VLAN的远程镜像为例，核心思路是：在源交换机上把镜像流量打上特定的VLAN标签，然后通过Trunk口送到远端交换机，远端交换机再把该VLAN的流量送到分析仪。
源交换机上的配置大概是这样的：
# 创建镜像会话 monitor session 1 source interface GigabitEthernet0/1 both # 指定远程镜像目的VLAN monitor session 1 destination remote vlan 999 # 配置上行口允许VLAN 999通过 interface GigabitEthernet0/24 switchport mode trunk switchport trunk allowed vlan add 999远端交换机上需要把VLAN 999的流量引到分析仪所连的端口：
# 配置分析仪所连端口为VLAN 999的接入口 interface GigabitEthernet0/10 switchport mode access switchport access vlan 999这里有个关键点：中间所有经过的交换机，都必须允许VLAN 999通过，否则镜像流量到不了远端。而且VLAN 999不能和现有业务VLAN冲突，最好用一个专门的VLAN ID。
远程镜像的封装会增加包的长度，如果原始包已经是1518字节的满包，加上VLAN标签就变成1522字节，再加上可能的隧道封装，可能超过中间链路的MTU。所以做远程镜像之前，一定要确认中间链路的MTU足够大，或者把源端口的镜像包截断，只复制前N个字节。
4.3 镜像流量过滤与限速
不是所有场景都需要抓全量包。有时候你只关心特定协议或者特定IP的流量，这时候可以用镜像过滤功能。大部分中高端交换机支持在镜像配置里加ACL，只复制匹配ACL的流量。
# 创建ACL匹配特定源IP access-list 100 permit ip 192.168.1.100 any # 在镜像会话中应用ACL monitor session 1 source interface GigabitEthernet0/1 rx access-list 100限速功能也很实用。如果源端口流量很大，目的口扛不住，可以限制镜像流量的速率：
# 限制镜像流量速率为100Mbps monitor session 1 destination interface GigabitEthernet0/24 rate-limit 100这个限速是对镜像流量生效的，不影响原始流量的转发。限速的单位不同厂商不一样，有的用kbps，有的用百分比，配置前查一下手册。
实操心得：做镜像的时候，先确认目的口的带宽和源端口的实际流量。如果源端口峰值流量超过目的口带宽的70%，就要考虑限速或者换更高带宽的目的口。否则镜像包丢失，抓到的数据不完整，分析结论可能就是错的。
5. 链路聚合实操配置与负载分担调优
5.1 动态链路聚合的标准配置
以LACP动态聚合为例，两边的配置需要对应。假设我们把GigabitEthernet0/1到0/4四个口聚合成一个逻辑口，配置如下：
# 创建聚合口 interface Bridge-Aggregation 1 description Uplink-to-Core link-aggregation mode dynamic # 把物理口加入聚合组 interface GigabitEthernet0/1 port link-aggregation group 1 interface GigabitEthernet0/2 port link-aggregation group 1 interface GigabitEthernet0/3 port link-aggregation group 1 interface GigabitEthernet0/4 port link-aggregation group 1对端设备做同样的配置。配置完成后，用display link-aggregation verbose查看聚合状态。输出里会显示每个成员口的状态，Selected表示该口被选中参与转发，Unselected表示该口备用。如果所有口都是Unselected，说明协商没成功，检查两边的模式是否都是dynamic，成员口的速率和双工是否一致。
LACP有两种模式：active和passive。active模式主动发送LACPDU，passive模式被动响应。两边至少有一边是active才能协商成功。我一般建议两边都配active，这样任何一边先起来都能主动发起协商。
5.2 负载分担算法的选择与验证
负载分担算法的配置命令不同厂商差异较大，但思路是一样的。以某主流厂商为例：
# 配置全局负载分担算法为基于源目IP link-aggregation load-sharing mode source-ip destination-ip选算法的核心原则是：让你的流量特征尽可能分散到不同成员口上。如果你的流量是多个客户端访问同一个服务器，用基于源IP的算法就能把不同客户端的流量分散开。如果是同一个客户端访问多个服务器，用基于目的IP的算法更合适。如果是服务器和客户端之间有很多并发会话，用基于源目端口号的算法最均匀。
验证算法效果的方法很简单：在聚合口上查看每个成员口的流量统计，看是否均匀。
display interface GigabitEthernet0/1 | include rate display interface GigabitEthernet0/2 | include rate如果发现某个口流量明显偏高，其他口偏低，说明算法不适合当前流量特征，需要调整。
注意：负载分担算法是全局生效的，改了会影响设备上所有聚合口。所以在生产环境改算法之前，最好在测试环境验证一下，或者选择业务低峰期操作。
5.3 聚合口故障切换与回切
链路聚合的故障切换速度取决于聚合模式和硬件。动态聚合模式下，如果一条成员链路断了，LACP协议会快速感知，把该链路从聚合组中移除，流量切换到剩余链路。切换时间通常在毫秒到秒级，具体看设备性能。
静态聚合模式下，如果一条链路断了，设备只能通过物理层信号丢失来感知，切换速度也很快，但如果链路是“假死”状态（物理层UP但实际不通），静态聚合就感知不到，流量会继续往坏链路上发，导致丢包。这就是动态聚合的优势所在。
回切行为也需要注意。当故障链路恢复后，动态聚合默认会等一段时间再把它加回聚合组，避免链路震荡导致流量反复切换。这个等待时间可以配，默认一般是30秒左右。如果业务对恢复时间敏感，可以适当调小，但调太小可能导致震荡。
6. 常见问题排查与避坑指南
6.1 端口镜像常见问题速查
| 问题现象 | 可能原因 | 排查方法 |
|---|---|---|
| 分析仪抓不到包 | 源端口方向配反 | 检查是rx还是tx，确认抓包方向 |
| 抓到大量重复包 | 目的口和源口在同一VLAN | 把目的口移到独立VLAN或取消VLAN配置 |
| 镜像流量丢包严重 | 目的口带宽不足 | 查看目的口流量统计，考虑限速或换口 |
| 配置后业务中断 | 目的口误配为业务口 | 检查目的口是否被业务占用 |
| 远程镜像收不到 | 中间VLAN未放通 | 逐跳检查Trunk口允许的VLAN列表 |
重复包这个问题特别常见。除了VLAN原因，还有一种可能是源端口本身就在接收重复包——比如网络里存在环路，源端口收到了两份同样的包，镜像自然也是两份。所以抓到重复包先别急着怀疑镜像配置，用show mac address-table看看MAC地址表有没有震荡，排除环路可能。
6.2 链路聚合常见问题速查
| 问题现象 | 可能原因 | 排查方法 |
|---|---|---|
| 聚合口起不来 | 两边模式不一致 | 检查一边dynamic一边static的情况 |
| 成员口状态Unselected | 速率双工不匹配 | 检查成员口物理参数是否一致 |
| 流量分担不均 | 算法不适合流量特征 | 查看各成员口流量，调整算法 |
| 聚合后丢包 | 成员口配置不一致 | 检查成员口的VLAN、STP配置 |
| 三层聚合口MAC变化 | 成员口顺序变化 | 手工指定聚合口MAC地址 |
成员口配置不一致是个大坑。比如你把四个口加入聚合组，其中三个口配了Trunk允许VLAN 10,20，另一个口只允许VLAN 10，那这个口可能被踢出聚合组，或者流量到了这个口就被丢弃。所以加入聚合组之前，先把所有成员口的配置刷成一样的。
6.3 独家避坑经验
第一个坑：镜像目的口不要配STP。有些交换机默认在所有端口上开STP，目的口如果参与STP，可能会因为收到BPDU而进入阻塞状态，镜像流量就出不去了。配镜像目的口的时候，顺手把STP关掉。
第二个坑：链路聚合不要跨设备。除非你用的是堆叠或者M-LAG这种高级特性，否则不要把两台不同交换机的端口聚合成一个聚合组。普通链路聚合要求所有成员口在同一台设备上，跨设备聚合需要专门的协议支持。
第三个坑：聚合口上不要配QoS限速。有些厂商的聚合口不支持QoS，配了不生效或者报错。如果确实需要对聚合口限速，在成员口上分别配，或者在上层用其他方式限速。
第四个坑：镜像会话和聚合口不要混用同一个物理口。一个物理口要么做镜像目的口，要么做聚合成员口，不能同时兼任。配之前先规划好端口用途。
第五个坑：动态聚合的LACPDU报文默认不打VLAN标签，如果中间经过Trunk链路，需要确保Trunk口允许untagged报文通过，或者把LACPDU的优先级调高。有些厂商支持LACP报文带VLAN标签，配置的时候注意一下。
7. 从排障视角看镜像与聚合的联动
在实际排障场景里，端口镜像和链路聚合经常是一起用的。比如你怀疑某条聚合链路有问题，但不确定是哪条成员链路，这时候可以在聚合口的成员口上做镜像，分别抓每个成员口的流量，对比分析。
具体做法是：在聚合组的每个成员口上配一个镜像会话，目的口分别接到分析仪的不同接口上。这样你就能看到每个成员口实际转发了哪些流量，哪个口在丢包，哪个口流量异常。这个方法我在排查一个间歇性丢包问题时用过，最后发现是其中一条成员链路的光模块老化，误码率偏高，导致该链路上的包偶尔损坏。如果没有分口镜像，你只能看到聚合口的总流量，根本定位不到具体是哪条链路的问题。
另一个联动场景是：当你做远程镜像的时候，镜像流量本身可能走的就是聚合链路。这时候要注意聚合口的负载分担算法对镜像流量的影响。如果算法是基于源IP的，而镜像流量的源IP是固定的（比如都是镜像源设备的IP），那所有镜像流量都会走同一条成员链路，可能把那条链路打满。这时候要么改算法，要么给镜像流量单独走一条链路。
实操心得：做复杂排障的时候，先在纸上画清楚流量路径，标出每个镜像点和聚合点，然后再动手配。我见过太多人上来就配，配到一半发现流量路径和自己想的不一样，又得全部删掉重来。画图花五分钟，省下半小时。
8. 写在最后的一些个人体会
这两个技术点我用了快十年，到现在也不敢说完全吃透了。不同厂商的设备、不同型号的芯片，在镜像和聚合的实现细节上都有差异，每次遇到新设备都得重新翻手册。但底层逻辑是通的：镜像的核心是“复制一份流量出来但不影响原始转发”，聚合的核心是“多条链路当成一条用但流量要分散开”。抓住这两个核心，剩下的就是查手册、做实验、积累经验。
如果你刚开始接触这两个功能，我的建议是：先在自己的实验环境里把各种配置组合都试一遍，包括本地镜像、远程镜像、静态聚合、动态聚合、不同负载分担算法。试的时候故意制造一些故障，比如拔掉一条聚合成员链路，看看流量切换是否正常；把镜像目的口配错VLAN，看看重复包长什么样。这些故障现象你亲眼见过一次，以后在客户现场遇到就能秒级定位。
最后再分享一个小技巧：做端口镜像的时候，如果分析仪支持多端口抓包，可以把多个镜像会话的目的口分别接到分析仪的不同接口上，然后在分析仪上做时间戳对齐。这样你能同时看到多个点的流量，对于分析跨设备的转发问题特别有用。这个技巧我在排查一个跨交换机丢包问题时用过，效果很好，比单点抓包效率高得多。
