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

[Douglas Fischer]

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...)

"Quantos?" e "Aonde" são outras duas perguntas muito boas também.
A meu ver, ladeando cada um dos RouteServers é uma boa resposta.


Será que já existem protocolos desenvolvidos para H.A. desse tipo de
serviço?




​

Em 9 de agosto de 2017 11:57, Douglas Fischer <fischerdouglas at gmail.com>
escreveu:

>
>
> Em 8 de agosto de 2017 14:42, Rubens Kuhl <rubensk at gmail.com> escreveu:
>
>> 2017-08-08 10:56 GMT-03:00 Douglas Fischer <fischerdouglas at gmail.com>:
>>
>> >  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.
>> >
>> >
>> O ARP-Responder já é padrão de soluções de EVPN.
>> Já filtragem (mas sem redirect) de muito tráfego Broadcast me parece que
>> já
>> é feito no IX de SP...​
>
>
> Eu fico imaginando que ​esse tipo de filtragem
>  "Deixa passar BCast só para os Arp-Responders, bloqueia para todo o
> resto."
> Não seja tão trivial de se implementar...
>
> Aí vem a pergunta: Como resolver isso?
>
>  - Andei lendo sobre o uso de SDN e ACLs L2 dinamicamente aplicadas
> distribuídas pelas portas dos Swichs L2(Isso me lembra muito um produto do
> portfolio de segurança L2 da Cisco).
> Como o Broadcast vai ser encaminhados a todas as portas(Exceto as que
> tiverem bloqueio) o ARP-Responder vai receber a requisição e responder com
> Unicast.
>
>  - Me passou pela cabeça alguma atuação complementar no ponto em que é
> feita a Vlan Translation
>
>
> E aí?
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>



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