Fichier de configuration de Junos Snapshot Administrator
Comprendre le fichier de configuration Junos Snapshot Administrator
Le fichier de configuration Junos Snapshot Administrator définit l’étendue d’un snapshot et les critères d’évaluation pour un seul instantané ou une comparaison de deux snapshots. Vous fournissez l’emplacement du fichier de configuration Junos Snapshot Administrator comme argument à la jsnap commande.
Dans le fichier de configuration Junos Snapshot Administrator, les blocs de code délimitent des blocs de code et les points-virgules signalent la fin d’une instruction ou d’une commande. Vous pouvez insérer des commentaires dans le fichier de configuration à l’aide d’un hachage (#) ou d’un point-virgule (;) au début d’une ligne.
Le fichier de configuration Junos Snapshot Administrator se compose d’un bloc de code requis do placé au début du fichier de configuration, suivi d’un nombre illimité de sections de test définies par l’utilisateur. Les détails des composants individuels du fichier de configuration sont décrits dans les sections suivantes :
section do
Le do bloc de code répertorie le nom de chaque section de test qui sera utilisée dans l’instantané. Cette section est obligatoire et doit être placée au début du fichier de configuration. Vous pouvez définir autant de sections de test que vous le souhaitez, mais vous devez inclure le nom de la section test dans le bloc de do code pour exécuter ce test. La syntaxe du do bloc de code est :
do {
test-section-name1;
test-section-name2;
test-section-name3;
}
Par exemple, le bloc de code suivant do répertorie cinq sections de test. Lorsque Junos Snapshot Administrator fait référence au fichier de configuration, bien que le fichier de configuration puisse définir plus de cinq sections de test, l’outil exécute uniquement les cinq sections de test répertoriées dans le bloc de do code.
do {
re0-master;
ospf-checks;
l2vpn-list;
vpls-list;
bgp-checks;
}
Test Sections
Dans le fichier de configuration, vous définissez une ou plusieurs sections de test. Les sections de test, qui sont placées dans n’importe quel ordre après le do bloc de code, définissent la portée d’un snapshot et les critères d’évaluation pour un seul instantané ou une comparaison de deux snapshots.
Chaque section de test est composée d’une strophe de configuration unique, qui contient :
Le nom de la section : chaîne unique définie par l’utilisateur qui doit décrire la vérification effectuée.
Une
commanddéclaration : spécifie la commande du mode opérationnel Junos OS qui est exécutée pour collecter les données.Une ou plusieurs
itemdéclarations de section deiteratecontenu : définit les cas de test utilisés pour évaluer les données.
La syntaxe générale du bloc de code de section de test est la suivante :
test-section-name {
command command-syntax;
(item | iterate) xpath-expression {
[id xpath-expression;]
# test cases
}
}
Par exemple :
re0-master {
command show chassis routing-engine;
item route-engine[slot = '0'] {
is-equal mastership-state, "master" {
info re0 is always master;
err " re0 is not master, rather %s", mastership-state;
err " Correct so that re0 is the master!";
}
}
}
Les composants de la section test sont décrits en détail dans les sections suivantes :
- Nom de la section test
- Instruction de commande de section de test
- Critères d’évaluation de la section test
Nom de la section test
Les noms des sections de test sont des chaînes uniques définies par l’utilisateur qui doivent décrire la vérification effectuée. Vous ajoutez le nom des sections de test que vous souhaitez exécuter au bloc de do code au début du fichier de configuration. Lorsque Junos Snapshot Administrator fait référence au fichier de configuration, l’outil exécute toutes les sections de test répertoriées dans le bloc de do code.
Dans l’idéal, vous devriez créer des noms de sections de test descriptifs afin que vous ou toute autre personne travaillant avec le fichier de configuration puisse rapidement discerner l’étendue et l’objectif de chaque section de test longtemps après la création du fichier de configuration. Par exemple, vous pouvez utiliser active-chassis-alarm-check une section de test qui vérifie s’il y a des alarmes de châssis actives, comme illustré ici :
active-chassis-alarm-check {
command show chassis alarms;
item alarm-summary {
exists no-active-alarm {
info No chassis alarms;
err "There are %s chassis alarms", active-alarm-count;
}
}
}
Instruction de commande de section de test
Chaque section de test se compose d’un identifiant unique command suivi de la commande du mode opérationnel Junos OS qui est exécutée pour collecter les données souhaitées pour cette vérification. Par exemple, si vous souhaitez collecter et évaluer des données sur les voisins OSPF d’une interface, vous devez inclure l’identifiant command suivi de la commande du show ospf neighbor mode opérationnel, comme illustré ici :
ospf-neighbor-check {
command show ospf neighbor;
iterate ospf-neighbor {
id interface-name;
#
# test cases
#
}
}
À condition que le ospf-neighbor-check nom de la section soit inclus dans le do bloc de code, l’instantané qui en résulte comprendra les données XML de la sortie de commande show ospf neighbor . Pour plus d’informations sur les commandes du mode opérationnel Junos OS, consultez la référence opérationnelle de l’API Junos XML. Un exemple de la show ospf neighbor sortie est illustré ici :
<ospf-neighbor-information>
<ospf-neighbor>
<neighbor-address>10.1.12.2</neighbor-address>
<interface-name>ae18.0</interface-name>
<ospf-neighbor-state>Full</ospf-neighbor-state>
<neighbor-id>10.0.0.2</neighbor-id>
<neighbor-priority>128</neighbor-priority>
<activity-timer>3</activity-timer>
</ospf-neighbor>
<ospf-neighbor>
<neighbor-address>10.1.15.2</neighbor-address>
<interface-name>ae19.0</interface-name>
<ospf-neighbor-state>Full</ospf-neighbor-state>
<neighbor-id>10.0.0.5</neighbor-id>
<neighbor-priority>128</neighbor-priority>
<activity-timer>3</activity-timer>
</ospf-neighbor>
</ospf-neighbor-information>
Vous pouvez évaluer des éléments spécifiques dans la sortie de snapshot ou comparer des éléments entre plusieurs snapshots en définissant des cas de test.
Critères d’évaluation de la section test
L’instruction de section command test peut être suivie d’une ou d’une item iterate déclaration de section de contenu, dans laquelle vous définissez un ou plusieurs cas de test pour évaluer les données d’instantané capturées. Vous utilisez l’instruction item pour identifier un élément spécifique de manière unique, et l’instruction iterate pour itérer sur plusieurs éléments.
La syntaxe générale de la déclaration de section de contenu est la suivante :
(item | iterate) xpath-expression {
test-operator operator-params {
#specify an ID for test operators that compare two collections
[id xpath-expression;]
info string;
err "string";
}
}
Chaque cas de test est défini par un opérateur de test suivi des paramètres requis. Pour plus d’informations sur les opérateurs de test disponibles, consultez La présentation des opérateurs de test de l’administrateur de snapshots Junos et Junos Snapshot Administrator Test Operators et Junos Snapshot Administrator Test Operators. Dans le bloc de code de cas de test, vous définissez une info déclaration pour fournir des informations sur le cas de test et les conditions d’exploitation attendues. Vous définissez également une ou plusieurs err déclarations, qui sont générées lorsque le contenu échoue au cas de test spécifique.
L’exemple suivant présente un cas de test qui vérifie la sortie XML de la show chassis routing-engine commande pour déterminer si le moteur de routage de l’emplacement 0 est le moteur de routage principal. Si le mastership-state moteur de routage dans l’emplacement 0 n’est pas égal à « maître », le code génère deux err déclarations.
re0-master {
command show chassis routing-engine;
item route-engine[slot = '0'] {
is-equal mastership-state, "master" {
info RE-0 is always master;
err " RE-0 is not master, rather %s", mastership-state;
err " Correct error so that RE-0 is the master";
}
}
}
Lorsque vous utilisez certains opérateurs de test pour comparer les valeurs d’éléments sur deux snapshots, afin de mapper le premier élément de données d’instantané à un deuxième élément de données d’instantané, vous devez sélectionner des éléments des données qui créent un ID unique. Pour créer un ID unique pour un cas de test, vous devez inclure l’instruction id suivie d’une expression XPath qui fait référence à l’élément unique. Pour créer un ID unique basé sur plusieurs valeurs d’éléments, vous définissez plusieurs id instructions. Vous pouvez également construire des valeurs d’ID par rapport à la valeur du contenu. Pour obtenir des informations détaillées sur la création de valeurs d’ID, consultez La section Comprendre les opérateurs de test junos Snapshot Administrator.
Exemple : création du fichier de configuration Junos Snapshot Administrator
Cet exemple crée un fichier de configuration de base Junos Snapshot Administrator.
Exigences
Junos Snapshot Administrator Version 1.0 est installé sur le serveur.
Aperçu
Cet exemple crée un fichier de configuration Junos Snapshot Administrator avec une section de test nommée re0-master. La re0-master section test récupère et analyse la sortie XML de la commande show chassis routing-enginedu mode opérationnel Junos OS . Un exemple de la sortie XML d’un équipement double moteur de routage est illustré ici :
<route-engine-information xmlns="http://xml.juniper.net/junos/11.4R1/junos-chassis">
<route-engine>
<slot>0</slot>
<mastership-state>master</mastership-state>
<mastership-priority>master (default)</mastership-priority>
<status>OK</status>
<temperature junos:celsius="30">30 degrees C / 86 degrees F</temperature>
<cpu-temperature junos:celsius="27">
27 degrees C / 80 degrees F
</cpu-temperature>
<memory-dram-size>768</memory-dram-size>
<memory-buffer-utilization>48</memory-buffer-utilization>
<cpu-user>1</cpu-user>
<cpu-background>0</cpu-background>
<cpu-system>5</cpu-system>
<cpu-interrupt>1</cpu-interrupt>
<cpu-idle>94</cpu-idle>
<model>RE-5.0</model>
<serial-number>19995858810</serial-number>
<start-time junos:seconds="1337708989">
2012-05-22 10:49:49 PDT
</start-time>
<up-time junos:seconds="8735869">
101 days, 2 hours, 37 minutes, 49 seconds
</up-time>
<last-reboot-reason>
Router rebooted after a normal shutdown.
</last-reboot-reason>
<load-average-one>0.00</load-average-one>
<load-average-five>0.00</load-average-five>
<load-average-fifteen>0.00</load-average-fifteen>
</route-engine>
</route-engine-information>
Pour un équipement double moteur de routage, le cas de test vérifie la sortie XML pour déterminer si le moteur de routage de l’emplacement 0 est le moteur de routage principal. La section test utilise l’expression item route-engine[slot = '0'] pour sélectionner l’élément dont la route-engine valeur d’élément slot enfant est « 0 ». Le cas de test utilise l’opérateur is-equal de test pour comparer la valeur de l’élément mastership-state enfant avec la valeur de chaîne « maître ». Si le cas de test revient vrai, le moteur de routage de l’emplacement 0 est le moteur de routage principal. Si le cas de test renvoie false, le code signale deux déclarations d’erreur.
La section obligatoire do comprend les noms de toutes les sections de test qui doivent être exécutées lorsque Junos Snapshot Administrator fait référence à ce fichier de configuration. Dans cet exemple, la do section contient uniquement re0-master.
Configuration
La configuration de Junos Snapshot Administrator se compose d’une section obligatoire do et d’une ou plusieurs sections de test.
Comment configurer les sections de test
Procédure étape par étape
La configuration de Junos Snapshot Administrator se compose de sections de test qui définissent les commandes et les critères d’évaluation utilisés dans une comparaison d’instantanés ou de snapshots. Pour configurer une section de test :
Nommez la section de test à l’aide d’une chaîne unique et descriptive.
re0-master { ... }Ajoutez l’instruction
commandet spécifiez la commande du mode opérationnel Junos OS que le code exécute pour récupérer les données XML souhaitées.re0-master { command show chassis routing-engine; }Ajoutez l’instruction
iterateouitemsuivie de l’expression XPath qui sélectionne les éléments souhaités.re0-master { command show chassis routing-engine; item route-engine[slot = '0'] { } }Si la section test compare des éléments à partir de deux snapshots, ajoutez l’instruction
idspécifiant un ID unique pour mapper le premier élément de données d’instantané au deuxième élément de données d’instantané.Cet exemple ne nécessite pas d’énoncé
id.Créez la condition de cas de test utilisée lors de la vérification.
re0-master { command show chassis routing-engine; item route-engine[slot = '0'] { is-equal mastership-state, "master" { } } }Dans le bloc de code de cas de test, ajoutez l’instruction
infodécrivant le cas de test ou les conditions d’exploitation normales.re0-master { command show chassis routing-engine; item route-engine[slot = '0'] { is-equal mastership-state, "master" { info re0 is always master; } } }Dans le bloc de code de cas de test, ajoutez une ou plusieurs
errdéclarations qui sont exécutées en cas d’échec du cas de test.re0-master { command show chassis routing-engine; item route-engine[slot = '0'] { is-equal mastership-state, "master" { info re0 is always master; err " re0 is not master, rather %s", mastership-state; err " Correct so that re0 is the master!"; } } }
Comment configurer la section « do »
Procédure étape par étape
Le fichier de configuration Junos Snapshot Administrator doit commencer par un do bloc de code qui définit les sections de test à utiliser dans l’instantané.
Au début du fichier de configuration, ajoutez le bloc de
docode.do { }Ajoutez le nom de chaque section de test qui sera utilisée dans l’instantané.
do { re0-master; }
Résultats
do {
re0-master;
}
re0-master {
command show chassis routing-engine;
item route-engine[slot = '0'] {
is-equal mastership-state, "master" {
info re0 is always master;
err " re0 is not master, rather %s", mastership-state;
err " Correct so that re0 is the master!";
}
}
}