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

Douglas Fischer fischerdouglas at gmail.com
Fri Aug 25 13:26:52 -03 2017


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



More information about the gter mailing list