[GTER] DiffServ em Linux

[Lucas Willian Bocchi]

Galera, tenho solução aqui com EF + HFSC. O HFSC está bem maduro e
muito bom dentro do kernel linux, porém ainda precisa amadurecer
bastante para chegar no nível do BSD. Tenho utilizado classes prio com
com pfifo atrelado a fila 1, tbf numa segunda fila e hfsc na terceira,
filtrando os tráfegos daí pra diante. Com o Kernel configurado para
baixa granularidade e redirecionando as interrupções das placas de
rede para núcleos diferentes, consegui boas performances.

Só que temos que colocar os pingos nos I's. Se você precisa realmente
de um qos de qualidade e profissional, o melhor mesmo é usar
equipamentos já conhecidos. Eu prefiro Cisco, portanto só posso falar
o que sei dele.


Em 27 de junho de 2011 14:29, Rafael Ganascim <rganascim at gmail.com> escreveu:
> Vamos ver como fica com o HTB gerindo a prioridade. Este resultado gostaria
> de ver mesmo :)
>
> Agora um detalhe, ou ainda, um problema que tive sobre a classificação
> estrita sobre DSCP. Tentei de todas as maneiras usar a classificação
> puramente por DSMARK. E em um cenário onde os roteadores são puramente
> 'trânsito' de pacotes (os dados não se originam/terminam em interfaces LAN
> dos mesmos), era perfeitamente aceitável. Porém, quando isto foi se
> extendendo para as bordas, para aqueles roteadores/firewalls que tem
> segmentos de LAN conectados (leia-se, o limite onde as marcações são
> realizadas), ficou impraticável a gestão de marcação via firewall (que foi a
> solução encontrada). Acabamos por usar classificadores genéricos(por
> IP/porta/destino/DSCP/ToS), sobre algumas classes pré-definidas, abolindo a
> marcação e classificação por DSCP.
>
>
> Em 27 de junho de 2011 13:42, Marlon Dutra <mfdutra at gmail.com> escreveu:
>
>> Rafael,
>>
>> http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#prio
>>
>> Lendo bem a documentação do HTB, vi que dá para fazer o mesmo esquema do
>> PRIO com o próprio HTB, usando o parâmetro "prio" de forma apropriada.
>>
>> Liberei uma nova versão do meu gerador levando isso em consideração.
>> Creio que a classe EF agora está bastante próxima da implementação LLQ
>> da Cisco.
>>
>> Uma coisa extremamente importante é nunca elevar a soma dos CIRs das
>> classes EF + AFs para qualquer coisa próxima de 100%, pois como o
>> desenfileiramento das classes é estritamente prioritário, o BE (tráfego
>> não classificado) pode estagnar. A Cisco recomenda que não se reserve
>> mais de 75% de banda. O meu script dá um warning se isso for feito.
>>
>> Att.
>>
>> --
>> MARLON DUTRA
>> Propus
>> GnuPG ID: 0x3E2060AC pgp.mit.edu
>> http://www.propus.com.br/
>> http://hackers.propus.com.br/~marlon/
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>