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

[Rodrigo Broilo]

Estes são os que possuem porta de acesso 1G UTP que conheço:

Juniper EX4200
Cisco 3750 / 3750-X

*Ambos acima possuem capacidade de porta 10G também, porém vide
documentação para hardware adicional/licença/etc..
**Eles fazem o LAG que você citou, lembrando que o backplane do stacking
será teu limitante em banda (vide documentação).

Abs,.

Rodrigo Broilo



On 15/02/12 09:36, "Lista" <lista.gter at gmail.com> wrote:

>Entendi Shine, e a todos obrigado pelos esclarecimento.
>PS:Teria algum switch que vocês conheçam que suporte essa feature em cima
>de stack?
>
>Em 14 de fevereiro de 2012 23:46, Shine <eshine at gmail.com> escreveu:
>
>> Vc está correto. Apenas observe que nem todos switches em stack fazem
>>isso,
>> por isso é importante vc checar se os switches aonde vc vai conectar seu
>> servidor suporta.
>> Mas falando especificamente de Linux... caso os switches não suportem a
>> funcionalidade acima ainda assim vc poderia usar soluções no kernel do
>> Linux como fazer bridging e usar STP para controlar o loop de camada 2.
>> A solução mais comum é utilizar redundância de camada 3 (por exemplo
>>VRRP),
>> conforme apresentado anteriormente pelos colegas. Mas a melhor
>>avaliação do
>> que aplicar vc tem q fazer conforme seu ambiente. Exemplificando, uma
>> solução conveniente para uma rede enterprise pode não ser aplicável a um
>> datacenter, outras são melhores para operadoras... e assim vai.
>>
>> sd,
>> Edgar
>>
>> Em 14 de fevereiro de 2012 09:55, Lista <lista.gter at gmail.com> escreveu:
>>
>> > 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
>> > >
>> > --
>> > 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
>