13年经验：OSPF邻接卡死，防御瞬间崩盘！

　　2025年4月下旬的一个周二，下午三点刚过，正蹲在机房角落啃凉掉的外卖，兜里的手机突然震得慌——运维群里三个机房的人同时炸锅，喊着“核心区断了”“东西区不通”，我攥着汉堡冲过去的时候，才发现是刚换的那批OSPF邻接卡死了。

　　哪年类似的事？那是十一年前的春天，也是周二，同一批同型号的旧设备，也是邻接闪断，但那次只卡了一个机房，这次倒好，三个核心节点一起掉链，连带防御的防火墙都没反应——我原以为OSPF的邻接是最稳的那根线，结果这次直接被卡死，整个防御圈瞬间就崩了。

　　我蹲在机柜前，手指在设备上扒拉，后来把运维组的阿明喊过来，说你帮我盯着邻接表，我查路由。刚碰到核心交换机的console口，阿明突然喊：“你看，直连的OSPF邻居，状态卡2-WAY快三分钟了！”我凑过去，屏幕上那俩邻居的状态跳得死慢，连个LOADING的影子都没，连起手来的包都不飘一下。

　　那时候我还没往配置里钻，以为是端口的问题，换了俩光纤口，换了纤芯，结果邻接还是卡着。阿明蹲得腿麻，靠在机柜门上骂：“这比上次那事儿邪性，上次至少还能捡回来仨机房，这次连个预警都没。”旁边的小郑递了根网线，说试试直连那俩核心，我插上去，邻接倒是秒起来了，但一插回原来的端口，又卡回2-WAY，才发现不是硬件的事。

文章配图，仅供参考

　　那时候我才明白，之前总觉得OSPF的优胜劣汰是靠区域划分、链路选路，是把没用的邻居都筛掉，可这次的卡死，不是选路的问题，是连邻居都选不出来，直接把整个网络的“眼睛”给闭上了。小郑蹲在旁边，手里攥着刚拔下来的光纤，说那防御呢？我说防御是跟路由走的，路由断了，防御规则没人给递，防火墙就跟瞎子一样，看见流量也拦不住，直接就崩了。

　　后来折腾了快俩小时，把MTU值改回匹配，邻接才终于起来，路由一点点飘回来，防御规则才慢慢归位。那时候我擦了擦脸上的灰，才想起上次那事儿，也是改了参数，那次是hello包时间，这次是MTU，看来每次OSPF出问题，都是那种“你以为改了小参数没事”的破事。

　　我后来跟厂商的人说这事儿，人家说OSPF的优胜劣汰是对网络的要求，可这次的卡死，是把“劣”没筛掉，把“优”给卡没了，整个网络的自我调节没起作用，直接就崩了。我原以为OSPF的邻接是那种“只要参数对就稳如狗”的东西，结果这次才知道，它的“眼睛”挑邻居的时候，容不得半点儿差池，差一点就直接卡死，连救的机会都没。

　　哦对，刚才阿明说他上周也碰过一次类似的，只不过是边缘机房的，没影响核心，这次是我没盯紧新设备的参数，把MTU的事儿给漏了，这锅我背，刚才还跟小郑甩了个锅，是我没提前测，这点得承认。

　　后来我跟运维组的人说，以后新设备上线，OSPF的参数得拉着三个人一起测，MTU、hello、dead，都得跟旧设备匹配，别光看配置表，得直连测了再插回去。哪年的事儿？十一年前那时候，我们是仨人测一个设备，这次我自己大意了，才出的事儿。

　　现在每次OSPF配完，我都得盯着邻接表看十分钟，就怕再出这事儿——毕竟防御的根儿在路由，路由的根儿在邻居，邻居要是卡死了，整个防御圈就没了。优胜劣汰是好的，但得先把邻居给弄起来，不然再优的网络，也崩得快。

　　哦对，刚才小郑说他记不清当时改了啥，好像是厂商给的配置模板里带的MTU值，这次上线没改，是模板的坑，我后来找厂商要了个新模板，把MTU的参数给锁死了，以后再也不会出这事儿了。

　　现在再想起那天的情况，还是后背冒冷汗，三个机房的防御同时崩盘，要是当时有流量打过来，后果不堪设想。原来OSPF的邻接卡死，不是小问题，是整个网络的生命线出了问题，而这个问题的根源，就是我原以为的“小参数”，差点毁了一整个防御体系。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!