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

Thu Aug 31 11:37:39 -03 2017

Apenas para aumentar o grau de atenção para esse tema:

De uma outra conversa surgiu a possibilidade de uma janela para uma Negação
de Serviço no IX.
Hoje, pelo que estamos analisando, os ARP-Requests estão na cada de
1500-1600 PPS na VLAN do ATM do IX-SP.

Isso faz com que caixas como o Juniper MX80(sem rate-limit) gastem 14-15%
de CPU para processar esses pacotes. Caixas como Cisco 7606 gastem 8-9%.

Oque impede um participante com uma porta no IX criar um script em bash
para gerar 30K PPS de arp-request?
(além do medo de tomar um BAN depois de rastreada a origem)

Qual seria o impacto disso?

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
>

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