山石网科如何利用GRE+IPSEC+BFD进行高可用组网-经验分享篇

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了山石网科如何利用GRE+IPSEC+BFD进行高可用组网-经验分享篇相关的知识,希望对你有一定的参考价值。

有些日子没过来写文章,一是最近在研究阿里云(ACP)等组网以及考试,而是也发现没有什么特别实用的技术在blog中去分享。不出意料的在上周通过了ACP的考试,发现云计算中又出现了一些的组网应用,虽然在阿里云和目前很多公司的云平台操作的时候,很难感觉到网络的存在,都是自己点一点就好了。。但如果在使用的过程只是这么简单以为的话,这是会出大问题的。


比如从网络的容灾的概念中,你虽然在各大云平台得到了网络配置的最大简化体验,此时网络工程的重心就会辐射到容灾、安全、流量切换等等。这些作为但凡作为一个运维都要考虑,而且要花大量的精力去做这件事情。


今天写文章不是聊云化的趋势和带来的改变等等,今天仍然是介绍一次真正案例中我们利用GRE、IPSEC、BFD解决冗余组网和自动切换的问题。且具有强大的“万精油”属性,在任何组网的案例下,都会有这样的需求,而且使用的都是标准协议,所以可以负责任的讲,如果企业没有强大的资本支撑IT的业务扩展时对高可靠的要求时,今天的这一篇文章就非常值得大家读一读里面的思想。时间匆忙,简单的画了一个示意图,如下所示:

技术分享

以上部分是简化过的拓扑,一是为了保护原案例的相关信息,二是助于大家去理解。


项目案例需求背景:

  1. 需要部署灾备数据中心,两个数据中心内网通过专线打通(我这里使用GRE做的测试,因为GRE在功能实现上就相当于物理专线MSTP,所以这个做完了,相当于专线也讲了一遍)

  2. 双数据中心无需做到同城双活,仅仅是在主数据中心上联出口完全中断,且恢复时间不可控时,我们把业务完全切换到灾备数据中心

  3. 需要保证两地之间通信除了专线物理线路,另外还要存在一条备份冗余链路,并可实现完全无缝自动切换

PS:需求我也做了省略很简化,关于DNSPOD、业务侧的切换、集群业务等等这里都不做过多的赘述,不然文章写不完了都,以后会慢慢补上


项目案例背景:

  1. 出口设备为:山石网科T级产品线(很高端设备)

  2. 交换机华为6700万兆

  3. 服务器上百台

  4. 存储、光交

  5. 内网waf、堡垒机、备份一体机等等

PS:这里详细介绍忽略一切三层设备,直接从山石网科设备上实现该功能,因为山石实现后,我们去把这个拆分到三层交换机上,或者其他路由器设备上都没问题。无非就是几条路由的问题。【原谅我这么嚣张,因为路由、交换真的就是用心学就搞的定,不要虚,好好学就总有一天会学会】


我这里就以工程师技术实施部署的思路去给大家介绍下。当然,还是以前一样,底层的配置不作赘述。

第一步,山石网科配置GRE,我们在FW-A和FW-B上配置了GRE,如下为数据配置方法,参考如下即可。zone、策略、路由配置这里不提及,希望大家多全面学习,不要做伸手党。

FW-A

tunnel gre "tofw-b"

  source 210.20.1.1

  destination 200.10.1.1

  key 10

  interface ethernet0/1

exit

interface tunnel1

  zone  "GRE"

  ip address 1.1.1.1 255.255.255.252

  manage ping

  tunnel gre "tofw-b" gw 1.1.1.2

————————————————————

FW-B

tunnel gre "tofw-a"

  source 200.10.1.1

  destination 210.20.1.1

  key 10

  interface ethernet0/1

exit

interface tunnel1

  zone  "GRE"

  ip address 1.1.1.2 255.255.255.252

  manage ping

  tunnel gre "tofw-a" gw 1.1.1.1


第二步,测试GRE直连地址是否可以通信?

FW-A# ping 1.1.1.2

Sending ICMP packets to 1.1.1.2

   Seq    ttl    time(ms)

   1      128    1.09 

   2      128    0.938 

   3      128    1.01 

   4      128    0.962 

   5      128    0.947 

statistics: 

5 packets sent, 5 received, 0% packet loss, time 4005ms

rtt min/avg/max/mdev = 0.938/0.989/1.091/0.069 ms


确认可以通信,即证明GRE完成配置。


第三步,测试底层主机是否可以内网通信,并测试路由走向?

主机:10.137.97.1

ping测图:技术分享

tracert图:

技术分享


主机:10.137.98.1

ping测图:

技术分享

tracert图:

技术分享


综上,目前内网间的流量即可实现从GRE互通了。第一阶段需求完成,那我们现在配置备份线路IPSEC,这里仍然使用的路由模式的IPSEC。


第二阶段,配置山石网科的IPSEC-VPN,我这里就不做介绍了,因为之前的文章中都有非常详细的介绍,若大家不熟,请参考官方手册或者参考以前笔者文章。

此时,因为路由模式IPSEC同样是需要目的路由来实现通信,我这里为了方便测试,这里我们暂时先把GRE的优先级就行了上调,使其与IPSEC的目的路由形成“浮动静态”。


主机:10.137.97.1

tracert图测试如下:

技术分享


主机:10.137.98.1

tracert图测试如下:

技术分享


好了,IPSEC的配置也完成并通过业务验证了。所以我们接下来要做今天非常重要的一步,就是如何使其GRE成为主线,IPSEC成为备份线路并实现自动切换,以及当GRE线路恢复后,线路再次切换回GRE主线。


第三阶段,配置BFD,在vroute中进行BFD的关联,这好比在路由后面加上track和优先级的概念,不难理解。

FW-A(config)# bfd echo-source-ip 1.1.1.1 

FW-A(config-vrouter)# ip route 10.137.98.0/24 tunnel1 1.1.1.1 bfd 

FW-B(config)# bfd echo-source-ip 1.1.1.2

FW-B(config-vrouter)# ip route 10.137.97.0/24 tunnel1 1.1.1.1 bfd

PS:这里我使用了直连接口做的检测,大家若有不同意见,当然可以用loopback或者其他方式实现,没有固定的配置思维模式 

————————————————————————————————————

LOG输出如下:

FW-A(config-vrouter)# 2017-04-04 01:51:16, Event [email protected]: BFD session state changed from Down to Up,local IP:1.1.1.1,neighbor IP:1.1.1.2

FW-B(config-vrouter)# 2017-04-04 01:51:14, Event [email protected]: BFD session state changed from Init to Up,local IP:1.1.1.2,neighbor IP:1.1.1.1


接着我们把两台山石网科的GRE的路由调整为默认的1,IPSEC的目的路由优先级调整为10,如下参考:

FW-A# show ip route

==============================================================================

S>* 10.137.98.0/24 [1/0/1/b] via 1.1.1.2, tunnel1

S   10.137.98.0/24 [10/0/1] is directly connected, tunnel2

==============================================================================


FW-B# show ip route

==============================================================================

S>* 10.137.97.0/24 [1/0/1/b] via 1.1.1.1, tunnel1

S   10.137.97.0/24 [10/0/1] is directly connected, tunnel2

==============================================================================

PS:以上做过简化

结论:可以发现,目前路由表中已经形成了浮动静态的状态,并tunnel的路由中成功挂在了BFD功能。所以我们现在可以进行完美的故障切换了。


切换过程中,属于动态的观察,而blog只能上传静态图片,所以我这里稍微简单的描述下。因为确实在我测试的过程当中也比较惊讶完全的无缝切换,没有任何丢包和延迟升高的情况。总之,听我讲倒不如大家去测试真实的体验一把,这样会更深刻一点。


故障模拟:

    shutdown GRE的tunnel接口===好比物理专线故障


以下为测试故障的过程截图,【没有】

主机:10.137.97.1

切换过程中前后ping包情况,中断后的瞬间,前后tracert图情况:

技术分享


主机:10.137.98.1

切换过程中前后ping包情况,中断后的瞬间,前后tracert图情况:

技术分享


然后我再次执行tunnel接口no shut的时候,情况和上面完全一样。所以这里的截图就省略不贴了。


模拟故障时,BFD的底层log提示:

FW-A# 2017-04-04 03:16:38, Event [email protected]: BFD session state changed from Up to Down,local IP:1.1.1.1,neighbor IP:1.1.1.2

技术分享


模拟故障恢复时,BFD的底层log提示:

FW-A# 2017-04-04 03:21:50, Event [email protected]: BFD session state changed from Down to Up,local IP:1.1.1.1,neighbor IP:1.1.1.2

技术分享


结论:

山石网科通过GRE+IPSEC+BFD实现两点专线热冗余方案验证通过,可以去PPT中写方案去了。


写在最后,当然这里也需要给大家再次提醒一次,我这属于实验环境,网络情况相对封闭和稳定,无法客观的呈现出广域网的故障情景,起码不会出现被“挖掘机”挖断光缆的事情,光衰过弱的情况,设备故障的情况等等~~~~~~~,所以网络这条路很长也很远,甚至可以讲深不可测。但是网络依然是改变所有业务支撑方式的最大的功臣,所以希望大家不会忽略网络的重要性,也不要骄傲自大以为自己会配置几个静态路由、配置几条VPN就觉得网络没什么可以学的了。

                        ————————来自一家二级运营商的网工分享


把学习当成习惯,把努力奋斗当作人生格言,把分享转换为大家的力量。



QQ:549675970

【欢迎加我交流技术心得,大家互相学习】

QZONE:http://user.qzone.qq.com/549675970

E-mail:

          [email protected]

             [email protected]


人生格言:越努力、越幸运


本文出自 “Allen在路上-从零到壹” 博客,转载请与作者联系!

以上是关于山石网科如何利用GRE+IPSEC+BFD进行高可用组网-经验分享篇的主要内容,如果未能解决你的问题,请参考以下文章

山石网科发布重磅容器安全产品“山石云铠”,云安全版图再下一城

山石网科防火墙图形配置

打破“单点防护”缺陷,山石网科发布“云网端”XDR解决方案

山石网科-Hillstone-HA(高可用)active/standby固件版本升级终结经验篇

山石网科-Hillstone-双ISP接入流量故障排错终结篇

山石网科发布数据安全综合治理体系,覆盖数据全生命周期