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

Renato Frederick frederick at dahype.org
Fri Aug 3 15:15:56 -03 2007


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





More information about the gter mailing list