Plusieurs processeurs résidant sur un module de processeur système dédié ainsi que localement sur le matériel d'interface fonctionnent ensemble pour assurer la transmission et la réception des paquets sur des circuits virtuels ATM. Ces processeurs communiquent entre eux en publiant des messages pour exécuter des fonctions telles que la configuration et le retrait des circuits virtuels, la collecte de statistiques de couche physique et la génération d'alarmes. Ces messages, appelés lettres d'amour ou messages d'amour, sont écrits par un processeur dans un bloc de mémoire. Un processeur récepteur lit ensuite le message. La sortie de la commande debug atm events fournit une fenêtre dans ce mécanisme de messagerie, comme la sortie suivante d'un PA-A3.
Jun 17 12:48:50.631 BST: atmdx_mailbox_proc(ATM5/0/0): received report type 2 Jun 17 12:48:50.631 BST: atmdx_process_love_letter(ATM5/0/0): 2 VCs core statistics Jun 17 12:48:55.631 BST: atmdx_mailbox_proc(ATM5/0/0): received report type 3 Jun 17 12:48:55.631 BST: atmdx_process_love_letter(ATM5/0/0): 1 VCs aux statistics
L'objectif de ce document est d'illustrer un exemple de sortie d'événement debug atm pour aider à distinguer les messages d'information et les messages qui pointent vers un problème opérationnel. Ce document passe également en revue l’architecture logicielle d’interface ATM standard.
Attention : Avant d'émettre des commandes debug, reportez-vous à Informations importantes sur les commandes Debug. La commande debug atm events peut imprimer une grande quantité de résultats de débogage perturbateurs sur un routeur de production en fonction du nombre de circuits virtuels pour lesquels il doit déclarer des statistiques ainsi que de la quantité d'événements liés au circuit virtuel.
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Toutes les interfaces ATM utilisent une architecture logicielle composée de plusieurs blocs. Avant de parcourir ces blocs logiciels, nous devons d'abord comprendre les pilotes du logiciel Cisco IOS® et l'architecture du bus PCI à l'intérieur de votre routeur.
Un pilote permet aux ingénieurs logiciels de mettre en oeuvre ce qu'on appelle l'abstraction matérielle. Il permet aux ingénieurs de créer un ensemble fondamental de blocs logiciels qui s'exécutent sur n'importe quelle plate-forme, puis d'utiliser des pilotes pour adapter ce code indépendant de la plate-forme à une plate-forme spécifique telle que la série 7200 ou la série 3600.
La carte PA-A3 prend en charge un pilote hôte PCI qui permet au processeur SAR (Segmentation and Reassembly) de s'interconnecter avec les bus PCI (Device Component Interconnect) de la gamme 7200/7400, ainsi qu'avec le processeur d'interface polyvalent (VIP) sur les plates-formes RSP. Les bus PCI servent de chemin de données entre les cartes de ports et la mémoire hôte sur le VIP ou sur le NPE (Network Processing Engine)/NSE (Network Services Engine). Le schéma suivant illustre l'architecture du VIP2 et l'emplacement des bus PCI :
Ce tableau répertorie les blocs logiciels sur le PA-A3 :
Bloc logiciel | Fonction |
coeur ATM | Fonctions logicielles indépendantes de la plate-forme ou de la PA utilisées par toutes les interfaces ATM. Par exemple, le coeur ATM gère la gestion OAM et ILMI. |
Pilote de plate-forme | Fonctions logicielles dépendantes de la plate-forme qui relient le logiciel principal ATM général au logiciel du pilote hôte PCI. Le coeur ATM et le pilote hôte PCI échangent des commandes, des mises à jour d’état et des statistiques via le pont. Le pilote ATM de plate-forme gère également le transfert de paquets de réception, les fonctions d'initialisation spécifiques à la plate-forme et les statistiques de couche physique, comme indiqué dans l'affichage show controller atm. |
Pilote hôte PCI | Fournit l'interface hôte PCI de la puce SAR sur le PA-A3. Effectue plusieurs fonctions clés :
|
Interface hôte | Partie du bloc fonctionnel matériel de chaque SAR. Effectue plusieurs actions clés :
|
Micrologiciel | Code de démarrage ou de démarrage ainsi que des images d'exécution optimisées pour l'unité de processeur ATM (APU) sur les SAR de réception et de transmission. Téléchargé à partir du pilote hôte PCI. |
Sur la plate-forme RSP/VIP, le pilote de plate-forme réside dans l'image système RSP et l'image système VIP, tandis que le pilote hôte PCI fait partie de l'image système VIP. Sur la plate-forme 7200, les deux pilotes font partie de l'image système.
Le logiciel PA-A3 est fourni avec le logiciel VIP ou avec le logiciel système pour d'autres plates-formes de support.
Comme indiqué ci-dessus, une boîte aux lettres fait partie d'un modèle de messagerie que Cisco IOS utilise pour transporter les messages entre deux processeurs. Voici comment fonctionne généralement ce processus :
Un pilote alloue une mémoire tampon de messages.
Une note d'amour ou une lettre remplit la mémoire tampon du message.
Le processeur de réception lit la mémoire tampon des messages.
Une fois la lecture du tampon de commande terminée, le processeur génère une interruption de message terminé.
La mémoire tampon du message est renvoyée au pool de mémoire tampon libre.
Ce document examine maintenant deux ensembles de messages échangés entre les processeurs exécutant les composants du logiciel Cisco IOS décrits dans le tableau ci-dessus.
Le pilote hôte PCI collecte des statistiques par circuit virtuel sur chaque paquet. Le pilote de la plate-forme VIP transmet ces statistiques de manière autonome au pilote de la plate-forme RSP via une note d'amour toutes les secondes. La commande show atm vc affiche les données VC actuelles. Le pilote de plate-forme VIP transmet les statistiques de trameur au RSP toutes les 10 secondes. Lorsque le système s'initialise, il crée un processus d'arrière-plan spécial qui gère les statistiques autonomes à partir du VIP en tant que processus planifié plutôt qu'au niveau d'interruption pour minimiser l'interruption du système.
La commande debug atm events imprime la sortie sur les événements liés au circuit virtuel, tels que la configuration et la désactivation.
Fonction | Description |
setupvc | Configurez un circuit virtuel. Le pilote dépendant de la plate-forme transmet la requête au pilote hôte PCI. |
teardownvc | Lance un circuit virtuel existant. Le pilote dépendant de la plate-forme relaie la requête au pilote hôte PCI. |
getvc_stats | Récupère des statistiques sur les CR à la demande ; ne prend en charge qu'une seule requête VC. |
qos_params_verify | Vérifie les paramètres QoS avant la configuration d'un circuit virtuel. |
La SAR se compose en interne de blocs fonctionnels matériels. L'un de ces blocs est l'unité de traitement ATM (APU), qui est un miniRISC avec une logique personnalisée pour les extensions spécifiques à ATM. Le pilote hôte PCI et l'APU, qui exécute le micrologiciel ATM, communiquent via une boîte aux lettres de messagerie. À tout moment, une commande en attente pour chaque APU est utilisée pour demander au microprogramme de la PA d'effectuer une tâche spécifique, telle qu'une configuration de circuit virtuel. Le micrologiciel transmet des statistiques par circuit virtuel et par port au pilote hôte PCI toutes les 10 secondes si les données changent.
Le résultat suivant généré à partir de l'événement debug atm montre les commandes envoyées par le pilote hôte PCI au microprogramme. Le micrologiciel renvoie uniquement des accusés de réception pour indiquer le succès de la commande. Ces accusés de réception ne sont pas affichés dans la sortie de débogage.
7200-1.3(config)# int atm 6/0 7200-1.3(config-if)# pvc 1/100 7200-1.3(config-if-atm-vc)# vbr-nrt 45000 45000 7200-1.3# 17:07:43: atmdx_setup_vc(ATM6/0): vc:14 vpi:1 vci:100 state:2 config_status:0 17:07:43: atmdx_pas_vc_setup(ATM6/0): vcd 14, atm hdr 0x00100640, mtu 4482 17:07:43: VBR: pcr 96000, scr 96000, mbs 94 17:07:43: vc tx_limit=1600, rx_limit=480 17:07:43: Created 64-bit VC counterss 7200-1.3(config)# int atm 6/0 7200-1.3(config-if)# no pvc 1/100 7200-1.3(config-if)# 17:08:48: atmdx_teardown_vc(ATM6/0): idb state 4 vcd 14 state 4 17:08:48: atmdx_pas_teardown_vc(ATM6/0): vcd 14
Ce document applique maintenant les informations ci-dessus en traversant l'architecture logicielle du module de réseau IMA (IMA) pour les gammes de routeurs 2600 et 3600.
Le module IMA NM a un côté « hôte » pour indiquer les fonctions ou la mémoire sur le module processeur et un côté « local » pour indiquer les fonctions ou la mémoire sur le module réseau lui-même. Le côté hôte exécute des pilotes indépendants de la plate-forme et dépendants de la plate-forme. Le côté local exécute le micrologiciel téléchargé par les pilotes hôtes sur le processeur intégré du NM. Cette image gère les fonctions de la couche physique, notamment le contrôle de l'ASIC du trameur, la collecte de statistiques de la couche physique et la génération de boucles et d'alarmes. Les pilotes Cisco IOS et le micrologiciel NM communiquent par courrier électronique.
Du côté local, l'IMA NM exécute également un pilote IMA qui utilise de la même manière une boîte aux lettres de message pour communiquer avec le processeur local.
Les messages dans la direction du côté hôte vers le côté local sont principalement conçus pour la configuration. Ces messages incluent :
Données de configuration de couche physique E1/T1
Configuration du groupe IMA
Configuration de bouclage
Configuration du débogage
Requête pour l'état du groupe/lien IMA
Requête pour données MIB (Management Information Base) RFC 1406
Requête pour les données MIB IMA
Les messages envoyés du côté local vers le côté hôte sont utilisés pour communiquer les changements d'état des lignes et les statistiques de performances, notamment :
Modifications de l’état de la couche physique E1/T1
Modifications de l'état du groupe IMA
Modifications de l'état de la liaison IMA
Modifications de l'état de bouclage
Messages de débogage
Réponse des données MIB RFC 1406
Réponse aux données MIB IMA
L'exemple suivant illustre les notes d'amour utilisées pour configurer et démonter un circuit virtuel. Nous avons arrêté et fermé l'interface physique pour forcer l'arrêt. Notez que « rs8234 » fait référence à la SAR sur le NM.
3640-1.1(config)# int atm2/ima2 3640-1.1(config-if)# pvc 1/1 3640-1.1(config-if-atm-vc)# shut 3640-1.1(config-if)# *Mar 1 00:17:20.323: Reserved bw for 1/1 Available bw = 6000 *Mar 1 00:17:20.323: rs8234_setup_vc(ATM2/IMA2): vc:4 vpi:1 vci:1 *Mar 1 00:17:20.323: rs8234_setup_vc_common() VCD=260 vp/vc=17/1 etype=0 *Mar 1 00:17:20.323: rs8234_setup_cos(ATM2/IMA2): vc:4 wred_name:- max_q:0 *Mar 1 00:17:20.327: Created 64-bit VC counters *Mar 1 00:17:20.327: rs8234_teardown_vc(ATM2/IMA2): vc:260 vpi:1 vci:1 *Mar 1 00:17:20.327: rs8234_teardown_vc proceeds (ATM2/IMA2): vc:260 vpi:1 vci:1 *Mar 1 00:17:20.327: Status and ptr is 400 Status Q is 1 *Mar 1 00:17:20.331: Resetting ATM2/IMA2 *Mar 1 00:17:20.331: rs8234_teardown_vc(ATM2/IMA2): vc:260 vpi:1 vci:1 *Mar 1 00:17:20.331: rs8234_teardown_vc proceeds (ATM2/IMA2): vc:260 vpi:1 vci:1 *Mar 1 00:17:20.331: Remove link with ports 8,links 4,channel 1 *Mar 1 00:17:22.327: %LINK-5-CHANGED: Interface ATM2/IMA2, changed state to administratively down 3640-1.1(config-if)# no shut 3640-1.1(config-if)# *Mar 1 00:17:31.287: Resetting ATM2/IMA2 *Mar 1 00:17:31.287: IMA config_interface ATM2/IMA2 *Mar 1 00:17:31.287: IMA config_restart ATM2/IMA2 *Mar 1 00:17:31.287: IMA restarting 0 VCs *Mar 1 00:17:31.287: rs8234_setup_vc(ATM2/IMA2): vc:4 vpi:1 vci:1 *Mar 1 00:17:31.287: rs8234_setup_vc_common() VCD=260 vp/vc=17/1 etype=0 *Mar 1 00:17:31.287: rs8234_setup_cos(ATM2/IMA2): vc:4 wred_name:- max_q:0
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
15-Nov-2007 |
Première publication |