[GTER] Roteador de Borda
Douglas Fischer
fischerdouglas at gmail.com
Wed Jun 20 16:55:24 -03 2018
Então...
Entre esses mundos ideais:
- mundo ideal ultra-flex
(Switch com Openflow, Engines avançadíssimas de roteamento, Orquestração
etc)
- mundo ideal brand-based
(Single-Brand para assegurar interoperabilidade, Caixas dedicadas a cada
função da rede, etc...)
Existe um um range significativo a ser explorado...
Como de costume vou contar um causo para me ajudar a explicar o que estou
falando.
Não escondo de ninguém que não sou fã de Mikrotik.
Mas há uns tempos atrás uma queima de um equipamento de um cliente me fez
colocar para rodar um cenário que achei que iria ficar um lixo e não
ficou...
CCR 1036 na borda fazia BGP.
Dell R710 com ESXi -> Um CHR para PPPoE(B-RAS), 4 Ubuntu com
Bind(autoritativo e recursivo), Sistema de gestão, etc...
Queimou a CCR?
RB1100 que tinha disponível não ia dar conta.
Comprou online licença de CHR, colocou para rodar a VM, configurei o modo
baunilha e subiu e ficamos esperando as reclamações.
Passou duas semanas e pouco ou quase nada incomodou.
P.S.: Como estava usando VMXNET3, a demanda de performance para
encaminhar entre Border e B-RAS era caiu muito. E latência quase nula.
Resumo? Queimei minha língua.
Bem naquela época o Uesley e o pessoal da N.E. falaram bastante do curso de
provedor virtual.
Ouvi vários relatos interessantíssimos, inclusive um bem legal do Patrick
na Hoki com direito a FailOver de multiplos níveis e o escambau de bico.
Tô falando que é para sair instalando CHR alopradamente?
NÃO! PELO AMOR DE DEUS NÃO!
Mas ficou claro para mim que esse caminho e virtualização dos serviços era
bem acertado para esse nicho de ISPs ultra-pequenos, pequenos, e até médios.
Oque vai rodar de BGP? Oque vai rodar de B-RAS?
-> Escolha individual!
Mas comprando uma lata razoável, pode desgostar de uma e ir para outra com
certa facilidade.
E para finalizar, estando nesse mundo virtualizado e ainda não
OpenFlow/OpenStack/OpenCompute/OpenTudoIsso, para começar a colocar o
pézinho num ambiente assim fica BEM FÁCIL... Agora se tiver tudo em
lata-fixa, aí é bem mais complicado.
Em qua, 20 de jun de 2018 às 15:20, Rogerio Mariano <rsouza.rjo at gmail.com>
escreveu:
> O Linux sim, funcionalidades e daemon para routing e customizar isso em um
> control-plane de escala e confiança é outra historia em detrimento a um
> router de borda que é o escopo da thread, pois embora exista um bom
> histórico desde o GNU Zebra, passando pelo Quagga e chegando ao GoBGP, não
> é tão trivial assim, basta perguntar ao time que desenvolve o FRR.
>
> https://frrouting.org/
>
> Então sim, é preciso desenvolver para usar, mesmo com integradores e
> consultores.
>
> Saudações,
>
> RMS
>
> Em 20 de junho de 2018 07:11, Bruno Cabral <bruno at openline.com.br>
> escreveu:
>
> > O Linux foi criado por um estudante universitario e hoje esta em bilhoes
> > de dispositivos pelo mundo.
> >
> >
> > Não é preciso desenvolver para usar. Para isso existem integradores,
> > consultores...
> >
> >
> > !3runo
> >
> > ________________________________
> > De: gter <gter-bounces at eng.registro.br> em nome de Rogerio Mariano <
> > rsouza.rjo at gmail.com>
> > Enviado: terça-feira, 19 de junho de 2018 20:19:19
> > Para: Alexandre J. Correa; Grupo de Trabalho de Engenharia e Operacao de
> > Redes
> > Assunto: Re: [GTER] Roteador de Borda
> >
> > Na verdade tudo depende da sua necessidade.
> >
> >
> > E sim, portas de switch são baratas ... porta de router são caras...
> pois
> > existem funções distintas como as inúmeras limitações de QoS na porta de
> > switch (por exemplo), se precisar de coisas mais sofisticadas como
> PIM-SSM,
> > TTZ, SyncE, TE-RDM ou TE-MAM também tende a ficar na mão….
> >
> >
> > O mais importante e talvez ponto a se considerar é a questão de ter
> alguns
> > serviços que uma porta de switch não pode prover em detrimento a porta de
> > um router, mesmos com switches mais modernos com seja para Campus ou para
> > Datacenter (Fabrics, por exemplo)..
> >
> >
> >
> > Sobre os pontos colocados pelo amigo Douglas Fisher e o amigo que
> comentou
> > de OpenSDN, dando minha opinião pessoal que trabalha com Massively-Scale,
> > eu não acredito que os pequenos e médios ISPs ou empresas realmente
> abracem
> > a idéia de construir seus próprios switches, ODMs com merchant silicon e
> > “White-Server” executando distros personalizados do Linux e processos de
> > roteamento personalizados. Porque para uma empresa tradicional ou para um
> > pequeno e médio ISP o tempo é muito importante. Tempo para se concentrar
> no
> > negócio. Tempo para se concentrar em apoiar a forma de como o dinheiro é
> > feito. Tempo para fazer mais. Da mesma forma, eu vejo que empresas e
> > Web-Scale como o Facebook, Google, Microsoft ou AT&T (uma Carrier que
> esta
> > nessa vibe) continuem empurrando o envelope de desenvolvimento e criando
> > novas soluções em merchant silicon. Porque essas empresas têm tempo para
> > gastar, tempo para jogar fora e desperdiçar , tempo para testar e tempo
> > para construir. E usam essas habilidades para ganhar dinheiro. Mas
> confesso
> > que em 3 anos eu concluo e digo não vejo um mundo onde esses dois lugares
> > se encontrem. Como a contenção de recursos é diferente entre esses dois
> > grupos, causa resultados diferentes... E é improvável que o valor desses
> > recursos mude. Não é tanto uma questão de tempo, mas uma questão de
> escala.
> >
> >
> > Então…para que as soluções de white-server façam valer o esforço para uma
> > organização, é necessário que haja escala e consistência. Na maior parte,
> > trata-se de economizar custos. No caso de uma web-scale ou similar, se
> seus
> > negócios são sobre a escala de computação, o Google, Facebook, Microsoft
> já
> > criarão seus próprios servidores, então por que não estender isso e
> > construir mais servidores e também os switches/roteadores para se
> adequarem
> > ao seu próprio modelo de gerenciamento/orquestração ? Então é o que
> fazem,
> > é uma consideração real para os seus hyperscale datacenter ou Hyperscale
> > Edge. Isso realmente não faz sentido fora desse contexto em que as peças
> > básicas não se adequam ao cenário; onde você não tem a escala ou a
> > consistência. O "joule" disso sera a evolução de empresas como a Cumulus,
> > PICA8 e Big Switch e aí talvez tenhamos ideia se o white-server e o
> > merchant silicon ganham um maior espaço ou não, alem dos muros das
> > Web-Scales ou de Campus Universitários…
> >
> >
> > Saudações.
> >
> >
> > RMS
> >
> > Em 19 de junho de 2018 12:53, Alexandre J. Correa <alexandre at onda.net.br
> >
> > escreveu:
> >
> > >
> > > Trabalhamos assim ...!portas de switch são baratas ... porta de router
> > são
> > > caras ...
> > >
> > >
> > >
> > >
> > >
> > > Enviado de myMail para iOS
> > >
> > >
> > > terça-feira, 19 de junho de 2018 11:29 -0300 de
> fischerdouglas at gmail.com
> > > <fischerdouglas at gmail.com>:
> > > >Eu tenho gostado cada vez mais da ideia de dois switchs L2
> > > >semi-burros/baratos/homologados recebendo todas as
> > > >interconexões(Links/Routers/B-RAS/App-Servers) e 2 ou 3 servidores em
> > > >cluster fazendo todo o resto do trabalho.
> > > >
> > > >Vamos brincar de advinhar valores?
> > > >2 X Switch Bão e Barato (com direito a algumas portas 10G e 40G) ->
> +/-
> > > >R$9-10K
> > > >2 X Servers Bão e Barato (contemplando roteamento e app-servers) ->
> +/-
> > > >R$12-13K
> > > >4 X NICs Dual l0Gb -> +/- R$1.5K
> > > >4 X QSPF+ -> +/- R$1.5K
> > > >
> > > >Lógico que é só uma brincadeira...
> > > >Mas nesse desenho, ter-se-á EXCELENTE nível de redundância(podendo ser
> > na
> > > >camada de roteamento e também da virtualização).
> > > >E eu chutaria que um cenário assim atenderia fácil um ISP com 15K
> > clientes
> > > >e um tanto de clientes corporativos.
> > > >
> > > >
> > > >Ficou pequeno? Põe mais um do lado.
> > > >Ficou obsoleto? Troca a lata e faz Live Migration para o hardware
> novo.
> > > >
> > > >
> > > >
> > > >Se juntar nessa receita ingredientes com OpenComputeProject(Servers e
> > > >Networking), Openstack, Openflow...
> > > >A brincadeira pode ficar "bem lôca".
> > > >Tem uns tal de Facebook, Microsoft, Google, e outros mais que estão
> bem
> > > >ativos nessa brincadeira...
> > > >
> > > >
> > > >
> > > >Em 15 de junho de 2018 16:00, Rafael Velloso < rafael at pox.com.br >
> > > escreveu:
> > > >
> > > >> Boa tarde a todos, estamos precisando trocar nosso roteador de
> borda,
> > > >> atualmente utilizamos os Server U L800 FreeBSD, porém não tem
> > > homologação
> > > >> da
> > > >> Anatel.
> > > >> Hoje temos 4 full routing, 10gb link, quais informações poderiam me
> > > >> fornecer
> > > >> a respeito do Juniper mx80 e do Huawei NE20e, o que seria mais
> > > >> interessante?
> > > >> Os dois são homologados? Custo x benefício? Desempenho? Licenças? Ou
> > > alguém
> > > >> pode indicar uma outra opção ao mesmo nível?
> > > >>
> > > >> Agradeço desde já!
> > > >>
> > > >> Att.
> > > >>
> > > >> Rafael Velloso
> > > >> Pox Network
> > > >>
> > > >> Att.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> 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
> >
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
--
Douglas Fernando Fischer
Engº de Controle e Automação
More information about the gter
mailing list