SD-WAN projelerinde en hızlı yanlış güven şudur: “2 hat var, SD-WAN zaten akıllı, otomatik geçer.” Üretimde ise problem genelde hat down değildir; hat “up” görünür ama latency/jitter/loss bozulur, uygulama kırılır ve ekipler “ISP mi, overlay mi, iç ağ mı?” diye saatler kaybeder.
Bu yazı; SD-WAN’da yol seçiminde SLA probe yaklaşımını nasıl kurguladığımı ve incident anında triage’ı nasıl hızlandırdığımı anlatır.
SLA probe neyi çözer?
SLA probe; belirli hedeflere düzenli küçük paketlerle ölçüm yaparak şunları üretir:
- RTT / latency (p50/p95)
- jitter (özellikle ses/video için kritik)
- packet loss (kırılma eşikleri uygulamaya göre değişir)
Bu sayede “default route” değil; uygulama sınıfı için en iyi yol seçilir.
İlk karar: Probe hedefleri (yanlış hedef = yanlış karar)
Probe hedeflerini “internet” diye tek bir IP’ye bağlamayın. İki katman hedef seçin:
- Underlay hedefleri (ISP içi / edge router): hat kalitesini ölçmek için
- Overlay hedefleri (hub, DC, cloud edge): gerçek servis yolunu ölçmek için
Örnek hedef seti:
- Şube → SD-WAN hub (overlay)
- Şube → DC edge (overlay)
- Şube → cloud region edge (overlay)
- Şube → ISP gateway (underlay)
Uygulama sınıfları: Tek SLA eşik seti kullanmayın
Çok görülen hata: tüm trafiğe aynı eşikler.
Örnek (kurumsal pratik):
- Voice/Video: jitter ve loss hassas (küçük bozulma bile etkiler)
- ERP/Interactive: latency hassas
- Bulk/Backup: loss toleranslı ama throughput önemli
Bu nedenle “application policy” şu bileşenleri içermeli:
- DSCP sınıfı
- SLA eşikleri (latency/jitter/loss)
- Failover davranışı (hızlı geçiş mi, sticky mi?)
- Geri dönüş davranışı (flap önleyici hysteresis)
Flap yönetimi: Hysteresis ve hold-down şart
SLA bozulup düzelirken yol seçim motoru “ping-pong” yaparsa, kullanıcı bunu “internet gidip geliyor” diye yaşar.
Önerdiğim minimumlar:
- Degrade eşiği: ör. 3 ardışık kötü ölçüm
- Recovery eşiği: ör. 10 ardışık iyi ölçüm
- Hold-down: yol değişince X dakika sabit kal
Bu üçlü, incident sırasında “karar kaosu”nu engeller.
Operasyon: Triage runbook’u (15 dakikada sınıflandır)
Bozulma başladığında ilk hedef: “root cause” değil; bozulmayı sınıflandırmak.
1) Hangi sınıf etkileniyor?
- Sadece voice/video mu?
- Sadece ERP mi?
- Tüm trafik mi?
Etkilenen sınıf; genelde root cause’a işaret eder (jitter → bufferbloat/queue, loss → fiziksel/ISP, latency → route değişimi).
2) Probe sonuçları ne diyor?
- Underlay iyi, overlay kötü → hub/DC tarafına bak
- Underlay kötü, overlay kötü → ISP / son mil
- Underlay iyi, overlay iyi ama kullanıcı şikâyetçi → iç LAN/Wi-Fi/endpoint
3) Failover kararını kontrollü ver
- “Auto failover” açıksa bile, kritik dalgalarda manuel “freeze” gerekebilir
- Büyük bir ISP incident’ında tüm şubelerin aynı anda diğer hatta geçmesi; ikinci hattı da boğabilir
Gözlemlenebilirlik: SD-WAN telemetrisini tek yerde topla
SLA probe çıktılarını “controller ekranında” bırakmayın. Şunları merkezi izleyin:
- Şube bazlı latency/jitter/loss trendi
- Yol değişim olayları (path change events)
- Uygulama sınıfı bazında tercih edilen yol
Bu veriler, vendor bağımsız olarak incident postmortem kalitesini yükseltir.
Son söz
SD-WAN’ın “akıllı” olması, sizin operasyonel refleksinizi gereksiz kılmaz. SLA probe ve doğru hedef/eşik tasarımıyla; yol seçimi gerçekten uygulama odaklı hale gelir, incident triage saatlerden dakikalara iner ve failover kararları daha kontrollü olur.