Bant genişliği yönetimi konusunda RouterOS’un en güçlü ama aynı zamanda en yanlış anlaşılan aracı queue tree’dir. Simple queue ile başlamak kolaydır; sürükle-bırak, IP yaz, hız sınırla, biter. Ama gerçek bir ofiste 80 kullanıcı, 4 farklı uygulama sınıfı, 1 Zoom konferansı ve 1 gecelik veritabanı yedeği aynı anda hat üzerinde dans ettiğinde simple queue’nun ipi kopar. İşte burada queue tree devreye girer — ve onu doğru kurmak için biraz HTB (Hierarchical Token Bucket) matematiği bilmek şart. Bu yazıda HTB’nin altında yatan tokenleri, burst hesaplarını, mangle paket işaretleme zincirini ve queue tree dallarının nasıl tasarlandığını adım adım anlatıyorum. Sahada test edilmiş örnek konfigürasyonlarla bitiriyorum; özellikle hibrit çalışma düzenine geçen ofisler için video konferans + dosya yedekleme + oyun trafiğinin nasıl barıştırılacağına odaklanıyorum.

Önce Doğru Soruyu Sormak: Hangi Trafiği Niye Yönetiyorum?

“Queue tree kuracağım” demek araç odaklı düşüncedir. Doğru başlangıç, iş gereksinimini netleştirmektir. Sahada müşterilerime sorduğum üç temel soru şunlardır:

• Hangi trafiğin latencyi hassastır? (VoIP, video konferans, online oyun)
• Hangi trafiğin throughput‘u kritiktir ama gecikmesi tolere edilebilir? (Yedekleme, büyük dosya transferi)
• Hangi trafik best-effort kategorisindedir? (Web browsing, sosyal medya, yazılım güncellemeleri)

Bu üç sınıfı belirlemeden queue tree kurmak, ne kadar trafiği nereye yönlendirdiğini bilmeden kavşağa trafik lambası dikmek gibidir.

HTB’nin Altındaki Matematik: Token Bucket Modeli

RouterOS queue tree, Linux’un HTB qdisc’inin uyarlanmış halidir. HTB’nin temelinde token bucket kavramı vardır: her sınıfın bir kovası vardır, kova belirli bir hızla doldurulur (limit-at, max-limit), her paket çıktığında o boyutta token harcanır. Önemli kavramlar:

limit-at (Garanti Edilen Hız / CIR)

Bu, sınıfın garanti aldığı minimum hızdır. Hat ne kadar dolu olursa olsun, bu sınıf en az bu hıza erişir. Toplamda tüm child sınıfların limit-at değeri, parent max-limit değerini aşamaz; aksi takdirde sistem garantilerine uyamaz ve queue tree’niz “mantıksal olarak tutarsız” olur.

max-limit (Tavan Hızı / PIR)

Hat boştayken sınıfın çıkabileceği maksimum hız. Hat doluysa, bu hıza erişmek için diğer sınıfların kullanmadığı banttan faydalanır.

burst-limit, burst-threshold, burst-time

Kısa süreli “boost” mekanizması. burst-time içinde ortalama trafik burst-threshold‘un altında kaldığı sürece, sınıf burst-limit hızına çıkabilir. Web browsing için ideal: sayfa açılışında 10 Mbps boost, sürekli kullanımda 4 Mbps’a düşer.

priority (1-8)

Düşük sayı yüksek öncelik. 1 en yüksek (VoIP), 8 en düşük (yedekleme). Hat dolduğunda priority 1 paketler ilk geçer. Bu sayı sadece sınıflar aynı parent altındaysa karşılaştırılır; farklı dallarda anlamı yoktur.

Pratik Bir Hesap: 100 Mbps Hattı Bölüştürmek

Diyelim 100/100 Mbps fiber hattınız var ve şu sınıfları tanımladınız:

Toplam limit-at: 20+15+30+10+5 = 80 Mbps — bu sayı hattın kapasitesinin (100 Mbps) altında olmalı; aksi halde garantiler tutmaz. Sahada hep “limit-at toplamı hattın %80’ini geçmesin” kuralını uygularım. %20 buffer, hat anomalileri ve TCP retransmit overhead için ayrılır.

Mangle ile Paket İşaretleme: Queue’dan Önce Yapılması Gereken

Queue tree, mangle tarafından işaretlenmiş paketleri sınıflandırır. Yani önce paketleri marketing yapmalısın. Tipik bir mangle zinciri:

/ip firewall mangle
# 1. CONNECTION-MARK: Bağlantıyı işaretle (sadece NEW state'te)
add chain=prerouting action=mark-connection 
    new-connection-mark=voip-conn 
    protocol=udp dst-port=3478,3479,5004-5008,8801-8810 
    connection-state=new comment="Zoom UDP ports"

add chain=prerouting action=mark-connection 
    new-connection-mark=teams-conn 
    protocol=udp dst-port=3478-3481,50000-50019 
    connection-state=new comment="MS Teams"

add chain=prerouting action=mark-connection 
    new-connection-mark=erp-conn 
    protocol=tcp dst-address=10.0.50.10 dst-port=1521,1433 
    connection-state=new comment="Oracle/MSSQL"

add chain=prerouting action=mark-connection 
    new-connection-mark=backup-conn 
    protocol=tcp dst-port=873,22 src-address=10.0.30.0/24 
    connection-state=new comment="rsync/SFTP backup VLAN"

# 2. PACKET-MARK: Connection'dan paket marka türet (bütün state'lerde)
add chain=prerouting action=mark-packet 
    new-packet-mark=voip-pkt connection-mark=voip-conn passthrough=no
add chain=prerouting action=mark-packet 
    new-packet-mark=teams-pkt connection-mark=teams-conn passthrough=no
add chain=prerouting action=mark-packet 
    new-packet-mark=erp-pkt connection-mark=erp-conn passthrough=no
add chain=prerouting action=mark-packet 
    new-packet-mark=backup-pkt connection-mark=backup-conn passthrough=no

Burada iki kritik incelik var:

1. Önce connection-mark, sonra packet-mark: Connection-mark yalnız connection-state=new paketlerde set edilir; performans için kritik. Packet-mark her pakete uygulanır ama connection-mark referansını kullanır — yani conntrack lookup tek seferdir.
2. passthrough=no: Paket bir kez işaretlendi mi sonraki kuralları atlar; CPU tasarrufu.

Queue Tree Dallarının Kurulumu

/queue tree
# ANA PARENT (interface)
add name=Upload parent=ether1-wan max-limit=95M
add name=Download parent=bridge max-limit=95M

# DOWNLOAD CHILD'LARI
add name=DL-VoIP parent=Download packet-mark=voip-pkt 
    limit-at=20M max-limit=40M priority=1 queue=default-small
add name=DL-Teams parent=Download packet-mark=teams-pkt 
    limit-at=20M max-limit=40M priority=1 queue=default-small
add name=DL-ERP parent=Download packet-mark=erp-pkt 
    limit-at=15M max-limit=50M priority=3 queue=default
add name=DL-Backup parent=Download packet-mark=backup-pkt 
    limit-at=10M max-limit=100M priority=7 queue=default
add name=DL-Default parent=Download packet-mark=no-mark 
    limit-at=20M max-limit=80M priority=5 queue=default

# UPLOAD CHILD'LARI (simetrik)
add name=UL-VoIP parent=Upload packet-mark=voip-pkt 
    limit-at=20M max-limit=40M priority=1 queue=default-small
# ... vb.

Dikkat: queue=default-small latency-sensitive trafik için kullanılır. PFIFO buffer’ı küçüktür (16 paket); kuyrukta bekleyiş süresi minimumdur. VoIP paketleri için bu kritik; uzun kuyrukta beklemek 100ms+ jitter doğurur.

Burst: Kullanıcı Deneyimini Değiştiren Sihirli Düğme

Burst, web browsing deneyimini dramatik şekilde iyileştirir. Şu kalıbı düşünün:

add name=DL-Web parent=Download packet-mark=web-pkt 
    limit-at=10M max-limit=30M 
    burst-limit=60M burst-threshold=20M burst-time=10s 
    priority=5 queue=default

Davranış: Kullanıcı 10 saniyelik pencerede ortalama 20 Mbps’tan az tüketmişse, bir sonraki indirme isteğinde 60 Mbps’a kadar boost alır. Tipik bir web sayfası 3-5 Mbps’lık bir burst ister, açılır, kullanıcı okumaya başlar. Bu süre içinde kova yeniden dolar. Sonuç: kullanıcı “hat çok hızlı” hisseder, oysa ortalama tüketim aynıdır.

Burst Matematiği

RouterOS burst hesabını şöyle yapar: son burst-time / 16 aralıkta ortalama trafik burst-threshold‘u aşıyor mu? Aşıyorsa burst kapalı, aşmıyorsa açık. Aralık 16’ya bölünür çünkü RouterOS scheduler her 1/16 burst-time’da bir kontrol yapar. 10sn burst-time için kontrol aralığı 625ms.

Saha Vaka: 80 Kullanıcılı Hibrit Ofiste Zoom + Veeam Backup

Kadıköy’de bir mimarlık firması müşterimiz: 80 kullanıcı, 200/200 Mbps fiber, %60 hibrit çalışıyor (3 gün ofis / 2 gün evden). Akşam 18:00’de tüm AutoCAD dosyaları NAS’a Veeam Agent ile yedekleniyor. Aynı saatte bazı ekipler hala Zoom toplantısında. Sorun: “Akşam 18:00’den sonra Zoom’da donmalar başlıyor.”

Tanı

Veeam Agent her bir kullanıcı makinesinden NAS’a TCP/445 ve TCP/873 portları üzerinden veri akıtıyor. 80 kullanıcı x ortalama 2 Mbps eş zamanlı upload = ~160 Mbps. WAN bağlantısının upload tarafı (NAS aslında WAN’a değil internal’a yazıyor ama çıkış için Veeam Cloud Connect 200 Mbps simetrik hattın upload’unu doyuruyor). Zoom paketleri kuyrukta bekleyince jitter 200ms’i geçiyor.

Çözüm

1. Veeam trafiği için yeni mangle: protocol=tcp dst-port=873,445,10000-10100 src-address=10.0.0.0/16 → backup-pkt
2. Queue tree’de UL-Backup’ı priority 7, limit-at 20M, max-limit 200M olarak ayarladık.
3. UL-VoIP’i priority 1, limit-at 40M, max-limit 80M olarak yükselttik.
4. queue=default-small ile VoIP kuyruğunda PFIFO buffer’ı küçülttük.

Sonuç: Veeam backup süresi 47 dakikadan 53 dakikaya çıktı (+%13), ancak Zoom jitter’ı 200ms’den 14ms’ye düştü. Kullanıcı şikayeti sıfırlandı. Bu, queue tree’nin temel felsefesidir: kritik trafiği koru, geri kalanı esnek bırak.

Pratik 2: ISP Senaryosu — 1Gbps PPPoE Müşteri Pool’unda QoS

Bir ISP müşterimiz CCR2116 üzerinde 1.200 PPPoE oturumu sonlandırıyor. Premium müşterilere 100 Mbps simetrik, standart müşterilere 50/20 Mbps veriyor. Sorun: bazı premium müşteriler “100 Mbps aldım ama hızım 60 Mbps’ta takılı” şikayetinde.

Tanı

Simple queue ile her PPPoE’ye 100M-100M atamışlar ama parent yok. Tüm 1.200 müşteri aynı interface’in (sfp-plus1) altında, hat 10 Gbps. Yani teoride sorun yok. Ama gece 22:00’de 850 müşteri aktif, hepsi Netflix izliyor, her biri 5-8 Mbps; toplam 4-5 Gbps. Premium müşteriler hızlı görünmesi gerekirken kuyrukta sıraya giriyor çünkü simple queue priority desteği yok.

Çözüm: Queue Tree ile Tier Yapısı

/queue tree
add name=PremiumPool parent=sfp-plus1 max-limit=3G priority=2
add name=StandardPool parent=sfp-plus1 max-limit=5G priority=5

# Her PPPoE için pcq queue, parent pool altında
add name=Premium-Down parent=PremiumPool queue=premium-pcq 
    packet-mark=premium-pkt
add name=Standard-Down parent=StandardPool queue=standard-pcq 
    packet-mark=standard-pkt

/queue type
add name=premium-pcq kind=pcq pcq-rate=100M pcq-limit=50 pcq-classifier=dst-address
add name=standard-pcq kind=pcq pcq-rate=50M pcq-limit=50 pcq-classifier=dst-address

PCQ (Per Connection Queue) burada dahidir: tek bir kural ile her IP’ye otomatik ayrı sub-queue açar. pcq-rate=100M her premium IP’ye 100 Mbps verir; toplamda parent 3Gbps’a kadar dağıtılır. Priority 2 ile premium pool, standard pool’dan önce paket gönderir. Sonuç: premium müşteriler gece bile 95+ Mbps gördü.

Oyun Trafiği: Latency Şampiyonu Bir Sınıf Nasıl Tasarlanır

Bazı müşterilerimiz internet kafe işletiyor. CS2, Valorant, League of Legends gibi oyunlarda 5ms fark “kötü oyuncu” damgası demektir. Oyun trafiği için ayrı bir sınıf önerisi:

/ip firewall mangle
add chain=prerouting action=mark-connection 
    protocol=udp dst-port=27000-27050 
    new-connection-mark=game-conn comment="Steam/Valve games"
add chain=prerouting action=mark-connection 
    protocol=udp dst-port=2099,5222,5223,8393-8400 
    new-connection-mark=game-conn comment="LoL/Valorant"
add chain=prerouting action=mark-packet 
    connection-mark=game-conn new-packet-mark=game-pkt passthrough=no

/queue tree
add name=DL-Game parent=Download packet-mark=game-pkt 
    limit-at=10M max-limit=50M priority=1 
    queue=game-fq

Burada queue=game-fq özel oluşturulmuş bir queue type. SFQ (Stochastic Fair Queueing) kuyruğunda her oyun bağlantısı eşit pay alır; tek bir kullanıcı kuyruğu doyuramaz. pcq-burst-rate ayarı ile ilk birkaç paket boost alır, bu da oyun “connection established” anını hızlandırır.

Yaygın Hatalar ve Doğru Pratikler

Hata 1: Mangle’da connection-state=new Kullanmamak

Connection-mark kuralında connection-state=new yoksa, her gelen paket için conntrack lookup yapılır ve mark yeniden set edilir. CCR2004’te bu hatayı düzelttiğimde CPU %35’ten %18’e düştü (800Mbps trafik altında).

Hata 2: Parent Olmadan Queue Tree

Parent global bırakılırsa queue tree fiziksel interface ile sınırlanmaz; başka interface’lere taşma olur. Her zaman parent=interface_name kullanın.

Hata 3: max-limit = limit-at

Bu durumda burst ve esneklik olmaz; queue tree kullanmak için sebep kalmaz. max-limit daima limit-at‘tan büyük olmalıdır (en az 1.5x).

Hata 4: priority Sayısını Yanlış Anlamak

Çok kişi “öncelik 8 daha iyi sanmıştım” hatasını yapar. Tam tersi: 1 en yüksek, 8 en düşük.

Hata 5: PCQ Classifier Yanlış

Download için pcq-classifier=dst-address, upload için pcq-classifier=src-address kullanılır. Karıştırılırsa tüm trafik tek bir sub-queue’ya düşer ve fair queueing çalışmaz.

İzleme: Queue Tree’nin Çalıştığını Nasıl Anlarsın?

Konfigürasyonu yazdıktan sonra çalışıp çalışmadığını kanıtlamadan canlıya almayın. Üç araç:

1. /queue tree print stats: Her queue’nun byte/packet counter’ı. 0 ise mangle paketi işaretlemiyor demektir.
2. /tool torch interface=ether1-wan: Canlı paket akışı; hangi sınıfa düştüğünü görmek için.
3. Grafana + SNMP: Her queue için bandwidth grafiği. 1.3.6.1.2.1.31.1.1.1.6/.10 OID’leri queue-specific değildir; mangle-based custom OID için script gerekir.

SSS: Queue Tree Hakkında En Sık Sorulan

Simple queue ile queue tree birlikte kullanılabilir mi?

Teknik olarak evet, ama önerilmez. İkisi de aynı interface üzerinde çalışırsa hesap çakışır ve davranış öngörülemez olur. Birinden birini seçin.

PCQ vs HTB ne zaman kullanılır?

PCQ otomatik per-IP sub-queue’lar açtığından ISP/çoklu kullanıcı senaryolarında idealdir. HTB sınıf bazlı kontrol ister; ofis uygulama sınıflandırması için uygundur.

Queue tree CPU’ya ne kadar yükler?

İyi yazılmış 20-30 kurallık bir queue tree, CCR2004’te 800Mbps trafikte CPU’ya %3-5 ek yük getirir. Kuralların sayısı değil, mangle’ın doğruluğu belirleyicidir.

Burst neden bazen çalışmıyor?

Çoğunlukla burst-threshold > limit-at olmadığından. Threshold limit-at’ın 1.5-2 katı olmalıdır.

Hangi interface’i parent yapayım?

Download için iç bridge, upload için WAN interface. Bu Queue tree’nin egress’te çalıştığını unutmayın; download için “çıkış” iç bridge’dir.

RouterOS 7’de queue tree değişti mi?

Çekirdek davranış aynı; eklenen özellikler: yeni queue type’ları (CAKE deneysel), REST API ile dinamik yönetim, daha iyi PCQ metrikleri.

Çoklu WAN Senaryosunda Queue Tree: PCC ve Mark-Routing Birleşimi

Birden fazla WAN bağlantısı olan ofislerde queue tree, mark-routing ile birlikte tasarlanmalıdır. Tipik bir hibrit senaryoda 200 Mbps fiber + 100 Mbps yedek xDSL hattınız vardır; bant genişliği yönetimi her iki hat için bağımsız işlemelidir. Yapılması gereken:

/ip firewall mangle
add chain=prerouting action=mark-routing in-interface=bridge 
    new-routing-mark=wan1-route packet-mark=voip-pkt
add chain=prerouting action=mark-routing in-interface=bridge 
    new-routing-mark=wan2-route packet-mark=backup-pkt

/queue tree
add name=WAN1-Upload parent=ether1-wan1 max-limit=190M
add name=WAN2-Upload parent=ether2-wan2 max-limit=90M

add name=WAN1-VoIP parent=WAN1-Upload packet-mark=voip-pkt 
    limit-at=40M max-limit=100M priority=1
add name=WAN2-Backup parent=WAN2-Upload packet-mark=backup-pkt 
    limit-at=20M max-limit=90M priority=7

VoIP trafiği daima ana fiber hattan; yedekleme trafiği daima yedek hattan akar. Birbirine girmez; queue tree her hat için bağımsız hesap tutar. Sahada bu mimariyi 2024’te 4 farklı müşteride uyguladık, hiçbirinde failover sırasında VoIP kesintisi yaşanmadı.

Wireshark + Torch ile Gerçek Zamanlı Doğrulama

Queue tree kuralları yazıldıktan sonra “çalışıyor mu?” sorusunu cevaplamanın en hızlı yolu MikroTik Torch + Wireshark capture kombinasyonudur. Adımlar:

1. WinBox’tan Tools > Torch’u açın, ether1-wan seçin, source/destination/port kolonlarını aktif edin.
2. Aynı anda kullanıcı bir Zoom toplantısı başlatsın.
3. Torch’ta UDP 8801 portuna giden trafiği izleyin; bps sütununda 1.5-2.5 Mbps görmelisiniz.
4. /queue tree print stats where name=UL-VoIP komutuyla aynı miktarın queue’da sayıldığını teyit edin.
5. Aynı anda büyük bir dosyayı NAS’a yükleyin; queue tree print stats’ta backup-pkt counter’ı artmalı, VoIP counter’ı stabil kalmalı.

Bu doğrulama, mangle’ın paketleri doğru sınıflandırdığını ve queue tree’nin doğru parent altında çalıştığını kanıtlar. Atlanırsa “kurdum ama çalışmıyor” şikayetlerinin kaynağı bulunamaz.

Sonuç: Queue Tree Sanat Değil, Disiplin

Queue tree iyi konfigüre edildiğinde kullanıcılarınız hattınızın daha hızlı olduğunu hissederler — oysa fiziksel kapasite aynıdır. Önce iş gereksinimini sınıflandırın, sonra HTB matematiğine uygun limit-at/max-limit hesaplayın, mangle’ı doğru zincirle yazın, queue tree’yi parent-child mantığıyla kurun. Saha pratiğim şunu söylüyor: 30 dakikalık iyi planlanmış queue tree, 3 saatlik panik QoS’tan daha iyidir. Bu yazıyı bitirdikten sonra mevcut konfigürasyonunuzu export edin, üç farklı sınıfa (VoIP / iş / best-effort) bölün, yukarıdaki şablona uyarlayın. Sonuçları ölçtüğünüzde, hat yatırımı yapmadan kapasite arttırdığınızı göreceksiniz.

Devam Eden Konular

Bu konuyla doğrudan ilişkili pratik rehberlerimiz:

• MikroTik RouterBoard Serisi: 2026'da Hangi Model Kime Uygun? Detaylı Karşılaştırma
• MikroTik Üzerinde Hız Testi: BTest, Bandwidth Monitör ve İperf3 ile Performans Ölçümü
• MikroTik CCR Serisi 2026: Hangi ISP İçin Hangi Model?
• MikroTik Cloud Hosted Router (CHR): VMware, Proxmox, AWS ve Hetzner Üzerinde Dağıtım

Kaynaklar ve Daha Fazla Bilgi

Bu yazıdaki konuları derinleştirmek için aşağıdaki otoriter kaynaklara başvurabilirsiniz:

• MikroTik Resmi Dökümantasyon (RouterOS Wiki)
• MikroTik Resmi Forumu
• MikroTik Resmi Sitesi
• Wikipedia: Network Address Translation
• Wikipedia: OSI Model