[GTER] RES: Redundância Router
João Rafael Card.
maxrafa at gmail.com
Thu Aug 4 16:01:59 -03 2016
mas o Fasttrack cria regras no firewall filter, então sem contrack ele não
funciona! ?
*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 3 de agosto de 2016 12:38, Soares <soares at tecnetce.com.br> escreveu:
> 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
>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list