Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP: fevereiro 2009




Muito Bem Vindo

Prezado Leitor, a proposta desse Blog é compartilhar conhecimento com as pessoas que trabalham com Linux, Asterisk, OpenSER, e com tecnologia de voz sobre a rede IP em geral, através de tutoriais, dicas, howto, notícias entre outros assuntos.

Atente para termo de uso do conteúdo do blog no rodapé da página.

domingo, 15 de fevereiro de 2009

TC: Índice do Conteúdo




Autor Original do texto:

Martin A. Brown
martin@linux-ip.net
http://linux-ip.net




1.  Introdução ao Controle de Tráfego Linux

2.  Visão Geral dos Conceitos

3.  Elementos Tradicionais de Controle de Tráfego

4.  Componentes do Controle de Tráfego Linux

5.  Software e Ferramentas

6.  Disciplinas de Enfileiramento Classless

7.  Disciplinas de Enfileiramento Classful

8.  Regras, Orientações e Abordagens

9.  Scripts para usar com Controle Tráfego/QoS

10. Diagrama Geral

11. Links que Detalham Controle de Tráfego









 ... Retorna
Início











Introdução ao Controle de Tráfego Linux




Autor Original do texto:

Martin A. Brown
martin@linux-ip.net
http://linux-ip.net




1. Introdução ao Controle de Tráfego Linux
O Linux oferece um conjunto muito rico de ferramentas para gerenciamento e manipulação na transmissão de pacotes. A grande comunidade Linux é muito familiar com as ferramentas disponíveis com o Linux para alteração de pacote e implementar firewall (netfilter, e antes desse, o ipchains) bem como centenas de serviços de rede que podem rodar sobre o sistema operacional. Poucos dentro da comunidade e muito poucos ainda fora da comunidade Linux têm consciência do tremendo poderio do subsistema de controle de tráfego que cresceu e amadureceu sob os kernels 2.2 e 2.4.

Esse HOWTO objetiva introduzir os conceitos de controle de tráfego, os elementos tradicionais (em geral), os componentes da implementação de controle de tráfego Linux e fornece algumas orientações. Esse HOWTO representa a coleção, o amálgama e síntese do HOWTO do LARTC, documentação dos projetos individuais e mais importante a lista de email LARTC além de um período de estudo.

Para a criatura impaciente, que simplesmente deseja experimentar imediatamente, é recomendado ler o HOWTO de Controle de Tráfego usando tcng e HTB e HOWTO do LARTC para satisfação imediata.


1.1 Público Alvo e suposições sobre o leitor
O público alvo para esse HOWTO é o administrador de rede ou usuário caseiro conhecedor que deseja uma introdução ao campo do controle de tráfego e uma visão rápida das ferramentas disponíveis com o Linux para implementação de controle de tráfego.

Eu estou supondo que o leitor é confortável com os conceitos UNIX e com a linha de comando e tem um conhecimento básico de implementação de rede IP. Usuários que desejam implementar controle de tráfego pode ser exigido a habilidade de aplicar patch, compilar e instalar um kernel ou pacote de software[1]. Para usuários com kernels mais recentes (2.4.20+, veja também Seção 5.1, “Requerimentos de Kernel”), contudo, a habilidade de instalar e de usar software pode ser tudo exigido.

Falando de um modo geral, esse HOWTO foi escrito com um usuário sofisticado em mente, talvez alguém que já teve experiência com controle de tráfego com o Linux. Eu suponho que o leitor pode não ter nenhuma experiência anterior de controle de tráfego.


1.2 Convenções
Esse texto foi escrito em DocBook (versão 4.2) com o vim. Toda formatação foi aplicada por xsltproc baseado na folha de estilos dos DocBook XSL e LDP XSL. Formatação de fonte e convenções são similares a muitas impressões e documentação técnica distribuída eletronicamente.


1.3 Abordagem Recomendada
Eu recomendo fortemente ao leitor ávido fazer uma primeira investida na disciplina de controle de tráfego, para ficar exatamente familiar casualmente com o utilitário de linha de comando tc, antes de se concentrar no tcng. O pacote de software tcng define uma linguagem completa para descrever as estruturas de controle de tráfego. Inicialmente, essa linguagem pode parecer assombrosa, mas o mistério daquelas coisas básicas dará rapidamente ao usuário uma habilidade muito mais ampla para empregar (e implementar) as configurações de controle de tráfego do que daria o uso direto de tc.

Onde for possível, eu tentarei dar preferência à descrição do comportamento do sistema de controle de tráfego Linux de uma forma abstrata, embora em muitos casos eu necessitarei fornecer a sintaxe de um ou de outros sistemas comuns para definir essas estruturas. Eu não poderei fornecer exemplos tanto na linguagem tcng quanto na linha de comando tc, logo o usuário esperto adquirirá alguma familiaridade com ambos.


1.4 Conteúdo faltante, correções e feedback
Existe ainda conteúdo que está faltando a esse HOWTO. Em particular, os itens seguintes serão acrescentados em algum ponto dessa documentação.

• Uma descrição e o diagrama do GRED, WRR, PRIO e CBQ.
• Uma seção de exemplos.
• Uma seção que detalha os classificadores.
• Uma seção que discute as técnicas para medição de tráfego.
• Uma seção que cobre os medidores.
• Mais detalhes sobre tcng.

Eu dou boas vindas as sugestões, correções e feedback em . Todos os erros e omissões são devidos estritamente lapsos de minha parte. Embora eu tenha feito todo o esforço para verificar a incorreção factual do conteúdo apresentado aqui, Eu não posso aceitar qualquer responsabilidade por ações tomadas sob a influência desse documento.



________________________________________
[1] Veja Seção 5, “Software e Ferramentas” para mais detalhes sobre o uso ou instalação de um mecanismo particular de controle de tráfego, kernel ou utilitário de linha de comando.









 ... Retorna











sábado, 14 de fevereiro de 2009

TC Visão Geral dos Conceitos




Autor Original do texto:

Martin A. Brown
martin@linux-ip.net
http://linux-ip.net



2. Visão Geral dos Conceitos
Essa seção introduzirá o controle de tráfego e examina razões para isso, identifica algumas vantagens e desvantagens e introduz conceitos chaves usados em controle de tráfego.


2.1 O Que é isso?
Controle de Tráfego é o nome dado aos conjuntos de mecanismos e sistemas de enfileiramento pelos quais os pacotes são recebidos e transmitidos sobre um roteador. Isso inclui decidir quais (e se) pacotes aceitar em qual taxa na entrada de uma interface e determinar quais pacotes transmitir em qual ordem e em qual taxa na saída de uma interface.

Na maioria esmagadora das situações, controle de tráfego consiste de uma fila única que coleta pacotes entrantes e os des-enfileira tão rápido quanto o hardware (ou dispositivo subjacente) pode aceitá-los. Esse tipo de fila é uma fila FIFO.

Obs.:
A qdisc padrão sob o Linux é o pfifo_fast, que é ligeiramente mais complexa que o FIFO.

Existem exemplos de filas em toda sorte de software. A fila é uma forma de organizar as tarefas e dados pendentes (veja também Seção 2.5, “Filas”). Como os links de rede tipicamente transportam dados de uma forma serializada, a fila é exigida para gerenciar os pacotes de dados de saída.

No caso de uma máquina desktop e um webserver eficiente compartilhando o mesmo uplink para a Internet, a conseqüente disputada de banda pode acontecer. O webserver pode ser capaz de preencher a fila de saída no roteador mais rápido do que os dados podem ser transmitidos através do link, nesse instante o roteador começa a descartar pacotes (seu buffer fica cheio!). Agora, a máquina desktop (com uma aplicação usuária interativa) pode se deparar com pacotes perdidos e elevada latência. Observe que latência elevada às vezes gera queixas de usuários! Separando as filas internas usadas para servir essas duas diferentes classes de aplicação, pode haver um melhor compartilhamento dos recursos da rede entre as duas aplicações.

O controle de Tráfego é o conjunto de ferramentas que permite ao usuário ter controle granular sobre essas filas e os mecanismos de enfileiramento de um dispositivo colocado na rede. O poder de re-arranjar os fluxos de tráfego e pacotes com essas ferramentas é tremendo e pode ser complicado, mas nada substitui largura de banda adequada.

O termo qualidade de serviço (QoS) é freqüentemente usado como um sinônimo para controle de tráfego.


2.2 O Porquê de usá-lo?
Redes comutadas por pacotes diferem das redes baseadas em circuitos em uma questão muito importante. Rede comutada por pacote por si só não mantém estado. Uma rede baseada em circuito (como um rede legada de telefonia) precisa manter o estado dentro da rede. Por projeto, as Redes IP’s são sem estado e as redes comutadas por pacote; de fato, essa falta de estado é uma das forças fundamentais da rede IP.

O ponto franco dessa falta de estado é a ausência de diferenciação entre os tipos de fluxos. Em termos mais simples, o controle de tráfego permite a um administrador enfileirar pacotes de forma diferente baseado em atributos do pacote. Ele pode simplesmente ser usado para simular o comportamento de uma rede baseada em circuito. Isso introduz a manutenção de estado na rede sem estado.

Existem muitas razões práticas para considerar o controle de tráfego, e muitos cenários em que o uso de controle de tráfego faz sentido. Abaixo estão alguns exemplos de problemas comuns que podem ser resolvidos ou pelo menos melhorados com essas ferramentas.

A lista abaixo não é uma lista exaustiva dos tipos de soluções disponíveis aos usuários de controle de tráfego, mas introduz os tipos de problemas que podem ser resolvidos quando se usa o controle de tráfego para maximizar a usabilidade de uma conexão de rede.

Soluções Comuns de controle de tráfego:
• Limitar largura de banda total a uma taxa conhecida; TBF, HTB com classe(s) filhas;
• Limitar largura de banda de um usuário particular, serviço ou cliente; classes HTB e classificação com um filtro;
• Maximizar taxa de transferência TCP em um link assimétrico; priorizar transmissão de pacotes ACK, wondershaper;
• Reservar largura de banda para uma aplicação particular ou usuário; HTB com classes filhas e classificação;
• Dar preferência a tráfego sensível à latência; PRIO dentro de uma classe HTB;
• Largura de banda gerenciada esgotada; HTB com empréstimo;
• Permitir distribuição eqüitativa de largura de banda não reservada; HTB com empréstimo;
• Assegurar que um tipo particular de tráfego seja descartado; policer associado a um filtro com uma ação drop.

Lembre-se, também que às vezes, é simplesmente melhor adquirir mais banda. Controle de tráfego somente não resolver todos os problemas!


2.3 Vantagens
Quando empregado adequadamente, o controle de tráfego leva ao uso mais previsível dos recursos de rede e menos disputa desses recursos voláteis. A rede então encontra os objetivos da configuração do controle de tráfego. Volume de Tráfego de download pode ser alocado a quantidade razoável de largura de banda mesmo quando o tráfego de mais alta prioridade for servido simultaneamente. Mesmo transferência de dados de baixa prioridade como email pode ter largura de banda alocada sem que afete substancialmente as outras classes de tráfego.

Em uma visão mais ampla, se a configuração de controle de tráfego representa uma gestão que foi comunicada aos outros usuários, então usuários (e, por extensão, aplicações) sabem o que esperar da rede.


2.4 Desvantagens
A complexidade é facilmente uma das desvantagens mais significativa de uso do controle de tráfego. Existem formas de se familiarizar com as ferramentas de controle de tráfego que facilita a curva de aprendizagem sobre o controle de tráfego e seus mecanismos, mas a identificação de uma configuração mal feita de controle de tráfego pode ser um desafio completamente.

O controle de tráfego quando usado de forma adequada pode levar distribuição mais eqüitativa dos recursos de rede. Igualmente pode facilmente ser instalado justamente de uma forma inadequada provoca mais e mais briga na disputa por recursos.

Os recursos computacionais exigem que um roteador suporte a necessidade de um cenário de controle de tráfego que seja capaz de tratar o custo incremental da manutenção das estruturas de controle de tráfego. Felizmente, esse é um custo incremental pequeno, mas pode se tornar mais significativo quando a configuração cresce em tamanho e complexidade.

Para uso pessoal, não existe qualquer custo de treinamento associado ao uso de controle de tráfego, mas uma companhia pode achar que aquisição de mais banda seja uma solução mais simples que implementar controle de tráfego. Treinamento de empregados e assegurar conhecimento profundo podem ser mais custosos que investir em mais banda.

Embora o controle de tráfego em redes comutadas por pacotes cubra uma área conceitual bastante ampla, você pode pensar sobre controle de tráfego como uma forma para fornecer [alguns dos] estados de uma rede baseada em circuito sobre uma rede comutada por pacote.


2.5 Filas
As filas formam o pano de fundo para tudo sobre controle de tráfego e é o conceito integral que está por trás do escalonamento. Uma fila é uma posição (ou buffer) que contém um número finito de itens esperando por uma ação ou serviço. Em implementação de rede, uma fila é o lugar onde os pacotes (nossas unidades) esperam ser transmitidos pelo hardware (o serviço). No modelo mais simples, pacotes são transmitidos em uma base primeiro a entrar primeiro a servir [2]. Na disciplina de implementação de rede de computador (e mais genericamente na ciência da computação), esse tipo de fila é conhecido como fila FIFO.

Sem qualquer outro mecanismo, uma fila não oferece qualquer promessa de controle de tráfego. Existem somente duas ações interessantes em uma fila. Tudo que entra em uma fila é enfileirado na fila. Para remover um item de uma fila é para desenfileirar esse item.

Uma fila se torna mais interessante quando são acoplados outros mecanismos que possa atrasar pacotes, rearranjar, descartar e priorizar pacotes em múltiplas filas. Uma fila pode também usar sub-filas, que permite mais complexidade do comportamento em uma operação de escalonamento.

Da perspectiva da camada superior de software, um pacote é simplesmente enfileirado para transmissão, e o modo e a ordem na qual os pacotes enfileirados são transmitidos é imaterial à camada superior. Assim, à camada superior, o sistema de controle de tráfego inteiro pode aparecer como uma única fila [3]. É somente examinando os internos dessa camada que as estruturas de controle de tráfego ficam expostas e disponíveis.


2.6 Flows (Fluxos)
Um flow é uma conexão ou uma conversação distinta entre dois hosts. Qualquer conjunto único de pacotes entre dois hosts pode ser considerado como um fluxo (flow). Sob o TCP o conceito de uma conexão com um endereço IP e uma porta de origem, e porta e endereço IP destino representa um fluxo. Um fluxo UDP pode ser definido de forma similar.

Os mecanismos de controle de tráfego freqüentemente separam o tráfego em classes de fluxos que podem ser agregados e transmitidos como fluxo agregado (considere o DiffServ). Mecanismos alternativos podem tentar dividir a largura de banda de forma uniforme baseado nos fluxos individuais.

Os fluxos se tornam importantes quando tentando dividir largura de banda de forma uniforme entre um conjunto de fluxos que competem, especialmente quando algumas aplicações deliberadamente constroem um grande número de fluxos.


2.7 Tokens e Buckets
Duas das peças chaves dos mecanismos de shaping são os conceitos inter-relacionados de tokens e buckets.

A fim de controlar a taxa de des-enfileiramento, uma implementação pode contar o número de pacotes ou bytes des-enfileirados quando cada item for des-enfileirados, embora isso exija uso complexo de cronômetros e medidas para limitar a precisão. Em vez de fazer cálculo da ocupação atual e do tempo, um método, usado amplamente no controle de tráfego, é gerar tokens a uma taxa desejada, e somente des-enfileirar pacotes ou bytes se um token estiver disponível.

Considere a analogia de um passeio no parque de entretenimento com uma fila de pessoas esperando a sua vez em algum dos cavalos. Imaginemos uma pista na qual os cavalos galopam a passos fixos. Os cavalos chegam à cabeceira da fila a uma taxa fixada. A fim de curtir o passeio, cada pessoa precisa esperar que um cavalo fique disponível. O cavalo é análogo a um token e a pessoa é análoga a um pacote. Novamente, esse mecanismo é uma limitação na taxa ou um mecanismo de shaping. Somente certo número de pessoas pode experimentar o passeio em um período particular.

Para expandir a analogia, imagine uma linha vazia para o passeio no parque de diversão e um grande número de cavalos de prontidão na pista pronto para transportar pessoas. Se um grande número de pessoas entrar na linha de vez muitas (talvez todas) delas podem experimentar o passeio por causa da disponibilidade dos cavalos que estão esperando. O número de cavalos disponíveis é um conceito análogo ao balde. Um balde contém um número de tokens e pode usar todos os tokens no balde sem considerar a passagem de tempo.

E para completar a analogia, os cavalos no passeio do parque de entretenimento (nossos tokens) chegam a uma taxa fixa e são mantidos somente disponíveis até o tamanho do balde. Assim, o balde é preenchido com tokens de acordo com a taxa, e se os tokens não forem usados, o balde pode ficar cheio. Se os tokens forem usados, então o balde não ficará cheio. Balde é um conceito chave em tráfego que suporta rajada como http.

A qdisc TBF é um exemplo clássico de um shaper (a seção sobre TBF inclui um diagrama que pode ajudar a visualizar os conceitos de token e bucket). O TBF gera taxa (rate) de tokens e somente transmite pacotes quando um token estiver disponível. Os tokens são um conceito genérico de shaping.

No caso de uma fila não precisar de tokens imediatamente, os tokens podem ser coletados até que eles sejam necessários. Coletar tokens indefinidamente negaria qualquer benefício do shaping por isso os tokens são coletados até que certo número de tokens tenha sido alcançado. Agora, a fila possui tokens disponíveis para um grande número de pacotes ou bytes que precisam ser des-enfileirados. Esses tokens intangíveis são armazenados em um balde intangível, e o número de tokens que pode ser armazenado depende do tamanho do balde.

Isso também significa que um balde cheio de tokens pode ficar disponível a qualquer instante. Tráfego regular muito previsível pode ser tratado por baldes pequenos. Baldes mais largos podem ser requeridos para tráfego com comportamento mais caracterizado por rajadas, a não ser que um dos objetivos desejados seja reduzir a rajada dos fluxos.

Em resumo, os tokens são gerados na taxa, e um máximo de valor de tokens de um balde pode ser coletados. Isso permite ao tráfego em rajadas ser manipulado, enquanto aparando e fazendo shape do tráfego transmitido.

Os conceitos de tokens e buckets são intimamente inter-relacionados e é usado tanto no TBF (uma das qdiscs classless) quanto no HTB (uma das qdiscs classful). Dentro da linguagem tcng, o uso de medidores de duas e três cores é indubitavelmente um conceito de token e bucket.


2.8 Pacotes e Frames
Os termos para envio de dados através da rede mudam dependendo da camada que o usuário está examinado. Esse documento vai especialmente sem cerimônia (e incorretamente) descuidar da distinção técnica que existe entre os termos pacotes e frames muito embora eles sejam descritos aqui.

A palavra frame (quadro) é tipicamente usada para descrever uma unidade de dados da camada 2 (enlace de dados) a ser encaminhada ao próximo receptor. Interfaces Ethernet, interfaces PPP, e interfaces T1 são todos nome dados ao frame para as suas unidades de dados na camada 2. O frame realmente é a unidade na qual o controle de tráfego é executado.

Um pacote, por outro lado, é um conceito da camada superior, que representa as unidades da camada 3 (rede). O termo pacote é o termo preferido nessa documentação, embora seja ligeiramente inexato.



________________________________________
[2] Esse modelo de enfileiramento tem sido longamente usado em países civilizados para distribuir alimentos escassos ou equilibradamente provisões. William Faulkner é respeitado por ter andado à frente da linha pra pegar sua parte de gelo, mostrando que nem todos gostam do modelo FIFO, e nos fornecendo um modelo que considera o enfileiramento com prioridade.

[3] De forma similar, o sistema de controle de tráfego inteiro aparece como uma fila ou escalonador para a camada superior que está enfileirando pacotes em sua camada.




















quinta-feira, 12 de fevereiro de 2009

Elementos Tradicionais de Controle de Tráfego




Autor Original do texto:

Martin A. Brown
martin@linux-ip.net
http://linux-ip.net




3. Elementos Tradicionais de Controle de Tráfego

3.1 Modelagem (Shaping)
Shapers atrasam pacotes para ajustar a uma taxa desejada.

Shaping é o mecanismo pelo qual os pacotes são atrasados antes da transmissão em uma fila sainte para ajustar a uma taxa sainte desejada. Esse é um dos desejos mais comuns de usuários que buscam soluções de controle de largura de banda. O ato de atrasar um pacote como parte de uma solução de controle de tráfego torna todo mecanismo shaping em um mecanismo non-work-conserving, significando grosso modo que: “Trabalho é exigido a fim de atrasar pacotes”.

Inversamente, a um mecanismo de enfileiramento non-work-conserving que executa uma função shaping. Um mecanismo de enfileiramento work-conserving (veja PRIO) não seria capaz de atrasar um pacote.

Shapers tenta limitar ou racionalizar o tráfego para regular, mas que não excede a uma taxa configurada (freqüentemente medida em pacotes por segundo ou bits/bytes por segundo). Como um efeito colateral, shapers podem podar rajadas de tráfego de saída [4]. Um das vantagens de fazer shape da largura de banda é a capacidade de controlar a latência de pacotes. O mecanismo subjacente de fazer o shape de uma taxa é tipicamente um mecanismo token e bucket. Veja também Seção 2.7, “Tokens e buckets” para detalhes adicionais sobre fichas e baldes.


3.2 Escalonamento (Scheduling)
Schedulers (Escalonadores) organiza e/ou reorganiza pacotes para saída.

Scheduling (Escalonamento) é o mecanismo pelo qual os pacotes são organizados (ou reorganizados) entre a entrada e a saída de uma fila particular. Esmagadoramente o escalonador mais comum é o escalonador FIFO (primeiro a entrar, primeiro a sair). De uma perspectiva mais ampla, qualquer conjunto de mecanismos de controle de tráfego que atuam sobre uma fila sainte pode ser considerado como um escalonador, porque os pacotes são organizados para a saída.

Outros mecanismos genéricos de escalonamento tentam compensar as várias condições de rede. Um algoritmo de enfileiramento justo (veja SFQ) tenta evitar que qualquer cliente sozinho ou fluxo de se apossar do uso da rede. Um algoritmo cíclico (round-robin), veja também WRR, dá a cada fluxo ou cliente uma chance de desenfileirar pacotes. Outros algoritmos sofisticados de escalonamento tentam evitar que o backbone fique sobrecarregado (veja GRED) ou que refinam outros mecanismos de escalonamento (veja ESFQ).


3.3 Classificação (Classifying)
Os Classificadores classificam ou separam o tráfego em filas.

Classificação é o mecanismo pelo qual os pacotes são separados para diferentes tratamentos, possivelmente em diferentes filas saintes. Durante o processo de aceitação, roteamento e transmissão de um pacote, um dispositivo de rede pode classificar o pacote de inúmeras formas diferentes. A Classificação pode incluir marcação de pacote, que normalmente acontece nos limites de uma rede sob um único controle administrativo ou a classificação pode ocorrer em cada hop individualmente.

O modelo Linux (veja Seção 4.3, “filter”) permite que um pacote seja cascateado através de uma série de classificadores em uma estrutura de controle de tráfego e ser classificado em conjunção com os policers (veja também Seção 4.5, “policer”).


3.4 Policiamento (Policing)
Os Policers (guardas) medem e limitam o tráfego em uma fila particular.

O policiamento, como um elemento de controle de tráfego, é simplesmente um mecanismo pelo qual o tráfego pode ser limitado. Policiamento é mais freqüentemente usado nas bordas de rede para assegurar que um par não esteja consumindo mais do que a sua largura de banda alocada. Um guarda aceitará tráfego a certa taxa, e então executa uma ação sobre o tráfego que exceder a essa taxa. Uma solução particularmente cruel é descartar o tráfego, muito embora o tráfego possa ser re-classificado em vez de ser descartado.

Um guarda é uma questão yes/no a cerca da taxa na qual o tráfego está entrando em uma fila. Se o pacote está a ponto de entrar em uma fila uma dada taxa inferior, toma uma ação (permite o enfileiramento). Se o pacote está a ponto de entrar em uma fila a uma dada taxa superior, toma uma outra ação. Ainda que o guarda use um mecanismo token bucket internamente, ele não tenha a capacidade de atrasar um pacote como faz um mecanismo de shaping.


3.5 Descarte (Dropping)
Dropping descarta um pacote, fluxo ou classificação inteira.

Fazer Drop de um pacote é um mecanismo pelo qual um pacote é descartado.


3.6 Marcação (Marking)
Marking (Marcação) é um mecanismo pelo qual o pacote é alterado.


Obs.:
Isso não é fwmark. O alvo MARK do iptables e a --mark do ipchains são usados para modificar pacote metadados, não são propriamente pacotes.


Os mecanismos de marcação do Controle de Tráfego carimbam um selo DSCP no próprio pacote, que é então usado e respeitado pelos demais roteadores dentro de um domínio administrativo (normalmente para o DiffServ).




________________________________________
[4] Esse efeito podar não é sempre desejado, e conseqüentemente os parâmetros burst e cburst do HTB.

















quarta-feira, 11 de fevereiro de 2009

Componentes do Controle de Tráfego Linux




Autor Original do texto:

Martin A. Brown
martin@linux-ip.net
http://linux-ip.net




4. Componentes do Controle de Tráfego Linux


Tabela 1. Correlação entre elementos de controle de tráfego e componentes Linux
Elemento tradicionalComponente Linux
shapingAs classes oferecem capacidades de shaping.
schedulingUma qdisc é um escalonador. Escalonadores podem ser simples como o FIFO ou complexos, contendo classes e outras qdisc’s, como HTB.
classifyingO objeto filter executa a classificação através da ação de um objeto classificador. Estritamente falando, classificadores Linux não podem existir fora de um filtro.
policingUm policer existe na implementação de controle de tráfego Linux somente como parte de um filtro.
droppingPara drop tráfego exige um filtro com um policer que usa “descartar” como uma ação.
markingA qdiscdsmark é usada para marcação.



4.1. Qdisc
Simplesmente indica que uma qdisc é um escalonador (Seção 3.2, “Scheduling”). Toda interface de saída precisa de algum tipo de escalonador, e o escalonador padrão é um FIFO. Outras qdisc’s disponíveis sob o Linux reorganizam os pacotes entrantes na fila do escalonador em consonância com aquelas regras do escalonador.

A qdisc é o bloco principal de montagem sobre a qual todo o controle de tráfego Linux é montado, e é também chamado de uma disciplina de enfileiramento.

As qdiscs classful podem conter classes, e fornecem um handle ao qual associar filtros. Não existe nenhuma proibição a respeito do uso de qdisc classful sem classes filhas, ainda que isso usualmente consumisse ciclos e outros recursos de sistema sem qualquer benefício.

As qdiscs classless não podem conter nenhuma classe, e nem é possível associar filtro a uma qdisc classless. Porque uma qdisc classless não contém nenhum filho de qualquer tipo, não existe nenhum utilitário para classificação. Isso significa que nenhum filtro pode ser associado a uma qdisc classless.

Uma fonte de confusão terminológica é o uso dos termos qdisc root e qdisc ingress. Essas não são realmente disciplinas de enfileiramento, mas especialmente locais nos quais estruturas de controle de tráfego podem ser associadas para egress (tráfego sainte) e ingress (tráfego entrante).

Cada interface contém ambas. A primária e mais comum é a qdisc egress, conhecida como qdisc root. Ela pode conter qualquer das disciplinas de enfileiramento (qdiscs) com classes potenciais e estrutura de classe. A maioria esmagadora das documentações se aplica a qdisc root e suas filhas. O tráfego transmitido sobre uma interface atravessa a egress ou a qdisc root.

Para tráfego aceitado sobre uma interface, a qdisc ingress é atravessada. Com sua utilidade limitada, ela não permite que nenhuma classe filha seja criada, e somente existe como um objeto na qual um filtro pode ser afixado. Para propósitos práticos, a qdisc ingress é meramente um objeto conveniente no qual associar um guarda para limitar a quantidade de tráfego aceitado sobre uma interface de rede.

Em resumo, você pode fazer muito mais com uma qdisc egress porque ela contém uma qdisc real e o poder total do sistema de controle de tráfego. Uma qdisc ingress pode somente suportar um guarda. O restante da documentação se preocupará com as estruturas de controle de tráfego associadas com a qdisc root a não ser que especificado em contrário.


4.2 Classe
As Classes somente existem dentro de uma qdisc classful (por exemplo, HTB e CBQ). As Classes são imensamente flexíveis e podem sempre conter tanto múltiplas classes filhas como uma única qdisc filha [5]. Não existe qualquer proibição contra uma classe conter uma qdisc classful em si, o que facilita tremendamente cenários complexos de controle de tráfego.

Qualquer classe pode também ter um número arbitrário de filtros afixados a ela, que permite a seleção de uma classe filha ou o uso de um filtro para re-classificar ou descartar o tráfego entrante em uma classe particular.

Uma classe folha é uma classe terminal em uma qdisc. Ela contém uma qdisc (FIFO padrão) e nunca conterá uma classe filha. Qualquer classe que contenha uma classe filha é uma classe interna (ou classe root) e não uma classe folha.



4.3 Filter
O filtro é o componente mais complexo no sistema de controle de tráfego Linux. O filtro fornece um mecanismo conveniente para colar junto vários dos elementos do controle de tráfego chaves. A função mais simples e mais óbvia do filtro é classificar pacotes (veja Seção 3.3, “Classifying”). Os filtros Linux permitem ao usuário classificar pacotes em uma fila de entrada tanto com vários filtros diferentes como um único filtro.

• Um filtro precisa conter uma frase classifier.
• Um filtro precisa conter uma frase policer.


Os filtros podem ser associados tanto a qdiscs classful como a classes, contudo o pacote enfileirado sempre entra primeiro na qdisc root. Após o filtro associado à qdisc root ter sido atravessada, o pacote pode ser direcionado a quaisquer subclasses (que pode ter seus próprios filtros) onde o pacote pode experimentar mais classificação.


4.4 Triador/Classificador (classifier)
Objetos filtro, os quais podem ser manipulados usando tc, pode usar vários mecanismos de classificação diferentes, o mais comum desses é o classificador u32. O classificador u32 permite ao usuário selecionar os pacotes baseado nos atributos de cada pacote.

Os classificadores são ferramentas que podem ser usadas como parte de um filtro para identificar características de um pacote ou metadados de pacote. O objeto classificador Linux é uma analogia direta com a operação básica e com o mecanismo elementar de classificação de controle de tráfego.



4.5 Vigilante (policer)
Esse mecanismo elementar é somente usado no controle de tráfego Linux como parte de um filtro. Um guarda chama uma ação acima e uma outra ação abaixo da taxa especificada. O uso hábil de guardas pode simular um medidor de três cores. Veja também a Seção 10, “Diagrama”.

Muito embora tanto o policiamento quanto a shaping sejam elementos básicos do controle de tráfego para limitar o uso de largura de banda, um guarda nunca vai atrasar o tráfego. Ele somente pode executar uma ação baseada no critério especificado. Veja também o Exemplo 5, “tc filter”.



4.6 drop
Esse mecanismo básico de controle de tráfego é usado somente no controle de tráfego Linux como parte de um guarda. Qualquer guarda associado a qualquer filtro pode ter uma ação descartar.


Obs.:
O único lugar no sistema de controle de tráfego Linux onde um pacote pode ser explicitamente descartado é em um guarda. Um guarda pode limitar pacotes enfileirados a uma taxa específica, ou pode ser configurado para descartar todo tráfego que bate com um padrão particular [6].


Existem, contudo, lugares dentro do sistema de controle de tráfego onde um pacote pode ser descartado como um efeito colateral. Por exemplo, um pacote será descartado se o escalonador empregado usa esse método para controlar fluxos como faz o GRED.

Também, um shaper ou escalonador que esteja rodando fora do seu espaço de buffer alocado pode precisar descartar particularmente um pacote durante uma rajada ou em um período sobrecarregado.



4.7 Handle
Toda classe e qdisc classful (veja também Seção 7, “Classful Queuing Disciplines (qdisc’s)”) exigem um identificador único dentro da estrutura de controle de tráfego. Esse identificador único é conhecido como handle e tem dois membros eleitor, o número major e o número minor. Esses números podem ser atribuídos arbitrariamente pelo usuário em consonância com as seguintes regras [7].

A numeração dos handle’s para classes e qdisc’s

major
Esse parâmetro é completamente livre de significado ao kernel. O usuário pode usar um esquema de numeração arbitrário, contudo, todos os objetos na estrutura de controle de tráfego com o mesmo parent (genitor) precisam compartilhar um número handle major. Esquemas de numeração convencional começa com 1 para objetos associados diretamente a qdisc root.

minor
Esse parâmetro identifica de forma não ambígua o objeto como uma qdisc se minor for 0. Qualquer outro valor identifica o objeto como uma classe. Todas as classes que compartilhar um genitor precisam ter números minor únicos.

O handle especial ffff:0 é reservado para a qdisc ingress.

O handle é usado como o alvo nas frases classid e flowid das instruções ‘tc filter’. Esses handle’s são identificadores externos para os objetos, usáveis pelas aplicações do espaço de usuário. O kernel mantém identificadores internos para cada objeto.



________________________________________
[5] Uma qdisc classful pode ter somente classes descendentes do seu tipo. Por exemplo, uma qdisc HTB pode ter somente classes HTB como descendentes. Uma qdisc CBQ não pode ter classes HTB como descendentes.

[6] Nesse caso, você teria um filtro que usa um classificador para selecionar os pacotes que você deseja descartar. Então você usaria um policer com uma ação drop igual aqui: police rate 1bps burst 1 action drop/drop.

[7] Eu não sei a faixa e nem a base desses números. Eu acredito que eles sejam números u32 hexadecimais, mas preciso confirmar isso.
















terça-feira, 10 de fevereiro de 2009

Software e Ferramentas




Autor Original do texto:

Martin A. Brown
martin@linux-ip.net
http://linux-ip.net





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    \ 1
> dev eth0 \ 2
> root \ 3
> handle 1:0 \ 4
> htb 5


1Adiciona (add) uma disciplina de enfileiramento. O verbo também pode ser del.
2Especifica o dispositivo no qual estamos amarrando a nova disciplina de enfileiramento.
3Isso 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.
4O 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.
5Essa é 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 \ 1
> dev eth0 \ 1
> parent 1:1 \ 1
> classid 1:6 \ 1
> htb \ 1
> rate 256kbit \ 1
> ceil 512kbit 1


1Adiciona (add) uma classe. O verbo também pode ser del.
2Especifica o dispositivo no qual nós estamos associando a nova classe.
3Especifica o handle pai ao qual estamos associando a nova classe.
4Esse é um handle (major:minor) único que identifica essa classe. O número minor precisa ser qualquer número diferente de zero.
5Ambas 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.
67Esses 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 \ 1
> dev eth0 \ 2
> parent 1:0 \ 3
> protocol ip \ 4
> prio 5 \ 5
> u32 \ 6
> match ip port 22 0xffff \ 7
> match ip tos 0x10 0xff \ 8
> flowid 1:6 \ 9
> police \ 10
> rate 32000bps \ 11
> burst 10240 \ 12
> mpu 0 \ 13
> action drop/continue 14


1Adiciona (add) um filtro. O verbo pode ser também del.
2Especifica o dispositivo no qual estamos associando o novo filtro.
3Especifica o handle genitor ao qual estamos associando o novo filtro.
4Esse parâmetro é exigido. Seu uso deve ser óbvio, ainda que Eu não saiba mais.
5O parâmetro prio permite a um dado filtro ser preferido acima de um outro. O parâmetro pref é sinônimo.
6Esse é um classificador, e é frase exigida em todo comando tc filter.
78Esses 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.
9O parâmetro flowid especifica o handle da classe alvo (ou qdisc) para a qual um filtro que faz match deve enviar seus pacotes selecionados.
10Esse é o policer, e é uma frase opcional em todo comando tcfilter.
11O guarda executará uma ação acima dessa taxa, e uma outra ação abaixo dessa taxa (veja o parâmetro action).
12O parâmetro burst é uma analogia exata para burst em HTB (burst é um conceito de buckets).
13A unidade mínima vigiada. Para levar em conta todo o tráfego, use um mpu de zero.
14O 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.




















Creative Commons License
Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP
by Cléviton Mendes de Araújo is licensed under a Creative Commons Atribuição 2.5 Brasil License.