[GTER] IX Broadcast - Sugestão - Broadcast Clearing vs ARP Sponge

Thu Aug 31 11:19:00 -03 2017

Então Thiago e demais colegas.

Andei fazendo algumas análise mais profundas, olhando principalmente para
os destinos...
E uma de minhas desconfianças agora já é uma conclusão.

 -> O uso de Rate-limit de ARP, seja em PPS seja em BPS, agrava MUITO os
problema do ARP no IX-SP.

Ainda não consegui achar um jeito de analisar "QUANTO" o problema aumenta.
Mas filtrando as perguntas por destino, observei MUITAS RE-perguntas de um
mesmo participante para outro participante...

Eu pude chegar a essa conclusão justamente analisando uma das coletas que
foi feita em uma porta que estava com esse Rate-Limit Aplicado.

Se eu fosse "CHUTAR" eu diria que de 20-30% do total são provocados pelo
uso dessa limitação.

Sei que isso está sendo feito para proteger a CPU dos Hardware Routers.
E isso, do ponto de vista individual, está corretíssimo.
Mas é sim, uma das causas do aumento de ARP-Requests em Broadcast no IX-SP.

A pergunta agora é:
Oque fazer para resolver?

Antes a minha opinião era a de "confinar" esse tráfego... Usando
Arp-Responder e ACLs L2.
Mudei de opinião!

Minha sugestão agora é:
Ajustar os ARP-Timeouts de todos os participantes
Implementação de ARP-Sponge (como uma palmatória para que não se adequar)

Porque mudei de ideia?
A causa do problema depende não de protocolo, e sim de configuração.
E na minha experiência problemas de configuração se resolvem com políticas.
Pode ser política de livre demanda(mundo ideal) ou reativas...

Eu estimo que no PIX(mais os CIX) mais populoso o número de participantes
pode bater uns 350 participantes.
Se for usado EVPN para isolar os ARP-Request, isso restringir-se-á a cada
PIX.
Só nesses 350 participantes que continuariam recebendo seus broadcasts de
ARP-Request, isso já seria o suficiente para gerar problemas nas CPUs de
algumas caixas.
Oque exigiria a aplicação de Rate-Limit, e por consequência geraria
re-envio de arp-requests.
Logo, a eficácia da solução seria parcial.

Então @Thiago
Eu tenho esperança que o NIC tome a frente nessa questão e crie um programa
e cronograma para esses ajustes de cada participante, e implementação de
ferramenta de monitoramento/palmatória.

Mas caso isso não aconteça, eu gostaria de contar com os colegas para
criarmos um Hall-Of-Shame de maneira automatizada.
Talvez com base no código do IX de Amsterdã, ao invés de reagir de maneira
ativa dentro do barramento do IX(não é permitido fazer isso), popular uma
lista de participantes fora do padrão esperado, e talvez até com disparo de
e-mails automatizados...

Abro aqui espaço para sugestões.
Ideias ainda sendo lapidadas...

Em 30 de agosto de 2017 09:24, THIAGO AYUB <thiago.ayub at upx.com> escreveu:

> Olá Douglas e demais envolvidos no assunto,
>
>
> Também tenho interesse em obter a lista em ranking dos nossos vizinhos mais
> ruidosos no ATM do IX.br de SP. Tenho os recursos humanos e computacionais
> para entrar em contato com dezenas e centenas de Sistemas Autônomos para
> emitir um alerta. Nosso SOC aqui já faz trabalho semelhante alertando por
> e-mail, INOC-DBA e telefone sobre vulnerabilidades exploradas para ataques
> DDoS e mantemos o cert at cert.br em cópia destas comunicações. Muitos de
> vocês aqui já devem ter recebido contatos nossos.
>
> Já que o NIC.br tem demorado a agir quanto a este assunto, vejo que como
> comunidade temos os meios, métodos e motivações corretas para resolver o
> problema. Estou disposto a colocar estes meus recursos para contactar AS
> por AS desse ranking de centenas de participantes, do mais ruidoso para o
> menos ruidoso, para que configurem seus roteadores de forma mais adequada
> nos parâmetros de ARP para atuarem no IX.br.
>
> Posso contar com a ajuda de vocês? Quem consegue gerar esse ranking para
> mim?
>
>
> Atenciosamente,
>
>
> T. Ayub
> UPX Technologies
>
>
>
>
>
> *T. Ayub* | Chief Technology Officer
>
> T.  +55 11 2626 3952 <+55%2011%202626-3952>
>
> www.upx.com
>
> Em 29 de agosto de 2017 22:35, Cristofer Velloso <
> cristofervellosol at gmail.com> escreveu:
>
> > Errata.. fui precipitado, hj deu pico de 2kpps.. nao tá limitando em
> > 1,5k não ...
> >
> > Com a engajamento de todos para no IX de SP deve baixar isto e melhorar
> > geral.. 1500 arp por segundo é bastante coisa de qualquer forma. muito
> > pra uma rede que não tem 1500 ativos.
> >
> > Lembrando que:
> >
> > *  mikrotik tem que aumentar arp cache timeout , sugerido foi 4h. e
> > desativar o discover (dá um broadcast por minuto, mas é broadcast ).
> >
> > /ip settings set arp-timeout=4h
> > /ip neighbor discovery  set [find] discover=no
> >
> > * Quem limita broadcast por pps em transporte ou na porta do router tem
> > que por no mínimo 1,5kpps pra não ter quase nada de descarte.
> >
> > * quem limita por mb/s  1m/s no mínimo. (Estou tendo descarte com 1m/s
> > mas é bem pouco , ptt-rs tive que por para 512k que com 256 estava
> > dando bastante descarte já )
> >
> > Apliquem  em outros IX para não chegar no mesmo problema no futuro, no
> > ptt-rs também domina mikrotik com 50% de CCRs.
> >
> > []os
> > Cristofer
> >
> > Em Seg, 2017-08-28 às 08:53 -0300, Cristofer Velloso escreveu:
> > > Oi..
> > > Dei mais uma estudada nas capturas e estava querendo medir em PPS os
> > > broadcast e encontrei um limite que parece ser pelo lado do IX.
> > >
> > > Já tinha tentando medir broadcast como non-unicast ou multicast com
> > > snmp em juniper e mikrotik sem sucesso. Testei com freebsd e huawei
> > > consegui medir via snmp (freebsd soma tudo no multicast, e huawei no
> > > non-unicast). Bati os números com capturas em mikrotik e porta de
> > > juniper e coincidem.
> > >
> > > O controle de storm provavelmente está limitando os broadcasts em
> > > 1,5Kpps pois o gráfico chapa ai quase o dia inteiro, baixando de
> > > 1Kpps
> > > somente entre as 2 e 6:30. Somente isso já gera retransmissões
> > > (efeito
> > > bola de neve) e falhas de arp.  Quem limita em pps muito baixo é
> > > prejudicado e deve ser o motivo do huawei ser os top "perguntados"
> > >
> > > Tem como aumentar esse numero do lado do IX pra diminuir o descarte ?
> > > é
> > > paleativo enquanto não se segmenta os broadcasts dos pix com EVPN.
> > >
> > > []os
> > > Cristofer
> > >
> > >
> > >
> > >
> > >
> > > Em Ter, 2017-08-08 às 10:56 -0300, Douglas Fischer escreveu:
> > > >
> > > >
> > > > Estive falando com vários amigos e colegas que estão, há algum
> > > > tempo,
> > > > sofrendo com Broadcast de ARP resolution no IX-SP.
> > > >
> > > > Primeira coisa que lembramos
> > > >  foi
> > > > sobre a discussão de uns 3 anos atrás sobre os filtros no PTT
> > > > "Portal
> > > > vs
> > > > Communities".
> > > > Comentamos como a solução mais dispendiosa inicialmente hoje é a
> > > > mais
> > > > elegante.
> > > >
> > > >
> > > >
> > > > Batemos uns papos sobre as possíveis causas, as várias possíveis
> > > > soluções e
> > > > outras variáveis na questão:
> > > > Filtros Locais(shaping/filter/copp), Filtros centralizadas(Sponge /
> > > > BroadcastFilter+ArpResponder), Ajustes de Timeout do ARP, Software
> > > > Router
> > > > vs Hardware routers, Vendors e Versões, Expertise, Pênaltis.
> > > > (Deu-se muitas risadas inclusive.)
> > > >
> > > > Conjecturou-se diversas possíveis soluções, mas as
> > > > principais(centralizadas) foram:
> > > >
> > > >  A - ARP sponge do IX de Amsterdã
> > > >      --------------------
> > > > --------
> > > >
> > > >  B - ARP Responder + Bloqueio(redirect) de Broadcast
> > > >      -----------------------------------------------
> > > >
> > > >
> > > > Eu pessoalmente estou mais inclinado pela opção do ARP Responder,
> > > > pois
> > > > penso que a solução do ARP Responder é basicamente reativa...
> > > > Eu nem tinha ideia que a técnica ARP-Responder já era utilizada em
> > > > grandes
> > > > provedores de Cloud.
> > > >
> > > >
> > > >
> > > >
> > > > Mas até agora estamos
> > > >
> > > > sentindo falta de uma discussão
> > > >
> > > > que esteja mais próxima dos envolvidos, equipe técnica do
> > > >  NIC, e demais colegas da GTER, e participantes do IX-SP.
> > > > Percebi que a conversa deu uma esfriada.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > P.S.1: Agradeço aos colegas! Aprendi bastante
> > > > ! I
> > > > nclusive sobre SDN e redes de grandes serviços de Cloud/Hosting.
> > > >
> > > > P.S.2: Importante dizer que verificamos que o problema também está
> > > > presente
> > > > no IX-RS e IX-PR, só que numa escala que não afeta tão gravemente
> > > > as
> > > > caixas... Imagino que outros IX mais gordinhos também estejam
> > > > padecendo.
> > > >
> > > >
> > > > --
> > > > Douglas Fernando Fischer
> > > > Engº de Controle e Automação
> > > > --
> > > > 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
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação