[GTER] Redundância entre Switchs (Era -Re: [caiu] Cloud Tecla Off)

[Lista]

Então pelo que entendi, se eu tiver dois switchs fazendo Stacking, tipo sw1
porta 1 e sw2 porta 1, e ativo o lacp em ambas as portas e conecto meu
roteador em ambas eth1 na porta 1 sw1 e eth2 porta1 sw2, e ativo o
bonding/lacp o switch e o roteador entederá que seria um unico equipamento,
devido a eles estarem empilhado, ae sim teria uma redundância entre switchs
via lacp/bonding (linux)?
Essa seria uma solução mais usual, oq vocês costuma utilizar nesse aspecto?

Em 13 de fevereiro de 2012 21:36, Rafael Ganascim <rganascim at gmail.com>escreveu:

> Uma alternativa é ter duas placas de rede no servidor. Conectar cada
> uma dessas placas em um switch diferente. Então, duas hipóteses:
>
> - ter dois switchs 'empilhados' (via stack) e fechar um link
> aggregation - eu gosto desta;
> - ter softwares como o Bacs da Broadcom, o lagg no FreeBSD no modo
> failover, ou ainda um shell script,  que deixam você ter duas placas,
> deixando uma em standby (sem aggregation)  - morreu uma ele assume a
> outra
>
>
> Em 13 de fevereiro de 2012 21:06, Lista <lista.gter at gmail.com> escreveu:
> > Tá mas a VRRP, vai atuar como backup de um interface de um roteador ou
> dele
> > por inteiro, ou switch, a pergunta é um roteador está conectado no sw1,
> via
> > porta X, como fazer para caso esse sw1 caia um sw2 assuma?
> >
> > Em 13 de fevereiro de 2012 16:27, Henrique de Moraes Holschuh <
> > henrique.holschuh at ima.sp.gov.br> escreveu:
> >
> >> On 13-02-2012 15:44, Lista wrote:
> >>
> >>> Caros colegas mais experiente no assunto, nesse caso como relato
> >>> pelo Pina, como disponibilizar que um host(servidor, ou roteador)
> >>> atrás de um switch fique redundante para o outro switch em caso de
> >>> pane eletrica, queima de eqpto, ou problemas de "osmár"?
> >>>
> >>
> >> Usando VRRP ou outro protocolo de alta-disponibilidade, só que..
> >>
> >>
> >>  Uma análise já foi conduzida (aparentemente erro de configuração
> >>>> no VRRP do switch) e um relatório será encaminhado para a Tecla em
> >>>> até 48 horas. Após recebermos o relatório, os clientes receberão
> >>>> uma cópia.
> >>>>
> >>>
> >> ... precisa ter certeza que não trocou "osmár" por coisa pior.
> >>
> >> Aqui a regra é testar o fail-over em todas as janelas de manutenção:
> >> VRRP e seus irmãos são todos notoriamente fáceis de configurar
> >> incorretamente.  Quando não é o VRRP, é a spanning-tree, ou alguma
> >> "feature" de segurança de equipamento de rede que atrapalha o fail-over
> >> correto.
> >>
> >> --
> >> 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
>