Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Problema: Le interfacce di gestione dell'interconnessione fabric UCS presentano problemi di connettività intermittente.

Topologia

Fabric Interconnect IP su VLAN 10

Comunicazione problematica del dispositivo sulla VLAN 1

Risoluzione dei problemi

Causa principale

Soluzione

Ulteriori informazioni

Informazioni correlate

Introduzione

In questo documento viene descritto come le interfacce UCS Fabric Interconnect Management (Mgmt) abbiano riscontrato problemi di connettività intermittenti con le comunicazioni da e verso un intervallo IP specifico.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

- Software Unified Computing Systems Manager (UCSM)

- Reti UCS (Unified Computing System)

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

- 6200 FI

- UCS Manager 4.0

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Problema: Le interfacce di gestione dell'interconnessione fabric UCS presentano problemi di connettività intermittente.

Le interfacce di gestione dell'interconnessione fabric UCS hanno una perdita di connettività intermittente, ma solo quando la comunicazione si trova su un intervallo IP specifico. L'intervallo IP 10.128.10.0/24 della VLAN 10 viene usato per le interfacce di gestione dell'interconnessione fabric (FI) e l'indirizzo IP virtuale (VIP). Quando la comunicazione tra la VLAN 1 e la VLAN 1 ha un intervallo IP di connettività 10.128.1.0/24 da e verso gli FI si interrompe. Pertanto, qualsiasi dispositivo sull'intervallo IP della VLAN 1 non è in grado di connettersi a UCSM e può eseguire il ping su un solo IP IP IP.  Almeno un IP FI (di tre, FI-A, FI-B, VIP) è sempre in grado di comunicare.

Topologia

Fabric Interconnect IP su VLAN 10

FI-A: 10.128.10.84

FI-B: 10.128.10.85

VIP:  10.128.10.86

GW: 10.128.10.1

Comunicazione problematica del dispositivo sulla VLAN 1

Subnet 10.128.1.0/24

GW: 10.128.1.1

Risoluzione dei problemi

Dal contesto di gestione locale di entrambe le interconnessioni Fabric, è possibile raggiungere il gateway (df) predefinito (gw), 10.128.10.1. ma nessun indirizzo IP nell'intervallo IP della VLAN 1 pari a 10.128.1.0/24 è raggiungibile dal contesto di gestione locale delle interconnessioni Fabric o proveniente da esso.

All'inizio, questo sembra essere un problema con il routing al gateway, e non un problema con l'UCS, perché è semplicemente un'interfaccia di gestione sulle interconnessioni fabric e se può raggiungere il gateway e qualsiasi altro intervallo IP. Questo problema si presenta come un problema del percorso di layer 3 sulla rete a monte.

Quando il comando traceroute viene eseguito dall'interconnessione fabric a un intervallo IP casuale (e a qualsiasi altro intervallo IP non compreso nell'intervallo della VLAN 1) (ad esempio, un IP della VLAN 20: 10.128.20.1), il primo hop sul traceroute è il gateway VLAN 10.128.10.1 e il ping ha esito positivo.

Quando il comando traceroute viene eseguito sull'intervallo IP 10.128.1.x/24 noto e problematico, il comando traceroute ha esito negativo.

- Questo porta alla ragione per cui è necessario indagare sul lato UCS.

- Questo non avrebbe dovuto causare un errore. Il primo hop deve essere il df gw 10.128.10.1 dell'interfaccia di gestione, come per 10 degli altri 10 IP testati e non compresi nell'intervallo IP della VLAN 10, e che non erano inclusi nell'intervallo IP della VLAN 1.

Per analizzare ulteriormente la situazione, è stato eseguito un etanalyzer per verificare cosa succede e quando viene eseguito il ping sull'intervallo IP della VLAN 1, l'ARP si comporta in modo curioso:

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

Il comportamento previsto era quello di chiedere chi aveva questo IP VLAN 1 e poi dirlo al gateway della VLAN 10 di gestione.

Tuttavia, quando viene eseguito il ping dell'intervallo IP della VLAN 1, ARP chiede a chi è associato l'IP e di comunicare il valore 10.128.0.142, attenersi alla seguente procedura:

- Dovrebbe essere "Tell 10.128.10.1" come per tutti gli altri IP testati.

- Non si riconosce neanche una subnet o un indirizzo IP 10.128.0.x.

Questo è un problema per cui la FI ha detto 10.128.0.142, durante l'indagine del dominio UCS è stato trovato che questo indirizzo IP è stato applicato al CIMC del server 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 principale

Si è verificato un errore di digitazione dell'indirizzo IP statico CIMC per il server 1/5.

Inoltre, è stato inserito in una subnet di 255.255.248.0

Ciò ha creato una voce indesiderata nella tabella di route dell'interconnessione fabric. una che supererebbe la condizione prima di raggiungere il percorso predefinito per tutti gli IP nell'intervallo da 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

Soluzione

La soluzione in questo caso è sfogliare il modulo UCSM da un intervallo IP non interessato e correggere l'indirizzo statico CIMC Out of Band (OOB) del server 1/5. Viene estratto dal pool di gestione OOB ed è già impostato. Deve essere utilizzato come qualsiasi altro server nell'ambiente.

Ulteriori informazioni

Se l'interconnessione Fabric viene riavviata, talvolta funziona. Il problema riguarda l'istanza di gestione del server. La voce della tabella di route indesiderata viene creata solo sull'interconnessione dell'infrastruttura. Quando l'istanza di gestione corrisponde all'interconnessione fabric dell'interconnessione fabric principale, non è possibile raggiungere l'indirizzo VIP o l'interconnessione fabric.

L'assegnazione IP della gestione CIMC deve essere sempre compresa nello stesso intervallo IP dell'intervallo IP OOB dell'interconnessione fabric.

Informazioni correlate

- Cisco UCS Manager Administration Management Guide 3.1

- Documentazione e supporto tecnico – Cisco Systems