[GTER] pc router

Tue Apr 24 15:12:59 -03 2012

Klaus e colegas,

compartilho sua visão de que o modelo de roteamento "caixa preta
única" está mudando com a modularização de componentes e a
disponibilidade de APIs que permitam uma efetiva separação dos planos
de controle e de encaminhamento autenticamente multi-vendor (ex:
OpenFlow).

Se alguem não acredita no modelo, já seja na escalabilidade,
performance o problemas de convergencia e tolherancia a falhas pela
separação dos planos, vale a pena olhar no que a Google apresentou na
semana passada no Open Networking Summit. Ainda não tem os slides
completos das duas apresentações da Google mas um ótimo resumo é o
seguinte: Hoje, 100% do tráfego de produção do backbone entre os data
centers deles é baseado numa arquitetura baseada em Quagga rodando em
servidores externos e "roteadores" OpenFlow, que na verdade são
encaminhadores "burros" com um minimo de plano de controle. Vide mais:

http://www.convergedigest.com/Bandwidth/newnetworksarticle.asp?ID=35604
http://www.networkworld.com/community/blog/google-pwns-networking-part-1

Klaus, obrigado pela menção do RouteFlow! Voce foi mais rapido que eu,
queria fazer a disseminação do projeto (Apache 2.0) para comunidade do
GTER na proxima semana assim tenhamos atualizado o site, materiais e
documentação com a nova versão do desenho.

RouteFlow (https://sites.google.com/site/routeflow/projects)
basicamente vem juntar pilhas de protocolo open-source baseados em
Linux (Quagga, XORP, Bird) rodando em servidores commodity com alto
poder computacional e mantendo o plano de dados line-rate sobre
hardware "commodity" que implemente o padrão OpenFlow.
Nos estamos colaborando atualmente com a Google, NTT, e uma serie de
universidades parceiras (Unicamp, Indiana University, Ufscar, Unirio)
no aprimoramento da solução para tornar ela uma realidade.

Seguem alguns artigos publicados pelo grupo:

"RouteFlow: Roteamento Commodity Sobre Redes Programáveis"
http://dl.dropbox.com/u/15183439/Papers/RouteFlow-RB-RESD-v4_n1_a05.pdf

"Uma plataforma de roteamento como serviço baseada em redes definidas
por software"
http://dl.dropbox.com/u/15183439/Papers/WGRS12-Uma%20plataforma%20de%20roteamento%20como%20servico%20baseada%20em%20redes%20definidas%20por%20software-120501.pdf

"Revisiting IP Routing Control Platforms with OpenFlow-based
Software-Defined Networks"
http://dl.dropbox.com/u/15183439/Papers/WPEIF12%20-%20Revisiting%20IP%20Routing%20Control%20Platforms%20with%20OpenFlow%20based%20SDN%20-%20120501.pdf

 "OpenFlow e redes definidas por software: um novo paradigma de
controle e inovação em redes de pacotes".
http://www.cpqd.com.br/cadernosdetecnologia/Vol7_N1_jul2010_jun2011/pdf/artigo6.pdf

E a seguir mais informações sobre a demo que fizemos na semana passada no ONS:
https://sites.google.com/site/routeflow/updates/happyoneyearoftheopen-sourcerouteflowproject

Klaus, seu comentario é muito válido: "O certo seria modelar o plano
de dados no routing engine consolidado".
Isso é precisamente no que estamos trabalhando na linha de aBGP
(aggregated BGP). Mais detalhes no artigo acima:
"Uma plataforma de roteamento como serviço baseada em redes definidas
por software"
http://dl.dropbox.com/u/15183439/Papers/WGRS12-Uma%20plataforma%20de%20roteamento%20como%20servico%20baseada%20em%20redes%20definidas%20por%20software-120501.pdf

Neste 2012 gostaríamos de ver casos piloto da tecnologia RouteFlow em
provedores e redes corporativas no Brasil.
Um ponto positivo é que o software está disponivel e uma adoção da
tecnologia pode ser tão "simples" quanto a substituição (ou expansão
da rede) de só um roteador legado por um roteador RouteFlow, não é
preciso pensar numa migração da rede como um todo.

Desde já ficamos a disposição para mais discussões, requisitos, e um
desenvolvimento comunitário que possa mudar a realidade atual do setor
em certos ambientes de rede.

Abraços,
Christian

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

Em 24 de abril de 2012 13:46, Henrique de Moraes Holschuh
<henrique.holschuh at ima.sp.gov.br> escreveu:
> On 24-04-2012 12:51, Klaus Schneider wrote:
>>
>> Exatamente, o quagga não encaminha pacotes, serve apenas como route
>> server, que seria a única semelhança com o PTT. O quagga suporta
>> muitas sessões full(nunca usei com mais de 3, mas certamente suporta
>>  mais de 10), coisa que fica um tanto complicado mesmo em um 7206 com
>>  npe-g2. O problema de softrouters é exatamente capacidade de
>> encaminhamento, e não estava discordando e sim concordando =)
>
>
> Daqui a uns poucos anos, o roteador "caixa única" vai ficar obsoleto,
> pelo menos em aplicações com fluxo de pacotes elevado e pouco
> centralizadas:  você vai comprar o plano de controle de alguém (e também
> terá a alternativa FLOSS), mas o plano de dados será distribuído, usando
> switches OpenFlow ou equivalente.  Isso já existe como produto
> comercial, mas ainda está caro.
>
> O ruim disso é o plano de controle ter uma topologia completamente
> diferente do plano de dados.  Tem uns jeitos meio absurdos de resolver
> isso.  O certo seria modelar o plano de dados no routing engine
> consolidado, mas até lá dá para montar uma gambiarra usando uma árvore
> de VMs que espelha a topologia real, e usar alguns recursos mais
> avançados do OpenFlow para espelhar na topologia virtual o que realmente
> está acontecendo no plano de dados.
>
> http://www.openflowhub.org/display/routeflow/RouteFlow+Home
>
> Aliás, essa do plano de controle não seguir o caminho do plano de dados
> pode acontecer quando você usa refletores ou servidores de rotas.
> Cuidado nesses casos, porque o iBGP não vai refletir a realidade dos
> enlaces, e portanto o *IGP* e a topologia tem que garantir que nunca vai
> haver particionamento no plano de dados que não seja detectável no plano
> de controle (e vice-versa!).  Daí a recomendação de colocar os
> refletores em caixas de meio de caminho, seguindo a topologia.
>
> Sinceramente, eu preferia que parassem de colocar CPU furreca nos
> roteadores com portas Gigabit e encaminhamento por hardware.  Ninguém
> vai reclamar que uma caixa ficou 1% a 5% mais cara porque no lugar de um
> ARM ou MIPS com quase nada de memória, foi colocado um Mobile Processor
> x86-64 com 8GiB de DDR3 ECC.
>
> --
> Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
> IM@ - Informática de Municípios Associados
> Engenharia de Telecomunicações
> TEL +55-19-3755-6555/CEL +55-19-9293-9464
>
> Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
> e do custo que você pode evitar.
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter