[GTER] Redundância Router

[João Butzke]

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