网络为什么有路由黑洞？带你认知网络的另一面

欢迎大家来到IT世界,在知识的湖畔探索吧!

写在前面

在NA时代，我们认为只要网络设备有路由条目，通信就一定正常，否则就无法通信，但到了NP，这个说法就不准确了。其实网络设备本身分为数据层面和控制层面。只有数据层面和控制层面都正常，这个通信才能保证OK。那么什么是控制层面和数据层面呢？

控制层面就是各种协议工作的层面。它的作用是通过控制和管理各种网络协议的运行，使得路由器/交换机能够对整个网络的设备、链路和运行的协议有一个准确的了解，并在网络发生变化时也能及时感知并调整。控制层面为数据层面转发数据提供了各种必要的信息。

数据层面是针对数据发送来说的。控制层面构建了路由表等数据发送的必要信息，数据层面根据这些信息来发送数据。网络设备中，对数据的各种具体的处理、转发过程都属于数据层面的范畴。数据层面主要占用的是硬件资源。了解这些之后，再来分析黑洞路由的产生，就不难了。

正文

欢迎大家来到IT世界,在知识的湖畔探索吧!

拓扑图

该环境为5台路由器，环境为eNSP，相关的IP、路由协议为上图所示，R1—R2为EBGP，R2-R4为IBGP关系，R4—R5为EBGP关系，R2—-R3—-R4为OSPF area0环境。

查看各路由器的详细情况

R1

R2

R3

R4

R5

在R1上发布自己的环回口（拓扑的中的主机）

[R1]bgp 100 [R1-bgp]network 1.1.1.1 32 -------------------------------- [R5]bgp 300 [R5-bgp]network 5.5.5.5 32

欢迎大家来到IT世界,在知识的湖畔探索吧!

在R1和R5查看路由表，看是否学到

R1

R5

此时肯定没有，原因在下图

由于学到的路由的下一跳为45.45.45.2，在R2的本地路由表没有该跳路由，所以打为次优路由，不会放入路由表，此时只需要在BGP修改路由的下一跳为本地即可，再查看下路由表

欢迎大家来到IT世界,在知识的湖畔探索吧![R2]bgp 200 [R2-bgp]peer 4.4.4.4 next-hop-local ------------------------------------------- [R4]bgp 200 [R4-bgp]peer 2.2.2.2 next-hop-local

R1

R5

此时双方都有各自的路由，进行ICMP测试（带源测试）

Ping测试

实验到这里问题就出现了，为什么有双方的路由却不通？我们详细看下1.1.1.1到5.5.5.5的详细过程

R1访问5.5.5.5，由于是跨网段，需要查询路由表，查询到的路由表为

R1查询路由表

要去往5.5.5.5下一跳为12.12.12.2，也就是R2，所以在R2的接口上抓包证实了这个过程

R2上抓包

此时包已经到了R2，在R2上查询路由表

R2路由表

此时发现去往5.5.5.5的下一跳为4.4.4.4，但4.4.4.4明显不是直连，所以继续查询去往4.4.4.4的路由

R2路由表

最终发现去往5.5.5.5的下一跳为23.23.23.2，即为R3，继续查询R3的路由

R3路由表

此时问题原因就出来了，就没有该条路由，从抓包结果可以看到

R3连接R2的接口抓包

R3接R4抓包无信息，证明R3接收到该ICMP报文，但由于没有路由信息就直接丢弃。那么我们预想的情况是怎么样的呢？

红色为理想访问，绿色为实际的访问流量

至此，整个问题的原因就找到了，问题出在R3上并没有路由，因此导致出现了路由黑洞，通信异常。那么实际工作情况会遇到吗？肯定会，最常见的就是MPLS-VPN里，很多这样的场景，这种解决访问有几种

• MPLS技术
• 组成FULL Mesh组网
• IGP、BGP重分发

由于2和3在现网中用的不多，所以讲解MPLS这种解决方案。MPLS解决的本质就是‘’欺骗路由器‘’，用标签构建控制层面，从而保证数据层面正常。命令十分简单（由于是实验环境，只涉及LDP分发标签）

[R2]mpls lsr-id 2.2.2.2 [R2-mpls]quit [R2]mpls ldp [R2-mpls-ldp]q [R2]interface GigabitEthernet 0/0/1 [R2-GigabitEthernet0/0/1]mpls [R2-GigabitEthernet0/0/1]mpls ldp [R2-GigabitEthernet0/0/1]quit [R2]route recursive-lookup tunnel 使能迭代隧道功能 ------------------------------------------------ [R3]mpls lsr-id 3.3.3.3 [R3-mpls]quit [R3]mpls ldp [R3-mpls-ldp]q [R3]interface GigabitEthernet 0/0/0 [R3-GigabitEthernet0/0/0]mpls [R3-GigabitEthernet0/0/1]mpls ldp [R3-GigabitEthernet0/0/1]interface GigabitEthernet 0/0/1 [R3-GigabitEthernet0/0/1]mpls [R3-GigabitEthernet0/0/1]mpls ldp [R3-GigabitEthernet0/0/1]quit [R3]route recursive-lookup tunnel ------------------------------------------------ [R4]mpls lsr-id 4.4.4.4 [R4-mpls]quit [R4]mpls ldp [R4-mpls-ldp]q [R4]interface GigabitEthernet 0/0/0 [R4-GigabitEthernet0/0/0]mpls [R4-GigabitEthernet0/0/1]mpls ldp [R4-GigabitEthernet0/0/1]quit [R4]route recursive-lookup tunnel

查看是否OK

R1上ping测试

R3抓包查看

此时访问正常，那么实验过程结束

总结

路由黑洞产生的本质为控制层面不通，控制层面在构建路由的时候因为协议的特性，导致配置存在缺陷，从而出现该现象。避免该问题可以通过网络的设计或协议巧妙的搭配，最后再说一句，问题的本质一定是有原因的，并非偶然，通过底层看本质，你会对协议更加了解，在后续MPLS-VPN会更加的详细描述黑洞路由的利用。