Failover konusu çoğu yerde “yedek hat var” diye kapanır. Üretimde ise gerçek sorun şu olur: link up, hatta BGP/OSPF session up… ama trafik bir noktada blackhole olur. Timer’lar dakikalarla ölçülüyorsa, incident süresi de dakikalarla uzar.
Bu yazı; FRR kullanan edge/router sunucularda BFD (Bidirectional Forwarding Detection) ile hızlı sinyal üretme yaklaşımını, operasyonel riskleriyle birlikte anlatır.
BFD neyi çözer?
BFD, “karşı uç gerçekten yaşıyor mu?” sorusunu çok kısa aralıklarla kontrol eder. BGP/OSPF gibi protokoller bu sinyali alıp daha hızlı convergance sağlar.
Tipik kazanım:
- Dakikalar yerine saniyeler (hatta yüzlerce ms) seviyesinde failover
- “link up ama trafik yok” senaryosunda erken tespit
Nerede kullanmalı?
Saha önerisi:
- Edge uplink (kritik çıkışlar)
- Transit router ↔ edge arasındaki kritik peering
- DC omurga (stabil, düşük jitter) ortamları
Kaçın:
- Wi-Fi / yüksek jitter hatlar
- CPU’su zaten sınırda çalışan cihazlar
Ön kontrol: mevcut failover gerçekten ne kadar sürüyor?
Önce baseline al:
- BGP: “session down → route withdraw → trafik geri geldi” süresi
- OSPF: dead interval davranışı
- Uygulama: hata oranı ve latency etkisi
Bu baseline olmadan BFD “hızlı oldu mu?” sorusuna net cevap veremezsin.
FRR tarafı: minimal devreye alma yaklaşımı
FRR’de BFD kullanımında iki prensip önemli:
- BFD session’ı aç (peer + timer’lar)
- Routing protokolüne BFD’yi bağla (BGP neighbor / OSPF interface)
Komut/sözdizimi FRR sürümüne göre değişebilir; ama operasyonel akış değişmez.
Örnek (vtysh ile, temsili):
sudo vtysh -c "show bfd peers" || true
sudo vtysh -c "show ip bgp summary" || trueTimer seçimi: hız–stabilite dengesi
Basit kural:
- DC içi düşük jitter: daha agresif
- İnternet/VPN: daha konservatif
Risk:
- Çok agresif timer → microburst/jitter → BFD down → route flap
Operasyon standardı:
- BFD devreye alındıktan sonra 24–72 saat “flap metriği” takip et
- Flap varsa timer’ı gevşet veya BFD kapsamını daralt
Doğrulama: gerçekten işe yarıyor mu?
Kontrol listesi:
- BFD session state Up mı?
- Protokol, BFD down olduğunda gerçekten route’u withdraw ediyor mu?
- Failover, uygulama metriklerinde gözle görülür iyileşme üretiyor mu?
Pratik test yaklaşımı:
- Uplink’i fiziksel kesmek yerine önce kontrollü traffic blackhole simülasyonu (lab/stage)
- Ardından üretimde “bakım penceresinde” planlı test
Olay Runbook’u: BFD flap veya false positive olursa
- BFD down/up olaylarını logla (timestamp ile)
- CPU ve interface error counter’larını kontrol et
- Timer’ı gevşet (daha uzun interval / higher multiplier)
- Gerekirse BFD’yi sadece kritik peer’larda bırak
Sonuç
BFD, failover’u “protokol timer’ı” seviyesinden “gerçek yaşam sinyali” seviyesine indirir. Değer; en agresif ayarı bulmakta değil, stabiliteyi bozmadan incident süresini düşürmekte ortaya çıkar.