[GTER] Hardware ServerU L-100 / L-800

Fri Feb 27 14:31:51 -03 2015

2015-02-25 15:37 GMT-03:00 Jonatas M. Victor <jonatasmv at gmail.com>:

>  Srs,
>
>    E na questão de redundância de hardware eles não tem fonte redundante.

Então eu trabalharia com eles como trabalho hoje, sempre com 2 caixas
> operando em nobreaks separados e com operadoras
> separadas  falando bgp entre si e entregando os 2 como gw no igp.
>   Como vcs tem trabalhado esse cenário?
>

convenhamos é melhor mesmo ter redundância de caixa do que uma caixa com
redundância de fontes, e não sei como seria no caso de um appliance serverU
mas servidores normalmente, barebone, só mobo e chassi, uma caixa com fonte
redundante sai quase o valor de duas

o que eu faço com redundância bgp é ter 2 caixas, em todas as portas que
vão pra minha infra (LAN) com CARP. em linux, vyos, etc você tem o
equivalente que é VRRP (FreeVRRP se não quiser pagar royalties pra cisco
pelo nome SHSHSH) ou uCARP.

nas pontas que vão pro upstream BGP, 2 sessões com cada operadora, Na caixa
master (carp/vrrp master) faço os anúncios BGP normalmente, na caixa BACKUP
(carp/vrrp backup) faço todos os mesmos anúncios, porém com prepend do meu
ASN 2 ou 3 vezes

o resultado é uma redundância literal com 0 de downtime

se a caixa master falhar imediatamente (imediatamente mesmo, cerca de
200ms) o slave assume os IPs do lado LAN, e na caixa backup o bgp ja esta
la, fechado, a saída está garantida; o retorno assim que o BGP perceber que
a caixa caiu (e salvo se sua outra ponta for desses que "deixa a rota
presa") já não existem as rotas bgp preferenciais e as únicas que sobram
são as com prepends

é 0 downtime pq vc tem a redundancia do BGP a seu pleno favor e a do
CARP/VRRP do lado de dentro, ou seja não tem que esperar uma possível
convergência BGP, rotas FULL chegarem, etc

no entanto existem operadoras que nem sempre tem a boa vontade de dar 2
sessões BGP pro cliente, se você não conseguir negociar isso na hora
apropriada (fechamento de contrato) e realmente eles criarem dificuldades
(telefônica e telemar normalmente), ai voce teria que fechar BGP num IP
redundante também (CARP/VRRP) e quando a caixa master cair, vai ter um
downtime até dar timeout do bgp, a sessão cair, subir de novo no mesmo IP
mas agora outra caixa, e as rotas convergirem... não será um downtime muito
longo, máximo HOLDTIME+KEEPALIVE+TEMPO_CONVERGENCIA que não deveria passar
de 2 minutos, mas também não será tão agradável como seria se tivesse
sessões BGP redundante sempre ativas e prontas pra serem usadas a qualquer
instante

não sei qual sistema voce vai usar mas a solução funciona nem no vrrp do
mikrotik, no vyos, claro freebsd, linux puro.

e claro não se aplica só a serverU mas qualquer caixa de qualquer
fabricante, seja uma cisco ou uma maquina montada

>
>
> 2015-02-25 12:54 GMT-03:00 Patrick Tracanelli <eksffa at freebsdbrasil.com.br
> >:
>
> >
> > > On 24/02/2015, at 20:32, Rubens Kuhl <rubensk at gmail.com> wrote:
> > >
> > > Qualquer x86 vai comer isso com farinha. O ServerU é legal pela
> > integração,
> > > consumo etc.,  mas 200 regras stateful é pouco para um PC.
> > >
> > >
> > > Rubens
> >
> > Maais ou menos, mais ou menos. Infelizmente não é bem assim pra x86 ou
> > qualquer outra arquitetura.
> >
> > O casfre perguntou sobre regras e não states. E uma regra é tudo que você
> > precisa pra gerar milhões de states e esgotar sua RAM. Vira e mexe essa
> > discussão acontece no NANOG, e os pontos sempre dão pano pra manga. Mas
> > vamos simplificar, IPTables vai consumir 4K por state sem contará, 5 a 6K
> > com conntrack. PF e IPFW vão gastar 4K de memória por state sem NAT. Dai
> ja
> > é fácil observar que tenha 2G, 4G, 8G ou 128G de RAM, o recurso e finito
> e
> > pode esgotar mesmo com 1 única regra.
> >
> > Isso independe da máquina, nada específico de ServerU, no site cada
> > ServerU tem seus limites informados.
> >
> > Da mesma forma 1 regra é tudo que você precisa pra acabar com a CPU de
> > qualquer máquina. Mesmo máquinas com mais processamento. Por exemplo,
> tenho
> > um cliente, provedor (que está aqui na lista inclusive) que desvia um
> > tráfego em paralelo tão alto de pro PeerApp que ele apenas 4 regras de
> fwd
> > fazem uma máquina com quase o dobro de processamento da ServerU sentar
> (na
> > prática, um Xeon 16 CPU @2.2Ghz) com apenas 4 regras de fwd. A solução
> pra
> > isso existe, poderia-se fazer com netmap-ipfw ou com uma placa que faça o
> > trabalho sujo ao invés de exaurir as CPU. Nesse cliente em específico o
> > segundo caso foi que fizemos. Antes disso ele tentou com uma caixa cisco
> > que também sentou, e uma caixa brocade que nem sei pra que ela se
> destina,
> > mas também sentou. Uma máquina com mais CPU que a L-800 sentou, então a
> > L-800 sentaria exceto se usasse a mesma estratégia de offload em hardware
> > próprio, que no caso da SU teria pelo menos 3 opções a mais de expansões.
> >
> > Ou seja 50 mil regras num x86 pode não fazer nem cócegas; 4 regras (ou
> até
> > menos) pode ser suficiente pra acabar com qualquer máquina. Na prática
> > pouco importa o número de regras, um firewall muito mal feito com 50 mil
> > regras que são sempre processadas e os pacotes só dão match na última,
> vai
> > gastar menos CPU pra evaluation do kernel (system) do que a ação vai
> gastar
> > de CPU com interrupções, principalmente se a ação não for um drop
> simples.
> > Ações mais elaboradas como fwd, divert, tee, nat, route-to, mangle, serão
> > mais CPU-intensive na efetivação da ação do que no evaluation das regras.
> >
> > Os limites de fato são sessões simultâneas e PPS filtrado. No caso das
> > ServerU, estão no datasheet e está no site. Testamos individualmente com
> os
> > sistemas de referência, e esses valores vão variar de sistema pra
> sistema,
> > por exemplo:
> >
> > Aba “Firewall & IDS” - http://www.serveru.us/pt/netmapl800
> >
> > No caso da L-100 por exemplo (http://www.serveru.us/pt/netmapl100)
> > podemos ver que um Linux vai suportar mais que o pfSense. E ambos vão
> > suportar mais que um ROS.
> >
> > Se você esperar mais PPS e mais sessões do que está la, a máquina pode
> não
> > dar conta. Independente do numero de regras carregada.
> >
> > Infelizmente a maioria dos fabricantes pouco se importam em testar e
> > deixar claro onde estão os limites. Exceto iXsystems mas o foco deles
> acaba
> > sendo outro. Nós tentamos ser o mais transparente possível pra indicar
> qual
> > o limite das ServerU. E no caso de firewall o limite certamente não está
> no
> > numero de regras.
> >
> > --
> > Patrick Tracanelli
> >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> .:Abraços:.
>
> <<< Jonatas M. Victor >>>
> jonatas at jmv.eti.br
> jonatasmv at gmail.com
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

-- 
===========
Eduardo Meyer
pessoal: dudu.meyer at gmail.com
profissional: ddm.farmaciap at saude.gov.br