Sincronizar configuração de dois 3560 redundantes

Nós implementamos em nossos DataCenters uma solução com 2x3650 10G(um em cada site) como cores redundantes e 2960S como a camada de acesso.
A solução inclui diversas VLANs, VRF para cada cliente, e HSRP entre os dois 3560(em cada Vlan) para fornecer a alta disponibilidade.

A solução funciona bem, se o 3560 primário cai o outro assume, com perdas muito baixas ...

Mas, o problema é manter o sincronismo da configuração de ambos 3560.
- Coisas como ACLs, protocolo de roteamento, endereço IP standby, etc .. Devem ser idênticas.
e
- As coisas como configuração de interfaces físicas, o endereço IP de interfaces lógicas, etc .. Precisam ser diferentes.


Nós concordamos em fazer mudanças preferencialmente no 3560 primário, e fazer um "show archive config diff" no secundário para analisar as diferenças e manualmente aplicá-las que no secundário.
Isso ajuda, mas ainda é muito complexo para manter o ambiente.


Um dos meninos linuqueiros aqui sugeriu escrever uma ferramenta para comparar as configurações, eliminar as diferenças que precisa ser diferente, e informar por e-mail aqueles que precisam ser aplicadas.
Talvez isso funciona, mas para mim isso tem uma cara de gambiarra...


Alguém tem uma sugestão melhor?

Sinceramente, até onde eu saiba, via config de IOS, não há como para 3560.

As duas únicas forma que pensei, seria via VSS (não suportado pelo 3560) ou via stack, onde você poderia configurar os switches e eles funcionariam como um só. Mas, pelo que li, o 3560, também não suporta stackwise nem gigastack.

Não sei se existe algo que possa rolar em cima de TCL shell. Acredito que não...

Partindo disso, eu pensaria sim em rolar um script num server unix, podendo usar TFTP para copiar a config dos switches envolvidos e rolar um diff de coisas que realmente devem ser idênticas...
Lembrando que sempre há coisas que NÃO devem e NÃO podem ser iguais, como IPs de interfaces. Portanto, deve-se usar expressões regulares e um trigger, que poderia ser, por exemplo, data de alteração (sh start | i Last) ou mesmo rola o script todos os dias.

Este é o ponto... pode até desenvolver um bom script, mas sempre estará sujeito a falhas.


A mehor solução neste caso, no meu ponto de vista, seria um bom controle de changes.
Documentar cada alteração previamente.
Quem faz a change, tem a obrigação de saber o que existe no ambiente, isto é, deve saber que existem dois switches e que deve aplicar a config em ambos.

Num documento de change, deve existir:

- Identificador da change (número de ticket / protocolo)
- Data e hora prevista para o início da change
- Data e hora para o final da change
- Data e hora para testes e fallback (geralmente 30 minutos ou 1 hora depois da change)
- Quem requisitou a change
- Motivo da change
- Quem vai implementar a change
- Qual é o impacto durante a implementação change
- Qual é o nível de risco da change (alto impacto, risco médio, sem impacto previsto, etc)
- Approvals (pessoas e outros times envolvidos ou que serão impactados devem aprovar e/ou estarem cientes da change previamente)
- Documentar o que exatamente vai ser alterado e como vai ser alterado
- Testes de validação da change
- Fall back (se a change der errado, quais os passos para retornar como estava antes)

Depois de implementado, deve-se colocar os resultados e marcar a change como successful ou failed, apresentando o motivo, no caso desta última.

Depois de documentado, é só arquivar o documento para consultas futuras.
Se esquecerem de implementar algo num dos dois switches, é só uma questão de pesquisar nos documentos e logs dos equipamentos para saber quem foi e por qual razão não fez como deveria, para então, alinhar o funcionário ou seja lá quem fez a change para que, no futuro, faça corretamente.

Escrevi demais hehehe...

Ronaldo,

Gostei do post rsss, especialmente a parte das changes.

Quando eu li este post eu pensei na mesma coisa, a unica feature que faria este tipo de replicação é um VSS resolveria mas não é suportado por esta plataforma.
Talvez um script em shell/perl, ou um software específico.

abs

Mesmo com controle de changes, sempre achamos pepinos! Ou esqueceram de algo, ou não dumentaram, ou sabonetaram, etc. hehehe...

onde eu trabalho, temos trocentos scripts... a maioria, em pearl, usando SNMP pra acessar os devices.
Até que a grande maioria deles funciona perfeitamente.