OSPF路由学不到，防环机制乱套了，到底该砍哪一刀？

　　最近在公司机房折腾MPLS VPN的OSPF对接，CE路由器死活学不到PE发来的路由。查LSA，发现Type5里DN位是1，CE直接丢掉了。翻文档、问老同事、抓包看tag，折腾两天才搞明白：原来不是设备坏了，是OSPF在VPN环境下自己给自己设了三道锁，每把锁开法不同，开错了就全卡住。

　　DN-bit其实就是个“身份标签”，PE从BGP学来路由再扔进OSPF时，悄悄打上DN=1，意思是“这玩意儿不是OSPF自己生的，是外面带进来的”。CE一看这标记，立马拒绝放进路由表——怕绕一圈又回BGP，形成环路。Route-tag更简单粗暴，华为默认填0，CE觉得“标签一样就是同源”，干脆不计算，防重复引入。这俩设计本身没问题，但放在真实场景里，比如客户CE压根没跑BGP，纯粹靠OSPF接VPN，这套防环逻辑反而成了拦路虎。

　　我们试过在CE上敲`dn-bit-check disable`，立马见效，路由全进了。可后来发现，隔壁机柜另一台CE也这么配，结果和PE之间的路由来回跳，下午三点那会儿，监控告警响了四次。后来才懂，这个命令只管本机，不影响别人，但全网CE都这么干，等于把防环责任甩给每台设备自己扛，出问题连锅都找不到源头。

　　`dn-bit-set`是PE侧动刀，让LSA发出去时DN位永远是0。听起来干净利落，但得所有PE统一配置，还得确认邻居CE是不是真能处理——有次测试环境里两台PE同时开这个，CE收到两条完全一样的Type5，SPF算来算去算懵了，干脆把其中一条标成无效，第二天业务组打电话说某条专线时断时续，查下来就是这个原因。

　　最猛的是`vpn-instance-capability simple`，一开全放行，DN位和Route-tag都不看了，LSA全塞进SPF计算。我们一开始图省事，在一台MCE设备上全开了，它底下连着三个VPN实例，结果其中两个实例的CE后来加了BGP，没过多久，流量就莫名其妙消失了一段，抓包发现路由表里有两条去同一目的地的路径，一条走OSPF，一条走BGP，但下一跳互相指，彻底堵死。这种环路不报错，也没告警，只能靠ping + traceroute一点点摸出来。

　　有次在机房蹲着看日志，发现一个细节：`dn-bit-check disable`命令在PE上敲根本没反应，命令能输进去，但show一下就没有生效标记。问研发那边才知道，PE压根不检查DN位，这是CE的事，配错地方等于白忙。还有人把`dn-bit-set`当成万能开关，全网PE一起开，结果CE端选路逻辑混乱，ECMP失效，部分流量走了黑路径，客户投诉说视频会议卡成PPT，查了六个小时才发现是LSA tag冲突导致的等价路由误判。

　　华为V200R024之后的版本，`vpn-instance-capability simple`打开后，Route-tag会自动重置为1，不是保持0。这点连官方手册里都写得模模糊糊，是我们抓包对比了十几次才确认的。还有一次割接前没清OSPF进程，老LSA还在LSDB里，新配置生效后，新旧LSA混在一起算，SPF树直接算歪了，CE上看到的路由掩码都变了。

　　现在遇到OSPF学不到路由，第一反应不是狂敲命令，而是先看CE有没有BGP邻居，再查PE发的LSA里DN和tag分别是多少，最后再决定动哪把刀。有时候问题根本不在OSPF，而在BGP下一跳不可达，CE收不到VPNv4路由，自然OSPF也分不出东西来。配命令就像拆保险丝，知道哪根能拔、哪根一拔整个楼都黑。

　　昨天又碰到一台CE学不到路由，show ip ospf database一看，Type5 LSA里DN=1，tag=0，CE配置了`dn-bit-check disable`但没生效。进去看才发现，OSPF进程绑在了错误的VPN实例下，进程根本没起来。重启进程后，三分钟内路由全回来了。

　　防环命令不是补丁，是开关。开关本身没好坏，关键是你知不知道它后面连的是灯还是炸药。配完记得用display ip routing-table看条目，用traceroute打个包，再看一遍LSDB。错了就undo，别硬扛。