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

[Cristofer Velloso]

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