Estou procurando alguns conselhos pós-evento para que esse evento não ocorra novamente.
Temos um núcleo de rede de dois switches Cisco 4500x, configurados para redundância VSS. Desses, temos dispositivos iSCSI, nosso bladecenter HP para nosso vSphere, além de links agregados para nossos comutadores de acesso de usuário e um par de comutadores 4948e para dispositivos de cobre em nossa sala de servidores. Fora dos 4948es, temos um par de switches 2960 para dois links ISP e um par de ASA como firewalls. Redundância bastante decente, exceto por muitos dos dispositivos que se conectam ao 4948e só possuem NICs únicas - o máximo que podemos fazer.
Estamos nos preparando para substituir nossos switches de acesso de usuário atuais (antigos Extremes) pelo Meraki. Também estamos implementando os Meraki APs para substituir nossos Arubas atuais. Parte do projeto sem fio envolve a criação de algumas novas VLANs e sub-redes, para gerenciamento de AP e sem fio convidado.
Nós tínhamos duas VLANs definidas (20 e 40) no 4500x que não eram usadas em nenhum lugar - confirmamos que as sub-redes estavam vazias, nenhuma porta as utilizava etc. Entrei no 4500x e emiti " no interface vlan 20
" e depois o reconstruí com a sub-rede Eu queria. Adicionei-o às duas portas de 10 Gb conectadas ao Meraki
switchport trunk allowed <previous list plus two VLANs above plus existing wireless VLAN>
Percebi que as 20 e 40 VLANs foram encerradas, por isso as emiti no shutdown
. Perdi o acesso aos Merakis naquele momento, então percebi que não havia adicionado as VLANs à interface do canal da porta para esse link.
Metade do nosso ambiente tornou-se inacessível neste momento
Nosso link da Internet ficou extremamente ruim. Nossos telefones VoIP da Avaya não puderam discar ou entrar. Temos alguns dispositivos iSCSI conectados a cobre que se tornaram indisponíveis - sem interrupção para nada voltado para o usuário, mas nossos backups e arquivo de mensagens foram afetados. Entrei na sala do servidor e desconectei o Merakis do 4500x (desconectamos as duas portas de fibra de 10Gb), caso eu tivesse de alguma forma criado um loop - nenhuma alteração. Eu admito que simplesmente olhei para isso por um tempo naquele momento.
Peguei o Orion e notei que um de nossos comutadores externos (o Cat2960) e um de nosso par ASA também estavam inativos. Aparentemente, tivemos algum tipo de perda parcial de conectividade da LAN, mas o par ASA também está conectado com crossover entre si, e seus uplinks não diminuíram, então eles não fizeram o failover para o que nossos dispositivos internos poderiam alcançar. Eu desliguei o ASA "inativo" e a internet se tornou acessível novamente.
Liguei para o TAC e, depois de algumas horas lutando com o técnico, que ficava procurando cada configuração de porta para cada host derrubado que eu estava mostrando a ele no 4500x, entrei em um dos nossos switches 4948e e mostrei como ele não podia executar ping que estavam diretamente conectados e ativos - um de nossos dispositivos iSCSI de cobre baseados no Windows, uma interface do iLO em nosso bladecenter, etc.
Ele examinou os logs e não encontrou nada, mas neste momento disse: "Parece um bug de árvore de abrangência, mesmo que eu não veja isso nos logs", então reiniciamos o 4948e e todos os seus arquivos diretamente. os hosts conectados voltaram imediatamente - incluindo o gabinete da Avaya; portanto, nossos telefones começaram a funcionar novamente. Ainda tínhamos problemas nos dispositivos conectados à fibra 4500x - caminhos mortos, pois tudo era redundante. Ele queria dar um ciclo de forma desagradável, mas isso tem todos os nossos iSCSI de 10 Gbit e isso faria com que nosso ambiente vSphere (essencialmente todos os nossos servidores) tivesse uma semana ruim. Eu o convenci a fazer uma transição graciosa de redundância, que cuidava dos problemas restantes.
TL; DR: Fiz uma mudança bastante inócua em nosso núcleo e causei um problema hediondo. Cometi um erro de configuração que deveria ter causado isso - por exemplo, se eu não tivesse desligado as VLANs primeiro e as adicionado ao canal de porta e depois às portas, isso seria evitado? O técnico da Cisco não disse isso; ele disse, com uptime de mais de um ano e versões antigas do IOS, situações como essa não são surpreendentes.
4500x: Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), versão 03.04.05.SG RELEASE SOFTWARE (fc1) ROM: 15.0 (1r) SG10
4948e: Software Cisco IOS, Software do Catalyst 4500 L3 Switch (cat4500e-IPBASEK9-M), versão 15.0 (2) SG10, SOFTWARE DE RELEASE (fc1) ROM: 12.2 (44r) SG11