[GTER] Redundância Router

Wed Apr 13 09:17:14 -03 2016

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
>