[FUG-BR] RES: WF2Q+ (era IPFW e VoIP)
Eduardo Schoedler
eschoedler em viavale.com.br
Sábado Abril 19 00:38:38 BRT 2008
Olá Patrick !!!
Primeiramente Muito Obrigado.
Realmente não é tãããooo fácil assim quanto eu imaginava.
Vamos lá... hoje meu one_pass está assim:
net.inet.ip.fw.one_pass: 1
Minha situação: eu trabalho em um provedor, e basicamente esse router possui
pipes para controlar a banda do cliente.
Como tenho blocos de redes /24, crio 1 regra com mask (src-ip e dst-ip)
limitando nas velocidades padrões.
Porém, quando há uma situação de velocidade específica, é criado um pipe
simples anterior a esses somente com o IP em questão.
Exemplo:
ipfw -q add pipe 1 ip from x.x.x.8 to any in recv xl0
ipfw -q pipe 1 config bw 1024Kbits/s
ipfw -q add pipe 2 ip from any to x.x.x.8 out xmit xl0
ipfw -q pipe 2 config bw 1024Kbits/s
ipfw -q add pipe 101 ip from x.x.x.0/24 to any in recv xl0
ipfw -q pipe 101 config mask src-ip 0x000000ff bw 300Kbits/s
ipfw -q add pipe 102 ip from any to x.x.x.0/24 out xmit xl0
ipfw -q pipe 102 config mask dst-ip 0x000000ff bw 600Kbits/s
E todas minhas regras são assim.
Pelo que pude entender, se eu quisesse priorizar o voip em relação à TODO o
meu tráfego, eu teria de criar um pipe só e trocar minha estrutura de pipes
hoje por queues e definir um weight padrão (5, por ex) e colocar um weight
de 100 nas queues do voip. Certo?
Porém como eu continuaria controlando a velocidade desses clientes ?
Você disse:
> Ai voce joga one_pass do ipfw pra 0 e depois desses queue/pipes
> simplesmente cria um pipe simples
> ipfw add pipe 25 tcp from any to $email_servers dst-port 25,110,143 in
> ipfw add pipe 26 tcp from $email_servers src-port 25,110,143 to any out
> ipfw pipe 25 config bw 2Mbit/s
> ipfw pipe 26 config bw 2Mbit/s
> Pronto. No QUEUE haverá o QoS, e como one_pass=0 garante que todos os
> pacotes continuem no firewall até encontrar uma ação
> (allow/deny/fwd/etc), passará por todas regras dummynet q existirem.
> Portanto ao chegar nesse pipe o fluxo 25,110,143 (smtp/pop/imap) não
> passará de 2Mbit/s, mesmo tendo sido "permitido" mais q isso no
> queue+pipe anterior.
Pelo que entendi, para que um pacote passe por mais de uma queue, eu devo
setar net.inet.ip.fw.one_pass=0...
Então eu montaria primeiramente as regras de QoS (que seria praticamente uma
cópia dos pipes existentes convertidas para queues) e logo após continuariam
meus pipes para fazer o controle de banda... certo ?
Realmente, vou ter de setar um ambiente de testes... pq testar isso em
produção vai ser um tiro no pé! hehehe.
Muito Obrigado novamente!
Abraços.
--------------------------------------------------
From: "Patrick Tracanelli" <eksffa em freebsdbrasil.com.br>
Subject: Re: [FUG-BR] RES: WF2Q+ (era IPFW e VoIP)
Eduardo Schoedler escreveu:
> Realmente, show de bola a explicação! =)
> Se eu tivesse um pipe para cada queue... claro que somente as queues
> teriam
> weigth maior, só essas seriam priorizadas, certo?
>
> Obrigado!
Eduardo, 1 pipe por queue, faz essa queue concorrer pelo pipe com ela
mesma. Ou seja é a mesma coisa que ter apenas 1 pipe por endereços IP, o
mais trivial.
Usamos queue quando queremos priorizar 1 trafego em relacao ao outro
dentro de 1 mesmo pipe.
Se voce tiver por exemplo 2 pipes, com 4 queues CADA UM, essa política é
totalmente independente. Ou seja nunca havera prioridade de peso em um
queue do pipe 2 sobre algum do pipe 1. Eles sequer vão se conhecer/saber
q existem.
Resumindo uma ideia de abordagem de QoS:
1 pipe com TODO SEU LINK.
N queues dentro desse pipe...
E ai sim, depois, se alem de trabalhar a relacao de pesos quiser ainda
limitar banda maxima, outro pipe sem queue pra cada um que vc queira
limitar.
Por exemplo. QoS basico
pipe 1 4Mbit/s, e conectado nesse pipe:
Q1:W5 - DNS
Q2:W5 - SSH
Q3:W10 - FTP
Q4:W30 - SMTP/POP/IMAP
Q5:W20 - VOIP
Q6:W25 - HTT/HTTPs
Q7:W5 - outros
Note que propositadamente fiz um esquema de W (pesos) cuja soma de 100.
Na pior situacao possivel, os 4Mbt/s do pipe estrapolado e todos esses
servindo demandando banda, eles teriam garantia em porcentagem do pipe
total, portanto 25% dos 4Mbit/s pra VOIP, 30% pra SMTP/POP/IMAP, etc.
Mas pense, numa situação em que nao eh o pior cenario... so tem la SMTP
e DNS e outros consumindo banda... nao havendo demanda nos outros
queues, esses que estao demandando vao dividir, na proporção de seus
pesos, os 4Mbit/s. Ou seja SMTP pode chegar a consumir uma penca, até
perto dos 4Mbit/s totais. Otimo! Ehisso q a gente quer, se tiver
sobrando deixa usar a vontade, priorizando de forma justa de acordo com
seus pesos, certo?
Pra mim isso é o cenário perfeito.
Mas pra você pode não ser. Vamos supor que você queira por algum motivo
que SMTP *jamais* ultrapasse 2Mbit/s?
Ai voce joga one_pass do ipfw pra 0 e depois desses queue/pipes
simplesmente cria um pipe simples
ipfw add pipe 25 tcp from any to $email_servers dst-port 25,110,143 in
ipfw add pipe 26 tcp from $email_servers src-port 25,110,143 to any out
ipfw pipe 25 config bw 2Mbit/s
ipfw pipe 26 config bw 2Mbit/s
Pronto. No QUEUE haverá o QoS, e como one_pass=0 garante que todos os
pacotes continuem no firewall até encontrar uma ação
(allow/deny/fwd/etc), passará por todas regras dummynet q existirem.
Portanto ao chegar nesse pipe o fluxo 25,110,143 (smtp/pop/imap) não
passará de 2Mbit/s, mesmo tendo sido "permitido" mais q isso no
queue+pipe anterior.
Ou seja sao politicas independentes.
Primeiro fazemos o QoS, e depois pipes independentes *se desejável*.
Nesse caso o pipe indepdentemente do que o QoS definiu vai limitar a
2Mbit/s o tráfego em questão.
Cara, pode ser que ainda tenha ficado confuso, eu reconheço. Mas
explicar mais que isso eu não dou conta, e qq confusão que ainda restar
sabe como resolver? mãos a massa! hehehe ;) esse é o tipo de coisa que a
gente só "vê pra entender" quando faz.
Faça um teste simples em um ambiente controlado (de testes), por
exemplo, limite sua banda a 128Kbit/s e coloque peso super alto pro ssh
(tcp 22) e baixo pra todo o resto, ai faça um sftp de um arquivo enorme,
e veja como sua navegação vai ficar; ai suspenda o sftp e veja o
comportamento da navegação, etc. Depois usando o mesmosetup coloque
outro pipe limitando a máxima do tcp:22. Já era, você vai ter controle
pleno do dummynet.
Ai você pode passar pra algo mais avançado depois.
>
>
> --------------------------------------------------
> From: "Mario Augusto Mania" <m3.bsd.mania em gmail.com>
> Subject: Re: [FUG-BR] RES: WF2Q+ (era IPFW e VoIP)
>
> Boa Eksffa hehehe
>
> Como sempre, direto ao assunto hehehe :)
>
> abracos.. m3
>
> Em 18/04/08, Patrick Tracanelli<eksffa em freebsdbrasil.com.br> escreveu:
>> Eduardo Schoedler escreveu:
>>
>>> Valeu Renato!
>> >
>> > O que eu não estava entendendo é que as queues não possuem uma
>> estrutura de
>> > árvore...
>> > Basta cada pipe ter seu weight e pronto, certo ?
>> > Claro que eu devo colocar o restante do tráfego dentro de um pipe
>> também, e
>> > setar um peso.
>> >
>> > Muito Obrigado!
>>
>>
>> Existe uma relação de árvore sim.
>> Pipes não tem weight. Quem tem weight são os queues, e os queues se
>> conectam a um pipe (essa é a relacao de árvore), ex:
>>
>>
>> PIPE 10
>> |
>> /|\
>> / | \
>> Q1 Q2 Q3
>>
>> Se Q1, Q2 e Q3 tem pesos. A soma dos pesos serão as fatias de banda em
>> bits que o WF2Q+ tem que "livrar-se" por segundo. E ele o fará de forma
>> justa (o F de FAIR da sigla) de acordo com o peso (W de weight da
>> sigla).
>>
>> Por exemplo, imagine que PIPE 10 seja 512Kbit/s, Q1 tenha peso 5, Q2
>> tenha peso 15 e Q3 tenha peso 10. A soma de 5+10+15 é 30.
>>
>> Os 512Kbit/s serão dividos em 30 slices, em bit/s, que na pior situação
>> possível - Worst case, o W da sigla, ou seja numa situação em que a soma
>> do Q1+Q2+Q3 em termos de demanda de banda for superior a largura de
>> banda configurada no pipe - será dividido na proporcão, ou seja 5/30
>> avos de 512Kbit/s para o Q1; 15/30 (portanto metade) de 512Kbit/s e Q3
>> 10/30 avos (1/3 de 512Kbit/s).
>>
>> Claro né?
>>
>> Transformando essa teoria em prática:
>>
>> ----------------------------------------------
>> ipfw pipe 10 config bw 512Kbit/s
>>
>> ipfw add queue 1 all from <origem> to <destino>
>> ipfw add queue 11 all from <destino> to <origem>
>> ipfw queue 1 config pipe 10 weight 5
>> ipfw queue 11 config pipe 10 weight 5
>>
>> ipfw queue 2 all from <origem> to <destino>
>> ipfw queue 22 all from <destino> to <origem>
>> ipfw queue 2 config pipe 10 weight 15
>> ipfw queue 22 config pipe 10 weight 15
>>
>> ipfw queue 3 all from <origem> to <destino>
>> ipfw queue 33 all from <destino> to <origem>
>> ipfw queue 3 config pipe 10 weight 10
>> ipfw queue 33 config pipe 10 weight 10
>> ----------------------------------------------
>>
>> Pronto. Simples. Note que eu criei 2 queues, em fluxo IN e OUT pra
>> garantir full-duplex a papagaiada toda ok? Os numeros de queue e pipe
>> são apenas identicadores e não faz a menor diferença se quiser colocar
>> outros.
>>
>> O corpo da regra é um protótipo. Normalmente você vai querer orienta-las
>> a fluxos e interfaces.
>>
>> Pro seu VOIP basta criar 2 queues, um com weight baixo e outro alto, na
>> proporção de consumo de banda que você queira dar peso preferencial ao
>> VOIP, exemplo
>>
>> Q1 = todos
>> Q1 = weight 5
>>
>> Q2 = voip
>> Q2 = weight 50
>>
>>
>> --
>> Patrick Tracanelli
>>
>> FreeBSD Brasil LTDA.
>> Tel.: (31) 3516-0800
>> 316601 em sip.freebsdbrasil.com.br
>> http://www.freebsdbrasil.com.br
>> "Long live Hanin Elias, Kim Deal!"
>
>
--
Patrick Tracanelli
FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"
Mais detalhes sobre a lista de discussão freebsd