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

Kurt Kraut listas at kurtkraut.net
Mon Aug 28 09:04:46 -03 2017


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
>



More information about the gter mailing list