[GTER] Communities no IX.br

[Rafael Ganascim]

Em 27 de outubro de 2016 19:23, Rubens Kuhl <rubensk at gmail.com> escreveu:

> 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).
>
>

No ARP não respondido de fato as requisições seguem um caminho não ideal
dentro dos roteadores (mesmo os grandes). Acho que não responder ARP
impacta a todos de forma bem negativa.



> 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.
>
>
Isto envolve reconfiguração por parte dos participantes do IX, e um grande
esforço para achar o next-hop adequado e comum.



> 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.
>
>
>
O blackhole irá proteger quem está sendo atacado e quer se proteger dos
miseráveis anti-BCPs que tb participam do IX. Pq os dados não vão chegar
até ele.
Agora se algum dos participantes estiver sendo usado para ataque, é melhor
mesmo que o link dele fique topado até o IX e ele vá tentar descobrir a
anormalidade.

De verdade não sei o peso computacional para o bloqueio no L2, mas ele, na
visão limitada que tenho de participante, parece tornar as coisas mais
simples.
A rota de blackhole vem do BGP, e o next-hop é algo válido no lado do
participante (e drop no lado do IX).