[GTER] pc router

[Gustavo Santos]

O problema é a própria RB1000x e a nova CR36 só ter uma fonte de
alimentação. Ela queimando, "babau"!

Gustavo Santos
Analista de Redes
CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER



Em 25 de abril de 2012 07:41, Sergio Ferreira <sergio at wgo.com.br> escreveu:

> E o que te impede de ligar duas fontes em redundância nas RBs ?
>
> Sergio Ferreira
> WGO Telecom
> 64 3411 3000
> 64 8119 1840
>
> Enviado via iPad
>
> Em 24/04/2012, às 20:42, Vicente De Luca <vdeluca at comp.ufla.br> escreveu:
>
> > E conhecendo bem o forum, se voce sugerir algo do tipo é capaz de
> dizerem que não precisa, pois voce pode comprar 2 routerboard e usar VRRP,
> já suportado no routeros :P
> >
> > abs,
> >
> > vdeluca
> > INOC: 28302*100
> > On 24/04/2012, at 19:58, Gustavo Santos wrote:
> >
> >> Infelizmente é a realidade. O Pessoal da Mikrotik investiu em CPU, mas
> >> esqueceu de detalhes básicos de equipamentos "Carrier Class" como fonte
> >> redundante.
> >>
> >>
> >> Gustavo Santos
> >> Analista de Redes
> >> CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER
> >>
> >>
> >>
> >> Em 24 de abril de 2012 17:27, Henrique de Moraes Holschuh <
> >> henrique.holschuh at ima.sp.gov.br> escreveu:
> >>
> >>> On 24-04-2012 14:47, Bruno Cabral wrote:
> >>>
> >>>> O ruim disso é o plano de controle ter uma topologia completamente
> >>>>> diferente do plano de dados.  Tem uns jeitos meio absurdos de
> >>>>> resolver isso.  O certo seria modelar o plano de dados no routing
> >>>>> engine consolidado, mas até lá dá para montar uma gambiarra usando
> >>>>> uma árvore
> >>>>>
> >>>>
> >>>> você fala tipo redistribuir loopbacks via IGP?
> >>>>
> >>>
> >>> Não.  Dá uma lida no site do routeflow, é um cenário bem mais complexo
> >>> que isso.
> >>>
> >>> As caixas nesse caso não tem nenhum plano de controle fora o do
> >>> OpenFlow, portanto elas não tem nem sequer IGP.
> >>>
> >>>
> >>> Aliás, essa do plano de controle não seguir o caminho do plano de
> >>>>> dados pode acontecer quando você usa refletores ou servidores de
> >>>>> rotas. Cuidado nesses casos, porque o iBGP não vai refletir a
> >>>>> realidade dos enlaces, e portanto o *IGP* e a topologia tem que
> >>>>> garantir que nunca vai haver particionamento no plano de dados que
> >>>>> não seja detectável no plano de controle (e vice-versa!).  Daí a
> >>>>> recomendação de colocar os refletores em caixas de meio de
> >>>>> caminho, seguindo a topologia.
> >>>>>
> >>>>
> >>>> no curso de BGP com mikrotik que ministro temos um lab exatamente
> >>>> desse jeito. e uma outra versão, com refletores nas pontas ao invés
> >>>> de no caminho
> >>>>
> >>>
> >>> A análise da árvore de falha precisa fazer parte desse lab :-)
> >>>
> >>>
> >>> Sinceramente, eu preferia que parassem de colocar CPU furreca nos
> >>>>> roteadores com portas Gigabit e encaminhamento por hardware.
> >>>>> Ninguém vai reclamar que uma caixa ficou 1% a 5% mais cara porque
> >>>>> no lugar de um ARM ou MIPS com quase nada de memória, foi colocado
> >>>>> um Mobile Processor x86-64 com 8GiB de DDR3 ECC.
> >>>>>
> >>>>
> >>>> quem sabe aquele novo router com 36 cores da mikrotik comece a fazer
> >>>> os fabricantes grandões pararem de economizar merrecas...
> >>>>
> >>>
> >>> Não acho que o mercado de roteadores enterprise vá sequer notar a
> >>> existência dessa caixa.
> >>>
> >>>
> >>> --
> >>> Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
> >>> IM@ - Informática de Municípios Associados
> >>> Engenharia de Telecomunicações
> >>> TEL +55-19-3755-6555/CEL +55-19-9293-9464
> >>>
> >>> Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
> >>> e do custo que você pode evitar.
> >>> --
> >>> gter list    https://eng.registro.br/**mailman/listinfo/gter<
> 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
>