[GTER] RES: Re: Cisco VSS

[eshine at gmail.com]

Pessoalmente n recomendo esse cenário. Temos q pensar no VSL não como um link redundante, mas como uma comunicação de control plane. Se o VSL fosse projetado para suportar esse tipo de projeto nem precisaria do dual com BFD para recuperar o sincronismo (imagino).
As sup ficam em redundância SSO, caso perca o sincronismo e uma volte diferente da outra, entraria em modo cold e na próxima falha a sup standby faria reload.

Uma das maneiras de resolver IPs sobrepostos é usar um workaround de NAT e depois ir migrando gradativamente para uma nova estrutura de rede paralela.

Sd,
Edgar

Enviado do meu celular Nokia
-----Msg original-----
De: Rafael M. Koike
Enviado:  29/07/2011 23:41:24
Assunto:  Re: [GTER] Cisco VSS

O problema deste modelo é que quando a fibra voltar é quais sessões serão
sobrepostas e quais permanecerão.
Não sei o que o VSS irá fazer quando tiver X sessões no switch A e Y sessões
no switch B e os dois se juntarem novamente. (Somar as sessões de A + B?)



Em 29 de julho de 2011 16:02, Bruno Camargo <mustardahc at gmail.com> escreveu:

> Srs,
>
> Obrigado pelas repostas. Achei interessante a ideia do Koike, pois resolve
> o
> problema que estamos enfrentando hj.
>
> Os espertões de plataforma auto entitularam o IP 10.1.1.1 como gateway da
> rede de produção, só que este é o IP físico da VLAN de produção no Data
> Center A. Porém máquinas do Data Center B utilizam o 10.1.1.1 como gateway,
> ou seja, se o channel de fibra cair, quase todas as máquinas e serviços do
> Data Center B ficarão fora, pois o default-gateway está inalcançável.
>
> A idéia era configurar MHSRP, usando os IPs físicos atuais como virtuais,
> mantendo o master de cada localidade. Assim em caso de queda do channel de
> fibra ambos os VSS assumiriam o papel de master para ambos os gateways.
> Correto?
>
> Porém, em um cenário normal continuamos com tráfego indo e vindo no fiber
> channel... pois o gateway da máquina pode estar no outro DC.
>
> Com a configuração de "VSS Esticado", um switch de cada DC formando o
> cluster, tvz esse problema se resolva... vou desenhar um pouco!
>
> Valeu
>
> Bruno Camargo
>
>
>
> 2011/7/23 Shine <eshine at gmail.com>
>
> > IMHO, seria mais interessante fazer o VSS no em cada DC e entre esses
> > VSS switches usar um channel nas fibras. Assim vc fica com uma conexão
> > looping free, que é uma das propostas do VSS e com o domínio das
> > caixas em cada DC ao invés de correr um risco maior de romper o canal
> > VSL.
> >
> > Sobre um update recente, a partir da versão 12.2(33)SX4 (hoje
> > recomendado SX6), é possível configurar o VSS em quatro Supervisors,
> > só que em RPR. Se antes vc tinha apenas a opção de ter o VSS com
> > apenas um Supervisor em cada chassis, ao menos agora vc pode ter
> > quatro e quando uma delas morrer vc não ficará sem um chassis inteiro
> > indisponível esperando chegar outra placa. Mas bom mesmo seria ter
> > tudo em SSO, claro...
> >
> > sd,
> > Edgar
> >
> > Em 23 de julho de 2011 21:00, Rafael M. Koike <r.koike at terra.com.br>
> > escreveu:
> > > Porque voce nao faz o VSS entre 6509A (DC1) <-> 6509A (DC2) e outro VSS
> > > entre 6509B (DC1) <-> 6509B (DC2)
> > > depois entre VSS1 e VSS2 voce faz rstp+ ou STP com uplinkfast,
> > backbonefast
> > > e portfast.
> > > Terá uma boa velocidade de convergencia.
> > >
> > > Em 22 de julho de 2011 16:39, Bruno Camargo <mustardahc at gmail.com>
> > escreveu:
> > >
> > >> Srs,
> > >>
> > >> Temos dois data centers conectados com um link de 20Gbps. São duas
> > fibras
> > >> apagadas de 10Gbps conectadas em dois switches 6509-E.
> > >>
> > >> Cada Data Center tem dois 6509-E com VSS habilitado, ou seja, um
> switch
> > >> virtual por DC. E o link entre eles é layer 2.
> > >>
> > >> Seria possivel habilitar o VSS entre os dois clusters ? VSS do VSS...
> > >> hein???
> > >>
> > >> Alguém já ouviu falar disso?
> > >>
> > >> Obrigado,
> > >>
> > >> --
> > >> Bruno Camargo
> > >> --
> > >> 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
> >
>
>
>
> --
> Bruno Camargo
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>
>
--
gter list    https://eng.registro.br/mailman/listinfo/gter