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

Mon Aug 28 10:17:51 -03 2017

Atendendo a solicitação, adicionei a coluna com o % relativo do número de
IPs no IX-SPO.
O link continua o mesmo...
https://drive.google.com/file/d/0B2ezlM5MIr8PbE9LbE1TRmRuaUU/view

P.S.: Estou em contato com diversos colegas através de Hangouts, Facebook,
WhatsApp, Telegram, etc...
      Fiquei MUITO FELIZ em ver que exitem vários colegas que com algumas
breves linhas declarando o problema e sugerindo solução se propuseram a
aplicar a solução, inclusive reportando inexistência de falhas...

Vou adicionar algumas conclusões e questionamentos que pude levantar a
partir da análise dos dados completos:

1- Não exite diferença de broadcast de arp-request entre nenhum do PIX.
   O que me leva a concluir que até o momento não exite nenhum recurso do
estilo arp-filtering / arp-responder ou EVPN aplicado.
   Essas técnicas podem amenizar em muito o problema

2- O uso de Rate-Limit de PPS de ARP packet só piora o problema geral.
   Essa técnica, por experiencia própria(depois de recomendações de
colegas) realmente baixa muito o consumo de CPU das caixas.
   Porém, como a filtragem não diferencia pacotes que são para o próprio
roteador e pacotes que são para outros participantes, ela dropa pacotes
válidos. O que resulta em REPETIÇÕES DE REQUESTS, e mas ruido na rede.

3- Existem participantes que estão emitindo arp-requests fora da faixa de
rede do IX-SP.
   São basicamente dois tipos de perguntas fora da faixa:
   A- Perguntando(em grande volume) endereços de redes internas (válidas e
inválidas) de participantes
      - IP secundário na Vlan do ATM para fechar bilateral?
      - Interface compartilhada?
   B- Perguntando endereços diversos da Internet
      - Rota default apontado não para IP, mas para a vlan?
Segue lista dos emissores de requisição fora da faixa
https://drive.google.com/open?id=0B2ezlM5MIr8PX3hJajBxQXRTSTg

4- Possibilidade de parte das causas problema estar nos destinos.
   Ainda estou tentando encontrar uma correlação... Mas me causou
estranheza a disparidade entre a proporção de número de participantes
usando  por exemplo Huawei 2,8% e o volume de requests procurando Huawei
10,14%.
   Isso vale para outros fabricantes, mas esse é o que está mais gritante...
   Talvez o caminho para achar algumas das causas do problema esteja aí.

5- Sim! Os Mikrotik fazem parte do problema, mas não são TODA a causa do
problema...
   Ao meu ver a origem do problem no caso Router-OS é do ARP-Timeout
default definida em 30 segundos...
   Isso é muito útil para ambientes de Hot-Spot por exemplo... Mas não para
uma aplicação de roteador de borda BGP.
   aplicar "/ip settings set arp-timeout=4h" resolve isso, e pode ser
aplicado em produção sem impactos.

6- No top 30 "perguntadores" interessantemente não são maioria Routerboard,
mas sim Cisco, Junniper, e NIC-Vendors(?x86?).
   Sendo que o TOP-TOP está emitindo 1,5% do total de ARP-Requests usa Dell.

Por enquanto o que tenho perguntas e boa vontade...
Aberto a sugestões de novas análises.

Em 25 de agosto de 2017 20:29, Rubens Kuhl <rubensk at gmail.com> escreveu:

> Seria legal uma coluna com a proporção daquela família de EUIs no IX... se
> a quantidade de membros é maior, o maior número de requests é esperado.
>
>
> Rubens
>
>
> 2017-08-25 13:26 GMT-03:00 Douglas Fischer <fischerdouglas at gmail.com>:
>
> > 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
> > --
> > 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