BFD從本質上講是一種高速獨立的Hello協議,目的是在兩個的3層節點之間進行鏈路之間的高速動態檢測,值得注意的是這裏的三層鏈路既能夠是物理三層鏈路(物理直連,物理專線等),因爲現有網絡的速度已經發展的很快,BFD能夠作到毫秒級別的相應,與傳統的檢測方式(如動態協議的Hello包等等)相比經過BFD能夠大大減小網絡的收斂時間,保證網絡能夠告訴動態的在備用鏈路之間進行切換,這樣的好處不言而喻。網絡
BFD技術要點:負載均衡
三層之間的通訊,這裏既能夠指物理直連(專線),也能夠指代邏輯直連(如2層MPLS ***(VPLS),各類隧道技術(IPsec、GRE、DM***)等)ide
本質是一個不可路由的快速Hello包,採用UDP進行封裝。測試
BFD的故障檢測時間遠小於1秒,能夠更快地加速網絡收斂,減小上層應用中斷的時間,提升網絡的可靠性和服務質量。spa
BFD的能夠爲不少上層協議聯動,如各類動態路由協議,靜態路由等等。3d
須要在兩端都要進行配置日誌
因爲靜態路由的實現,比動態路由協議更爲複雜,咱們這裏就利用靜態路由來給你們講解BFDrouter
實驗:blog
情景一:接口
R1和R2之間有兩條鏈路,一條是專線。另一條是虛擬鏈路,是基於Internet的GRE隧道。R1的tunnel0口ip爲10.10.10.1/24,R2的隧道口IP爲10.10.10.2/24。
配置命令:
router(config-if)#bfd interval {50-9999 in milliseconds} min_rx {50-9999 in millicseconds} multiplier {3-50}
router(config)#ip route static bfd {interface type} {Interface number} {gateway address}
router(config)#ip route {network address} {network mask} {interface(which bfd enabled)} {next-hop address}
要求R一、R2的172.16.x.x流量平時走專用鏈路,若是檢測到發生故障那麼須要走GRE隧道。
實驗配置:
R1:
R1(config-if)#int e0/0
R1(config-if)#bfd interval 500 min_rx 500 multiplier 3 #在須要開啓BFD的接口下輸入間隔、最小接收時間、和幾倍的間隔的holddown時間等參數
R1(config)#ip route static bfd e0/0 10.1.1.2 #創建BFD鄰居關係,後面的是對端直連三層地址
R1(config)#int tunnel 0
R1(config-if)#tunnel mode gre ip
R1(config-if)#tunnel source Ethernet0/1
R1(config-if)#tunnel destination 25.1.1.2
R1(config)#ip route 172.16.2.0 255.255.255.0 tunnel 0 10.10.10.2 10 #設置備用GRE隧道的備用靜態路由,修改AD值爲10,使其正常不走這條鏈路。
相似的配置R2
R2:
R2(config-if)#int e0/0
R2(config-if)#bfd interval 500 min_rx 500 multiplier 3
R2(config)#ip route static bfd e0/0 10.1.1.1
R2(config)#int tunnel 0
R2(config-if)#tunnel mode gre ip
R2(config-if)#tunnel source Ethernet0/1
R2(config-if)#tunnel destination 25.1.1.1
R2(config)#ip route 172.16.1.0 255.255.255.0 tunnel 0 10.10.10.1 10
咱們來看一下路由表,經過觀察能夠看到,分別有R1和R2分別有去往對端172.16.x.0/24網絡的靜態路由。
經過show ip static route進一步查看分別能夠看到:經過專線的網絡處於Active狀態,而且有BFD檢測。
如今咱們能夠將兩個交換機中間的某個接口shutdown掉,模擬鏈路故障,幾乎與shutdown接口的同時,R1和R2上跳出了這條日誌信息。顯示BFD檢測失敗,表示專線之間鏈路存在問題
咱們再來查看一下R1和R2的路由表,能夠觀察到原來的專線鏈路中的路由信息已經被轉化成了Non-active狀態,GRE隧道的備用路徑已經開啓。
從R1上ping對端地址172.16.2.1,驗證可達
咱們再來開啓以前shutdown的接口,通過一會的等待時間,R1和R2彈出下面的日誌
再開查看路由發現原有路由恢復正常
經過traceroute發現,的確走了所需路由。
情景2:
在公司Internet網關設備上有多條上行鏈路鏈路從不通的運營商接入時,也能夠利用這個進行切換。
環境說明:
R1做爲公司的出口設備,分別具備兩條互聯網的上行鏈路來自兩個不通的運營商。平時NAT進行負載均衡,當一條鏈路斷掉的時候進行自動切換(這裏的自動切換利用BFD達到)。實驗中咱們利用8.8.8.8測試互聯網的連通性。
實驗中,關於NAT部分已經預配好,這裏不是咱們討論的話題,所以再也不過多的進行描述。後面會專門作一篇文檔講解如何作到雙上行網絡的負載。
配置:
R1
R2(config)int e0/1
R2(config-if)bfd interval 500 min_rx 500 multiplier 3
R2(config-if)int e0/2
R2(config-if)bfd interval 500 min_rx 500 multiplier 3
R2(config-if)ip route static bfd e0/1 12.1.1.1
R2(config)ip route static bfd e0/2 13.1.1.1
R2(config)ip route 0.0.0.0 0.0.0.0 e0/1 12.1.1.1
R2(config)ip route 0.0.0.0 0.0.0.0 e0/2 13.1.1.1
R2
R2(config)int e0/0
R2(config-if)bfd interval 500 min_rx 500 multiplier 3
R2(config)ip route static bfd e0/1 12.1.1.2 unassociate #這裏說明一下unassociate這個參數,在正常狀況下須要有一條靜態路由的關聯到接口上時才能生效,可是有了這個參數就能夠在沒有任何路由的狀況下生效。這裏只作了互聯網鏈接運營商沒法知道也不能知道任何內部的路由,所以須要作這條參數
R3
R3(config)int e0/0
R3(config-if)bfd interval 500 min_rx 500 multiplier 3
R3(config)ip route static bfd e0/1 12.1.1.2 unassociate
這樣就配置好了。在雙上行鏈路沒有故障的時候能夠看到有兩條默認路由指向不一樣的運營商並負載均衡。而且都進行了BFD檢測。
咱們能夠驗證一下,選擇任意一臺user進行測試。 #這裏的user用路由器模擬
經過Traceroute能夠發現,這時用戶走的是ISP1的線路。
咱們去R2上關閉掉這個E0/0接口,模擬線路故障。R1產生這條日誌信息
再次查看路由表發現,因爲BFD檢測失敗,ISP1的默認路由被改成了Non-active
再從用戶的角度去traceroute一下,發現這裏走了運營商2的線路。
固然,若是有須要的話,能夠修改某條上行鏈路的默認路由的AD,作線路熱備,並不必定要負載。
本篇文檔就介紹到這裏,但願能幫助到你。須要實驗拓撲的小夥伴能夠關注一下我,給我私信或者加個人QQ,我能夠將個人實驗環境分享給你。謝謝