[GTER] Redundância Router

Helio Filho heliofilho at enteriw.com.br
Wed Apr 13 09:41:01 -03 2016


http://www.dell.com/us/business/p/networking-n3000-series/pd

Em 13 de abril de 2016 09:17, Lista <lista.gter at gmail.com> 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
>



-- 
*Helio Filho*
*Supervisor Técnico*
*Enteriw Provedor de Internet Ltda*
(83)3535-2121 *(Fixo)*
(83)3535-2334 *(Fixo)*
(83)9991-4177 *(Celular / TIM)*
*INOC-DBA: ** 61570*200*
*Skype/E-mail*: heliofilho at enteriw.com.br
*Web Site*: http://www.enteriw.com.br



More information about the gter mailing list