[GTER] Redundância Router

Antonio Modesto modesto at isimples.com.br
Wed Apr 13 17:03:53 -03 2016 


On 13-04-2016 11:54, Ricardo Pereira via gter wrote:
> Bom dia, quando você citou caixa L800, está se referindo ao 
> equipamento abaixo?
> http://www.serveru.us/pt/netmapl800
>
Esse mesmo.


> Att,
> Ricardo Pereira
>
> 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

-- 
Atenciosamente,

More information about the gter mailing list