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

Fri Aug 25 19:08:51 -03 2017

Obrigado pela resposta Lucenildo!

Acho a ideia de documentação de L2 excelente...

Porém é fato que a leitura desses materiais complementares tem dificuldade
de penetração justamente nos participantes que tem menos intimidade com
protocolos...

Logo, quanto mais mastigado e coesas as informações, menor a possibilidade
de o executor de configuração "esquecer" de algum detalhe.

Levando em consideração o quanto de dificuldade essa questão do ARP
excessivo está causando, Reitero a sugestão de colocar o aumento do Arp
timeout ali, juntinho da linha que aumenta o número de quantidade de
registros Arp....

P.S.: Se a linha de corte para localização da configuração é L2 vs L3,
tecnicamente o ARP é justamente a ponte entre as duas camadas. Hahaha.

Em 25 de ago de 2017 6:03 PM, "Lucenildo Lins Aquino Júnior" <
lucenildo at nic.br> escreveu:

Caro Douglas,

O texto que está publicado no site do IX.br é focado nos Router Servers,
ou seja, serviços na camada 3 de rede.

Está no nossos planos fazer uma base de conhecimento publica focada na
parte Layer 2 incluindo a parte do LACP e otimizações para diversos
vendors ou plataformas.

Hoje durante o processo de ativação e/ou migração caso seja necessário
os nossos analistas fornecem informações para solução de problemas
conhecidos e casos omissos de alguns fabricantes.

Temos ainda no nosso site um documento que explica as nossa políticas
técnicas que da um overview geral.

Vide: http://ix.br/doc/PRT_IX.br_V1.0_30_06_2017.pdf

Grato,

Em 25/08/17 17:05, Douglas Fischer escreveu:
> Uma sugestão para a equipe do NIC seria complementar os guias de
> configuração
> http://ix.br/route-server-and-commmunities
>
> Adicionar as linhas que jogam o arp-timeout para 4h
>
> Router-OS
> /ip settings set arp-timeout=4h
>
> E isso em cada um dos fabricantes exemplificados.
>
>
>
> 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
>>
>
>

--
NIC.br | Lucenildo Aquino Júnior
Analista de Projeto
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3557R.: 4122
INOC 22548*552
www.nic.br <http://nic.br>

--
gter list    https://eng.registro.br/mailman/listinfo/gter