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

[Douglas Fischer]

Kurt,
dentro dos planos de nossa galerinha está a criação desse "hall-of-shame".
Mas EU TENHO MEDO de divulgar essa lista!

A ideia original de criar esse "hall-of-shame" era justamente sugerir que
os demais participantes isolassem esses barulhentos, filtrando prefixos
entrantes e divulgando no-export(65000:ASN)...

Mas eu ouvi coisas bastante esdrúxulas nessa jornada. Como:
 - "Eu quero mais é que se F****, comprei ASR e quanto mais problema der
para os outros melhor."
 - "Vamos atacar esses *?*?*?*."
 - Várias e Várias ideias de como tentar derrubar os coleguinhas.


Então, apesar que sabermos que qualquer um pode construir uma lista assim.
Estou preferindo segurar um pouco, ajudar a galera e o time do NIC a
encontrar uma solução, e evitar a animosidade dos justiceiros.


Como os colegas que me passaram os arquivos e Sniffing me pediram
discrição, estou me reservando o direito de não divulgar esses arquivos.
Até porque tenho a esperança de repetir essa coleta daqui 2 semanas e ver
um cenário bem diferente. E para isso conto com esses mesmos colegas.


Em 28 de agosto de 2017 09:04, Kurt Kraut <listas at kurtkraut.net> escreveu:

> Aloha Douglas,
>
>
> Com as mesmas ferramentas que você usou para fazer um relatório de
> fabricantes, você não conseguiria fazer um ranking dos "noisy neighbours"?
> Um ranking dos MAC ADDRESSESS que mais mandam ARP e com as seguintes
> colunas na planilha:
>
> a) Número de ARPs durante o período estuado (o que justifica a posição no
> ranking
> b) MAC ADDRESS
> b) IP de BGP Peer no ATM do PTT
> c) ASN deste participante do ATM (pelas rotas anunciadas por ele dá para
> descobrir pelo ASPATH ou pela página do peeringdb)
>
> Assim podemos como comunidade (e o pessoal de operações/suporte do IX)
> acionar esses participantes ruidosos para que certifiquemos que façam os
> devidos ajustes em seus roteadores.
>
>
> Abraços,
>
>
> Kurt Kraut
>
> Em 25 de agosto de 2017 13:26, Douglas Fischer <fischerdouglas at gmail.com>
> escreveu:
>
> > Retomando um pouco o tema dos ARP Excessivos no IX-SPO
> >
> > Com a ajuda de alguns amigos fizemos uns sniffings no IX-SP e tabulamos
> um
> > pouco os dados...
> > Segue link de uma análise dos Pacotes de ARP-Request em relação aos
> > fabricantes de cada caxa.
> >
> > https://drive.google.com/file/d/0B2ezlM5MIr8PbE9LbE1TRmRuaUU/view
> >
> > Essa análise levou em consideração o EUI do MAC address, logo macs
> > clonados, ou X86 não estão representando bem seus fabricantes...
> >
> > Para quem se interessar, tenho mais alguns dados que também posso
> > disponibilizar.
> > Favor me procurar privadamente.
> >
> >
> >
> >
> >
> > Em 10 de agosto de 2017 00:01, Shine <eshine at gmail.com> escreveu:
> >
> > > Sobre o EVPN, o link que o Rubens mandou é bem ilustrativo.
> > > O que se discute no controle de broadcast de ARP é a capacidade do EVPN
> > de
> > > propagar o binding de IP/MAC, eliminando a necessidade de propagar o
> ARP,
> > > pois ele seria respondido por um elemento local ao invés de ir para a
> > rede.
> > > Mas eu tenho dúvidas em relação ao design para uso em uma aplicação de
> > IX.
> > >
> > > Colocadas as devidas proporções, as questões do IX são complexas, com
> uma
> > > variedade considerável de participantes. Do meu ponto de vista manter
> > essa
> > > flexibilidade sem sacrificar a simplicidade e robustez e
> > complementarmente
> > > ter um bom controle operacional é um grande desafio.
> > >
> > > Em 9 de agosto de 2017 15:15, Douglas Fischer <
> fischerdouglas at gmail.com>
> > > escreveu:
> > >
> > > > Não sou conhecedor dos conceitos e protocolos de EVPN.
> > > > Mas estou começando a estudar.
> > > >
> > > > Alguma recomendação de material alternativo ao da Cisco que seja um
> > pouco
> > > > mais pedagógico que a própria RFC?
> > > >
> > > >
> > > > Toda a Malha do IX-SP é baseada em EVPN?
> > > > Inclusive os CIX?
> > > > É possível revelar os fabricantes envolvidos?
> > > >
> > > >
> > > > Em 9 de agosto de 2017 14:55, Rubens Kuhl <rubensk at gmail.com>
> > escreveu:
> > > >
> > > > > 2017-08-09 14:50 GMT-03:00 Douglas Fischer <
> fischerdouglas at gmail.com
> > >:
> > > > >
> > > > > > Há também que se lembrar da questão do ponto único de falha do
> > > > > > ARP-Responder.
> > > > > > É imprescindível que haja alta disponibilidade nesse recurso.
> > > > > > (Falhas físicas ou lógicas desse serviço, Isolamento de PIX,
> > etc...)
> > > > > >
> > > > >
> > > > > No caso de EVPN, o ARP-Responder é o PE. E se você não tem acesso
> ao
> > > PE,
> > > > já
> > > > > era de qualquer forma.
> > > > >
> > > > >
> > > > > >
> > > > > > "Quantos?" e "Aonde" são outras duas perguntas muito boas também.
> > > > > > A meu ver, ladeando cada um dos RouteServers é uma boa resposta.
> > > > > >
> > > > > >
> > > > > Eu acho que não, e que deveria ser um por PIX, até para garantir
> que
> > o
> > > > > tráfego broadcast morra naquele PIX sem ir para a matriz.
> > > > >
> > > > > Será que já existem protocolos desenvolvidos para H.A. desse tipo
> de
> > > > > > serviço?
> > > > > >
> > > > >
> > > > > Me parece que HA aqui basta fazer pass-thru...  é um controle
> > > > quantitativo,
> > > > > e não política de segurança.
> > > > >
> > > > >
> > > > > Rubens
> > > > > --
> > > > > 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
> > > >
> > > --
> > > 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
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



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