Les interfaces de gestion d'interconnexion de fabric UCS présentent des problèmes de connectivité intermittents
Options de téléchargement
-
ePub (91.6 KB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone -
Mobi (Kindle) (81.7 KB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Langage exempt de préjugés
Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
À propos de cette traduction
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Contenu
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
Contribution d’experts de Cisco
- Neil MartinCisco TAC Engineer
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)