Kurumsal LAN’da QoS: Ses ve Video İçin DSCP ve Kuyruk Tasarımı

Telefonda ses kesik kesik geliyor, görüntülü toplantıda yüzler donuyor; ağ grafiği ise “uplink yüzde yirmi dolu, sorun yok” diyor. Kampüs ağında QoS sorunlarının çoğu buradan başlar: ya hiç yapılandırılmamıştır ya da bir şablondan kopyalanmış, kimsenin doğrulamadığı satırlar olarak durur. Ses ve görüntü kalitesini ortalama bant belirlemez; tıkanıklığın yaşandığı birkaç milisaniyelik anlar belirler. Aşağıda QoS’un LAN’da ne zaman gerektiğini, DSCP sınıf modelini, güven sınırının yerini ve yapılandırmanın sahada nasıl doğrulandığını anlatıyoruz.

LAN’da QoS ne zaman gerçekten gerekir?

QoS bant genişliği üretmez. Yalnızca kuyruk oluştuğunda hangi paketin önce gideceğine, hangisinin düşürüleceğine karar verir. Kuyruk yoksa QoS’un yapacağı iş de yoktur. Bu yüzden ilk soru şudur: ağda tıkanıklık noktası var mı? Kampüste bu noktalar genellikle aynı yerlerde çıkar:

• Hız uyumsuzluğu: 10G uplink’ten gelen trafiğin 1G erişim portuna aktığı yer. Sunucudan istemciye başlayan tek bir büyük dosya aktarımı çıkış kuyruğunu doldurmaya yeter.
• Uplink oversubscription: 48 adet 1G portun 2×10G uplink’i paylaştığı erişim switch’i. Ortalama düşük görünür; gece yedeği, yazılım dağıtımı veya kamera kaydı başladığında anlık yük fırlar.
• Mikro patlamalar (microburst): SNMP’nin 5 dakikalık ortalamasında düşük kullanımda görünen bir arayüz, milisaniye ölçeğinde tamponu taşırıp paket düşürebilir. En somut iz, arayüz sayaçlarındaki çıkış düşmeleridir (output drops).
• Kablosuz kenar: Wi-Fi’da ortam paylaşımlıdır. Kablolu ağda yazılan DSCP değeri erişim noktasında WMM erişim kategorilerine doğru eşlenmezse işaretleme orada biter.

Sahada kullandığımız karar kuralı basit: ses veya video şikâyeti var ve arayüzlerde çıkış düşmesi görülüyorsa QoS gerekir. Düşme yoksa önce gecikme ve jitter’ın kaynağını ayırın; sorun çoğu zaman Wi-Fi, WAN hattı veya uç cihazdadır. Kampüs dışındaki hattın kalitesi için WAN hat kalitesi ve SLA ölçümü yazısına bakın. Yapılandırmaya girmeden önce uplink’lerin gerçek kullanımını uplink kullanımı ve kapasite raporlaması yöntemiyle görün. Ortalama yalan söyler.

Sınıflandırma, işaretleme ve güven sınırı

Uçtan uca QoS, birbirinden ayrı üç işle çalışır:

1. Sınıflandırma: Trafiğin hangi sınıfa ait olduğunu belirlemek (DSCP değeri, ACL, uygulama tanıma).
2. İşaretleme: Sınıf değerini IP başlığındaki DSCP alanına yazmak. Bu iş ağın kenarında bir kez yapılır; dağıtım ve çekirdek bu değere güvenerek kuyruklar.
3. Kuyruklama ve planlama: Her çıkış portunda sınıfları ayrı kuyruklara koymak ve hangi kuyruğun ne kadar hizmet alacağını belirlemek.

Güven sınırı (trust boundary), ağın uç cihazdan gelen işaretlemeyi kabul etmeye başladığı noktadır. Kural net: kontrol etmediğiniz cihazın işaretlemesine güvenmeyin. Bir kullanıcı bilgisayarı tüm trafiğini EF olarak işaretleyebilir; erişim portu bunu kabul ederse öncelik kuyruğu dolar ve gerçek ses trafiği ezilir. Güven sınırını uca mümkün olduğunca yakın, pratikte erişim switch portunda kurun:

• Yönetilen IP telefonlar ve video terminalleri: işaretlemeye güven (koşullu güvenle).
• Kullanıcı bilgisayarları: güvenme. Switch’te ACL ile sınıflandırıp yeniden işaretle ya da her şeyi varsayılan sınıfa (DSCP 0) indir.
• Sunucular ve ses/video altyapı bileşenleri (çağrı kontrol sunucusu, medya geçidi): yönetimi sizde olduğu için veri merkezi tarafında güvenilebilir.

DSCP değerleri ve örnek sınıf tablosu

DSCP, IP başlığındaki 6 bitlik alandır; 64 değer alabilir. Sınıf adları ve önerilen değerler için temel referans IETF’in hizmet sınıfları kılavuzu RFC 4594’tür; EF davranışı RFC 3246, AF grupları RFC 2597 ile tanımlanır. Kampüste gereğinden fazla sınıf açmak yönetimi zorlaştırır, faydası da sınırlı kalır. Çoğu kurum için dört ile altı sınıf yeter. Aşağıdaki tablo örnek bir modeldir:

Sinyalleşme için RFC 4594 CS5 önerir; birçok IP telefon ve Cisco tabanlı ses ortamı ise sinyalleşmeyi varsayılan olarak CS3 ile işaretler. Hangisini seçerseniz seçin, tüm ağda ve WAN kenarında aynı eşlemeyi kullanın. Yedekleme ve yazılım dağıtımı için RFC 8622 ayrıca “Lower Effort” (LE, DSCP 1) değerini tanımlar. Mevcut cihazlarınızın bu değeri hangi kuyruğa attığını doğrulamadan kullanmayın; bazı eski platformlar onu tanımadığı varsayılan kuyruğa koyar.

Kuyruklama: öncelik kuyruğu ve tampon

Ses trafiği öncelik kuyruğuna (strict priority / LLQ) gider: bu kuyrukta paket varsa her zaman önce gönderilir. Riski de buradadır. Öncelik kuyruğuna fazla trafik girerse diğer kuyruklar aç kalır. Bu yüzden öncelik kuyruğu ya bir polis (policer) ile sınırlanır ya da sıkı bir güven sınırıyla yalnız gerçek ses trafiğinin oraya girmesi sağlanır. Cisco tasarım kılavuzlarında sık geçen pratik kural, öncelik kuyruğunun bağlantı kapasitesinin yaklaşık üçte birini aşmamasıdır. Bu bir standart değil, başlangıç değeridir.

Diğer sınıflar ağırlıklı kuyruklarla (bandwidth remaining) pay alır. Buradaki değerler üst sınır değil, tıkanıklık anındaki minimum paydır; tıkanıklık yokken her sınıf boştaki bandı kullanabilir. Bu ayrımı karıştırıp “video yüzde otuzla sınırlandı” diye şikâyet edilen durumlara sahada sık rastlıyoruz.

Tampon yönetimi en çok atlanan kısımdır. Erişim switch’lerinde tampon, ASIC başına paylaşılan sınırlı bir bellektir. Video ve yedekleme gibi patlamalı akışlar tamponu doldurduğunda düşme, sınıftan bağımsız yaşanabilir. Catalyst 9000 gibi platformlarda kuyruk başına tampon oranı ve paylaşılan tampon ayarı (örneğin qos queue-softmax-multiplier) değiştirilebilir. Bu ayarlar platforma özgüdür; dokunmadan önce üreticinin QoS yapılandırma kılavuzunu okuyun. Tampon sonsuz değildir.

Ses VLAN’ı ve IP telefon ile güven

Bilgisayarın telefonun arkasına bağlandığı klasik masaüstü senaryosunda erişim portu iki VLAN taşır: veri VLAN’ı (etiketsiz) ve ses VLAN’ı (802.1Q etiketli). Telefon ses VLAN bilgisini CDP veya LLDP-MED ile öğrenir. Ses VLAN’ını ayırmak tek başına QoS sağlamaz; ama sınıflandırmayı, DHCP kapsamını ve politika uygulamasını sadeleştirir. VLAN yapısının genel tasarımı için kurumsal ağda VLAN tasarımı yazısı başlangıç noktasıdır.

Koşullu güven: Cisco switch’lerde trust device cisco-phone komutu, porta CDP ile bir Cisco IP telefon algılandığında işaretlemeye güvenir. Telefon sökülüp yerine bilgisayar takılırsa güven kendiliğinden kalkar. Başka üreticinin telefonlarında aynı sonuç, ses VLAN’ından gelen trafiğe ACL tabanlı sınıflandırma uygulanarak alınır.

Yazılım istemcileri: Teams, Zoom veya Webex bilgisayarda çalışır; trafiği veri VLAN’ından gelir. İki yol var: işletim sisteminde DSCP işaretleyip switch’te yalnız beklenen port aralıklarından gelen işaretlemeyi kabul etmek ya da işaretlemeyi doğrudan switch’te port aralığına göre yapmak. Microsoft Teams için yönetim merkezinde medya port aralıkları tanımlanabilir; Microsoft dokümantasyonu ses için 50000–50019, video için 50020–50039 kaynak port aralığını örnek verir. Windows’ta işaretleme Grup İlkesi veya PowerShell ile yapılır:

New-NetQosPolicy -Name "Teams Ses" -AppPathNameMatchCondition "ms-teams.exe" `
  -IPSrcPortStartMatchCondition 50000 -IPSrcPortEndMatchCondition 50019 `
  -DSCPAction 46 -NetworkProfile All

Uygulama yolu ve port aralıkları istemci sürümüne göre değişebilir. Değerleri kendi yönetim merkezi ayarlarınızla eşleştirin; istemci güncellendikten sonra işaretlemenin sessizce kaybolduğu durum sahada tanıdık bir arızadır.

Örnek erişim switch’i yapılandırması

Aşağıdaki örnek, Cisco IOS XE çalıştıran bir Catalyst 9300 için MQC sözdizimiyle hazırlandı. Giriş politikası bilgisayar portlarında güven sınırını kurar; çıkış politikası uplink ve erişim portlarında kuyruklamayı tanımlar. Yüzde değerleri örnektir, kendi trafik profilinize göre belirleyin.

ip access-list extended ACL-SOFTPHONE-SES
 permit udp any range 50000 50019 any
ip access-list extended ACL-SOFTPHONE-VIDEO
 permit udp any range 50020 50039 any
!
class-map match-any CM-SES-IN
 match access-group name ACL-SOFTPHONE-SES
class-map match-any CM-VIDEO-IN
 match access-group name ACL-SOFTPHONE-VIDEO
!
policy-map PM-PC-INGRESS
 class CM-SES-IN
  set dscp ef
 class CM-VIDEO-IN
  set dscp af41
 class class-default
  set dscp default
!
class-map match-any CM-SES
 match dscp ef
class-map match-any CM-VIDEO
 match dscp af41
class-map match-any CM-SINYAL
 match dscp cs3
class-map match-any CM-TOPLU
 match dscp cs1
!
policy-map PM-EGRESS
 class CM-SES
  priority level 1
  police rate percent 20
 class CM-VIDEO
  bandwidth remaining percent 30
 class CM-SINYAL
  bandwidth remaining percent 5
 class CM-TOPLU
  bandwidth remaining percent 5
 class class-default
  bandwidth remaining percent 60
!
interface GigabitEthernet1/0/12
 description USR | Masaustu + IP telefon
 switchport access vlan 20
 switchport voice vlan 120
 trust device cisco-phone
 service-policy output PM-EGRESS
!
interface GigabitEthernet1/0/30
 description USR | Yalniz bilgisayar
 switchport access vlan 20
 service-policy input PM-PC-INGRESS
 service-policy output PM-EGRESS
!
interface TenGigabitEthernet1/1/1
 description UPL | DS01 Te1/0/5
 service-policy output PM-EGRESS

ACL’ler yalnız kaynak port aralığına bakar. Aynı portları kullanan başka bir uygulama da EF alabilir; çıkıştaki öncelik kuyruğunun police ile sınırlanmasının nedeni budur. Ses VLAN’ındaki telefon portunda (Gi1/0/12) trust device cisco-phone yalnız CDP ile Cisco telefon algılandığında DSCP’ye güvenir. Ancak telefonun arkasındaki bilgisayarın veri VLAN’ı trafiği de aynı porttan girer ve güven bu trafiği de kapsayabilir. Bilgisayarın işaretlemesini de denetlemek istiyorsanız porta veri VLAN’ını yeniden işaretleyen bir giriş politikası eklemeyi değerlendirin. Koşullu güven ile service-policy input birlikte kullanıldığında platformun davranışını Catalyst QoS yapılandırma kılavuzundan doğrulayın.

Uplink portunda giriş politikası yok; dağıtım katmanından gelen işaretleme güven sınırının içinde kaldığı için olduğu gibi kabul edilir. Dağıtım ve çekirdekte de aynı DSCP–kuyruk eşlemesini uygulayın. Aksi halde öncelik yalnız ağın bir parçasında geçerli olur. Zincir en zayıf halkada kopar.

QoS’un doğrulanması ve sık hatalar

Yapılandırma yazıldı diye QoS çalışıyor sayılmaz. İşaretleme ve kuyruk sayaçları ölçülerek doğrulanır. Konsolda izlediğimiz sıra şu:

1. İşaretlemeyi uçta kontrol edin: İstemci tarafında ve uplink üzerinde SPAN ile alınan yakalamada Wireshark filtresi ip.dsfield.dscp == 46 ile ses paketlerinin EF taşıdığını görün. Yakalama tekniği için Wireshark ile ağ paket analizi rehberini kullanabilirsiniz.
2. Politika eşleşmelerini sayın: show policy-map interface GigabitEthernet1/0/30 çıktısında sınıflara düşen paket sayaçlarının arttığını doğrulayın. Sayaç sıfırsa ACL tutmuyordur.
3. Kuyruk düşmelerini izleyin: Catalyst 9000’de show platform hardware fed switch active qos queue stats interface TenGigabitEthernet1/1/1 kuyruk bazlı enqueue ve drop sayaçlarını verir. Düşmeler varsayılan ve toplu iş kuyruğunda olmalı, ses kuyruğunda sıfır kalmalı.
4. Uygulama tarafını ölçün: Görüşme platformunun çağrı kalite raporlarında jitter ve paket kaybının yük altında da kabul edilebilir aralıkta kaldığını kontrol edin.

Sahada en sık gördüğümüz hatalar:

• Bilgisayar portlarında gelen DSCP’ye koşulsuz güvenmek; öncelik kuyruğunun ses dışı trafikle dolması.
• Erişim katmanında QoS yapıp dağıtım/çekirdekte yapmamak ya da katmanlar arasında farklı DSCP–kuyruk eşlemesi kullanmak.
• Videoyu EF ile işaretlemek; öncelik kuyruğunu patlamalı, yüksek bantlı trafiğe açmak.
• Kablosuz kontrolcüde veya erişim noktasında DSCP–WMM eşlemesini kontrol etmemek; kablolu ağdaki işaretlemenin Wi-Fi tarafında kaybolması.
• Firewall veya WAN cihazının DSCP değerini sıfırlaması; işaretlemenin şubeye hiç ulaşmaması.
• Sorunun kaynağı uplink kapasitesi veya kablolama hatasıyken QoS’u çözüm sanmak. CRC hatası olan portu QoS düzeltmez.

QoS çalışmasına başlamadan önce mevcut düşme noktalarını ve şikâyetlerin kaynağını netleştirmek için network performans analizi yapılabilir. Sınıf modeli ve güven sınırı, VLAN ve yönlendirme tasarımıyla birlikte segmentasyon projesinin parçası olarak ele alındığında tutarlı kalır.

Sık sorulan sorular

Bant genişliğimiz yeterliyse LAN’da QoS’a ihtiyaç var mı?

Arayüzlerde çıkış düşmesi yoksa QoS’un etkisi sınırlıdır, çünkü QoS yalnız kuyruk oluştuğunda devreye girer. Ama ortalama kullanım düşük görünse bile hız uyumsuzluğu ve mikro patlamalar kısa süreli düşmelere yol açar. Kararı ortalama kullanıma göre değil, düşme sayaçlarına bakarak verin.

Bilgisayardan gelen DSCP işaretlemesine güvenmeli miyim?

Hayır. Bilgisayar portunda gelen işaretlemeyi sıfırlayın; yalnız beklenen uygulama ve port aralıklarına uyan trafiği switch üzerindeki ACL ile yeniden işaretleyin. Böylece öncelik kuyruğu ses dışı trafikle dolmaz.

Video trafiğini neden EF ile işaretlemiyoruz?

EF öncelik kuyruğuna gider ve bu kuyruk diğerlerinden önce hizmet alır. Video yüksek bantlı ve patlamalıdır; öncelik kuyruğuna alınırsa diğer sınıfları aç bırakabilir. Etkileşimli video için AF41 ile garantili bant payı vermek daha dengeli sonuç verir.

QoS’un çalıştığını nasıl kanıtlarım?

Paket yakalamasıyla DSCP değerlerinin doğru taşındığını, policy-map sayaçlarıyla sınıflara eşleşme olduğunu, kuyruk istatistikleriyle de düşmelerin ses kuyruğunda değil düşük öncelikli kuyruklarda yaşandığını gösterin. Yük altında bir çağrı testi yapıp jitter ve kayıp değerlerini kaydedin.