[GTER] pc router

Thu May 3 15:44:37 -03 2012

Olá Christian boa Tarde,

Em 29 de abril de 2012 16:21, Christian Esteve Rothenberg <
esteve at cpqd.com.br> escreveu:

> Olá Lista,
>
> > Gostei do conceito apresentado, em si ele vai funcionar como um
> > router-server porém nas nuvens, pelo que entendi no conceito.
> > Onde o RF-Server fará todo o gerenciamento das VM's, para manter uma alta
> > disponibilidade. Sabendo disso e sendo certo, as VM's mandará as
> > informações para os ativos via OpenFlow via API, até tudo blz.
> > A minha pergunta é, todas as seções BGP será fechada com os RF-Server,
> isso
> > inclue as seções com os Upstream?
> Sim, todas são fechadas no(s) proceso(s) BGP rodando no(s)
> containers/VM(s) conforme determinado pelo RF-Server. Os pacotes de
> estabelecimento da sessão TCP do BGP entram pelas interface virtual
> conforme o mapeamento da porta fisica do switch OpenFlow pela que
> entro o pacote no plano de dados.
>
>
Certo

> Sabendo que a comunicação será via api do
> > OF, o ativo precisará instalar toda a tabela na FIB, qdo recebe das VM's,
> > ou cada vez que se passa um pacote ela consulta os rf e assim ele faz a
> > função de encaminhar após essa consulta?(desculpe mas não entendi muito
> bem
> > essa parte)
> Se voce nao entendeu é nossa culpa :)
> Idealmente toda a FIB é carregada no elemento OF para que todo o
> encaminhamento do tráfego aconteça em hardware.
> 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?

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

> Espero tenha ajudad. Por favor nao deixe de perguntar a vontade, e se
> precisar ajuda com o setup experimental é só falar.
>
> Ok, irei lhe perguntar bastante. :)

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