[GTER] RES: Redundância Router
Soares
soares at tecnetce.com.br
Wed Aug 3 12:38:34 -03 2016
Sem regra de firewall e queues.
Se habilitar qualquer umas desta funções o FAST-PATH não funciona.
Habilitando a função "ALLOW FAST PATH"
http://wiki.mikrotik.com/wiki/Manual:Fast_Path
-----Mensagem original-----
De: gter [mailto:gter-bounces at eng.registro.br] Em nome de João Rafael Card.
Enviada em: terça-feira, 2 de agosto de 2016 15:48
Para: Grupo de Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br>
Assunto: Re: [GTER] Redundância Router
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
>
--
gter list https://eng.registro.br/mailman/listinfo/gter
More information about the gter
mailing list