[GTER] Redundância Router

Wed Apr 13 10:50:16 -03 2016

Bom dia!
O modelo do Switch da Dell é o Dell Networking N4032F.
http://www.dell.com/us/business/p/networking-n4000-series/pd

Em 13/04/2016 09:17, Lista escreveu:
> Qual o modelo do Dell para interfaces 10Gbp/s?
>
> Em 13 de abril de 2016 08:57, Ricardo Pereira via gter <gter at eng.registro.br
>> escreveu:
>> 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