[GTER] alternativa a Mikrotik

Thu Oct 31 10:42:49 -02 2013

Caro William, primeiramente obrigado pelas informações e pelo 
compartilhamento da informação.
Para quem deseja utilizar OpenBGPD, acho que o grande entrave sejam exemplos 
de configuração.
Se pudesse enviar exemplo da sua configuração, acho que seria otimo para 
todos.

Obrigado

Edinilson
------------------------------------------
ATINET
Tel Voz: (0xx11) 4412-0876
http://www.atinet.com.br

----- Original Message ----- 
From: "willian pires" <willian_pires at hotmail.com>
To: "Grupo de Trabalho de Engenharia e Operacao de Redes" 
<gter at eng.registro.br>
Sent: Thursday, October 31, 2013 1:18 AM
Subject: Re: [GTER] alternativa a Mikrotik

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 suporte aos 
dois mundos.Netdispatcher não causa qualquer melhoria.Pouco ou quase nenhum 
suporte, já ficamos 8 horas com problemas junto a Algar porque alguém lá 
resolveu tirar do cisco e colocar no Juniper e ouve a necessidade de 
atualizar meu Openbgpd que rodava a mais de 2 anos direto.
Fico a disposição para ajudar desde que o ambiente seja com freebsd e 
openbgpd.
Abraço a todos.

> From: lucasmcz at gmail.com
> Date: Wed, 30 Oct 2013 16:31:12 -0200
> To: gter at eng.registro.br
> Subject: Re: [GTER] alternativa a Mikrotik
>
> Em 30 de outubro de 2013 14:52, Douglas Fischer
> <fischerdouglas at gmail.com>escreveu:
>
> > Concordo com o raciocínio do Marcelo...
> >
> > Para iSCSI e similares, o troughput é alto, mas o PPS é ínfimo quando
> > comparado ao trafego típico de internet.
> >
> >
> > Em 30 de outubro de 2013 15:11, Marcelo Gondim <gondim at intnet.com.br
> > >escreveu:
> >
> > > Em 30/10/13 11:03, Eng. Fabio Roberto escreveu:
> > >
> > >  Marcelo,
> > >>
> > >>     Temos alguns R710 formando um ambiente virtualizado em cima de
> > >> solução VMware Enterprise, todos eles com placa placa Quad Port da 
> > >> Intel
> > >> trabalhando em cima de link aggregate, com throughput bem elevado,
> > >> funcionando há praticamente 2,5anos sem nenhum problema ou queda de
> > >> performance. Inclusive a Dell disponibiliza um software para seus
> > clientes
> > >> para coleta de informações para estudo de desempenho do Storage, e 
> > >> não
> > >> tivemos nenhum índice com problema. É só uma experiência própria que
> > temos
> > >> para ajudá-lo.
> > >>
> > >> Att.
> > >>
> > >>  Olá Fabio,
> > >
> > > Você pode não ter tido o mesmo problema devido à arquitetura da Dell 
> > > nos
> > > R710. Como comentei posteriormente o grande problema pode estar no
> > gargalo
> > > do FSB. Outra coisa é que throughput não é o único fator problemático 
> > > mas
> > > também o PPS suportado no roteamento. Se o PPS for tão alto que o
> > > equipamento não suporte, você poderá ter uma interface de 1 Gbps e ela
> > > apresentar problemas com consumo de 700Mbps ou menos e por aí vai. O
> > > conjunto tem que ser muito bom e na maioria das vezes, pelo que 
> > > percebi
> > até
> > > de outras pessoas, o uso de uma interface Quad Port com grandes 
> > > tráfegos
> > > tende à dar mais problemas que o contrário.
> > > Mas mesmo assim é bom saber que em um hardware desse modelo da Dell a
> > > coisa tem fluído bem pra ti. Mas como comentei hardware para servidor 
> > > de
> > > dados não é o mesmo para roteamento pesado.  :)
> > >
> > > []'s
> > > Gondim
> > >
> > > --
> > > gter list    https://eng.registro.br/**mailman/listinfo/gter<
> > https://eng.registro.br/mailman/listinfo/gter>
> > >
> >
>
>
> O calcanhar de Aquiles quando trabalhamos com roteamento de grande volume,
> é PPS e o FSB.
> Saber disso faz a diferença tanto pra dimensionar Servidores para
> Roteadores, como também pra comprar caixas tipo Cisco, Juniper entre 
> outros.
>
> Gosto da possibilidade de trabalhar com SoftRouter com múltiplos cores, 
> com
> placa boa (Intel na sua maioria) Junto com FreeBSD porque dá pra otimizar
> muita coisa... E ainda ganha um(uns) Firewall(s) pra alguma necessidade
> especial.
>
> Substitui de boa e com segurança.
>
> -- 
> .:: Lucas Dias
> .:: (82) 8813-1494 / 8111-2288
> .:: Antes de imprimir, veja se realmente é necessário!!!
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

--
gter list    https://eng.registro.br/mailman/listinfo/gter