Qualidade de Serviços para Gateways Linux (QoS)

Este artigo visa visa informar sobre os aspectos e implementação de qualidade de serviço para roteadores Linux através da classificação e policiamento de diferentes tipos de tráfego Internet. Trata-se de uma forma de otimizar o uso de banda disponível para acesso externo.

[ Hits: 159.992 ]

Por: Gustavo Carvalho em 28/07/2006


Comprovando o funcionamento dos mecanismos de QoS



Para termos uma idéia dos resultados obtidos, abaixo serão mostrados alguns testes que foram realizados e que provam a eficácia do modelo apresentado. Como já falado, o protocolo ICMP que fora alocado com prioridade máxima será o nosso mecanismo de teste.

Primeiramente, antes mesmo da execução do script de QoS, executando duas ações simultâneas, sendo estas um teste de ping e uma transferência de arquivo, podemos observar a latência dos pacotes ICMP.

a) PING para 64.233.179.104, sem quaisquer outras atividades de rede, sem QoS:

$ ping 64.233.179.104 -t
Pinging 64.233.179.104 with 32 bytes of data:
Reply from 64.233.179.104: bytes=32 time=190ms TTL=241
Reply from 64.233.179.104: bytes=32 time=192ms TTL=241
Reply from 64.233.179.104: bytes=32 time=192ms TTL=241
Reply from 64.233.179.104: bytes=32 time=190ms TTL=241
Reply from 64.233.179.104: bytes=32 time=196ms TTL=241
Reply from 64.233.179.104: bytes=32 time=192ms TTL=241
Reply from 64.233.179.104: bytes=32 time=197ms TTL=241
Reply from 64.233.179.104: bytes=32 time=196ms TTL=241
Reply from 64.233.179.104: bytes=32 time=193ms TTL=241
Reply from 64.233.179.104: bytes=32 time=197ms TTL=241
Reply from 64.233.179.104: bytes=32 time=192ms TTL=241
Reply from 64.233.179.104: bytes=32 time=192ms TTL=241
Reply from 64.233.179.104: bytes=32 time=196ms TTL=241
Reply from 64.233.179.104: bytes=32 time=193ms TTL=241
Reply from 64.233.179.104: bytes=32 time=197ms TTL=241
Reply from 64.233.179.104: bytes=32 time=197ms TTL=241
Reply from 64.233.179.104: bytes=32 time=196ms TTL=241
Reply from 64.233.179.104: bytes=32 time=192ms TTL=241
Reply from 64.233.179.104: bytes=32 time=193ms TTL=241
Reply from 64.233.179.104: bytes=32 time=188ms TTL=241
Reply from 64.233.179.104: bytes=32 time=192ms TTL=241
Reply from 64.233.179.104: bytes=32 time=187ms TTL=241
Reply from 64.233.179.104: bytes=32 time=197ms TTL=241
Reply from 64.233.179.104: bytes=32 time=200ms TTL=241
Reply from 64.233.179.104: bytes=32 time=193ms TTL=241
Reply from 64.233.179.104: bytes=32 time=193ms TTL=241
Reply from 64.233.179.104: bytes=32 time=192ms TTL=241
Reply from 64.233.179.104: bytes=32 time=189ms TTL=241
Reply from 64.233.179.104: bytes=32 time=192ms TTL=241
Reply from 64.233.179.104: bytes=32 time=188ms TTL=241
Reply from 64.233.179.104: bytes=32 time=192ms TTL=241
Reply from 64.233.179.104: bytes=32 time=197ms TTL=241
Reply from 64.233.179.104: bytes=32 time=196ms TTL=241
Reply from 64.233.179.104: bytes=32 time=193ms TTL=241

Ping statistics for 64.233.179.104:
    Packets: Sent = 34, Received = 34, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 187ms, Maximum = 200ms, Average = 193ms

--- Latência não passa de 200ms.

b) PING para 64.233.179.104, no momento da transferência de um arquivo, com Qos habilitado.

Buscando imagem iso:

$ wget -c ftp://ftp.planetmirror.com/pub/Mandrake/devel/iso/10.1/i586/\
Mandrakelinux-10.1-Community-Download-CD1.i586.iso
...
 0% [                ] 1,896,316     23.4K/s  ETA 7:43:12

-- Taxa de transferência de 23Kbytes/s
Latência do PING:

$ ping 64.233.179.104 -t
Pinging 64.233.179.104 with 32 bytes of data:
Reply from 64.233.179.104: bytes=32 time=253ms TTL=241
Reply from 64.233.179.104: bytes=32 time=225ms TTL=241
Reply from 64.233.179.104: bytes=32 time=237ms TTL=241
Reply from 64.233.179.104: bytes=32 time=290ms TTL=241
Reply from 64.233.179.104: bytes=32 time=226ms TTL=241
Reply from 64.233.179.104: bytes=32 time=224ms TTL=241
Reply from 64.233.179.104: bytes=32 time=491ms TTL=241
Reply from 64.233.179.104: bytes=32 time=450ms TTL=241
Reply from 64.233.179.104: bytes=32 time=199ms TTL=241
Reply from 64.233.179.104: bytes=32 time=216ms TTL=241
Reply from 64.233.179.104: bytes=32 time=191ms TTL=241
Reply from 64.233.179.104: bytes=32 time=296ms TTL=241
Reply from 64.233.179.104: bytes=32 time=456ms TTL=241
Reply from 64.233.179.104: bytes=32 time=512ms TTL=241
Reply from 64.233.179.104: bytes=32 time=418ms TTL=241
Reply from 64.233.179.104: bytes=32 time=376ms TTL=241
Reply from 64.233.179.104: bytes=32 time=389ms TTL=241
Reply from 64.233.179.104: bytes=32 time=229ms TTL=241
Reply from 64.233.179.104: bytes=32 time=261ms TTL=241
Reply from 64.233.179.104: bytes=32 time=193ms TTL=241
Reply from 64.233.179.104: bytes=32 time=243ms TTL=241
Reply from 64.233.179.104: bytes=32 time=295ms TTL=241
Reply from 64.233.179.104: bytes=32 time=239ms TTL=241
Reply from 64.233.179.104: bytes=32 time=238ms TTL=241
Reply from 64.233.179.104: bytes=32 time=197ms TTL=241
Reply from 64.233.179.104: bytes=32 time=230ms TTL=241
Reply from 64.233.179.104: bytes=32 time=489ms TTL=241
Reply from 64.233.179.104: bytes=32 time=448ms TTL=241
Reply from 64.233.179.104: bytes=32 time=205ms TTL=241
Reply from 64.233.179.104: bytes=32 time=213ms TTL=241
Reply from 64.233.179.104: bytes=32 time=192ms TTL=241
Reply from 64.233.179.104: bytes=32 time=195ms TTL=241
Reply from 64.233.179.104: bytes=32 time=472ms TTL=241
Reply from 64.233.179.104: bytes=32 time=538ms TTL=241
Reply from 64.233.179.104: bytes=32 time=496ms TTL=241
Reply from 64.233.179.104: bytes=32 time=403ms TTL=241
Reply from 64.233.179.104: bytes=32 time=362ms TTL=241
Reply from 64.233.179.104: bytes=32 time=270ms TTL=241
Reply from 64.233.179.104: bytes=32 time=301ms TTL=241
Reply from 64.233.179.104: bytes=32 time=194ms TTL=241
Reply from 64.233.179.104: bytes=32 time=303ms TTL=241
Reply from 64.233.179.104: bytes=32 time=194ms TTL=241
Reply from 64.233.179.104: bytes=32 time=266ms TTL=241
Reply from 64.233.179.104: bytes=32 time=302ms TTL=241

Ping statistics for 64.233.179.104:
    Packets: Sent = 44, Received = 44, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 191ms, Maximum = 538ms, Average = 304ms

--- Média de 300ms

c) Mantendo a transferência de arquivo, e removendo o QoS:

$ ping 64.233.179.104 -t
Pinging 64.233.179.104 with 32 bytes of data:
Reply from 64.233.179.104: bytes=32 time=1279ms TTL=241
Reply from 64.233.179.104: bytes=32 time=1316ms TTL=241
Reply from 64.233.179.104: bytes=32 time=1381ms TTL=241
Reply from 64.233.179.104: bytes=32 time=1435ms TTL=241
Reply from 64.233.179.104: bytes=32 time=1488ms TTL=241
Reply from 64.233.179.104: bytes=32 time=1541ms TTL=241
Reply from 64.233.179.104: bytes=32 time=1597ms TTL=241
Reply from 64.233.179.104: bytes=32 time=1647ms TTL=241
Reply from 64.233.179.104: bytes=32 time=1700ms TTL=241
Reply from 64.233.179.104: bytes=32 time=1753ms TTL=241
Reply from 64.233.179.104: bytes=32 time=1819ms TTL=241
Reply from 64.233.179.104: bytes=32 time=1868ms TTL=241
Reply from 64.233.179.104: bytes=32 time=1859ms TTL=241
Request timed out.
Reply from 64.233.179.104: bytes=32 time=2069ms TTL=241
Reply from 64.233.179.104: bytes=32 time=2124ms TTL=241
Reply from 64.233.179.104: bytes=32 time=2180ms TTL=241

Ping statistics for 64.233.179.104:
    Packets: Sent = 17, Received = 16, Lost = 1 (5% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1279ms, Maximum = 2180ms, Average = 1691ms

---- Máximo de 2 segundos!!!!!! E ainda observamos perda de pacote!!!

Com isto, pudemos comprovar o funcionamento do script apresentado.

Quaisquer dúvidas, esclarecimentos ou mesmo críticas (construtivas :) ), pode entrar em contato.

Abs a todos!

Gustavo Carvalho

Página anterior    

Páginas do artigo
   1. Introdução ao QoS e identificação do cenário base
   2. Projetando e configurando as políticas de QoS
   3. Classificando os tráfegos de interesse
   4. Comprovando o funcionamento dos mecanismos de QoS
Outros artigos deste autor
Nenhum artigo encontrado.
Leitura recomendada

Instalando o Cacti em plataforma Debian

Instalando o aMSN com suporte a SSL no OpenBSD

Como montar um proxy reverse no servidor Apache

Enjaulando o Bind9 em um chroot

Sistemas Operacionais Online

  
Comentários
[1] Comentário enviado por TheHawk em 28/07/2006 - 10:39h

Interessante isso, acho que vou tentar colocar isso em operação, se funcionar vai ficar show o serviço.

[2] Comentário enviado por fabianotecnico em 28/07/2006 - 11:03h

cara
se eu te contar tu não acredita..to sofrendo pra fazer o htb funcionar...já estou bem no processo...mas faltam alguns detalhes..por exemplo

eu tenho
eth0 - rede interna

e a
eth1 - speedy ip fixo.

só que quando levanto o htb com a configuração de 128 kbits a rede fica lenta e o SSH fica lento todas as portas ficam lentas..só que coloquei para funcionar a regra só na porta 80, o MSN caiu e as outras portas ficaram lentas.

vc já colocou o HTB pra funcionar?

essas regras TC o que faço com elas
coloco em algum arquivo...como que funciona..faltou só explicar isso.

blz.
no aguardo
fabiano

ME DE UM HELP.

[3] Comentário enviado por alvaromo em 28/07/2006 - 11:04h

Muito bom. Tirou o restante de minhas dúvidas sobre o assunto e aqui já implementei segundo as orientações de seu tuto.

[4] Comentário enviado por thelinux em 28/07/2006 - 14:18h

Cara, não posso deixar de dá parabéns não só pelo excelente artigo, mas pelo assunto abordado. Existe muito pouca documentação em português do mesmo.
Sucesso.

[5] Comentário enviado por gustavo.carvalho em 29/07/2006 - 23:44h

Pessoal. Primeiramente agradeço os comentários!

Fabiano, conforme vc havia perguntado, eu já tenho um ambiente funcionando perfeitamente com o o HTB. Mas para que eu possa te ajudar melhor vc vai precisar me passar melhores detalhes do seu problema.
Com relação às regras TC, elas servem para criar filas com diferentes bandas disponíveis. Ex: vc pode criar uma fila para o seu tráfego prioritário (ssh, telnet, snmp), uma segunda para msn, yahoo messenger, icq e uma terceira para o resto (Best Effort). Isto é apenas um exemplo, pois o HTB é capaz de trabalhar de forma hierárquica como seu próprio nome já diz. Ou seja, posso montar uma árvore composta de diferentes filas...

Qualquer coisa é só escrever...

Abs

Gustavo

[6] Comentário enviado por thiagoferreira04 em 31/07/2006 - 08:21h

E como funcionaria para Subnets ou IPs?

[7] Comentário enviado por dailson em 01/08/2006 - 09:51h

Bom artigo amigo... muito bom artigo
Parabéns!

[8] Comentário enviado por guesser em 05/10/2006 - 21:33h

Cara realmente isto é show de bola,

Só me tira umas dúvidas, estou tentando fazer isto na minha rede para priorizar o tráfego de voz e vídeo e não esta dando muito certo quais são as regras que devo utilizar?

[9] Comentário enviado por removido em 20/10/2006 - 12:15h

parabens

[10] Comentário enviado por gustavo.carvalho em 20/10/2006 - 13:24h

Olá pessoal! Primeiramente agradeçco os comentários! Valeu mesmo!

Agora, respondendo ao guesser...

Para que você possa priorizar tráfegos de voz e vídeo basta que você saiba quais portas UDP os mesmos trabalham OU você pode também utilizar o iptables para classificar os tráfegos pelos IPs de origem das estações que envolvidas. Se você tem um servidor de vídeo por exemplo, poderá utilizar a classificação puramente por IP.
Abs

[11] Comentário enviado por balani em 21/10/2006 - 11:07h

Muito bom e util seu artigo

[12] Comentário enviado por lduarte10 em 31/10/2006 - 14:11h

fabianotecnico, cara o htb ele limita o trafego na sua interface. da uma olhada nesse link http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm

olhe esse ex. onde eth0 é a if local

tc qdisc add dev eth0 root handle 1: htb default 12
tc class add dev eth0 parent 1: classid 1:1 htb rate 100000kbit ceil 100000kbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 80000kbit ceil 100000kbps

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 10.0.0.0 match ip dport 80 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 10.0.0.0 match ip dport 22 0xffff flowid 1:10

Assim todo mundo da rede 10.0.0.0 vai compartilhar de 80mb a 100mb quando forem acessar a porta 80 e 22

acho que essas regras podem te ajudar

[13] Comentário enviado por lduarte10 em 31/10/2006 - 14:50h

Alguem tem alguma dica para controle de upload para programas como kazaa, e-mule, bittorrent ??? quero limitar o upload destes programas na rede, pois quando o upload esta alto a NAVEGAÇÃO web fica muito lenta. o upload alto nao influencia na taxa de download (ou influencia pouco), as é notavel quando vai navegar em painas web, jah fiz o teste, a tulização da banda (download) nao esta nem 10% mas o upload estava em 95%-100% e a navegação ficou super lenta, mas quando coloquei para fazer download a taxa estava alta. é meio estranho, ate se alguem tiver uma explicação logica pra isso poderia postar né?

[14] Comentário enviado por ecbr em 06/11/2006 - 07:30h

se nao me engando o htb so controla o trafego de saida, entao eu me pergunto, como as suas regras pode ta funcinando sendo que na maioria vc usou o PREROUTING que trabalha no trafego de entrada, se nao me engano o certo seria o POSTROUTING ou OUTPUT ou ate mesmo FORWARD.

[15] Comentário enviado por gustavo.carvalho em 07/11/2006 - 12:56h

ola amigo. Primeiramente agradeço o comentário. No entanto, o material apresentado é realmente funcional. O htb realmente apenas trabalha com tráfego de saída, ou seja, para que se possa influenciar o tráfego de entrada de uma interface de uplink (internet) é necessário OBRIGATORIAMENTE trabalhar com a saída do tráfego na interface de downlink (rede interna) e vice-versa. Aí está a mágica ...
Abs

[16] Comentário enviado por fernandosilva em 22/11/2006 - 07:56h

Eu trabalho com servidores linux e acho muito bom, pois ñ tenho um software que me de maior segurança como o linux... E ainda mais com o controle pelo nagios, fica td mais fácil...

[17] Comentário enviado por mredd em 04/12/2006 - 08:45h

Olá.

Achei excelente este artigo... mas estou apanhando para fazer QoS entre várias interfaces de rede. Eu tenho um gateway com 4 interfaces de rede, onde a eth0 está um velox de 1Mbps e as outras 3 interfaces estao conectadas a 3 redes distintas. Nao consigo fazer QoS para as 3 redes.

Abs

[18] Comentário enviado por hilmilho em 06/01/2007 - 20:33h

Alguém realizou os mesmos testes em máquinas diferentes? Tipo um fazer download, outra fazer ping? Aqui não tá fazendo efeito em máquinas diferentes...

Será que é o HUB? Tipo o download "engarrafa" o hub, fazendo as outras máquinas mais lentas... Alguma solução pra isso?

[19] Comentário enviado por gustavo.carvalho em 07/01/2007 - 13:29h

Deve existir algum ponto que não está legal nas suas configurações.
Mesmo considerando-se que HUBs realmente prejudicam o desempenho de redes internas pela quantidade de broadcasts, as configurações de QoS descritas no artigo resolvem em parte este problema. Na realidade o que você deve estar deixando ocorrer é a utilização de 100% da banda para downloads... Você deve ajustar a taxa de utilizacao CEIL para classe Best Effort em um valor um pouco abaixo do total disponível. Isso deve ajudar...

Abs

[20] Comentário enviado por gustavo.carvalho em 07/01/2007 - 13:32h

Respondendo ao mredd....

O que realmente está acontecendo ? Vc está recebendo mensagens de erro quando cria as filas para mais de uma interface ?

Abs

[21] Comentário enviado por cytron em 08/01/2007 - 10:35h

Estive pensando em implantar essa técnica em um provedor, mas fica meio complicado, pois eu precisaria saber o real tráfego de um tal serviço para poder especificar a largura nas regras, mas os clientes nunca vão usar o serviço ao mesmo tempo para eu poder chegar a um valor real, e o pior ainda, a medida que novos clientes vão chegando é preciso refazer os valores novamente.

Existe uma outra maneira que poderia resolver essa questão?
O ideal seria por porcentagem, mas aí já é querer demais. hehe.

Atualmente estou usando apenas priorização de protocolos através do iptables.

O que eu poderia fazer para melhorar?

[22] Comentário enviado por hilmilho em 08/01/2007 - 16:19h

Valeu Gustavo, realmente tá funcionando mesmo pelo hub... Foi algum erro nas velocidades... Eu fiz um teste e minha conexão que é de 128 dá uns 102 kbit... então eu mudei ligeiramente as taxas ceil pra 100 e a ceil :30 pra 80... No meu caso nem me preocupo com largura de banda pq não tenho muita mesmo, mas o que quero é latência boa e com esse exemplo funcionando devo me aventurar mais nessa área...
Agora mesmo vou tentar acrescentar outra interface da rede interna ao script... flw!

[23] Comentário enviado por hilmilho em 04/02/2007 - 12:50h

Alguém sabe que regras devo usar afim de permitir compartilhamento de arquivos no windows?

[24] Comentário enviado por cbpower2000 em 28/02/2007 - 22:44h

ola amigo, busco um profissional capaz de resolver um problemao de p2p aqui na rede da empresa, percebi que voce pode nos ajudar, se puder por favor entre em contato em willians@rededisquenet.com que lhe passo maiores detalhes, obrigado!

[25] Comentário enviado por capitainkurn em 14/03/2007 - 12:02h

Excelente artigo! Muito didático e elucidativo.

[26] Comentário enviado por efloriani em 02/05/2007 - 11:43h

Ola,

Primeiramente, parabéns pelo artigo.

tc class add dev ppp0 parent 1: classid 1:1 htb rate 128kbit ceil 128kbit

Gostaria de saber o que essa regra está dizendo....
Ela nao possui prioridade.... mas o 128Kbit fazem parte do somatório dos 256kbit disponíveis...

Aguardo retorno.

[27] Comentário enviado por fonoavancada em 17/05/2007 - 18:14h

muito bom artigo!!
abraços

[28] Comentário enviado por guttoballa em 20/05/2007 - 14:00h

Gostei do seu artigo... Parabéns, já usei o HTB configurando mais ou menos igual ao seu. Depois fui usar o HTB Tools, achei fácil usar ele, pq ele ta liberando o q vem da cache do squid a full... para meus clientes, desta forma é interessante ter cache. Vc sabe como incluir a cache a full neste script seu?

[29] Comentário enviado por els2net em 29/05/2007 - 14:42h

Gustavo, primeiramente parabéns, a matéria é excelente e extremamente necessária para todos do ramo.

Féra, não sei onde errei, mas após, implantar o QoS, seguindo seu exemplo, meu upload não esta passando de 128K mesmo para os serviço que estão com prio 1, que nesse caso deveria atingir 512K.

Outro detalhe, como eu faço para tirar o QoS da memória para que eu possa ir isolando as regras?

Agradeço qualquer ajuda bem como seus comentários.
Edson

[30] Comentário enviado por camolez em 16/07/2007 - 16:28h

Muito bom mesmo !!!

[31] Comentário enviado por tuxSoares em 03/08/2007 - 00:20h

Essa questão da marcação de pacotes é bem sinistra, irei me aperfeiçoar mais no assunto, mas seu artigo ja deu uma boa ideia de como funciona.
voce esta de parabens, continue contribuindo com a comunidade

Grande abraco.

[32] Comentário enviado por paulouber em 06/08/2007 - 22:36h

muito interessante.

abraços

[33] Comentário enviado por scsidney em 24/08/2007 - 18:53h

Bom!!!

Apreciei muito seu artigo a pouco tempo efetuei tal função em switch gerenciáveis, não conhecia tal funcionalidade no Linux.

Tentarei aplicar em produção tais funcionadades.

Qual o material fonte, de consulta que você trabalhou. podereia postar o nome das consultas?

Grande Abraço

[34] Comentário enviado por sdr_smart em 25/09/2007 - 14:47h

interessante !
parabens

[35] Comentário enviado por gandiva em 13/10/2007 - 20:54h

Otimo artigo, valeu!
Estou tentando efetuar alguns testes. Em breve postarei os resultados!

Abraço a todos!

[36] Comentário enviado por fnpaulinos em 15/10/2007 - 12:32h

Olá Gustavo. Muito bom seu artigo.
Tenho um Debian como roteador da minha rede interna e já reparei que quando utilizo Emule, Torrent e afins em uma outra máquina (XP), ou seja, quando o número de conexões tcp é maior, a navegação fica lenta, quase impossível. Será que consigo um melhor desempenho aplicando as regras de QoS aqui descritas? Não tenho esses problemas quando utilizo um Router Linksys com firmware alterado, mas também não consegui saber o que o permite trabalhar sem problemas.
Atenciosamente,
Fábio Nunes.

[37] Comentário enviado por gtcesar em 07/02/2008 - 13:51h

sistema
completo de Ordem de Serviço,
Peço apenas que me deixe os creditos na pagina do menu, e use avontade.

Instalação
execute o data.sql que esta destro do diretorio sql
depois altere a conexão data.php que esta dentro do diretorio connections

depois é só usar o sistema a vontade, só peço que deixem os creditos
na pagina menu.php,
já que estou disponibilizando este sistema de graça e gostaria de ser
lembrado por isso,
qualquer alteração que de melhorias ao sistema, postem novamente aqui
no site e coloquem,
no campo versão do menu.php, a devida numeração e acrescente junto ao
meu nome o credito referente a pessoa que adcionou,
se quem usar o sistema for honesto nestes quesitos, eu prometo colocar
o sistema de estoque todo em ajax que estou desenvlvendo.

mande a solicitação ao costamarques@gmail.com que eu mando o sistema, se quiser pode pegar em plugmasters.com.br,codigolivre.com.br


quem quiser baixar sem dar satisfações pode ir direto ao link: http://www.intersatonline.com/sistema.rar

[38] Comentário enviado por amunizbr em 20/02/2008 - 13:40h

Ola,

O htb pode ser utilizado para controlar a banda tanto de entrada como de saida, so depende do bom entendimento de tc

[39] Comentário enviado por ygorre em 02/03/2008 - 12:39h

Ola.

O que são essas configurações de DSCP? Elas alteram algo no controle de banda?

Obrigado.

[40] Comentário enviado por paulopmt1 em 07/03/2008 - 17:45h

Excelente artigo! show de bola cara. era bem isso que eu estava precisando. Bom segui suas regras e criei um arquivo chamado script.sh e as coloquei dentro. quando rodo o arquivo tenho o retorno:
debian:/home/paulo/qos# ./script.sh
What is "rete"?
Usage: ... qdisc add ... htb [default N] [r2q N]
default minor id of class to which unclassified packets are sent {0}
r2q DRR quantums are computed as rate in Bps/r2q {10}
debug string of 16 numbers each 0-3 {0}

... class add ... htb rate R1 [burst B1] [mpu B] [overhead O]
[prio P] [slot S] [pslot PS]
[ceil R2] [cburst B2] [mtu MTU] [quantum Q]
rate rate allocated to this class (class can still borrow)
burst max bytes burst which can be accumulated during idle period {computed}
mpu minimum packet size used in rate computations
overhead per-packet size overhead used in rate computations
ceil definite upper class rate (no borrows) {rate}
cburst burst but for ceil {computed}
mtu max packet size we create rate map for {1600}
prio priority of leaf; lower are served first {0}
quantum how much bytes to serve from leaf at once {use r2q}

TC HTB version 3.3
RTNETLINK answers: Invalid argument

o que será que está errado? uso debian sarge e tenho o iproute instalado. Agradeço qualquer ajuda...
Abraço galera do VOL

[41] Comentário enviado por llordvic em 03/06/2009 - 21:45h

Boa noite turma

cara, grande tutorial, parabéns, consegui entender os parametros do tc, mas gostraria de saber se é possivel
ajustar taxas para ips individualmente, tipo, o modelo a baixo q encontrei noutro tuto

tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 1000000kbit

tc class add dev eth0 parent 1:1 classid 1:10 htb rate 512kbit # ceil 512kbit

tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10

U32="tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip src 192.168.1.10/24 "

$U32 match ip dst 10.0.0.10/24 flowid 1:10
$U32 match ip dst 10.0.0.12/24 flowid 1:10
$U32 match ip dst 10.0.0.13/24 flowid 1:10

a eth0 é a rede interna.
e outra, o rate da classid 1:1 htb da eth0 tem q ser em funçao da taxa da ppp0 ?

claro q eu ainda nao fiz os testes, gostaria de uma opiniao sua antes de tentar e quebrar a cabeça, ja q vc tem uma experiencia anterior.

[42] Comentário enviado por gustavo.carvalho em 13/06/2009 - 15:25h

Amigo, você pode seguir a mesma linha de raciocínio utilizada para construção do script postado aqui, criando as classes, definindo suas bandas e transbordos, e no iptables classificar o tráfego baseando-se apenas nas subredes IP e não por portas TCP ou UDP. Desta forma você poderia utilizar o mesmo esqueleto já descrito aqui com pequenas modificações...

Espero ter ajudado! Abs. Gustavo

[43] Comentário enviado por refinski em 24/03/2014 - 07:09h

Bom dia Gustavo, tudo bem?
Estou fazendo o TCC da faculdade e preciso criar uma topologia de uma rede voip entre uma matriz e uma filial, so que nao tenho ideia como fazer, acredito que eu tenha que usar dois roteadores, um servidor voip(asterisk) na matriz, vou usar dois micros para comunicação voip, e minha duvida e se tenho que criar dois servidores um de cada lado para usar iptables com HTB para tratar o QoS, queria saber onde ficaria nesta topologia os servidores, usaria como gateway? visto que meu tcc sera uma comparacao de QoS entre CISCO e LINUX, se puder me dar uma luz te agradeco, grande abraco.

[44] Comentário enviado por Aleciano em 25/04/2016 - 01:09h

Ótimo artigo! Funcionou perfeito!!

Um detalhe é que hoje em dia (2016), com conexõe de internet que atingem facilmente de 1--5 Mbps, algumas das regras ficam difíceis de serem testadas pois a conexão já comporta suficientemente tudo que você for fazer. Por exemplo, sem Qos Algum, testando ping + download, não há taaaanta diferença pra o QoS ativo para pacotes ICMP e tcp porta 80. Se vocÊ excluir a regra do ICMP, até que nota um certo jitter, mas não é lá estas coisas.

Então é importante ter isso em mente para entender o funcionamento durante os testes das regras.
o/


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts