- 產品與解決方案
- 行業解決方案
- 服務
- 支持
- 合作夥伴
- BOB登陆 人才研學中心
- 關於我們
關鍵詞：BFD
摘 要：BFD是用來實現快速故障檢測的標準協議。本文對BFD技術實現和典型組網應用進行介紹。
縮略語：
字段 | 英文全名 | 中文解釋 |
BFD | Bidirectional Forwarding Detection | 雙向轉發檢測 |
UDP | User Datagram Protocol | 用戶數據報協議 |
目 錄
為了保護關鍵應用，網絡中會設計有一定的冗餘備份鏈路，網絡發生故障時就要求網絡設備能夠快速檢測出故障並將流量切換至備份鏈路以加快網絡收斂速度。目前有些鏈路（如POS）通過硬件檢測機製來實現快速故障檢測。但是某些鏈路（如以太網鏈路）不具備這樣的檢測機製。此時，應用就要依靠上層協議自身的機製來進行故障檢測，上層協議的檢測時間都在1秒以上，這樣的故障檢測時間對某些應用來說是不能容忍的。某些路由協議如OSPF、IS-IS雖然有Fast Hello功能來加快檢測速度，但是檢測時間也隻能達到1秒的精度，而且Fast Hello功能隻是針對本協議的，無法為其它協議提供快速故障檢測。
BFD協議就是在這種背景下產生的，提供了一個通用的標準化的介質無關和協議無關的快速故障檢測機製。具有以下優點：
l 對網絡設備間任意類型的雙向轉發路徑進行故障檢測，包括直連物理鏈路、虛電路、隧道、MPLS LSP、多跳路由路徑以及單向鏈路等。
l 可以為不同的上層應用服務，提供一致的快速故障檢測時間。
l 提供小於1秒的檢測時間，從而加快網絡收斂速度，減少應用中斷時間，提高網絡的可靠性。
BFD在兩台網絡設備上建立會話，用來檢測網絡設備間的雙向轉發路徑，為上層應用服務。BFD本身並沒有鄰居發現機製，而是靠被服務的上層應用通知其鄰居信息以建立會話。會話建立後會周期性地快速發送BFD報文，如果在檢測時間內沒有收到BFD報文則認為該雙向轉發路徑發生了故障，通知被服務的上層應用進行相應的處理。下麵以OSPF與BFD聯動為例，簡單介紹會話工作流程。
圖1 BFD會話建立流程圖
(1) OSPF通過自己的Hello機製發現鄰居並建立連接；
(2) OSPF在建立了新的鄰居關係後，將鄰居信息（包括目的地址和源地址等）通告給BFD；
(3) BFD根據收到的鄰居信息建立會話。
圖2 BFD故障發現處理流程圖
(1) 被檢測鏈路出現故障；
(2) BFD檢測到鏈路故障，拆除BFD鄰居會話；
(3) BFD通知本地OSPF進程BFD鄰居不可達；
(4) 本地OSPF進程中斷OSPF鄰居關係
BFD有兩種操作模式：異步模式和查詢模式。目前Comware隻支持異步模式。在此模式下，會話兩端周期性地發送BFD控製報文，根據是否能收到對端的BFD控製報文來檢測會話狀態。
另外，Comware還支持回聲功能。回聲功能啟動後，會話的一端周期性地發送BFD Echo報文，對端不對此報文進行處理，而隻將此報文轉發回發送端。根據發送端是否能收到BFD Echo報文來檢測會話狀態。
BFD會話的兩端可能是在直連網段（即IP報文的一跳），也可能是在不同網段。回聲功能隻可以檢測直連網段故障，即BFD Echo報文是單跳發送；而BFD控製報文可以檢測直連網段和非直連網段的故障，即BFD控製報文可以是單跳或多跳發送。
BFD控製報文包括強製部分和可選認證部分。
強製部分格式如圖3：
圖3 BFD控製報文
可選認證部分格式如圖4：
圖4 BFD控製報文（認證部分）
BFD控製報文各字段含義如表1：
表1 BFD控製報文各字段含義
字段 | 含義 |
Vers | BFD協議版本號，目前版本號為1 |
Diag | 診斷碼，表明發送方最近一次會話Down的原因 |
Sta | 發送方BFD會話當前狀態，取值為：0代表AdminDown，1代表Down，2代表Init，3代表Up |
P | 會話參數變化時置位 |
F | 如果收到的BFD控製報文P字段置位，則將下一個發送的BFD控製報文的F字段置位作為應答 |
C | 該字段置位表明BFD的實現是獨立於控製平麵的 |
A | 該字段置位表明報文包含認證部分，會話需要進行認證 |
D | 該字段置位表明發送方希望以查詢模式運行，不置位表明不希望以查詢模式運行或不支持查詢模式 |
R | 保留位，發送時設為0，接收時忽略該字段 |
Detect Mult | 檢測時間倍數 |
Length | BFD控製報文長度，單位為字節 |
My Discriminator | 發送方產生的一個較少非0值，用來標識不同的BFD會話 |
Your Discriminator | 如果已經收到會話鄰居發送的BFD控製報文則該值為收到報文中的My Discriminator，否則為0 |
Desired Min TX Interval | 發送方支持的最小BFD控製報文發送時間間隔，單位為微秒。 |
Required Min RX Interval | 發送方支持的最小BFD控製報文接收時間間隔，單位為微秒 |
Required Min Echo RX Interval | 發送方支持的最小BFD Echo報文接收時間間隔，單位為微秒。為0表示不支持BFD Echo報文 |
Auth Type | 認證類型 |
Auth Len | 可選認證部分長度，包括Auth Type和Auth Len字段，單位為字節 |
BFD控製報文采用UDP封裝，目的端口號為3784，源端口號在49152到65535的範圍內。
BFD Echo報文提供了一種不依賴於BFD控製報文的故障檢測方法。本端發送本端接收，遠端不對報文進行處理，而隻是將此報文在反向通道上返回。因此BFD協議並沒有對BFD Echo報文的格式進行定義，較少的要求是發送方能夠通過報文內容區分會話。
BFD Echo報文采用UDP封裝，目的端口號為3785，目的IP地址為發送接口的地址，源IP地址由配置產生（配置的源IP地址要避免產生ICMP重定向）。
& 說明：
下麵僅介紹通過發送控製報文來建立會話並進行故障檢測的過程。
BFD會話建立前有主動與被動兩種模式。如果一台設備為主動模式，那麼在會話建立前不管有沒有收到對端發來的BFD控製報文，都會主動發送BFD控製報文。如果一台設備為被動模式，那麼在會話建立前就不會主動發送BFD控製報文，直到收到對端發來的BFD控製報文才發送。
要建立BFD會話的兩端中至少要有一端為主動模式才能成功建立起會話。下麵對兩端都為主動模式的會話建立過程進行說明，一端主動模式一端被動模式的會話建立過程基本相同。
圖5 BFD會話連接建立
BFD使用三路握手的機製來建立會話，發送方在發送BFD控製報文時會在Sta字段填入本地當前的會話狀態，接收方根據收到的BFD控製報文的Sta字段以及本地當前會話狀態來進行狀態機的遷移，建立會話。
l Router A和Router B的BFD收到上層應用的通知後，發送狀態為DOWN的BFD控製報文。Router B的BFD狀態變化同Router A。
l Router B收到對端狀態為DOWN的BFD控製報文後，本地會話狀態由DOWN遷移到INIT，隨後發送的BFD控製報文中將Sta字段填為2表明會話狀態為INIT。Router A的BFD狀態變化同Router B。
l Router A收到對端狀態為INIT的BFD控製報文後，本地會話狀態由INIT遷移到UP，隨後發送的BFD控製報文中將Sta字段填為3表明會話狀態為UP。Router B的BFD狀態變化同Router A。
l BFD雙方狀態都為UP，會話成功建立並開始檢測鏈路狀態。
BFD會話建立前BFD控製報文以1秒的時間間隔周期發送以減小報文流量。在會話建立後則以協商的時間間隔發送BFD控製報文以實現快速檢測。在BFD會話建立的同時，BFD控製報文發送時間間隔以及檢測時間也會通過報文交互協商確定。在BFD會話有效期間，這些定時器可以隨時協商修改而不影響會話狀態。BFD會話不同方向的定時器協商是分別獨立進行的，雙向定時器時間可以不同。
BFD控製報文發送時間間隔為本端Desired Min TX Interval與對端Required Min RX Interval之中的最大值，也就是說比較慢的一方決定了發送頻率。
檢測時間為對端BFD控製報文中的Detect Mult乘以經過協商的對端BFD控製報文發送時間間隔。
如果加大本端Desired Min TX Interval，那麼本端實際發送BFD控製報文的時間間隔必須要等收到對端F字段置位的報文後才能改變，這是為了確保在本端加大BFD控製報文發送時間間隔前對端已經加大了檢測時間，否則可能導致對端檢測定時器錯誤超時。
如果減小本端Required Min RX Interval，那麼本端檢測時間必須要等收到對端F字段置位的報文後才能改變，這是為了確保在本端減小檢測時間前對端已經減小了BFD控製報文發送間隔時間，否則可能導致本端檢測定時器錯誤超時。
然而如果減小Desired Min TX Interval，本端BFD控製報文發送時間間隔將會立即減小；加大Required Min RX Interval，本端檢測時間將會立即加大。
下麵詳細介紹參數改變後定時器的協商過程：
圖6 BFD檢測時間協商
Router A與Router B建立BFD會話，雙方的Desired Min TX Interval和Required Min RX Interval（下麵簡稱為TX和RX）都為100ms，Detect Mult都為3。根據定時器協商規則，Router A的發送時間間隔為Router A的TX與Router B的RX中的最大值也就是100ms，Router B的發送時間間隔也是100ms，雙方的檢測超時時間都為300ms。
如果此時將Router A的TX和RX加大到150 ms。
(1) Router A比較本端的RX（150ms）和Router B的TX（100ms），從而將本端檢測時間改為450ms。同時向對端發送P字段置位的BFD控製報文（TX和RX均為150ms）。
(2) Router B收到報文後，給Router A回複F字段置位的BFD控製報文（TX和RX均為100ms）。同時將收到報文中的RX與本端的TX進行比較，由於TX較大，故Router B的發送間隔改為150ms。經過比較本端RX和對端的TX，從而將檢測時間也增大到450ms。
(3) Router A收到對端發來F字段置位的控製報文。根據報文中的RX與本端的TX進行比較計算出新的時間間隔為150ms。
(4) 定時器協商完成，雙方的發送間隔和檢測時間分別為150ms和450ms。
BFD會話建立及定時器協商完成後，兩端會以協商後的間隔發送BFD控製報文。每當收到BFD控製報文時，就會重置檢測時間定時器，保持會話UP狀態。如果在檢測時間內沒有收到BFD控製報文，BFD會話會遷移到DOWN狀態，並通知該會話所服務的上層應用發生故障，由上層應用采取相應的措施。本端BFD會話DOWN後，發給對端的BFD控製報文中的Sta字段就填為1，通知對端會話DOWN，對端的BFD會話也遷移到DOWN狀態。
圖7 路由協議與BFD聯動組網圖
兩台路由器Router A、Router B通過二層交換機互連，在設備上運行路由協議，網絡層相互可達。
由於通過二層交換機相連，Router A與Router B之間的鏈路故障可能不會導致接口DOWN，隻能通過協議握手去檢測。通過在Router A與Router B之間使用BFD就能快速檢測出故障，路由協議得到BFD通知後可以盡快計算新的路由，從而縮短收斂時間。
圖8 快速重路由與BFD聯動典型組網圖
隨著網絡的快速發展，IP網絡越來越多的承載語音、視頻等多種業務，這些業務對網絡的高可靠性提出了更高的要求，從而運營商網絡要求更快的收斂速度。
BFD應用於路由協議以及路由協議快速收斂技術的使用雖然很大程度提高了收斂速度，但還是無法滿足語音、視頻等新業務對業務中斷時間的要求。
而快速重路由和BFD聯動技術可以很好的滿足這種要求，通過提前計算備用路徑，快速發現主用路徑故障，並在主用路徑故障時不依賴於控製平麵的收斂而直接在轉發平麵切換至備用路徑，極大的縮短了業務中斷時間。
圖9 VRRP與BFD聯動典型組網圖
VRRP的協議關鍵點是當Master出現故障時，Backup能夠快速接替Master的轉發工作，保證用戶數據流的中斷時間盡量短。當Master出現故障時，VRRP依靠Backup設置的超時時間來判斷是否應該搶占，切換速度在1秒以上。將BFD應用於Backup對Master的檢測，可以實現對Master故障的快速檢測，縮短用戶流量中斷時間。
VRRP還會監視Master的上行鏈路能否正常工作，Master即使正常工作，但是如果其上行鏈路出現了故障，用戶報文實際上也是無法正常轉發的。VRRP是依靠監視接口狀態來判斷上行鏈路是否正常工作的，當被監視的接口DOWN掉時，Master主動降低優先級，引起切換。這種監視接口的處理方式依賴於接口的協議狀態，如果上行鏈路出現故障而接口不DOWN則無法感知到。將BFD應用於VRRP上行鏈路的檢測可以有效解決問題。
l Katz D., Ward D., "Bidirectional Forwarding Detection”, draft-ietf-bfd-base-05.
l Katz D., Ward D., "Generic Application of BFD”, draft-ietf-bfd-generic-02.
l Katz D., Ward D., "BFD for IPv4 and IPv6 (Single Hop)”, draft-ietf-bfd-v4v6-1hop-05.
l Katz D., Ward D., "BFD for Multihop Paths”, draft-ietf-bfd-multihop-03.
Copyright ©2008 杭州華三通信技術有限公司 版權所有，保留一切權利。
非經本公司書麵許可，任何單位和個人不得擅自摘抄、複製本文檔內容的部分或全部，並不得以任何形式傳播。
本文檔中的信息可能變動,恕不另行通知。
售前谘詢
售後谘詢
人工在線谘詢
