As interfaces de gerenciamento de interconexão de estrutura UCS têm problemas de conectividade intermitente
Opções de download
Linguagem imparcial
O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
Sobre esta tradução
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Contents
Introduction
Este documento descreve como as interfaces UCS Fabric Interconnect Management (Mgmt) enfrentaram problemas intermitentes de conectividade com comunicações para e de um intervalo de IP específico.
Prerequisites
Requirements
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Software Unified Computing Systems Manager (UCSM)
- Rede do Unified Computing System (UCS)
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
- FI 6200
- UCS Manager 4.0
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Problema: As interfaces de gerenciamento de interconexão de estrutura do UCS têm problemas de conectividade intermitente.
As interfaces de gerenciamento de interconexão de estrutura do UCS têm perda de conectividade intermitente, mas somente quando a comunicação está em um intervalo de IP específico. O intervalo IP 10.128.10.0/24 da VLAN 10 é usado para interfaces de gerenciamento de Interconexão de estrutura (FI) e IP virtual (VIP). Quando a comunicação é para ou do intervalo IP da VLAN 1 de conectividade 10.128.1.0/24 para e dos FIs se interrompe. Assim, qualquer dispositivo no intervalo IP da VLAN 1 não pode se conectar ao UCSM e pode fazer ping somente em um IP FI. Pelo menos um IP FI (de três, FI-A, FI-B, VIP) é sempre capaz de se comunicar.
Topologia
IPs de interconexão de estrutura na VLAN 10
FI-A: 10.128.10.84 FI-B: 10.128.10.85 VIP: 10.128.10.86 GW: 10.128.10.1
Comunicação de dispositivo problemática na VLAN 1
Subnet 10.128.1.0/24 GW: 10.128.1.1
Troubleshoot
Do contexto de gerenciamento local de ambas as interconexões de estrutura, ele pode alcançar seu gateway padrão (df) (gw), 10.128.10.1. mas nenhum endereço IP no intervalo de IP da VLAN 1 de 10.128.1.0/24 é alcançável para ou do contexto de gerenciamento local das interconexões de estrutura.
No início, isso parece ser um problema de roteamento no gateway, e não um problema de UCS, pois isso é simplesmente uma interface de gerenciamento em interconexões de estrutura e se pode acessar o gateway e qualquer outro intervalo de IP. Isso se apresenta como um problema de rota de Camada 3 na rede upstream.
Quando o traceroute é executado do Interconector de estrutura para um intervalo de IP aleatório (e qualquer outro intervalo de IP fora do intervalo da VLAN 1) (por exemplo, um IP da VLAN 20: 10.128.20.1), o primeiro salto no traceroute é o Gateway da VLAN 10 de 10.128.10.1 e o ping foi bem-sucedido.
Quando o traceroute é executado no intervalo IP problemático conhecido 10.128.1.x/24, o traceroute falha.
- Isso leva à razão para investigar o UCS.
- Isso não deve ter falhado, e o primeiro salto deve ser o df gw da interface mgmt, 10.128.10.1, assim como era para 10 de 10 outros IPs que foram testados e estavam fora do intervalo IP da VLAN 10 e não estavam no intervalo IP da VLAN 1.
Para investigar mais, você executou um analisador de eventos para ver o que acontece e quando o intervalo IP da VLAN 1 é executado por ping, o ARP age de forma curiosa:
EWQLOVIUCS02-A(nxos)# ethanalyzer local interface mgmt display-filter arp limit-captured-frames 0 Capturing on eth0 2019-12-17 11:45:50.807837 00:de:fb:a9:37:e1 -> ff:ff:ff:ff:ff:ff ARP Who has 10.128.1.77? Tell 10.128.0.142 2019-12-17 11:45:51.807835 00:de:fb:a9:37:e1 -> ff:ff:ff:ff:ff:ff ARP Who has 10.128.1.77? Tell 10.128.0.142 2019-12-17 11:45:52.807827 00:de:fb:a9:37:e1 -> ff:ff:ff:ff:ff:ff ARP Who has 10.128.1.77? Tell 10.128.0.142 2019-12-17 11:45:55.807829 00:de:fb:a9:37:e1 -> ff:ff:ff:ff:ff:ff ARP Who has 10.128.1.77? Tell 10.128.0.142
O comportamento esperado era perguntar quem tem esse IP de VLAN 1, mas depois informar ao gateway de VLAN 10 de gerenciamento.
No entanto, quando o intervalo de IP da VLAN 1 é executado por ping, o ARP pergunta quem tem esse IP e para informar 10.128.0.142, siga estes passos:
- Deve ser "Diga 10.128.10.1" como foi com todos os outros IPs testados.
- Você nem mesmo reconhece uma sub-rede ou um endereço IP 10.128.0.x.
Esta é uma questão pela qual o FI diria 10.128.0.142, durante a investigação do domínio do UCS descobriu-se que esse endereço IP foi aplicado ao CIMC do servidor 1/5:
EWQLOVIUCS02-B(local-mgmt)# show mgmt-ip-debug ip-tables <SNIPPED> Chain PREROUTING (policy ACCEPT 5303K packets, 360M bytes) pkts bytes target prot opt in out source destination 188 9776 cimcnat tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 0 0 cimcnat tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 0 0 DNAT icmp -- * * 0.0.0.0/0 10.128.10.85 to:127.6.1.1 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.85 tcp dpt:2068 to:127.6.1.1:2068 0 0 DNAT udp -- * * 0.0.0.0/0 10.128.10.85 udp dpt:623 to:127.6.1.1:623 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.85 tcp dpt:22 to:127.6.1.1:22 449 26940 DNAT icmp -- * * 0.0.0.0/0 10.128.10.108 to:127.6.1.2 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.108 tcp dpt:2068 to:127.6.1.2:2068 0 0 DNAT udp -- * * 0.0.0.0/0 10.128.10.108 udp dpt:623 to:127.6.1.2:623 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.108 tcp dpt:22 to:127.6.1.2:22 931 55860 DNAT icmp -- * * 0.0.0.0/0 10.128.10.107 to:127.6.1.3 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.107 tcp dpt:2068 to:127.6.1.3:2068 0 0 DNAT udp -- * * 0.0.0.0/0 10.128.10.107 udp dpt:623 to:127.6.1.3:623 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.107 tcp dpt:22 to:127.6.1.3:22 0 0 DNAT icmp -- * * 0.0.0.0/0 10.128.10.104 to:127.6.1.3 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.104 tcp dpt:2068 to:127.6.1.3:2068 0 0 DNAT udp -- * * 0.0.0.0/0 10.128.10.104 udp dpt:623 to:127.6.1.3:623 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.104 tcp dpt:22 to:127.6.1.3:22 920 55200 DNAT icmp -- * * 0.0.0.0/0 10.128.10.106 to:127.6.1.4 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.106 tcp dpt:2068 to:127.6.1.4:2068 0 0 DNAT udp -- * * 0.0.0.0/0 10.128.10.106 udp dpt:623 to:127.6.1.4:623 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.106 tcp dpt:22 to:127.6.1.4:22 912 54720 DNAT icmp -- * * 0.0.0.0/0 10.128.10.105 to:127.6.1.6 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.105 tcp dpt:2068 to:127.6.1.6:2068 0 0 DNAT udp -- * * 0.0.0.0/0 10.128.10.105 udp dpt:623 to:127.6.1.6:623 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.105 tcp dpt:22 to:127.6.1.6:22 0 0 DNAT icmp -- * * 0.0.0.0/0 10.128.0.142 to:127.6.1.5 <<---- Indicates that 10.128.0.142 is the OOB KVM IP address for server 1/5. 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.0.142 tcp dpt:2068 to:127.6.1.5:2068 0 0 DNAT udp -- * * 0.0.0.0/0 10.128.0.142 udp dpt:623 to:127.6.1.5:623 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.0.142 tcp dpt:22 to:127.6.1.5:22 910 54600 DNAT icmp -- * * 0.0.0.0/0 10.128.10.102 to:127.6.1.7 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.102 tcp dpt:2068 to:127.6.1.7:2068 0 0 DNAT udp -- * * 0.0.0.0/0 10.128.10.102 udp dpt:623 to:127.6.1.7:623 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.102 tcp dpt:22 to:127.6.1.7:22 908 54480 DNAT icmp -- * * 0.0.0.0/0 10.128.10.101 to:127.6.1.8 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.101 tcp dpt:2068 to:127.6.1.8:2068 0 0 DNAT udp -- * * 0.0.0.0/0 10.128.10.101 udp dpt:623 to:127.6.1.8:623 0 0 DNAT tcp -- * * 0.0.0.0/0 10.128.10.101 tcp dpt:22 to:127.6.1.8:22 <SNIPPED>
Causa raiz
O problema foi um endereço IP CIMC estático com erro de digitação para o servidor 1/5.
Além disso, ele foi colocado em uma sub-rede 255.255.248.0
Isso criou uma entrada indesejada na tabela de roteamento do Interconector de estrutura. Um que atingiria a condição antes de atingir a rota padrão para todos os IPs no intervalo de 10.128.0.1 a 10.128.7.254
Linux(debug)# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.128.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.15.1.0 0.0.0.0 255.255.255.0 U 0 0 0 vlan4042 127.7.0.0 0.0.0.0 255.255.0.0 U 0 0 0 vlan4043 127.5.0.0 0.0.0.0 255.255.0.0 U 0 0 0 vlan4044 127.14.0.0 0.0.0.0 255.255.0.0 U 0 0 0 vlan4046 127.12.0.0 0.0.0.0 255.255.0.0 U 0 0 0 bond0 127.9.0.0 0.0.0.0 255.255.0.0 U 0 0 0 vlan4047 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0 <<---- Undesired route entry 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0 <<---- Undesired route entry 0.0.0.0 10.128.10.1 0.0.0.0 UG 0 0 0 eth0
Solução
A solução para esse caso é navegar pelo UCSM a partir de um intervalo de IP não afetado e corrigir o endereço estático OOB (Out of Band, fora da banda) do CIMC do servidor 1/5. Ele é extraído do pool de gerenciamento OOB e já está configurado. Deve ser usado como qualquer outro servidor no ambiente.
Additional Information
Se a interconexão de estrutura for reinicializada, ela funcionará às vezes. O problema está na Instância de gerenciamento desse servidor. A entrada da tabela de rota indesejada é criada somente no Interconector de estrutura. Quando a instância de gerenciamento era a mesma interconexão de estrutura que a interconexão de estrutura principal, eles não conseguiam acessar o VIP ou essa interconexão de estrutura.
A atribuição de IP de gerenciamento do CIMC deve estar sempre dentro do mesmo intervalo de IPs que o intervalo de IP OOB da interconexão de estrutura.
Informações Relacionadas
Colaborado por engenheiros da Cisco
- Neil MartinCisco TAC Engineer
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)