Planlı bakımın en pahalı hali şudur: “bakım var, route düşecek, kesinti bekleyin.” Bu, çoğu kurumda alışkanlıktır ama teknik olarak her zaman zorunlu değildir. BGP Graceful Restart (GR) doğru tasarlanırsa, kontrol düzlemi yeniden başlarken data plane bir süre daha taşımaya devam edebilir ve kesinti etkisi ciddi azalır.
Bu yazı; GR’yi “feature açtık” seviyesinde değil, operasyonel bir bakım disiplini olarak ele alır.
GR ne yapar, ne yapmaz?
GR’nin vaadi:
- Routing daemon/CPU restart olurken, komşu cihazlar route’ları hemen silmek yerine kısa süre stale olarak tutar.
- Bu sırada forwarding plane (FIB) trafikleri taşımaya devam edebilir.
GR’nin yapmadığı:
- Data plane zaten bozuksa (ASIC/linecard/port) GR seni kurtarmaz.
- Yanlış yerde açılırsa, bozuk route’ları “yaşıyor gibi” tutarak blackhole süresini uzatır.
Nerede anlamlı?
GR, özellikle şu tip geçişlerde etkilidir:
- BGP süreç restart / upgrade
- Konfig değişiklikleri (policy/route-map) sonrası kısa restart ihtiyacı
- Control plane failover (redundant supervisor) senaryoları
Operasyonel tasarım: GR tek başına yetmez
Saha prensibi:
- GR: kontrol düzlemi restart penceresini yumuşatır
- BFD / hızlı failure sinyali: gerçek arızada hızlı withdraw sağlar
- Maintenance mode: trafiği kontrollü boşaltır (drain/weight düşürme)
Bu üçlü yoksa, GR bir süre sonra “blackhole uzatıcı” olur.
Planlı bakım runbook’u (saha akışı)
1) Bakım öncesi: risk çerçevesi
Yazılı cevaplar:
- Bakımda “worst case” nedir? (kesinti süresi, etkilenen servis)
- Geri dönüş planı nedir? (rollback)
- Kim karar veriyor? (Incident Commander / NetOps lead)
2) Trafik boşaltma (varsa)
Bakım öncesi ideal hareket:
- egress/edge weight azalt
- ECMP’de ilgili next-hop’u kademeli çıkar
- health-check tabanlı yönlendirmede bakımdaki node’u pasife al
3) Doğrulama: GR gerçekten devrede mi?
Kontrol listesi:
- Komşu cihazlarla GR capability müzakere edildi mi?
- Restart-time / stale-time değerleri mantıklı mı?
- “Stale route” durumu görünür mü? (vendor/stack’e göre)
4) Bakım anı
- Change kaydı aç (komutlar, saat, kim)
- Sadece hedef cihaz/proses üzerinde işlem yap
- Eş zamanlı iki kritik değişiklik yapma (ör. hem GR ayarı hem policy revizyonu)
5) Bakım sonrası doğrulama
İki boyut:
- Routing: neighbor up, route sayıları, flap var mı?
- Hizmet: latency/hata oranı, edge saturation, müşteri sinyali
6) Geri dönüş standardı
Bakım bittiğinde:
- Trafiği kademeli geri al
- “stale/GR window” süresini raporla
- Beklenmeyen flap/blackhole olduysa postmortem’e yaz
En sık hata: GR ile “sessiz blackhole”
GR’nin en tehlikeli tarafı, gerçek arızada route’un bir süre daha tutulmasıdır. Bu yüzden:
- GR’yi sadece planlı bakım senaryosuna bağla
- Gerçek failure sinyalini BFD/physical link ile hızlı üret
- Bakım modunu trafikten izole et
Sonuç
Graceful Restart, doğru çerçevede kullanıldığında planlı bakımı kesintisiz hale yaklaştırır. Ancak “feature açtım” seviyesinde bırakılırsa, sadece incident sürelerini uzatan bir risk katmanına dönüşür. GR’yi; bakım runbook’u, süre standardı ve doğrulama adımlarıyla birlikte yönettiğinde gerçek değer ortaya çıkar.