5. Software e Ferramentas
5.1 Requerimentos do Kernel
Muitas distribuições fornecem kernels com suporte para controle de tráfego como módulo ou monolítico (Qualidade de Serviço). Já kernels customizados podem não fornecer suporte (modular ou não) para as funcionalidades requeridas. Se não fornecer, adiante está uma lista muito resumida das opções do kernel necessárias.
O usuário que tem pouca ou nenhuma experiência na compilação de um kernel é recomendado ler o HOWTO sobre o Kernel . Compiladores experimentados do kernel devem ser capazes de determinar quais dessas opções abaixo se aplicam a uma configuração desejada, depois de ler um pouco mais sobre controle de tráfego e planejamento.
Exemplo 1. Opções de compilação do Kernel [8]
#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_CSZ=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y
Um kernel compilado com o conjunto de opções acima fornecerá suporte modular para quase tudo discutido nessa documentação. O usuário pode precisar do comando modprobe module antes de usar uma dada funcionalidade. Novamente, é recomendado ao usuário que esteja embaraçado ler o HOWTO sobre o Kernel , porque esse documento não pode tratar adequadamente as questões relativas ao uso do kernel Linux.
5.2. Ferramentas iproute2 (tc)
O Pacote iproute2 é uma reunião de utilitários de linha de comando que manipula estruturas do kernel para configuração de rede IP em uma máquina. Para documentação técnica dessas ferramentas, veja a documentação do iproute2 e para uma discussão mais expositiva, a documentação em http://linux-ip.net. Das ferramentas do pacote iproute2, o binário tc é o único usado para controle de tráfego. Esse HOWTO ignorará as demais ferramentas do pacote.
Como ela interage com o kernel para criar, apagar e modificar as estruturas de controle de tráfego, o binário tc precisa ser compilado com suporte a todas as qdisc’s que você deseja usar. Em particular, a qdisc HTB não é suportada ainda no pacote iproute2 principal. Veja a Seção 7.1, “HTB, Hierarchical Token Bucket” para mais informação.
A ferramenta tc executa todas as configurações das estruturas do kernel exigidas para suportar o controle de tráfego. Como resultado de seus muitos usos, a sintaxe da linha de comando pode ser descrita (na melhor das hipóteses) como algo só compreendido por poucos. O utilitário toma como seu primeiro argumento sem opções um dos três componentes de controle de tráfego Linux, qdisc, class ou filter.
Exemplo 2. Uso do comando tc
[root@leander]# tc
Usage: tc [ OPTIONS ] OBJECT { COMMAND | help }
where OBJECT := { qdisc | class | filter }
OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] }
Cada objeto aceita mais e diferentes opções, e será descrito incompletamente e documentado a seguir. As dicas nos exemplos seguintes são projetadas para introduzir as excentricidades da sintaxe da linha de comando de tc. Para mais exemplos, consulte o HOWTO do LARTC. Para melhor entendimento de fato, consulte o kernel e o código de iproute2.
Exemplo 3. Comando tc qdisc
[root@leander]# tc qdisc add \ 
> dev eth0 \ 
> root \ 
> handle 1:0 \ 
> htb  |
| Adiciona (add) uma disciplina de enfileiramento. O verbo também pode ser del. |
| Especifica o dispositivo no qual estamos amarrando a nova disciplina de enfileiramento. |
| Isso significa “egress” para o tc. Contudo, a palavra root precisa ser usada. Uma outra qdisc com funcionalidade limitada, a qdisc ingress pode ser associada ao mesmo dispositivo. |
| O handle é um número especificado pelo usuário da forma major:minor. O número minor para qualquer handle da disciplina de enfileiramento precisa ser zero (0). Um atalho aceitável para um handle qdisc qdisc é a sintaxe "1:", onde número minor é assumido ser zero (0) se não for especificado. |
| Essa é a disciplina de enfileiramento a associar, nesse exemplo, o HTB. A disciplina de enfileiramento especifica parâmetros que se seguirá a esse. No exemplo aqui, não adicionamos nenhum parâmetro específico da qdisc. |
Acima foi o uso mais simples do utilitário tc para adicionar uma disciplina de enfileiramento a um dispositivo. Aqui está um exemplo do uso de tc para adicionar uma classe a uma classe pai existente.
Exemplo 4. Comando tc class
[root@leander]# tc class add \
> dev eth0 \
> parent 1:1 \
> classid 1:6 \
> htb \
> rate 256kbit \ 
> ceil 512kbit 
| Adiciona (add) uma classe. O verbo também pode ser del. |
| Especifica o dispositivo no qual nós estamos associando a nova classe. |
| Especifica o handle pai ao qual estamos associando a nova classe. |
| Esse é um handle (major:minor) único que identifica essa classe. O número minor precisa ser qualquer número diferente de zero. |
| Ambas as qdiscs classful requerem que quaisquer classes descendentes sejam classes do mesmo tipo que a classe genitor. Conseqüentemente uma qdisc HTB vai conter classes HTB. |
| Esses são alguns parâmetros específicos de classe. Consulte a Seção 7.1, “HTB, Hierarchical Token Bucket” para mais detalhes sobre esses parâmetros. |
Exemplo 5. Comando tc filter
[root@leander]# tc filter add \
> dev eth0 \
> parent 1:0 \
> protocol ip \
> prio 5 \
> u32 \
> match ip port 22 0xffff \
> match ip tos 0x10 0xff \ 
> flowid 1:6 \ 
> police \ 
> rate 32000bps \ 
> burst 10240 \ 
> mpu 0 \ 
> action drop/continue 
| Adiciona (add) um filtro. O verbo pode ser também del. |
| Especifica o dispositivo no qual estamos associando o novo filtro. |
| Especifica o handle genitor ao qual estamos associando o novo filtro. |
| Esse parâmetro é exigido. Seu uso deve ser óbvio, ainda que Eu não saiba mais. |
| O parâmetro prio permite a um dado filtro ser preferido acima de um outro. O parâmetro pref é sinônimo. |
| Esse é um classificador, e é frase exigida em todo comando tc filter. |
| Esses são parâmetros para o classificador. Nesse caso, pacotes com um flag tipo de serviço (que indica uso interativo) e que batem com a porta 22 serão selecionados por essa instrução. |
| O parâmetro flowid especifica o handle da classe alvo (ou qdisc) para a qual um filtro que faz match deve enviar seus pacotes selecionados. |
| Esse é o policer, e é uma frase opcional em todo comando tcfilter. |
| O guarda executará uma ação acima dessa taxa, e uma outra ação abaixo dessa taxa (veja o parâmetro action). |
| O parâmetro burst é uma analogia exata para burst em HTB (burst é um conceito de buckets). |
| A unidade mínima vigiada. Para levar em conta todo o tráfego, use um mpu de zero. |
| O parâmetro action indica o que deve ser feito se a rate baseado nos atributos do vigilante (policer). A primeira palavra especifica a ação a tomar se o vigia foi superado. A segunda palavra especifica a ação a tomar no caso contrário. |
Como evidenciado acima, o utilitário de linha de comando tc possui uma sintaxe complexa e arcaica, mesmo para operações simples como esses exemplos mostrados. Deve suceder como sem qualquer surpresa ao leitor que haja uma forma mais fácil de configurar o controle de tráfego Linux. Veja a próxima seção, Section 5.3, “tcng, Traffic Control Next Generation”.
5.3 tcng, Traffic Control Next Generation
CORRIJA-ME; canção de louvor ao tcng. Veja também o HOWTO Controle de Tráfego usando o tcng e o HTB e documentação do tcng.
Controle Tráfego de Próxima Geração (doravante, tcng) fornece todo o poderio do controle de tráfego sob o Linux com vinte por cento de dor de cabeça.
5.4 IMQ, Intermediate Queuing device
CORRIJA-ME; precisa discutir o IMQ. Veja também o website do Patrick McHardy em IMQ.
[8] As opções listadas nesse exemplo são tomadas de uma árvore do código fonte do kernel 2.4.20. As opções exatas podem diferir ligeiramente de liberação para liberação do kernel dependendo dos patch’s e dos novos escalonadores e classificadores.
