Table des matières

Introduction

Concept

Conditions préalables

Configuration Steps

Dépannage et vérification

Introduction

Ce document décrit la configuration de Call Home dans un environnement Cisco ACI.

Concept

La fonction CallHome nous permet de recevoir par e-mail des notifications critiques sur les fonctionnalités du fabric, notamment des informations de diagnostic et des erreurs ou événements environnementaux. Il envoie ces alertes à plusieurs destinataires via des profils de destination CallHome, qui peuvent être configurés avec des formats de message et des catégories de contenu spécifiques.

Conditions préalables

- Le fabric doit être sur 4.2(1) ou supérieur.

- Tous les périphériques du fabric doivent disposer d'une connectivité réseau au serveur SMTP/E-Mail.

- Le port TCP de communication 25 doit être autorisé entre les périphériques du fabric et le serveur SMTP/E-Mail.

Configuration Steps

Étape 1 : Connectez-vous au contrôleur APIC.

- Accédez au contrôleur APIC en utilisant les identifiants admin.

Étape 2 : Créez un groupe de destinations CallHome.

- Accédez à APIC > Admin > External Data Collectors > Monitoring Destination

- Cliquez avec le bouton droit sur CallHomefolder et sélectionnez Create CallHome Destination Group.

Étape 3 : saisissez les informations requises.

Les détails requis sont mentionnés ci-dessous

- Nom - Nom du groupe de destinations CallHome

- Admin - activer cette option

- Port - 25, Numéro du port sur lequel SMTP communiquera.

- Serveur SMTP - Nom DNS ou adresse IP du serveur SMTP

- Adresse e-mail - adresse e-mail à partir de laquelle le fabric nous enverra des messages

- EPG de gestion : EPG oob ou inb accessible à notre serveur SMTP

- E-mail du contact : adresse e-mail à laquelle les messages seront reçus

- Sur la page suivante, nous pouvons créer des destinations exactes (c'est-à-dire des destinataires de messages CallHome).

- Cliquez sur + signer et remplir les champs

- Nom - nom de destination

- État admin : si cette option est désactivée, la destination ne recevra aucun message

- Niveau : niveau de gravité des messages qui seront envoyés à la destination. Je recommande ce jeu avec une valeur d'erreur ou supérieure. Un tableau des niveaux de gravité sera fourni ci-dessous.

- E-mail : adresse e-mail à laquelle les messages doivent être envoyés

- Format : si nous ne prévoyons pas d'analyser automatiquement les messages entrants, définissez cette option sur short-txt. Nous pouvons expérimenter pour voir les différences entre eux.

- Taille maximale (octets) - taille maximale d'un message électronique unique. Dans le cas où nous définissons Format à aml ou xml alors les messages peuvent être assez grands, donc le nombre de 100-200KB sont ok. Nous pouvons expérimenter avec ce nombre pour déterminer la taille requise. Pour le format court-texte, il doit suffire de le définir sur 10 Ko.

- Compatible RFC - Mieux vaut dire ne l'active pas.

- Nous pouvons créer autant de destinations que nécessaire et en créer davantage en cliquant avec le bouton droit sur notre groupe de destinations CallHome et en sélectionnant Créer une destination CallHome.

Étape 4 : Créez des groupes de requêtes Callhome

- Accédez à APIC > Admin > External Data Collectors > CallHome Query Groups

- Cliquez avec le bouton droit sur le dossier CallHome Query Groups et sélectionnez Create CallHome Query Group.

- Définissez le nom du groupe de requêtes et cliquez sur le signe + pour créer une définition de requête.

- Nom - nom de la requête

- Type : sélecteur de type d'objet qui sera surveillé à la recherche de modifications. J'ai sélectionné ici ce qui signifie "nom distinctif".

- DN ou nom de classe : nom de l'objet surveillé. Et c'est là que la magie entre en action ! Nous ne trouverons nulle part une quelconque description de quel type de nom d'objet ou quoi que ce soit qui doit être inséré dans ce champ. Ce champ n'était pas obligatoire dans la version 4 antérieure du contrôleur APIC. À partir de la version 4, elle est obligatoire. Si nous avons sélectionné forType, alors nous pouvons mettre ici ce qui signifie littéralement "Tout l'univers" ou en d'autres termes - "Tous les objets en tissu".

- Cible : sélectionne si les informations de sous-arborescence doivent être incluses pour l'objet renvoyé par la requête. J'ai sélectionné un sous-traitant.

- Sous-arborescence : sélectionne les objets de sous-arborescence qui doivent être renvoyés par la requête. J'ai sélectionné ici.

- Inclure : type d'objets qui seront renvoyés par la requête. J'ai tous sélectionné.

Étape 5 : Stratégies de surveillance du fabric et création de sources CallHome

Maintenant que les destinations et les requêtes CallHome sont configurées, nous pouvons passer à la modification de la stratégie de surveillance.

- Accédez à APIC > Fabric > Fabric Policies > Policies > Monitoring

- Assurez-vous que la valeur « ALL » est sélectionnée dans la liste déroulante « Monitoring Object » et que « Source Type » est défini sur « CallHome ».

- Cliquez sur+connectez-vous dans la partie droite du volet droit

- Nom - CallHome Nom de la source (Callhome_Source)

- Inclure : sélectionnez le type de notifications à recevoir

- Niveau - gravité de l'événement déclenchant l'action (niveau sélectionné ou supérieur)

- Groupe de destinations - ici , sélectionnez Groupe de destinations CallHome créé avant

- Groupe de requêtes - ici , sélectionnez Groupe de requêtes CallHome créé avant

- Cliquez sur Envoyer.

Remarque : Une fois la configuration terminée, nous pouvons affiner notre stratégie de surveillance en créant des sources CallHome distinctes pour différents objets de surveillance et en utilisant plusieurs groupes de destinations et requêtes CallHome

Étape 6 : Politiques d'accès Sources CallHome

Dans cette section, nous allons configurer les stratégies d'accès au fabric pour créer des sources CallHome.

Accédez à APIC > Fabric > Access Policies > Policies > Monitoring

- Le dossier Surveillance contient la stratégie de surveillance par défaut. Ouvrez la stratégie par défaut, cliquez sur le dossier CallHome/Smart CallHome/SNMP/Syslog/TACACS.

- Assurez-vous que ALL est sélectionné dans la liste déroulante Objet de surveillance et que Type de source est défini sur CallHome.

- Cliquez sur+connectez-vous dans la partie la plus à droite du volet droit :

- Nom - entrez le nom de la source CallHome (Access_CallHome)

- Inclure - sélectionnez le type de notifications à recevoir

- Niveau - gravité de l'événement déclenchant l'action (niveau sélectionné ou supérieur)

- Groupe de destinations : ici, nous sélectionnons le groupe de destinations CallHome que nous avons créé auparavant

- Groupe de requêtes : ici, nous sélectionnons le groupe de requêtes CallHome que nous avons créé avant

Étape 7 :  Une fois ces modifications effectuées, nous devons recevoir des alertes par e-mail sur l'ID de messagerie configuré.

Dépannage et vérification

1. Vérification de la connectivité du serveur SMTP

Pour confirmer que les périphériques APIC et Leaf peuvent atteindre le serveur SMTP via le port TCP 25, exécutez des tests ping et telnet.

1.1 Test Ping

Utilisez les commandes ci-dessous pour vérifier l'accessibilité de base du réseau à l'hôte SMTP :

Sur APIC :

APIC # ping x.x.x.x

Sur le commutateur Leaf :

Leaf# iping x.x.x.x

1.2 Test Telnet (port 25)

Exécutez les commandes suivantes pour vérifier que le port SMTP 25 est ouvert et accessible :

Sur APIC :

APIC # curl -v telnet://smtp_server_ip:port

Example :

APIC# curl -v telnet://x.x.x.x:25

Sur le commutateur Leaf :

Leaf# icurl -v telnet://smtp_server_ip:port

Example:

Leaf#icurl -v telnet://x.x.x.x:25

2. Validation de la configuration CallHome

Vérifiez que CallHome est correctement configuré sur le contrôleur APIC et sur les commutateurs Leaf.

2.1 Validation du profil CallHome

Assurez-vous que le profil est configuré avec le port et les paramètres corrects :

Sur APIC :

Apic# moquery -c callhomeProf

Sur le commutateur Leaf :

Leaf# moquery -c callhomeProf

2.2 Validation de la destination CallHome

Vérifiez que le serveur et le port SMTP de destination sont correctement définis :

Sur APIC :

Apic# moquery -c callhomeDest

Sur le commutateur Leaf :

Leaf# moquery -c callhomeDest

3. Vérification de la transmission du courrier électronique CallHome

Dans un fabric ACI typique, les messages CallHome sont lancés à partir de APIC2 dans un cluster à trois noeuds. Si APIC2 n'est pas disponible, ces messages peuvent provenir d'un commutateur leaf. Pour confirmer la source et la transmission des messages CallHome, utilisez tcpdump sur les interfaces appropriées.

3.1 À partir du contrôleur APIC (accès racine requis)

Si la gestion intrabande est configurée, remplacez bond0.330 par le VLAN utilisé pour la gestion intrabande :

Apic# tcpdump -i bond0.330 port 25

À partir du commutateur Leaf :

Utilisez l'interface kpm_inb pour surveiller le trafic SMTP sortant :

Leaf# tcpdump -i kpm_inb port 25

4. Dans certains cas, même après une configuration et une vérification réussies de CallHome, de la connectivité SMTP et des stratégies de surveillance, nous ne pouvons pas recevoir d'alertes de panne d'interface par e-mail.

Suivez les étapes ci-dessous pour résoudre le problème :

Utilisez l'explorateur de magasin d'objets pour inspecter la panne.

4.1 Accédez à l'interface concernée dans l'interface utilisateur graphique de l'ACI Cisco.

4.2 Cliquez avec le bouton droit sur l'interface et sélectionnez « Ouvrir dans le navigateur de la banque d'objets » (reportez-vous à la capture d'écran ci-dessous pour obtenir une assistance visuelle).

4.3 Dans l'explorateur de magasin d'objets, localisez le nom distinctif (DN) associé à l'objet défaillant.

4.4 Après avoir identifié le DN, accédez à l'interface de ligne de commande APIC et exécutez la commande suivante pour interroger les détails de l'objet :

Exemple : -

apic# moquery -d "topology/pod-1/node-101/sys/phys-[eth1/1]"

4.5. Dans le résultat de la commande précédente, localisez le champ monPolDn.

Exemple :

monPolDn : uni/infra/moninfra-default

Ce champ indique le nom distinctif (DN) de la stratégie de surveillance appliqué à l'objet interface.

4.6 Dans cet exemple, la politique de surveillance est la suivante : uni/infra/moninfra-default

Cela montre que la stratégie de surveillance par défaut sous le locataire Infra est appliquée à l'interface.

4.7 Pour s'assurer que CallHome génère et envoie des alertes pour les défaillances d'interface :

Vérifiez que la configuration CallHome est présente sous le locataire Infra.

Assurez-vous que la stratégie de surveillance (moninfra-default dans ce cas) est liée à un profil CallHome correctement configuré.