[GTER] pc router

Mon May 14 18:33:18 -03 2012

Olá!

Desculpe o atraso em dar continuidade a esta thread...

>> Porém, pode se pensar tambem no caso tambem de nao ter suficiente
>> espaço nas tabelas OpenFlow para a "full FIB", nesse caso os pacotes
>> poderiam subir no plano de controle até a VM que contem sim a FIB toda
>> e faça a toma de decisão de encaminhamento. Na sequencia e por um
>> tempo determinado de atividade (ex: pacotes batendo nessa entrada)
>> poderia se instalar uma entrada OF para que o trafego seja encminhado
>> em hardware.
>>
> Blz, mas nesse caso em que a memoria do eqpto OF, seja abaixo para uma
> tabela full, fazendo essa consulta nos RF, não tornaria o forward um pouco
> lento, pois ele terá que fazer a consulta no plano acima para depois
> instalar na FIB e ae sim fazer o encaminhamento por hardware, nisso já
> perdemos alguns tempo ou ele tem algum algoritimo modificado para tal
> situação?

Voce está certo. Voce pode pensar nessas casos como um "cache-miss".
O bom é que recentes estudos mostram que existe uma distribuição Zipf
da popularidade dos destinos (i.e. entradas da FIB) o que permitiria
tais casos ser excepções e não a norma para grande parte do tráfego.
Vide:  http://www.fibium.org/papers/2012-ccr-offloading.pdf

>> > Se a maquina vai ser somente para informar os ativos via OF, por qual
>> > caminho o pacote deva ir, qual a necessidade de uma placa NetFPGA?(não
>> > ficou muito claro para mim esse item tbem)
>> Espero que tenha ficado claro com a resposta anterior. No caso NetFPGA
>> == switch OF.
>> Se tudo fosse encaminhado pelas VMs seria um encaminhamento
>> ineficiente e 100$ em software (virtualizado e remoto) :(
>>
> Mas essa placa NetFpga não vai ser somente para comunicar com os OF, ou
> terá tráfego alto atrelado a ela, que justifique a sua utilização, pois
> pelo que vejo placas intel igb ou ixgbe ou até mesmo as giga da broadcom
> tem uma performance boa para tráfego giga e 10 giga(ixgbe), já que o unico
> trafego pelo que entendi é de consultas dos OF, e estabelece a comunicação
> com as VM e seções (e,i)GP.

A placa NetFPGA atúa como switch OpenFlow para encaminhar tráfego em
line rate.

Além de implementar o agente OpenFlow (que recebe as entradas da "FIB"
a ser instaladas e transporta as sessões (e,i)BGP com as VMs), a
NetFPGA atua como hardware switch OpenFlow no plano de dados para
encaminhar o tráfego conforme a tabela da FIB controlada pelo
OpenFlow.

Voce está certo, ao invés de usar uma NetFPGA voce poderia usar outro
elemento para encaminhar tráfego em altas taxas. Podem ser as
alternativas que voce menciona, ou pode ser outros equipamentos como
hardware switches da HP, NEC, Pronto, etc. que falem o protocol
OpenFlow.
Como de costume, vai existir um trade-off entre preço, tamanho das
tabelas, é desempenho no encaminhamento de tráfego.

Para quem chegou até :) seguem duas palestras do pessoal da Google que
usam uma arquitetura semelhar baseada em Quagga (control plane em
servidores) + OpenFlow (data plane). A pena que eles não liberaram os
slides:

SDN Stack for Service Provider Networks - Amin Vahdat, Google
http://www.youtube.com/watch?v=56UASyV65zs

OpenFlow @ Google - Urs Hoelzle, Google
http://www.youtube.com/watch?v=VLHJUfgxEO4

Abraços,
Christian

>>
>> >
>> > Em 26 de abril de 2012 18:11, Rafael Galdino da Cunha <
>> > sup.rafaelgaldino at gmail.com> escreveu:
>> >
>> >> Realmente o que importa é o que vai ta de hardware e como foi
>> configurado.
>> >>
>> >> me lembrei hoje que a uns anos atraz estava eu e o Joacy ANID, tirando
>> umas
>> >> antenas para a Openline "Bruno Cabral", e o rádio e firewall era um pc
>> acho
>> >> que um pc133 com 8mega de ram, duas placas de rede boa, e um disquete
>> com
>> >> um linux. e olhe que não tiramos por cancelamento ou coisa do tipo. era
>> pq
>> >> já faziamos um bom tempo que não usavamos.
>> >>
>> >> voltando ao Foco, tem que ver como configura as maquinas corretamente,
>> seja
>> >> o processador correto, seja as memórias, seja o calculo das vazões da
>> >> memoria se vai ter fsb ou qpi ou outra forma de barramento. ver as
>> pontes
>> >> da placa mãe, etc...
>> >> creio que pode ser feito sim um roteador até da linha 72xx na casa de
>> uns
>> >> XX mil's reais com uma maquina, porém lembrando de fonte, case, etc..
>> para
>> >> acomodar corretamente e esquecer que existe.
>> >>
>> >>
>> >>
>> >> Em 26 de abril de 2012 17:16, Lucas Willian Bocchi
>> >> <lucas.bocchi at gmail.com>escreveu:
>> >>
>> >> > E como que fica o firewall de borda no caso desse tipo de solução?
>> >> >
>> >> >
>> >> > Em 26 de abril de 2012 16:48, Christian Esteve Rothenberg
>> >> > <esteve at cpqd.com.br> escreveu:
>> >> > >>
>> >> > >>
>> >> > >>> control plane em software livre seria um sonho, desde que o
>> resultado
>> >> > >>> (control plane + caixas OpenFlow) consiga ter um uptime bem alto e
>> >> > >>> seja capaz de line-rate sem sacrificar todas as funcionalidades
>> >> > >>> necessárias de segurança da operação...
>> >> > >>>
>> >> > >>
>> >> > >> Bom, parece que dá para conseguir caixa openflow no Brasil :-)
>> >> > >> http://www.hp.com/hpinfo/**newsroom/press/2012/120202a.**html<
>> >> > http://www.hp.com/hpinfo/newsroom/press/2012/120202a.html>
>> >> > >>
>> >> > >>
>> >> > >> No Brasil tem tambem equipamentos comerciais da NetGear.
>> >> > > Da NEC tambem é possivel conseguir.
>> >> > >
>> >> > > É importante lembrar que a tecnologia está ainda madurecendo....
>> >> > > O tamanho das tabelas OpenFlow em equipamentos "legados" é baixo
>> para
>> >> > > aplicações de roteamento.
>> >> > > Outro detalhe importante é saber quais funcionalidades do OpenFlow
>> (ex:
>> >> > > matching, re-escrita de cabeçalhos, contadores) são implementados
>> em SW
>> >> > (na
>> >> > > CPU do switch) ou em hardware (no ASIC / FPGA do switch).
>> >> > > Vide o exemplo os "Hardware Acceleration Limitations" da HP:
>> >> > >
>> >> >
>> >>
>> http://h20000.www2.hp.com/bc/docs/support/SupportManual/c03170243/c03170243.pdf
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Christian Esteve Rothenberg, Ph.D.
>> >> > > Converged Networks Business Unit (DRC) / CPqD
>> >> > > Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087
>> >> > > esteve at cpqd.com.br
>> >> > > www.cpqd.com.br
>> >> > > --
>> >> > > gter list    https://eng.registro.br/mailman/listinfo/gter
>> >> > --
>> >> > gter list    https://eng.registro.br/mailman/listinfo/gter
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Att.
>> >>
>> >> Rafael Galdino
>> >> --
>> >> gter list    https://eng.registro.br/mailman/listinfo/gter
>> >>
>> > --
>> > gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>>
>>
>> --
>> Christian Esteve Rothenberg, Ph.D.
>> Converged Networks Business Unit (DRC) / CPqD
>> Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087
>> esteve at cpqd.com.br
>> www.cpqd.com.br
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

-- 
Christian Esteve Rothenberg, Ph.D.
Converged Networks Business Unit
CPqD - Center for Research and Development in Telecommunications
Tel. (+55 19) 3705 4479 / Cel. (+55 19) 8193-7087