[GTER] Priorização e Reserva de banda

[Marconi Pereira]

Oi Luiz e grupo,
 
1) O número de states é dado pelo número de flows de conexões Established?
2) Tem algum comando no openBSD que mostre a quantidade de conexões EST?
3) A minha máquina contém um pf.conf todo comentado e a carga do pfctl se dá com outro arquivo (o tal que enviei, sem nenhuma opção). Sem nenhuma opção setada, ainda assim ele tem 10.000 states como default?
4) Se você diz que 10.000 states estouram com mais de 2Mbp/s, o que acontecem com essas conexões? É preciso fazer retransmissão ou novos pedidos de conexão têm que aguardar a liberação de pool? Isso não gera um efeito cascata?
 
Se isso gerar um efeito cascata, já vi que quem está sendo diretamente atingido é o nosso firewall (que está atrás do openBSD). Ele está consumindo CPU pra caramba justamente nesses momentos de saída de SMTP. A CPU fica em torno de 60/80% e algumas máquinas na DMZ ficam inacessíveis!!! Será que está havendo um número tal de retransmissões que o firewall fica catatônico?
 
Na realidade, eu tinha 6Mbp/s e pulei para 18, depois para 28 e certamente vai aumentar mais ainda. Mesmo com 18Mbp/s, eu nunca tive indisponibilidade de máquinas na DMZ no barramento eth100! 
 
Muito bizarro.
 
Pô, só de ter postado na lista e confirmar a minha sensação que essa config tava um lixo já me deu um alento e eu até to gostando de resolver esse troço. Eu sempre tive uma queda pela tela preta da força :-)
 
[]s e obrigado a todos que estão colaborando!
Marconi
 
 
> Date: Sat, 4 Aug 2007 09:50:51 -0300> From: luiz at visualconnect.com.br> To: gter at eng.registro.br> Subject: Re: [GTER] Priorização e Reserva de banda> > Rafael Faria escreveu:> > Bom dia Marconi,> >> > > (...)> > # Opções> > set timeout { interval 10, frag 30 }> > set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }> > set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 }> > set timeout { udp.first 60, udp.single 30, udp.multiple 60 }> > set timeout { icmp.first 20, icmp.error 10 }> > set timeout { other.first 60, other.single 30, other.multiple 60 }> > set timeout { adaptive.start 0, adaptive.end 0 }> > set limit { states 10000, frags 5000 }> > set loginterface $wan_if> > set optimization normal> > set block-policy drop> > set require-order yes> > set fingerprints "/etc/pf.os"> > set skip on lo> >> > # Normalização> > scrub in on $wan_if all fragment reassemble min-ttl 15 max-mss 1400> >> > > Marconi,> > Uma implementação de QoS em "seja la o que" com 28Mb de banda começa a > "dar trabalho".> > De qualquer maneira, quanto ao pf, você precisa aumentar o número de > states (que por padrão e também no exemplo do amigo é de 10.000). 10.000 > states estouram com pouco mais de 2Mb (depende do uso até com menos).> > Agora as 9:30 da manhã de sábado (baixa utilização), tenho mais de > 33.000 states num pf (que faz exatamente o mesmo que o seu) num link de > 12Mb. Para você ter uma idéia o limite deste pf esta em 500.000 states.> > A utilização de scrub com max-mss 1400 (no exemplo acima) deve ser > utilizada apenas em clientes pppoe para manter o mtu dentro dos 1492 > bytes úteis. A regra padrão do scrub já resolve no seu caso.> > Procure alguém que possa auxiliar no seu problema de ponta a ponta (do > problema a solução), independente das ferramentas utilizadas (elas vão e > vem - com novidades - todos os dias) e que possa lhe ajudar no meio de > "tantas informações".> > []'s> Luiz> > --> gter list https://eng.registro.br/mailman/listinfo/gter
_________________________________________________________________
Find a local pizza place, movie theater, and more….then map the best route!
http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01