[GTER] Redundância Router

[Patrick Tracanelli]

> 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!"