[GTER] Redundância Router

Wed Apr 13 09:34:40 -03 2016

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