ospf报文类型有哪些(依托设备抓包区分现场报文)
上周夜班割接核心区三层组网，盯着Wireshark抓包盯了三个小时，才彻底理清ospf报文类型有哪些，之前背的书本分类放到现场基本用不上，书本只按功能分五类，现场抓包还要结合报文协议号区分，很容易搞混。
一开始直接照着题库记忆，把hello、dd、lsr、lsu、lsack当成全部五类，割接时发现设备之间频繁互发未知长度的ospf报文，和记忆里的特征对不上，一度以为是链路存在环路，直接下发了端口限流命令。现在回头看，这个操作完全多余，还导致两台接入设备邻居直接断裂。
限流后五分钟，两台设备邻居状态彻底down，控制台不停弹出邻居超时告警。当时下意识排查光衰、端口双工，反复插拔尾纤三次，光衰数值始终在-12db正常区间，双工模式也已经强制统一，链路层没有任何异常。这一步浪费了四十多分钟，典型的舍本逐末，链路没问题，问题全在报文交互逻辑。
后来才反应过来，限流把hello报文的最小发送带宽挤占了。hello报文默认十秒一发，是ospf维持邻居保活的唯一报文，长度只有44字节，属于极短报文。现场抓包能直观看到，全网所有正常建立邻居的设备，每间隔9.8-10.2秒就会推送一次，没有例外。之前一直忽略了它的带宽占用极小，盲目全局限流直接截断了保活交互。
（极短段落）dd报文是邻居协商后的第一轮同步报文。
dd报文不会携带完整路由条目，只携带LSA头部摘要，用来做两台设备之间的路由目录比对。当时抓包里dd报文成对出现，主从设备交替发送，主设备序列号递增速度更快。之前实操误区就是觉得dd报文会传路由明细，之前排查另一套组网时，浪费大量时间在dd报文中检索路由前缀，自然什么都找不到。
lsr、lsu、lsack是绑定联动的三类报文，不会单独出现。两台设备比对dd报文发现本地缺少LSA摘要后，立刻发出lsr报文请求明细，对端收到后推送lsu报文携带完整LSA数据，接收端校验无误后回复lsack确认。当晚割接里，核心和汇聚之间一共交互了117组这类联动报文，其中23组lsack报文丢失，导致局部路由重复刷新，cpu占用率短时冲高到47%。
当时没有做任何路由清洗，只是修改了接口mtu值，把默认1500改成1480，消除报文分片，丢失问题直接消失。事后翻看设备日志，才发现分片后的lsu报文会被交换机随机丢弃，ospf本身没有分片重组机制，这是书本完全不会提到的隐性细节。
还有一个书本遗漏的点，本地设备自发产生的ls刷新报文，归类依旧属于lsu，不属于独立第六类报文，网上很多博主拆分六类报文的说法都是错的，现场三十次以上抓包都没有检出独立第六类ospf协议报文。
天亮之后随手清空了设备抓包缓存，盯着控制台剩余的路由收敛进度条发呆。最懊恼的是当初无脑套用书本知识点，没有提前现场抓包核验。
# ospf报文类型有哪些(依托设备抓包区分现场报文)
上周夜班割接核心区三层组网，盯着Wireshark抓包盯了三个小时，才彻底理清ospf报文类型有哪些，之前背的书本分类放到现场基本用不上，书本只按功能分五类，现场抓包还要结合报文协议号区分，很容易搞混。
一开始直接照着题库记忆，把hello、dd、lsr、lsu、lsack当成全部五类，割接时发现设备之间频繁互发未知长度的ospf报文，和记忆里的特征对不上，一度以为是链路存在环路，直接下发了端口限流命令。现在回头看，这个操作完全多余，还导致两台接入设备邻居直接断裂。
限流后五分钟，两台设备邻居状态彻底down，控制台不停弹出邻居超时告警。当时下意识排查光衰、端口双工，反复插拔尾纤三次，光衰数值始终在-12db正常区间，双工模式也已经强制统一，链路层没有任何异常。这一步浪费了四十多分钟，典型的舍本逐末，链路没问题，问题全在报文交互逻辑。
后来才反应过来，限流把hello报文的最小发送带宽挤占了。hello报文默认十秒一发，是ospf维持邻居保活的唯一报文，长度只有44字节，属于极短报文。现场抓包能直观看到，全网所有正常建立邻居的设备，每间隔9.8-10.2秒就会推送一次，没有例外。之前一直忽略了它的带宽占用极小，盲目全局限流直接截断了保活交互。
dd报文是邻居协商后的第一轮同步报文。
dd报文不会携带完整路由条目，只携带LSA头部摘要，用来做两台设备之间的路由目录比对。当时抓包里dd报文成对出现，主从设备交替发送，主设备序列号递增速度更快。之前实操误区就是觉得dd报文会传路由明细，之前排查另一套组网时，浪费大量时间在dd报文中检索路由前缀，自然什么都找不到。设备先通过hello报文确认双向互通、区域参数一致，再协商主从身份，之后才会推送dd报文，这个时序颠倒也会直接导致邻居卡在loading状态，之前遇到过两次，都没弄懂时序逻辑。
lsr、lsu、lsack是绑定联动的三类报文，不会单独出现。两台设备比对dd报文发现本地缺少LSA摘要后，立刻发出lsr报文请求明细，对端收到后推送lsu报文携带完整LSA数据，接收端校验无误后回复lsack确认。当晚割接里，核心和汇聚之间一共交互了117组这类联动报文，其中23组lsack报文丢失，导致局部路由重复刷新，cpu占用率短时冲高到47%。运维看板里cpu告警持续了两分多钟，机房告警音箱一直滴滴响，周边同事都以为是路由雪崩，其实只是报文分片导致的确认丢失。
当时没有做任何路由清洗，只是修改了接口mtu值，把默认1500改成1480，消除报文分片，丢失问题直接消失。事后翻看设备日志，才发现分片后的lsu报文会被接入层二层交换机随机丢弃，普通二层交换机不识别ospf内层协议，只会按照ip分片规则转发，超大分片会直接丢弃，而ospf本身没有内置分片重组机制，这是书本完全不会提到的隐性细节，所有教材只会单纯罗列五类报文名称。
还有一个实操误区，网上很多博主拆分出第六类刷新报文，但本地三十多次不同组网抓包都能验证，设备自发触发的LSA周期刷新报文，报文头部类型字段依旧标注为lsu，不属于独立新报文，网传六类报文的说法纯粹是概念混淆，不能在线上排查里采信。
天亮之后随手清空了设备抓包缓存，盯着控制台剩余的路由收敛进度条发呆。最懊恼的是当初无脑套用书本知识点，没有提前现场抓包核验。