有些日子沒過來寫文章，一是最近在研究阿里雲（ACP）等組網以及考試，而是也發現沒有什麼特別實用的技術在blog中去分享。不出意料的在上週通過了ACP的考試，發現雲計算中又出現了一些的組網應用，雖然在阿里雲和目前很多公司的雲平臺操作的時候，很難感覺到網絡的存在，都是自己點一點就好了。。但如果在使用的過程只是這麼簡單以爲的話，這是會出大問題的。
比如從網絡的容災的概念中，你雖然在各大雲平臺得到了網絡配置的最大簡化體驗，此時網絡工程的重心就會輻射到容災、安全、流量切換等等。這些作爲但凡作爲一個運維都要考慮，而且要花大量的精力去做這件事情。
今天寫文章不是聊雲化的趨勢和帶來的改變等等，今天仍然是介紹一次真正案例中我們利用GRE、IPSEC、BFD解決冗餘組網和自動切換的問題。且具有強大的“萬精油”屬性，在任何組網的案例下，都會有這樣的需求，而且使用的都是標準協議，所以可以負責任的講，如果企業沒有強大的資本支撐IT的業務擴展時對高可靠的要求時，今天的這一篇文章就非常值得大家讀一讀裏面的思想。時間匆忙，簡單的畫了一個示意圖，如下所示：
以上部分是簡化過的拓撲，一是爲了保護原案例的相關信息，二是助於大家去理解。
項目案例需求背景：
需要部署災備數據中心，兩個數據中心內網通過專線打通（我這裏使用GRE做的測試，因爲GRE在功能實現上就相當於物理專線MSTP，所以這個做完了，相當於專線也講了一遍）
雙數據中心無需做到同城雙活，僅僅是在主數據中心上聯出口完全中斷，且恢復時間不可控時，我們把業務完全切換到災備數據中心
需要保證兩地之間通信除了專線物理線路，另外還要存在一條備份冗餘鏈路，並可實現完全無縫自動切換
PS:需求我也做了省略很簡化，關於DNSPOD、業務側的切換、集羣業務等等這裏都不做過多的贅述，不然文章寫不完了都，以後會慢慢補上
項目案例背景：
出口設備爲：山石網科T級產品線（很高端設備）
交換機華爲6700萬兆
服務器上百臺
存儲、光交
內網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：
人生格言：越努力、越幸運