WAN darboğazı başladığında ilk refleks genelde “QoS açalım, kritik trafik kurtulsun” olur. QoS doğru kurgulanırsa gerçekten hayat kurtarır; yanlış kurgulanırsa da sorunu gizler, teşhisi zorlaştırır ve ekipleri yanıltır.
Bu yazıda teoriyi uzatmadan, sahada çalıştırdığım şekilde anlatıyorum: DSCP işaretleme + trust boundary + kuyruk politikası + ölçüm.
1) Önce sınıfları tanımla (iş değil, akış)
QoS sınıfları “departman” ya da “uygulama adı” üzerinden değil, akış davranışı üzerinden tanımlanmalı:
- Interactive: düşük gecikme/jitter (VoIP, VDI, terminal)
- Transactional: kısa burst, hataya hassas (API, ödeme, login)
- Bulk: büyük transfer, gecikmeye toleranslı (backup, artifact, replication)
- Control-plane: routing, keepalive, monitoring
Benim önerim: ilk etapta 3–5 sınıfı geçmeyin. Çok sınıf, çok istisna = operasyonel borç.
2) DSCP: “etiket” değil, sözleşme
DSCP’yi şöyle düşünün:
- Edge’de işaretlersiniz (marking)
- Ağ boyunca korursunuz (trust boundary)
- Dar boğazda davranışa çevirirsiniz (queueing/shaping)
DSCP sınıfı seçerken bir “sözleşme” dokümanı çıkarın:
- DSCP değeri
- Hangi akışlar
- Nerede işaretlenir (ingress)
- Nerede yeniden yazılır (remark)
- Nerede “trust edilir”
Trust boundary olmadan QoS olmaz
Eğer her yer DSCP’yi “trust” ederse, bir servis yanlış işaretleyerek tüm WAN’ı rehin alabilir.
Pratik kural:
- Access/host tarafında DSCP’yi trust etme, yeniden yaz
- DC edge / SD-WAN edge üzerinde trust boundary oluştur
- WAN core üzerinde “trust edilmiş sınıflar” ile çalış
3) Dar boğaz nerede? (Yalnızca WAN linki değil)
QoS’u sadece WAN linkinde uygulamak çoğu zaman yetmez. Dar boğaz şu noktalarda da olur:
- İnternet çıkışı (egress)
- VPN/IPsec tünel (şifreleme CPU, MTU, fragment)
- Cloud interconnect (rate limit / policing)
- Firewall/NGFW throughput
Bu yüzden “QoS rollout” işini bir bottleneck haritası ile başlatın:
- Link kapasitesi
- Gerçek kullanım (p95)
- Drop nedeni (queue tail drop mı, policer mı?)
- MTU/fragment göstergeleri
4) Kuyruk politikası: “öncelik” değil “adil pay”
İki yaygın hata:
- Her şeyi “yüksek öncelik” yapma
- Yüksek önceliğe sınırsız bant verme
Benim yaklaşımım:
- Interactive sınıfa düşük ama garanti bant + düşük gecikme kuyruğu
- Transactional sınıfa garanti + burst
- Bulk sınıfa kalan bant + agresif shaping
- Control-plane’e küçük ama dokunulmaz bant
5) MTU ve tüneller: QoS’un sessiz katili
WAN’da QoS doğru görünür ama kullanıcı hala şikayet ediyorsa, kontrol listem:
- IPsec overhead sonrası effective MTU kaç?
- MSS clamping var mı?
- Fragment/drop artıyor mu?
- DSCP, tünel içinde kayıp mı oluyor (encapsulation remark)?
DSCP’nin tünel giriş/çıkışında taşındığını kanıtlayın: kısa bir packet capture ile (iç + dış header).
6) Rollout planı (operasyonel olarak güvenli)
Bu iş “tek seferde global enable” değil, ring ring yapılmalı:
- Sınıfları tanımla (doküman + ownership)
- Edge’de marking (pasif: sadece işaretle, kuyruklama yok)
- Ölç: DSCP dağılımı, yanlış işaretlenen akışlar
- Egress’te queueing/shaping (canary site)
- SLO: p95 latency/jitter hedefleri
- Runbook: rollback (tek komut / tek policy)
7) Başarı kriteri (ölçülebilir)
Benim “QoS başarılı” dediğim tablo:
- Dar boğaz anında interactive p95/jitter korunuyor
- Transactional hata oranı yükselmiyor (timeout/5xx)
- Bulk transferler yavaşlıyor ama “kill” olmuyor
- QoS yanlış sınıflandırma alarmı var (anomaliler)
Kapanış: QoS, kapasite tartışmasını ertelemesin
QoS iyi bir emniyet kemeridir, ama fren değildir. Eğer sürekli QoS ile “kurtarıyorsanız” kapasite planlama, path çeşitlendirme veya uygulama seviyesinde degrade/load shedding gündemine girmek gerekir.
Bu yazıyı bir cümleye indirgersem: QoS’u “policy” olarak değil, “operasyonel sözleşme” olarak yönetin.