Cem Kemal Erbaş Network, Siber Güvenlik ve Teknik Rehberler
QoS policy konfigürasyonunun mevcut olması, kritik trafiğin gerçekten doğru sınıfa girdiği ve önceliklendirildiği anlamına gelmez.
Cisco ağlarda QoS troubleshooting sırasında benim temel kontrol sıram:
Classification → DSCP → Class-Map → Policy-Map → Interface/Direction → Queue/Drops
1. Trafik Doğru Class’a Giriyor mu?
İlk kontrol:
show policy-map interface GigabitEthernet0/0Cisco IOS XE’de bu komut, interface üzerindeki QoS policy davranışını doğrulamanın temel yollarından biridir. Class bazında packet/byte counter ve platforma göre queue/drop istatistikleri görülebilir.
Özellikle:
Class counters → Offered rate → Queue depth → Drops
kontrol edilmelidir.
Beklediğiniz trafik akarken ilgili class counter artmıyorsa önce classification tarafına odaklanın.
2. DSCP Gerçekten Doğru mu?
Örneğin voice için yaygın olarak:
DSCP EF = 46kullanılır.
Class-map:
class-map match-any VOICE
match dscp efşeklindeyse ama uç cihaz veya upstream network trafiği EF olarak işaretlemiyorsa paketler VOICE class’ına girmeyecektir.
Bu nedenle yalnızca policy’ye değil, paketin firewall/router’a hangi DSCP değeriyle ulaştığına da bakmak gerekir.
3. LLQ Gerçekten Uygulanıyor mu?
Örnek:
policy-map WAN-QOS
class VOICE
priority percent 20priority percent ilgili trafik class’ına strict priority / LLQ davranışı sağlar ve belirtilen oranı interface bandwidth’inin yüzdesi olarak tanımlar.
Bu özellikle düşük gecikme gerektiren voice gibi trafiklerde kullanılır.
Ancak şu ayrımı unutmayın:
Priority queue var ≠ Trafik doğru class’a giriyor
Önce classification’ın gerçekten çalıştığından emin olun.
4. Policy Doğru Interface ve Direction’da mı?
Örneğin WAN çıkışındaki congestion’ı yönetmek istiyorsanız:
interface GigabitEthernet0/0
service-policy output WAN-QOSgibi doğru egress noktası seçilmelidir.
service-policy input veya output yönünde interface’e bağlanabilir; queueing politikalarının yön ve platform desteği cihaz ailesine göre değişebilir.
Yanlış interface veya yanlış direction, QoS troubleshooting’de sık görülen hatalardandır.
5. Congestion Gerçekten Oluşuyor mu?
Örneğin:
Interface kapasitesi : 1 Gbps
Gerçek trafik : 50 Mbpsise priority queue’nun etkisini gözlemlemek zor olabilir.
Ancak:
WAN kapasitesi : 100 Mbps
Trafik talebi : 120 Mbpsolduğunda scheduler hangi trafiğin önce gönderileceğine karar vermek zorunda kalır.
QoS queueing’in asıl değeri burada ortaya çıkar.
Önemli nüans:
Classification, marking veya policing congestion olmadan da çalışabilir; congestion özellikle scheduling ve queueing davranışını görünür hale getirir.
6. Queue ve Drop Counter’larına Bakın
Tekrar:
show policy-map interface GigabitEthernet0/0çıktısını inceleyin.
Platforma göre aşağıdaki değerler görülebilir:
queue depth
total drops
offered rate
drop rate
packets / bytes
policeCisco’nun QoS verification örneklerinde de show policy-map interface çıktısı class match, queue depth ve drop istatistiklerini birlikte gösterir.
Örneğin VOICE class counter artıyor ancak priority queue üzerinde drop oluşuyorsa artık problem classification değil, bandwidth/policing/queue tasarımı tarafındadır.
Hızlı Troubleshooting Akışı
Traffic → DSCP → Class-Map → Policy-Map → Service-Policy → Queue → Drops
QoS troubleshooting’de asıl soru:
“QoS policy var mı?”
değil,
“Kritik trafik doğru class’a giriyor mu ve congestion sırasında beklenen scheduler davranışını gerçekten görüyor muyum?”
olmalıdır.
QoS yalnızca:
“Voice’a priority verdim.”
demek değildir.
Asıl amaç:
Congestion oluştuğunda hangi trafiğin hangi öncelik ve bant genişliği politikasıyla iletileceğini önceden belirlemektir.
