[GTER] Controle de Banda

Fri Nov 6 09:33:06 -02 2009

Nada contra o linux, mas acho bem mais fácil a sintaxe dos firewalls da
familia BSD e mais documentado também.

2009/11/6 Emerson Pinter <epinter at picturecorp.com.br>

> Vou substituir um servidor que atualmente é Linux, não quero trocar o
> sistema operacional.
>
> Emerson Pinter
>
> On Fri, 06 Nov 2009 09:05:21 -0200, Zhu Sha Zang <zhushazang at yahoo.com.br>
> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Emerson Pinter escreveu:
> >> Utilizo o Linux para controlar banda já alguns anos, e não tenho nenhuma
> >> reclamação quanto a segurança ou estabilidade.  Muito pelo contrário, o
> >> Linux se mostrou muito bom em todos aspectos.
> >> Acredito que esse problema de exibição das regras no boot seja
> >> configuração/script.
> >> Nada contra {Open,Free,Net}BSD (já usei muito, inclusive como Desktop),
> >> mas
> >> para alguns serviços prefiro ser conservador.
> >>
> >>
> >> Emerson Pinter
> >>
> >>
> >> On Thu, 5 Nov 2009 22:24:19 -0300, Paulo Henrique
> >> <paulo.rddck at bsd.com.br>
> >> wrote:
> >>> Olha não tenho nada contra as soluções disponiveis no Linux, contudo as
> >>> melhores soluções quanto a controle de banda foi utilizado o
> >>> FreeBSD+DUMMYNET+IPFW, FreeBSD+PF+AltQ e OpenBSD+PF+AltQ, considerando
> a
> >>> ultima sendo um roteador em que eu mesmo fiquei impressionado, as
> >> soluções
> >>> linux que tenho experiência até agora foi Slackware+Kernel-2.6.17+CBQ,
> >>> embora funcional não considerei ele seguro visto com coloca todas as
> >> regras
> >>> na tela durante o boot bastando ligar o monitor que mesmo sem
> >> autenticação
> >>> se consegue analisar todas as regras....
> >>>
> >>>
> >>> 2009/11/5 Emerson Pinter <epinter at picturecorp.com.br>
> >>>
> >>>> Sou antigo usuário do IMQ com HTB e estou configurando um servidor
> para
> >>>> controlar banda, agora com o IFB. Estou conseguindo controlar a banda
> >>>> de
> >>>> entrada e saida perfeitamente com o IFB, mas tenho uma dúvida...
> >>>>
> >>>> Alguém sabe se o IFB pode causar qualquer problema futuro se for usado
> >>>> para
> >>>> controlar upload e download (estou redirecionado trafego de entrada e
> >>>> saida
> >>>> da eth0 para a ifb0) ?
> >>>>
> >>>> Atenciosamente.
> >>>>
> >>>> Emerson Pinter
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Sat, 24 Oct 2009 17:40:23 -0200, Guilherme de Freitas Figueiredo
> >>>> <gff at wkve.com.br> wrote:
> >>>>> Senhores,
> >>>>>
> >>>>>   Boa tarde!
> >>>>>
> >>>>>   Paulo , qual é a versão do kernel do seu GNU/Linux ?
> >>>>>   O processador é SMP ?
> >>>>>
> >>>>>   Digo isso porque passei os mesmos problemas , e tenho um amigo que
> >>>>> desenvolve patchs para o IMQ , o mesmo não aconselhou usar IMQ em
> >>>>> kernel
> >>>>> acima de 2.6.26 , sendo assim , tive que mudar minha solução para ifb
> >> ,
> >>>>> funcionou sem problemas , utilizando junto com HTB ou HFSC.
> >>>>>
> >>>>>   Segue abaixo um exemplo de regra utilizando IFB+HTB , uma vez que ,
> >> o
> >>>>> IFB controla somente o UPLOAD.
> >>>>>
> >>>>>
> >>>>> #
> >>>>> # DEV = interfaces
> >>>>> #
> >>>>> tc qdisc add dev $dev root handle 1: htb r2q 5120 default 1
> >>>>> tc class add dev $dev parent 1:  classid 1:1 htb rate 1000mbit ceil
> >>>>> 1000mbit
> >>>>> tc class add dev $dev parent 1:  classid 1:2 htb rate 1000mbit ceil
> >>>>> 1000mbit
> >>>>> tc qdisc add dev $dev handle ffff ingress
> >>>>>
> >>>>> #
> >>>>> # IFB
> >>>>> #
> >>>>> tc qdisc add dev ifb0 root handle 1: htb r2q 5120 default 1
> >>>>> tc class add dev ifb0 parent 1:  classid 1:1 htb rate 1000mbit ceil
> >>>>> 1000mbit
> >>>>> tc class add dev ifb0 parent 1:  classid 1:2 htb rate 1000mbit ceil
> >>>>> 1000mbit
> >>>>>
> >>>>> #
> >>>>> # Redirecionamento de ingress para ifb0
> >>>>> #
> >>>>> tc filter add dev $dev parent ffff: protocol ip prio 10 u32 match u32
> >> 0
> >>>>> 0 flowid 1:2 action mirred egress redirect dev ifb0
> >>>>>
> >>>>> #
> >>>>> # Class
> >>>>> #
> >>>>> tc class add dev $dev parent 1:2 classid 1:$1 htb rate $down ceil
> >> $down
> >>>>> #
> >>>>> # Class IFB0
> >>>>> #
> >>>>> tc class add dev ifb0 parent 1:2 classid 1:$1 htb rate $down ceil
> >> $down
> >>>>> #
> >>>>> # Filter
> >>>>> #
> >>>>> tc filter add dev $dev parent 1: protocol ip prio 10 u32 match ip dst
> >>>>> ${ip} flowid 1:${NUMERO}
> >>>>>
> >>>>> #
> >>>>> # Filter IFB0
> >>>>> #
> >>>>> tc filter add dev ifb0 parent 1: protocol ip prio 10 u32 match ip src
> >>>>> ${ip} flowid 1:${NUMERO}
> >>>>>
> >>>>> #
> >>>>> #
> >>>>>
> >>>>> Lembrando que , eu faço o controle somente nas LANS , deixo as WANS
> de
> >>>>> fora.
> >>>>> Não se esqueça também de subir a interface ifb0 ( ip link set dev
> ifb0
> >>>>> up
> >>>> )
> >>>>> Qualquer coisa estamos à disposição!
> >>>>>
> >>>>> Abraços!
> >>>>>
> >>>>>
> >>>>>
> >>>>> Paulo escreveu:
> >>>>>> 2009/10/24 Rubens Marins Marins Schner Pereira Junior <
> >>>>>> rubens.marins at gmail.com>
> >>>>>>
> >>>>>>> Se voce ja descobriu que o problema esta no IMQ, tente nao usar
> ele,
> >>>>>>> usando regras para cada uma das interfaces.
> >>>>>>>
> >>>>>>> Digamos que voce tem a eth0 que vai para a internet, e a eth1 que
> >> vai
> >>>>>>> para a sua rede, voce coloca as regras de upload na eth0 e as
> regras
> >>>>>>> de download na eth1.
> >>>>>>> E se voce esta controlando banda para ips, use o u32 do tc filter
> >>>>>>> para
> >>>>>>> identificar o trafego, o iptables da uma sobrecarga a mais na
> coisa,
> >>>>>>> e
> >>>>>>> so e recomendado para regras muito especificas que voce so consegue
> >>>>>>> identificar usando regra de iptables. E claro com poucas regras na
> >>>>>>> maquina, normalmente um micro para compartilhar adsl.
> >>>>>>>
> >>>>>>> Um exemplo para um cliente de 20mbit que tem o ip 192.168.0.1 e uma
> >>>>>>> rede 10.0.0.0/24 com ele.
> >>>>>>>
> >>>>>>> ## Regra de upload
> >>>>>>> tc class add dev eth0 parent 1:1 classid 1:100 htb rate 20480kbit
> >>>>>>> tc qdisc add dev eth0 parent 1:100 handle 100: sfq perturb 10
> >>>>>>> tc filter add dev eth0 protocol ip parent 1: u32 match ip src
> >>>>>>> 192.168.0.1 flowid 1:100
> >>>>>>> tc filter add dev eth0 protocol ip parent 1: u32 match ip src
> >>>>>>> 10.0.0.0/24 flowid 1:100
> >>>>>>>
> >>>>>>> ## Regra de Download
> >>>>>>> tc class add dev eth1 parent 2:1 classid 2:100 htb rate 20480kbit
> >>>>>>> tc qdisc add dev eth1 parent 2:100 handle 100: sfq perturb 10
> >>>>>>> tc filter add dev eth1 protocol ip parent 2: u32 match ip dst
> >>>>>>> 192.168.0.1 flowid 2:100
> >>>>>>> tc filter add dev eth1 protocol ip parent 2: u32 match ip dst
> >>>>>>> 10.0.0.0/24 flowid 2:100
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Abracos,
> >>>>>>>
> >>>>>>>
> >>>>>> Obrigado, pelas dicas e sugestões de todos.
> >>>>>>
> >>>>>> O problema é realmente o IMQ. Quando faço o controle na interface
> >> real
> >>>>>> (eth+) como o Rubens disse, consigo entregar a banda normalmente,
> >>>>>> 50mb,
> >>>>>> 65mb, 20mb, 87mb. O problema é quando o IMQ tá ativo. Uma
> alternativa
> >>>>>> é
> >>>>>> utilizar as interfaces reais do servidor, porém, a utilização das 2
> >>>>>> interfaces IMQ como alvo nas regras de PRE e POSTROUTING é muito
> bom,
> >>>>>> evito
> >>>>>> de criar várias qdisc e class usando as interfaces, que são muitas.
> >>>>>>
> >>>>>> O IFB não funciona da mesma forma que a IMQ, mas vou procurar
> >>>> informações
> >>>>>> sobre a IFB antes de controlar o tráfego de download e upload nas
> >>>>>> interfaces
> >>>>>> eth+.
> >>>>>>
> >>>>>> Alguém tem experiência utilizando o FreeBSD para controlar banda de
> >>>>>> vários
> >>>>>> links grande?
> >>>>>>
> >>>>>> Bom sábado para todos.
> >>>>>> --
> >>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>>>
> >>>> Esta mensagem pode conter informações confidenciais, privilegiadas ou
> >>>> privadas.
> >>>> Caso não seja o destinatário, favor  apagá-la e notificar o remetente.
> >>>> Saiba que o uso impróprio das informações existentes é estritamente
> >>>> proibido, sendo tratado conforme as normas da empresa e a legislação
> em
> >>>> vigor.
> >>>>
> >>>> --
> >>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>
> >>> --
> >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>
> >>> ----------------------------------------------------------------------
> >>>
> >>> --
> >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> > Não entendi o "ser conservador" neste caso.
> >
> > att
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2.0.11 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iEYEARECAAYFAkr0AvEACgkQ35zeJy7JhCintgCfXXV13pUn/Syonvnln6weYIp0
> > STUAn1Qv5xAs47dhnYBJppoRWLaNrLv6
> > =gFy2
> > -----END PGP SIGNATURE-----
> >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
>
> Esta mensagem pode conter informações confidenciais, privilegiadas ou
> privadas.
> Caso não seja o destinatário, favor  apagá-la e notificar o remetente.
> Saiba que o uso impróprio das informações existentes é estritamente
> proibido, sendo tratado conforme as normas da empresa e a legislação em
> vigor.
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>