faz o pipe apenas pelo IP...
e a regra do accept faça atraves de AND do ip e mac.
assim vc 'nao complicou' o seu script de fw fazendo regra dummynet em
layer2...
e liberou apenas os clientes com MAC previamente cadastrados
o mal intencionado teria q saber q vc faz isso, e clonar o mac de algu
Entendi...
seu objetivo (q estaria causando o kernel panic) é o MAC + pipes
Não dá Kernel Panic no 9.2, somente no 10.1, no 10 simplesmente não há
navegação, nem com MAC nem com IP direto.
Sobre PPPoE é meu futuro, estou caminhando para isso mais são muitos
clientes e tenho muitos concentradores
Entendi...
seu objetivo (q estaria causando o kernel panic) é o MAC + pipes
Duvida:
-sem as regras de mac address, está tudo carregando normal ne? (pipes por
IP) e baixa cpu?
-pra estar gerando tanta carga na cpu assim, qual o throughput q estamos
falando? (pra saber se a alta demanda de cpu é
Testes que eu fiz com a versão 10.1-RC4, se alguem puder fazer algo
semelhante no PRERELEASE pra ver se o resultado é o mesmo.
Options no Kernel:
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100
options IPFIREWALL_DEFAULT_TO_ACCEPT
Fabricio, eu uso o divert em alguns cases (mais de 20), só que o consumo de
cpu e a latência conforme a banda consumida e o número de sub-redes com
alias na placa interna aumenta está ficando inviável.
A tentativa de utilizar essa forma de NAT é reduzir esse consumo de CPU e
também manter uma latê
> Em 11/11/2014, à(s) 12:05, Marcelo Gondim escreveu:
>
> On 11/11/2014 11:07, Paulo Henrique - BSDs Brasil wrote:
>>
>> Em 11/11/2014 10:42, Marcelo Gondim escreveu:
>>> Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode
>>> ser atualizado à partir da árvore releng/10.1
Talvez o divert natd seja o q esteja funcionando no seu script
add divert natd all from 192.168.0.0/16 to any via wan0
eu costumava usar assim, inclusive com pipes.
mas o seu one_pass está me fazendo refletir se deveria ser setado em 1 ou nao...
[ ]'s
Fabricio Lima
When your hammer is C++, eve
On 11/11/2014 11:07, Paulo Henrique - BSDs Brasil wrote:
Em 11/11/2014 10:42, Marcelo Gondim escreveu:
Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já
pode ser atualizado à partir da árvore releng/10.1 através do svn. :)
[]´s
Gondim
-
Histórico: h
On 11/11/2014 11:13, Tiago Ribeiro wrote:
Em 11/11/2014, à(s) 11:07, Paulo Henrique - BSDs Brasil
escreveu:
Em 11/11/2014 10:42, Marcelo Gondim escreveu:
Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode ser
atualizado à partir da árvore releng/10.1 através do svn. :
Bom dia pessoal, devido a um problema com Pipe + MAC Address no FreeBSD 10
para controle de upload (thread antiga aqui), estou fazendo testes na
versão 9.2 do Nat do IPFW usando libalias.
Pois bem, independentemente das demais regras (testei somente com as de
NAT) o comportamento no FreeBSD 9.2 fi
> Em 11/11/2014, à(s) 11:13, Tiago Ribeiro escreveu:
>
>
>> Em 11/11/2014, à(s) 11:07, Paulo Henrique - BSDs Brasil
>> escreveu:
>>
>>
>> Em 11/11/2014 10:42, Marcelo Gondim escreveu:
>>> Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode
>>> ser atualizado à partir
> Em 11/11/2014, à(s) 11:07, Paulo Henrique - BSDs Brasil
> escreveu:
>
>
> Em 11/11/2014 10:42, Marcelo Gondim escreveu:
>> Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode
>> ser atualizado à partir da árvore releng/10.1 através do svn. :)
>>
>> []´s
>> Gondim
>>
Em 11/11/2014 10:42, Marcelo Gondim escreveu:
Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já
pode ser atualizado à partir da árvore releng/10.1 através do svn. :)
[]´s
Gondim
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista
Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já
pode ser atualizado à partir da árvore releng/10.1 através do svn. :)
[]´s
Gondim
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebs
14 matches
Mail list logo