WAN Hat Kalitesi ve SLA Ölçümü: Gecikme, Jitter ve Paket Kaybı

Operatör sözleşmesinin SLA eki imza günü bir kez okunur, sonra ilk büyük arızaya kadar çekmecede kalır. Arıza günü ortaya çıkan gerçek şudur: kendi tarafınızda ölçmediğiniz bir taahhüdü talep edemezsiniz. Aşağıda WAN ve internet hatlarında gecikme, jitter, paket kaybı ve erişilebilirliğin nasıl tanımlandığını, Cisco IP SLA, TWAMP ve iperf3 ile nasıl ölçüleceğini ve operatöre arıza bildirirken kabul görecek kanıtın nasıl hazırlanacağını anlatıyoruz.

Operatör SLA’sında ölçülen metrikler

SLA ekini okurken her metrik için dört soru sorun: Nasıl tanımlanmış? Hangi iki nokta arasında ölçülüyor? Hangi periyotta ortalama alınıyor? İhlal olursa ne oluyor? Tipik bir kurumsal hat sözleşmesinde şu kalemler bulunur:

Erişilebilirlik yüzdesini dakikaya çevirince beklenti netleşir. 30 günlük bir ay 43.200 dakikadır; aylık yüzde 99,9 taahhüt bu sürenin binde biri, yani yaklaşık 43 dakikalık kesinti payıdır. Ölçüm noktası ise en çok gözden kaçan ayrıntıdır. MPLS hizmetlerinde operatörler gecikme taahhüdünü çoğunlukla kendi omurgalarındaki PE yönlendiriciler arasında verir; erişim devresi ve müşteri yerindeki cihaz bu ölçümün dışında kalır. Sizin uçtan uca ölçümünüzle operatör raporunun farklı çıkmasının ilk nedeni budur. İkisi de doğru olabilir.

Gecikme, jitter ve paket kaybı tanımları

Bu metriklerin standart tanımları IETF IPPM çalışma grubunun belgelerindedir. Operatörle tartışırken ortak dil bunlardır:

• Tek yön gecikme (RFC 7679): Paketin kaynaktan çıkışı ile hedefe varışı arasındaki süre. İki ucun saatleri senkronize olmalıdır; NTP ile milisaniye düzeyinde hata kalabildiği için düşük gecikmeli hatlarda sonucu dikkatli yorumlayın.
• Gidiş-dönüş gecikme (RTT) (RFC 2681): Saat senkronizasyonu gerektirmediği için en yaygın ölçümdür; ama gecikmenin hangi yönde oluştuğunu göstermez.
• Jitter (IPDV) (RFC 3393): Ardışık paketlerin gecikmeleri arasındaki fark. Ses ve video uygulamalarında jitter tamponu bu oynamayı emer; tampon aşılınca paket geç geldiği halde kaybolmuş sayılır.
• Paket kaybı (RFC 7680): Belirli bir süre içinde hedefe ulaşmayan paketlerin oranı. Dağılım da önemlidir: aynı ortalama oran, dağınık tekil kayıplarda ses kalitesini az etkiler, art arda kayıplarda ise konuşmada belirgin kopmalar yaratır.

Ses için referans olarak ITU-T G.114, çoğu uygulamada tek yön gecikmenin 150 ms altında tutulmasını önerir. Bu bir operatör taahhüdü değildir, uçtan uca bütçedir; kodlama, jitter tamponu ve LAN gecikmesi de bu bütçeden pay alır. Hattın kendisine kalan pay daha küçüktür.

Aktif ölçüm: Cisco IP SLA ve TWAMP

Arayüz sayaçları ve akış verisi hattın ne kadar dolu olduğunu söyler, ne kadar iyi olduğunu söylemez. Kaliteyi görmek için hattın üzerinden düzenli olarak sentetik test trafiği gönderen aktif ölçüm gerekir.

Cisco IP SLA

Cisco IOS ve IOS XE yönlendiricilerde IP SLA, ICMP’den UDP jitter ölçümüne kadar çeşitli işlemler sunar. udp-jitter işlemi gecikme, jitter ve yön bazında kayıp verir; karşı uçta IP SLA responder çalışmalıdır. Aşağıdaki örnek, merkezdeki router’a ses kodeğini taklit eden test trafiği gönderir ve gecikme eşiği aşılınca SNMP trap üretir:

! Şube router
ip sla 10
 icmp-echo 198.51.100.1 source-interface GigabitEthernet0/0/0
 frequency 30
ip sla schedule 10 life forever start-time now
!
ip sla 20
 udp-jitter 10.255.0.1 16384 codec g711alaw
 tos 184
 frequency 60
ip sla schedule 20 life forever start-time now
ip sla reaction-configuration 20 react rtt threshold-value 150 100 threshold-type consecutive 3 action-type trapOnly
!
! Merkez router (karşı uç)
ip sla responder
!
! Sonuçların incelenmesi
show ip sla statistics 20 details
show ip sla summary

tos 184 değeri DSCP EF (46) işaretlemesine karşılık gelir; ölçüm paketleri gerçek ses trafiğiyle aynı QoS sınıfında taşınır. Sahada sık gördüğümüz hata, ölçümün işaretlemesiz çalıştırılmasıdır: QoS’li bir hatta best-effort sınıfında ölçüm yapmak ses trafiğinin deneyimini yansıtmaz. Responder tarafında da kontrol edin: karşı uçta ip sla responder yoksa ya da aradaki firewall test portunu kesiyorsa udp-jitter işlemi sessizce başarısız olur. show ip sla statistics çıktısında dönüş kodunu mutlaka okuyun.

TWAMP

TWAMP (RFC 5357), farklı üreticilerin cihazları arasında iki yönlü ölçüm için standart protokoldür. Kontrol ve test oturumlarından oluşan tam sürümün yanında, yalnızca yansıtıcı tarafın çalıştığı daha basit TWAMP Light modu da yaygındır; daha yeni STAMP (RFC 8762) benzer hafif yaklaşımı standartlaştırır. Birçok operatör CPE’sinde ve SD-WAN cihazında TWAMP yansıtıcısı bulunur. Operatörle aynı yöntemle ölçmek istiyorsanız teslim cihazında TWAMP desteğini sözleşme aşamasında sorun; arıza günü sormak geç kalmaktır. Protokol ayrıntıları için RFC 5357 birincil kaynaktır.

iperf3 ile throughput testi

Gecikme ve kayıp ölçümü hattın kalitesini, throughput testi kapasitesini doğrular. iperf3 bir uçta sunucu, diğer uçta istemci olarak çalışır:

# Karşı uçta (merkez veya bulut sunucusu)
iperf3 -s

# TCP, 4 paralel akış, 30 saniye, yükleme yönü
iperf3 -c 203.0.113.50 -P 4 -t 30

# Aynı test indirme yönünde (sunucu gönderir)
iperf3 -c 203.0.113.50 -P 4 -t 30 -R

# UDP, 50 Mbps sabit hızda: jitter ve kayıp raporu
iperf3 -c 203.0.113.50 -u -b 50M -t 30

# Sonuçları JSON olarak kaydetmek için
iperf3 -c 203.0.113.50 -P 4 -t 30 -J > test-$(date +%F-%H%M).json

Sonucu yorumlarken sınırları bilin. Tek bir TCP akışı yüksek gecikmeli hatlarda pencere boyutu yüzünden hat hızına ulaşmayabilir; paralel akış bu etkiyi azaltır. Test istemcisi kablosuz ağda değil, kablolu ve hattın önündeki firewall’un inceleme yükünü taşımayan bir noktada olmalı. Firewall’daki IPS veya SSL inceleme kapasitesi sonuca karışırsa ölçtüğünüz şey hat değil cihazdır. Bu hatayı çok görürüz. UDP testinde -b değerini hat hızının üzerine çıkarmak kayıp üretir; bu kayıp hattın değil aşırı yüklemenin sonucudur. Hat kapasitesinin baştan nasıl belirleneceği internet hattı kapasite planlama yazısında anlatılıyor.

Ölçüm noktası ve zamanlaması

Ölçümün nerede ve ne zaman yapıldığı, sonucun kime kanıt olacağını belirler.

• Teslim noktasına yakın ölçün: Operatöre sunulacak kanıt, ölçüm kaynağı operatör cihazının hemen arkasındaysa güçlüdür. Firewall’un dış arayüzü veya teslim switch’ine bağlı bir ölçüm cihazı iyi seçimdir.
• Uçtan uca ölçümü ayrıca tutun: Kullanıcı deneyimini temsil eden ikinci bir ölçüm, kurumsal ağ altyapısındaki LAN ve firewall kaynaklı sorunları hat sorunlarından ayırmanızı sağlar.
• Sürekli ölçün: Sorun yalnızca belirli saatlerde görülüyorsa (mesai başı, gece yedeklemesi) anlık testler işe yaramaz. Düşük sıklıklı ama sürekli aktif ölçüm, sorunun zaman desenini ortaya çıkarır.
• Yükle birlikte okuyun: Gecikme artışı kendi hat doluluğunuzla çakışıyorsa sorun kapasitedir; hat boşken de görülüyorsa operatör tarafında aranmalıdır.

Yol üzerindeki ara noktaları görmek için mtr -rwzc 200 203.0.113.50 gibi bir rapor kullanın. Yalnızca bir ara atlamada görünen, sonraki atlamalarda ve hedefte görünmeyen kayıp çoğunlukla o cihazın kendisine gelen ICMP’yi düşük öncelikle işlemesinden kaynaklanır. Gerçek kayıp değildir. Operatöre bu ekran görüntüsüyle gitmek, ilk yazışmada geri çevrilmenin en kısa yoludur.

Eşik ve alarm tanımları

Eşikleri sözleşme değerlerinden ve hattın kendi normalinden birlikte türetin. Evrensel sabitler yerine birkaç haftalık ölçümle çıkardığınız temel çizgiyi (baseline) referans alın. Aşağıdaki tablo örnek bir yapıdır; değerleri hat türüne göre uyarlayın.

Tek ölçüme dayalı alarm gürültü üretir; ardışık sayı veya zaman penceresi koşulu ekleyin. Kapanış için de benzer bir koşul (histerezis) tanımlayın, yoksa sınırda dalgalanan bir hat gece boyunca aç-kapa bildirimi üretir ve ekip bir hafta sonra o alarmı okumayı bırakır. Ölçümleri bir izleme sisteminde tutacaksanız seçenekler Zabbix, LibreNMS ve PRTG karşılaştırması yazısında değerlendiriliyor.

Operatöre arıza bildirimi için kanıt paketi

Operatör arıza masası çoğu zaman önce sizin tarafınızı sorgular. Aşağıdaki paketle başvurmak ilk tur yazışmaları kısaltır:

1. Hat kimliği ve teslim bilgisi: Devre numarası, teslim arayüzü, IP bilgileri.
2. Zaman damgalı ölçüm verisi: NTP ile senkronize cihazlardan, sorunun başladığı andan önce ve sonra gecikme, jitter ve kayıp grafikleri. Saat dilimini yazın.
3. Yük grafiği: Aynı aralıkta hattın doluluk oranı; sorunun kendi trafiğinizden kaynaklanmadığını gösterir.
4. Fiziksel katman verisi: Arayüz hata sayaçları (CRC, input errors), fiber hatlarda optik seviyeler (Cisco’da show interfaces transceiver), link düşme kayıtları.
5. Yol analizi: Her iki yönde mtr veya traceroute çıktısı; mümkünse karşı uçtan da alınmış.
6. Doğrudan bağlantı testi: Gerekirse firewall’u devreden çıkarmak için teslim noktasına doğrudan bağlanan bir dizüstü bilgisayarla kısa süreli test; bu bilgisayarın yerel güvenlik duvarı açık ve yamaları güncel olmalı.

Çift hatlı yapılarda aynı ölçümler yedeğe geçiş kararının da girdisidir; bu mekanizma çift internet hattı ile failover yazısında anlatılıyor. Hat kalitesinin sürekli izlenmesi ve operatör süreçlerinin yönetimi internet hat yönetimi, mevcut performans sorunlarının teşhisi network performans analizi hizmetimizin kapsamındadır.

Sık sorulan sorular

Ping ile ölçülen gecikme SLA ölçümü yerine geçer mi?

Kısmen. ICMP tabanlı RTT ölçümü erişilebilirlik ve kaba gecikme takibi için yeterlidir; ama jitter ve tek yön kaybı hakkında sınırlı bilgi verir ve bazı cihazlar ICMP’yi düşük öncelikle işler. Ses ve video taşıyan hatlarda UDP tabanlı ölçüm (IP SLA udp-jitter veya TWAMP) daha doğru sonuç verir.

Operatör kendi ölçümünde sorun görmüyor, ne yapmalıyım?

Önce iki tarafın neyi ölçtüğünü eşleştirin: operatör çoğu zaman kendi omurgasında PE’ler arasını ölçer, siz uçtan uca ölçersiniz. Ölçümü teslim noktasına olabildiğince yakın yapın; zaman damgalı, sürekli veriyle, hat kimliği ve fiziksel arayüz hata sayaçlarıyla başvurun. Sorunun teslim noktasının ötesinde olduğunu gösteren veri arızanın kabulünü hızlandırır.

iperf3 testini internetteki açık sunuculara yapmak doğru mu?

Sonuç, karşı sunucunun yükü ve onun internet bağlantısıyla da sınırlanır; hat kapasitesini kanıtlamak için güvenilir değildir. Diğer lokasyonunuzdaki veya bulutta kendi kontrolünüzdeki, test edilen hattan daha hızlı bağlantıya sahip bir sunucuyu kullanın ya da operatörden test sunucusu isteyin.

Erişilebilirlik yüzdesi pratikte ne anlama gelir?

Ay bazında, 30 günlük bir ayda yüzde 99,9 erişilebilirlik yaklaşık 43 dakika, yüzde 99,95 yaklaşık 22 dakika, yüzde 99,99 ise yaklaşık 4,3 dakika toplam kesinti payı demektir. Planlı bakımların ve müşteri kaynaklı arızaların bu hesaptan hariç tutulup tutulmadığını sözleşmede ayrıca kontrol edin.