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

Fri Aug 25 20:40:11 -03 2017

No teste de adesão já deveria poder haver um teste para o arp. Sei lá,
mudar o arp da placa e se caso depois da mudança ficasse alcancável dentro
de X tempo, o cara já ficaria bloqueado.

Em 25 de agosto de 2017 20:22, Bruno Cabral <bruno at openline.com.br>
escreveu:

> Desligar os discoveries de neighbor que vem por padrao também é outro item
> que merece atenção
>
> !3runo Cabral
> ________________________________
> De: gter <gter-bounces at eng.registro.br> em nome de Douglas Fischer <
> fischerdouglas at gmail.com>
> Enviado: sexta-feira, 25 de agosto de 2017 19:08:51
> Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> Assunto: Re: [GTER] IX Broadcast - Sugestão - Broadcast Clearing vs ARP
> Sponge
>
> 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>