Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Problème : Les interfaces de gestion d'interconnexion de fabric UCS présentent des problèmes de connectivité intermittents.

Topologie

IP d'interconnexion de fabric sur VLAN 10

Communication de périphérique problématique sur VLAN 1

Dépannage

Cause première

Solution

Additional Information

Informations connexes

Introduction

Ce document décrit comment les interfaces de gestion des interconnexions de fabric UCS ont rencontré des problèmes de connectivité intermittents avec les communications à destination et en provenance d'une plage IP spécifique.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

- Logiciel Unified Computing Systems Manager (UCSM)

- Mise en réseau de Unified Computing System (UCS)

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

- 6 200 FI

- 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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Problème : Les interfaces de gestion d'interconnexion de fabric UCS présentent des problèmes de connectivité intermittents.

Les interfaces de gestion d'interconnexion de fabric UCS présentent une perte de connectivité intermittente, mais uniquement lorsque la communication s'étend sur une plage IP spécifique. La plage IP 10.128.10.0/24 du VLAN 10 est utilisée pour les interfaces de gestion d'interconnexion de fabric (FI) et les adresses IP virtuelles (VIP). Lorsque la communication entre dans ou depuis la plage IP 10.128.1.0/24 du VLAN 1, la connectivité entre les FI et en provient tombe en panne. Ainsi, tout périphérique de la plage IP du VLAN 1 ne peut pas se connecter à UCSM et ne peut envoyer qu'une requête ping à une adresse IP FI.  Au moins une adresse IP FI (sur trois, FI-A, FI-B, VIP) est toujours en mesure de communiquer.

Topologie

IP d'interconnexion de fabric sur VLAN 10

FI-A: 10.128.10.84

FI-B: 10.128.10.85

VIP:  10.128.10.86

GW: 10.128.10.1

Communication de périphérique problématique sur VLAN 1

Subnet 10.128.1.0/24

GW: 10.128.1.1

Dépannage

À partir du contexte de gestion locale des deux interconnexions de fabric, il peut atteindre sa passerelle (df) par défaut (gw), 10.128.10.1. mais aucune adresse IP sur la plage IP VLAN 1 de 10.128.1.0/24 n'est accessible au contexte de gestion locale des interconnexions de fabric ou depuis celui-ci.

Dans un premier temps, cela semble être un problème de routage au niveau de la passerelle, et non un problème UCS, car il s'agit simplement d'une interface de gestion sur les interconnexions de fabric et si elle peut atteindre la passerelle et toute autre plage IP. Il s’agit d’un problème de route de couche 3 sur le réseau en amont.

Lorsque la commande traceroute s'exécute à partir de l'interconnexion de fabric vers une plage d'adresses IP aléatoire (et toute autre plage d'adresses IP ne figurant pas dans la plage du VLAN 1) (par exemple, une adresse IP du VLAN 20 : 10.128.20.1), le premier saut de la commande traceroute est la passerelle du VLAN 10 de 10.128.10.1 et la requête ping a abouti.

Lorsque la commande traceroute s'exécute sur la plage IP connue et problématique 10.128.1.x/24, la commande traceroute échoue.

- C'est pourquoi il convient d'étudier la solution UCS.

- Cela n'aurait pas dû échouer, et le premier saut devrait être le df gw de l'interface de gestion, 10.128.10.1, comme c'était pour 10 des 10 autres IP qui ont été testées et étaient en dehors de la plage IP du VLAN 10, et qui n'étaient pas dans la plage IP du VLAN 1.

Afin d'approfondir l'enquête, vous avez exécuté un analyseur d'éthers pour voir ce qui se passe et quand la plage IP de VLAN 1 est envoyée par ping, ARP agit curieusement :

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

Le comportement attendu consistait à demander qui possède cette adresse IP VLAN 1, puis à indiquer la passerelle du VLAN 10 de gestion.

Cependant, lorsque la plage IP du VLAN 1 est envoyée par ping, ARP demande qui possède cette adresse IP et, pour indiquer 10.128.0.142, suivez ces instructions :

- Il doit s’agir de « Tell 10.128.10.1 », comme c’était le cas pour toutes les autres adresses IP testées.

- Vous ne reconnaissez même pas un sous-réseau ou une adresse IP 10.128.0.x.

Il s'agit d'un problème pour lequel l'IF a indiqué 10.128.0.142, lors de l'enquête sur le domaine UCS, il a été constaté que cette adresse IP était appliquée au CIMC du serveur 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>

Cause première

Le problème était une adresse IP CIMC statique mal typée pour le serveur 1/5.

En outre, il a été placé dans un sous-réseau de 255.255.248.0

Cela a créé une entrée indésirable dans la table de routage de Fabric Interconnect. Celle qui atteindrait la condition avant d’atteindre la route par défaut pour toutes les adresses IP comprises entre 10.128.0.1 et 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

Solution

La solution pour ce cas est de parcourir UCSM à partir d'une plage d'adresses IP non affectée et de corriger l'adresse statique CIMC hors bande (OOB) du serveur 1/5. Il est extrait du pool de gestion OOB et est déjà configuré. Il doit être utilisé comme tous les autres serveurs de l'environnement.

Additional Information

Si l'interconnexion de fabric est redémarrée, elle fonctionne parfois. Le problème concerne l'instance de gestion de ce serveur. L'entrée de table de routage non souhaitée est uniquement créée sur l'interconnexion de fabric. Lorsque l'instance de gestion était la même interconnexion de fabric que l'interconnexion de fabric principale, elle ne peut pas atteindre le VIP ou cette interconnexion de fabric.

L'affectation IP de gestion CIMC doit toujours se trouver dans la même plage d'adresses IP que la plage d'adresses IP OOB de Fabric Interconnect.

Informations connexes

- Guide de gestion de l'administration de Cisco UCS Manager 3.1

- Support et documentation techniques - Cisco Systems