[GTER] RES: RES: Priorização e Reserva de banda

Fri Aug 3 15:43:55 -03 2007

Ah sim :)

Realmente, são 2 sintaxes bem diferentes, a lógica de cada uma é bem
específica, mas ambas atendem com satisfação o que ele precisa! 

-----Mensagem original-----
De: gter-bounces at eng.registro.br [mailto:gter-bounces at eng.registro.br] Em
nome de Leandro Pereira de Lima e Silva
Enviada em: sexta-feira, 3 de agosto de 2007 15:28
Para: Grupo de Trabalho de Engenharia e Operacao de Redes
Assunto: Re: [GTER] RES: Priorização e Reserva de banda

Tenho certeza que os dois sistemas resolvem o problema muito bem, muita
gente usa BSD e muita gente usa Linux pra fazer isso.

Minha resposta foi só por causa do comentário do "c0re dumped".

"O que vc vai usar ? O BUGtables ? Se com a sintaxe do PF vc está tendo
dificuldade imagina com aqueles zilhões de flags..."
Essa crítica não procede.

[]s Leandro

Em 03/08/07, Renato Frederick <frederick at dahype.org> escreveu:
>
> O problema do colega não é por ser BSD... é consultoria que fez coisa
> errada, isto iria acontecer com cisco, freebsd, openbsd, solaris, aix,
> QnX,
> DoS, Linux.... falta de profissionalismo e de acompanhamento da solução
> instalada resulta nisto.
>
>
> Sobre a solução, Houve discussões na GTER a respeito do PF já:
>
>
> http://eng.registro.br/pipermail/gter/2006-July/010965.html
>
> A lista FUG, orientada ao FreeBSD possui pessoal muito qualificado, que
> pode
> ajudá-lo, já teve muita discussão sobre isto lá também:
>
>
>
http://www.fug.com.br/historico/cgi-bin/namazu.cgi?query=pf+queue&idxname=fr
> eebsd
>
>
>
> -----Mensagem original-----
> De: gter-bounces at eng.registro.br [mailto:gter-bounces at eng.registro.br] Em
> nome de Leandro Pereira de Lima e Silva
> Enviada em: sexta-feira, 3 de agosto de 2007 14:57
> Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> Assunto: Re: [GTER] Priorização e Reserva de banda
>
> Com linux isso realmente sai fácil.
>
> Com uma ou 2 regras de iptables dá pra marcar o tráfego e com htb.init vc
> regula a banda e faz o qos.
>
> []s Leandro
>
> Em 03/08/07, Wagner Furquim <wagnerfurquim at gmail.com> escreveu:
> >
> >   Amigo será que sai muito caro comprar um Switch Multilayer L3 ou L4??
> > que
> > faça a grande maioria das funções em hardware usando ASIC's.. Ai sim
> > poderia
> > implementar varias features sem nenhuma penalidade no quesito
> perfomance.
> >
> >         Eu acho que vc teria que pensar em hardware especializado, pois,
> o
> > link é alto e um PC perde perfomance processando todos o fluxo.
> >
> >
> >            Abraços!!
> >
> >
> > On 8/3/07, Marconi Pereira <marconipp at hotmail.com> wrote:
> > >
> > > Amigos,
> > >
> > > já vi que aqui eu posso conseguir uma ajuda de alto nível.
> > >
> > > Possuo um link de 28Mb via Embratel que entra num Tellabs EdgeNode
> 6310.
> > > Dele, vai por fast ethernet prum openBSD que funciona basicamente como
> > um
> > > router. Eu antes tinha um router Cisco com priority-queue ligado e que
> > > resolvia todos os meus problemas de priorização de pacotes. Mas, como
> > fiz
> > > upgrade de banda e não tinha dinheiro para acompanhar com um router
> mais
> > > potente, optou-se por um unix.
> > > Nossa característica de tráfego é SMTP. Nós enviamos toneladas e
> > toneladas
> > > de email por dia. São gigas e gigas por dia. O inbound é pífio, não
> > tenho
> > > problema com download, meu problema tá no upload. A primeira coisa que
> > eu
> > > queria entender é por que o overhead de SMTP é alto? Até agora eu não
> > > achei
> > > nenhuma explicação clara para isso. Todo mundo fala mas ninguém
> explica.
> > >
> > > Além disso, tenho vários webservers e também temos a nossa navegação
> > > interna
> > > e emails administrativos. Nosso problema atual é justamente esse: nós
> > > damos
> > > DoS em nós mesmos. Quando sai email a rodo, a nossa indisponibilidade
> > fica
> > > terrível.
> > >
> > > Foi contratada, então, essa consultoria que socou esse unix com PF e
> > ALTQ.
> > > Eu não saco absolutamente nada de mundo unix e fico meio perdido,
> > > portanto,
> > > recorro aos gurus daqui para lançar um pouco de luz nas trevas.
> > > A priori, eu queria que esse bicho funcionasse como um cisco no
> > > priority-queue, mas o bicho não se comportou como um cisco. A
> > priorização
> > > do
> > > cisco era absurda, a gente não tinha indisponibilidade. Ele
> simplesmente
> > > enfileirava os pacotes com mais alta prioridade mesmo com o link no
> talo
> > e
> > > tudo funcionava perfeitamente. A idéia básica é: o link tá ocioso?
> pode
> > > arrebentar, pode consumir tudo o que quiser em SMTP. Se houver algum
> > outro
> > > uso diferente de SMTP, ultrapassa na frente, não importa o que seja
> nem
> > > qual
> > > o tamanho. Era isso que o Cisco fazia.
> > >
> > > A config mais próxima que melhorou um pouquinho a nossa
> > indisponibilidade
> > > aqui foi com CBQ (reserva de banda). O cara tentou de todas as formas
> > > implementar priority-queue cisco like (inclusive vendeu isso) mas, no
> > > final,
> > > entubamos.
> > >
> > > Essa é a config de priority-queue que não funciona a contento nem por
> um
> > > decreto. Se vocês puderem dar uma olhada e ver o que tem de errado
> nesse
> > > troço, agradeço muito! (Eu observo que a aplicação dessa filtragem é
> > feita
> > > na interface WAN que é 100Mbps, mas o link tem 28Mbps. Esse troço não
> tá
> > > inundando o Tellabs?)
> > >
> > >
> > > # Variaveis (Macros)
> > >
> > > # Informacoes da Interface Wan
> > > wif="fxp0"
> > > wip="200.255.248.10"
> > > wmask="255.255.255.252"
> > >
> > > # Interface Lan
> > > eif="xl0"
> > > eip="200.214.72.222"
> > > enmask="255.255.255.224"
> > >
> > > allproto ="{ tcp, udp, gre }"
> > >
> > > netbios = "{ 135, 137, 138, 139, 445 }"
> > > # Definicao de tables
> > >
> > >
> > > altaprioridade = "{ 200.214.72.249, 200.214.72.239, 200.214.72.237,
> > > 200.214.72.131, 200.214.72.227 }"
> > > mediaalta = "{ 200.214.72.245, \
> > > 200.244.55.194, 200.214.72.230, \
> > > 200.244.121.203, 200.244.55.198, 200.214.72.227, \
> > > 200.244.55.197, 200.244.55.199, 200.244.121.250, 200.244.121.201, \
> > > 200.214.72.252 }"
> > >
> > > mediaprioridade = "{ 200.244.121.0/28 }"
> > >
> > > table <rfc1918> { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
> > >
> > > office = "{ 200.244.121.0/24, 200.214.72.128/25, 200.244.55.192/26 }"
> > >
> > > smtp_proto = "{ 200.244.121.211, 200.244.121.212, 200.244.121.213, \
> > > 200.244.121.214, 200.244.121.215, 200.244.121.216, 200.244.121.217, \
> > > 200.244.121.218, 200.244.121.219 }"
> > > # Definicao do sistema de QoS (Altq)
> > >
> > > altq on $wif priq bandwidth 100Mb queue { altpri medaltpri medpri
> baxpri
> > }
> > > queue altpri priority 14 qlimit 100 priq(default)
> > > queue medaltpri priority 5 priq(red)
> > > queue medpri priority 4 priq(red)
> > > queue baxpri priority 3 qlimit 2 priq(red)
> > >
> > > block in quick log on $wif proto tcp from any to $office port 1433
> flags
> > > S/SA label "BloqueiodeAcessoaoMSSQL"
> > > block in quick log on $wif proto udp from any to $office port 1433
> label
> > > "BloqueiodeAcessoaoMSSQL"
> > > block in quick log on $wif proto tcp from any to $office port 1434
> flags
> > > S/SA label "BloqueiodeAcessoaoMSSQL"
> > > block in quick log on $wif proto udp from any to $office port 1434
> label
> > > "BloqueiodeAcessoaoMSSQL"
> > > block in quick log on $wif proto tcp from any to $office port $netbios
> > > label
> > > "BloqueiodeAcessoprotocoloNetbios"
> > > block in quick log on $wif proto udp from any to $office port $netbios
> > > label
> > > "BloqueiodeAcessoprotocoloNetbios"
> > >
> > > pass in on $eif proto tcp from any to any port != smtp queue altpri
> > > pass in on $eif proto tcp from 200.214.72.249 to any queue altpri
> > > pass in on $eif proto tcp from 200.244.121.203 to any queue altpri
> > > pass in on $eif proto tcp from any to any port smtp queue baxpri
> > >
> > >
> > >
> > > A config que funciona hoje de forma muito ruim, mas melhor do que o
> > > priority-queue, é essa que usa CBQ (reserva):
> > >
> > > # Variaveis (Macros)
> > >
> > > # Informacoes da Interface Wan
> > > wif="fxp0"
> > > wip="200.255.248.10"
> > > wmask="255.255.255.252"
> > >
> > > # Interface Lan
> > > eif="xl0"
> > > eip="200.214.72.222"
> > > emask="255.255.255.224"
> > >
> > > allproto ="{ tcp, udp, gre }"
> > >
> > > netbios = "{ 135, 137, 138, 139, 445 }"
> > > # Definicao de tables
> > >
> > > table <altaprioridade> { 200.214.72.249, 200.214.72.239,
> 200.214.72.237,
> > > 200.214.72.131 }
> > > table <mediaalta>  { 200.214.72.245, \
> > > 200.244.55.194, 200.214.72.230, \
> > > 200.244.121.203, 200.244.55.198, 200.214.72.227, \
> > > 200.244.55.197, 200.244.55.199, 200.244.121.250, 200.244.121.201, \
> > > 200.214.72.252 }
> > >
> > > table <mediaprioridade> { 200.244.121.0/28 }
> > >
> > > table <rfc1918> { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
> > >
> > > table <unear> { 200.244.121.0/24, 200.214.72.128/25,
200.244.55.192/26}
> > >
> > > table <smtp_proto> { 200.244.121.211, 200.244.121.212, 200.244.121.213
> ,
> > \
> > > 200.244.121.214, 200.244.121.215, 200.244.121.216, 200.244.121.217, \
> > > 200.244.121.218, 200.244.121.219, 200.244.121.220, 200.244.121.221, \
> > > 200.244.121.222, 200.244.121.223, 200.244.121.224, 200.244.121.225, \
> > > 200.244.121.226, 200.244.121.227 }
> > >
> > > # Definicao do sistema de QoS (Altq)
> > >
> > >
> > > altq on $wif cbq bandwidth 25000Kb queue { std office smtp_proto }
> > >
> > > queue std bandwidth 2500Kb cbq(default) priority 2
> > > queue office bandwidth 5500Kb cbq(borrow) priority 7
> > > queue smtp_proto bandwidth 17000Kb priority 1
> > >
> > > # Definicao das regras de filtragem a aplicacao do QoS
> > >
> > > antispoof log quick for $wif inet
> > > # block in quick log on $wif proto tcp from any to any flags S/SAFR
> > > block in quick log on $wif proto $allproto from <rfc1918> to any label
> > > "rfc1918"
> > > block drop in inet6 all
> > >
> > > ### Aplicacao das regras de QoS
> > >
> > > pass in on $eif proto tcp from any to any port != smtp queue office
> > > pass in on $eif from 200.214.72.131 to any queue office
> > > pass in on $eif proto tcp from 200.214.72.249 port smtp queue office
> > > pass in on $eif proto tcp from 200.244.121.203 port smtp queue office
> > > pass in on $eif proto tcp from 200.244.55.194 port smtp queue office
> > > pass in on $eif proto tcp from 200.244.55.197 port smtp queue office
> > > pass in on $eif proto tcp from any to any port smtp queue smtp_proto
> > >
> > > block in quick log on $wif proto tcp from any to <office> port 1433
> > label
> > > "Bloqueio de Acesso ao MSSQL"
> > > block in quick log on $wif proto udp from any to <office> port 1433
> > label
> > > "Bloqueio de Acesso ao MSSQL"
> > >
> > > block in quick log on $wif proto tcp from any to <office> port
> $netbios
> > > label "Bloqueio de Acesso protocolo Netbios"
> > > block in quick log on $wif proto udp from any to <office> port
> $netbios
> > > label "Bloqueio de Acesso protocolo Netbios"
> > >
> > >
> > > Agradeço a todos que puderem dar uma luz nisso.
> > > Obrigado,
> > > Marconi
> > >
> > > _________________________________________________________________
> > > Booking a flight? Know when to buy with airfare predictions on MSN
> > Travel.
> > > http://travel.msn.com/Articles/aboutfarecast.aspx&ocid=T001MSN25A07001
> > >
> > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> Leandro Pereira de Lima e Silva
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

-- 
Leandro Pereira de Lima e Silva
--
gter list    https://eng.registro.br/mailman/listinfo/gter