一台机器白天跑得好好的晚上业务高峰就开始丢包ping时通时断延迟从 0.3ms 跳到 200ms 再掉回来。第一反应是查 IP 冲突、查路由、查防火墙策略查了一整圈没问题最后拔下网线换了一根好了。这类事我碰到过不止一次问题根本不在三层以上而在最底下那两层——物理层和数据链路层。这两章在教材里往往被当成“背概念就行”的部分介质种类、编码方式、CRC 多项式、CSMA/CD 的退避算法考完就忘。可真到了机房里、机柜旁、光模块前面能救你的恰恰是这些内容。物理层管的是比特怎么变成电平和光脉冲送到对端数据链路层管的是这些比特怎么切成帧、怎么标地址、怎么发现传错了。它们合起来决定了“一根线到底能不能通、通了之后稳不稳”。下面我按自己排障和做项目的顺序把这两层里真正影响结果的东西拆开讲包括介质指标的由来、编码和速率的换算、CRC 的能力边界、以太网和交换机的实际行为、VLAN 打标的坑以及怎么用系统自带的命令把这两层“看见”。1. 先把这两层的位置摆正从一块网卡的视角看数据怎么下楼梯很多人学这两层学得别扭是因为一直在背 OSI 七层表的横向排列而没有在脑子里建立“纵向流动”的画面。你敲一条ping数据不是“经过”七层而是被一层层套上信封再交下去每一层只关心自己那一段。把这条路径走一遍物理层和数据链路层的职责边界自然就清楚了后面所有细节都能挂在这条路径上。1.1 一次 ping 在下楼梯时到底被套了几层壳假设你在终端敲ping 10.0.0.20长度默认 56 字节数据。应用层生成 ICMP 报文ICMP 头 8 字节加上数据 56 字节一共 64 字节交给 IP 层。IP 层加 20 字节头无选项变成 84 字节。到了数据链路层以太网要给这 84 字节套一个帧头目的 MAC 6 字节、源 MAC 6 字节、类型字段 2 字节共 14 字节帧尾再加 4 字节 FCS 校验。所以这一帧在线上是 14 84 4 102 字节。再往下物理层还要加 8 字节前导码7 字节前导 1 字节帧起始定界符并且在每帧之间留至少 12 字节的帧间隙。这个账很多人从来没算过。算完你就明白所谓“千兆带宽”实际有效载荷占比是多少84 字节的有用数据其实 ICMP 的 56 字节才算真正有用对应线上 102 8 12 122 字节的时间片。这还没算 TCP 的确认包、IP 分片、ARP 广播这些“伴随流量”。所以为什么iperf打千兆口能跑到 940Mbps 就算优秀因为剩下的都被前导码、帧间隙、帧头、FCS、TCP/IP 头、确认包吃掉了。这个结论在物理层和数据链路层的交界处是理解“标称带宽”和“实际吞吐”差距的第一把钥匙。再往下物理层拿到的是 102 字节的串行比特流。它不管这是 ICMP 还是 TCP只管把这些 0 和 1 变成电平跳变送上双绞线或者变成光脉冲送进光纤。物理层没有任何“地址”和“校验”的概念它甚至连“帧”都不知道它只知道连续的比特。这就是为什么物理层出问题时你在上层看到的永远是“时通时断”“大量重传”这种模糊症状——物理层没有能力告诉你“哪里错了”它只会沉默地把错误传上去。1.2 排障时“自下而上”和“自顶向下”该怎么选我见过两种排障习惯。一种是从应用往下查业务报错→查服务→查端口→查防火墙→查路由→查 IP→最后才想到线。另一种是从物理往上查先看灯、看link状态、看错包计数再往上看 MAC、ARP、IP。两种都能通但适用场景不一样。如果症状是“完全不通”自下而上更快因为物理层是唯一无法被软件绕过的层线没插、光衰超标、模块不兼容你在上面折腾一整天都是白费。如果症状是“部分不通”“某几个网段不通”“某类流量不通”那大概率是三层以上的策略或路由问题自顶向下更省时间。麻烦的是“时通时断”和“慢”。这类症状在两层之间反复横跳最容易被误判。我自己的习惯是先花三十秒做物理层体检看网口灯link 灯亮不亮、act 灯闪不闪、看ip -s link的 errors/dropped 计数、看光模块的收发光功率。这三步不通过坚决不往上查。因为一旦物理层有错包你上面所有抓包分析都会建立在一堆不可信的数据上。提示错包计数是累积值看绝对值没意义要看“是否在增长”。先记一次跑五分钟业务再记一次增长的才是真问题。2. 物理层不是“背介质”是搞清信号怎么在铜和光上跑教材讲物理层喜欢列介质清单双绞线、同轴电缆、光纤、无线电。列完就完了。但真到现场你需要知道的是这根线为什么只能跑 100 米、为什么六类线接千兆没事接万兆就不行、为什么光模块的收光功率低了 3dB 就开始丢包。这些问题的答案都在电气和光学指标里不在清单里。2.1 双绞线的 100 米限制到底是被什么卡住的先说结论100 米不是标准拍脑袋定的是衰减、串扰、回波损耗几个指标在常见布线工艺下的折中结果。双绞线传输的是高频信号频率越高衰减越大而且信号会沿着线缆“漏”到相邻线对上去这叫串扰NEXT近端串扰。线对绞得越密、绞距设计越讲究串扰越小。超五类Cat5e在 100MHz 频率下的衰减大约是每 100 米 22dB 左右六类Cat6因为线径更粗、内部有十字骨架隔离指标好一些能支撑到 250MHz。六类增强Cat6a做到 500MHz屏蔽做得更狠才敢跑万兆到 100 米。这里的工程含义是你把一根超五类线拉到 130 米短距离测通没问题因为百兆、千兆的链路训练阶段可能还能协商成功但一到满负载、温度升高夏天桥架里能到 50 度以上衰减随温度上升、或者线缆被强电桥架干扰误码率就上来了。表现出来就是“白天没事晚上丢包”或者“大文件传输时速度掉到几兆”。这类问题用ping大包能复现ping -s 1472 -f打几千个包看丢包率。线缆类别支持频率典型应用距离现场最容易踩的点Cat5e100MHz千兆 100 米便宜线材铜包铝长距离衰减超标Cat6250MHz千兆 100 米万兆 55 米十字骨架被压扁串扰指标劣化Cat6a500MHz万兆 100 米屏蔽层接地不规范反而引入干扰多模光纤依等级几百米内端面污染收光功率下降单模光纤依等级数公里到数十公里弯折半径过小宏弯损耗表格里最后两行是我特别想强调的。光纤的问题八成不是“断了”而是端面脏了。一根多模跳线端面沾了手指油污收光功率可能掉 2 到 5dB链路能起来但误码率高表现和网线劣化几乎一样。所以现场必备无水乙醇和擦拭笔这不是讲究是基本功。2.2 编码和调制0 和 1 究竟是怎么“放”到线上的物理层最抽象的部分是编码。为什么不能直接“高电平代表 1、低电平代表 0”因为接收端需要知道“每一位从哪里开始到哪里结束”这就是时钟同步问题。如果连续发送一长串 1电平一直不变接收端的采样时钟会和发送端慢慢漂移采错位。早期以太网用曼彻斯特编码解决这个问题每一位中间必有一次跳变高到低代表 0低到高代表 1或者反过来取决于约定。好处是自带时钟坏处是效率只有 50%——传 1 个比特需要 2 个波特。10Mbps 以太网线路上的波特率其实是 20M Baud。到了百兆改用 4B/5B 编码每 4 个比特映射成 5 个比特保证不出现过长连 0 或连 1效率 80%。千兆铜缆更狠用 PAM-5 四电平调制一对线每个符号携带 2 比特四对线同时双向传输250M 符号/秒 × 2 比特 × 4 对 2000Mbps也就是全双工千兆。这个算法值得亲手算一遍算完你对“为什么千兆需要四对线全用上”就有实感了——百兆只用了两对一对发一对收所以一根网线断了蓝、棕两对百兆还能通千兆就直接降速或不通。这也解释了一个现场常见现象某些老设备或者劣质线材下网口协商从 1000M 掉到 100M。多数人以为是“协商问题”其实是四对线的某一对指标不合格千兆的链路训练过不去自动降级到只用两对线的百兆。这时候你把网口强行固定成千兆全双工结果是彻底不通而不是“强制成功”。所以我一般不建议在现场硬编码速率和双工模式除非对端设备明确要求。2.3 香农公式和“跑不满”的关系香农公式 C B log₂(1 S/N) 说的是信道容量上限B 是带宽S/N 是信噪比。这个公式在物理层排障里的实际用途不是算数而是建立直觉想在同样的线缆上跑更高速率要么拓宽频带用更高类别的线要么提高信噪比更好的屏蔽、更短的线、更强的发送功率要么换更好的调制方式更接近香农限。三者都不能凭空变出来所以“这条线最多能跑多少”是有物理上限的。实际测速跑不满的另一个原因在协议开销。前面算过一个 84 字节的 IP 包在线上占 122 字节的时间。如果业务是小包比如游戏、VoIP、大量短连接开销比例会更夸张。拿 TCP 短连接举例三次握手、慢启动、四次挥手真正的数据传输可能只占整个过程的一小部分。这就是为什么同样千兆口传大文件能到 940Mbps跑 HTTP 短连接压测可能只有 300Mbps。这部分不算物理层的锅但你得知道该往哪找原因别一头扎进线缆里。3. 数据链路层帧边界、差错检测和“看起来能用其实很脆”的协议物理层把比特送到了接下来要回答三个问题这串比特从哪里开始、到哪里结束成帧传过来的内容对不对差错检测发太快了对端顶不住怎么办流量控制。这三个问题的解法在教材里有标准答案但工程上的取舍远比答案复杂。3.1 成帧的三种套路各自的脆弱点在哪第一种是字节填充。用特殊字符做帧头和帧尾如果数据里恰好出现这个字符就在前面插一个转义字符。问题是转义字符本身也可能出现在数据里得再转义实现上容易出错而且和字符编码绑定不适合传任意二进制。第二种是比特填充HDLC 用的就是这个发送方在数据中每遇到连续 5 个 1就强制插入一个 0接收方看到连续 5 个 1 后面的 0 就删掉。这样 6 个连续 101111110就永远不会在数据里出现可以安全地当帧定界符。这个设计很优雅但它的代价是接收方要做逐位扫描硬件实现上比按字节处理麻烦。第三种是长度字段计数以太网和很多现代协议走的是这条路线帧头里留一个长度/类型字段接收方先读长度再按长度收。以太网更特殊它靠前导码加帧起始定界符SFD来确定帧的起点然后靠物理层的载波侦听和帧间隙来判定边界。这种做法效率高但一旦长度字段错了接收方就会“串帧”——把下一帧的头当成这一帧的数据整个流全乱。在现场成帧错误最常见的表现是frame errors或alignment errors计数增长。这类错误基本只有一个来源物理层信号质量问题导致接收方认错了位边界。所以看到frame errors不要试图在链路层修直接回去查线、查光模块、查端口。这是我在排障时反复强调的一条纪律错包计数的类型直接告诉你该去哪个层找原因。计数名称含义大概率原因rx_crc_errors帧内容校验失败线缆劣化、光衰、电磁干扰rx_frame_errors帧边界对齐错误物理层位同步失败、双工不匹配rx_length_errors帧长度异常巨帧配置不一致、驱动问题rx_over_errors接收缓冲区溢出上层处理不过来、中断风暴rx_missed_errors硬件丢包队列满、PCIe 带宽不足rx_dropped软件丢包内核协议栈、过滤规则注意over_errors和missed_errors不是物理层问题虽然它们名字里带 rx。这两个通常是主机侧性能问题CPU 忙不过来或者队列设置太小。分清楚这两类能省掉大量无效的换线操作。3.2 CRC 只能检错不能纠错别指望重传解决一切以太网帧尾的 FCS 是一个 32 位 CRC。CRC 的数学本质是把数据看成一个多项式除以一个约定的生成多项式取余数附加在数据后面。接收方做同样的除法余数为 0 就认为没错。这个机制的能力边界要说清楚它能检测出所有单比特错误、所有双比特错误、所有奇数个比特错误以及长度小于等于 32 位的突发错误对于更长的突发错误漏检概率约为 2⁻³²。这个概率听起来很低大约 42 亿分之一但要注意它是“每帧”的概率。如果一条链路每秒传 100 万帧理论上几小时就可能漏检一次。更关键的是CRC 漏检的后果不是“丢一个包”而是“一个错误的数据被当成正确的交给了上层”可能造成更隐蔽的问题。所以我一直认为“链路层有 CRC 就不用管物理层”是个危险的想法。CRC 是最后一道筛子不是第一道防线。另一个常见误解是“有重传就不怕错”。链路层的重传比如某些无线协议里的 ARQ会带来延迟抖动TCP 层的重传会触发拥塞控制降窗。一条误码率 0.001 的链路在实验室里跑测试完全正常上了生产环境就是“偶发卡顿”。这类问题最难查因为你抓包看到的都是“重传”看不出为什么重传。这时候必须回到物理层看crc_errors是不是在涨。3.3 流量控制和窗口大小带宽时延积到底意味着什么教材讲停等协议、回退 N 帧、选择重传讲完给个公式就结束了。工程上真正有用的是带宽时延积BDP这个概念链路能容纳的“在途数据量” 带宽 × 往返时延。一条 1Gbps、RTT 20ms 的链路BDP 是 20Mb约 2.5MB。意思是发送方在收到第一个确认之前最多可以发出 2.5MB 数据而不浪费链路。这直接决定了窗口该开多大。窗口小于 BDP链路就跑不满窗口远大于 BDP只会增加缓冲区压力。很多“为什么跨机房传输只有理论带宽的十分之一”的问题根源就在这里默认窗口太小或者接收窗口被应用读取速度限制住了。链路层的滑动窗口和 TCP 的窗口是两套机制但背后的数学是同一套。现场判断方法很简单抓包看有没有大量“窗口满”或者“零窗口”通告或者用ss -ti看连接的重传和拥塞窗口。如果发现窗口是瓶颈调大 socket 缓冲区往往比换硬件有效得多。4. 以太网那一套MAC、交换机、VLAN 到今天还怎么用以太网这一套东西诞生几十年了很多人觉得“太老了不用深究”。但你现在插的每一根网线、每一台交换机、每一个 VLAN跑的还是这套逻辑。不理解 MAC 表和 VLAN 标签的实际行为配置交换机基本靠猜。4.1 MAC 地址的真实结构那两个低位比特很关键MAC 地址 6 字节 48 位前 3 字节是厂商前缀OUI后 3 字节由厂商分配。这个大家都知道。容易忽略的是第一个字节的两个低位比特。最低位第 0 位是 I/G 位0 表示单播1 表示组播。所以01:00:5e开头的地址是 IPv4 组播映射来的33:33开头是 IPv6 组播。你看到ff:ff:ff:ff:ff:ff就是广播。次低位第 1 位是 U/L 位0 表示全球唯一厂商烧录1 表示本地管理。虚拟机、容器、网桥经常用本地管理地址比如02:42开头的就是典型特征。这个知识在排查“这个 MAC 是谁”的时候很有用02:42开头多半是容器网桥00:50:56、00:0c:29这类是虚拟化平台的虚拟网卡。还有一个实践中的坑MAC 地址冲突。正常情况下不该发生但虚拟机克隆、手工配置、网络设备配置错误都会造成。冲突的表现是交换机的 MAC 表在两个端口之间反复跳变MAC 漂移对应主机的网络时通时断。查这个要看交换机的 MAC 地址表看同一个 MAC 是不是出现在两个端口上。4.2 交换机的转发逻辑和 MAC 表老化交换机的工作逻辑简单到三句话收到帧看源 MAC 记到“这个 MAC 在哪个口”看目的 MAC表里有就从对应口转发表里没有就向除入端口外的所有端口泛洪广播和组播一律泛洪组播有 IGMP Snooping 时例外。这个“学习—转发—泛洪”的循环是所有二层网络的基础。MAC 表有老化时间常见是 300 秒。超过这个时间没收到某 MAC 的帧表项就删掉下次再收到要重新学习。这个设计是为了应对设备换口、虚拟机动迁移。但它带来一个副作用如果某台设备长时间不发帧比如一个只收不发的采集终端它的表项会老化交换机就得重新泛洪。MAC 表容量是另一个常被忽视的点。接入交换机通常几千条汇聚和核心几万条。如果下挂大量虚拟机、容器MAC 数量可能超出表容量这时候交换机会在“表满”状态下大量泛洪导致整个广播域内流量暴涨、性能骤降。表现形式很像“环路”但其实是表满。这个坑在虚拟化环境里踩过的人不少。环路则是另一个大坑。二层没有 TTL帧会一直转圈广播风暴瞬间打满链路。生成树协议STP/RSTP/MSTP就是干这个的但它的收敛时间从几十秒到几秒不等对业务不友好。现在的数据中心更多用 MC-LAG 或者干脆三层到接入来避免大二层。不管用哪种方案我个人的做法是所有接入口都开边缘端口PortFast 或等价配置防止终端插拔触发拓扑震荡所有级联口都配 BPDU 保护防止误接设备把环路引进来。4.3 VLAN 打标的工程细节那 4 个字节插在哪VLAN 标签802.1Q是 4 字节插在源 MAC 后面、类型字段前面2 字节 TPID固定 0x8100 2 字节 TCI里面 3 位优先级、1 位 DEI、12 位 VLAN ID。所以理论上 VLAN ID 范围是 0 到 4095其中 0 和 4095 保留可用的 1 到 4094。这 4 个字节带来的第一个副作用是帧变长了标准以太网帧最大 1518 字节带 VLAN 标签后是 1522 字节。绝大多数设备支持 1522但有些老设备、有些软件网桥、有些隧道封装场景下1522 会被当成超长帧丢弃。这就是为什么配了 VLAN 之后“某些大包不通”——ping小包正常传文件就卡住。诊断方法很直接ping -s 1500带不分片标志如果小包通、大包不通基本就是 MTU 问题。Access 口和 Trunk 口的区别我见过太多人配反。Access 口属于某个 VLAN进出都不带标签进的时候打上 PVID出的时候剥掉Trunk 口承载多个 VLAN出方向带标签入方向按标签识别。最容易出错的是 Native VLANTrunk 口上有一个 VLAN 是不带标签传输的两端 Native VLAN 不一致就会出现“某些 VLAN 通、某些 VLAN 不通”或者“两个 VLAN 串到一起”的诡异现象。第二个容易出错的是 PVID 和 VLAN 成员关系搞混。一个端口可以有多个 VLAN 成员Tagged但只有一个 PVIDUntagged。如果一台终端接在 Trunk 口上它收到的帧带标签普通网卡不认识标签直接把帧丢掉表现就是“插上不通”。4.4 链路聚合四根线的带宽不是四倍链路聚合LAG/LACP把多条物理链路捆成一条逻辑链路目的是增加带宽和冗余。但很多人配完发现单流速度没变就以为配错了。其实这是哈希算法的必然结果聚合口把流量按源 MAC、目的 MAC、源 IP、目的 IP、端口号的某种组合做哈希同一条流的所有包一定走同一根物理线。所以四根千兆捆起来跑单个 TCP 连接还是 1Gbps只有多个并发流才可能接近 4Gbps。现场判断方法看聚合口的每根成员口的流量是否均衡。如果一根跑满其他空闲说明哈希粒度不够或者流量本身只有一条流。可以在交换机上改哈希算法比如从基于 MAC 改成基于 IP端口但如果业务本身就是单流改算法也解决不了只能上更高带宽的单链路。LACP 还有一个坑是速率。LACP 有两种模式静态手工和动态LACP 协议协商。静态配置简单但对端配错或者一根线坏了流量可能还往坏线上发动态模式能检测成员口状态更可靠。我一般建议用动态模式并且开启“最小活动链路数”保护——如果活动链路少于阈值整个聚合口 down 掉避免带宽悄悄缩水还不报警。5. 把这些理论落到排障上一条自下而上的检查链路前面讲的是“应该怎样”这一节讲“出问题时怎么查”。我把自己常用的检查顺序整理成一条链路从物理层向上每一步都有明确的判据和退出条件。这套流程的价值在于它让你在十分钟内排除掉大部分不可能的原因而不是在应用层反复打转。5.1 物理层体检灯、计数、光功率第一步看灯。link 灯不亮说明物理层没建立连接可能是线没插好、对端没开、模块不兼容、光路断了。link 灯亮但 act 灯不闪说明链路起来了但没有流量问题在上层。这个信息量已经很大了。第二步看计数。Linux 上用ip -s link show eth0看 errors 和 dropped。更细的要靠ethtool -S eth0不同驱动的字段名不一样但常见的有rx_crc_errors、rx_frame_errors、rx_length_errors、rx_fifo_errors。看的时候一定要间隔采样先记一次跑一段业务再看一次只关注增长的。# 采样两次间隔 60 秒对比错包是否增长 ip -s link show eth0 sleep 60 ip -s link show eth0 # 更细的驱动级计数字段名随驱动不同 ethtool -S eth0 | grep -Ei err|drop|miss|discard|crc|frame第三步看光功率。ethtool -m eth0能读出模块的收发光功率、温度、电压需要模块支持 DDM/DOM。收光功率低于模块灵敏度下限就会开始误码高于饱和点同样会误码。这两个值之间通常只有十几 dB 的窗口衰减过大或过小都不行。注意ethtool -m输出的是原始十六进制或转换后的值不同厂商的解码不一致。看到异常值时先对照模块规格书里的灵敏度和饱和点别只看数字大小判断好坏。另外双工不匹配是物理层排障里的经典陷阱。一端强制全双工、一端自协商自协商那端会退到半双工结果就是大量冲突和 CRC 错包。现在大多数设备默认自协商这个问题少了但接老设备时仍会遇到。判断方法是看ethtool eth0输出的Duplex字段两端必须一致。5.2 链路层体检ARP、MAC 表、VLAN 标签物理层干净之后往上看链路层。第一步是 ARP。ip neigh show看目标 IP 有没有解析成 MAC。如果一直处于INCOMPLETE状态说明 ARP 请求发出去了但没回应可能是 VLAN 不对、对端不在这个广播域、或者对端开了防护。# 查看邻居表状态 ip neigh show # 清掉某条记录强制重新解析 ip neigh del 10.0.0.20 dev eth0第二步看 MAC 表。在交换机上查目的 MAC 学习在哪个端口如果学不到说明帧根本没到交换机或者被 VLAN 隔离了。如果同一个 MAC 在两个端口之间跳基本可以确定是 MAC 冲突或环路。第三步验证 VLAN 标签。在 Linux 主机上抓包时如果看到帧里带 802.1Q 标签而业务应该走 Access 口那就是配置问题。反过来Trunk 口上抓不到标签说明 native VLAN 配置生效了标签被剥掉了。5.3 三张表对照常见现象现象优先怀疑的层关键命令判据完全不通灯不亮物理层看指示灯、ip linklink 状态 DOWN时通时断延迟跳变物理层ethtool -Scrc/frame 错误增长小包通大包不通链路层ping -s 1500 -M doMTU 或 VLAN 标签导致超长帧同网段部分主机不通链路层ip neighARP 状态 INCOMPLETE跨网段不通但同网段通网络层ip route、traceroute路由表或网关配置速度只有标称值十分之一链路层及以上iperf、ss -ti窗口、聚合哈希、双工这张表不是万能的但能覆盖八成的现场问题。它的用法是先定位层再在层内找具体原因而不是一上来就瞎猜。6. 抓包看帧把抽象概念变成屏幕上的一行行字节理论讲再多不如亲眼看一次帧的结构。抓包工具在这里的作用不是“看流量”而是“验证你对协议的每一个假设”。我建议每个做网络的人都至少完整拆解过一次 ARP 请求和一次 TCP 三次握手的帧结构那种“原来真的是这样”的感觉比背十遍书有用。6.1 一次 ARP 请求的字节级拆解假设主机 A00:11:22:33:44:55IP10.0.0.10要访问10.0.0.20不知道对方 MAC发 ARP 请求。这一帧在线上是这样的前导码 7 字节AA AA AA AA AA AA AA用于接收方时钟同步帧起始定界符 1 字节AB标志帧开始目的 MAC 6 字节FF FF FF FF FF FF广播源 MAC 6 字节00 11 22 33 44 55类型 2 字节08 06表示 ARPARP 载荷 28 字节硬件类型 2 字节00 01以太网、协议类型 2 字节08 00IPv4、硬件地址长度 1 字节06、协议地址长度 1 字节04、操作码 2 字节00 01请求、发送方 MAC 6 字节、发送方 IP 4 字节、目标 MAC 6 字节全 0、目标 IP 4 字节填充字段因为以太网最小帧长 64 字节不含前导码和 FCSARP 载荷只有 28 字节帧总长 14 28 42 字节不够 64要补 18 字节填充FCS 4 字节这里有个常被忽略的细节最小帧长 64 字节不是随便定的。早期共享式以太网用 CSMA/CD冲突检测依赖“发送方在发送过程中能听到冲突”。如果帧太短发送方可能在冲突信号传回来之前就发完了检测不到冲突。64 字节对应的就是最远距离下往返传播时间。现在全双工交换式网络不需要 CSMA/CD 了但最小帧长的规定保留了下来所以你会看到很多小包后面跟着填充字节。6.2 抓包时的三个常见误区第一个误区是没开混杂模式。默认情况下网卡只接收目的 MAC 是自己的帧或者广播/组播帧。如果要看经过本机但不发给本机的流量得开混杂模式。但注意在交换机环境下你本来就看不到别人的单播流量开混杂模式也没用除非配置了端口镜像。第二个误区是忽略网卡的卸载功能。现代网卡支持 TSOTCP 分片卸载、LRO大包接收卸载、校验和卸载。抓包工具抓到的是“卸载前”或“卸载后”的数据取决于抓包位置。你会看到“校验和错误”的帧或者看到超过 MTU 的巨帧这往往不是真的有问题而是卸载机制造成的假象。分析时要么关掉卸载ethtool -K eth0 tso off gso off gro off要么在分析工具里忽略校验和验证。第三个误区是看不到 VLAN 标签。很多网卡和驱动会在收到带标签的帧时自动剥离标签抓包时看到的是“干净”的帧。要看到标签得关掉 VLAN 剥离功能ethtool -K eth0 rxvlan off或者用支持显示标签的分析工具配置。# 关闭常见卸载避免抓包假象测试环境用生产慎用 ethtool -K eth0 tso off gso off gro off lro off # 关闭 VLAN 标签剥离 ethtool -K eth0 rxvlan off # 抓 ARP 包带完整链路层头 tcpdump -i eth0 -e -n arptcpdump -e这个参数很多人不知道它会打印链路层头部包括源 MAC、目的 MAC、以太类型必要时还有 VLAN 标签。看二层问题没有这个参数基本等于盲人摸象。我个人在实际操作中的体会是物理层和数据链路层的知识价值不在于考试而在于它给了你一套“不可辩驳”的判断依据。应用层的问题可以争论“是不是代码写错了”但rx_crc_errors在涨就是线有问题这种确定性在排障时特别珍贵。所以每次遇到“时通时断”和“偶发丢包”我都会先把这两层的计数抓出来看一眼这一步花不了两分钟却能省掉后面几小时的弯路。
一台机器白天跑得好好的晚上业务高峰就开始丢包ping时通时断延迟从 0.3ms 跳到 200ms 再掉回来。第一反应是查 IP 冲突、查路由、查防火墙策略查了一整圈没问题最后拔下网线换了一根好了。这类事我碰到过不止一次问题根本不在三层以上而在最底下那两层——物理层和数据链路层。这两章在教材里往往被当成“背概念就行”的部分介质种类、编码方式、CRC 多项式、CSMA/CD 的退避算法考完就忘。可真到了机房里、机柜旁、光模块前面能救你的恰恰是这些内容。物理层管的是比特怎么变成电平和光脉冲送到对端数据链路层管的是这些比特怎么切成帧、怎么标地址、怎么发现传错了。它们合起来决定了“一根线到底能不能通、通了之后稳不稳”。下面我按自己排障和做项目的顺序把这两层里真正影响结果的东西拆开讲包括介质指标的由来、编码和速率的换算、CRC 的能力边界、以太网和交换机的实际行为、VLAN 打标的坑以及怎么用系统自带的命令把这两层“看见”。1. 先把这两层的位置摆正从一块网卡的视角看数据怎么下楼梯很多人学这两层学得别扭是因为一直在背 OSI 七层表的横向排列而没有在脑子里建立“纵向流动”的画面。你敲一条ping数据不是“经过”七层而是被一层层套上信封再交下去每一层只关心自己那一段。把这条路径走一遍物理层和数据链路层的职责边界自然就清楚了后面所有细节都能挂在这条路径上。1.1 一次 ping 在下楼梯时到底被套了几层壳假设你在终端敲ping 10.0.0.20长度默认 56 字节数据。应用层生成 ICMP 报文ICMP 头 8 字节加上数据 56 字节一共 64 字节交给 IP 层。IP 层加 20 字节头无选项变成 84 字节。到了数据链路层以太网要给这 84 字节套一个帧头目的 MAC 6 字节、源 MAC 6 字节、类型字段 2 字节共 14 字节帧尾再加 4 字节 FCS 校验。所以这一帧在线上是 14 84 4 102 字节。再往下物理层还要加 8 字节前导码7 字节前导 1 字节帧起始定界符并且在每帧之间留至少 12 字节的帧间隙。这个账很多人从来没算过。算完你就明白所谓“千兆带宽”实际有效载荷占比是多少84 字节的有用数据其实 ICMP 的 56 字节才算真正有用对应线上 102 8 12 122 字节的时间片。这还没算 TCP 的确认包、IP 分片、ARP 广播这些“伴随流量”。所以为什么iperf打千兆口能跑到 940Mbps 就算优秀因为剩下的都被前导码、帧间隙、帧头、FCS、TCP/IP 头、确认包吃掉了。这个结论在物理层和数据链路层的交界处是理解“标称带宽”和“实际吞吐”差距的第一把钥匙。再往下物理层拿到的是 102 字节的串行比特流。它不管这是 ICMP 还是 TCP只管把这些 0 和 1 变成电平跳变送上双绞线或者变成光脉冲送进光纤。物理层没有任何“地址”和“校验”的概念它甚至连“帧”都不知道它只知道连续的比特。这就是为什么物理层出问题时你在上层看到的永远是“时通时断”“大量重传”这种模糊症状——物理层没有能力告诉你“哪里错了”它只会沉默地把错误传上去。1.2 排障时“自下而上”和“自顶向下”该怎么选我见过两种排障习惯。一种是从应用往下查业务报错→查服务→查端口→查防火墙→查路由→查 IP→最后才想到线。另一种是从物理往上查先看灯、看link状态、看错包计数再往上看 MAC、ARP、IP。两种都能通但适用场景不一样。如果症状是“完全不通”自下而上更快因为物理层是唯一无法被软件绕过的层线没插、光衰超标、模块不兼容你在上面折腾一整天都是白费。如果症状是“部分不通”“某几个网段不通”“某类流量不通”那大概率是三层以上的策略或路由问题自顶向下更省时间。麻烦的是“时通时断”和“慢”。这类症状在两层之间反复横跳最容易被误判。我自己的习惯是先花三十秒做物理层体检看网口灯link 灯亮不亮、act 灯闪不闪、看ip -s link的 errors/dropped 计数、看光模块的收发光功率。这三步不通过坚决不往上查。因为一旦物理层有错包你上面所有抓包分析都会建立在一堆不可信的数据上。提示错包计数是累积值看绝对值没意义要看“是否在增长”。先记一次跑五分钟业务再记一次增长的才是真问题。2. 物理层不是“背介质”是搞清信号怎么在铜和光上跑教材讲物理层喜欢列介质清单双绞线、同轴电缆、光纤、无线电。列完就完了。但真到现场你需要知道的是这根线为什么只能跑 100 米、为什么六类线接千兆没事接万兆就不行、为什么光模块的收光功率低了 3dB 就开始丢包。这些问题的答案都在电气和光学指标里不在清单里。2.1 双绞线的 100 米限制到底是被什么卡住的先说结论100 米不是标准拍脑袋定的是衰减、串扰、回波损耗几个指标在常见布线工艺下的折中结果。双绞线传输的是高频信号频率越高衰减越大而且信号会沿着线缆“漏”到相邻线对上去这叫串扰NEXT近端串扰。线对绞得越密、绞距设计越讲究串扰越小。超五类Cat5e在 100MHz 频率下的衰减大约是每 100 米 22dB 左右六类Cat6因为线径更粗、内部有十字骨架隔离指标好一些能支撑到 250MHz。六类增强Cat6a做到 500MHz屏蔽做得更狠才敢跑万兆到 100 米。这里的工程含义是你把一根超五类线拉到 130 米短距离测通没问题因为百兆、千兆的链路训练阶段可能还能协商成功但一到满负载、温度升高夏天桥架里能到 50 度以上衰减随温度上升、或者线缆被强电桥架干扰误码率就上来了。表现出来就是“白天没事晚上丢包”或者“大文件传输时速度掉到几兆”。这类问题用ping大包能复现ping -s 1472 -f打几千个包看丢包率。线缆类别支持频率典型应用距离现场最容易踩的点Cat5e100MHz千兆 100 米便宜线材铜包铝长距离衰减超标Cat6250MHz千兆 100 米万兆 55 米十字骨架被压扁串扰指标劣化Cat6a500MHz万兆 100 米屏蔽层接地不规范反而引入干扰多模光纤依等级几百米内端面污染收光功率下降单模光纤依等级数公里到数十公里弯折半径过小宏弯损耗表格里最后两行是我特别想强调的。光纤的问题八成不是“断了”而是端面脏了。一根多模跳线端面沾了手指油污收光功率可能掉 2 到 5dB链路能起来但误码率高表现和网线劣化几乎一样。所以现场必备无水乙醇和擦拭笔这不是讲究是基本功。2.2 编码和调制0 和 1 究竟是怎么“放”到线上的物理层最抽象的部分是编码。为什么不能直接“高电平代表 1、低电平代表 0”因为接收端需要知道“每一位从哪里开始到哪里结束”这就是时钟同步问题。如果连续发送一长串 1电平一直不变接收端的采样时钟会和发送端慢慢漂移采错位。早期以太网用曼彻斯特编码解决这个问题每一位中间必有一次跳变高到低代表 0低到高代表 1或者反过来取决于约定。好处是自带时钟坏处是效率只有 50%——传 1 个比特需要 2 个波特。10Mbps 以太网线路上的波特率其实是 20M Baud。到了百兆改用 4B/5B 编码每 4 个比特映射成 5 个比特保证不出现过长连 0 或连 1效率 80%。千兆铜缆更狠用 PAM-5 四电平调制一对线每个符号携带 2 比特四对线同时双向传输250M 符号/秒 × 2 比特 × 4 对 2000Mbps也就是全双工千兆。这个算法值得亲手算一遍算完你对“为什么千兆需要四对线全用上”就有实感了——百兆只用了两对一对发一对收所以一根网线断了蓝、棕两对百兆还能通千兆就直接降速或不通。这也解释了一个现场常见现象某些老设备或者劣质线材下网口协商从 1000M 掉到 100M。多数人以为是“协商问题”其实是四对线的某一对指标不合格千兆的链路训练过不去自动降级到只用两对线的百兆。这时候你把网口强行固定成千兆全双工结果是彻底不通而不是“强制成功”。所以我一般不建议在现场硬编码速率和双工模式除非对端设备明确要求。2.3 香农公式和“跑不满”的关系香农公式 C B log₂(1 S/N) 说的是信道容量上限B 是带宽S/N 是信噪比。这个公式在物理层排障里的实际用途不是算数而是建立直觉想在同样的线缆上跑更高速率要么拓宽频带用更高类别的线要么提高信噪比更好的屏蔽、更短的线、更强的发送功率要么换更好的调制方式更接近香农限。三者都不能凭空变出来所以“这条线最多能跑多少”是有物理上限的。实际测速跑不满的另一个原因在协议开销。前面算过一个 84 字节的 IP 包在线上占 122 字节的时间。如果业务是小包比如游戏、VoIP、大量短连接开销比例会更夸张。拿 TCP 短连接举例三次握手、慢启动、四次挥手真正的数据传输可能只占整个过程的一小部分。这就是为什么同样千兆口传大文件能到 940Mbps跑 HTTP 短连接压测可能只有 300Mbps。这部分不算物理层的锅但你得知道该往哪找原因别一头扎进线缆里。3. 数据链路层帧边界、差错检测和“看起来能用其实很脆”的协议物理层把比特送到了接下来要回答三个问题这串比特从哪里开始、到哪里结束成帧传过来的内容对不对差错检测发太快了对端顶不住怎么办流量控制。这三个问题的解法在教材里有标准答案但工程上的取舍远比答案复杂。3.1 成帧的三种套路各自的脆弱点在哪第一种是字节填充。用特殊字符做帧头和帧尾如果数据里恰好出现这个字符就在前面插一个转义字符。问题是转义字符本身也可能出现在数据里得再转义实现上容易出错而且和字符编码绑定不适合传任意二进制。第二种是比特填充HDLC 用的就是这个发送方在数据中每遇到连续 5 个 1就强制插入一个 0接收方看到连续 5 个 1 后面的 0 就删掉。这样 6 个连续 101111110就永远不会在数据里出现可以安全地当帧定界符。这个设计很优雅但它的代价是接收方要做逐位扫描硬件实现上比按字节处理麻烦。第三种是长度字段计数以太网和很多现代协议走的是这条路线帧头里留一个长度/类型字段接收方先读长度再按长度收。以太网更特殊它靠前导码加帧起始定界符SFD来确定帧的起点然后靠物理层的载波侦听和帧间隙来判定边界。这种做法效率高但一旦长度字段错了接收方就会“串帧”——把下一帧的头当成这一帧的数据整个流全乱。在现场成帧错误最常见的表现是frame errors或alignment errors计数增长。这类错误基本只有一个来源物理层信号质量问题导致接收方认错了位边界。所以看到frame errors不要试图在链路层修直接回去查线、查光模块、查端口。这是我在排障时反复强调的一条纪律错包计数的类型直接告诉你该去哪个层找原因。计数名称含义大概率原因rx_crc_errors帧内容校验失败线缆劣化、光衰、电磁干扰rx_frame_errors帧边界对齐错误物理层位同步失败、双工不匹配rx_length_errors帧长度异常巨帧配置不一致、驱动问题rx_over_errors接收缓冲区溢出上层处理不过来、中断风暴rx_missed_errors硬件丢包队列满、PCIe 带宽不足rx_dropped软件丢包内核协议栈、过滤规则注意over_errors和missed_errors不是物理层问题虽然它们名字里带 rx。这两个通常是主机侧性能问题CPU 忙不过来或者队列设置太小。分清楚这两类能省掉大量无效的换线操作。3.2 CRC 只能检错不能纠错别指望重传解决一切以太网帧尾的 FCS 是一个 32 位 CRC。CRC 的数学本质是把数据看成一个多项式除以一个约定的生成多项式取余数附加在数据后面。接收方做同样的除法余数为 0 就认为没错。这个机制的能力边界要说清楚它能检测出所有单比特错误、所有双比特错误、所有奇数个比特错误以及长度小于等于 32 位的突发错误对于更长的突发错误漏检概率约为 2⁻³²。这个概率听起来很低大约 42 亿分之一但要注意它是“每帧”的概率。如果一条链路每秒传 100 万帧理论上几小时就可能漏检一次。更关键的是CRC 漏检的后果不是“丢一个包”而是“一个错误的数据被当成正确的交给了上层”可能造成更隐蔽的问题。所以我一直认为“链路层有 CRC 就不用管物理层”是个危险的想法。CRC 是最后一道筛子不是第一道防线。另一个常见误解是“有重传就不怕错”。链路层的重传比如某些无线协议里的 ARQ会带来延迟抖动TCP 层的重传会触发拥塞控制降窗。一条误码率 0.001 的链路在实验室里跑测试完全正常上了生产环境就是“偶发卡顿”。这类问题最难查因为你抓包看到的都是“重传”看不出为什么重传。这时候必须回到物理层看crc_errors是不是在涨。3.3 流量控制和窗口大小带宽时延积到底意味着什么教材讲停等协议、回退 N 帧、选择重传讲完给个公式就结束了。工程上真正有用的是带宽时延积BDP这个概念链路能容纳的“在途数据量” 带宽 × 往返时延。一条 1Gbps、RTT 20ms 的链路BDP 是 20Mb约 2.5MB。意思是发送方在收到第一个确认之前最多可以发出 2.5MB 数据而不浪费链路。这直接决定了窗口该开多大。窗口小于 BDP链路就跑不满窗口远大于 BDP只会增加缓冲区压力。很多“为什么跨机房传输只有理论带宽的十分之一”的问题根源就在这里默认窗口太小或者接收窗口被应用读取速度限制住了。链路层的滑动窗口和 TCP 的窗口是两套机制但背后的数学是同一套。现场判断方法很简单抓包看有没有大量“窗口满”或者“零窗口”通告或者用ss -ti看连接的重传和拥塞窗口。如果发现窗口是瓶颈调大 socket 缓冲区往往比换硬件有效得多。4. 以太网那一套MAC、交换机、VLAN 到今天还怎么用以太网这一套东西诞生几十年了很多人觉得“太老了不用深究”。但你现在插的每一根网线、每一台交换机、每一个 VLAN跑的还是这套逻辑。不理解 MAC 表和 VLAN 标签的实际行为配置交换机基本靠猜。4.1 MAC 地址的真实结构那两个低位比特很关键MAC 地址 6 字节 48 位前 3 字节是厂商前缀OUI后 3 字节由厂商分配。这个大家都知道。容易忽略的是第一个字节的两个低位比特。最低位第 0 位是 I/G 位0 表示单播1 表示组播。所以01:00:5e开头的地址是 IPv4 组播映射来的33:33开头是 IPv6 组播。你看到ff:ff:ff:ff:ff:ff就是广播。次低位第 1 位是 U/L 位0 表示全球唯一厂商烧录1 表示本地管理。虚拟机、容器、网桥经常用本地管理地址比如02:42开头的就是典型特征。这个知识在排查“这个 MAC 是谁”的时候很有用02:42开头多半是容器网桥00:50:56、00:0c:29这类是虚拟化平台的虚拟网卡。还有一个实践中的坑MAC 地址冲突。正常情况下不该发生但虚拟机克隆、手工配置、网络设备配置错误都会造成。冲突的表现是交换机的 MAC 表在两个端口之间反复跳变MAC 漂移对应主机的网络时通时断。查这个要看交换机的 MAC 地址表看同一个 MAC 是不是出现在两个端口上。4.2 交换机的转发逻辑和 MAC 表老化交换机的工作逻辑简单到三句话收到帧看源 MAC 记到“这个 MAC 在哪个口”看目的 MAC表里有就从对应口转发表里没有就向除入端口外的所有端口泛洪广播和组播一律泛洪组播有 IGMP Snooping 时例外。这个“学习—转发—泛洪”的循环是所有二层网络的基础。MAC 表有老化时间常见是 300 秒。超过这个时间没收到某 MAC 的帧表项就删掉下次再收到要重新学习。这个设计是为了应对设备换口、虚拟机动迁移。但它带来一个副作用如果某台设备长时间不发帧比如一个只收不发的采集终端它的表项会老化交换机就得重新泛洪。MAC 表容量是另一个常被忽视的点。接入交换机通常几千条汇聚和核心几万条。如果下挂大量虚拟机、容器MAC 数量可能超出表容量这时候交换机会在“表满”状态下大量泛洪导致整个广播域内流量暴涨、性能骤降。表现形式很像“环路”但其实是表满。这个坑在虚拟化环境里踩过的人不少。环路则是另一个大坑。二层没有 TTL帧会一直转圈广播风暴瞬间打满链路。生成树协议STP/RSTP/MSTP就是干这个的但它的收敛时间从几十秒到几秒不等对业务不友好。现在的数据中心更多用 MC-LAG 或者干脆三层到接入来避免大二层。不管用哪种方案我个人的做法是所有接入口都开边缘端口PortFast 或等价配置防止终端插拔触发拓扑震荡所有级联口都配 BPDU 保护防止误接设备把环路引进来。4.3 VLAN 打标的工程细节那 4 个字节插在哪VLAN 标签802.1Q是 4 字节插在源 MAC 后面、类型字段前面2 字节 TPID固定 0x8100 2 字节 TCI里面 3 位优先级、1 位 DEI、12 位 VLAN ID。所以理论上 VLAN ID 范围是 0 到 4095其中 0 和 4095 保留可用的 1 到 4094。这 4 个字节带来的第一个副作用是帧变长了标准以太网帧最大 1518 字节带 VLAN 标签后是 1522 字节。绝大多数设备支持 1522但有些老设备、有些软件网桥、有些隧道封装场景下1522 会被当成超长帧丢弃。这就是为什么配了 VLAN 之后“某些大包不通”——ping小包正常传文件就卡住。诊断方法很直接ping -s 1500带不分片标志如果小包通、大包不通基本就是 MTU 问题。Access 口和 Trunk 口的区别我见过太多人配反。Access 口属于某个 VLAN进出都不带标签进的时候打上 PVID出的时候剥掉Trunk 口承载多个 VLAN出方向带标签入方向按标签识别。最容易出错的是 Native VLANTrunk 口上有一个 VLAN 是不带标签传输的两端 Native VLAN 不一致就会出现“某些 VLAN 通、某些 VLAN 不通”或者“两个 VLAN 串到一起”的诡异现象。第二个容易出错的是 PVID 和 VLAN 成员关系搞混。一个端口可以有多个 VLAN 成员Tagged但只有一个 PVIDUntagged。如果一台终端接在 Trunk 口上它收到的帧带标签普通网卡不认识标签直接把帧丢掉表现就是“插上不通”。4.4 链路聚合四根线的带宽不是四倍链路聚合LAG/LACP把多条物理链路捆成一条逻辑链路目的是增加带宽和冗余。但很多人配完发现单流速度没变就以为配错了。其实这是哈希算法的必然结果聚合口把流量按源 MAC、目的 MAC、源 IP、目的 IP、端口号的某种组合做哈希同一条流的所有包一定走同一根物理线。所以四根千兆捆起来跑单个 TCP 连接还是 1Gbps只有多个并发流才可能接近 4Gbps。现场判断方法看聚合口的每根成员口的流量是否均衡。如果一根跑满其他空闲说明哈希粒度不够或者流量本身只有一条流。可以在交换机上改哈希算法比如从基于 MAC 改成基于 IP端口但如果业务本身就是单流改算法也解决不了只能上更高带宽的单链路。LACP 还有一个坑是速率。LACP 有两种模式静态手工和动态LACP 协议协商。静态配置简单但对端配错或者一根线坏了流量可能还往坏线上发动态模式能检测成员口状态更可靠。我一般建议用动态模式并且开启“最小活动链路数”保护——如果活动链路少于阈值整个聚合口 down 掉避免带宽悄悄缩水还不报警。5. 把这些理论落到排障上一条自下而上的检查链路前面讲的是“应该怎样”这一节讲“出问题时怎么查”。我把自己常用的检查顺序整理成一条链路从物理层向上每一步都有明确的判据和退出条件。这套流程的价值在于它让你在十分钟内排除掉大部分不可能的原因而不是在应用层反复打转。5.1 物理层体检灯、计数、光功率第一步看灯。link 灯不亮说明物理层没建立连接可能是线没插好、对端没开、模块不兼容、光路断了。link 灯亮但 act 灯不闪说明链路起来了但没有流量问题在上层。这个信息量已经很大了。第二步看计数。Linux 上用ip -s link show eth0看 errors 和 dropped。更细的要靠ethtool -S eth0不同驱动的字段名不一样但常见的有rx_crc_errors、rx_frame_errors、rx_length_errors、rx_fifo_errors。看的时候一定要间隔采样先记一次跑一段业务再看一次只关注增长的。# 采样两次间隔 60 秒对比错包是否增长 ip -s link show eth0 sleep 60 ip -s link show eth0 # 更细的驱动级计数字段名随驱动不同 ethtool -S eth0 | grep -Ei err|drop|miss|discard|crc|frame第三步看光功率。ethtool -m eth0能读出模块的收发光功率、温度、电压需要模块支持 DDM/DOM。收光功率低于模块灵敏度下限就会开始误码高于饱和点同样会误码。这两个值之间通常只有十几 dB 的窗口衰减过大或过小都不行。注意ethtool -m输出的是原始十六进制或转换后的值不同厂商的解码不一致。看到异常值时先对照模块规格书里的灵敏度和饱和点别只看数字大小判断好坏。另外双工不匹配是物理层排障里的经典陷阱。一端强制全双工、一端自协商自协商那端会退到半双工结果就是大量冲突和 CRC 错包。现在大多数设备默认自协商这个问题少了但接老设备时仍会遇到。判断方法是看ethtool eth0输出的Duplex字段两端必须一致。5.2 链路层体检ARP、MAC 表、VLAN 标签物理层干净之后往上看链路层。第一步是 ARP。ip neigh show看目标 IP 有没有解析成 MAC。如果一直处于INCOMPLETE状态说明 ARP 请求发出去了但没回应可能是 VLAN 不对、对端不在这个广播域、或者对端开了防护。# 查看邻居表状态 ip neigh show # 清掉某条记录强制重新解析 ip neigh del 10.0.0.20 dev eth0第二步看 MAC 表。在交换机上查目的 MAC 学习在哪个端口如果学不到说明帧根本没到交换机或者被 VLAN 隔离了。如果同一个 MAC 在两个端口之间跳基本可以确定是 MAC 冲突或环路。第三步验证 VLAN 标签。在 Linux 主机上抓包时如果看到帧里带 802.1Q 标签而业务应该走 Access 口那就是配置问题。反过来Trunk 口上抓不到标签说明 native VLAN 配置生效了标签被剥掉了。5.3 三张表对照常见现象现象优先怀疑的层关键命令判据完全不通灯不亮物理层看指示灯、ip linklink 状态 DOWN时通时断延迟跳变物理层ethtool -Scrc/frame 错误增长小包通大包不通链路层ping -s 1500 -M doMTU 或 VLAN 标签导致超长帧同网段部分主机不通链路层ip neighARP 状态 INCOMPLETE跨网段不通但同网段通网络层ip route、traceroute路由表或网关配置速度只有标称值十分之一链路层及以上iperf、ss -ti窗口、聚合哈希、双工这张表不是万能的但能覆盖八成的现场问题。它的用法是先定位层再在层内找具体原因而不是一上来就瞎猜。6. 抓包看帧把抽象概念变成屏幕上的一行行字节理论讲再多不如亲眼看一次帧的结构。抓包工具在这里的作用不是“看流量”而是“验证你对协议的每一个假设”。我建议每个做网络的人都至少完整拆解过一次 ARP 请求和一次 TCP 三次握手的帧结构那种“原来真的是这样”的感觉比背十遍书有用。6.1 一次 ARP 请求的字节级拆解假设主机 A00:11:22:33:44:55IP10.0.0.10要访问10.0.0.20不知道对方 MAC发 ARP 请求。这一帧在线上是这样的前导码 7 字节AA AA AA AA AA AA AA用于接收方时钟同步帧起始定界符 1 字节AB标志帧开始目的 MAC 6 字节FF FF FF FF FF FF广播源 MAC 6 字节00 11 22 33 44 55类型 2 字节08 06表示 ARPARP 载荷 28 字节硬件类型 2 字节00 01以太网、协议类型 2 字节08 00IPv4、硬件地址长度 1 字节06、协议地址长度 1 字节04、操作码 2 字节00 01请求、发送方 MAC 6 字节、发送方 IP 4 字节、目标 MAC 6 字节全 0、目标 IP 4 字节填充字段因为以太网最小帧长 64 字节不含前导码和 FCSARP 载荷只有 28 字节帧总长 14 28 42 字节不够 64要补 18 字节填充FCS 4 字节这里有个常被忽略的细节最小帧长 64 字节不是随便定的。早期共享式以太网用 CSMA/CD冲突检测依赖“发送方在发送过程中能听到冲突”。如果帧太短发送方可能在冲突信号传回来之前就发完了检测不到冲突。64 字节对应的就是最远距离下往返传播时间。现在全双工交换式网络不需要 CSMA/CD 了但最小帧长的规定保留了下来所以你会看到很多小包后面跟着填充字节。6.2 抓包时的三个常见误区第一个误区是没开混杂模式。默认情况下网卡只接收目的 MAC 是自己的帧或者广播/组播帧。如果要看经过本机但不发给本机的流量得开混杂模式。但注意在交换机环境下你本来就看不到别人的单播流量开混杂模式也没用除非配置了端口镜像。第二个误区是忽略网卡的卸载功能。现代网卡支持 TSOTCP 分片卸载、LRO大包接收卸载、校验和卸载。抓包工具抓到的是“卸载前”或“卸载后”的数据取决于抓包位置。你会看到“校验和错误”的帧或者看到超过 MTU 的巨帧这往往不是真的有问题而是卸载机制造成的假象。分析时要么关掉卸载ethtool -K eth0 tso off gso off gro off要么在分析工具里忽略校验和验证。第三个误区是看不到 VLAN 标签。很多网卡和驱动会在收到带标签的帧时自动剥离标签抓包时看到的是“干净”的帧。要看到标签得关掉 VLAN 剥离功能ethtool -K eth0 rxvlan off或者用支持显示标签的分析工具配置。# 关闭常见卸载避免抓包假象测试环境用生产慎用 ethtool -K eth0 tso off gso off gro off lro off # 关闭 VLAN 标签剥离 ethtool -K eth0 rxvlan off # 抓 ARP 包带完整链路层头 tcpdump -i eth0 -e -n arptcpdump -e这个参数很多人不知道它会打印链路层头部包括源 MAC、目的 MAC、以太类型必要时还有 VLAN 标签。看二层问题没有这个参数基本等于盲人摸象。我个人在实际操作中的体会是物理层和数据链路层的知识价值不在于考试而在于它给了你一套“不可辩驳”的判断依据。应用层的问题可以争论“是不是代码写错了”但rx_crc_errors在涨就是线有问题这种确定性在排障时特别珍贵。所以每次遇到“时通时断”和“偶发丢包”我都会先把这两层的计数抓出来看一眼这一步花不了两分钟却能省掉后面几小时的弯路。
