[GTER] alternativa a Mikrotik

[Lista]

Muito bom Willian.

Uma pergunta todo esse seu ambiente é montado em bsd?

Esse cenario é baseado em isp?


Em sexta-feira, 1 de novembro de 2013, Raimundo Santos<raitech at gmail.com>
escreveu:
> +1 para apresentação no GTER.
>
> Willian, parabéns! Tomei a liberdade de guardar aqui nas minhas
referências
> pessoais, com o devio crédito. Tenho planos que precisam dessas dicas em
> breve.
>
> Obrigado!
>
>
> 2013/10/31 willian pires <willian_pires at hotmail.com>
>
>> Boa noite,
>> Minha experiencia atual  tenho 8 routers com cargas diversas desde core
I5
>> com  600Mbps  até dual Xeon e2700 com 1.8Gbps.
>> Em um caso tipico de trafego de internet com MTU de 1500 ~ 1536, 410k
>> rotas instaladas na tabela de roteamento, 50 regras de pf e opção de
kernel
>> HZ configurada em 1000 o que eu tenho:
>> Banda de 100Mbit/s correspondem a 10kpps  8% de cpu.
>> Esses elementos crescem de forma "quadrada", 200Mbit/s 20kpps e 16% de
cpu
>> e assim sucessivamente.
>> Elementos que causam overhead nesse ambiente:
>> Tabela de roteamento.Filtro de pacotes.Desvio de rotas.Carga de
>> processamento no core 0.
>> Minhas placas de rede são intel dual-port em placas mãe com no minimo 2
>> pci-e 16x, não uso pci normal ou pci-x mesmo de 133Mhz.
>> O driver igb prove 4 irq's de "trafego" e 1 de sinalização por porta
>> .rt04# vmstat -i | grep -i igbirq259: igb0:que 0           49513375873
>>   8101irq260: igb0:que 1           48513500730       7938irq261:
igb0:que 2
>>           48048397625       7862irq262: igb0:que 3           48624606499
>>     7956irq263: igb0:link                      2          0irq264:
igb1:que
>> 0           52553838846       8599irq265: igb1:que 1
48901074080
>>       8001irq266: igb1:que 2           49130825639       8039irq267:
>> igb1:que 3           49160000605       8043irq268: igb1:link
>>        2          0
>> Existem placas mais modernas x340 ibm que provem 8 irq mas a nossa lógica
>> segue a mesma.
>> Em ambientes com 1 cpu e 4 cores eu divido:
>> Porta ethernet 1 todos irq de trafego no core 2.Porta ethernet 2 todos
irq
>> de trafego no core 3.
>> Todos irq de sinalização no core 1.
>> Cada irq  é amarrado da seguinte forma:cpuset -x 259 -l 2 e assim por
>> diante.
>> Os processos do openbgpd, pf e roteamento ficam por si só amarrados ao
>> core 0.PS: o processo do openbgpd deve ser configurado com cpuset -p
>> <pid> -l 0.
>> Para ambientes com 2 pastilhas "processadores" a divisão é a mesma porem
>> coloco sempre mais 1 placa para dividir as tarefas, 2 wans 2 lans, não
>> fazemos swap de interrupções entrepastilhas físicas isso gera uma perda
de
>> performance na ordem de 50% não nos aprofundamos nos motivos mas
assistimos
>> um roteador com processadores E5645 com menos de 300Mbit/s chegar a um
load
>> de  7 e pacotes receberem uma latência de mais de 0.300 ms por pacote.
>> Nenhum state é feito no pf.conf o "last match" é sempre com "no state"
>> evitamos regular um trafego quepor si só deve ser regulado no firewall do
>> cliente.
>> Benefícios:Meu openbgpd carrega 400k rotas em 13 segundos, injetando elas
>> no kernel.Minha latência tipica de roteamento é 0.099ms.Por mais que a
>> maquina esteja a 80% no cores 2,3 tenho sempre uma resposta muito rápida
de
>> interação.Com o openbgpd no core 0 isolado não documentamos hang do
>> processo.Redundancia a partir de 2 sessões BGP de wan as rotas ficam
>> praticamente aguardando entrar e a convergencia totaldemora menos de 5
>> segundos.Mesmo sob ataque de 480kpps udp a caixa se manteve estável e
>> roteando.OpenBGPD na minha opinião é a ferramenta mais flexível e
completa
>> para roteamento comparado com: Juniper,Cisco,Brocade,Mikrotik.
>> Deficiências:Estamos limitados a 64 vlans por porta segundo o driver da
>> Intel.O filtro de pacotes ainda  é o maior vilão do cpu 0.Não conseguimos
>> um bom processo de swap de interrupções entre os processadores.A partir
de
>> 2000 hosts em uma tabela de pf o processo de checagem se torna lento.Não
>> conseguimos usar ECMP **:-(** Esse com certeza é o maior problema atual,
>> uma vez que MP_RADIX derruba o kernel quando chega em 3 Milhões de rotas
e
>> o trafego ultrapassa 100Mbit/s.Nenhuma agregação de link L2 funcionou
>> adequadamente com suporte a falha.Não temos uma integração boa entre
OSPF e
>> BGP é feito um segundo BGP para uma caixa "Allied/Extreme" com su