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

[THIAGO AYUB]

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
>