[GTER] Communities no IX.br

[Rubens Kuhl]

2016-10-27 19:08 GMT-02:00 Antonio M. Moreiras <moreiras at nic.br>:

> Em 27/10/16 17:30, Rubens Kuhl escreveu:
>
> >> O problema é que isto geraria uma inundação de ARP Request para todo
> mundo.
> >>
> > Você está assumindo que o ARP não esteja sendo controlado de outra
> forma...
> > ;-)
> > Hoje o IX tem toda a informação necessária para manter ARP funcionando na
> > matrix do IX sem nunca sequer os membros chegarem a receber requisições
> > ARP... um ambiente L2 sob controle rígido permite soluções diferentes da
> > operação usual de uma rede Ethernet.
>
> O Rubens tem razão quanto aos ARP requests. Dá pra tratar isso. Por
> exemplo, poderíamos bloquear os ARPs no core do IX, e criar um
> 'respondedor' de ARPs em cada PIX, que conhece e responde por todos os
> MACs dos participantes.
>

Ou mesmo fazer protocol-based VLAN e o ARP se tornar uma rede distinta, ou
encapsular todo ARP em um VC VPLS, ou n maneiras de se fazer com Neston...


>
> O que eu não tenho certeza é sobre o comportamento dos switches caso o
> MAC não seja resolvido na rede. Ele dropa o frame? Ou ele envia o frame
> para todas as portas? Todos os switches se comportariam do mesmo jeito?
> Se os switches resolverem usar flood pra tratar o frame com MAC não
> resolvido isso pode ser um desastre.
>
>
Ainda estamos na camada 3; não tem como fazer flood, pq vc não sabe para
quem encapsular o pacote. O que já vi de comportamentos não tão agradáveis
para esse cenário foi fazer punt para a CPU de todos esses pacotes... mas
eles não tem como ser transformados em frames, pois não tem para quem
entregar. O comportamento usual de arquiteturas de alta performance para
esse caso é dar drop enquanto não se completa a adjacência, a questão só é
de se o drop acontece no fast-path (ASIC ou interrupção) ou no slow-path
(CPU ou processo).

Detalhe que isso tem uma solução simples é que quem tiver qualquer
restrição com isso transformar a rota para o IP de drop numa discard route
(RouterOS), colocar um rota mais específica para esse IP apontando para
nul0 (IOS), ou diversos outros jeitos. O que eu gosto nesse modelo é que
ele já funciona de primeira sem configuração em 1 mil participantes... e
quem não gostar da implementação default, pode substituir pela que mais lhe
agrade de acordo com sua arquitetura de equipamento.

Outro detalhe é que muitos participantes do IX pagam transporte até ele,
então o descarte no IX não resolve o fato de que o canal dele pode lotar no
sentido de uplink e ele ser degradado por um ataque volumétrico.


Rubens