[GTER] alternativa a Mikrotik

Osvaldo T Crispim Filho osvaldotcf at gmail.com
Sun Nov 3 10:37:54 -02 2013 

Muito interessante tudo o que vi aqui, confesso que estou com um certo frio
na barriga pois vou caminhar para uma solução convergente a do William e me
parece algo de dimensões enormes.

Imagino que o projeto BSD Router Project ( http://bsdrp.net/ ) seja o
caminho que vou usar pois me parece atingir o alvo em cheio.


Vi aqui questões sobre os "open-source" que sempre vejo em outras
discussões e , para mim, acredito ser a falta de suporte o maior problema
das soluções "open-source" e que muitas vezes é causado pelo entendimento
de que open-source tem que ser de graça! Achar uma boa solução de suporte
pode ser a diferença entre sucesso e fracasso em implantação de projetos
que fazem uso de soluções de código aberto.

Muito obrigado a todos pelas informações trazidas aqui.
Abraço a todos e por favor nos avisem sobre a apresentação do William.


Em 1 de novembro de 2013 08:32, 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 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
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
             - Osvaldo T Crispim Filho -

More information about the gter mailing list