[GTER] RES: Redundância Router

Geeek Masters rgeeek at gmail.com
Thu Aug 4 17:32:22 -03 2016 

confunda fasttrack com fastpath.

Em 4 de agosto de 2016 16:01, João Rafael Card. <maxrafa at gmail.com>
escreveu:

> 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
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 


<https://ubnt.zendesk.com/attachments/token/cSQI60Oj1xSqnAmT4s2bmyCXj/?name=Rodrigo+Gregorio+C.+de+Paula+%28Geeek%29.pdf>[image:
IPV6 Ready?] <http://geeekzone.com/>[image: IPV6 Ready?]
<https://ipv6.he.net/certification/scoresheet.php?pass_name=Geeek>

More information about the gter mailing list