+ Responder ao Tópico



  1. #1

    Padrão tc e htb na unha

    Boa tarde galera!

    Vou encurtar um pouco o discurso até porque já escrevi bastante sobre isto (e pretendo escrever mais) em meumaravilhosomundolivre.blogspot.com. Estou tentando "largar" o htb-tools e usar htb diretamente com tc, pra aprendar sobre as "entranhas" do QoS com linux.

    A princípio gostaria que dessem pitaco sobre uma configuração hipotética de 512k de download sendo o controle feito pela interface de saída (eth0) conforme regras abaixo, ou seja, se está correto e se parâmetros como burst, cburst e quantum fariam muita diferença:
    Código :
    [FONT=trebuchet ms][FONT=courier new]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
    [/FONT][/FONT][FONT=trebuchet ms][FONT=courier new]tc class add dev eth0 parent 1:1 classid 1:9 htb rate 8k
    [/FONT][/FONT][FONT=trebuchet ms][FONT=courier new]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
    [/FONT][/FONT][FONT=trebuchet ms][FONT=courier new]tc class add dev eth0 parent 1:1 classid 1:103 htb rate 128k ceil 512k
    [/FONT][/FONT][FONT=trebuchet ms][FONT=courier new]tc class add dev eth0 parent 1:1 classid 1:104 htb rate 128k ceil 512k
    tc qdisc add dev eth0 parent 1:101 handle 1010: sfq perturb 10
    [/FONT][/FONT][FONT=trebuchet ms][FONT=courier new]tc qdisc add dev eth0 parent 1:102 handle 1020: sfq perturb 10
    [/FONT][/FONT][FONT=trebuchet ms][FONT=courier new]tc qdisc add dev eth0 parent 1:103 handle 1030: sfq perturb 10
    [/FONT][/FONT][FONT=trebuchet ms][FONT=courier new]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
    [/FONT][/FONT][FONT=trebuchet ms][FONT=courier new]tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.102/32 flowid 1:102
    [/FONT][/FONT][FONT=trebuchet ms][FONT=courier new]tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.103/32 flowid 1:103
    [/FONT][/FONT][FONT=trebuchet ms][FONT=courier new]tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.104/32 flowid 1:104
    [/FONT][/FONT]

    Estas regras em um roteador (sem nat e sem squid) deveria fazer "divisão da banda" entre 4 computadores, sem nenhum tipo de priorização, somente QoS mesmo de um link full de 512k. Upload sei que faria basicamente a mesma coisa, somente informando a interface ligada ao meu gateway.

    Isto está certo?

    Obrigado pessoal.

  2. #2

    Padrão

    Uso desse jeito aqui e estou satisfeito. Está certo.

    O sfq seria assim:

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

    pertub em 1 dá resultados melhores, força mais a divisão de banda.

    Para o Upload eu fiz assim:

    tc qdisc add dev eth1 handle ffff: ingress

    tc filter add dev eth1 protocol ip parent ffff:0 prio 1 u32 match ip src 10.0.1.254 police rate 32kbit burst 64kbit drop flowid ffff:1
    Última edição por Josue Guedes; 19-02-2009 às 08:52.



  3. #3

    Padrão

    Josue, tu poderias me apontar onde encontro documentação sobre o ingress, pois pelo que entendi superficialmente no site do htb-tools, este usa ingress quando se quer controlar upload na mesma interface do download, mas faz justamente é o drop dos pacotes que excedem a taxa especificada, sem contar que não conseguiria definir minha capacidade de up para que as classes possam tomar emprestado umas das outras, ou seja, teria 2mb de up e 100 clientes a rate 20k e ceil 64k compartilhando suas sobras.
    Por isto escrevi lá que faria o mesmo controle feito para o download, também no upload, mas na interface de saída, ou seja, na que liga ao gateway de internet.

    Brigadão.

  4. #4

    Padrão

    É meu amigo, tem uns 2 anos já que procuro o que você está pedindo, meu último feito aqui foi conseguir marcar o destino com tc por MAC, assim controlo a velocidade por mac, apanhei uns 6 mêses, mais o upload por mac é mosca branca. Não consigo e nem por ip. Parece que tem poucas pessoas que fazem essas configurações. Por enquanto faz ai do jeito que passei que funciona bem, mais não divide banda como você pode ver. Se eu conseguir eu posto.



  5. #5

    Padrão

    Josue veja só: Imagine que eth0 seja minha interface lan e eth1 minha interface wan , como terei um roteador (sem fazer nat) responsável somente pelo QoS, então faço o controle de download pela interface eth0 sem problemas e acredito que poderei fazer o controle de upload pela interface eth1 sem problema também, pois como não estou mascarando nada, acredito que não vou precisar fazer marcação de pacotes nem outra coisa. Terei outro computador que então será meu gateway e vai ser responsável pelo proxy.

    A algum tempo atrás já fiz teste semelhante utilizando htb-tools e um arquivo para cada interface e pareceu-me trabalhar corretamente, mas como estou pretendendo utilizar tc diretamente estou pesquisando como trabalhar com ele, seu parâmetros, etc. Por exemplo burst é algo que está totalmente desvinculada a capacidade do link a não ser sua capacidade de tráfego, não interessaria por exemplo que fosse modem discado, dedicado, adsl, 3g?

    Obrigado

  6. #6

    Padrão

    No seu caso, nunca testei, sempre usei em uma máquina com nat e cache, afinal sou provedor, o burst é uma rajada por um período, mais nunca usei no controle de Download, no upload ele quase não fez diferença aqui. Melhor que usar burst é usar o compartilhamento de banda do HTB e SFQ como você vai fazer.



  7. #7

    Padrão

    Beleza Josue, vou ver se consigo ao menos testar neste feriadão e então posto os resultados. Exatamente nat e squid é que impedem de se conseguir controle de tráfego de upload pela interface de saída, então por isto terei um computador somente para QoS. A princípio estava pensando em uma RB433 que tenho, mas primeiro vou utilizar um PC para aprender e depois vou ver o que faço.

    Abraço

  8. #8

    Padrão

    Citação Postado originalmente por flaviomreis Ver Post
    Beleza Josue, vou ver se consigo ao menos testar neste feriadão e então posto os resultados. Exatamente nat e squid é que impedem de se conseguir controle de tráfego de upload pela interface de saída, então por isto terei um computador somente para QoS. A princípio estava pensando em uma RB433 que tenho, mas primeiro vou utilizar um PC para aprender e depois vou ver o que faço.

    Abraço
    Então você vai ter um PC com duas interfaces na mesma faixa de IP, e vai vai fazer HTB de saída numa interface e HTB de entrada na outra interface, legal, posta os resultados.



  9. #9

    Padrão

    Na verdade teria algo assim no controlador de tráfego: lan eth0 192.168.127.1/24 e na wan eth1 192.168.128.2/24. Esta máquina vai ser simplesmente uma roteador sem nat, repassando o tráfego para o seu gateway padrão que seria 192.168.128.1.

    No meu gateway padrão vou fazer nat e ter uma rota assim: route add -net 192.168.127.0 netmask 255.255.255.0 192.168.128.2, ou seja, ele vai repassar todo o tráfego de retorno para o meu controlador de tráfego que vai entregar aos clientes. Digamos que em um possível cenário a outra interface de rede vai ter o IP válido.

    Seria basicamente isto.