Sempre fui fiel usuário do htb-tools para controle de tráfego do meu roteador de internet na prefeitura de Terra de Areia. É claro que o uso do htb-tools dá-se principalmente pela minha completa falta de competência em saber lidar com o comando tc "na unha".
Minha estrutura é simples, por isto mantenho o squid nesta mesma máquina fazendo nat, o que sempre me trouxe o problema do controle preciso de upload, pois com nat e squid, definitivamente não dá pra fazer controle de upload da mesma forma "simples" que download.
Estes dias passei a estudar traffic control para linux e htb no intuito de preparar um novo roteador que me permitisse controle preciso de download e upload e para isto é lógico que precisava separar o nat e o squid para outra máquina a fim de manter de forma simples estes controles.
Até estava pensando em continuar usando htb-tools, afinal sempre fez muito bem seu trabalho, mas um htb generate eth0 (por exemplo) gerou uma infinidade de regras totalmente incompreensíveis para mim e decidi que queria saber como funcionam as suas entranhas.
A princípio sempre soube que o controle de tráfego é sempre feito no fluxo (interface) de saída e como faço controle de upload com htb-tools ele muda esta política e passa a controlar pelo fluxo de entrada (ingress, pelo menos eu acho).
Ainda estou totalmente cru com todos os conceitos envolvidos em controle de tráfego e com a forma de aplicá-los com o comando tc, por isto resolvi escrever minhas memórias como forma de documentação do meu aprendizado e para que as bondosas almas possam indicar-me minhas falhas.
Sem dúvida o fórum underlinux é minha principal fonte de aprendizado e busca por respostas, mas não posso deixar de citar o manual traduzido do htb e QosLinux.ppt.
Como resultado final deste trabalho pretendo desenvolver uma aplicação em ruby, java, php ou qualquer outra linguagem para que a partir de um arquivo com os ips e taxas de download e upload sejam geradas um conjunto de regras para estes controles.
Ainda não tenho a mínima idéia de como fazer, mas "em cima" do controle de tráfego de cada computador da rede quero fazer também priorização, ou seja, dar prioridade maior para pacotes de voip do que ftp, independente de quem está fazendo download, assim não precisaria prioriza individualmente.
Para começar quero registrar como faria para controlar o tráfego de dowload de um link de 512k entre 4 computadores. A interface da lan (ou saída do tráfego do roteador de internet para a lan) será a eth0, assim as regras para definir taxa garantida de 128k e limite de 512k ficariam assim:
tc qdisc add dev eth0 root handle 1:0 htb default 9
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 512kbit
tc class add dev eth0 parent 1:1 classid 1:9 htb rate 8k
tc class add dev eth0 parent 1:1 classid 1:101 htb rate 128k ceil 512k
tc class add dev eth0 parent 1:1 classid 1:102 htb rate 128k ceil 512k
tc class add dev eth0 parent 1:1 classid 1:103 htb rate 128k ceil 512k
tc class add dev eth0 parent 1:1 classid 1:104 htb rate 128k ceil 512k
tc qdisc add dev eth0 parent 1:9 handle 90: sfq perturb 10
tc qdisc add dev eth0 parent 1:101 handle 1010: sfq perturb 10
tc qdisc add dev eth0 parent 1:102 handle 1020: sfq perturb 10
tc qdisc add dev eth0 parent 1:103 handle 1030: sfq perturb 10
tc qdisc add dev eth0 parent 1:104 handle 1040: sfq perturb 10
tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.101/32 flowid 1:101
tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.102/32 flowid 1:102
tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.103/32 flowid 1:103
tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.104/32 flowid 1:104
Temos assim, a definição do htb como qdisc, a classe que estabelece a capacidade do link em 512k, as classes que definem as taxas para cada ip, as qdisc para cada uma destas classes e os filtros para direcionamento dos tráfegos de saída.
Acredito que seja simplesmente isto para fazer o controle básico de download embora ainda não tenha posto isto em prática. Num futuro gostaria de poder contar com as possíveis vantagens da utilização dos parâmetros quantum, burst e cburst (entre outros).
Por enquanto era isto, assim que conseguir testá-los vou usar basicamente estas mesmas regras com a interface de saída do roteador para o roteador de internet (eth1) para controle de upload, lembrando que não vou fazer nat e nem ter squid neste roteador.
Mostrando postagens com marcador htb. Mostrar todas as postagens
Mostrando postagens com marcador htb. Mostrar todas as postagens
segunda-feira, 16 de fevereiro de 2009
quinta-feira, 24 de janeiro de 2008
Controle de banda para provedor wireless com pouco link para upload
Olha que suamos a camiseta e mesmo assim eu ainda não estou com plena confiança de que está bom. Como sugeria professor de Teoria Geral de Administração, a Administração trata da forma como se gerencia/controla recursos finitos, pois para recursos infinitos não precisamos de gerenciamento/controle.
Pois bem, para download temos bastante banda, não quer dizer que não precisemos de Administração para ela, mas não estamos em um estado tão crítico, mas para upload a coisa está um tanto mais complicada.
Tenho usado htb para Administração de banda desde o princípio (mas a história de como iniciamos o projeto do provedor vai ficar para outros posts), auxiliado pelo htb-tools. Conseguir afinar o arquivo de configuração do htb-tools que será a base para a geração das regras "tc" não parecia tão complicado a princípio, pois claro até então os recursos eram como se fossem quase infinitos, mas agora temos uma grande carteira de clientes e meu upload está me dando trabalho. Se fosse simplesmente atribuir 24kbps para cada cliente e que o htb se virasse com o resto seria o ideal, mas como o htb vai saber qual a melhor de atribuir burst? Como EU vou saber o que isto, burst, significa e como funciona?
A resposta é que não sei e ainda vou continuar pesquisando a este respeito para poder afinar ainda mais minhas configurações e conseguir realmente oferecer serviços de ótima qualidade.
Só escrevi isto tudo aqui porque vai que aparece alguma alma caridosa que já tenha passado por isto e tenha como auxiliar-me nesta demanda. Encontrei o projeto htb-gen e pretendo experimentá-lo a semana que vem.
Abraços a todos.
Pois bem, para download temos bastante banda, não quer dizer que não precisemos de Administração para ela, mas não estamos em um estado tão crítico, mas para upload a coisa está um tanto mais complicada.
Tenho usado htb para Administração de banda desde o princípio (mas a história de como iniciamos o projeto do provedor vai ficar para outros posts), auxiliado pelo htb-tools. Conseguir afinar o arquivo de configuração do htb-tools que será a base para a geração das regras "tc" não parecia tão complicado a princípio, pois claro até então os recursos eram como se fossem quase infinitos, mas agora temos uma grande carteira de clientes e meu upload está me dando trabalho. Se fosse simplesmente atribuir 24kbps para cada cliente e que o htb se virasse com o resto seria o ideal, mas como o htb vai saber qual a melhor de atribuir burst? Como EU vou saber o que isto, burst, significa e como funciona?
A resposta é que não sei e ainda vou continuar pesquisando a este respeito para poder afinar ainda mais minhas configurações e conseguir realmente oferecer serviços de ótima qualidade.
Só escrevi isto tudo aqui porque vai que aparece alguma alma caridosa que já tenha passado por isto e tenha como auxiliar-me nesta demanda. Encontrei o projeto htb-gen e pretendo experimentá-lo a semana que vem.
Abraços a todos.
Assinar:
Postagens (Atom)