Linux tc ile VoIP için DSCP EF İşaretleme ve Öncelik Kuyruğu Yapılandırması

Ortamımda, tc kullanarak VoIP trafiğinin Linux yönlendiriciler ve ağ geçitlerinde düşük gecikmeli işlenmesini sağlıyorum. Temel fikir, paketleri DSCP EF (Expedited Forwarding) ile işaretleyerek kuyrukta önüne geçmesini sağlamak. İlk olarak VoIP trafiğini sınıflandırıyorum—genelde SIP için UDP 5060 bağlantı noktası ve RTP için 10000-20000 aralığı—sonra EF işaretini uyguluyorum. Bundan sonra, WAN arayüzünde HTB kullanarak giden trafiği şekillendiriyorum ve EF sınıfına strict öncelik veriyorum.

VoIP Paketlerini DSCP EF ile İşaretleme

VoIP akışlarını tanımlayarak başlarım. SIP sinyali için bağlantı noktası 5060 ile eşleşirme yaparım. Medya için ise PBX tarafından kullanılan RTP bağlantı noktası aralığını eşleştiririm. iptables'in mangle tablosunu kullanarak DSCP alanını 0x2e (EF) olarak ayarlarım. Uyguladığım kural kümesi şu şekildedir:

# SIP sinyali
iptables -t mangle -A POSTROUTING -p udp --dport 5060 -j DSCP --set-dscp-class EF
# RTP medya aralığı
iptables -t mangle -A POSTROUTING -p udp --dport 10000:20000 -j DSCP --set-dscp-class EF

Kuralları uyguladıktan sonra tcpdump -vv -i eth0 ile doğrulama yaparım—IP başlığındaki DSCP alanının 0x2e göstermesi gerekir. Göstermezse, tablo ve zincir yerleşimini kontrol ederim; yerel olarak üretilen trafik için POSTROUTING işe yarar, ancak yönlendirme trafiği için FORWARD kullanılmalı veya yönlendirmeye göre ayarlanmalıdır.

EF Kuyruğunu HTB ile Yapılandırma

Sadece işaretleme öncelik sağlamaz; DSCP'i sayan bir kuyrulama disiplini gerekir. Eğri arayüz (örneğin eth0) üzerinde HTB kullanarak üç sınıf oluştururum: EF için yüksek öncelik, toplu trafik için orta ve en iyi çaba için düşük. EF sınıfına garanti minimum bant genişliği verir ve bant boşta ise patlama yapmasına izin verir.

İlk olarak kök qdisc'i eklerim:

tc qdisc add dev eth0 root handle 1: htb default 20

Sonra sınıfları oluştururum. ISP düşüşlerinden kaçınmak için WAN hızımın %90'unu şekillendiririm—digel 10mbit bağlantı için 9mbit örneğiyle:

# Üst sınıf
tc class add dev eth0 parent 1: classid 1:1 htb rate 9mbit ceil 9mbit
# EF sınıfı (10)
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1mbit ceil 9mbit prio 0
# Toplu sınıf (20)	tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit ceil 9mbit prio 1
# En iyi çaba (30)	tc class add dev eth0 parent 1:1 classid 1:30 htb rate 5mbit ceil 9mbit prio 2

Her sınıfa sfq qdisc'i ekleyerek adalet sağlarım:

tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10

Son olarak, DSCP işaretine göre trafiği EF sınıfına yönlendiren filtreyi eklerim:

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32
  match ip dscp 0x2e 0xfc flowid 1:10

EF sınıfındaki prio 0, bu sınıfın ilk olarak hizmet görmesini sağlar. HTB'de düşük prio numarası daha yüksek öncelik anlamına gelir.

Jitter Ölçümüyle SLA Doğrulama

Doğrulamak için pings veya UDP üzerinden iperf3 kullanarak sentetik VoIP trafiği üretirim, ardından jitteri ölçerim. RTP benzeri paketleri yakalamak ve chegouzamanı farkı varyansını hesaplamak için küçük bir betikle tcpdump kullanırım:

# UDP 5004 bağlantı noktasını yakala (örnek RTP portu)
tcpdump -i eth0 -w voip.pcap udp port 5004

Ardından tshark ile analiz yaparım:

tshark -r voip.pcap -Y udp -T fields -e frame.time_relative | \
awk '{if (NR>1) print $1-prev; prev=$1}' | \
stats  # basit awk tabanlı min/max/avg/stddev kullanılarak

VoIP için tek yönlü jitter 30ms'in altında kabul edilebilir; 10ms'in altında iyi sayılır. tc yapılandırmasından önce ve sonra bu testi çalıştırarak iyileşmeyi gösteririm. Jitter artarsa, EF sınıfının aç bırakıp bırakmadığını kontrol ederim—ceil oranını doğrularım ve başka bir sınıfın 과도하게 bant genişliği alıp almadığını kontrol ederim.

IPv6 komşu keşfi hakkındaki önceki yazımda da belirttiğim gibi, düzenli izleme gerilemeleri erken yakalar. EF sınıfı düşüş sayacının artması durumunda uyarı almak için cron üzerinden günlük tc istatistiklerini kaydederim.

Yaygın Hatalar

Sık rastlanan bir hata, işaretlemenin yanlış yönde yapıl olmasıdır. DSCP, LAN'dan WAN'a giden paketlerde ayarlanmalıdır. Routerınız NAT yapıyorsa, NAT'tan önce işaretleme yapmalı veya doğru arayüzde -t mangle -A POSTROUTING kullanmalısınız. Başka bir hata da bazı ISP'lerin kenarlarında DSCP'i yeniden işaretlemeleridir—EF'nin hayatta kalıp kalmadığını görmek için kendi AS'nız dışındaki bir VPS ile test yapmalısınız.

Ayrıca, HTB açıkça prio 0 ayarlanmazsa varsayılan olarak classid'i öncelik olarak kullanır; bu beklentileri ters çevirebilir. Her zaman prio'yi açıkça tanımlayın.

Bu kurulumla, SIP çağrısı kurulum sürelerinde düşüş ve izleme araçlarında MOS skorlarında iyileşme gözlemledim. Büyüleyici değil, ama doğru DSCP işaretleme ve kuyruklama, paylaşılan bağlantılarda VoIP için mücadele şansı verir.

Kapak görseli: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/6038427/photo-image-public-domain-technology-line