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

[Douglas Fischer]

​Extra da mesma questão sobre métrica dos barulhentos:

Um segundo nível de contabilização:

 - Limitar em 3 pps.
 - Integralizar a cada minuto.
 - Liberar 3 excessos a cada 15 minutos.
 - Manter os registros de cada vez que o participante exceder os PPS de ARP.

Dessa forama:
- Rajadas legítimas serão toleradas.
- PPS alto continuamente serão penalizados
- Rajadas recorrentes serão registradas para análise futura.

​

Em 31 de agosto de 2017 14:21, Douglas Fischer <fischerdouglas at gmail.com>
escreveu:

> ​Questões levantadas por um colega sobre a ​elaboração da métrica dos
> barulhentos:
>
> Fatos como:
> - um flap no link
> - a execução de um "clear arp"
> - varredura realizada por um bot dentro de uma de suas redes
>
> Provocariam fortes rajadas legítimas de arp-request por um participante
> específico.
>
>
>
> Para contornar isso, acredito que o aumentando o tempo de integralização
> para algo como 5 minutos, e o máximo de 15 arp-requests por segundo, seja o
> suficiente.
>
> Num limite de 15 PPS, em 5 minutos, 60 segundos... -> 4500 pacotes.
>
> Um exemplo de rajada válida
> ---------------------------
> Digamos que e tenhamos 2000 IPs na rede do ATM.
> E alguém tenha feito um "clear arp-cache" e tenha que reconstruir sua
> tabela ARP.
> Presumindo que seja um participante MUITO ATIVO e que fale com todos os
> outros participantes.
> Ele iria fazer 2000 solicitações em poucos segundos.
> Presumindo que todos(extrapolando) esses requests falhem uma vez, seriam
> 4000 requests.
>
> Ou seja, ainda assim esse participante não tomaria um pênalti numa
> ocorrência como essa.
>
>
> Um exemplo de volume ofensivo de arp-requests
> ---------------------------------------------
>
> Um participante que fale somente com 500 dos atuais 1390 IPs do ATM.
> Que esteja com seu arp-timeout configurado para 30 segundos
> 500 destinos, 5 minutos, 2 pacotes por minuto -> 5000 request
>
> Nesse caso o participante tomaria um penalti(que ainda precisa ser
> definido).
>
> Depois de o tráfego dele cair e voltar por umas 10 vezes consecutivas,
> tenho certeza que ele vai verificar "oque estou fazendo de errado".
>
>
>
>
> Isso foi só um esboço.
> Mas acho que é uma boa referência de começo.
>
>
> Em 31 de agosto de 2017 14:01, Douglas Fischer <fischerdouglas at gmail.com>
> escreveu:
>
>> ​Opções que​ me passaram pela cabeça:
>>
>> Sem fazer uso de SDN:
>> Esse arp sponge, que teria uma porta com exeções e suas configurações,
>> soltaria uma rajada de uns 3 minutos de ARP Gratuito com um source-mac
>> fake(black hole) com o IP desse participante.
>>
>> Fazendo uso de SDN:
>> Mudar esse cara da Vlan oficial do ATM para a Vlan de Quarentena do ATM.
>>
>>
>> A ideia de derrubar os anúncios do cara não é ruim.
>> Mas o cara passaria ileso nas bilaterais.
>>
>>
>> Em 31 de agosto de 2017 13:55, Rubens Kuhl <rubensk at gmail.com> escreveu:
>>
>>> 2017-08-31 13:42 GMT-03:00 Douglas Fischer <fischerdouglas at gmail.com>:
>>>
>>> > Na verdade me referia a uma parte dos recursos da atual implementação
>>> do
>>> > arp sponge.
>>> > https://ams-ix.net/downloads/arpsponge/
>>> >
>>> > Só a contabilização... O gatilho.
>>> >
>>> > As ações, ainda devem ser melhor exploradas.
>>> > Mas gosto da ideia da palmatória(Freireanos que não me escutem).
>>> >
>>> >
>>> Em termos de ação concreta, uma possibilidade seria a remoção temporária
>>> de
>>> anúncios do ATM. A ação do sponge como implementada lá serviria a um
>>> outro
>>> caso, que é de participante que perdeu conectividade com o IX (ex:
>>> transporte caiu).
>>>
>>>
>>> Rubens
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>
>>
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>>
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>



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