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

Thu Aug 31 11:37:00 -03 2017

 > 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)

Eu considero desde o começo dessa thread a adoção de ARP-Sponge como a mais
interessante, inclusive sendo usada por outros IX pelo globo.

Também voto por um pente fino em captura de pacotes para verificar os
tempos em que cada participante enviam os dados. E sim, capturar arp por
4h, gravar tudo e gerar estátisticas - visando notificar os poluentes.
Talvez seja conveniente que esta captura seja feita periodicamente.

[image: --]

Leonardo Amaral
[image: https://]about.me/leonardo.amaral
<https://about.me/leonardo.amaral?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>

Em 31 de agosto de 2017 11:19, Douglas Fischer <fischerdouglas at gmail.com>
escreveu:

> 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>