1. 为什么要在核心交换机上做端口镜像1.1 端口镜像到底解决了什么问题做网络运维的人迟早会碰到这样一个需求业务部门反馈某个应用特别慢或者安全团队怀疑内网有异常流量这时候你手里没有专业的流量分析设备也没法在服务器上装抓包工具怎么办最直接的办法就是在交换机上把某个端口的流量复制一份出来送到分析仪器、电脑或者安全设备上这就是端口镜像。华为交换机16700系列作为数据中心核心设备承担着南北向和东西向的大部分流量汇聚转发任务。在这种位置配置端口镜像本质上不是复制流量这么简单而是要解决一个核心矛盾业务不能中断流量却必须可见。你不可能把核心链路拔下来串一个分光器也不能在核心设备上随便加策略影响转发性能端口镜像几乎是唯一既不影响业务又能拿到原始报文的手段。我见过不少刚接触核心交换机配置的人觉得端口镜像不就是把A口流量复制到B口吗实际上在16700这种级别的设备上事情远没有这么简单。你面对的是几十个100GE甚至400GE接口的高密度转发设备镜像的粒度、方向、带宽匹配、观察口的位置选择每一个环节都可能让整份配置失效甚至引发转发问题。这篇文章就围绕16700系列把端口镜像从原理到实战命令再到排错经验完整梳理一遍。1.2 哪些场景必须用端口镜像而不是抓包很多人会问服务器上直接tcpdump不就能抓包吗为什么要费劲在交换机上配置镜像这个疑问我理解但实际生产环境里需要镜像的场景恰恰是那些没法在终端上抓包的情况。第一类是安全审计场景。你部署了IDS、IPS或者网络回溯分析系统这些设备必须被动接收全量流量才能工作。它们不能串联在链路上串联会影响时延和可用性只能通过旁路方式接入。旁路接入的数据从哪来就是交换机的镜像端口。第二类是故障定位场景。业务侧说丢包了时延高但服务器上的抓包只能看到本机视角的报文看不见交换机转发层面的情况。尤其是跨机房的访问路径中间经过好几跳设备只有在核心交换机上做镜像才能拿到一个中立视角的完整报文判断丢包到底发生在哪一段。第三类是容量规划场景。想搞清楚某个业务链路到底跑了多少流量、峰值出现在什么时间用NetStream/sFlow做采样统计是可以的但采样有精度损失。要精确分析就得靠镜像做全量流量统计。16700这种设备常用于数据中心核心做容量评估时镜像是很常规的手段。如果你遇到的场景只是单机调优那直接在服务器上抓包完全够用。但一旦涉及多设备路径、安全审计、全量流量分析端口镜像就是绕不开的配置项。2. 16700镜像机制拆解本地镜像、远程镜像与流镜像怎么选2.1 三种镜像模式的能力边界开始敲命令之前先把机制讲清楚。华为数据中心交换机16700系类的端口镜像按实现方式分三类我做过一张选型对比表先放在这里镜像类型适用场景传输范围观察端口要求典型带宽复杂度本地端口镜像单台设备内抓包分析本机内本机任意空闲口与源端口匹配低远程端口镜像(RSPAN)流量汇聚到远端分析设备跨设备二层网络远端设备端口受中间链路限制中流镜像(基于ACL)只挑感兴趣的业务流量本机或远端同本地/远程大幅减少镜像量中高本地端口镜像最常用配置也最简单。它的逻辑就是把指定接口的入方向、出方向或者双向流量复制一份送到本机指定为观察端口的接口上。适用场景就是分析仪、笔记本直接接到这台16700的某个空闲口然后对业务口做镜像。远程端口镜像也就是RSPAN解决的是分析设备不在同一台设备上的问题。比如你有一台集中的流量分析服务器放在机房某一侧所有核心交换机的镜像流量都要送到那里。这时需要在16700上定义远程镜像VLAN镜像流量通过二层网络穿越中间设备最终在远端设备上落地。配置比本地镜像多两步但跨设备汇聚能力很强。流镜像是基于ACL匹配特定报文特征的镜像。它不关心端口而是关心流量内容——比如只镜像源IP是某个网段的流量或者只镜像访问特定端口如443的HTTPS流量。这种模式在流量量级大、分析设备性能有限的情况下特别好用能显著降低镜像链路的带宽压力。选型逻辑说白了就一条分析设备和被监控流量在不在同一台设备上以及你到底需不需要全量流量。不需要全量就选流镜像需要跨设备汇聚就选RSPAN简单场景本地镜像就够了。2.2 观察端口带宽与镜像方向的选型逻辑配置镜像之前对带宽的估算是很多人忽略但非常关键的一步。我见过不少案例镜像配完一时爽跑了两小时业务高峰分析仪那边收到的报文全是乱的一问原因观察口带宽不够在交换机内部就直接丢包了。镜像方向有三种ingress入方向、egress出方向、both双向。如果镜像双向流量且业务口带宽接近满负荷观察口实际承载的流量就是两倍的关系。举例来说你镜像一个10GE业务口的both方向流量假设线速跑到8Gbps那么观察口至少要16Gbps的能力——你用10GE口做观察口必然是丢包的。16700系列设备上选择观察口时我建议遵循两个原则。第一观察口带宽要大于等于镜像源口带宽的两倍如果配置both方向。比如镜像源是100GE口观察口最好用100GE或更高不要拿25GE口去接。第二观察口不要配置任何业务的IP地址和VLAN它就是一个纯旁路口一旦参与业务转发镜像流量和业务流量就会互相干扰严重时还会造成环路。镜像方向的选择也要结合需求来看。只想分析服务器收到的请求就镜像入方向只想看服务器返回的响应就镜像出方向做全链路会话分析那就both。没有明确需求时我一般建议先用both抓全量拿到数据后再逐步过滤比一开始就限定方向更稳妥。3. 本地端口镜像一步步配置3.1 配置前的规划在实际配置16700之前先把三件事确认好被镜像的接口是哪一个、它的流量方向怎么选、观察口接什么设备。以我的经验这时候最稳妥的做法是先体检一下设备当前状态。登录设备后先用display interface brief看一下接口状态和光模块信息确认你要镜像的接口确实在正常转发流量再确认作为观察口的接口是up状态且没有在用的业务配置。然后规划一下接口编号。16700作为框式设备接口编号格式通常是100GE1/0/1这种三段式第一段是槽位号第二段是子卡号第三段是接口号。不同版本和板卡类型可能有差异敲命令前最好先display interface brief确认实际编号避免配错接口。规划表可以参考这样规划项示例说明镜像源接口100GE1/0/1承载业务流量的接口镜像方向both入方向出方向全部镜像观察口100GE1/0/24空闲口不参与业务对端分析设备笔记本WiresharkIP配置为同网段即可3.2 命令级配置下面进入关键部分完整的本地端口镜像配置命令。16700系列用的是华为CE系列命令行风格核心命令分为两步第一步定义观察端口第二步在被镜像接口上应用。登录设备进入系统视图system-view配置观察端口将100GE1/0/24指定为观察端口编号1observe-port 1 interface 100GE1/0/24进入被镜像的业务接口100GE1/0/1interface 100GE1/0/1配置镜像到观察端口方向为bothport-mirroring to observe-port 1 both退出接口视图检查配置quit display observe-port display port-mirroring这四步就是本地端口镜像的最小配置集。执行完后100GE1/0/1口进出的所有报文都会复制一份从100GE1/0/24口送出去对端接的Wireshark或分析设备就能收到数据。需要注意一个细节port-mirroring to observe-port 1 both这条命令你可以在接口视图下反复执行来调整方向但如果要取消镜像用的是undo port-mirroring to observe-port 1。取消时不需要带方向参数直接整体撤销华为的命令设计里这条是幂等的。3.3 配置验证与抓包对接配置完成后千万别直接跑先用命令验证。我习惯按下面的顺序检查display observe-port这条命令会列出所有已定义的观察端口及其属性。确认观察口编号、实际物理接口是否对应。display port-mirroring这条命令会列出所有被镜像接口与观察端口的绑定关系包括接口名、方向、观察端口ID。看到你配置的绑定关系出现在输出里这一步才算完成。接下来接上分析设备做实际抓包验证。观察口对端如果接的是笔记本记住给网卡配上和观察口同一个二层域的IP或者直接把分析端口的网卡设置为混杂模式。我在Wireshark里抓包时会把捕获过滤器设置成host 目标IP或tcp.port 80这种先快速确认能不能看到业务报文再决定是否做全量采集。如果发现抓不到包不要急着怀疑镜像配置。先确认分析设备网卡是否为up状态、是否启用了混杂模式再看观察口光模块和线缆是否正常。我培训新人时常说一句话镜像配置只有和物理链路同时正确流量才能真正从观察口出去。4. 远程镜像和流镜像的进阶玩法4.1 RSPAN远程镜像配置本地镜像的局限是分析设备必须物理连接到被镜像的交换机上。在数据中心场景里分析设备往往集中部署比如统一的安全分析平台放在独立管理网段核心交换机镜出来的流量要通过二层网络送到汇聚端的分析口。这时候就要用远程端口镜像RSPAN。RSPAN的核心概念是远程镜像VLAN。源交换机把镜像流量打上特殊VLAN标签通过trunk口送到中间网络上目的交换机在远端把该VLAN的流量解出来从指定观察口送出。在16700上配置RSPAN第一步是创建远程镜像VLAN假设用VLAN 100vlan 100 remote注意这里的remote关键字它把这个VLAN标记为远程镜像专用VLAN。配置完成后这个VLAN就不能再当作业务VLAN使用否则会造成未知流量泛洪混乱。第二步在源交换机上把镜像流量引入该VLAN同时在trunk口放通VLAN 100observe-port 1 interface 100GE1/0/24这里说明一下RSPAN的观察口其实是一个逻辑概念。在华为CE系列上远程镜像的最终出口是由目的交换机的物理端口决定的。源交换机的trunk口负责把VLAN 100的流量送往远端。interface 100GE1/0/2 port link-type trunk port trunk allow-pass vlan 100第三步在源设备上把被镜像接口的流量应用到观察端口interface 100GE1/0/1 port-mirroring to observe-port 1 both第四步在目的交换机上也定义远程镜像VLAN和物理出口vlan 100 remote # observe-port 2 interface 100GE1/0/24这里注意编号可以不同关键是VLAN要对上。然后在目的交换机上把VLAN 100的流量映射到观察口interface 100GE1/0/24 port link-type access port default vlan 100 quit interface 100GE1/0/24 port-mirroring to observe-port 2不同版本下远程镜像的收尾命令略有差异有的版本需要配置mirror-vlan绑定有的版本直接在目的交换机上配置远程镜像VLAN和解封装即可。配置前一定先用display version确认版本再查对应版本的配置手册不要照搬网上的老命令。RSPAN配置里最容易出问题的点是中间链路的VLAN透传。镜像流量经过中间交换机时如果中间设备没有放通VLAN 100流量到不了目的端。我排查过最头疼的一个案例就是中间设备做了端口隔离RSPAN VLAN被隔离开来镜像流量进了设备就丢了。4.2 流镜像只挑你需要的流量全量镜像在流量不大时没什么问题但核心链路上经常是动辄几十Gbps的流量分析设备根本吃不下。流镜像就是为解决这个问题设计的通过ACL规则匹配特定流量只把匹配到的部分复制到观察口。这种场景很典型某天安全设备提示有服务器在和外部异常IP通信你只需要抓这个IP的会话而不是整条链路的全量流量。流镜像配置的核心是全局流策略。第一步定义ACL匹配规则。我用基本ACL或高级ACL都可以看你想匹配什么条件。假设匹配目的IP为192.168.1.0/24网段的流量acl number 4000 rule 5 permit ip destination 192.168.1.0 0.0.0.255第二步定义流分类把ACL关联上traffic classifier c1 if-match acl 4000第三步定义流行为动作是镜像到指定观察口traffic behavior b1 mirroring to observe-port 1第四步定义流策略把分类和行为绑定traffic policy p1 classifier c1 behavior b1第五步在接口上应用流策略。注意方向选择比如只在入方向应用interface 100GE1/0/1 traffic-policy p1 inbound执行完这条后只有匹配ACL 4000的入方向流量才会被镜像。这样分析端收到的数据量会小很多同时保证关注的重点流量一条不漏。流镜像是个好东西但要注意ACL规则不要写得太宽泛否则过滤效果不明显。另外流行为mirroring to observe-port在部分版本上需要和观察口配合使用如果设备提示观察口不存在说明要先完成第一章节里observe-port的定义。5. 镜像配置踩坑实录问题定位与修复5.1 观察口带宽被打满导致反复丢包先说一个我真实踩过的坑。有次给一台16700配置镜像被镜像口是100GE双向跑满差不多50Gbps我图省事找了个空闲的40GE口做观察口接的是数据分析平台的40GE网卡。配置完的前半小时一切正常但一到业务高峰分析平台那边就疯狂报警说丢包率超过5%。最开始我怀疑是分析平台服务器性能不够但检查CPU和内存都正常。后来在交换机上查display observe-port发现观察口的discard计数一直在涨。这下基本确定了观察口带宽不够交换机在复制流量时直接在出接口上丢了报文。解决办法只能从两方面下手要么把观察口换成100GE口要么减少镜像流量总量。当时分析平台只关心特定几个业务网段的流量我就把全量镜像改成了ACL流镜像只镜像那几个网段的报文实测观察口带宽从45Gbps降到了8Gbps问题立即解决。这个案例给我的教训是配置镜像前必须算清楚观察口的带宽余量。如果观察口带宽小于镜像流量峰值无论配置多正确丢包都是注定的。5.2 配置后出现环路告警还有一次配置完成后设备报STP拓扑变化告警业务也出现间歇性卡顿。登录设备一查原因是观察口被配置了业务VLAN并且接入了现网交换机等于把镜像出去的流量又回到了业务网络里形成了第二层环路风险。华为设备其实有保护机制正常情况下CE交换机的观察口是不能跑STP的但如果手动把观察口改为trunk口并放通了业务VLAN这个保护就被绕过了。这里给一个非常明确的建议观察口必须保持access口属性不划分任何业务VLAN不通任何业务。它存在的唯一意义就是把数据吐给分析设备不该参与任何转发决策。配置完成后用display port-mirroring查看观察口的端口属性确认是access且default vlan不是业务VLAN。5.3 镜像流量出现乱序有次用户反馈分析平台收到的数据包顺序完全不正常TCP会话无法重组。排查后发现是我们在两台设备上做了堆叠被镜像的业务口和观察口不在同一台成员设备上跨框转发引入了额外的处理时延导致镜像报文乱序。华为堆叠场景下观察口和镜像源口推荐选在同一台成员设备上这样可以避免跨框交换。如果实在没法避免就要确认交换矩阵的带宽余量足够否则跨框镜像在高流量下还会有丢包风险。排查乱序问题的时候我建议用分析端的Wireshark查看TCP序列号规律。如果序列号整体连续但时序错乱说明是设备转发路径不一致导致的优先调整镜像源口和观察口的物理位置。如果发现序列号有跳变那就要回到第5.1节的带宽问题上查丢包了。5.4 配置丢失镜像配置本身不难难的是它经常和设备重启、主备倒换这种操作纠缠在一起。有次设备升级重启后镜像配置全部丢失业务倒没影响但监控平台全盲了。华为16700的镜像配置默认保存在设备flash里前提是你在配置完成后执行了save。但有些镜像相关配置特别是ACL流镜像的流策略如果当时没有同步到配置文件重启后就会丢。我习惯的保存顺序是save y然后检查配置文件里是否有相关内容display current-configuration | include observe-port display current-configuration | include port-mirroring display current-configuration | include traffic-policy这三条命令输出里都有内容说明配置已经持久化了。如果第二条或第三条为空说明流策略或镜像绑定没有保存成功需要重新配置。另外提一句16700系列配置镜像的配置量不大但涉及ACL时配置文件里可能还有其他业务ACL规则用include过滤查看时注意区分别把不相干的ACL规则当成镜像配置带进来。6. 事后验证与日常运维建议6.1 完整的验收流程配置完成后把这几个验证步骤走完才算真正交付第一验证观察端口确实能收到流量。display observe-port能看到观察口的报文计数在增长。这个计数器涨得快慢取决于镜像流量大小。如果计数器完全不动大概率是镜像源口没有流量或者方向配错了。第二验证分析设备能正常解码。接上分析设备后确认能通过Wireshark或其他分析工具看到报文并且源目MAC、IP都符合预期。很多次我们发现镜像配置没问题但分析设备本身网卡没有开启混杂模式导致收不到报文这一步能避免误判交换设备问题。第三验证镜像对业务无影响。观察业务口的转发计数和时延指标确认镜像没有造成额外丢包。我通常会在镜像后对比配置前后的接口丢包计数如果镜像后丢包计数持续上涨就要考虑带宽或硬件资源问题。这三个步骤中第一步和第三步要在交换机上验证第二步在你的分析工具上验证三者缺一不可。6.2 长期运维中的资源监控镜像配置不是配完就完事长期运行中要定期关注观察口的健康状况。建议把下面几个指标加入监控平台的告警项观察口带宽利用率持续超过70%就要考虑扩容或分流观察口discard计数持续增长说明已经在丢包被镜像接口的丢包计数镜像后如果开始丢包优先排查是否是镜像本身占用了转发资源设备的CPU占用率在16700这种核心设备上过度镜像确实可能影响主控CPU如果CPU持续飙升就要审视镜像策略是否过于激进我在帮客户做运维巡检时会把端口镜像也列入月度巡检项。这不是小题大做——镜像资源占用的异常往往是核心交换机故障的前兆。6.3 一份快速可抄的配置模板最后整理一份可复制的配置模板。以下命令适用于本地端口镜像场景按顺序粘贴即可实际环境注意替换接口编号system-view observe-port 1 interface 100GE1/0/24 interface 100GE1/0/1 port-mirroring to observe-port 1 both quit save y远程镜像模板system-view vlan 100 remote quit observe-port 1 interface 100GE1/0/24 interface 100GE1/0/2 port link-type trunk port trunk allow-pass vlan 100 quit interface 100GE1/0/1 port-mirroring to observe-port 1 both quit save y流镜像模板system-view observe-port 1 interface 100GE1/0/24 acl number 4000 rule 5 permit ip source 192.168.1.0 0.0.0.255 quit traffic classifier c1 if-match acl 4000 quit traffic behavior b1 mirroring to observe-port 1 quit traffic policy p1 classifier c1 behavior b1 quit interface 100GE1/0/1 traffic-policy p1 inbound quit save y6.4 我个人踩过坑之后的几点体会最后分享几条实操心得。第一镜像命令本身很简单难的是理解网络拓扑和业务模型。同样的镜像需求在不同组网下配置方法完全不同先搞清楚拓扑再动手敲命令能省掉大量排查时间。第二不要过度镜像。我有段时间养成了先全部镜像再说的习惯结果核心设备CPU压力明显上升。后来改成按需镜像、用完即删设备健康状态好了很多。生产设备上任何额外功能都有代价端口镜像也不例外。第三文档和注释非常重要。16700项目里往往是多个团队共用一台设备你今天配的镜像可能影响别人的监控。最好在配置里加上清晰的接口描述用description命令标注这些接口是做什么用的避免后来者误改或者误删。我在每个被镜像口上面都会写一行description mirrored-to-analyzer观察口写description observe-port-for-XXX这个小习惯帮我避免了好几次误操作。配置好端口镜像抓住一次棘手的故障或者让安全设备顺利上线那种感觉还是挺值得的。希望这篇操作手册能帮你少走一些弯路一次配置成功。
