[GTER] Priorização e Reserva de banda

Fri Aug 3 13:08:08 -03 2007

  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
>