本帖最后由 闫辉 于 2021-2-22 10:59 编辑
在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
第二个场景：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
而这个命令在华为官方文档中，原文如下： 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位是否是置位状态。
添加老师：Tigerlab666666，即可免费领取哦！
| 
简体中文
英语
日语
韩语
法语
西班牙语
越南语
泰语
阿拉伯语
俄语
葡萄牙语
德语
意大利语
希腊语
荷兰语
波兰语
保加利亚语
爱沙尼亚语
丹麦语
芬兰语
捷克语
罗马尼亚语
斯洛文尼亚语
瑞典语
匈牙利语
繁体中文
文言文
发表于 2021-2-22 10:29:08
置顶卡
喧嚣卡
变色卡
千斤顶
感谢大神！
