1. 802.1ag CFM 是什么解决二层网络的什么痛点1.1 以太网“看得见连不上”的尴尬做网络这一行久了你会发现一个特别拧巴的现象只要故障定位到二层原本清晰的思路一下子就乱了。拿最基础的场景举例两台交换机之间用光纤连着端口状态都是UPVLAN也都放行了但业务就是不通。你坐在电脑前抓包一眼望去全是广播报文在飘单播帧怎么发出去就怎么消失好像被黑洞吸走了一样。这时候如果手里只有传统的三层工具基本就得靠猜而且是拿着放大镜在拓扑图上一处处瞎找。所以当我第一次接触IEEE 802.1ag CFMConnectivity Fault Management连通性故障管理的时候第一反应就是早该有这东西了。CFM是在以太网数据链路层实现的一套运维协议它不依赖IP不依赖ICMP不依赖交换机上那半吊子命令行只认MAC地址、VLAN和协议定义好的维护域。你可以把它理解成给“以太网链路”本身配了一套ping和traceroute工具专门用来回答两台设备之间二层到底通没通、中间每跳是谁、断在哪一跳这三个最折磨人的问题。这篇文章是我做Wireshark抓包实战和网络排障时的笔记整理围绕802.1ag CFM展开适合三类人看一是搞运营商以太网和城域接入网交付的工程师二是企业内部网络需要跨交换机、跨机房排查二层链路的人三是正在啃Wireshark协议解码、想深入理解以太网故障定位机制的学生或测试工程师。看完你至少能上手配CFM、看懂抓到的报文并照着我的思路定位一次真实的二层断点。1.2 和传统 ICMP 工具的本质区别很多人刚开始容易把CFM和Ping搞混觉得不都是发个探测包看有没有回应吗。差远了。我们先明确一个概念ICMP Echo是三层工具它要求路径上的设备具备三层转发能力并且中间设备不能把回包丢弃。但现实中二层交换机转发纯二层帧的时候根本不看IP头很多哑交换机连IGMP、ARP都懒得处理更谈不上回应你的Ping。所以你会发现电脑Ping网关是通的网关Ping核心也是通的但从核心Ping一个二层接人的傻瓜设备死活没反应。这时候你没法判断到底是链路断了还是设备压根不支持三层。CFM就不一样它工作在EtherType 0x8902插入到以太网帧头之后和MAC地址、802.1Q VLAN标签同生存周期。只要端口UP、VLAN匹配、协议层能识别它就处理。路径上的每一个交换机都可以配置成维护中间点也就是MIP收到探测报文就能回LTR链路两端的配置节点叫MEP负责发起和终结各种CFM报文。整个体系独立于IP栈哪怕交换机没有管理IP只要转发引擎支持CFM就能参与故障检测。拿最常见的两个动作对比动作传统Ping802.1ag CFM工作层级三层IPICMP二层以太网帧内依赖条件三层可达、支持ICMP回应端口UP、VLAN匹配、支持CFM路径中每一跳可感知基本不能只能看到最终结果通过MIP逐跳响应可定位断点适用场景三层网络连通性验证二层网络/VPLS/VXLAN等基础设施验证这个区别在做大型以太网专线交付时尤其明显。用户报障说总部和分支二层不通你用Ping试了一下网关通了然后就没有然后了。换成CFM你可以直接在两端的MEP之间发起Loopback立刻得到这条二层链路是否端到端可用。如果还不行再发个Linktrace看中间每一跳谁应答了、谁没应答故障点几乎一秒锁定。1.3 核心组件MD、MA、MEP、MIPCFM概念里有一套让人头大的缩写但别怕拆开就很简单。MDMaintenance Domain维护域一个逻辑管理边界比如企业网、接入网、运营商骨干网各算一个域。域有层级从0到7数字越小层级越低位置越靠近用户数字越大层级越高越靠近核心。层级的意义在于让不同运营商的CFM报文互不干扰就像小区物业和市政管网各自管各自的不会因为物业要把楼道灯关了就影响整条路的供电。MAMaintenance Association维护关联在维护域里针对某个VLAN或某种服务实例建立的检测集合。你可以理解成针对一条具体业务通道建立监控台账。MEPMaintenance End Point维护端点域的边界点。CFM的CCM报文、Loopback报文都由MEP发起也只有MEP能终结。MEP有方向性要么面向客户侧要么面向网络侧。MIPMaintenance Intermediate Point维护中间点域内部的中间节点。MIP不主动发报文但会响应Linktrace报文并转发CCM和Loopback报文。层级这个概念刚开始容易糊涂。简单类比一个跨省专线承载着企业两个园区的VLAN 100业务运营商网络内部建了一个MD Level 3的维护域在两端PE设备上建MEP企业自己也想检测这段链路于是在客户侧交换机上建MD Level 0的维护域。两端MEP的Level只要定好就互不干扰不会出现客户的探测报文被运营商MIP截胡回包的情况。2. 四种报文逐个拆解CCM、LBM/LBR、LTM/LTR2.1 CCM 连续性检查报文CCMContinuity Check Message是CFM体系里最常用的心跳报文。MEP会按照配置的周期定时向对端MEP发送CCM对端MEP收到后就知道链路还活着。CCM携带一个关键字段叫“间隔”可选3.33ms、10ms、100ms、1s、10s等等周期越短故障发现越快但对CPU和带宽消耗也越大。生产环境一般用1s或10s保护倒换类场景才用亚秒级。看一个典型CCM报文Wireshark里打开会看到MD Level标识当前报文所属维护域层级。Version固定为0。OpCodeCCM固定是0x01。Flags最低位是RDIRemote Defect Indication。当MEP在连续超时后检测到对端故障就会在CCM里置位RDI告诉对端方向“我这边收不到你了”。这在单向链路故障时特别有用。MAIDMaintenance Association Identifier维护关联标识由MD名字MA名字拼成。两端的MEP只有MD Level、MAID一致才能把彼此识别为同一个维护关联里的节点。不一致就意味着配错域了CCM能自动发现这种错配。MEPID本地维护端点的编号用来区分同一个MA里哪个MEP发的。Sequence Number递增序号Wireshark可以帮你算出有没有丢包。Interval发送周期。Meg Level从报文里还能看到维护实体组级别个别厂商叫MEG Level和MD Level一回事别被绕晕。我一般抓CFM报文第一眼就看OpCode和MD Level配合过滤条件cfm.interval快速核对两端配置的CCM周期是否一致。如果对端配置了200ms本地配置了1s抓包看到对端的CCM每0.2秒一条本地的每1秒一条链路通着但两边的超时判断会非常容易误报。Wireshark在这种场景下甚至可以当作配置校验工具来用。2.2 LBM 与 LBR 环回测试LBMLoopback Message和LBRLoopback Reply合起来就是“以太网二层Ping”。LBM由源MEP发出目的地址可以是一个远端MEP的MAC也可以直接填一个组播MAC目标MEP收到后本应回LBR。收到LBM的MEP会校验MD Level、MAID等信息匹配然后生成一条LBR原路返回。如果链路有任何问题LBR就回不来。报文结构和CCM一样也有MD Level、Version、OpCode。区别是OpCode LBM为0x02、LBR为0x03中间有个关键的Transaction Identifier字段相当于ICMP Echo的Identifier和Sequence Number用来将请求和应答配对。Wireshark里用cfm.opcode 0x02 || cfm.opcode 0x03过滤后可以看到每个请求对应一个回复。实测经验如果两条链路做的是负载均衡或者聚合口LBM的发出接口和LBR的返回接口可能不是同一个中间路径不一致会丢包。做丢包率判断的时候要把抓包点放在源MEP的入端口和出端口同时看不要只看一个方向。另外还要注意LBM是带VLAN的和业务VLAN绑定。你发LBM时指定VLAN 100报文就带着VLAN 100的Tag出去。如果中间某台交换机没有放行VLAN 100LBM就断在半路LBR自然回不来。这一点特别适合排查那种“端口状态正常但业务VLAN被误删”的意外情况。2.3 LTM 与 LTR 链路追踪LTMLinktrace Message和LTRLinktrace Reply是CFM里最有价值的traceroute工具。它的原理是源MEP发出一个LTM报文目的MAC指向远端MEPTTL这里叫Hop Count从64或255开始递减。路径上的每个MIP收到LTM后会复制一份报文记录自己的MAC和入端口然后生成LTR回给源MEP同时把原始LTM的Hop Count减1继续转发。最终目的MEP收到后自己也回一条LTR。源MEP把所有LTR汇总就能得到一条完整的二层路径类似traceroute一条条显示中间路由器IP的效果。LTM OpCode是0x04LTR OpCode是0x05。LTR里最值得关注的字段有两个Reply Reliability是否成功转发给了下一跳。Relay Action标识接收者做了什么动作比如是MEP终结、MIP转发、还是被丢弃。抓LTM/LTR的时候我把Wireshark过滤器设置成cfm.opcode 0x04 || cfm.opcode 0x05然后按Transaction Identifier排序就能看到同一次探测经过的所有跳。每一跳的LTR里都有源MAC、Ingress Action等字段对照拓扑图一查哪一跳没回哪一跳显示转发失败故障点直接压到物理端口这个粒度。3. Wireshark 抓包实战过滤器、面板与报文关键字段3.1 抓包前的准备工作和过滤器先提醒一句CFM报文不是默认就能被Wireshark正确识别出来的依赖抓包网卡的驱动支持。Linux下用libpcap、Windows下用WinPcap/Npcap只要以太网类型0x8902的帧能进入抓包缓冲区Wireshark基本都能自动解码。真正容易出问题的是抓包位置。CFM报文只在参与CFM协议的设备之间转发你抓包要抓在MEP设备上或者MIP设备的镜像口上别随手找一台哑交换机接个笔记本就开抓那样大概率只能看到广播。过滤器我推荐写cfm这是Wireshark注册的协议名等效于eth.type 0x8902。如果只想看某一种报文可以细分cfm.opcode 0x01只看CCMcfm.opcode 0x02只看LBM请求cfm.opcode 0x03只看LBR应答cfm.opcode 0x04只看LTMcfm.opcode 0x05只看LTR实际操作环境里CCM是周期性发出的抓包文件会迅速被塞满。我建议抓包时先用cfm.opcode 0x02 || cfm.opcode 0x03这种定向过滤器配合Wireshark的Capture Filter而不是Display Filter直接在抓包前就过滤掉大部分CCM噪声文件体积能缩小十倍以上。3.2 怎么看懂 CCM 报文我习惯把一个CCM报文从上到下拆成四层看。第一层是封装层。正常情况下帧从网卡打出来是目的MAC通常组播01-80-c2-00-00-30到01-80-c2-00-00-3f之间的某个地址、源MAC、802.1Q VLAN Tag、EtherType 0x8902。注意CFM报文的目的MAC一般是组播地址尤其CCM否则MIP在转发时可能无法正确识别。Wireshark会把这一段显示为Ethernet II和802.1Q Virtual LAN。第二层是CFM公共头。这里能看到MD Level、Version、OpCode三个字段。MD Level取值范围0-7默认0通常表示客户侧7留给网络最大层级。Version固定是0OpCode是1到5中一个代表不同报文类型。第三层是CCM特有的字段。MAID长度最长可达48字节里面是MD名字和MA名字的拼接注意不同厂商对名字的编码方式有差异有的用UTF-8有的用十六进制。MEPID是个2字节整数代表本MEP在MA里的编号。Interval字段看着小但决定了超时时间一般是3.33ms/10ms/100ms/1s/10s等档位。Sequence Number则可以看出连续性如果中间有跳变说明前面丢了CCM报文。第四层是Flags和RDI位。RDI如果有值说明对端已经处于故障认知状态。这个位平时很少注意但在单向链路故障时可太关键了。两条光纤一收一发如果接收光纤断了但发送光纤还是好的本端MEP收不到对端CCM就会在它发出CCM里置RDI对端看到RDI就能够意识到自己这一侧发出去了但对方可能已经收不到了。Wireshark的Expert Info会直接提示RDI或者Loss of continuity一眼就能识别。3.3 LBM/LBR、LTM/LTR 的实际报文段我搭建过一个最小验证环境两台Linux主机各配一个虚拟网桥和一个veth口然后用Open vSwitch模拟桥接并配置CFM。终端在主机A上发一条指令比如用ethtool --identify配合思科/华为的Loopback测试命令生成一个LBM请求。Wireshark在主机B上立刻就能抓到OpCode 02的报文。LBM报文的关键字段主要是Transaction Identifier它和CCM的Sequence Number不同是单独维护的一套计数器。每一次发起LBMTransaction Identifier就加一。目标MEP收到后在LBR里回填同样的Transaction IdentifierWireshark在显示过滤后你会看到两个报文紧挨着一左一右就像ICMP Echo和Echo Reply。如果中间有交换机丢掉LBM那边你就只看到孤零零的02请求没有03应答。抓LTM/LTR比抓LBM有意思。在核心交换机上发起一次linktraceWireshark会瞬间涌入一串LTR每一跳对应一条。看这些LTR里的源MAC就能把整条二层路径画出来。我之前在实验室做过一次跨三台交换机的VLAN 100路径追踪发一个LTM马上收到三条LTR第一条来自第一台交换机的MIP第二条来自第二台交换机的MIP第三条来自目的MEP。把三个源MAC分别对上三台设备中间物理链路一根根查故障一目了然。4. 真实排障实验用 CFM 找准二层断点4.1 模拟场景一跨交换机 VLAN 双向通但业务异常某次测试环境里两台服务器接在同一台TOR交换机上前置业务说延迟高但核查网络没发现拥塞。我在TOR上配了两个MEP一个在服务器A接入的VLAN里一个在服务器B接入的VLAN里然后周期性发CCM。抓包后发现CCM有间隔性丢失每隔几秒就会断一条Sequence Number跳号明显。顺着这个线索查下去发现TOR和上游交换机之间的聚合口有一条成员链路CRC错误暴涨流量被哈希到了这条坏链路上形成随机丢包。这种问题用普通Ping很难发现因为ICMP丢包跟TCP重传混在一起时有时无。CCM每秒打一次肚丢不丢一目了然。把Wireshark过滤器停在cfm.opcode 0x01上观察Sequence Number的间隙就能量化丢包率。这种“心跳式排障”是CFM最牛的地方。4.2 模拟场景二从主机到核心交换机整条链路追踪再分享一个跨三层设备排查二层链路的例子。有个客户报告说一台接入交换机连不上核心端口起来了但业务全断。我在接入交换机上配置了一个MEP在核心交换机上配了对应的MEP然后发起LTM。Wireshark显示LTR只回了一跳来自接入交换机自己的MIP而核心MEP始终没有任何LTR返回。这就说明LTM在中间某一跳就丢了。顺着LTR里显示的转发状态字段看会发现Relay Action显示为“Down MEP”意思是这台中间设备认识自己是这个维护域的MIP但没找到下一跳出口。再一查发现中间那台交换机对应VLAN的出口被STP阻塞了。这个问题如果用传统思路可能要登录四五台设备逐台看STP状态而CFM一条Linktrace就锁定了位置剩下的就是确认配置和恢复转发。4.3 用 Wireshark 定位具体哪一跳黑掉我们再把镜头拉近一点讲怎么通过Wireshark界面里的线索判断故障源。发起一次LTM扫描后如果路径上的每一跳都正常你会看到一串LTR每个都带有Reply Success的标记。但如果某一跳有问题LTR的Info列会直接显示Request received, but not forwarded或者Incorrect entry。我习惯把所有LTR按Transaction Identifier分组然后看最后一跳的状态。若最后一跳是某个MIP说明LTM走到了这个MIP附近就被终结或者丢弃了若最后一跳显示的源MAC是目的MEP路径全通。还有个细节藏得比较深LTR里的Ingress Action区分“Ingress”和“Egress”。如果一个LTR显示收到了LTM但Egress失败说明问题在出口方向如果连Ingress都没有那可能是入方向就被策略丢弃了。配合Wireshark的TCP流跟踪式的聚合把同一个Transaction Identifier的LTR全部挑出来每个LTR里携带的端口和VLAN信息就是一张完整的二层路径图比任何物理拓扑图画得都准。5. 常见问题与避坑指南结合 Wireshark 使用5.1 抓不到 CFM 报文先别怀疑Wireshark经常有人急着问我过滤器明明写的cfm怎么一条都没有。这种情况下我十个里有八个是抓包位置选错了。CFM报文不像普通的广播帧会全网泛洪它是定向的、配置性的。如果设备管理员没有把CFM协议报文镜像到你的抓包口或者中间交换机直接把EtherType 0x8902丢弃了你抓不到什么都正常。另一种可能是抓包网卡把组播帧过滤掉了网卡驱动默认只会把发给本机MAC、广播和特定组播的帧交给上层。CFM使用的组播MAC地址不一定被网卡默认接收你需要关闭网卡的组播过滤或者在镜像口上抓。Npcap在Windows下有个选项可以设置混杂模式和组播接收建议抓CFM前检查一遍。还有一个常见的坑某些交换机的端口安全或风暴控制策略默认丢弃未知组播帧如果你的CFM MIP收到了LTM但出口做了组播抑制后续LTR可能发不出去。这就是为什么抓包没问题但就是看不到回包。遇到这种情况先去交换机上看端口丢包计数别在Wireshark里死磕。5.2 MD Level 或 MAID 不匹配导致没反应CFM诊断里最经典的问题就是“两边都配了就是不生效”。我看过太多案例最后都是MD Level或MAID不匹配。MD Level不匹配的典型表现是抓包能看到CFM报文进来了但设备不予回应。原因在于MEP只会处理与自己MD Level相等的CCM/LBM而MIP只会参与比自己MD Level高或者相等的维护域。比如一个Level 3的LTM发到Level 0的MIP设备上这个MIP原则上根本不会转发因为设备只关联低层级域。所以两头配CFM之前一定要先约定一个Level我建议客户侧用0核心网用3以上留出余量。MAID不匹配就比较隐蔽了尤其跨厂商设备。MD名称和MA名称的编码格式各家可能不同有的在MAID后面加了区段标识有的默认不带。这时候最好用Wireshark抓两边各自发出的CCM报文逐字节比较MAID字段。我遇到过最无语的一次两边MAID肉眼看着一模一样但一个用UTF-8编码另一个用十六进制编码导致字符串不一样。所以别靠肉眼对比直接看十六进制才是硬道理。5.3 VLAN 和物理口封装影响判断CFM报文本身就是带VLAN的你在业务VLAN里检测和在管理VLAN里检测完全是两回事。很多排障工程师把CFM的MEP配在管理VLAN里测出来链路是通的结果业务VLAN一塌糊涂。这不算CFM失效是测错了对象。MEP必须建在目标业务VLAN对应的桥域里报文走的才是业务数据通道。另外如果是trunk口CFM报文是否打上两层Tag也要注意。运营商网络常用QinQ外层是运营商VLAN内层才是用户VLAN。MEP在用户侧可能只能看到内层Tag报文要经过一层剥壳。抓包看到CFM帧带两层802.1Q Tag时别慌这是正常的只要Wireshark能把两层VLAN都解析出来看MAID字段里的VLAN识别符和配置是否一致即可。5.4 CCM 周期和超时判断的坑CCM周期不是越短越好。我碰到过有工程师把CCM周期调到10ms结果交换机CPU打满CCM都来不及发反而造成误判。CCM的性能开销和间隔成反比周期缩小一倍报文量增大一倍。10ms档位基本是给保护倒换场景留的普通连通性检测用1s足够。把CCM设得太密Wireshark也受苦文件增长极快过滤和统计分析都受影响。另一个容易踩的坑是超时倍数。CCM报文如果设置间隔1s那么MEP通常要连续丢失3个CCM才认定故障。也就是说故障发现时间在3到4秒之间。如果你觉得这个时间太长不要只改CCM周期还要看设备上是否有独立的故障确认倍数配置。Wireshark只能告诉你丢了几条CCM不能替你决定设备多久后拉起告警所以排障时要把间隔、超时倍数、告警阈值三者一起核对。5.5 RDI 标志位的实际使用和误读RDI位是CCM里最容易误读的字段。当本端MEP因为收不到对端CCM而产生Loss of Continuity告警后它会在发出去的CCM里把RDI置1告诉对端“我这边不健康”。但有些人抓包看到RDI为1就认为链路坏了其实RDI置1只代表发报文的这一端自己感知到了对端异常并不一定就是物理层断了也可能是中间STP阻塞、风暴抑制、或者CPU拥塞导致CCM没来得及处理。Wireshark提示RDI有用但也需要结合其他字段。比如RDI置位的同时如果Sequence Number仍然连续说明发送方向转发正常可能只是接收方向问题如果Sequence Number也有跳变说明双向都存在问题。把CCM的Flags、RDI、Sequence Number三个字段一起看判断会准确得多。6. 我总结的排障套路收尾最后分享一套我在实际项目里反复用、成功率极高的CFM排障执行顺序供参考。第一步确认拓扑里哪些设备支持CFM哪些不支持。CFM不是所有交换机都支持的老设备、低端傻瓜交换机会直接无视0x8902帧。在规划阶段就把支持CFM的设备选为MEP或MIP节点不支持的别硬配。第二步统一MD Level、MAID、VLAN三个要素。两端配置前先用文档记录清楚避免上线后抓包才知道有差异。配置完成后立刻抓一条CCM逐字段核对MAID十六进制编码。第三步在业务VLAN里发LBM往返回包正常后再发LTM。LTM能告诉你一跳一跳的细节但它依赖中间设备都支持CFM。如果中间有某台设备不支持LTM只能显示到最后支持的一跳这时要把不支持设备之前的路径认定是通的之后的部分用端口状态、CRC计数这些信息去补充排查。第四步从Wireshark导出一份统计视图把CCM的丢失率、LTR的应答列表存下来。这些不仅是排障依据也是后期和运营商或设备厂商扯皮的好材料。有一次我就凭一张Wireshark截图让对方承认了某台设备对未知组播帧丢弃导致CFM不通的事实。说句实在话以太网发展了这么多年业界不缺工具缺的是能把工具用到位的人。802.1ag CFM不像OSPF那样天天被讨论但在关键时刻它比任何花哨的可观测性平台都更贴近物理转发面。我个人的经验是做二层网络排障先把CFM摸透然后再谈什么分布式追踪、全链路监控。它朴实但真的管用。