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

[Shine]

Quando se fala de agregação de portas camada 2, vc tem duas premissas:
1) ambas pontas (host - switch) precisam suportar o mesmo protocolo de
agregação (LACP/802.1AX, PAGP).
2) A entidade switch ser única. Entenda-se switch ser "único" como uma
entidade lógica única. Isso pode ser feito por empilhamento, clustering ou
virtualização.
No caso do host, o suporte à agregação pode ser por software (exemplo
habilitar o link bonding no Linux kernel) ou por hardware (exemplo integrar
uma blade switch no servidor) ou mesmo ambos (exemplo integrar uma blade
switch com VM e VSphere).
Alternativa pode ser spanning tree (pode ser habiltado nos hosts de forma
similar à agregação) . Mas note que existem modelos distintos de spanning
tree (802.1d, Rapid e MST entre outros) e embora tenha uma certa
compatibilidade entre os diversos "flavors", a vida prática nos mostra que
a abordagem de estender o spanning tree até o host pode ser uma estratégia
ruim na medida em que a rede for aumentando.

Existem também falhas no campo que podem gerar problemas. Os fabricantes em
resposta implementaram algumas soluções que podem minimizar essas situações
como por exemplo fazer checagem bidirecional de BPDUs.

sd,
Edgar

Em 13 de fevereiro de 2012 21:18, Cassio Lange <cassio at cassio.eng.br>escreveu:

> Ola,
>
> Se vc deseja fazer entre o servidor e sw, pode usar etherchannel ou 802.3ad
>
> 2012/2/13 Lista <lista.gter at gmail.com>
>
> > 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
>