Cem Kemal Erbaş Network, Siber Güvenlik ve Teknik Rehberler
Kesinti anında “cihaz ayağa kalktı” demek yetmez. Gerçek HA, kritik akışların oturum (state) ile birlikte hayatta kalması ve routing/komşulukların hızlı normalize olmasıdır. FortiGate tarafında bu işi yapan temel mekanizma FGCP HA + session pickup’tır: primary’nin TCP session table’ı diğer üyelere senkronize edilir ve failover sonrası mümkün olan en az kesinti hedeflenir.
Neden şimdi?
🚦 İş-kritik akışlarda “sıfıra yakın kesinti” beklentisi
🧩 Multi-WAN + dinamik yönlendirme + SD-WAN karmaşası
🛡️ Denetime hazır runbook + ölçülebilir RTO/RPO ihtiyacı
✅ 7 Kritik Nokta (Kısa ama sahada işe yarayan checklist)
1️⃣ 🔁 Session Sync: session-pickup + bağlantısız trafik
- TCP için:
session-pickup enable - UDP/ICMP (VoIP/DNS gibi) için: ayrıca
session-pickup-connectionless enablegerekir; aksi halde FGCP varsayılan olarak UDP/ICMP için session table tutmaz.
Örnek (FGCP – konsept):
config system ha
set session-pickup enable
set session-pickup-connectionless enable
end
Kritik gerçek: Session pickup “ideal koşullarda” çok iyi sonuç verir ama %100 garanti değildir; bazı oturumlar yine de yeniden başlayabilir.
Büyük not (çoğu kişinin atladığı):
- Proxy-based security profile ile taranan oturumlarda stateful failover sınırlı olabilir; dokümanda proxy-based taranan session’lar için failover desteklenmediği, flow-based’te ise failover sonrası inspeksiyonun devam etmeyebileceği belirtiliyor.
- Ayrıca cluster tarafından terminate edilen oturumlar (ör. bazı management, explicit proxy, IPsec/SSL VPN terminate senaryoları vb.) genelde stateful olarak failover olmaz; yeniden kurulumu planlayın.
2️⃣ 🧷 Heartbeat: iki bağımsız hat + izolasyon + split-brain hijyeni
Heartbeat trafiği L2 frame olarak akar; varsayılan heartbeat aralığı 200 ms’tir. En iyi pratik: heartbeat’i kullanıcı ağlarından izole edin; 2 üye varsa back-to-back bağlamak önerilir.
Ek olarak Fortinet, en az iki heartbeat interface tanımlayıp farklı öncelik vermeyi ve mümkünse patch-kablo ile direkt bağlantıyı önerir.
Split-brain riskini azaltmanın “temeli”: izole heartbeat + doğru monitor + tutarlı override/priority.
3️⃣ 🧲 Gratuitous ARP: L2 komşular hızlı güncellensin
Failover sonrası yeni master, switch’in MAC tablolarını güncellemek için Gratuitous ARP (GARP) kullanır; Fortinet bunu packet capture ile gösteriyor.
HA’da gratuitous-arps ayarı bulunur.
GARP yetmiyorsa (bazı switch/ortamlar):
link-failed-signalveyabounce-intf-upon-failoverile failover’da interface’leri kısa süre “down/up” yaptırıp komşu tablolarını zorla tazeletebilirsiniz.
4️⃣ 🧪 Port/Link Monitoring: “brownout” da tetiklesin, “flap” da SOC’u yakmasın
Monitored interface down olduğunda failover tetiklenir.
Best practice:
- Heartbeat interface’i monitor etmeyin
- Cluster tam oturmadan monitor eklemeyin
- Her interface’i değil, kritik interface’leri izleyin
Ayrıca Fortinet, WAN tarafındaki ISP flap’lerinin HA’yı “zıplatabileceğini” ve bu yüzden WAN monitor seçimini dikkatli yapmayı vurguluyor.
5️⃣ 🧭 Dinamik Routing: “cihaz ayakta” yetmez, routing de ayakta olmalı
HA failover’da routing daemon (ör. BGP) yeni primary’de yeniden ayağa kalkar; peer tarafı route’ları silebilirse trafik kesilir. Fortinet’in BGP graceful-restart tip’i bunu doğrudan hedefliyor.
FGCP’nin BFD-enabled BGP graceful restart desteklediği ve failover sonrası BGP’nin yeni primary’de komşulara bağlanmak için kısa bir auto-start süresi beklediği dokümante edilmiş.
Pratik hedef KPI: “BGP/OSPF komşulukları kaç saniyede normalize oluyor?”
6️⃣ ⚖️ Override / Preempt: “stabilite mi, geri dönüş mü?”
Override davranışı primary seçim mantığını etkiler. Fortinet, override ayarının tüm cluster üyelerinde tutarlı (hepsinde açık/hepsinde kapalı) olmasını “strongly recommended” olarak yazar; karışık konfigürasyonlar öngörülemez seçimlere yol açabilir.
Saha kuralı:
- Stabilite öncelikse: gereksiz preempt/geri alma tetiklemeyin
- Operasyon “primary hep şu cihaz olsun” diyorsa: override + priority’yi disiplinle yönetin (ve her iki node’da aynı).
7️⃣ 🧱 A-P vs A-A vs VDOM Virtual Clustering: trafik profiline göre seç
- A-P: en basit, en öngörülebilir; state sync planlaması daha kolay
- A-A: load-balancing ile throughput avantajı olabilir ama operasyonel karmaşıklık artar (özellikle inspection modları / session davranışları)
- VDOM virtual clustering: Multi-VDOM’da bazı VDOM’ları bir node’a, diğerlerini öbür node’a “partition” ederek throughput’u artırabilir; failover’da normal HA gibi tek node’a düşer.
🧪 Gerçek Senaryo – Canlı Test Paketi (denetim için de altın)
🌐 TCP: Büyük download kesintisiz devam ediyor mu? (session pickup etkisi)
🎙️ SIP/RTP: UDP oturumları düşüyor mu? (connectionless pickup şart)
🔒 IPsec/SSL VPN: Tüneller otomatik toparlıyor mu? (stateful bekleme; rekey/yeniden kurulum planla)
🚚 BGP/OSPF: Komşuluk kaç sn’de geri geliyor? (graceful restart/BFD)
🧲 L2: GARP sonrası switch MAC tabloları güncelleniyor mu?
⚡ 48s Mini-Sprint (Hemen başla)
- ✅
session-pickupaçık mı? UDP/ICMP gerekiyorsasession-pickup-connectionlessaçık mı? - ✅ Heartbeat: en az 2 interface, izole, mümkünse back-to-back/dedicated switch?
- ✅ Monitor listesi: sadece kritik interface’ler, hbdev hariç?
- 🧪 Brownout simülasyonu: uplink loss/jitter ile failover tetikle
- 📈 Metrikler: failover süresi, oturum yaşama oranı, SIP drop %, BGP normalize süresi, GARP etkisi
- 📘 Çıktı: HA Runbook + rollback adımları (denetimde direkt değer)
Cem Kemal Erbaş sitesinden daha fazla şey keşfedin
Subscribe to get the latest posts sent to your email.
