[GTER] Construindo um EBGP com NetFPGA

[Rubens Kuhl]

>> Em Watts, com certeza SRAM é melhor. Mas a complexidade é transferida
>> para o algoritmo que mastiga a RIB e gera a FIB.
>>
>
> Pois é. Estive conversando com alguns desenvolvedores de aplicações de
> forwarding da NetFPGA sobre a real necessidade de uma TCAM e parece ser um
> consenso que algoritmos tem capacidade de suplantar a necessidade de uma.

É certo que tem a capacidade de, mas requer uma quantidade de
desenvolvimento especializado que eu só vejo em fabricantes ou em
universidades.

> Acho que lookup cache não necessariamente é uma vulnerabilidade. Vai ser
> preciso estudar como tornar o algoritmo mais robusto e evitar esse tipo de
> situação que, aliás, foi o que aconteceu com o Linux nos idos de 2003.

Uma das maneiras é fazer CIDR-cache, ou seja, ao fazer look-up de um
IP fazer cache de todo o espaço de endereçamento no entorno que tenha
o mesmo destino.

Exemplo:
192.168.0.0/16 -> Destino1
192.168.4.0/24 -> Destino2

Pacote para IP 192.168.4.5 -> Cache recebe 192.168.4.0/24 -> Destino2
Pacote para IP 192.168.0.9 -> Cache recebe 192.168.0.0/22 -> Destino1
(notar que não é o 192.168.0.0/16 pois isso cobriria um pedaço onde
isso não vale)

Mas mesmo isso eu ainda acho arriscado.


> Inclusive estão trabalhando pra retirar isso do kernel, embora não saibam
> quando.
>
> Apenas como update: consegui alguns resultados interessantes usando GPUs,
> com a vantagem de se utilizar o framework da pilha IP do kernel do Linux,
> que obviamente seria perdido com o uso de um FPGA.

Talvez GPU seja um caminho para wire-speed multi-gigabit enquanto se
prepara um router FPGA 10G.


Rubens