[GTER] Indicação de roteador bgp e empresa de fornecimento de link em Natal/RN

[Lucenildo Lins Aquino Júnior]

Caros,

Concordo com Willian, acho que tem ficar claro a diferença de control
plane e data plane. Obviamente qualquer um dos RSs tais como: BIRD,
Quagga e até mesmo GoBGP são mais rápidos para receber, concatenar,
executar o best path e propagar a tabela. Todavia a performance para
forward é bem menor que um ativo de propósito especifico.

Para quem quiser experimentar soluções que usam ativos apartados para
Control Plane e Data Plane, recomendo dar uma olhada em:
https://www.dropbox.com/s/40n4j9kp3w1eecg/Tutorial%20SDN%20%26%20NFV%20LACNIC26.pdf?dl=0

http://www.lacnic.net/web/eventos/lacnic26-agenda-tutoriales#02

No último LACNIC/LACNOG - José Miguel Guzmán (Whitestack - Ex. Google)
no slide 54, fez um lab durante o evento mostrando um trafego direto
entre dois AS através de um switch com openflow, o BGP era fechado com
um terceiro AS mas o trafego de dados não passava pelo ativo que
estabelecia o BGP.

Grato,


Em 15/02/17 01:27, willian pires escreveu:
> Uma coisa que eu concordo plenamente é com a capacidade de router-server serem rápidos ou melhores que sistema muito monolíticos como são os bgp de IOS com cisco huawei e hpe por exemplo eles dão um banho em velocidade de processamento de tabela agora forward de pacote é outra coisa.
>
> Get Outlook for Android<https://aka.ms/ghei36>
>
>
> ________________________________
> From: gter <gter-bounces at eng.registro.br> on behalf of João Butzke <lista-gter at tbonet.net.br>
> Sent: Wednesday, February 15, 2017 12:23:31 AM
> To: gter at eng.registro.br
> Subject: Re: [GTER] Indicação de roteador bgp e empresa de fornecimento de link em Natal/RN
>
> Se você souber falar japones, sim.
>
>
> Em 14/02/2017 18:32, Fabrício Cabral escreveu:
>> Então compensa de jogar fora o OpenBGPD e colocar o GoBGP? Já se tem
>> condições
>> de se fazer isso?
>>
>> At.te.
>>
>> 2017-02-14 17:03 GMT-03:00 Fábio Hernandes <fabio at hernandes.eti.br>:
>>
>>> No último IX Forum o Shu Sugimoto do JPNAP veio falar justamente sobre a
>>> experiência deles com o GoBGP.
>>>
>>> Fiquei quase a apresentação toda acordado.
>>>
>>>
>>> --
>>> Fábio R. Hernandes
>>> Fone: (17) 99643 6715
>>> Skype: hernandes.fabio
>>>
>>> Em 14 de fevereiro de 2017 17:18, Douglas Fischer <
>>> fischerdouglas at gmail.com>
>>> escreveu:
>>>
>>>> OK, OK... ~120 ASNs, 600Gbps
>>>> Estou convencido!
>>>>
>>>> Não precisa vir com grosseria.
>>>> rsrsrs
>>>>
>>>>
>>>> Em 14 de fevereiro de 2017 16:12, Rubens Kuhl <rubensk at gmail.com>
>>>> escreveu:
>>>>
>>>>> 2017-02-14 16:08 GMT-02:00 Douglas Fischer <fischerdouglas at gmail.com>:
>>>>>
>>>>>> Interessante o GoBGP!
>>>>>>
>>>>>> Mas existem ASNs com mais de 20 peering(em todo o AS) e mais de
>>>>>>
>>>>> GoBGP é um dos route-servers do JPNAP... uma das cidades do JPNAP:
>>>>> http://bgp.he.net/exchange/JPNAP%20Tokyo
>>>>>
>>>>>
>>>>>
>>>>>> 20Gbps(números exemplificantes) rodando com GoBGP?
>>>>>>
>>>>> Throughput é questão de kernel e hardware, não de daemon BGP. Mas já
>>> que
>>>> o
>>>>> plano de dados é outro papo, o JPNAP tem 600 Gbps de tráfego... ;-)
>>>>>
>>>>>
>>>>> Rubens
>>>>> --
>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>>
>>>>
>>>> --
>>>> Douglas Fernando Fischer
>>>> Engº de Controle e Automação
>>>> --
>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

-- 
NIC.br | Lucenildo Aquino Júnior
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537R.: 4122
INOC 22548*552
www.nic.br <http://nic.br>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: OpenPGP digital signature
URL: <https://eng.registro.br/pipermail/gter/attachments/20170215/ef2547c8/attachment.sig>