通过GRE隧道实现OSPF、BGP、IS-IS的套接使用

正文共：999 字 9 图，预估阅读时间：1 分钟

书接上文**（** 专线入云场景能否配置动态路由协议？），我们发现通过一定的配置，具体就是组合使用IBGP和静态路由，在使用云专线接入到资源池后通过动态路由协议可以实现云上云下业务的互通。缺点也是很明显的，那就是转发的所有流量在专线交换机上都要有对应的路由配置，两端配置动态路由协议，中间设备还要逐条配置静态路由，这个动态路由确实用了个寂寞。

其实要解决也很简单，一是可以提前做好网段规划，直接在专线交换机上配置好大段的静态路由，这样整体网络的变动就比较小了。

但事情发展往往是变化的，如果我们还是想使用动态路由协议，那不妨考虑一下使用隧道技术规避掉专线交换机的影响。

这里推荐使用GRE隧道就好了，简单好用。

VSR

css 复制代码

#
interface Tunnel1 mode gre
 ip address 10.11.1.1 255.255.255.0
 source 10.1.1.1
 destination 172.16.1.2

css 复制代码

#
interface Tunnel1 mode gre
 ip address 10.11.1.2 255.255.255.0
 source 172.16.1.2
 destination 10.1.1.1

配置完成之后，查看隧道状态及网络连通性。

IBGP

有了这个二层接口之后，动态路由是不是就能随便使用了呢？我们先看看IBGP。

VSR

css 复制代码

#
bgp 100
 router-id 10.11.1.1
 peer 10.11.1.2 as-number 100
 #
 address-family ipv4 unicast
  import-route direct
  peer 10.11.1.2 enable

css 复制代码

#
bgp 100
 router-id 10.11.1.2
 peer 10.11.1.1 as-number 100
 #
 address-family ipv4 unicast
  peer 10.11.1.1 enable

查看邻居建立状态。

邻居建立成功，测试一下业务可达性。

可以看到，一跳即达，通过GRE隧道转发成功。

EBGP

上次测试EBGP，因为不是直连的，导致邻居建立失败，现在我们再测试一下EBGP邻居能够正常建立。

VSR

css 复制代码

#
bgp 100
 router-id 10.11.1.1
 peer 10.11.1.2 as-number 200
 #
 address-family ipv4 unicast
  import-route direct
  peer 10.11.1.2 enable

css 复制代码

#
bgp 200
 router-id 10.11.1.2
 peer 10.11.1.1 as-number 100
 #
 address-family ipv4 unicast
  import-route direct
  peer 10.11.1.1 enable

看一下邻居建立状态。

邻居建立成功，测试一下业务可达性。

一跳即达，通过GRE隧道转发成功。

OSPF

那使用OSPF能不能行呢？

VSR

css 复制代码

#
ospf 1
 import-route direct
 area 0.0.0.0
  network 10.11.1.0 0.0.0.255

css 复制代码

#
ospf 1
 import-route direct
 area 0.0.0.0
  network 10.11.1.0 0.0.0.255

看一下邻居建立状态。

邻居建立成功，测试一下业务可达性。

可以看到，在同时配置了EBGP和OSPF时，OSPF的路由优先级为150，高于EBGP的255，所以优先展示。结果同样是一跳即达，通过GRE隧道转发成功。

IS-IS

最后我们再测试一下IS-IS。

VSR

properties 复制代码

#
isis 1
 is-level level-1
 network-entity 10.0000.0000.0001.00
 #
 address-family ipv4 unicast
  import-route direct level-1
#
interface Tunnel1 mode gre
 isis enable 1

properties 复制代码

#
isis 1
 is-level level-1
 network-entity 10.0000.0000.0002.00
 #
 address-family ipv4 unicast
  import-route direct level-1
#
interface Tunnel1 mode gre
 isis enable 1

配置完成之后，我们发现邻居关系不太稳定，一直在频繁的UP/DOWN。大概是UP之后持续30秒左右，然后再经过10秒左右重新UP。

这个时间间隔和IS-IS的Hello报文发送时间间隔基本类似。通过分析，我们可以看到，这个异常主要是因为引入了全部直连路由导致的。

默认情况下，GRE隧道接口的两个地址是可以直接互通的，第一个IS-IS的Hello报文发送之后，双方进入邻居协商阶段，此时会将直连路由也引入进来，因为IS-IS的比较高，是15，高于我们之前配置的底层链路的静态路由的优先级60，这就导致静态路由失效，两个邻居之间就不通了；紧接着，过了3个Hello报文发送时间间隔之后，邻居关系失效。周而复始，循环往复。

解决方案也有，可以配置IS-IS协议的路由优先级低于静态路由，也可以配置路由策略不引入底层配置了静态路由的接口路由。

不过，为了简单，建议就别用IS-IS了，毕竟OSPF和BGP都能使用了。

总结一下，在配置了GRE隧道之后，OSPF、IBGP、EBGP都能正常使用；如果要使用IS-IS，可以配置IS-IS协议的路由优先级低于静态路由，也可以配置路由策略不引入底层配置了静态路由的接口路由。

长按二维码

关注我们吧

专线入云场景能否配置动态路由协议？
<> <>

IPsec封装引入了额外的报文开销，具体是多少？
<> <>

软考里面竟然开始考H3C CAS了，突击补一下课
<> <>

H3C CAS部署之安装CVK节点
<> <>

H3C CAS部署之CVM纳管CVK节点
<> <>

H3C CAS部署Windows虚拟机
<> <>

通过SNMP统计网络资产
<> <>

用SNMP模仿Zabbix读取设备接口流量
<> <>

79.55 Gbps！已经初步测得VMWare ESXi 6.7的vSwitch转发性能
<>