Ce document fournit une référence unique sur la façon de collecter des données de gestion de réseau sur une interface ATM à l’aide du protocole SNMP (Simple Network Management Protocol). Il se concentre spécifiquement sur les interfaces ATM de routeur Cisco.
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.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
ATM comprend une pile à trois couches : une couche d’adaptation ATM (AAL), une couche ATM et une couche physique, telle que Sonet ou T1. Chaque couche compte les paquets et les octets d’une manière légèrement différente. Par conséquent, une interface ATM apparaît plusieurs fois dans ifTable, avec les entrées suivantes :
Couche physique, telle que Sonet
Couche cellule ATM
couche AAL5
Toutes les sous-interfaces (selon le niveau du logiciel Cisco IOS)
Voici un exemple de données ifTable qui illustre ces couches multiples :
# snmpwalk -c public 192.168.1.1 ifDescr IF-MIB::ifDescr.1 = STRING: ATM0 IF-MIB::ifDescr.2 = STRING: Ethernet0 IF-MIB::ifDescr.3 = STRING: ATM0-atm layer IF-MIB::ifDescr.4 = STRING: ATM0.0-atm subif IF-MIB::ifDescr.5 = STRING: ATM0-aal5 layer IF-MIB::ifDescr.6 = STRING: ATM0.0-aal5 layer IF-MIB::ifDescr.7 = STRING: Null0 IF-MIB::ifDescr.8 = STRING: ATM0.1-atm subif IF-MIB::ifDescr.9 = STRING: ATM0.1-aal5 layer IF-MIB::ifDescr.10 = STRING: ATM0.11-atm subif IF-MIB::ifDescr.11 = STRING: ATM0.11-aal5 layer # snmpwalk -c public 192.168.1.1 ifType IF-MIB::ifType.1 = INTEGER: sonet(39) IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6) IF-MIB::ifType.3 = INTEGER: atm(37) IF-MIB::ifType.4 = INTEGER: atmSubInterface(134) IF-MIB::ifType.5 = INTEGER: aal5(49) IF-MIB::ifType.6 = INTEGER: aal5(49) IF-MIB::ifType.7 = INTEGER: other(1) IF-MIB::ifType.8 = INTEGER: atmSubInterface(134) IF-MIB::ifType.9 = INTEGER: aal5(49) IF-MIB::ifType.10 = INTEGER: atmSubInterface(134) IF-MIB::ifType.11 = INTEGER: aal5(49)
Référez-vous à Compteurs SNMP : Foire aux questions pour plus de détails sur les compteurs SNMP.
Une unité de données de protocole AAL5 (PDU) contient :
En-tête d’encapsulation RFC 1483 à huit octets
Paquet de couche 3 initial
Remplissage de longueur variable
Huit octets de la queue de bande AAL5
Le remplissage de longueur variable est utilisé pour faire de la taille totale de l'unité de données de protocole AAL5 un multiple de 48 octets. Les octets de la couche AAL5 ne comptent que les octets du paquet de couche 3 d’origine et les huit octets de l’en-tête RFC1483. Les paquets de ce niveau comptent le nombre de PDU AAL5. Utilisez les compteurs show ATM vc et show interface ATM command-line interface (CLI) ou utilisez SNMP pour consulter les informations de couche AAL5 pour voir ce résultat :
# snmpwalk -c public 192.168.1.1 ifDescr | grep aal5 IF-MIB::ifDescr.5 = STRING: ATM0-aal5 layer IF-MIB::ifDescr.6 = STRING: ATM0.0-aal5 layer IF-MIB::ifDescr.9 = STRING: ATM0.1-aal5 layer IF-MIB::ifDescr.11 = STRING: ATM0.11-aal5 layer
Les unités de données de protocole AAL5 sont ensuite segmentées en plusieurs blocs de 48 octets, puis chaque bloc dispose d’un en-tête de cellule de cinq octets pour former une cellule ATM de 53 octets au niveau de la couche ATM.
Sur les commutateurs ATM de campus Cisco, les octets de la couche ATM comptent le nombre total d’octets de la cellule ATM, tandis que les paquets comptent le nombre de cellules.
Sur les routeurs Cisco, les compteurs SNMP de la couche cellule ATM ne sont pas maintenus en raison des limitations des pilotes de la plupart des interfaces ATM. La couche de cellules ATM pour les sous-interfaces ATM sur le routeur hérite de cette limite. Pour plus de détails sur les compteurs de cellules, référez-vous à Mesure de l'utilisation des circuits virtuels permanents ATM.
Au niveau de la couche physique (avec, par exemple, SONET ou T1), les compteurs SNMP pour l'interface principale représentent toujours des unités de données de protocole AAL5, comme dans la sortie de commande show interface ATM. Dans ce cas, il s'agit de compteurs ifTable/ifXTable pour :
#snmpwalk -c public 192.168.1.1 ifDescr.1 IF-MIB::ifDescr.1 = STRING: ATM0 #snmpwalk -c public 192.168.1.1 ifType.1 IF-MIB::ifType.1 = INTEGER: sonet(39)
Les compteurs de paquets de non-monodiffusion, de diffusion et de multidiffusion n'ont aucune signification au niveau des couches Sonet et AAL5 ; ils ne sont pas présents ou définis sur 0.
Au niveau de la couche physique (avec, par exemple, SONET ou T1), vous pouvez obtenir le nombre d'octets et de paquets à l'aide de ifTable et ifXTable.
Des technologies telles que ATM, Frame Relay et les réseaux locaux virtuels (VLAN) ont introduit un type d’interface différent : l'interface virtuelle, ou sous-interface. Sur une interface ATM, par exemple, vous pouvez avoir plusieurs circuits virtuels permanents (PVC). Bien que l’utilisation globale de l’interface principale soit importante, la quantité de trafic sur les sous-interfaces individuelles présente également un intérêt. La RFC 1573 (remplacée par la RFC 2233 ) a introduit le concept de tables éparses pour les sous-interfaces. Les tables séparées signifient qu'une ligne de ifTable pour une sous-interface peut ne pas avoir de valeurs dans les colonnes où les objets ne s'appliquent pas à la sous-interface.
Le logiciel Cisco IOS a mis en oeuvre la prise en charge des sous-interfaces dans le ifTable de la version 11.1. La prise en charge des sous-interfaces LAN (LANE) Frame Relay et ATM a été ajoutée dans la version 11.1 du logiciel Cisco IOS. La prise en charge des autres sous-interfaces ATM a été ajoutée dans la version 12.0(1)T pour les plates-formes Cisco 12000, 4x00/M, 72xx et 75xx. Chaque sous-interface est représentée par deux entrées ifTable : une pour la couche ATM (atmSubInterface) et une pour la couche AAL5. En ce qui concerne l’interface principale, les compteurs de paquets et d’octets sont disponibles uniquement pour les entités de couche AAL5, car la plupart des interfaces de routeur ATM ne prennent pas en charge le nombre de couches de cellules.
La ifType atmSubInterface (IANA [Internet Assigned Numbers Authority] ifType number = 134) est définie pour une sous-interface ATM. La couche atmSubinterface est une couche ATM virtuelle. Les variables MIB d'interface qui correspondent à la couche atmSubInterface ont la même sémantique que celles de la couche ATM sur une interface principale (physique).
Ces groupes de conformité s'appliquent à la couche atmSubInterface :
ifGeneralInformationGroup
ifFixedLengthGroup
ifHCFixedLengthGroup
Les valeurs de ces variables sont définies pour les couches atmSubInterface et AAL5 lors de la création de la sous-interface ATM :
ifIndex
ifDescr
ifName
ifType
Les valeurs de ces variables sont mises à jour de manière identique pour les couches atmSubInterface et AAL5 :
ifSpeed, ifHighSpeed : ces variables sont mises à jour lors d'une demande SNMP GET à l'aide de la bande passante configurée sur la sous-interface ATM. Si aucune bande passante distincte n’est configurée sur la sous-interface, la bande passante de l’interface principale est utilisée.
ifPhysAddress —Cette variable est mise à jour avec l'adresse du point d'accès au service réseau (NSAP) de la sous-interface, lors de chaque demande SNMP GET pour tenir compte de la possibilité de suppression d'adresse NSAP.
ifAdminStatus, ifOperStatus —Ces variables reflètent l'état administratif et opérationnel de la sous-interface, et les valeurs sont déterminées à partir des états disponibles dans les blocs de descripteurs d'interface matérielle et logicielle Cisco IOS.
ifLastChange : cette variable est mise à jour avec sysUpTime au moment où la sous-interface entre dans son état opérationnel actuel.
Ces variables ne sont pas conservées pour la couche atmSubInterface en raison de l'absence de compteurs de la couche cellule dans les pilotes des interfaces actuelles :
ifInOctets, ifOutOctets
ifHCInOctets, ifHCOutOctets
Les compteurs peuvent être mis en oeuvre si les pilotes des nouvelles cartes de ports ATM (PA) fournissent des compteurs de couche de cellule.
Ces variables ne sont pas conservées pour la couche atmSubInterface, car elles ne sont pas conservées au niveau de la couche ATM :
ifInUcastPkts, ifInNUcastPkts
ifOutUcastPkts, ifOutNUcastPkts
ifInBroadcastPkts, ifOutBroadcastPkts
ifInMulticastPkts, ifOutMulticastPkts
ifInDisques
ifHCInUcastPkts, ifHCInMulticastPkts, ifHCInBroadcastPkts,
ifHCOutUcastPkts, ifHCOutMulticastPkts, ifHCOutBroadcastPkts
Ces variables ne sont pas mises à jour au niveau de la couche atmSubInterface, car il n'est pas possible de collecter ces statistiques par VC :
ifInErrors
ifOutErrors
ifInUnknownProtos
ifOutDiscards
ifOutQLen
Ces variables sont câblées en dur sur FALSE pour les sous-interfaces ATM :
ifPromiscuousMode
ifConnectorPresent
Pour les compteurs de chaque circuit virtuel AAL5, utilisez CISCO-AAL5-MIB et reportez-vous à Mesure de l'utilisation des circuits virtuels permanents ATM pour plus de détails. Si votre circuit virtuel AAL5 est le seul circuit virtuel configuré sur une sous-interface ATM, vous pouvez obtenir des compteurs AAL5 correspondants via SNMP en utilisant des entrées de couche AAL5 pour cette sous-interface dans le ifTable/ifXTable. Les valeurs absolues des compteurs de sous-interface de couche AAL5 peuvent refléter les états antérieurs des circuits virtuels qui ont été précédemment configurés sur cette sous-interface et qui ont été supprimés ou remplacés ultérieurement. En règle générale, ce n'est pas une préoccupation, car vous utilisez normalement delta (la différence entre deux sondages de compteur) dans un calcul.
Les interfaces ATM prennent en charge les déroutements de liaison générique vers le haut et vers le bas définis dans la MIB II. Cet exemple de sortie a été capturé sur un multiplexage inverse ATM sur un module de réseau ATM (IMA). Il a utilisé la commande debug snmp packet pour afficher le contenu des déroutements.
3640-1.1(config)# interface ATM 2/0 3640-1.1(config-if)# no shutdown 3640-1.1(config-if)# *Mar 1 20:17:24.222: SNMP: Queuing packet to 171.69.102.73 *Mar 1 20:17:24.222: SNMP: V1 Trap, ent products.110, addr 10.10.10.1, gentrap 3, spectrap 0 !--- The gentrap value "3" identifies the LinkUp generic trap. ifEntry.1.1 = 1 ifEntry.2.1 = ATM2/0 ifEntry.3.1 = 18 lifEntry.20.1 = up *Mar 1 20:17:24.290: SNMP: Queuing packet to 171.69.102.73 *Mar 1 20:17:24.290: SNMP: V1 Trap, ent ciscoSyslogMIB.2, addr 10.10.10.1, gentrap 6, spectrap 1 clogHistoryEntry.2.49 = LINK clogHistoryEntry.3.49 = 4 clogHistoryEntry.4.49 = UPDOWN clogHistoryEntry.5.49 = Interface ATM2/0, changed state to up clogHistoryEntry.6.49 = 7304420
Exécutez la commande show snmp pour confirmer que le routeur a envoyé une PDU de déroutement.
3640-1.1# show snmp Chassis: 10526647 55 SNMP packets input 0 Bad SNMP version errors 16 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37 Number of requested variables 0 Number of altered variables 2 Get-request PDUs 37 Get-next PDUs 0 Set-request PDUs 55 SNMP packets output 0 Too big errors (Maximum packet size 1500) 2 No such name errors 0 Bad values errors 0 General errors 39 Response PDUs 16 Trap PDUs
Avant la version 12.2 du logiciel Cisco IOS, la sortie de la commande debug snmp packet affiche la valeur NO_SUCH_INSTANCE_EXCEPTION pour l'objet locIfReason sur une sous-interface ATM. En d’autres termes, pour une sous-interface ATM, le routeur génère un déroutement qui contient ces informations par défaut :
sysUpTime.0 = 53181 snmpTrapOID.0 = snmpTraps.3 ifEntry.1.64 = 64 ifEntry.2.64 = ATM1/0.1-aal5 layer ifEntry.3.64 = 49 ifEntry.20.64 = NO_SUCH_INSTANCE_EXCEPTION
Cette exception se produit parce que l'ANCIENNE MIB-INTERFACES-CISCO ne prend pas en charge les sous-interfaces. L'ID de bogue Cisco CSCdp41317 (clients enregistrés uniquement) résout ce problème via la commande snmp-server trap link ietf. Ce résultat est maintenant attendu et conforme à la RFC 2233 :
sysUpTime.0 = 46573 snmpTrapOID.0 = snmpTraps.4 ifEntry.1.64 = 64 ifEntry.7.64 = 1 ifEntry.8.64 = 1 ifEntry.2.64 = ATM1/0.1-aal5 layer ifEntry.3.64 = 49
La RFC 1695 définit la base de données ATM-MIB, qui fournit des objets ATM et AAL5 pour la gestion des interfaces ATM, des liaisons virtuelles ATM, des interconnexions ATM, des entités AAL5 et des connexions AAL5. Cette base MIB organise les objets gérés en huit groupes :
Configuration de l’interface ATM
ATM Interface DS3 PLCP
Sous-couche TC de l'interface ATM
Configuration VPL d’interface ATM
Configuration VCL de l’interface ATM
ATM VP Cross Connect
Connexion croisée VC ATM
Statistiques de performances ATM Interface AAL5 VCC
Les versions 11.2 et ultérieures du logiciel Cisco IOS fournissent une instrumentation ATM-MIB standard pour de nombreux compteurs déjà fournis dans les interfaces ATM du routeur. ATM-MIB fournit certaines fonctionnalités permettant de modifier la configuration ATM sur le périphérique en prenant en charge un certain nombre d'opérations SNMP SET (reportez-vous à Configuration des connexions virtuelles ATM avec SNMP pour plus de détails). Cette fonctionnalité snmp ATM-MIB n'est pas prise en charge sur les routeurs Cisco dotés d'interfaces ATM, mais vous pouvez l'utiliser pour les commutateurs ATM Cisco. Il y a encore quelques limites. Par exemple, ATM-MIB n'est pas pris en charge pour la interconnexion de VC/VP à des pseudo-interfaces ATM (ATM-P) pour les cartes de ports CES (Circuit Emulation Service).
Pour localiser d'autres MIB ATM prises en charge par chaque produit, utilisez les outils MIB Cisco IOS, ainsi que les fiches techniques et les guides de configuration de la carte de ports ATM ou du module spécifique.
Voici une liste de MIB ATM généralement prises en charge sur les routeurs :
Voici une liste de MIB ATM généralement prises en charge sur les commutateurs ATM de campus Cisco :
En outre, considérez les MIB liées au support physique, telles que DS1-MIB, DS3-MIB et SONET-MIB.