[GTER] Redundância Router

João Rafael Card. maxrafa at gmail.com
Tue Aug 2 15:47:52 -03 2016 

Como essa conta fecha?   79Gbps com apenas 1Mpps (essa conta não fecha!)
estou errado?






*Att,*

. ı | ı . ı | ı .

*João** Rafael *

*Security Network Engineer*

*Skype: maxrafa <maxrafa at gmail.com>*

55 21 *97203-8776*

                                                        *Together* *we are
the* *h**u**m**a**n* *n**e**t**w**o**r**k*

Em 13 de abril de 2016 17:33, Kurt Kraut <listas at kurtkraut.net> escreveu:

> Aloha Henrique,
>
>
> Já vi mais de uma vez gente demonstrando atingir 80gbit/s com a CCR1072,
> como por exemplo, https://www.youtube.com/watch?v=nzcwVapVwQQ
>
>
> Abraços,
>
> Kurt Kraut
>
> Em 13 de abril de 2016 09:34, Henrique Isoppo - Websul Datacenter <
> henrique at websul.com.br> escreveu:
>
> > Não sei o que recomendar no lugar da CCR, mas se a idéia é ter essa parte
> > do core em 10G, fuja.
> >
> > Assim como o throughput do CRS, essa router é só fantasia.
> > Duas portas 10G + oito portas 1G, mas possui um backplane de 28G.
> >
> > Para comparação, um switch TL-SG5412F, da TPLink, com 12 portas SFP
> > Gigabit, possui backplane de 24G = 2G por porta (1G in / 1G out)
> >
> > --
> >
> > Henrique C. Isoppo
> > Gestor - Datacenter - Websul Telecom
> > t: (51) 4063-6699 | Ramal 702 - INOC-DBA: 52851*100
> > e: henrique at websul.com.br | w: www.websul.net.br
> >
> >
> > -----Original Message-----
> > From: gter [mailto:gter-bounces at eng.registro.br] On Behalf Of Ricardo
> > Pereira via gter
> > Sent: 13 April 2016 08:58 AM
> > To: Grupo de Trabalho de Engenharia e Operacao de Redes
> > Cc: Ricardo Pereira
> > Subject: Re: [GTER] Redundância Router
> >
> > 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
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

More information about the gter mailing list