[GTER] Redundância Router

Wed Apr 13 17:33:33 -03 2016

Aloha Henrique,

Já vi mais de uma vez gente demonstrando atingir 80gbit/s com a CCR1072,
como por exemplo, https://www.youtube.com/watch?v=nzcwVapVwQQ

Abraços,

Kurt Kraut

Em 13 de abril de 2016 09:34, Henrique Isoppo - Websul Datacenter <
henrique at websul.com.br> escreveu:

> Não sei o que recomendar no lugar da CCR, mas se a idéia é ter essa parte
> do core em 10G, fuja.
>
> Assim como o throughput do CRS, essa router é só fantasia.
> Duas portas 10G + oito portas 1G, mas possui um backplane de 28G.
>
> Para comparação, um switch TL-SG5412F, da TPLink, com 12 portas SFP
> Gigabit, possui backplane de 24G = 2G por porta (1G in / 1G out)
>
> --
>
> Henrique C. Isoppo
> Gestor - Datacenter - Websul Telecom
> t: (51) 4063-6699 | Ramal 702 - INOC-DBA: 52851*100
> e: henrique at websul.com.br | w: www.websul.net.br
>
>
> -----Original Message-----
> From: gter [mailto:gter-bounces at eng.registro.br] On Behalf Of Ricardo
> Pereira via gter
> Sent: 13 April 2016 08:58 AM
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
> Cc: Ricardo Pereira
> Subject: Re: [GTER] Redundância Router
>
> Estamos em processo de upgrade do core da Rede.
>
> Instalaremos um SW Dell com portas 10G. A CCR atual é o modelo que não
> possui interface SFP+, por isto já havíamos decidido em substituí-la
> pelo modelo CCR1036-8G-2S + EM que tem duas portas SFP+.
> No caso iríamos adquirir duas (uma seria backup), o que vocês
> recomendariam instalar no lugar desta CCR?? Neste caso o valor poderia
> ser o de duas CCR's do modelo citado!!
>
>
> Em 12/04/2016 19:48, João Butzke escreveu:
> > Hoje uma caixa L800 está quase na faixa de uma CCR1036 amigo, que no
> > caso rodaria o freebsd ( me corrijam se estiver errado.. )
> >
> > Em 12/04/2016 14:48, Ricardo Pereira via gter escreveu:
> >> Boa tarde!
> >> Ainda não cogitamos o uso de equipamentos deste porte, mas é algo que
> >> em um futuro poderemos pensar.
> >> Mas obrigado pela sugestão!!
> >>
> >> Em 12/04/2016 11:08, Patrick Tracanelli escreveu:
> >>>> On 11/04/2016, at 17:45, Thiago Gomes <thiagomespb at gmail.com> wrote:
> >>>>
> >>>> pensou em  usar outro roteador... ? cisco, juniper, freebsd ?
> >>>>
> >>>> Em 11 de abril de 2016 16:40, Ricardo Pereira via gter
> >>>> <gter at eng.registro.br> escreveu:
> >>>>> Boa tarde pessoal!
> >>>>> Necessito prover redundância de um Roteador (Uma CCR 1036). Este
> >>>>> Router faz
> >>>>> parte do Core da Rede, e devido a falhas que já ocorreram
> >>>>> (travamentos),
> >>>>> gostaria de prover redundância deste Router em caso de falhas.
> >>>>> Li sobre o VRRP, mas não sei se seria a melhor opção para o meu
> >>>>> cenário.
> >>>>>
> >>>>> Gostaria de sugestões para o cenário abaixo, para que eu possa
> >>>>> analisar  e
> >>>>> estudar qual seria a melhor opção.
> >>>>> Desde já, grato pelas sugestões.
> >>>>>
> >>>>> Diagrama
> >>>>>
> >>>>>
> >>>>> --
> >>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>
> >>>>
> >>>> --
> >>>> Thiago Gomes
> >>>> --
> >>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>
> >>> Não vi o diagrama, não veio imagem, então algumas sugestões blind:
> >>>
> >>> Setup 1) Multi peering com mesmos neighbors
> >>> - WAN multi peered com cada neighbor (router1 + router2 com peering
> >>> individuais com cada neo)
> >>> - router 1 (master) sem prepend
> >>> - router 2 (backup) prepend 2 ou prepend 3
> >>> - VRRP/CARP entre router1+router2 na(s) LAN(s)
> >>> - rede usando IP virtual do VRRP/CARP como gateway
> >>>
> >>> Quando router1 cair router2 vira gateway, ja tem as devidas sessões
> >>> BGP estabelecidas e tabelas convergidas, trafego de saída
> >>> praticamente imediato. Downtime máximo é até o mundo convergir e ver
> >>> que router1 caiu e passar e devolver as respostas pro router2 que ja
> >>> existia mas era prepended.
> >>>
> >>> Setup 2) Routers distintos, peering distintos
> >>> - router 1 faz peering com parte dos neighbors
> >>> - router 2 faz peering com outra parte dos neighbors
> >>> - ibgp entre router1 e router2
> >>> - router1 anuncia parte da rede diretamente pros respectivos
> >>> upstream e outra parte pro router2 (ibgp) prepended 2 ou prepended 3
> >>> - router1 localpref primario pros upstream contornando em caso de
> >>> falha ou sobrecarga (engenharia de trafego) com localpref seletivo
> >>> pro router2
> >>> - router2 anuncia sua parte da rede diretamente pros respectivos
> >>> upstream e a outra parte pro router1 (igb) prepended 2 ou prepended 3
> >>> - router2 localpref primario pros upstream contornando em caso de
> >>> falha ou sobrecarga (engenharia de trafego) com localpref seletivo
> >>> pro router1
> >>> - VRRP/CARP instancia 1 entre router1+router2 gerando redundancia do
> >>> IP pra LAN do router1
> >>> - VRRP/CARP instancia 2 entre router1+router2 gerando redundancia do
> >>> IP pra LAN do router2
> >>> - POPs e saltos abaixo da borda (LAN) usam IP virtual do router1 ou
> >>> do router2 seletivamente
> >>>
> >>> Quando router1 falhar router2 assume IP do router1, ambos gateways
> >>> continuam de pé, voce fica meio manco (so os upstream do router2 te
> >>> levam pro mundo, se Deus quiser vc terá IX pelo menos em ambos
> >>> routers pra aliviar o trauma). Quando router2 falhar acontece a
> >>> mesma coisa, mas router1 assume IP do router2. Quando nenhum falhar
> >>> voce tem tudo de pe balanceado em 2 routers e gerencia demanda entre
> >>> o enlace iBGP. Mesma convergência do cenário 1, tempo de downtime é
> >>> o tempo do mundo “ver” que um dos routers não prependados morreu.
> >>> Maior complexidade pra gerenciar.
> >>>
> >>> Setup 3) Primo pobre, single peering com todos neighbors de
> >>> upstream, sem enlace backup iBGP
> >>> - VRRP/CARP em todas as sessões BGP upstream
> >>> - VRRP/CARP em todas as interfaces LAN
> >>> - BGP com upstreams fechados no IP virtual do CARP/VRRP
> >>>
> >>> Enquanto router1 estiver vivo, router2 não tem BGP com ninguém e
> >>> fica ali de spare. Quando router1 cair, router2 assume IPs de
> >>> redundancia na LAN imediatamente, router2 assume IPs de BGP nas WAN
> >>> (upstream), em algum momento os peers com router1 vão notar que
> >>> router1 caiu e tentar restabelecer BGP no mesmo IP e agora router2
> >>> estará la. Conforme as sessões subirem e convergirem você vai
> >>> restabelecendo o ambiente. É a opção com maior downtime e maior
> >>> chance de barulho até restabelecer BGP no backup, que pode ser
> >>> minimizado com holdtime e keep alive mais curtos no router1. Mesmo
> >>> sendo a pior opção ainda é melhor que não ter redundancia ou ter que
> >>> deslocar um técnico ao local mediante falha. Pode-se também
> >>> automatizar um “bgpctl nei ${NEI} up” no router2 quando ele virar
> >>> master o que invariavelmente chama atenção dos upstream mais
> >>> espertos (OBGP, BIRD, Juniper) que o router1 caiu ja que alguém com
> >>> mesmo IP esta tentando estabelecer sessão. Ainda assim maior
> >>> downtime, maior tempo de convergência, mais barulho e maior
> >>> percepção de falha dentre as opções.
> >>>
> >>> Esses são os setup mais simples que eu uso, todos os demais são
> >>> variação desses que podem envolver um route server centralizando o
> >>> BGP e apontando os next hop pros respectivos roteadores de fato, ou
> >>> podem envolver mais sessões iBGP com mais pernas com saída própria
> >>> (diversos upstream pra Internet distribuídos em localizações
> >>> diversas), mas no fim é só uma variação dos 3 cenários acima
> >>> (normalmente do cenário 2).
> >>>
> >>> Pessoalmente gosto do Setup 1 e prefiro ele sempre que possível.
> >>> Também gosto do Setup 2 mas o cliente normalmente não gosta (maior
> >>> custo operacional, + horas de recurso humano mantendo).
> >>> Estranhamente muitos adoram o Setup 3 mesmo sendo o menos
> >>> recomendado e acham o custo do downtime aceitável dada a frequência
> >>> de falha e facilidade operacional.
> >>>
> >>> --
> >>> Patrick Tracanelli
> >>>
> >>> FreeBSD Brasil LTDA.
> >>> Tel.: (31) 3516-0800
> >>> 316601 at sip.freebsdbrasil.com.br
> >>> http://www.freebsdbrasil.com.br
> >>> "Long live Hanin Elias, Kim Deal!"
> >>>
> >>> --
> >>> 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
>