Qualidade de Serviços para Gateways Linux (QoS)

Autor: Gustavo Carvalho <gus_acs at yahoo.com.br>

Introdução ao QoS e identificação do cenário base

Este documento visa informar e servir como base para criação de um modelo de qualidade de serviço para gateways Linux.

Primeiramente, para podermos obter uma melhor visão sobre o modelo adotado, devemos ter melhor entendimento de alguns detalhes sobre QoS.

Quando falamos de policiamento, estamos visando em adequar um determinado tráfego a uma determinada taxa de transmissão, sendo que todo o excedente deverá ser descartado ou mesmo remarcado com uma nova prioridade.

Pelo contrário, quando falamos de shaping, consideramos o armazenamento dos pacotes excedentes em buffers, de tal forma a evitar o descarte dos pacotes no momento que uma determinada taxa de transmissão é ultrapassada.

Válido informar que o modelo aqui descrito está puramente baseado em policiamento de tráfego e não shaping do mesmo.

De acordo com a topologia abaixo, poderemos ter uma melhor visualização do cenário base.

Pode-se claramente observar que trata-se da presença de um acesso ADSL (256K/128K) através da interface ppp0 do gateway Linux e a interface eth1 do mesmo pertencente à rede interna.

O endereço da rede interna é 10.1.1.0/24, sendo que o IP configurado na interface eth1 é 10.1.1.10/24. O host interno possui endereço 10.1.1.5/24.

Iniciando a criação do modelo de QoS baseado na arquitetura DiffServ, ou seja, através da criação de classes de serviço, escolhe-se o número de classes que serão utilizadas para segregar o tráfego total passante.

Importante lembrar, conforme comentado anteriormente neste documento, que estamos trabalhando com policiamento, ou seja, sempre estamos nos baseando no tráfego de saída de uma interface.

Quando se pensa em adequar um determinado tráfego entrante a uma interface, estamos falando do mecanismo de shaping, que através do armazenamento de pacotes, informa ao originador do tráfego , que o mesmo deve abaixar a sua taxa de transmissão, de maneira que se possa suportar e alocar os pacotes nos buffers, sem que ocorram perdas (BUFFERs SÃO FINITOS!).

Tem-se como um resumo de tudo comentado acima, o fato de que, para controlarmos o tráfego sainte, devemos criar classes de serviço para a interface de saída ppp0, e para o tráfego de entrada, devemos policiá-lo através de outras classes de serviço para a interface eth1.

Só conseguimos realizar o policiamento de entrada (tráfego vindo da internet) depois que o mesmo entre pelo interface ppp0 e seja encaminhado para a interface eth1, daí o motivo deste modelo adotado.

Importante informar que estaremos utilizando a arquitetura de QoS em Linux chamada HTB, devido à sua maior simplicidade e melhor desempenho em termos de processamento. Para melhores explicações dos pré-requisitos necessários para utilização do HTB, visite:

Projetando e configurando as políticas de QoS

O meu ambiente de testes é formado por um gateway Mandrake Linux 10.1.

Iremos neste momento dar início ao script. Comentários e observações serão presentes antes e depois dos comandos.

tc qdisc add dev ppp0 root handle 1: htb default 30
tc class add dev ppp0 parent 1: classid 1:1 htb rate 128kbit ceil 128kbit
tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 28kbit ceil 128kbit prio 1
tc class add dev ppp0 parent 1:1 classid 1:20 htb rate 50kbit ceil 128kbit prio 2
tc class add dev ppp0 parent 1:1 classid 1:30 htb rate 50kbit ceil 110kbit prio 3

As linhas acima dizem que para a interface ppp0, teremos uma hierarquia de 3 classes de serviço pertencentes a uma dada raiz:

 

 

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s