Tweet
BFD – Phát hiện sự cố Layer 3 tốc độ cao
Trong thiết kế Fast Convergence, một trong những vấn đề lớn là routing protocol thường phát hiện failure dựa trên timer của chính nó. Nếu giảm Hello/Hold/Dead timer quá thấp, control plane phải xử lý nhiều packet hơn và mạng có thể trở nên nhạy cảm với các sự cố thoáng qua.
BFD – Bidirectional Forwarding Detection giải quyết bài toán này bằng cách tách chức năng phát hiện failure khỏi routing protocol.
Thay vì để OSPF, EIGRP, IS-IS hay BGP tự phát hiện lỗi, chúng ta có thể để BFD làm việc đó rồi thông báo kết quả cho routing protocol.
BFD detects failure
↓
OSPF / EIGRP / IS-IS / BGP
↓
Neighbor/session removed
↓
Route recalculation
↓
Fast Convergence Tại sao BFD tốt hơn aggressive protocol timers?
Slide nhấn mạnh BFD được strongly recommended over aggressive protocol timers vì ba ưu điểm chính.
Reduced control-plane load and link bandwidth usage: thay vì mỗi routing protocol phải chạy timer cực thấp riêng, nhiều protocol có thể tận dụng chung cơ chế BFD để phát hiện lỗi.
Sub-second failure detection: BFD được thiết kế để phát hiện lỗi ở mức dưới một giây, thậm chí nhanh hơn tùy platform, timer và khả năng xử lý.
In-flight timer negotiation: hai BFD peer có thể trao đổi các giá trị timer và xác định tốc độ gửi/nhận phù hợp với khả năng của hai bên.
Điểm cần nhớ:
BFD Operation Modes – BFD hoạt động như thế nào?
BFD session được thiết lập thông qua asynchronous control packets.
Hai thiết bị gửi BFD Control packet cho nhau để xác nhận khả năng bidirectional forwarding.
Slide mô tả hai cách hoạt động chính. 1. Asynchronous Mode – Không sử dụng Echo
Trong chế độ cơ bản:
R1 R2
| ---- BFD Control ----> |
| <--- BFD Control ----- |
| ---- BFD Control ----> |
| <--- BFD Control ----- |
Hai router độc lập gửi BFD Control packet theo tốc độ đã thương lượng.
Mỗi router về cơ bản đang nói với router kia:
"I'm alive."
Nếu không nhận được BFD packet trong khoảng thời gian:
Detection Time ≈ Interval × Multiplier
peer sẽ được xem là Down.
Ví dụ nếu negotiated receive interval là 100 ms và multiplier bằng 3, về nguyên tắc failure có thể được phát hiện sau khoảng:
100 ms × 3 = 300 ms
Sau đó BFD thông báo cho routing protocol liên quan để quá trình convergence bắt đầu.
2. Asynchronous Mode + Echo
Nếu hai bên hỗ trợ và thương lượng BFD Echo, cách phát hiện failure có thể được tối ưu hơn.
Lúc này có hai loại traffic:
BFD Control packets → gửi với tốc độ chậm hơn
BFD Echo packets → dùng để kiểm tra forwarding path
Điểm thú vị của Echo Mode là packet được gửi sang neighbor rồi được loop/forward trở lại chính thiết bị gửi.
Có thể hình dung:
Echo
R1 -----------------> R2
^ |
|_____________________|
returned
R1 gửi Echo packet qua R2 và chờ packet quay trở lại. Nhờ đó R1 có thể kiểm tra trực tiếp forwarding path.
Khi Echo được sử dụng, BFD Control packet không nhất thiết phải gửi với tần suất cao như trước, giúp giảm phần processing liên quan đến control packets.
Control Packet và Echo Packet khác nhau ở đâu?
Đây là điểm dễ nhầm khi học BFD.
Với Asynchronous Mode, hai router kiểm tra nhau:
R1 → "R1 alive" → R2
R2 → "R2 alive" → R1
Còn với Echo, router kiểm tra forwarding path bằng packet quay về chính nó:
R1 → Echo → R2 → R1
R2 → Echo → R1 → R2
Vì vậy hình thứ hai có nhiều đường packet hơn hình đầu tiên.
Tư duy troubleshooting BFD
Khi triển khai BFD, đừng chỉ hỏi:
Hãy tách thành hai câu hỏi:
BFD Session
↓
Forwarding path alive?
↓
Routing Protocol
↓
Neighbor/session alive?
Ví dụ OSPF Dead Timer là hàng chục giây nhưng BFD phát hiện failure trong vài trăm millisecond:
Link/forwarding failure
↓
BFD detects ~300 ms
↓
Notify OSPF
↓
OSPF adjacency down
↓
SPF / RIB / FIB update
↓
Traffic moves to alternate path
Đó chính là giá trị lớn nhất của BFD:
Trong các mạng Enterprise Core, Data Center và Service Provider yêu cầu High Availability + Fast Convergence, BFD vì vậy thường được kết hợp với OSPF, IS-IS, EIGRP, BGP, MPLS và các cơ chế redundancy khác, thay vì đơn giản giảm mạnh timer của từng protocol.
Trong thiết kế Fast Convergence, một trong những vấn đề lớn là routing protocol thường phát hiện failure dựa trên timer của chính nó. Nếu giảm Hello/Hold/Dead timer quá thấp, control plane phải xử lý nhiều packet hơn và mạng có thể trở nên nhạy cảm với các sự cố thoáng qua.
BFD – Bidirectional Forwarding Detection giải quyết bài toán này bằng cách tách chức năng phát hiện failure khỏi routing protocol.
Thay vì để OSPF, EIGRP, IS-IS hay BGP tự phát hiện lỗi, chúng ta có thể để BFD làm việc đó rồi thông báo kết quả cho routing protocol.
BFD detects failure
↓
OSPF / EIGRP / IS-IS / BGP
↓
Neighbor/session removed
↓
Route recalculation
↓
Fast Convergence Tại sao BFD tốt hơn aggressive protocol timers?
Slide nhấn mạnh BFD được strongly recommended over aggressive protocol timers vì ba ưu điểm chính.
Reduced control-plane load and link bandwidth usage: thay vì mỗi routing protocol phải chạy timer cực thấp riêng, nhiều protocol có thể tận dụng chung cơ chế BFD để phát hiện lỗi.
Sub-second failure detection: BFD được thiết kế để phát hiện lỗi ở mức dưới một giây, thậm chí nhanh hơn tùy platform, timer và khả năng xử lý.
In-flight timer negotiation: hai BFD peer có thể trao đổi các giá trị timer và xác định tốc độ gửi/nhận phù hợp với khả năng của hai bên.
Điểm cần nhớ:
BFD không tìm best path và cũng không chạy SPF. BFD chỉ trả lời rất nhanh câu hỏi: đường forwarding giữa hai endpoint còn sống hay đã chết?
BFD Operation Modes – BFD hoạt động như thế nào?
BFD session được thiết lập thông qua asynchronous control packets.
Hai thiết bị gửi BFD Control packet cho nhau để xác nhận khả năng bidirectional forwarding.
Slide mô tả hai cách hoạt động chính. 1. Asynchronous Mode – Không sử dụng Echo
Trong chế độ cơ bản:
R1 R2
| ---- BFD Control ----> |
| <--- BFD Control ----- |
| ---- BFD Control ----> |
| <--- BFD Control ----- |
Hai router độc lập gửi BFD Control packet theo tốc độ đã thương lượng.
Mỗi router về cơ bản đang nói với router kia:
"I'm alive."
Nếu không nhận được BFD packet trong khoảng thời gian:
Detection Time ≈ Interval × Multiplier
peer sẽ được xem là Down.
Ví dụ nếu negotiated receive interval là 100 ms và multiplier bằng 3, về nguyên tắc failure có thể được phát hiện sau khoảng:
100 ms × 3 = 300 ms
Sau đó BFD thông báo cho routing protocol liên quan để quá trình convergence bắt đầu.
2. Asynchronous Mode + Echo
Nếu hai bên hỗ trợ và thương lượng BFD Echo, cách phát hiện failure có thể được tối ưu hơn.
Lúc này có hai loại traffic:
BFD Control packets → gửi với tốc độ chậm hơn
BFD Echo packets → dùng để kiểm tra forwarding path
Điểm thú vị của Echo Mode là packet được gửi sang neighbor rồi được loop/forward trở lại chính thiết bị gửi.
Có thể hình dung:
Echo
R1 -----------------> R2
^ |
|_____________________|
returned
R1 gửi Echo packet qua R2 và chờ packet quay trở lại. Nhờ đó R1 có thể kiểm tra trực tiếp forwarding path.
Khi Echo được sử dụng, BFD Control packet không nhất thiết phải gửi với tần suất cao như trước, giúp giảm phần processing liên quan đến control packets.
Control Packet và Echo Packet khác nhau ở đâu?
Đây là điểm dễ nhầm khi học BFD.
Với Asynchronous Mode, hai router kiểm tra nhau:
R1 → "R1 alive" → R2
R2 → "R2 alive" → R1
Còn với Echo, router kiểm tra forwarding path bằng packet quay về chính nó:
R1 → Echo → R2 → R1
R2 → Echo → R1 → R2
Vì vậy hình thứ hai có nhiều đường packet hơn hình đầu tiên.
Tư duy troubleshooting BFD
Khi triển khai BFD, đừng chỉ hỏi:
"OSPF neighbor có Full không?"
Hãy tách thành hai câu hỏi:
BFD Session
↓
Forwarding path alive?
↓
Routing Protocol
↓
Neighbor/session alive?
Ví dụ OSPF Dead Timer là hàng chục giây nhưng BFD phát hiện failure trong vài trăm millisecond:
Link/forwarding failure
↓
BFD detects ~300 ms
↓
Notify OSPF
↓
OSPF adjacency down
↓
SPF / RIB / FIB update
↓
Traffic moves to alternate path
Đó chính là giá trị lớn nhất của BFD:
Routing protocol lo chuyện tìm đường. BFD chuyên lo phát hiện đường forwarding bị chết càng nhanh càng tốt.
Trong các mạng Enterprise Core, Data Center và Service Provider yêu cầu High Availability + Fast Convergence, BFD vì vậy thường được kết hợp với OSPF, IS-IS, EIGRP, BGP, MPLS và các cơ chế redundancy khác, thay vì đơn giản giảm mạnh timer của từng protocol.
Attached Files