[GTER] Construindo um EBGP com NetFPGA

[Rubens Kuhl]

> Ainda não se sabe. Mas creio que nos futuros modelos, com mais memória, será
> possível rodar IPv6 que
> pelo passo de tartaruga, ainda deve levar uns 2 anos pra chegar no Brasil.

Ao contrário de informação insistentemente repetida por uma certa
associação, o IPv6 já está no Brasil. E o IPv4 já já vai acabar no
Brasil... não dá para começar um desenvolvimento em 2011 sem IPv6.

> Dá tempo de ter uma versão
> nova por aí que segundo eles, será lançada agora no último quadrimestre
> desse ano.

De hardware não vai mudar, e o gateware deles está bem lento em
lançamentos. Eu havia entendido que a idéia era justamente pegar o que
já tem de gateware pronto e começar agora... esperar joga qualquer
projeto para 2013.

>> Os 288M são de memória mais lenta, que pode ser usada para buffer de
>> pacotes.
>> Os 27M de SRAM é que tem performance suficiente para look-up.
>>
>
> Mais lenta que a SRAM, mas não lenta em linhas gerais.
> Pelas especificações (
> http://download.micron.com/pdf/datasheets/rldram/MT49H16M36A.pdf), é uma DDR
> de 533 MHz.
> Existem diversas plataformas que usam memórias muito mais lentas que essa
> pra tarefas até mais exigentes.

Não roteadores com hardware-forwarding. Você mencionou 20 Gbps de
capacidade tráfego, isso dá 30 Mpps, ou seja, um pacote a cada 33 ns.
Forwarding dessa capacidade requer multi-banking de SRAM para
funcionar, qualquer DRAM não vai conseguir responder a tempo.

> E look-up é algo não só para roteamento como também para ACLs, e
>> punt-to-CPU para ACL é pedir para cair no primeiro DDoS.
>>
>
> Pode-se usar a RLRAM pra ACL look-up depois do pacote em buffer e só
> consultar a FIB depois de tudo.

Seus 33 ns acabaram muito antes disso...

> Mas ainda acho que uma DDR 533 é suficientemente rápida pra isso.
> Vamos aos testes. :-)

Mesmo conceitualmente isso já não está decolando...

> Bloom filter é um algoritmo consolidado e relativamente fácil de
> implementar. Seria uma escolha natural.

Os problemas de performance de atualização da tabela conforme
alterações vem do plano de controle são tão determinantes na escolha
desses algoritmos quanto o look-up. Consolidado e fácil não resolvem
um pacote a cada 33 ns.



Rubens