[FUG-BR] FreePF -- Firewall box com interface e scripts em python

2016-06-27 Por tôpico Luiz Gustavo S. Costa
Olá Senhor@s,

Tenho trabalhado em um projeto de implementar um firewall box com
inicialização (configuração de rede, serviços, etc...) tudo via python,
inclusive usando o supervisord como gerenciador de daemons do sistema (sim,
englobando coisas como ssh, syslog, etc).

Desafio bem legal, já que estou migrando boa parte de shellscript (sh) para
python, o que achei muito bom !

Outra parte de desenvolvimento é GUI web para gerenciamento, com uma camada
de message queue com celery (e a principio com zmq) e para a parte web
nosso famoso Flask como framework.

Enfim, esta embrionário e espero logo já ter uma versão funcional bem
rápido, se tudo correr bem com o projeto e $eus patrocinadores. (assim que
possível formalizo documento para parcerias)

é um desafio e tanto !!! :-) ... quem tiver interessado no projeto e quiser
acompanhar de mais perto ainda, entre em contato comigo.

As principais features são:
- Licença BSD (sempre!)
- FreeBSD 10.3 & 11.x (e possivelmente Netbsd port)
- Reescrevendo tudo em python (inclusive o init -- rc.py) ( baseado no
pfSense / m0n0wall )
- Tudo em camada:
> Camada CLI (acesso root)
> Camada Task (entre GUI e CLI)
> Camada GUI (framework Web e API)
- instalador python multi-lingua (60%)
- interface cli (console - menu) multi-lingua (70%)
- Tudo yaml (inclusive init rc.py)...
- task manager (celery) - 30%
- Interface web (Framework Flask + API) + nginx (?) - 25%
Isso tudo ainda é uma prévia-da-prévia a coisa vai se difundir mais com
o primeiro release, inclusive para developers.

Já temos uma url (sem nada por enquanto) = http://www.freepf.org

Abraços !

-- 
Luiz Gustavo Costa (Powered by BSD)
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
ICQ: 2890831 / Gtalk: gustavo@gmail.com
Blog: http://www.luizgustavo.pro.br
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Re: [FUG-BR] Interrupção alta no ServerU

2016-06-27 Por tôpico Patrick Tracanelli

> On 23/06/2016, at 08:51, Antonio Modesto  wrote:
> 
> 
> 
> On 21-06-2016 18:47, Patrick Tracanelli wrote:
>>> On 20/06/2016, at 13:15, ae moura  wrote:
>>> 
>> mete netmap-ipfw nisso ai e seja feliz
>> 
> evandin sempre a frente do seu tempo rsrs
> 
 HAHAHA bixa militar enrustida
>>> pra quem você sempre bate continência rsrs palhaço :-P
> seu cenario ta bem legal, esta estavel o netmap-rt?
>>> o que está estável está estável rsrs, mas 2 coisas não estão...
>>> 
>>> 
>>> as acls do netmap-rt não funciona a ação nexthop por porta ainda (pbr) o 
>>> que me impede por exemplo de redirecionar para um cache, isso é bug e o 
>>> patrick está sabendo e parece que estão corrigindo, as rotas na fib e no 
>>> netmap-rt as vezes ficam divergentes, mas notei que só acontece isso quando 
>>> cai alguma sessão bgp e tem flood de withdraw routes, o próprio 
>>> netmap-rtctl percebe a divergência quando da "route get" ai eu corrijo 
>>> dando "netmap-rtctl fib sync" também é bug e acho que está sendo corrigido 
>>> rsrs
>>> 
>>> 
>>> ou seja nada que comprometa o uso, mas requer melhorias
>>> 
>>> agora minha reclamação é que as vezes durante o start da um kernel panic 
>>> maldito e reboota tudo, mas isso é do netmap e não do netmap-rt porque dá 
>>> isso com netmap-ipfw também por exemplo… foda
>> 
>> Bom dia,
>> 
>> A ação nexthop das ACLs vai funcionar amanhã, no netmap-rt 0.5, amanhã 
>> liberaremos o pacote.
>> 
>> A divergência de sincronia quando tem um flood é por conta do paralelismo do 
>> RTM_SOCKET, as vezes perde-se RTM_MESSAGES de UPDATE, CHANGE ou DELETE, é 
>> osso isso, é um limite da facility de kernel do FreeBSD, da pra perceber 
>> esse limite manualmente, se você rodar “route -n monitor” durante a 
>> convergência de um FULL ROUTE BGP vai ver que embora tudo entre na FIB, nem 
>> todas as mensagem são percebidas pelo socket pa na prática é um while no FD 
>> e enquanto vc esta processando uma message podem chegar varias outras e voce 
>> perder. Estamos trabalhando nessa estratégia de convergência, nas próximas 
>> versões isso será melhorado ;) Esse problema é crítico pra mim porque o 
>> roteamento baseado em instruções ASICS nas Chelsio também dependemos disso, 
>> jovem.
>> 
>> Mas segue sendo cobaia (digo, beta tester ;) ai que seu feeling é 
>> importante! :D
>> 
>> Sobre os panic, vamos lançar o ProApps com um novo Netmap, mais novo que no 
>> -CURRENT e mais novo que no Github, que deve melhorar demais essa 
>> estabilidade em redes Intel, e tem razão é do netmap, não da aplicação.
>> 
>> VQV :-)
> 
> Fala Patrick,
> 
> Esse netmap-rt vai ser open source ou somente integrado ao pro apps?

Modesto,

As duas coisas, uma não exclui a outra, é open source com distribuição de 
fontes a parceiros/clientes mas por hora restrito a uso no ProApps, mesmo em 
pkg, e não pretendemos mudar isso nessa etapa de BETA. Pra ser bem sincero nem 
da pra rodar no FreeBSD normal ainda, o netmap que tem no FreeBSD -STABLE é bem 
velho e preliminar, e mesmo no -CURRENT é um netmap bem diferente do github 
(publico) ou do repositório do Giuseppe / Luigi. Ja no ProApps tem um netmap 
todo diferente, MFC que nós mantemos no -STABLE de algo alem do que existe no 
-CURRENT ou github. Não que esse “diferencial” nos deixe orgulhosos hehe é um 
saco manter MFC do Netmap (o framework) no ProApps, queríamos que o do -STABLE 
estivesse ja com MFC feito e mantido na versão mais top possível, mas não é 
assim hoje. Até tentamos (o Jean) com o Luigi submeter o MFC do ProApps pro 
10-STABLE mas a verdade é que nós só testamos com Intel (ix, igb) e Chelsio, 
não temos tempo ou maquinas pra testar em redes re, rl, bce, bge, em, mellanox, 
etc, ou seja o que é bom pro ProApps não é necessariamente abrangente o 
suficiente pro FreeBSD -STABLE. Então rodar o netmap-rt no 11 hoje, é possível, 
mas não vai dar os melhores resultados. E rodar no FreeBSD -STABLE hoje seria 
frustrante: panic so de subir o serviço, se não for em rede Chelsio.

Infelizmente no FreeBSD 11.0-ALPHA1 ainda não vi merges felizes do branch 
Melifaro Routing ou do Netmap, mas sei que o primeiro existe no roadmap e o 
segundo em algum momento o Giuseppe diz que vai fazer um merge no mínimo do que 
tem no Github (o que ja seria ótimo), mas a verdade é que ainda não da pra 
saber ao certo o que teremos no 11 quando sair pra saber se vamos poder 
considerar rodar netmap no FreeBSD e não apenas no ProApps.

Portanto a coisa vai um pouco além, o FreeBSD 11 seria o mínimo, e ainda 
insuficiente, mas o carimbo “CURRENT” assusta. Ja no -STABLE é frustração pura, 
com direito a kernel panic de cara ou não funcionar quando sobe hehehe. Então 
deixa a coisa andar no FreeBSD, enquanto isso anda por aqui, e no futuro o 
plano é liberar versões do netmap-rt, mesmo com alguns ciclos de atraso do que 
tem no ProApps (afinal o ProApps tem que manter o diferencial hehehe), mas hoje 
rodar fora do ProApps é 

Re: [FUG-BR] Interrupção alta no ServerU

2016-06-27 Por tôpico Antonio Modesto



On 17-06-2016 10:48, Sergio Faulhaber wrote:

Caros,

comprei um serveru lm-400 para substituir 4 pcs que tenho hoje fazendo 
autenticação de clientes.

Uso o freebsd 10.2 nele e todas as placas rede são igb.
Na autenticação do usuário é criado um par de regras pipe definindo a 
velocidade de conexão.
Estou usando apenas 2 interfaces , uma no barramento principal e outra 
no barramento dos clientes.
O problema que estou tendo é que com 800 usuários autenticados e e 
torno de 300 mbits/s emcada interface

a interrupção esta beirando 90% e idle 0 .
Me indicaram a refazer o firewall usando tables e criando poucas 
regras de pipe .
Hoje com 800 usuários o firewall fica com 800 pares de pipe ( 1 in 
outro out) .
Só que preciso de tempo para refazer o firewall e achava que o 
equipamento iria aguentar pelo menos 1200 usuarios.
Tenho feito alterações no loader.conf e sysctl.conf mas estou na 
tentativa e erro.

Já aumentei o kernel.hz para 2000 ,
hw.igb.rxd="4096"
hw.igb.txd="4096"
e várias outros.
Alguém teria alguma orientaçao para poder melhorar a performance ?

Obrigado




Acho que nesse caso você teria mais sucesso com o Accel-PPP, que possui 
controle de banda internamente, sem regras de firewall. Infelizmente o 
accel só funciona no Linux.



--
Atenciosamente,


-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd