You are on page 1of 23

Mecanismos de QoS em Linux tc – Traffic Control

Edgard Jamhour

Edgard Jamhour

Este módulo descreve os principais mecanismos de QoS disponíveis no kernel do Linux. Para utilizar esses mecanismos, é necessário criar uma política coerente de QoS, que determina como os pacotes recebidos serão classificados, tratados e encaminhados pelo S.O. A configuração de QoS no linux é baseada no utilitário de comando de linha denominado tc (traffic control). Existem algumas outras tentativas de construir outras interfaces de administração do QoS do Linux, mas a maioria delas usa o próprio tc para gerar as configurações de QoS. Por isso, esse módulo irá se focar apenas no uso do tc.

Algumas das figuras utilizadas nessa apostila foram extraídas do tutorial: http://www.opalsoft.net/qos/DS.htm

Controle de Tráfego (TC)
Camadas Superiores (TCP, UDP) S Elementos do TC Policiamento Destino é Interno? N Rotamento Enfileiramento na Saída

Interface de Entrada

Interface de Saída

Edgard Jamhour

O Linux possui implementado em seu kernel um conjunto de algoritmos para controle de tráfego, genericamente denominados como TC (Traffic Control). Esses algoritmos permitem modificar a forma como os pacotes recebidos pelo sistema operacional são encaminhados pela rede. Basicamente, o controle de tráfego é implementado através de dois mecanismos: 1) Pacotes são policiados na entrada. Através do policiamento, pacotes indesejáveis são descartados. 2) Pacotes são enfileirados na respectiva interface de saída. Os pacotes armazenados nas filas podem ser atrasados, marcados, descartados ou priorizados As políticas de QoS do Linux são criadas de forma independente para cada interface do equipamento. Em qualquer caso, deve-se sempre levar em conta que o policiamento é feito para pacotes encaminhados para uma data interface e, o controle de tráfego propriamente dito, para os pacotes que são enviados pela interface. Por exemplo, em um roteador, cada interface controla o QoS do tráfego em um único sentido. Se um roteador possui uma interface para a LAN interna e outra WAN para Internet, então as políticas de QoS na interface LAN controlam o que é transmitido para Internet (upload) e na interface WAN o que é recebido (download). Para ter acesso as funções de controle de tráfego, o Linux disponibiliza um utilitário de comando de linha denominado tc. O tc permite criar uma política de QoS, que define a seqüência de algoritmos que são aplicados para tratamento do tráfego. A política de QoS é definida cascateando-se elementos lógicos que representam por quais etapas os pacotes serão encaminhados, antes de serem entregues a interface de saída.

c) Filters utilizados para policiar e classificar os pacotes e atribuí-los as classes.Política de QoS e Elementos do TC Qdisc da classe Qdisc principal Edgard Jamhour Os elementos definidos pelo tc são os seguintes: a) Queuing Disciplines = qdisc algoritmos que controlam o enfileiramento e envio de pacotes. Os filtros são os classificadores. pacotes de dados para uma classe e pacotes de VoIP para outra). A quantidade de classes é variável e depende da quantidade de tratamentos diferenciados que serão implementados pelo tc. É ela quem define a estratégia geral de QoS implementada pelo tc e. se a política quiser criar tratamentos diferenciados para os dados. de qual das classes o pacote será escolhido para envio. Sua função é encaminhar os pacotes para sua respectiva classe (por exemplo. se a política de QoS quer apenas diferenciar o tratamento de tráfego de VoIP e dados. A figura ilustra uma estrutura típica para controle de tráfego. Observe que as qdiscs são usadas em duas situações: a qdisc principal e as qdiscs associadas as classes. Por exemplo. A qdisc principal é obrigatória. Contudo. d) Policers utilizados para evitar que o tráfego associado a cada filtro ultrapasse limites pré-definidos. mais classes precisarão ser criadas. A função das qdiscs de classes é definir quais pacotes da classe estão prontos para serem transmitidos. bastariam apenas duas classes. em especial. . b) Classes representam “entidades de classificação de pacotes”.

. não precisando ser definidos em ordem. onde N é um número inteiro qualquer. Observe que as classes são filhas da qdisc principal (conforme observado pelo atributo parent). As classes são identificadas por um código classid. Esse código precisa seguir o seguinte formato específico: (handle do elemento pai):(código da classe). Contudo. O segundo conjunto de comandos da figura cria duas classes com taxas diferentes. No exemplo. Todas as qdiscs são definidas por um tipo de algoritmo que define como o controle de tráfego é efetuado. O primeiro comando da figura cria a qdisc principal (root) associada a interface eth0. É importante observar que as políticas de controle de tráfego são específicas para cada uma das interfaces disponíveis no equipamento. O funcionamento do htb será discutido na seqüência deste módulo. htb (hierachical token bucket) é o algoritmo utilizado pela qdisc. Cada comando tc é responsável por criar um dos elementos da política de controle de tráfego desejada. não podem haver elementos de política com classid ou handle repetidos. e são do mesmo tipo htb. As classes do tipo htb exigem um parâmetro que define a taxa com que os pacotes armazenados em cada classe serão transmitidos. O número depois dos “:” pode ser qualquer. Todas as qdiscs precisam ser identificadas por um número denominado handle.Comandos tc: Criar a qdisc principal > tc qdisc add dev eth0 root handle 1:0 htb > tc class add dev eth0 parent 1:0 classid 1:1 htb rate 500Kbit > tc class add dev eth0 parent 1:0 classid 1:2 htb rate 300Kbit Edgard Jamhour A configuração da política de QoS é feita através de um script formado por uma seqüência de comandos tc. O identificador da qdisc tem sempre o formato N:0. as classes são nomeadas como 1:1 e 1:2 porque elas são filhas da qdisc de handle 1:0. No exemplo.

O segundo conjunto de comandos cria os filtros. as qdisc precisam ser identificadas por um handle que segue o formato N:0. pois é necessário criar regras identificadas por índices com o iptables. de forma similar ao que é feito com endereços IP. o uso do iptables junto com tc é menos recomendado. criando um buffer com capacidade máxima de 10 pacotes. ip de destino. O tc permite utilizar dois tipos de filtros: o u32 e o iptables. tos. podem ser definidos diretamente no comando tc. Caso contrário. No exemplo. e encaminhado para o código da classe definido pelo flowid. independente da regra criada. • match ip <valor campo> <máscara>: indica qual o critério utilizado para classificar um pacote. a próxima regra é testada.Comandos: Criar as qdisc das classes > tc qdisc add dev eth0 parent 1:1 handle 10:0 pfifo limit 10 > tc qdisc add dev eth0 parent 1:2 handle 20:0 pfifo limit 10 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip protocol 0x06 0xff flowid 1:1 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip protocol 0x11 0xff flowid 1:2 Edgard Jamhour O primeiro conjunto de comandos na figura cria as qdiscs associadas a cada classe. dscp. Os filtros u32 são definidos da seguinte forma: • protocol ip u32: indica que o filtro do tipo u32 será utilizado. . e aportar esses índices usando o tc. porta de destino). Os filtros u32. tipo de protocolo. O código 0x06 corresponde ao TCP e o código 0x11 ao código UDP (conforme norma do IANA). Geralmente. etc) ou tcp/udp (porta de origem. A máscara é usada da seguinte forma: Se <campo do pacote> E-BINÁRIO <máscara> = <valor do campo> então o pacote é classificado pela regra. O classificador u32 utiliza máscaras para todos os códigos dos campos. As qdiscs de classe determinam em que ordem os pacotes já armazenados na fila serão removidos. as qdiscs implementam uma simples política do tipo FIFO (First-In First-Out). o critério é baseado unicamente no campo protocol (tipo de protocolo) do cabeçalho IP. por outro lado. Novamente. Observe que cada qdisc é filha das classe a ela associada (conforme indicado pelo parâmetro parent). a regra é definida em termos dos campos do cabeçalho ip (ip de origem. Esses parâmetros são repetidos em todos os comandos tc que usam o filtro u32. Apesar de ser mais familiar. Nesse caso.

Se o roteador testar se um pacote pertence a classe 1:2 primeiro. Os demais pacotes TCP recebidos por esse host vão para classe 1:2". Os filtros de prio menor são testados sempre antes dos maiores. nenhum pacote será enviado a classe 1.1. Os demais pacotes TCP recebidos por esse host vão para classe 1:2 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip protocol 0x06 0xff match ip sport 80 0xfff match ip dst 192.1/24 flowid 1:2 Edgard Jamhour Os filtros u32 são analisados em seqüência. provavelmente o último filtro a ser criado será testado primeiro.0.1/24 vão para classe 1:1.168. uma política de QoS pode definir filtros sobrepostos. Se dois filtros tem o mesmo prio.0.1/24 vão para classe 1:1.0.168. Contudo. . Geralmente.0. Para evitar que isso aconteça é necessário colocar os filtros em ordem.168. Isso é feito utilizando o atributo prio disponível para os filtros u32. Observe que todos os pacotes enviados a classe 1:1 são na verdade um subconjunto dos pacotes enviados a classe 1:2. como os da seguinte política: "Pacotes HTTP recebidos por 192.168. de forma semelhante as regras de um firewall. e utilizar o valor de prio para garantir uma ordem correta de interpretação dos filtros. é melhor nunca confiar nessa premissa. listando os filtros mais específicos antes dos mais genéricos.Seqüência de filtros u32 • Pacotes HTTP recebidos por 192.1/24 flowid 1:1 tc filter add dev eth0 parent 1:0 protocol ip prio 2 u32 match ip protocol 0x06 0xff match ip dst 192.

raramente é instalado pelas distribuições do Linux. Geralmente é melhor criar um script com todos os comandos tc ao invés de digitá-los diretamente via console. Isto é. quando um novo elemento é criado. as estatísticas associadas aos filtros são também mostradas. sem necessidade de apagá-la. . Essa política é sobreposta. As estatísticas são muito dependentes do tipo de qdisc criada. o Linux utiliza uma política do tipo FIFO default associada a cada interface. é necessário apagar todos os elementos da política antes de executar os script novamente.Verificando as regras com o tc • tc [-s] qdisc/class/filter show dev eth0 – mosta as qdisc/class/filter associadas a interface – –s mostra as estatísticas do uso da qdisc/class/filter • tc qdisc del root dev eth0 – limpa as regras de QoS • iplink show – mostra a classe default associada a interface Edgard Jamhour As políticas criadas pelo tc ficam em memória até que o computador seja reiniciado. As estatísticas descrevem a quantidade de pacotes que foi classificada por cada filtro. O seguinte comando deve ser incluído no início do script para garantir que apenas a política do script será utilizada pelo sistema operacional: tc qdisc del root dev eth0 Normalmente. as estatísticas associadas as qdiscs são mostradas. Assim com as qdiscs. Como os comandos são acumulativos. Em alguns sistemas o comando iplink show permite ver a classe default associada a interface. Se o atributo opcional [-s] for utilizado. Se o atributo opcional [-s] for utilizado. mas geralmente contém a quantidade de pacotes que foi processada por cada qdisc. os anteriores não são eliminados. contudo. tc [-s] class filter dev eth0: Mostra todas os filtros e policiadores associados a interface eth0. as estatísticas associadas as classes são mostradas. pois os comandos tc são acumulativos. quando se cria uma nova classe “root”. É possível listar todos os elementos tc em memória através dos seguintes comandos: tc [-s] qdisc show dev eth0: Mostra todas as qdiscs associadas a interface eth0. e descrevem a quantidade de pacotes processada por cada classe. as estatísticas são muito dependentes do tipo de classe criada. tc [-s] class show dev eth0: Mostra todas as classes associadas a interface eth0. Se o atributo opcional [-s] for utilizado. O iplink.

Queueing Disciplines • • • • • • • • FIFO: First In First Out SFQ: Stochastic Fair Queuing TBF: Token Bucket Flow DS_MARK: Diff-Serv Marker RED: Random Early Detection PRIO: Priority Queue [CBQ: Class-Based Queueing] = OBSOLETA HTB: Hierarquical Token Bucket Edgard Jamhour O efeito de uma política de QoS é determinada pelo tipo da queuing discipline (qdisc). CBQ: (Class-Based Queueing): coordena a ordem em que as filas são servidas segundo um esquema hierárquico. . o atraso médio experimentado pelos pacotes As seguintes qdiscs são usadas para controlar o escalonamento de múltiplas classes filhas: PRIO (Priority Queue): coordena a ordem em que as filas são servidas segundo um esquema de prioridade (injusto). que indica que os pacotes serão servidos na mesma ordem que chegaram. RED (Random Early Detection): algoritmo de descarte preventivo para diminuir o tamanho da fila e. consequentemente. As seguintes qdiscs são usadas para controlar o escalonamento de uma única classe: FIFO (First In First Out): implementa a política First-In First-Out. HTB: (Hierarquical Token Bucket): coordena a ordem em que as filas são servidas segundo um esquema hierárquico. mas cada uma delas pode ser desabilitadas individualmente durante compilação do kernel. Conforme dissemos. SFQ (Stochastic Fair Queuing): procura equilibrar a quantidade de banda disponível para cada fluxo em uma fila. DS_MARK (Diff-Serv Marker): efetua a marcação dos campos DSCP dos pacotes para implementar a metodologia Diffserv. TBF (Token Bucket Flow): permite controlar a taxa com que os pacotes de uma fila são servidos. Substituto do CBQ Todas as qdiscs acima está definidas para o kernel do Linux sem adição de patches. algumas qdiscs são utilizadas para controlar o escalonamento de múltiplas classes e outras para controlar a saída de tráfego de uma única classe.

Na abordagem FIFO. pois não existe forma de equilibrar a quantidade de banda alocada a cada fluxo. denominado limit. . se forem misturados pacotes TCP e UDP em uma mesma fila. Observe que essa qdisc solicita apenas um parâmetro. é possível que os pacotes UDP dominem o uso da banda. A figura ilustra a criação da qdisc para as duas situações: o primeiro comando cria a classe como root e o segundo comando cria a qdisc FIFO como uma classe filha. O uso da FIFO como root é a implementação default da política QoS do Linux. A qdisc do tipo FIFO implementa um procedimento de encaminhamento em que os pacotes são servidos na mesma ordem em que chegam a interface do roteador ou a uma classe. que determina a quantidade máxima de pacotes que podem aguardar na fila antes que sejam descartados. As qdisc FIFO podem ser criadas como root (default) ou associadas as classes. independente do fluxo ao qual eles pertencem.FIFO: First In First Out > tc qdisc add dev eth0 root handle 1:0 pfifo limit 10 > tc qdisc add dev eth0 parent 1:1 handle 10:0 pfifo limit 10 Edgard Jamhour A figura ilustra o princípio do algoritmo FIFO.

Por exemplo. As classes são nomeadas de acordo com o código handle da qdisc. isto é. usualmente. a classe de média prioridade 1:2 e a classe de baixa prioridade 1:3. a classe de alta prioridade será 1:1. . já com as três classes e um qdisc fifo associada a cada classe. apenas como classe “root”. média prioridade e baixa prioridade. sendo usada. mas não cria os filtros. Observe que a PRIO não solicita nenhum parâmetro. O comando cria uma política completa. A classe de média prioridade é servida apenas quando a classe de alta prioridade estiver vazia. se a qdisc PRIO tiver o código 1:0. Esse tipo de escalonamento é dito injusto pois pode fazer com que as classes menos prioritárias jamais sejam servidas. Para completar a política o administrador do sistema deve criar os filtros indicando quais políticas são alocadas para cada uma das classes.PRIO: Priorização Injusta > tc qdisc add dev eth0 root handle 1:0 prio Edgard Jamhour O qdisc do tipo PRIO controla o escalonamento de múltiplas classes filhas. A classe de baixa prioridade é servida apenas quando ambas as classes superiores estão vazias. A parte inferior da figura mostra como a qdisc é criada. Essa qdisc cria automaticamente três classes: alta prioridade. O escalonamento implementado pela PRIO é uma priorização injusta. a classe de alta prioridade é servida enquanto tiver pacotes.

Esse problema pode ser evitado. caso hajam muitos pacotes associados a classe 1:1. Observe que o primeiro comando cria as três classes e também as qdiscs do tipo FIFO associadas a cada classe (de forma automática). O segundo comando substitui a qdisc FIFO associada a classe 1:1 por outra do tipo TBF. Esse mecanismo é usado para evitar que um fluxo de pacotes pequenos seja tratado da mesma forma que poucos pacotes grandes. utiliza-se o MTU de um quadro Ethernet (1500 bytes). suponha que a qdisc principal seja do tipo PRIO. gerando as classes 1:1 (alta prioridade). O primeiro caso consome mais recursos do roteador. A seqüência de comandos para implementar essa política é ilustrada na figura. 1:2 (média prioridade) e 1:3 (baixa prioridade). o escalonamento PRIO é injusto. Geralmente.5mbit burst 5k latency 70ms peakrate 1mbit minburst 1500 Edgard Jamhour A qdisc do tipo TBF (Token Bucket Function) é usada para controlar a banda de uma única classe. Por exemplo. Os parâmetros usados pelo TBF são os seguintes: rate: taxa média atribuída a classe burst: tamanho do balde (em bytes). se uma qdisc TBF limitar a banda da classe 1:1. . e por isso é penalizado. a quantidade de fichas consumidas do balde contabilizará o valor de minburst.TBF: Token Bucket Function > tc qdisc add dev eth0 root handle 1:0 prio > tc qdisc add dev eth0 parent 1:1 tbf rate 0. para controlar a duração das rajadas latency: tempo máximo que um pacote pode ficar na fila aguardando uma ficha peakrate: taxa de pico máxima das rajadas (em kbps ou mpbs) minburst: quantidade mínimas de bytes contabilizada por pacote. pois as classes 1:2 e 1:3 podem nunca ser servidas. Como vimos. Mesmo que um pacote com tenha tamanho inferior ao minburst.

pois depende da quantidade de fluxos que atravessa uma interface ou uma classe do rotedor. de maneira que a quantidade de banda atribuída a cada fila é equilibrada. Esse tipo de algoritmo cria automaticamente múltiplas filas para distribuir o fluxo de pacotes. Um fluxo de pacotes é determinado pela tupla (ip_origem:porta_origem – ip_destino:porta_destino). utilizando a estratégia de round-robin. A quantidade de filas SFQ nessa abordagem é variável. cada vez que ela é servida. O valor default é 1 = maximum sized packet (MTU-sized). que readapta as filas para uma nova quantidade de fluxos. o que determina que um pacote é enviado por completo de cada fila. quantum: determina a quantidade de pacotes removidos da fila SFQ por interação. O valor recomendado para esse parâmetro é 10s.SFQ: Stochastic Fair Queuing > tc qdisc add dev eth0 root handle 1:0 sfq perturb 10 > tc qdisc add dev eth0 parent 1:1 handle 10:0 sfq perturb 10 Edgard Jamhour O algoritmo SFQ (Stochastic Fair Queuing) controla a forma como os pacotes de uma classe ou interface são encaminhados. As filas SFQ são servidas um pacote de cada vez. Esse algoritmo é controlado por dois parâmetros: perturb: que determina o intervalo para recálculo do algoritmo de hashing. .

A rede A recebeu 2 Mbps de banda garantida.HTB: Hierarquical Token Bucket Link (3 Mbps) 200. reduzindo sua latência (prio 0 é a maior) Para ilustrar como o HTB é utilizado considere o exemplo da figura. a classe root precisa ser do tipo htb. cuja implementação ineficiente não é considerada mais recomendada. O mesmo raciocínio se aplica para http e outros tipos de tráfego.2. Para criar uma política HTB.0/24 Subrede B (rate 1 Mbps) (ceil 1 Mbps) telnet (rate 200 kbps) (ceil 2 Mbps) http (rate 800 kbps) (ceil 2 Mbps) outros (rate 1 Mbps) (ceil 2 Mbps) http (rate 500 kbps) (ceil 1 Mbps) outros (rate 500 kbps) (ceil 1 Mbps) > tc qdisc add dev eth0 root handle 1: htb > tc class add dev eth0 parent 1:0 classid 1:1 htb rate rate ceil rate burst bytes [ cburst bytes ] [ prio priority ] Edgard Jamhour O algoritmo HTB permite estruturar uma hierarquia de divisão de bandas pela concatenação de classes. conforme indicado no primeiro comando da figura. mesmo que haja banda disponível no enlace (pois rate é igual a ceil). mas podem usar toda a banda da subrede caso as outras classes não estejam usando (pois o ceil é igual a capacidade total da subrede).1. O HTB é considerado substituto do CBQ (Class Base Queuing). . A rede B possui 1 Mbps de banda garantida.3. Observe que o limite das classes filhas não pode ultrapassar o rate da classe pai. e não pode ultrapassar esse limite. A política determina que um enlace de 3 Mbps deve ser dividido entre duas redes: A e B. cria-se um conjunto de classes usando o segundo comando.1. Os parâmetros da classe são os seguintes: rate: taxa média garantida para classe e suas filhas ceil: taxa máxima que pode ser emprestada da classe pai burst: quantidade máxima de bytes que pode ser enviada na taxa ceil cburst: quantidade máxima de bytes que pode ser enviada na taxa da interface (quando não houver limite imposto pela classe pai) priority: ordenamento das classes. A banda da subrede A é dividida em aplicações de telnet. As aplicações de telnet tem 200kbps garantidos. http e outras. Em seguida. As classes possuem um conjunto de parâmetros utilizados para controlar a taxa de transmissão do tráfego que ela representa.0/24 Subrede A (rate 2 Mbps) (ceil 2 Mbps) 200. e também não pode ultrapassar esse limite. As classes de maior prioridade recebem o excesso de banda primeiro.

é necessário escolher os identificadores de cada classe que compõe a política. O script que ilustra a criação das classes para a política do desenho pode ser definido da seguinte forma: #!/bin/bash tc qdisc del dev eth0 root # cria a qdisc principal tc qdisc add dev eth0 handle 1:0 root htb # cria as classes para o link tc class add dev eth0 parent 1:0 classid 1:1 htb rate 3000 kbit # cria as classes para as subredes tc class add dev eth0 parent 1:1 classid 1:2 htb rate 2000 kbit ceil 2000 kbit tc class add dev eth0 parent 1:1 classid 1:3 htb rate 1000 kbit ceil 1000 kbit # cria as classes para dividir o tráfego da subrede A tc class add dev eth0 parent 1:2 classid 1:21 htb rate 200 kbit ceil 2000 kbit tc class add dev eth0 parent 1:2 classid 1:22 htb rate 800 kbit ceil 2000 kbit tc class add dev eth0 parent 1:2 classid 1:23 htb rate 1000 kbit ceil 2000 kbit # cria as classes para dividir o tráfego da subrede B tc class add dev eth0 parent 1:3 classid 1:31 htb rate 500 kbit ceil 1000 kbit tc class add dev eth0 parent 1:3 classid 1:32 htb rate 500 kbit ceil 1000 kbit .3.2.0/24 1:3 Subrede B (rate 1 Mbps) (ceil 1 Mbps) 1:31 http (rate 500 kbps) (ceil 1 Mbps) 1:32 outros (rate 500 kbps) (ceil 1 Mbps) 200.1. Como todas as classes são filhas da qdisc principal (identificada no exemplo pelo handle 1:0).0/24 1:2 Subrede A (rate 2 Mbps) (ceil 2 Mbps) 1:22 http (rate 800 kbps) (ceil 2 Mbps) 1:23 outros (rate 1 Mbps) (ceil 2 Mbps) 1:21 telnet (rate 200 kbps) (ceil 2 Mbps) Edgard Jamhour A fim de criar a hierarquia de classes. Um cuidado especial deve ser feito para indicar o relacionamento entre classes pais e filhas.HTB: Criação da Classes 1:0 qdisc root HTB 1:1 Link (3 Mbps) 200. todas as classes seguem a numeração 1:X.1.

2.0/24 1:3 Subrede B (rate 1 Mbps) (ceil 1 Mbps) 1:31 http (rate 500 kbps) (ceil 1 Mbps) 310:0 qdisc FIFO qdisc FIFO 1:32 outros (rate 500 kbps) (ceil 1 Mbps) 320:0 200.HTB: Qdisc das Classes 1:0 qdisc root HTB 1:1 Link (3 Mbps) 200. # cria as qdiscs FIFO associada as classes folhas tc qdisc add dev eth0 parent 1:21 handle 210:0 pfifo limit 10 tc qdisc add dev eth0 parent 1:22 handle 220:0 pfifo limit 10 tc qdisc add dev eth0 parent 1:23 handle 230:0 pfifo limit 10 tc qdisc add dev eth0 parent 1:31 handle 310:0 pfifo limit 10 tc qdisc add dev eth0 parent 1:32 handle 320:0 pfifo limit 10 .1.3.0/24 1:2 Subrede A (rate 2 Mbps) (ceil 2 Mbps) 1:22 http (rate 800 kbps) (ceil 2 Mbps) 220:0 qdisc FIFO qdisc FIFO 1:23 outros (rate 1 Mbps) (ceil 2 Mbps) 230:0 1:21 telnet (rate 200 kbps) (ceil 2 Mbps) 210:0 qdisc FIFO Edgard Jamhour Para completar a política é necessário incluir as qdisc para cada uma das classes folhas.1. O script a seguir ilustra esse conceito. significa remover o pacote da fila antes que ele seja completamente classificado. Associar uma qdisc a uma classe não folha. Observe que apenas as classes folha (as mais inferiores na hierarquia) pode ser associadas as qdiscs. No exemplo todas as qdiscs das classes são do tipo FIFO.

mas de prioridade mais baixa.1.1. Os filtros para o tráfego default (indicado como outros na figura). O script a seguir ilustra esse conceito.1. pacotes que não se classificarem nas regras de prioridade 1 (telnet) ou 2 (htth).0/24 1:3 Subrede B (rate 1 Mbps) (ceil 1 Mbps) 1:31 http (rate 500 kbps) (ceil 1 Mbps) 310:0 qdisc FIFO filtro prio 4 qdisc FIFO filtro prio 5 Edgard Jamhour 1:32 outros (rate 500 kbps) (ceil 1 Mbps) 320:0 200. na subrede A.HTB: Filtros 1:0 qdisc root HTB 1:1 Link (3 Mbps) 200.0/24 match ip dport 80 0xfff flowid 1:22 tc filter add dev eth0 parent 1:0 protocol ip prio 3 u32 \ match ip src 200. # Cria os filtros para as classes folhas tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 \ match ip src 200.2.3.1.0/24 match ip dport 23 0xfff flowid 1:21 tc filter add dev eth0 parent 1:0 protocol ip prio 2 u32 \ match ip src 200.2.0/24 1:2 Subrede A (rate 2 Mbps) (ceil 2 Mbps) 1:22 http (rate 800 kbps) (ceil 2 Mbps) 220:0 qdisc FIFO filtro prio 2 qdisc FIFO filtro prio 3 1:23 outros (rate 1 Mbps) (ceil 2 Mbps) 230:0 1:21 telnet (rate 200 kbps) (ceil 2 Mbps) 210:0 qdisc FIFO filtro prio 1 Além das qdiscs é necessário definir os filtros que classificam os pacotes para cada classe. Novamente.0/24 flowid 1:32 .1. Por exemplo. são implementados criando-se regra genéricas (sempre satisfeitas). Por exemplo. uma para descriminar a subrede e outro para dizer caracterizar o tráfego de telnet.1. que acumulam todas as regras de classificação das classes pai.3.0/24 match ip dport 80 0xfff flowid 1:31 tc filter add dev eth0 parent 1:0 protocol ip prio 5 u32 \ match ip src 200.2.3.2. o filtro para classe de telnet da subrede A possui dois conjuntos de condições "match". são classificados necessariamente na classe 3 (pois ela não tem restrição de porta). são definidos filtros apenas para as classes folhas.1.0/24 flowid 1:23 tc filter add dev eth0 parent 1:0 protocol ip prio 4 u32 \ match ip src 200.

conforme indicado no primeiro comando da figura. O comando "tc class change" é definido por dois parâmetro: mask e value. então poderão ser feitas até 4 marcações de pacotes com diferentes valores de DS (6 bits DSCP + 2bits ECN). usando os códigos N:1. . ou seja: new_DS = (old_DS & mask) | value Esse método é bastante flexível pois permite tanto efetuar a marcação com a remarcação do byte DS. Para criar uma política de marcação. será necessário utilizar índices=8. A qdisc DSMARK cria automaticamente uma classe para receber os pacotes de cada um dos diferentes valores de DS que serão marcados. O parâmetro indices corresponde ao número de marcações distintas que serão feitas. Por exemplo. etc. Observe que para atribuir um valor ao byte DS de forma independente do seu conteúdo anterior..DSMARK: Marcação do Byte DS new_DS = (old_DS & mask) | value > tc qdisc add dev eth0 root handle 1:0 dsmark indices n default_index id > tc class change dev eth0 classid 1:id dsmark mask mask value value Edgard Jamhour A qdisc DSMARK é utilizada para fazer a marcação ou remarcação do byte DS. se indices=4. As classes são criadas de acordo com o handle da qdisc root. é necessário executar um comando "tc class change" para cada uma das classes de marcação da política. de forma que se forem necessários marcar 7 códigos distintos. onde N:0 é código da qdsic root. O valor de indices deve ser múltiplo de 4. A qdisc dsmark é definida por dois parâmetros: indices e default_index. Para definir como a marcação será feita. Essas classes não possuem marcação associada. N:2. é necessário criar uma qdisc root do tipo dsmark. basta utilizar o valor 0x00 como mask. conforme indicado pelo segundo comando da figura. O byte DS do pacote é marcado efetuando-se duas operações: um AND com o valor de mask e depois um OR com o valor de value.

Byte DS X DSCP para PHBs padronizados Drop Precedence DSCP em Hexa DS em Hexa Edgard Jamhour A classes DSMARK alteram o valor do byte DS e não do campo DSCP. sem alterar os bites ECN e os bits de precedência. Como a DSMARK usa um valor em hexadecimal para os oito bits do byte DS. os bits ECN ainda são pouco usados. de forma que o uso principal do DSMARK é a marcação do campo DSCP. Convém recordar que o byte DS é composto por dois campos: 6 bits do código DSCP e 2 bits de notificação explícita de congestionamento (ECN). A tabela na figura ilustra quais os valores devem ser usados no campo DS para obter cada um dos códigos DSCP correspondentes aos PHB's padronizados do Diffserv. Atualmente. mask 0x1f (b’00011111) value 0x60 (b’01100000) . é preciso fazer uma manipulação de bits (um shift left de dois bits) para determinar qual o valor do DS corresponde a um dado código de DSCP. A seguir são listados alguns exemplos de como definir os valores de mask e value para as classes DSMARK: a) Setar todos os pacotes para AF23 independente do valor original: mask 0x0 (b’00000000 ) value 0x58 (b’01011000 ) b) Setar todos os pacotes como AF12. preservando os bits ECN: mask 0x3 (b’00000011 ) value 0x30 (b’00110000 ) c) Setar em 2 o 'drop precedence' de todos os pacotes mask 0xe3 (b’11100011 ) value 0x10 (b’00010000) d) Setar todos os pacotes para AF3.

Três ações são possíveis: drop: os pacotes são descartados continue: procura-se uma outra regra para classificar o excesso de tráfego. classify (apenas para CBQ): classifica o pacote como Best Effort. O policiamento é implementado de acordo com um filtro token bucket definido por uma taxa média (parâmetro rate. . mas também de acordo com a quantidade de pacotes recebidos na classe. em kbps) e um tamanho de balde (burst. alguns pacotes do tráfego de dados de um usuário podem ser marcados como AF11. conforme indicado na figura.Policiamento: Policing Controle do excesso de tráfego e marcação para classe de core • Tráfego garantido: AF11 • Tráfego excedente: AF12 • Tráfego violado: DROP Roteador de borda Roteador de core > tc filter . O último parâmetro especifica o que deve ser feito com os pacotes que excederem o burst.. Por exemplo. AF12 ou descartados já na entrada do roteador. em kbytes). As políticas de policiamento são implementadas juntamente com os filtros incluindo-se a palavra reservada police no comandos tc filter. dependo se ele excedeu ou não a quantidade de tráfego garantida no seu contrato de SLA. A razão para isso é que os pacotes pertencentes ao PHB AF (Assured Forwarded) não são classificados apenas de acordo com o tipo de tráfego. as políticas do tipo DSMARK são utilizadas juntamente com políticas de policiamento. police rate kbit burst BYTES [reclassify | drop | continue] Edgard Jamhour Normalmente...

os mesmos valores para os campos do cabeçalho IP ou TCP/UDP).g.5 k drop classid 1:2 . a figura define a seguinte política: pacotes enviados pelo usuário até a taxa de 500 kbps são marcados como AF11.g.1.168. 62. O script que implementa essa política é definido a seguir: #!/bin/bash tc qdisc del dev eth0 root # Crias as classes dsmark tc qdisc add dev eth0 handle 1:0 root dsmark indices 4 # Marcação em AF11 tc class change dev eth0 parent 1:0 classid 1:1 dsmark mask 0x0 value 0x28 # Marcação AF12 tc class change dev eth0 parent 1:0 classid 1:2 dsmark mask 0x0 value 0x30 # Filtro para classe AF11 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 \ match ip dst 192. Por exemplo.2/32. 500 kbps tráfego total balde 1 continue (excesso) drop balde 2 (excesso) burst: e.g.g.Policiamento: Policing ENVIADO PARA CLASSE NORMAL ENVIADO PARA CLASSE DE TRATAMENTO DE EXCESSO e. mas com valores e ações de policiamento distintas. AF12 rate: e.168.5k continue classid 1:1 # Filtro para classe AF12 tc filter add dev eth0 parent 1:0 protocol ip prio 2 u32 match ip dst 192. AF11. AF11 rate: e.1.2/32 police rate 500kbit burst 62. AF12 e drop) é implementada cascateando-se filtros que tem o mesmo critério de classificação (isto é. pacotes entre 500 kbps e 1000 kbps são marcados como AF12 e pacotes acima de 1 Mbps são descartados.5 kbytes Edgard Jamhour Uma política de marcação com múltiplas cores (por exemplo.1.2/32 police rate 500kbit burst 62.5 kbytes X drop burst: e. 62. Suponha que essa política se aplica a qualquer pacote enviado pelo usuário 192.g. 500 kbps e.168.g.

0). Entre min e max.RED: Random Early Detection > tc qdisc add dev eth0 root handle 1:0 \ red limit <bytes> min <bytes> max <bytes> avpkt <bytes> \ burst <packets> probability <number> bandwidth <kbps> [ecn] > tc qdisc add dev eth0 parent 1:1 handle 10:0 red . Corresponde ao bits menos significativos do byte DS. Os parâmetros que controlam o comportamento dessa qdisc são os seguintes: probability: probabilidade de descarte (de 0. . Esse tipo de qdisc pode ser usado tanto em classes root (primeiro comando do exemplo). Recomendado: 0. a probabilidade de descarte é proporcional ao tamanho médio da fila max: tamanho médio da fila com probabilidade de descarte máxima. quanto para classes individuais (segundo comando do exemplo). Valor recomendado: (min+min+max)/(3*avpkt).0 a 1. avpkt: Tamanho médio do pacote em bytes ecn: Explicit Congestion Notification. Valor recomendado: 1/3 * max limit: tamanho máximo instantâneo da fila.02. Esse valor é determinado pela fórmula: (largura de banda do enlace) * (atraso máximo desejado) min: tamanho de fila médio que inicia o descarte. controlando o atraso médio introduzido na transmissão de pacotes.01 ou 0. bandwidth: usado para calcular o tamanho médio da fila na ausência de tráfego (velocidade do link).. os pacotes abaixo de “limit” são marcados com ECN ao invés de descartados.. Valor recomendado: >> max + burst ou 8 * max burst: tolerância para tamanho instantâneo da fila. Quando ECN é usado. Edgard Jamhour O principal objetivo deste algoritmo é limitar o tamanho das filas.

f) Tolerância para o tamanho instantâneo da fila em pacotes <burst> = (2 * <min> + <max>) / (3 * <avpkt>) = (2 * 12000 + 32000) / (3 * 1000) = 18. considere a seguinte política associada a interface de um roteador com capacidade de 512 kbps. O tamanho médio dos pacotes é 1 Kbyte.5 s. . adota-se o seguinte procedimento: a) Cálculo da capacidade do enlace em bytes/sec <bandwidth> = 512 kbps ~ 512000 bps = 64000 bytes / sec b) Cálculo do tamanho máximo da fila em bytes Latência máxima desejada = 500 ms.5 sec = 32000 bytes c) Tamanho da fila onde o descarte é iniciado: <min> = ~ 1/3 <max> = 12000 bytes d) Tamanho máximo instantâneo da fila <limit> = ~ 8 * <max> = 256000 bytes.67 ~ 20.02 bandwidth 512 ecn Edgard Jamhour Para ilustrar como os parâmetros do algoritmo de RED são calculados.RED: Random Early Detection descarte total para fila instantânea descarte probabilístico máximo descarte probabilístico variável sem descarte 0 256 kbytes 32 kbytes 12 kbytes > tc qdisc add dev eth0 root handle 1:0 \ red limit 256000 min 12000 max 32000 avpkt 1000 \ burst 20 probability 0. e) Tamanho médio dos pacotes: <avpkt> = 1000 bytes. Então: <max> = 64000 bytes / sec * 0. Para calcular os parâmetros do RED. Deseja-se que os pacote sejam servidos com um atraso médio inferior a 0.

Cabe ao administrador de rede selecionar o conjunto de mecanismos mais adequado para a política de QoS que deseja implementar. e não os que entram. As políticas de QoS são feitas de forma independente para cada interface do computador/roteador e afetam apenas os pacotes que saem pela interface. Contudo. Por exemplo. cada interface controla o QoS do tráfego em um único sentido. Um cuidado especial deve ser tomado com o sentido do tráfego que se deseja controlar. Edgard Jamhour Nesse módulo nós vimos o conjunto de mecanismos de QoS disponíveis no kernel do linux. Se um roteador possui uma interface para a LAN interna e outra WAN para Internet. Existem um conjunto amplo de mecanismos disponíveis para QoS. e não os que entram. por exemplo. Esses mecanismos são configurados através de políticas através do comando tc. • As políticas de QoS são feitas de forma independente para cada interface do computador/roteador • Os algoritmos de enfileiramento afetam apenas os pacotes que saem pela interface.Conclusão • O tc do linux apresenta um conjunto de algoritmos para controlar a forma como o tráfego é transmitido. Se as políticas forem aplicadas a um servidor. elas irão afetar o download para o servidor e não o upload. muitos desses mecanismos são usados em situações diferentes. é preciso controlá-la na origem. cada interface controla o QoS do tráfego em um único sentido. . • Em um roteador. em um roteador. A razão para isso é que não se pode controlar diretamente a quantidade de pacotes que chega apenas no seu destino. então as políticas de QoS na interface LAN controlam o que é transmitido para Internet (upload) e na interface WAN o que é recebido (download).