[GTER] Limitar Upload com PF+HFSC

[Rubens Kuhl Jr.]

> É uma idéia interessante, mas estou dando preferência em usar queueing
> para centralizar a administração.

Mas mesmo no exemplo que você colocou os controles de up e down são
distintos, não centralizados. Administração centralizada significa ter
um único ponto de alteração que faz as alterações em todos os lugares
necessários, não significa usar o mesmo método de controle. Essa
solução de policing de entrada + queueing de saída é a que mais vejo
em funcionamento em redes diversas (com sistemas diversos como IOS, tc
e altq).

Mas se você prefere usar queueing, procure por um equivalente BSD do
IMQ. No Linux, o IMQ é uma interface virtual que recebe pacotes da
interface física, o que permite controle de queing na saída da
interface virtual.

Para registro, as referências a Linux são para dar um parâmetro, não
para comparar a efetividade ou estabilidade das soluções. Por exemplo,
o IMQ tem um histórico de instabilidade que me leva a pensar 12345
vezes antes de usá-lo, mas que eu acredito esteja confinado à sua
implementação corrente em Linux, não ao princípio de interface virtual
intermediária que é bem interessante.


Rubens


>
> Em 06/04/06, Rubens Kuhl Jr.<rubensk at gmail.com> escreveu:
> > No sentido seu link -> cliente, que você chamou nas suas regras de
> > download, o tráfego de saída na interface já é feito desnateado, então
> > você deveria poder colocar um filtro na saída da interface interna e
> > limitar a velocidade.
> >
> > Agora, no sentido cliente -> seu link, você poderia usar ingress
> > policing ao invés de queueing/shaping. No Linux isso seria o "ingress
> > qdisc", deve ter um equivalente no BSD. Seria algo mais "bruto" que o
> > HSFC: passou da velocidade contratada o pacote é jogado fora, ao invés
> > de enfileirado para ser emitido dentro da velocidade contratada.
> >
> >
> > Rubens
> >
> >
> > On 4/6/06, Mauricio Bonani <mbonani at gmail.com> wrote:
> > > Hoje resolvi analisar esse problema até achar a
> > > causa. Consegui, agora falta pensar na solução.
> > >
> > > A questão é a seguinte, essa máquina onde faço o
> > > controle de banda também faz NAT para as conexões
> > > vindas da minha rede interna. Portanto o tráfego
> > > de saída vai com o IP 200.xxx.xxx.xxx da
> > > interface externa (obviamente), e esse IP não
> > > está contemplado pelas filas o pf.conf.
> > > Como todos os clientes "saem" com o mesmo IP
> > > 200.xxx.xxx.xxx, ainda não consegui enxergar como tratar esse tráfego.
> > >
> > > Nas regras que citei (abaixo), faço uso das tags,
> > > mesmo assim o tráfego passa pela fila padrão.
> > >
> > > Algum dos colegas tem idéia de como poderia resolver isso?
> > >
> > > At 09:29 31/03/2006, you wrote:
> > > >Salve
> > > >
> > > >pass in  quick on $if_int from $cli1 to any tag UP_CLI1 keep state
> > > >
> > > >esta regra vc nao colocou FILA... entaum tudo o
> > > >que esta nela passa pela padrao ;)
> > > >
> > > >Qq coisa pvt e eu helpeio vc ;)
> > > >
> > > >t+
> > > >
> > > >Christopher Giese
> > > >chris at irapida.com.br
> > > >
> > > >
> > > >
> > > >Mauricio Bonani wrote:
> > > > > Estou com o mesmo problema que o amigo Fabio
> > > > > Catelani, a diferença é que uso OpenBSD+PF+HFSC.
> > > > >
> > > > > Fiz a configuração da seguinte forma:
> > > > >
> > > > > # Filas
> > > > > altq on $if_ext hfsc bandwidth 100000Kb queue { std_ext, up_cli1 }
> > > > >       queue std_ext bandwidth 2Kb hfsc(default)
> > > > >       queue up_cli1 bandwidth 128Kb hfsc(realtime 64Kb, upperlimit 128Kb)
> > > > >
> > > > > altq on $if_int hfsc bandwidth 100000Kb queue { std_int, dn_cli1 }
> > > > >       queue std_int bandwidth 2Kb hfsc(default)
> > > > >       queue dn_cli1 bandwidth 256Kb hfsc(realtime 128Kb, upperlimit 256Kb)
> > > > >
> > > > > # Regras
> > > > > pass in  quick on $if_int from $cli1 to any tag UP_CLI1 keep state
> > > > > pass out quick on $if_ext tagged UP_CLI1 keep state queue up_cli1
> > > > > pass out quick on $if_int from any to $cli1 queue dn_cli1
> > > > >
> > > > > O tráfego de saída passa pela fila padrão
> > > > > (std_ext) ao invés de ir pela fila do cliente (up_cli1).
> > > > >
> > > > > Onde estou "pisando na bola"?
> > > > >
> > > > > Unix is very simple, but it takes a genius to understand the simplicity.
> > > > > (Dennis Ritchie)
> > > > >
> > > > > --
> > > > > Mauricio Bonani
> > > > > mailto:mbonani at gmail.com
> > > > >
> > > > > --
> > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > >
> > > >
> > > >--
> > > >gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > >
> > > Unix is very simple, but it takes a genius to understand the simplicity.
> > > (Dennis Ritchie)
> > >
> > > --
> > > Mauricio Bonani
> > > mailto:mbonani at gmail.com
> > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
> --
> Mauricio Bonani
> mailto:mbonani at gmail.com
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>