SUR CETTE PAGE
Modification de la configuration à l’aide d’un script d’événement
Vous pouvez configurer une stratégie d’événements pour modifier la configuration en réponse à un événement. Les stratégies d’événements peuvent modifier la configuration en appelant un script d’événement qui modifie et valide la configuration ou en utilisant l’instruction change-configuration pour exécuter des commandes de mode de configuration qui modifient la configuration. Les scripts d’événements offrent plus de flexibilité que l’instruction change-configuration lors de la modification de la configuration. Par exemple, les scripts d’événements vous permettent de vérifier des conditions spécifiques, de fournir les données de configuration dans différents formats et de spécifier comment fusionner les données avec la configuration existante. Dans certains cas, par exemple sur les équipements à double moteur de routage sur lesquels le routage actif ininterrompu (NSR) est activé, les stratégies d’événements ne peuvent utiliser que des scripts d’événements pour modifier la configuration.
Les sections suivantes traitent de l’utilisation de scripts d’événements pour modifier la configuration.
Comment modifier la configuration à l’aide d’un script d’événement SLAX ou XSLT
Les scripts d’événements SLAX et XSLT peuvent appeler le jcs:load-configuration modèle pour apporter des modifications structurées à la configuration de Junos OS. Vous devez établir une connexion avec l’équipement cible avant d’appeler le modèle pour modifier la configuration. Pour plus d’informations sur le modèle, consultez jcs :load-configuration et Modifier la configuration à l’aide de scripts SLAX et XSLT.
Le script d’événement SLAX suivant ouvre une connexion à l’équipement local, appelle le jcs:load-configuration modèle pour modifier et valider la configuration, puis ferme la connexion. Toutes les valeurs requises pour le jcs:load-configuration modèle sont définies en tant que variables, qui sont ensuite transmises au modèle en tant qu’arguments.
version 1.2;
ns junos = "http://xml.juniper.net/junos/*/junos";
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";
import "../import/junos.xsl";
match / {
<event-script-results> {
/* Open a connection to the local device */
var $connection = jcs:open();
/* Define configuration change */
var $configuration-change = <configuration> {
<routing-options> {
<static> {
<route> {
<name>"198.51.100.0/24";
<next-hop>"10.1.3.1";
}
}
}
}
/* Load and commit the configuration */
var $load-action = "merge";
var $options := {
<commit-options> {
<log> "Configuration modified through event script";
}
}
var $results := { call jcs:load-configuration($connection, $action=$load-action, $configuration=$configuration-change, $commit-options=$options); }
/* Close the connection */
var $close-results = jcs:close($connection);
}
}
Pour configurer une stratégie d’événements qui appelle le script d’événement SLAX pour un événement donné :
Comment modifier la configuration à l’aide d’un script d’événement Python
Les scripts Python peuvent utiliser la bibliothèque Junos PyEZ pour apporter des modifications à la configuration sur les périphériques exécutant Junos OS. L’utilitaire Junos PyEZ jnpr.junos.utils.config.Config fournit des méthodes d’instance pour verrouiller, charger, valider et déverrouiller la configuration.
Le script d’événement Python suivant se connecte à l’appareil local et met à jour et valide la configuration.
from jnpr.junos import Device
from jnpr.junos.utils.config import Config
import jcs
with Device() as dev:
with Config(dev) as cu:
cu.load("set routing-options static route 198.51.100.0/24 next-hop 10.1.3.1", format="set")
cu.commit(comment="Configuration modified through event script", timeout=300)
Pour configurer une stratégie d’événements qui appelle le script d’événement Python pour un événement donné :
Pour plus d’informations sur l’utilisation de Junos PyEZ pour configurer des périphériques exécutant Junos OS, reportez-vous au Guide du développeur Junos PyEZ.
Modification de la configuration à l’aide de scripts d’événements sur des appareils sur lesquels le routage actif en continu est activé
Lorsque vous utilisez une stratégie d’événements pour modifier la configuration d’un périphérique à double moteur de routage sur lequel le routage actif ininterrompu (NSR) est activé, nous vous recommandons d’appeler une stratégie d’événements qui valide la configuration mise à jour sur le moteur de routage principal uniquement. Cela permet de s’assurer que la mise à jour de la configuration et l’opération de validation suivante réussissent sur les deux moteurs de routage. La configuration est automatiquement synchronisée avec le moteur de routage de secours, car l’instruction commit synchronize est configurée au niveau de la [edit system] hiérarchie dans le cadre de la configuration NSR. Par ailleurs, si vous utilisez l’instruction change-configuration pour modifier la configuration, ou si le script d’événement ne valide pas la modification uniquement sur le moteur de routage principal, les deux moteurs de routage peuvent tenter simultanément d’acquérir un verrou sur la base de données de configuration, ce qui entraîne l’échec d’une ou des deux validations.
Pour créer un script d’événement qui configure et valide uniquement la configuration sur le moteur de routage principal, incluez une logique qui teste si le moteur de routage actuel est le moteur de routage principal. Si le moteur de routage actuel est le moteur de routage principal, mettez à jour la configuration et validez-la.
Le script d’événement SLAX suivant se connecte à l’équipement local et vérifie si le moteur de routage actuel est le moteur de routage principal. S’il s’agit du moteur de routage principal, le script met à jour la configuration, puis la valide.
version 1.2;
ns junos = "http://xml.juniper.net/junos/*/junos";
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";
import "../import/junos.xsl";
match / {
<event-script-results> {
/* Retrieve chassis information */
var $rpc = <get-chassis-inventory>;
var $chassis_rpc = jcs:invoke($rpc);
var $current_state = $chassis_rpc/chassis/name;
/* Open a connection to the local device */
var $connection = jcs:open();
/* Define configuration change */
var $configuration-change = <configuration> {
<routing-options> {
<static> {
<route> {
<name>"198.51.100.0/24";
<next-hop>"10.1.3.1";
}
}
}
}
/* Load and commit the configuration */
var $load-action = "merge";
var $options := {
<commit-options> {
<log> "Configuration modified through event script";
}
}
if ($current_state == "Chassis") {
var $results := { call jcs:load-configuration($connection, $action=$load-action, $configuration = $configuration-change, $commit-options=$options); }
}
/* Close the connection */
var $close-results = jcs:close($connection);
}
}
De même, le script d’événement Python suivant se connecte à l’appareil local et ne met à jour et valide la configuration que si le moteur de routage actuel est le moteur de routage principal :
from jnpr.junos import Device
from jnpr.junos.utils.config import Config
import jcs
with Device() as dev:
if("master" in dev.facts["current_re"]):
with Config(dev) as cu:
cu.load("set routing-options static route 198.51.100.0/24 next-hop 10.1.3.1", format="set")
cu.commit(comment="Configuration modified through event script", timeout=300)