来源头条作者:网络工程师6IE闫辉
在MPLS VPN 中， OSPF 设置了两个防环技术，一个是DN位防环， 一个是vpn-instance-capability，但是关于这两个防环技术具体怎么使用 ， 在官网也没找到使用案例，不过， 在找的过程中， 发现官网文档写的有错误，文末位置有详细介绍。
今天， 和大家讨论一下，为什么OSPF 要设置两个防环技术。
开局先上图：
实验环境：
如图， 在这个环境中，R2-3-4 属于运营商的MPLS域， 两两之间建立IBGP 邻居关系。R2-3-4 使用ospf 1 作为底层路由协议， 实现底层连通性
R5 上宣告一条路由， 给到R4 ， R4 绑定vpn instance，导入到MPLS网络中，通过BGP传递给R2 和R3 ，
R2和R3 再把路由导出传给R1，R1 会学习到两条相同路径。
想一下在这个环境中是否会出现环路，
环境配置：
首先配置环境，R2/3/4之间运行OSPF 1作为底层 路由协议， 实现底层连通性，并且启用MPLS+LDP
配置命令：
OSPF 配置过程省略， 宣告接口为R2/3/4之间的直连接口以及环回口， 全部宣告进area 0
全局模式下
mpls lsr-id 2.2.2.2
mpls
mpls ldp
内网接口下
mpls
mpls ldp
在R2/3/4 上分别使用这两条命令可以看到有2个内网接口启用MPLS，并且有2个LDP邻居
[R2]display mpls interface
[R2]display mpls ldp peer
接着配置R2/3/4 之间的BGP，环回口建邻居 ,
下边以R2 配置为例：
bgp 100
router-id 2.2.2.2
peer 3.3.3.3 as-number 100
peer 3.3.3.3 connect-interface LoopBack0
peer 4.4.4.4 as-number 100
peer 4.4.4.4 connect-interface LoopBack0
#
ipv4-family unicast
undo synchronization
peer 3.3.3.3 enable
peer 3.3.3.3 next-hop-local
peer 4.4.4.4 enable
peer 4.4.4.4 next-hop-local
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
ipv4-family vpn-instance 1
import-route ospf 100
#
ospf 1 router-id 2.2.2.2
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 23.1.1.2 0.0.0.0
network 24.1.1.2 0.0.0.0
#
ospf 100 vpn-instance 1
import-route bgp
area 0.0.0.0
network 12.1.1.2 0.0.0.0
同理，R3/4 也做相同操作
R1/2/3/5 之间运行OSPF 100， 关联vpn instance 1，
配置好以后， 检查R1/5 的OSPF 邻居， 没有问题，
查看R1 路由表， 发现有R5 路由， 说明路由连通性没有问题， 一共有2条路由， 一条是R2 过来的， 一条是R3 过来的。
第一个场景：DN位防环
接下来我们在R1的g0/0/0口抓包， 在R5 上撤销这条5.5.5.5/32的路由， 再重新通告一下，
发现这条路由的OSPF 报文中的option 字段中存在N位置位， 这个DN位就是为了防止环路的， 那么， 这个环路是怎么来的呢？
R5 把路由传递给R4， R4 把路由传递给R2/3， R2/3会把路由传递给R1 ， R1 会把路由传递给R3/2
现在我们分析R3，R3 会收到R1 和R4 两个方向的路由，现在我们查看到R3 上去往5.5.5.5/32的路由是R4 ， 只能说R3 从R1 收到的路由不是最优的， 不能加表， 正常情况下， R1 是会把路由给R3 的，我们在R3 上做了BGP和OSPF的双向路由引入，而R2/3之间是有IBGP邻居关系的，这样就会出现环路问题， 现在我们去R2 上看一下这个路由，可以看到R2 上去往5.5.5.5/32的路由下一跳也是4.4.4.4.不管从哪个方向接收的路由， 最终的下一跳都是4.4.4.4， 意思是说， R3 并没有把R4-2-1 发送过来的路由放入路由表中，同理， R2 没有把R4-3-1 传递过来的路由放入路由表中， 而这个地方没有出现环路， 原因说就这里DN位置位了，
因为PE（R2）向CE（R1）通告OSPF路由的时候，会把相应3类LSA中option 字段的DN位置位， 只要你是OSPF路由的3类LSA， 这里DN位就会置位， 另外一个PE收到带有DN位置位的LSA， 是不计算的，
这里， 如果我们把DN位关了， 会发生环路吗？
关闭R2 OSPF100 中DN位
[R2-ospf-100]dn-bit-set disable ?
ase AS external link states——-关闭5类LSA 中DN位
nssa NSSA external link states——–关闭7类LSA中DN位
summary Network summary link states——关闭3类LSA中DN位
[R2-ospf-100]dn-bit-set disable summary ——这里我们关闭3类LSA中DN位
同样在R1 G0/0/0口抓包， 发现DN位已经关闭
接下来查看R1 路由表，发现R1 关于5.5.5.5/32的路由下一跳是R2
而关闭R2 DN位之前， 这里是等价负载均衡的
为什么下一跳R3 消失了呢？
这里可以理解， R3 不给R1 通告路由了， 现在只是把PE的OSPF DN位关闭了， 为什么还会影响CE呢？
我们分析一下R3， R3 会收到R1 和R4 分别发送过来的关于5.5.5.5/32的路由， 两边的路由都是DN位不置位的，
那么R3会不会计算呢？应该是会计算的，
R3 收到左边的路由是3类LSA，OSPF 优先级10，从右边收到的这条路由是BGP，优先级是255， 所以优选左边过来的路由， R3 关于这条路由下一跳应该是R1 ， 现在我们查看R3 路由表：
现在我们分析一下， 关于这条5.5.5.5/32的路由， R3 的下一跳是R1， R1 的下一跳是R2 ， 那么R2 的下一跳是谁呢？还是4.4.4.4， 因为下边这个R3 ， 我们并没有关闭DN位， 所以R2 收到这个R3 发的路由还是不计算的
所以这里没有环路， 现在我们把R3 的DN位关闭，
[R3-ospf-100]dn-bit-set disable summary
现在分析一下， R2和R3 关于5.5.5.5的下一跳都应该是R1，我们检查一下路由表
发现
发现并没有出现环路，这是为什么呢？
因为R2 没有收到R1 通告的这条LSA，因为在R3上关闭DN位的时候，R3 是从R1 收到LSA的， R3 就不会再向R1 通告这条LSA， 所以R2 也就没有收到这条SLA .,这是路由水平分割，是根本就没有传过来， 而不是收到不计算。
所以R2 永远指向4.4.4.4， 所以这里还是没有环路，网络还是通的。
构造环路
现在我们把R2 g0/0/1口关闭， 分析一下会出现什么问题
[R2]interface GigabitEthernet 0/0/1
[R2-GigabitEthernet0/0/1]shutdown
现在我们把这条链路关闭， R2 就收不到4.4.4.4 发送过来的5.5.55路由， 也不会把这条路由发送给R1，
现在分析一下路由流向， R5 把路由发送给R4 ， R4 把路由发送给R3 ，R3 把路由通告给R1 ， R1 会把路由通告给R2 ， 那么R2关于这条路由下一跳应该是R1 ，这应该是OSPF计算的结果，这个圈现在应该是反过来了，
现在我们查看R2 上这条路由的下一跳。
发现还是R4， 但是出接口改成g0/0/0了， 看刚才R2关于这一条路由的出接口是g0/0/1，
也就是说， R2 去往5.5.5.5 下一跳是4.4.4.4， 但是要经过R3 ，这个时候路径走向是R1-2-3-4-5， 依然没有环路，
现在我们查看R3 路由表。
R3 关于这条路由的下一跳是R1 ， 路由走向是R5-4-3-2-1， 这个路径难以理解， 到此， 这个环路还是没有产生。
但是， 假设R3 G0/0/1 口出现故障， 我们分析一下， 把R3 gi0/0/1 口关闭
[R3]interface GigabitEthernet 0/0/1
[R3-GigabitEthernet0/0/1]shutdown
查看环路
接下来查看R1-2-3 路由表
发现虽然目的地不可达， 路由表条目并没有消失，
可以看到R1 指向R2 ， R2 指向R3 ， R3 指向R1 ， 此时， 已经形成了环路
现在我们把DN 位恢复， 发现环路消失
[R2-ospf-100]undo dn-bit-set disable summary
[R3-ospf-100]undo dn-bit-set disable summary
此时的实验环境：OSPF_DN_Bit_MPLS.zip
第二个场景：vpn-instance-capability simple 防环
现在我们换个场景，如图， 还是这个环境， 只是把R1 和R3 之间的区域改为area 1
查看DN 位默认值
现在我们把接口开起来， DN位启用， 查看R1 路由表， 路由5.5.5.5/32已经学习到了两条等价路由
环境配置变更：把R1-3 之间的链路宣告进area 1， 现在邻居都起来了。
我们再来查看R1 路由表
问题：现在R2 把路由发给R1 ， R1 转发给R2 的时候， 这个DN位是置0 还是置1？
现在R1 是一个ABR，我们验证一下
在R3G0/0/2口抓包， 在R5 上重新宣告一下5.5.5.5/32
我们可以看到 ， 有2个LSU，一个源是R1 ， 一个源是R3，
来自R1 的LSU中DN位是没有置位的， 而来自R3 的LSU中DN位还是置位的，
由于R3 收到R1 发过来的LSU，DN位没有置位， 所以还是会正常计算，相当于关闭DN位，
这里DN位为什么关闭了？
因为经过R1， 而R1是ABR， 已经还原了DN位为初始参数。
在这里， 由于 R1 是ABR ， LSA经过ABR的转发， 已经关闭DN位防环功能， 所以， 不能依靠DN来防环，
所以OSPF 还有另外一个防环机制， 来解决DN位关闭的环路场景， 这个工具就是
vpn-instance-capability simple
构造环路
首先， 默认情况下， 这个vpn-instance-capability simple 功能是默认开启的， 查看配置， 是不显示的，
我们现在R2-3 都是默认配置， 这个功能默认开启，先查看R1 关于5.5.5.5/32的路由下一跳：
可以看到，R1 去往5.5.5.5/32的下一跳是R2，
R2 去往5.5.5.5/32的下一跳是R4， 出接口是去往R4 的接口G0/0/1，
我们把R2去往R4 的接口关闭，
[R2]interface GigabitEthernet 0/0/1
[R2-GigabitEthernet0/0/1]shutdown
再次查看R2 路由表
发现下一跳还是R4 ， 但是出接口是去往R3 的，
我们查看R3 路由表
发现R3 的路由表中5.5.5.5/32 路由是去往R4 的， 出接口也是去往R4 的。
接下来我们分析，由于R1 本地是拥有去往5.5.5.5/32的路由的， 下一跳是R2， R2的下一跳是R3 ，
而R1 是不知道这条路由是来自R3 的， 所以R1 会非常信任这条从R2 学习来的路由， 而现在路由流向是
R5-4-3-2-1， 由于R3的路由是通过R4 学习路由， 通告给R2 的，没有通告给R1 ，R3 也不可能把自己的路由通告给R1 ，因为R3 是靠近MPLS 网络， 这个MPLS是OSPF的超级骨干，R1-3之间是区域1 ，R1 -2之间是area0，根据OSPF LSA的传递规格，两个骨干区域被非骨干区域分割，这种LSA是传递不过去的，反而R3 是有可能从R1 获取LSA的，因为R1-3 之间是area1，从ABR （R1）获取area 0的LSA是情理之中的，
接下来我们在R3 上把这个防环功能关闭
查看R3 路由表
发现这个时候， 已经形成了环路：
我们再来回顾一下环路：
现在已经形成环路， 可以把R3 去往R4 的接口关闭了，由于R3 去往5.5.5.5的路由出接口是G0/0/2， 下一跳是R1 ， 所以关闭R3 去往R4的右边接口， 对于这条路由来说， 应该不消失
[R3]interface GigabitEthernet 0/0/1
[R3-GigabitEthernet0/0/1]shutdown
接下来检查环路效果， 在R1 上
[R1]tracert -a 1.1.1.1 5.5.5.5
这是当前配置环境
ospf_MPLS_simple.zip
而这个命令在华为官方文档中，原文如下：
https://support.huawei.com/hedex/hdx.do?docid=EDOC1000184580&tocURL=resources%2Fdc_ac_cli%2Fvrp%2Fvpn-instance-capability_simple_ospf.html
显然这里的说法是错误的，R3 收到来自R1 的LSA中， 由于R1 是ABR，DN位已经恢复为未置位状态，
在R3 上是看不到这个DN位置位的LSA的， vpn-instance-capability simple 检查功能显然不能检查到DN位是否是置位状态。
