[GTER] RES: Redundância Router
Gustavo Stocco
gustavostocco at gmail.com
Thu Aug 4 17:49:11 -03 2016
Complementando o que o Geek falou:
FastPath = Encaminha os pacotes sem processamento desnecessário;
Conntrack = Tabela na qual todas as conexões são armazenadas;
Fasttrack = FastPath + Conntrack;
2016-08-04 17:32 GMT-03:00 Geeek Masters <rgeeek at gmail.com>:
> 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>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
--
Gustavo Stocco
GNet Telecomunicaçõeshttp://www.gnettelecom.com.br
+55 (47) 3373-3322
0800-932-0000 R.3322
INOC-DBA BR 53001*100
More information about the gter
mailing list