[GTER] IX Broadcast - Sugestão - Broadcast Clearing vs ARP Sponge
Cristofer Velloso
cristofervellosol at gmail.com
Sat Aug 26 16:44:09 -03 2017
!3runo,
Isso está nas orientações, e nos testes de quarentena..
Infelizmente pelo que vi nas capturas um numero significativo dos
mikrotik está ativo. 272 numa captura que apareceram 626 routerboards
(fora os mikrotik x86 que aparecem como outros fabricantes)
Tem ubiquiti dando discovery tbm e outros protocolos dando broadcast
udp. O que estava com ospf no ATM parou.
Deveria ser bloqueado o broadcast udp e o multicast como é outros
protocolos, não sei se tem alguma restrição técnica nos pix para isso.
Pois não pode bloquear o mac de broadcast por conta do arp e do icmpv6
ND. E bloquear em L3 o 255.255.255.255 deve ser impraticável.
[]os
Cristofer
Em Sex, 2017-08-25 às 23:22 +0000, Bruno Cabral 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 <f
> ischerdouglas 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 gmai
> > l.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 g
> > > > mail.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@
> > > > > > 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
More information about the gter
mailing list