Mangle e Queue Tree no Mikrotik: como limitar velocidade por plano

O rate-limit direto no PPP Profile resolve o básico: cliente contratou 100 Mega, o Mikrotik entrega até 100 Mega. Só que essa abordagem simples trata todo o tráfego daquele cliente como uma coisa só, sem distinguir download de upload de forma fina, sem priorizar um tipo de tráfego sobre outro e sem dar visibilidade real de quanto cada perfil está consumindo em conjunto. Para um provedor com poucas dezenas de clientes isso raramente incomoda. Para quem já passou de algumas centenas e começa a receber reclamação de lentidão em horário de pico, entender Mangle e Queue Tree deixa de ser luxo técnico e vira ferramenta de diagnóstico.

O que cada peça faz

• Mangle: marca o tráfego (connection mark e depois packet mark) com base em critério — pode ser por interface, por faixa de IP, por protocolo. É o "crachá" que identifica de que grupo aquele pacote faz parte antes de chegar na fila.
• Queue Tree: organiza o tráfego marcado em uma hierarquia de filas, com limites e prioridades próprias para cada ramo. É onde a banda de fato é distribuída e limitada.

A combinação das duas permite algo que o rate-limit simples não faz bem: criar uma fila-pai por plano de internet (por exemplo, uma fila "100 Mega" e outra "300 Mega") e, dentro dela, sub-filas por cliente — isso dá visibilidade agregada por plano e, ao mesmo tempo, mantém o limite individual de cada assinante.

Quando vale a pena migrar do rate-limit simples

Três sinais indicam que chegou a hora:

1. Você não consegue responder "quantos clientes do plano X estão consumindo banda agora" sem abrir um por um.

2. Horário de pico degrada a rede como um todo, e falta uma forma de priorizar tráfego sensível a latência (VoIP, jogos) sobre downloads em massa.

3. A revenda de link está no limite e é preciso garantir que nenhum cliente sozinho consuma banda desproporcional ao contratado, mesmo com rajadas.

Um cuidado real: Queue Tree mal configurado degrada performance

Queue Tree em excesso de granularidade — uma fila específica para cada cliente sem necessidade, com HTB mal dimensionado — consome CPU da Routerboard e pode, paradoxalmente, piorar a latência geral da rede em vez de melhorar. A prática mais segura é começar com filas por plano (agregadas) e só descer para o nível de cliente individual quando realmente precisar de controle fino, evitando montar uma árvore gigante que ninguém mais entende seis meses depois.

Documentar a estrutura evita o "só quem configurou entende"

Uma armadilha comum: o dono ou o técnico que montou a árvore de Mangle e Queue Tree sai de férias (ou da empresa) e ninguém mais sabe explicar por que aquela regra existe. Vale documentar, mesmo que de forma simples, o que cada mark representa e por que aquela fila foi criada daquele jeito — isso poupa muita dor de cabeça na hora de debugar um problema de banda meses depois.

Onde entra o sistema de gestão

Configurar QoS resolve o tráfego dentro do Mikrotik, mas não resolve o outro lado: saber, no cadastro do cliente, qual plano ele contratou e garantir que o profile aplicado bate com o que está sendo cobrado. O ZISP mantém o cadastro de planos e clientes sincronizado com o Mikrotik via API do RouterOS, então a mudança de plano no sistema já reflete no profile aplicado, sem depender de alguém lembrar de ajustar a fila manualmente depois do reajuste. Para ver como funciona na prática, veja em sistema.zisp.com.br.