有些日子沒過來寫文章，一是最近在研究阿里云（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-×××，我這里就不做介紹了，因為之前的文章中都有非常詳細的介紹，若大家不熟，請參考官方手冊或者參考以前筆者文章。

此時，因為路由模式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 CRIT@NET: 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 CRIT@NET: 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 CRIT@NET: 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 CRIT@NET: BFD session state changed from Down to Up,local IP:1.1.1.1,neighbor IP:1.1.1.2

結論：

山石網科通過GRE+IPSEC+BFD實現兩點專線熱冗余方案驗證通過，可以去PPT中寫方案去了。

寫在最后，當然這里也需要給大家再次提醒一次，我這屬于實驗環境，網絡情況相對封閉和穩定，無法客觀的呈現出廣域網的故障情景，起碼不會出現被“挖掘機”挖斷光纜的事情，光衰過弱的情況，設備故障的情況等等~~~~~~~，所以網絡這條路很長也很遠，甚至可以講深不可測。但是網絡依然是改變所有業務支撐方式的最大的功臣，所以希望大家不會忽略網絡的重要性，也不要驕傲自大以為自己會配置幾個靜態路由、配置幾條×××就覺得網絡沒什么可以學的了。

                        ————————來自一家二級運營商的網工分享

把學習當成習慣，把努力奮斗當作人生格言，把分享轉換為大家的力量。

QQ:549675970

【歡迎加我交流技術心得，大家互相學習】

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

E-mail：

          549675970@qq.com

             allen_junjun@hotmail.com

人生格言：越努力、越幸運

文章標題：山石網科如何利用GRE+IPSEC+BFD進行高可用組網-經
轉載來于：http://m.newbst.com/article40/pjchho.html

成都網站建設公司_創新互聯，為您提供微信公眾號、服務器托管、網站改版、網頁設計公司、網站內鏈、自適應網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯