Sur cette page
Exemples de chargement d’une configuration à partir d’un fichier ou d’un terminal
Comment l’encodage de caractères fonctionne sur les équipements Juniper Networks
À propos de la spécification des déclarations et des identifiants
À propos du chargement d’une configuration à partir d’un fichier
Charger les données de configuration JSON avec des entrées de liste non ordonnées
Chargement des fichiers de configuration
Le chargement des fichiers de configuration sur l’équipement est utile pour charger des parties de fichiers de configuration qui peuvent être courantes sur de nombreux équipements au sein d’un réseau.
Exemples de chargement d’une configuration à partir d’un fichier ou d’un terminal
Vous pouvez créer un fichier contenant des données de configuration pour un équipement Juniper Networks, copier le fichier sur l’équipement local, puis le charger dans la CLI. Une fois le fichier chargé, vous pouvez le valider pour activer la configuration sur l’équipement, ou modifier la configuration de manière interactive à l’aide de l’interface CLI et valider la configuration ultérieurement.
Vous pouvez également créer une configuration tout en tapant au terminal, puis charger la configuration. Il est utile de charger une configuration à partir du terminal lorsque vous coupez des parties existantes de la configuration et que vous les collez ailleurs dans la configuration.
Pour charger un fichier de configuration existant situé sur l’équipement, vous utilisez la commande mode de load configuration :
[edit] user@host# load (factory-default | merge | override | patch | replace | set | update) filename <relative> <json>
Pour charger une configuration à partir du terminal, vous utilisez la version suivante de la commande du load mode de configuration. Appuyez sur Ctrl-d pour terminer l’entrée.
[edit] user@host# load (factory-default | merge | override | patch | replace | set | update) terminal <relative> <json>
Pour remplacer une configuration entière, vous spécifiez l’option override à n’importe quel niveau de la hiérarchie. Une load override opération remplace complètement la configuration de candidature actuelle par le fichier que vous chargez. Ainsi, si vous avez enregistré une configuration complète, vous utilisez cette option.
Une override opération élimine la configuration candidate actuelle et charge la configuration dans filename ou la configuration que vous saisissez au terminal. Lorsque vous utilisez l’option override et que vous validez la configuration, tous les processus système réparent la configuration.
Pour remplacer des parties d’une configuration, vous spécifiez l’option replace . L’opération load replace recherche replace: les balises que vous avez ajoutées au fichier chargé. L’opération remplace ensuite ces parties de la configuration du candidat par ce qui est spécifié après la balise. Cela est utile lorsque vous souhaitez plus de contrôle sur ce qui est en train d’être modifié. Pour que cette opération fonctionne, vous devez inclure des replace: balises dans le fichier ou la configuration que vous saisissez au niveau du terminal. Le logiciel recherche les replace: balises, supprime les déclarations existantes du même nom, le cas échéant, et les remplace par la configuration entrante. Si aucune déclaration du même nom n’existe, l’opération replace ajoute à la configuration les déclarations marquées avec la replace: balise.
Si, dans une override ou merge opération, vous spécifiez un fichier ou un texte qui contient replace: des balises, les replace: balises sont ignorées. Dans ce scénario, l’opération override ou merge prend la priorité et est exécutée.
Si vous effectuez une replace opération et si le fichier que vous spécifiez manque de replace: balises, l’opération s’exécute replace comme une merge opération. L’opération replace s’exécute également comme une merge opération si le texte que vous saisissez manque de replace: balises. Ces informations peuvent être utiles si vous exécutez des scripts automatisés et que vous ne pouvez pas savoir à l’avance si les scripts doivent effectuer une replace opération ou une merge opération. Les scripts peuvent utiliser l’opération replace pour couvrir les deux cas.
L’opération load merge fusionne la configuration du fichier ou du terminal enregistré avec la configuration du candidat existant. Ces informations sont utiles si vous ajoutez de nouvelles sections de configuration. Par exemple, supposons que vous ajoutiez une configuration BGP au niveau de la [edit protocols] hiérarchie, où il n’y avait pas de configuration BGP auparavant. Vous pouvez utiliser l’opération load merge pour combiner la configuration entrante avec la configuration du candidat existant. Si la configuration existante et la configuration entrante contiennent des instructions contradictoires, les instructions de la configuration entrante remplacent celles de la configuration existante.
Pour remplacer uniquement les parties de la configuration qui ont changé, vous spécifiez l’option update à n’importe quel niveau de la hiérarchie. L’opération load update compare la configuration du candidat et les nouvelles données de configuration. Cette opération ne modifie que les parties de la configuration du candidat qui sont différentes de la nouvelle configuration. Vous utiliserez cette opération, par exemple, s’il existe une configuration BGP existante et que le fichier que vous chargez la modifie d’une manière ou d’une autre.
Le merge, overrideet les update options prennent en charge le chargement des données de configuration au format JSON (JavaScript Object Notation). Lorsque vous chargez des données de configuration au format JSON, vous devez spécifier l’option json dans la commande. Pour charger les données de configuration JSON qui contiennent des entrées de liste non ordonnées, c’est-à-dire des entrées de liste dont la clé de liste n’est pas nécessairement le premier élément de l’entrée de liste, reportez-vous à la section Charger les données de configuration JSON avec des entrées de liste non ordonnées.
Pour modifier une partie de la configuration avec un fichier de correctif, vous spécifiez l’option patch . L’opération load patch charge un fichier ou une entrée de terminal qui contient les modifications de configuration. Tout d’abord, sur un équipement dont la configuration est déjà modifiée, vous saisissez la show | compare commande pour extraire les différences entre deux configurations. Vous pouvez ensuite charger les différences sur un autre équipement. L’avantage de la load patch commande est qu’elle vous évite d’avoir à copier des extraits de différents niveaux hiérarchiques dans un fichier texte avant de les charger dans l’équipement cible. Cela peut vous permettre de gagner du temps si vous configurez plusieurs équipements avec les mêmes options. Par exemple, supposons que vous configurez une stratégie de routage sur routeur1 et que vous souhaitiez répliquer la configuration de stratégie sur routeur2, routeur3 et routeur4. Vous pouvez utiliser l’opération load patch .
Dans cet exemple, vous exécutez d’abord la show | compare commande.
Exemple :
user@router1# show | compare rollback 3
[edit protocols ospf]
+ export default-static;
- export static-default
[edit policy-options]
+ policy-statement default-static {
+ from protocol static;
+ then accept;
+ }En continuant cet exemple, vous copiez la sortie de la show | compare commande dans le presse-papiers, en vous assurant d’inclure les niveaux hiérarchiques. Sur routeur2, routeur3 et routeur4, vous saisissez load patch terminal et collez la sortie. Vous appuyez ensuite sur Entrée et appuyez sur Ctrl-d pour mettre fin à l’opération. Si l’entrée de correctif spécifie des valeurs différentes pour une instruction existante, l’entrée de correctif remplace l’instruction existante.
Pour utiliser le merge, replace, setou update l’option sans spécifier le niveau hiérarchique complet, vous spécifiez l’option relative . Cette option charge la configuration entrante par rapport à votre point de modification actuel dans la hiérarchie de configuration.
Exemple :
[edit system]
user@host# show static-host-mapping
bob sysid 987.654.321ab
[edit system]
user@host# load replace terminal relative
[Type ^D at a new line to end input]
replace: static-host-mapping {
bob sysid 0123.456.789bc;
}
load complete
[edit system]
user@host# show static-host-mapping
bob sysid 0123.456.789bc;
Pour charger une configuration qui contient des set commandes de mode de configuration, spécifiez l’option set . Cette option exécute les instructions de configuration ligne par ligne dès qu’elles sont stockées dans un fichier ou à partir d’un terminal. Les instructions peuvent contenir n’importe quelle commande de mode de configuration, par setexemple , edit, exitet top.
Pour copier un fichier de configuration d’un autre système réseau vers le routeur local, vous pouvez utiliser les utilitaires SSH et Telnet, comme décrit dans l’Explorateur CLI.
Si vous travaillez dans un environnement de critères communs, des messages de journal système sont créés chaque fois qu’un secret attribut est modifié (par exemple, changement de mot de passe ou modification du secret partagé RADIUS). Ces modifications sont enregistrées lors des opérations de charge de configuration suivantes :
load merge load replace load override load update
Comment l’encodage de caractères fonctionne sur les équipements Juniper Networks
Les données de configuration de Junos OS et la sortie des commandes opérationnelles peuvent contenir des caractères non ASCII, qui sont en dehors du jeu de caractères ASCII 7 bits. Lors de l’affichage de données opérationnelles ou de configuration dans certains formats ou au sein d’un certain type de session, le logiciel s’échappe et code ces caractères. Le logiciel échappe ou encode les caractères à l’aide de la référence décimale UTF-8 équivalente.
La CLI tente d’afficher tous les caractères non ASCII dans les données de configuration produites au format texte, set ou JSON. La CLI tente également d’afficher ces caractères dans la sortie de commande produite au format texte. Dans les cas d’exception, l’interface CLI affiche la référence des caractères décimaux UTF-8 à la place. (Les cas d’exception incluent les données de configuration au format XML et la sortie de commande au format XML ou JSON,) Dans les sessions de protocole XML NETCONF et Junos, vous obtenez un résultat similaire si vous demandez des données de configuration ou une sortie de commande qui contient des caractères non ASCII. Dans ce cas, le serveur renvoie la référence décimale UTF-8 équivalente pour ces caractères pour tous les formats.
Par exemple, supposons que le compte d’utilisateur suivant, qui contient la petite lettre latine n avec un tilde (ñ), soit configuré sur l’équipement.
[edit] user@host# set system login user mariap class super-user uid 2007 full-name "Maria Peña"
Lorsque vous affichez la configuration obtenue au format texte, la CLI imprime le caractère correspondant.
[edit] user@host# show system login user mariap full-name "Maria Peña"; uid 2007; class super-user;
Lorsque vous affichez la configuration obtenue au format XML dans la CLI, le caractère ñ est mappé à la référence ñdécimale UTF-8 équivalente . Le même résultat se produit si vous affichez la configuration dans n’importe quel format dans une session de protocole NETCONF ou Junos XML.
[edit]
user@host# show system login user mariap | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/17.2R1/junos">
<configuration junos:changed-seconds="1494033077" junos:changed-localtime="2017-05-05 18:11:17 PDT">
<system>
<login>
<user>
<name>mariap</name>
<full-name>Maria Peña</full-name>
<uid>2007</uid>
<class>super-user</class>
</user>
</login>
</system>
</configuration>
<cli>
<banner>[edit]</banner>
</cli>
</rpc-reply>
Lorsque vous chargez des données de configuration sur un équipement, vous pouvez charger des caractères non ASCII à l’aide de leurs références décimales UTF-8 équivalentes.
À propos de la spécification des déclarations et des identifiants
Cette rubrique fournit des détails sur les instructions de conteneur CLI et les déclarations de branche afin que vous sachiez comment les spécifier lors de la création de fichiers de configuration ASCII. Cette rubrique décrit également comment l’interface cli vérifie les types pour vérifier que les données que vous avez saisies sont au bon format.
Spécification d’instructions
Les déclarations sont affichées de deux façons, soit avec des accolades ({ }) soit sans :
-
Nom et identifiant de l’énoncé, avec une ou plusieurs déclarations de niveau inférieur entourées d’accolades :
statement-name1 identifier-name { statement-name2; additional-statements; } -
Nom de l’énoncé, identifiant et un seul identifiant :
statement-name identifier-name1 identifier-name2;
C’est statement-name le nom de l’énoncé. Il identifier-name s’agit d’un nom ou d’une autre chaîne qui identifie de manière unique une instance d’une instruction. Vous utilisez un identifiant lorsqu’une instruction peut être spécifiée plus d’une fois dans une configuration.
Lorsque vous spécifiez une instruction, vous devez spécifier un nom d’instruction, un nom d’identifiant ou les deux, en fonction de la hiérarchie d’instruction.
Vous spécifiez des identifiants de l’une des manières suivantes :
-
identifier-nameidentifier-name: est un mot-clé utilisé pour identifier une déclaration de manière unique lorsqu’une déclaration peut être spécifiée plus d’une fois dans une instruction.
-
identifier-name valueidentifier-name: est un mot-clé, et la value est une variable d’option obligatoire.
-
identifier-name [value1 value2 value3
...]— Le identifier-name est un mot clé qui accepte plusieurs valeurs. Les crochets sont requis lorsque vous spécifiez un ensemble de valeurs ; toutefois, elles sont facultatives lorsque vous ne spécifiez qu’une seule valeur.
Les exemples suivants illustrent comment les déclarations et les identifiants sont spécifiés dans la configuration :
protocol { # Top-level statement (statement-name).
ospf { # Statement under "protocol" (statement-name).
area 0.0.0.0 { # OSPF area "0.0.0.0" (statement-name identifier-name),
interface so-0/0/0 { # which contains an interface named "so-0/0/0."
hello-interval 25; # Identifier and value (identifier-name value).
priority 2; # Identifier and value (identifier-name value).
disable; # Flag identifier (identifier-name).
}
interface so-0/0/1; # Another instance of "interface," named so-0/0/1,
} # this instance contains no data, so no braces
} # are displayed.
}
policy-options { # Top-level statement (statement-name).
term term1 { # Statement under "policy-options"
# (statement-name value).
from { # Statement under "term" (statement-name).
route-filter 10.0.0.0/8 orlonger reject; # One identifier ("route-filter") with
route-filter 127.0.0.0/8 orlonger reject; # multiple values.
route-filter 128.0.0.0/16 orlonger reject;
route-filter 149.20.64.0/24 orlonger reject;
route-filter 172.16.0.0/12 orlonger reject;
route-filter 191.255.0.0/16 orlonger reject;
}
then { # Statement under "term" (statement-name).
next term; # Identifier (identifier-name).
}
}
}
Lorsque vous créez un fichier de configuration ASCII, vous spécifiez des déclarations et des identifiants. Chaque instruction a un style préféré, et la CLI l’utilise lors de l’affichage de la configuration en réponse à une commande du mode show de configuration. Vous pouvez spécifier des déclarations et des identifiants de l’une des façons suivantes :
-
Déclaration suivie des identifiants :
statement-name identifier-name [...] identifier-name value [...];
-
Déclaration suivie des identifiants joints à des accolades :
statement-name { identifier-name; [...] identifier-name value; [...] } -
Pour certains identifiants répétitifs, vous pouvez utiliser un ensemble d’accolades pour toutes les déclarations :
statement-name { identifier-name value1; identifier-name value2; }
Vérification des types CLI
Lorsque vous spécifiez des identifiants et des valeurs, l’interface cli vérifie que les données que vous avez saisies sont au bon format. Par exemple, pour une déclaration dans laquelle vous devez spécifier une adresse IP, la CLI exige que vous saisissiez une adresse dans un format valide. Sinon, un message d’erreur indique ce que vous devez saisir. répertorie les types de données que l’interface cli vérifie. Les types d’entrée de configuration CLI suivants sont les suivants :
|
Type de données |
Format |
Exemples |
|---|---|---|
|
Nom de l’interface physique (utilisé dans la [ |
|
Correct: Incorrect: |
|
Nom complet de l’interface |
|
Correct: Incorrect: |
|
Nom complet ou abrégé de l’interface (utilisé dans des endroits autres que [ |
|
Correct: |
|
Adresse IP |
|
Correct: Sample translations:
|
|
Adresse IP (préfixe de destination) et longueur du préfixe |
|
Correct: Sample translations:
|
|
Adresse de l’Organisation internationale de normalisation (ISO) |
|
Correct: Sample translations:
|
|
Identifiant de zone OSPF (ID) |
|
Correct: Sample translations:
|
À propos du chargement d’une configuration à partir d’un fichier
Les exemples suivants illustrent le processus de chargement d’une configuration à partir d’un fichier.
Télécharger un fichier de configuration
Vous pouvez créer un fichier de configuration sur votre système local, copier le fichier sur l’équipement, puis le charger dans la CLI. Une fois le fichier de configuration chargé, vous pouvez le valider pour activer la configuration sur l’équipement. Vous pouvez également modifier la configuration de manière interactive à l’aide de la CLI et la valider ultérieurement.
Pour télécharger un fichier de configuration depuis votre système local :
Pour consulter les résultats des étapes de configuration avant de procéder à la validation de la configuration, saisissez la show commande à l’invite de l’utilisateur.
Pour valider ces modifications dans la configuration active, saisissez la commit commande à l’invite de l’utilisateur. Vous pouvez également modifier la configuration de manière interactive à l’aide de la CLI et la valider ultérieurement.
Charger les données de configuration JSON avec des entrées de liste non ordonnées
Le schéma Junos définit certains objets de configuration comme des listes. Dans les données de configuration JSON, une instance de liste est encodée sous la forme d’une paire nom/tableau, et les éléments du tableau sont des objets JSON. En règle générale, l’ordre des membres d’une entrée de liste en code JSON est arbitraire, car les objets JSON sont fondamentalement des collections de membres non ordonnées. Toutefois, le schéma Junos exige que les clés de liste précèdent les autres frères et sœurs d’une entrée de liste et apparaissent dans l’ordre spécifié par le schéma.
Par exemple, l’objet user au niveau de la [edit system login] hiérarchie est une liste où name est la clé de liste qui identifie chaque utilisateur de manière unique.
list user {
key name;
description "Username";
uses login-user-object;
}Dans les exemples de données de configuration suivants, la clé de liste (name) est le premier élément pour chaque utilisateur. Par défaut, lorsque vous chargez des données de configuration JSON, les équipements Junos exigent que les clés de liste précèdent les autres frères et soeurs d’une entrée de liste et apparaissent dans l’ordre spécifié par le schéma.
{
"configuration" : {
"system" : {
"login" : {
"user" : [
{
"name" : "operator",
"class" : "operator",
"uid" : 3001
},
{
"name" : "security-admin",
"class" : "super-user",
"uid" : 3002
}
]
}
}
}
}Les équipements Junos offrent deux options pour charger les données de configuration JSON qui contiennent des entrées de liste non ordonnées, c’est-à-dire des entrées de liste où la clé de liste n’est pas nécessairement le premier élément.
-
Utilisez la
request system convert-json-configurationcommande du mode opérationnel pour produire des données de configuration JSON avec des entrées de liste ordonnées avant de charger les données sur l’équipement. -
Configurez l’instruction
reorder-list-keysau niveau de la[edit system configuration input format json]hiérarchie. Après avoir configuré l’instruction, vous pouvez charger les données de configuration JSON avec des entrées de liste non ordonnées, et l’équipement réordonner les clés de liste comme requis par le schéma Junos pendant l’opération de charge.
Lorsque vous configurez l’instruction reorder-list-keys , l’analyse de la configuration peut prendre beaucoup plus de temps, en fonction de la taille de la configuration et du nombre de listes. Ainsi, pour les configurations de grande taille ou avec de nombreuses listes, nous recommandons d’utiliser la request system convert-json-configuration commande plutôt que l’instruction reorder-list-keys .
Par exemple, supposons que le user-data.json fichier contienne la configuration JSON suivante. Si vous essayiez de charger la configuration, l’équipement émettrait une erreur de charge car admin2 la clé name de liste n’est pas le premier élément de cette entrée de liste.
user@host> file show /var/tmp/user-data.json
{
"configuration" : {
"system" : {
"login" : {
"user" : [
{
"name" : "admin1",
"class" : "super-user",
"uid" : 3003
},
{
"class" : "super-user",
"name" : "admin2",
"uid" : 3004
}
]
}
}
}
}Si vous utilisez la request system convert-json-configuration commande avec le fichier précédent comme entrée, la commande génère le fichier de sortie spécifié avec les données de configuration JSON que l’équipement Junos peut analyser pendant l’opération de charge.
user@host> request system convert-json-configuration /var/tmp/user-data.json output-filename user-data-ordered.json
user@host> file show user-data-ordered.json
{
"configuration":{
"system":{
"login":{
"user":[
{
"name":"admin1",
"class":"super-user",
"uid":3003
},
{
"name":"admin2",
"class":"super-user",
"uid":3004
}
]
}
}
}
}Vous pouvez également configurer l’instruction de reorder-list-keys configuration.
user@host# set system configuration input format json reorder-list-keys user@host# commit
Après avoir configuré l’instruction, vous pouvez charger le fichier de configuration JSON d’origine avec des entrées de liste non ordonnées, et l’équipement gère les entrées de liste lorsqu’il analyse la configuration.
user@host# load merge json /var/tmp/user-data.json load complete