Configuration de NETCONF/YANG pour les plates-formes Cisco IOS XE 16.X
Table des matières
Introduction
Ce document décrit comment configurer NETCONF/YANG sur les plates-formes basées sur Cisco IOS® XE 16.x.
Conditions préalables
Exigences
NETCONF/YANG est pris en charge par le logiciel Cisco IOS® XE 16.3.1.
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
Dans cet exemple, un commutateur autonome WS-C3850-12X48U exécutant Cisco IOS XE 16.3.3 est utilisé comme serveur NETCONF. Il s'agit du périphérique configuré et à partir duquel les données (sortie de la commande show) sont collectées via NETCONF/YANG.
Un ordinateur portable (Apple MacBook Pro exécutant macOS Sierra 10.12.2 et navigateur Google Chrome) est utilisé comme client NETCONF. Il agit en tant que plate-forme de gestion centralisée et utilise l'application Yang Explorer. C'est le périphérique qui crée les requêtes formatées YANG qui sont envoyées au Catalyst 3850 via les messages NETCONF RPC (Remote Procedure Call) pour configurer et collecter des données du Catalyst 3850.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
L'exemple donné dans ce document se concentre sur les tests en laboratoire avec le Catalyst 3850, cependant, les informations fournies s'appliquent également à d'autres plates-formes Cisco IOS XE 16.x telles que les routeurs de la gamme Cisco ASR 1000.
Modèles de données - Configuration et surveillance programmatiques et normalisées
Les modèles de données offrent un moyen différent et centralisé de configurer les périphériques Cisco (au lieu d’utiliser l’interface de commande en ligne ou le protocole SNMP [Simple Network Management Protocol]) et de recueillir des données opérationnelles (afficher les commandes) des périphériques Cisco. Étant donné que les modèles de données sont des normes basées sur la même procédure et qu'ils peuvent également être utilisés pour configurer ou collecter des données à partir de périphériques non Cisco, ils sont idéaux pour les clients qui prennent en charge plusieurs fournisseurs. Une plate-forme de gestion centralisée (par exemple, un ordinateur portable) peut être utilisée pour configurer ou collecter des données à partir de plusieurs périphériques Cisco et l'architecture de modèle de données permet d'automatiser ces procédures via un script Python (deux avantages clés supplémentaires).
Un autre langage de modélisation de données de nouvelle génération (YANG) (RFC 6020)
YANG est un langage de modélisation de données basé sur des normes utilisé pour créer des demandes de configuration de périphérique ou des demandes de données opérationnelles (afficher la commande). Il a un format structuré semblable à un programme informatique qui est lisible par l’homme. Plusieurs applications sont disponibles et peuvent être exécutées sur une plate-forme de gestion centralisée (par exemple, un ordinateur portable) pour créer ces demandes de configuration et de données opérationnelles.
Il existe à la fois des modèles de données YANG standard (communs) qui s'appliquent à tous les fournisseurs (par exemple, une demande de désactivation ou d'arrêt d'une interface Ethernet peut être identique pour les périphériques Cisco et non Cisco) et des modèles de données de périphériques (natifs, spécifiques au fournisseur) qui facilitent la configuration ou la collecte de données opérationnelles associées aux fonctionnalités propriétaires du fournisseur.
Protocole de configuration réseau (NETCONF) (RFC 6241)
NETCONF est un protocole standard codé en langage XML (Extensible Markup Language) qui fournit le transport permettant de communiquer la demande de données opérationnelles ou de configuration formatée YANG d'une application qui s'exécute sur une plate-forme de gestion centralisée (par exemple, un ordinateur portable) au périphérique Cisco à partir duquel un utilisateur souhaite configurer ou demander des données opérationnelles (commande show). Il fournit des services basés sur les transactions, tels que l’abandon de la demande de configuration complète lorsqu’une partie de cette demande de configuration échoue. NETCONF utilise un mécanisme simple d’appel de procédure à distance (RPF) pour faciliter la communication entre un client (script ou application de plateforme de gestion centralisée) et un serveur (commutateur ou routeur Cisco). Il utilise Secure Shell (SSH) comme couche de transport entre les périphériques réseau. Certaines opérations NETCONF comprennent get, get-config, edit-config et rpc.
Configurer
1. Configuration de base d'un Catalyst 3850 exécutant le logiciel Cisco XE 16.3.3 pour prendre en charge la modélisation de données NETCONF/YANG
3850-1# show running-config
netconf-yang -------------------------------------> Enable NETCONF/YANG globally. It may take up to 90 seconds to initialize
username cisco1 privilege 15 password 0 cisco1 ---> Username/password used for NETCONF-SSH access
aaa new-model
aaa authorization exec default local -------------> Required for NETCONF-SSH connectivity and edit-config operations
2. Configuration supplémentaire (facultative) pour permettre la surveillance des événements NETCONF/YANG Syslog et SNMP
Ces configurations de serveur SNMP doivent être présentes afin d'activer la génération de notifications NETCONF (RFC 5277 - Tools 5277) pour les messages Syslog et pour toutes les interruptions SNMP configurées pour générer également des notifications NETCONF.
Remarque : bien que ces paramètres soient le minimum requis, des entrées snmp-server enable supplémentaires peuvent également être présentes. Un client (plate-forme de gestion centralisée) s'enregistre pour recevoir le flux de notification NETCONF d'un serveur (Catalyst 3850) et envoyer un abonnement spécifique RPC (voir la section 3 de Configuration de la plate-forme de gestion centralisée (ordinateur portable)).
3850-1# show running-config
snmp-server community <string> RW ------------------------------> SNMP gateway in DMI requires community public prior to 16.5.1. A configurable community is supported on 16.5.1 and later.
netconf-yang cisco-ia snmp-community-string <string> -----------> Configure the same community string to enable SNMP MIB access for both NETCONF and RESTCONF.
snmp-server trap link ietf -------------------------------------> enable traps for IETF link up/down
snmp-server enable traps snmp authentication linkdown linkup ---> enable traps for link up/down
snmp-server enable traps syslog --------------------------------> enable traps for Syslog so notifications can be generated
snmp-server manager --------------------------------------------> enable snmp-server
Pour Syslog, cette configuration doit être présente pour que l'interface DMI (Data Model Interface) sur le Catalyst 3850 puisse générer des notifications NETCONF définies dans la RFC 5277 lorsque des messages Syslog sont générés par Cisco sur le Catalyst 3850.
logging history debugging -------> required for the generation of any NETCONF notification messages for Syslog
logging snmp-trap emergencies ---> configure 1 or more of the following to control which levels of Syslog messages are returned as notifications
logging snmp-trap alerts
logging snmp-trap critical
logging snmp-trap errors
logging snmp-trap warnings
logging snmp-trap notifications
logging snmp-trap informational
logging snmp-trap debugging
Pour les alertes SNMP, cette configuration est nécessaire pour générer des notifications NETCONF. Dans le logiciel Cisco XE 16.3.1, un maximum de 10 déroutements SNMP peuvent être configurés pour générer des notifications NETCONF, mais cette restriction peut être supprimée dans une version ultérieure. La génération de notification pour les alertes SNMP est activée par défaut. Pour désactiver la génération de notifications de déroutement SNMP, utilisez cette CLI, no netconf-yang cisco-ia snmp-trap-control global-forwarding.
netconf-yang cisco-ia snmp-trap-control trap-list 10.3.6.1.6.3.1.1.5.3 --------> LinkDown trap
netconf-yang cisco-ia snmp-trap-control trap-list 10.3.6.1.6.3.1.1.5.4 --------> LinkUp trap
netconf-yang cisco-ia snmp-trap-control trap-list 10.3.6.1.4.1.9.9.41.2.0.1 ---> Syslog generated notification trap
3. Configuration de la connectivité réseau du Catalyst 3850 utilisé dans cet exemple
Dans cet exemple, l’interface de gestion GigabitEthernet0/0 du Catalyst 3850 est utilisée pour se connecter au réseau et à la plate-forme de gestion centralisée (un ordinateur portable peut être utilisé). Le protocole DHCP (Dynamic Host Configuration Protocol) a été utilisé pour attribuer une adresse IP 172.16.167.175 à cette interface. D’autres configurations peuvent être utilisées sur le commutateur Catalyst 3850 tant que l’ordinateur portable peut l’atteindre sur le réseau.
3850-1# show running-config
vrf definition Mgmt-vrf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
interface GigabitEthernet0/0
vrf forwarding Mgmt-vrf
ip address dhcp
negotiation auto
ip route vrf Mgmt-vrf 0.0.0.0 0.0.0.0 172.16.167.161
3850-1# show ip interface brief
Interface IP-Address OK? Method Status Protocol
Vlan1 10.1.1.1 YES NVRAM up up
Vlan10 10.10.10.1 YES NVRAM up up
Vlan20 10.20.20.1 YES NVRAM up up
GigabitEthernet0/0 172.16.167.175 YES DHCP up up
Fo1/1/1 unassigned YES unset down down
Fo1/1/2 unassigned YES unset down down
GigabitEthernet1/0/1 unassigned YES manual up up
GigabitEthernet1/0/2 unassigned YES unset up up
GigabitEthernet1/0/3 unassigned YES unset down down
GigabitEthernet1/0/4 unassigned YES unset down down
GigabitEthernet1/0/5 unassigned YES unset down down
Vérifiez NETCONF/YANG sur le Catalyst 3850
1. À partir de l’interface de ligne de commande (CLI) du Catalyst 3850, cette commande peut être utilisée pour s’assurer que les processus logiciels requis pour prendre en charge l’interface de modèle de données (DMI) sur le Catalyst 3850 s’exécutent une fois que netconf-yang est configuré.
3850-1# show platform software yang-management process
confd : Running
nesd : Running
syncfd : Running
ncsshd : Running
dmiauthd : Running
vtyserverutild : Running
opdatamgrd : Running
ngnix : Running
Les prochaines étapes sont effectuées à partir de la plateforme de gestion centralisée. Dans cet exemple, un ordinateur portable (Apple MacBook Pro exécutant macOS Sierra 10.12.2) est utilisé et dispose d’un accès réseau au Catalyst 3850. Les commandes sont émises à partir d’une invite de terminal sur l’ordinateur portable. Aucune application spéciale n’est chargée sur l’ordinateur portable à ce stade.
2. Assurez-vous que la plate-forme de gestion centralisée (ordinateur portable) peut atteindre le Catalyst 3850 (172.16.167.175) sur le réseau.
USER1-M-902T:~ USER1$ ping 172.16.167.175
PING 172.16.167.175 (172.16.167.175): 56 data bytes
64 bytes from 172.16.167.175: icmp_seq=0 ttl=247 time=3.912 ms
64 bytes from 172.16.167.175: icmp_seq=1 ttl=247 time=6.917 ms
64 bytes from 172.16.167.175: icmp_seq=2 ttl=247 time=4.063 ms
64 bytes from 172.16.167.175: icmp_seq=3 ttl=247 time=4.371 ms
^C
3. Vérifiez la connectivité SSH au Catalyst 3850 (172.167.175 dans cet exemple) à partir de la plate-forme de gestion centralisée (ordinateur portable) avec le nom d'utilisateur et le mot de passe (cisco1/cisco1) de cette configuration Catalyst 3850. La réponse peut être une longue liste de fonctionnalités NETCONF du Catalyst 3850, suivie d’un message Hello. Port TCP 830 = netconf-ssh.
USER1-M-902T:~ USER1$ ssh -s cisco1@172.16.167.175 -p 830 netconf
cisco1@172.16.167.175’s password: cisco1
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability
--snip--
</capabilities>
<session-id>2870</session-id></ hello>]]>]]>
Use < ^C > to exit
Configurez la plateforme de gestion centralisée (ordinateur portable)
1. Installer l'application Yang Explorer sur un ordinateur portable
Dans cet exemple, l’application Yang Explorer est utilisée sur un ordinateur portable (Apple MacBook Pro exécutant macOS Sierra 10.12.2, navigateur Google Chrome) pour servir de plateforme de gestion centralisée. Yang Explorer permet à l’utilisateur de faire ce qui suit :
• Charger/compiler des modèles de données YANG à partir de l’interface utilisateur ou de la ligne de commande
• Créer des appels RPC NETCONF (appels de procédure à distance)
• Exécuter les appels RPC sur un serveur NETCONF réel (Catalyst 3850)
• Enregistrer les appels RPC créés dans les collections pour une utilisation ultérieure
• Parcourir les arborescences de modèles de données et inspecter les propriétés YANG
2. Utiliser l'application Yang Explorer
Lancez l'application Yang Explorer - à partir d'une invite de terminal sur l'ordinateur portable, exécutez la commande ./start.sh et à partir du répertoire yang-explorer.
USER1-M-902T:~ USER1$ cd yang-explorer
USER1-M-902T:yang-explorer USER1$ ./start.sh &
Starting YangExplorer server ..
Use http://localhost:8088/static/YangExplorer.html
Performing system checks...
System check identified no issues (0 silenced).
January 19, 2017 - 23:12:20
Django version 1.8.3, using settings 'server.settings'
Starting development server at http://localhost:8088/
Quit the server with CONTROL-C.
Lancez l'interface graphique de Yang Explorer - Lancez l'interface graphique de l'application Yang Explorer et connectez-vous à l'interface graphique de l'application Yang Explorer en tant qu'invité/invité dans le coin supérieur droit du menu principal de l'interface graphique de l'application (reportez-vous à la capture d'écran).
Récupérez des fonctionnalités à partir du Catalyst 3850. Entrez les détails du Catalyst 3850 (adresse IP, nom d'utilisateur/mot de passe, port TCP 830 pour ssh-netconf) et cliquez sur Capabilities pour récupérer la liste des capacités opérationnelles YANG du logiciel Catalyst 3850.
Chargez les modèles de données Yang – Vous pouvez vous abonner à divers modèles de données YANG sous Manage Models (gérer les modèles). Une fois inscrits, ils s’affichent dans la zone Explorer à gauche. Ces modèles YANG permettent à l’application Yang Explorer de créer des messages d’appels RPC (NETCONF Remote Procedure Calls) au format YANG (qui sont envoyés au commutateur Catalyst 3850 pour le configurer ou récupérer des données à partir de celui-ci) sans devoir posséder une expertise YANG approfondie. Des exemples de la façon de le faire sont présentés dans la section suivante Basic NETCONF/YANG Operational
Exemples:
3. Abonnez-vous aux notifications NETCONF (facultatif)
Un client (plateforme de gestion centralisée) s’enregistre pour recevoir les flux de notification NETCONF d’un serveur (Catalyst 3850) en envoyant ce message d’appel RPC NETCONF au format YANG. Le commutateur Catalyst 3850 envoie des notifications NETCONF de manière asynchrone à chaque client qui s’abonne. Avant de terminer cette tâche, assurez-vous que la bonne configuration est en place sur le commutateur Catalyst 3850 pour prendre en charge les notifications NETCONF (voir section 2) de Configuration de NETCONF/YANG sur le commutateur Catalyst 3850. Le serveur NETCONF (Catalyst 3850) commence à envoyer les notifications d’événements au client NETCONF (plateforme de gestion centralisée) au fur et à mesure que les événements se produisent dans le système. Ces notifications d'événements peuvent continuer à être envoyées jusqu'à la fin de la session NETCONF ou jusqu'à la fin de l'abonnement pour une autre raison. Voir RFC 5277 pour plus de détails sur les options d'abonnement Outils 5277.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>snmpevents</stream>
</create-subscription>
</rpc>
Pour ce faire, vous devez le couper et le coller dans l'interface utilisateur graphique de l'application Yang Explorer en tant que RPC personnalisé.
Ensuite, Run (exécuter) est sélectionné afin d’envoyer le message d’appel RPC personnalisé au commutateur Catalyst 3850 au moyen de NETCONF. Le commutateur Catalyst 3850 répond par un message OK pour informer l’utilisateur que l’opération a réussi.
Exemples opérationnels de base NETCONF/YANG
Maintenant que le Catalyst 3850 et la plate-forme de gestion centralisée sont configurés et ont commencé à communiquer, examinons quelques exemples opérationnels de base.
Les exemples peuvent démontrer que les messages RPC NETCONF formatés YANG envoyés via NETCONF depuis l'application d'exploration Yang de la plate-forme de gestion centralisée (ordinateur portable) vers le Catalyst 3850 sont convertis en CLI Cisco IOS standard par le processus logiciel confd sur le Catalyst 3850. De plus, les données de l’interface de commande en ligne Cisco IOS (show command data) sont converties en données au format YANG par le processus logiciel confd sur le commutateur Catalyst 3850 avant d’être envoyées en tant que message d’appel RPC NETCONF à l’application Yang Explorer de la plateforme de gestion centralisée (ordinateur portable). Cela signifie que l’interface de commande en ligne régulière peut toujours être utilisée sur le commutateur Catalyst 3850 pour le configurer et recueillir les données d’affichage de la commande en plus d’utiliser NETCONF/YANG pour faire de même.
1. Exemple de récupération de données
Demandez une liste de noms d’interface auprès du commutateur Catalyst 3850
L’opération souhaitée peut être sélectionnée dans la section Explorer du côté gauche de l’interface graphique utilisateur de l’application Yang Explorer. Dans ce cas, les données de nom d’interface doivent être extraites du commutateur Catalyst 3850 et donc Oper (pour « opérations ») est sélectionné, suivi de get-config dans la liste déroulante du nom de l’interface. RPC est ensuite sélectionné afin de générer l’appel RPC NETCONF au format YANG (lisible par un humain) qui doit être envoyé au commutateur Catalyst 3850 au moyen de NETCONF afin de récupérer ces données du commutateur.
Une fois que le message d’appel RPC NETCONF au format YANG est généré, Run (exécuter) est sélectionné afin de l’envoyer au commutateur Catalyst 3850. Le Catalyst 3850 répond avec une liste formatée YANG (lisible par l'utilisateur) des noms d'interface du Catalyst 3850 (GigabitEthernet1/1/1, GigabitEthernet1/1/2, etc.).
2. Exemple de configuration
Mettez hors tension une interface Ethernet sur le commutateur Catalyst 3850
L’opération souhaitée est sélectionnée dans la section Explorer du côté gauche de l’interface graphique utilisateur de l’application Yang Explorer. Dans ce cas, pour configurer une interface (arrêt d'une interface) est nécessaire sur le Catalyst 3850 et donc Config (pour la configuration) est sélectionné, suivi des paramètres opérationnels requis sous les menus déroulants de l'interface. RPC est ensuite sélectionné afin de générer l’appel RPC NETCONF au format YANG (lisible par un humain) qui doit être envoyé au commutateur Catalyst 3850 au moyen de NETCONF afin d’exécuter la tâche de configuration.
Une fois que le message d’appel RPC NETCONF au format YANG est généré, Run (exécuter) est sélectionné afin de l’envoyer au commutateur Catalyst 3850. Le commutateur Catalyst 3850 répond par un message au format YANG (lisible par un humain) indiquant que l’opération de configuration a réussi (ok).
Afin de confirmer que la modification a eu lieu, la configuration peut être vérifiée. Une opération get-config (Oper) peut être utilisée lorsque le Catalyst 3850 répond que la configuration de l'interface GigabitEthernet 1/0/16 a activé = false maintenant, ce qui signifie que l'interface a été arrêtée.
Une fois que le message d’appel RPC NETCONF au format YANG est généré, Run (exécuter) est sélectionné afin de l’envoyer au commutateur Catalyst 3850. Le commutateur Catalyst 3850 répond par un message au format YANG qui indique que la configuration de l’interface GigabitEthernet 1/0/16 indique « enabled = false » (activé = faux), ce qui signifie que l’interface a été fermée.
Affichage de la configuration d’interface en ligne de commande du Catalyst 3850 avant et après la modification de configuration NETCONF/YANG précédente
Lors de la précédente opération de modification de la configuration de Yang Explorer, celle-ci était émise par l’interface de commande en ligne du commutateur Catalyst 3850. L’interface GigabitEthernet 1/0/16 était dans l’état par défaut « no shutdown » (aucun arrêt) jusqu’à ce que le message d’appel RPC NETCONF soit reçu, comme indiqué dans le message de journal sur le commutateur Catalyst 3850. Après réception du message d’appel RPC NETCONF contenant la demande au format YANG pour fermer l’interface, l’opération est terminée, l’interface est arrêtée et la configuration en cours est modifiée pour refléter cela. Cela montre également comment le processus logiciel confd sur le commutateur Catalyst 3850 convertit le message d’appel RPC NETCONF reçu en interface de commande en ligne IOS Cisco standard. Cela signifie qu’un utilisateur peut toujours utiliser l’interface de commande en ligne de Cisco IOS pour modifier la configuration et exécuter l’affichage des commandes en plus d’utiliser NETCONF/YANG pour faire de même.
3850-1# show running-config interface gigabitEthernet 1/0/16
Building configuration...
Current configuration : 39 bytes
!
interface GigabitEthernet1/0/16
end
3850-1# show startup-config | begin 1/0/16
interface GigabitEthernet1/0/16
!
*Jan 5 17:05:55.345: %DMI-5-CONFIG_I:Switch 1 R0/0: nesd: Configured from NETCONF/RESTCONF by cisco1, transaction-id 31332
*Jan 5 17:05:57.335: %LINK-5-CHANGED: Interface GigabitEthernet1/0/16, changed state to administratively down
3850-1# show running-config interface gigabitEthernet 1/0/16
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/16
shutdown -------------------------> the interface is shutdown now
end
3850-1#
3850-1# show startup-config | begin 1/0/16
interface GigabitEthernet1/0/16
!
Enregistrez la configuration sur un commutateur Catalyst 3850
La configuration en cours peut être enregistrée dans la configuration de démarrage du commutateur Catalyst 3850 en envoyant ce message d’appel RPC NETCONF au format YANG au Catalyst 3850 au moyen de NETCONF.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:save-config xmlns:cisco-ia="cisco/yang/cisco-ia"
</rpc>
Vous pouvez le faire en copiant-collant ceci dans l’application Yang Explorer en tant qu’appel RPC personnalisé.
Run (exécuter) est sélectionné afin d’envoyer le message d’appel RPC personnalisé au commutateur Catalyst 3850 au moyen de NETCONF. Le commutateur Catalyst 3850 répond par un message de réussite.
Affichage de la configuration de démarrage enregistrée après l'opération d'enregistrement de la configuration NETCONF/YANG précédente dans l'interface de ligne de commande du Catalyst 3850
La configuration de démarrage correspond maintenant à la configuration exécutée :
3850-1# show running-config interface gigabitEthernet 1/0/16
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/16
shutdown
end
3850-1# show startup-config | begin 1/0/16
interface GigabitEthernet1/0/16
shutdown
!
Configurez le commutateur Catalyst 3850 à partir de l’interface de commande en ligne
Comme mentionné précédemment, l’interface de commande en ligne régulière du commutateur Catalyst 3850 peut toujours être utilisée pour configurer le commutateur et recueillir les données d’affichage de commandes en plus d’utiliser NETCONF/YANG pour faire de même. Lorsque l'interface de ligne de commande du Catalyst 3850 est utilisée à la place de NETCONF/YANG pour configurer le commutateur, la nouvelle configuration en cours est synchronisée avec l'interface DMI (Data Model Interface) du Catalyst 3850 via le processus logiciel syncfd.
3850-1# show running-config interface gigabitEthernet 1/0/16
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/16
shutdown
end
3850-1# config t
Enter configuration commands, one per line. End with CNTL/Z.
3850-1(config)# interface gigabitEthernet 1/0/16
3850-1(config-if)#no shutdown
3850-1(config-if)# exit
3850-1(config)# exit
3850-1#
*Jan 24 16:39:09.968: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/16, changed state to down
*Jan 24 16:39:13.479: %SYS-5-CONFIG_I: Configured from console by console
*Jan 24 16:39:15.208: %DMI-5-SYNC_START:Switch 1 R0/0: syncfd: External change to running configuration detected. The running configuration can be synchronized to the DMI data store.
*Jan 24 16:39:43.290: %DMI-5-SYNC_COMPLETE:Switch 1 R0/0: syncfd: The running configuration has been synchronized to the DMI data store.
3850-1#
La prochaine fois que l’application Yang Explorer demande une copie de la configuration de l’interface après la modification de l’interface de commande en ligne, la modification est reflétée correctement dans la sortie YANG.
Run (exécuter) est sélectionné afin d’envoyer le message d’appel RPC get-config pour GigabitEthernet1/0/16 au commutateur Catalyst 3850 via NETCONF. Le commutateur Catalyst 3850 répond par la configuration d’interface GigabitEthernet1/0/16 indiquant « enabled = true » (activé = vrai).
3. Vérifiez les données opérationnelles SNMP MIB disponibles via les opérations de requête GET
Les données MIB SNMP qui peuvent être retournées avec les opérations NETCONF GET ne sont pas configurables par l’utilisateur. Toutes les MIB SNMP prises en charge qui sont converties en données structurées définies par les modèles de données YANG font partie du logiciel Cisco XE sur le Catalyst 3850. Trois options permettent de déterminer les données MIB disponibles dans les requêtes GET. Toutes les MIB prises en charge peuvent inclure smiv2 dans la réponse de capacité.
Option 1. Le bouton Capabilities (capacités) peut être sélectionné dans l’interface graphique utilisateur de l’application Yang Explorer. Le commutateur Catalyst 3850 répond avec sa liste de capacités qui contient des entrées smiv2 MIB.
Option 2. Ce message d’appel RPC NETCONF au format YANG peut être envoyé au commutateur Catalyst 3850 au moyen de NETCONF afin de récupérer la liste des capacités qui comprend les modèles de MIB smiv2 disponibles.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<get>
<filter type="subtree">
<ncm:netconf-state xmlns:ncm="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<ncm:capabilities/>
</ncm:netconf-state>
</filter>
</get>
</rpc>
Vous pouvez le faire en la copiant-collant dans l’application Yang Explorer en tant qu’appel RPC personnalisé.
Run (exécuter) est sélectionné afin d’envoyer le message d’appel RPC personnalisé au commutateur Catalyst 3850 au moyen de NETCONF. Le commutateur Catalyst 3850 répond par une liste de capacités qui comprend les MIB smiv2 prises en charge.
Option 3. Une liste des modèles MIB disponibles peut être affichée dans les fonctionnalités NETCONF et le message Hello renvoyé par le Catalyst 3850 en réponse à une connexion SSH de la plate-forme de gestion centralisée (ordinateur portable).
USER1-M-902T:~ USER1$ ssh -s cisco1@172.16.167.175 -p 830 netconf
cisco1@172.16.167.175’s password: cisco1
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability
--snip--
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CONFIG-MAN-MIB?module=CISCO-CONFIG-MAN-MIB&revision=2007-04-27</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CONTEXT-MAPPING-MIB?module=CISCO-CONTEXT-MAPPING-MIB&revision=2008-11-22</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-DATA-COLLECTION-MIB?module=CISCO-DATA-COLLECTION-MIB&revision=2002-10-30</capability>
--snip--
</capabilities>
<session-id>2870</session-id></ hello >]]>]]>
Use < ^C > to exit
Chargez des modèles de données YANG supplémentaires
Ce lien contient des fichiers de modèles de données YANG supplémentaires. Ces fichiers permettent l'exécution d'opérations supplémentaires via NETCONF/YANG qui se rapportent à d'autres fonctionnalités du Catalyst 3850, telles que la configuration du routage de monodiffusion IPv4, la qualité de service, etc.
Les modèles standard (standard, IETF (Internet Engineering Task Force)) qui s'appliquent à tous les fournisseurs peuvent être trouvés en choisissant standard, ietf, rfc. Cela fournit les modèles de données YANG basés sur des normes tirés de publications RFC par l’organisme de normalisation IETF.
GitHub Yang Modèles Tree Master Standard
Les modèles natifs de Cisco (spécifiques au périphérique, au fournisseur) peuvent être trouvés en sélectionnant vendor (fournisseur), cisco, xe, 1632. Cela fournit les modèles de données propriétaires YANG pour la version 16.3.2 du logiciel Cisco IOS XE pour le commutateur Catalyst 3850.
GitHub Yang Modèles Yang Tree Master Vendor
Ces fichiers peuvent être téléchargés sur la plate-forme de gestion centralisée (ordinateur portable), puis à leur tour chargés dans l'application Yang Explorer. Il existe deux façons de procéder. La première est de charger les différents fichiers de modèle de données YANG individuellement, la seconde est de charger en bloc tous les fichiers.
1. Charger les différents fichiers de modèles de données YANG individuellement
Dans cet exemple, cisco-ethernet.yang a déjà été téléchargé depuis github sur la plate-forme de gestion centralisée (ordinateur portable). Voici les étapes à suivre pour charger le fichier dans l’interface graphique utilisateur de l’application Yang Explorer, puis s’abonner à celui-ci pour qu’il soit chargé dans la section Explorer de l’outil.
2. Chargement en masse de tous les fichiers du modèle de données YANG en une seule fois
Cette procédure est également mentionnée dans la section 5.2.2 ici : github.
À partir d’une invite de terminal sur la plateforme de gestion centralisée (ordinateur portable – Apple MacBook Pro exécutant macOS Sierra 10.12.2) :
USER1-M-902T:~ USER1$ cd yang-explorer
USER1-M-902T:yang-explorer USER1$ cd server
USER1-M-902T:server USER1$ python manage.py bulkupload --user guest --git https://github.com/YangModels/yang.git --dir vendor/cisco/xe/1632
Git upload ..
Cloning into '/Users/USER1/yang-explorer/server/data/session/tmpk7V4O6'...
remote: Counting objects: 5610, done.
remote: Total 5610 (delta 0), reused 0 (delta 0), pack-reused 5610
Receiving objects: 100% (5610/5610), 11.80 MiB | 2.34 MiB/s, done.
Resolving deltas: 100% (3159/3159), done.
Checking out files: 100% (3529/3529), done.
Cleaning up /Users/USER1/yang-explorer/server/data/session/tmpk7V4O6
Compiling : user: guest, file: /Users/USER1/yang-explorer/server/data/session/tmpHTAEP3/cisco-acl-oper.yang
DEBUG:root:Compiling session dependency ...
//anaconda/bin/pyang
DEBUG:root:Rebuilding dependencies for user guest
--snip--
Tous les modèles de données Yang sont maintenant visibles dans l’interface graphique utilisateur de l’application Yang Explorer. Les fichiers associés aux fonctionnalités qui vous intéressent peuvent être sélectionnés lorsque vous cliquez sur Subscribe (s’abonner), ce qui les ajoute à la section Explorer de l’outil.
D’autres tâches peuvent maintenant être effectuées, comme générer l’appel RPC NETCONF/YANG requis pour enregistrer la configuration sur le commutateur Catalyst 3850. Cela se fait lorsque vous sélectionnez l’appel RPC save-conf dans la section Explorer sur le côté gauche de l’application Yang Explorer. Ensuite, RPC est sélectionné pour générer le YANG formaté NETCONF RPC qui peut être envoyé au Catalyst 3850 via NETCONF pour enregistrer la configuration sur le Catalyst 3850.
Run (exécuter) est sélectionné afin d’envoyer le message d’appel RPC personnalisé au commutateur Catalyst 3850 au moyen de NETCONF. Le commutateur Catalyst 3850 répond par un message de réussite.
Modèles de données YANG notables
Modèle de données cisco-ia.yang
Voici quelques exemples d’appels RPC pour le modèle de données cisco-ia.yang. Ils sont remarquables car ils impliquent des opérations telles que l'enregistrement de la configuration du Catalyst 3850, la synchronisation de la configuration en cours du Catalyst 3850 avec le magasin de données DMI (Data Model Interface) local, et la réinitialisation de l'interface DMI sur le Catalyst 3850.
La première étape consiste à vous abonner au modèle de données cisco-ia.yang pour qu’il s’affiche dans la section Explorer à gauche de l’interface graphique utilisateur du YANG Explorer.
Une fois le modèle de données Cisco-IA développé dans la section Explorer à gauche de l'interface utilisateur graphique de l'application YANG Explorer, les différentes options opérationnelles sont affichées. Par exemple, pour utiliser l'une des options disponibles du modèle de données cisco-ia.yang, l'opération save-config est sélectionnée et le RPC associé est généré lorsque vous sélectionnez le bouton RPC.
Ensuite, Run (exécuter) est sélectionné afin d’envoyer le message d’appel RPC au commutateur Catalyst 3850 au moyen de NETCONF. Le commutateur Catalyst 3850 répond par un message de réussite pour informer l’utilisateur que l’opération a réussi.
Toutes les opérations du modèle de données cisco-ia.yang sont décrites ici :
sync-from – Cet appel RPC amène l’interface NETCONF sur le commutateur Catalyst 850 à synchroniser la représentation de la banque de données NETCONF du périphérique qui exécute la configuration avec la configuration en cours sur le périphérique. Les deux existent sur le commutateur Catalyst 3850 lui-même.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:sync-from xmlns:cisco-ia
</rpc>
Le comportement par défaut de cet appel RPC est d’effectuer une synchronisation sans valeurs par défaut, ce qui entraîne la synchronisation de la sortie d’une commande show running-config envoyée au périphérique avec la banque de données NETCONF. Si sync-defaults est présent, l’interface NETCONF lit également les informations de configuration par défaut fournies par le code de fonction. Dans la plupart des cas, cette option n’est pas utilisée. En général, cela ne serait utilisé que si l’utilisateur de l’interface NETCONF voulait utiliser les commandes replace (remplacement) NETCONF pour remplacer des sections complètes de la configuration du périphérique.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:sync-from xmlns:cisco-ia/>
<cisco-ia:sync-defaults/>
</cisco-ia:sync-from>
</rpc>
save-config – Cet appel RPC exécute une commande de mémoire en écriture (copy running-config startup-config) pour enregistrer le périphérique en cours de configuration dans la configuration de démarrage du périphérique.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:save-config xmlns:cisco-ia
</rpc>
Checkpoint : ce RPC entraîne l'enregistrement de la configuration en cours par l'interface NETCONF sur un stockage non volatile à l'aide de la fonction d'archivage de configuration intégrée de Cisco IOSd.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:checkpoint xmlns:cisco-ia
</rpc>
restauration – Cet appel RPC amène l’interface NETCONF à restaurer la configuration en cours du périphérique à une configuration en cours d’enregistrement qui a été enregistrée avec le point de contrôle d’appel RPC ou toute autre configuration en cours d’exécution valide enregistrée sur le périphérique.
target-url string (name of the saved checkpoint file)
verbose? Boolean (show detail during rollback process)
nolock? Boolean (lock configuration)
revert-on-error? Empty (if error occurs during rollback, leave running unchanged)
revert-timer? int16 (time in seconds before revets to the original configuration)
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:rollback xmlns:cisco-ia=
<cisco-ia:target-url>saved-config</cisco-ia:target-url>
<cisco-ia:verbose>true</cisco-ia:verbose>
<cisco-ia:nolock>true</cisco-ia:nolock>
<cisco-ia:revert-on-error></cisco-ia:revert-on-error>
<cisco-ia:revert-timer>10</cisco-ia:revert-timer>
</cisco-ia:rollback>
</rpc>
revert : ce RPC entraîne la modification du compteur de retour par l'interface NETCONF à partir du RPC de restauration. Ceci annule la restauration chronométrée et déclenche la restauration immédiatement, ou réinitialise les paramètres de la restauration chronométrée.
now? empty
timer? int16
idle? int16
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:revert xmlns:cisco-ia
<cisco-ia:now/>
<cisco-ia:timer>10</cisco-ia:timer>
<cisco-ia:idle>60</cisco-ia:idle>
</cisco-ia:revert>
</rpc>
reset (réinitialisation) – L’interface NETCONF peut être redémarrée à l’aide de cet appel RPC. Si la valeur de réinitialisation est True (vraie), l’interface NETCONF efface toutes les informations d’état qui existent dans le magasin de données accessible en écriture. Si la valeur est False (faux) (valeur par défaut), les informations d’état de la banque de données de configuration NETCONF sont conservées.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:reset xmlns:cisco-ia
<cisco-ia:reinitialize>true</cisco-ia:reinitialize>
</cisco-ia:reset>
</rpc>
<nc:rpc-error xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:error-type>application</nc:error-type>
<nc:error-tag>operation-failed</nc:error-tag>
<nc:error-severity>error</nc:error-severity>
<nc:error-path xmlns:cisco-ia
<nc:error-message lang="en" xmlns="https://www.w3.org/XML/1998/namespace">Reset not supported</nc:error-message>
<nc:error-info>
<nc:bad-element>reset</nc:bad-element>
</nc:error-info>
</nc:rpc-error>
Modèle de données ned.yang
Les modèles de données NED (Network Elements Driver) tels que ned.yang fournissent la plus grande puissance en termes de configuration du périphérique Cisco (Catalyst 3850). Voici quelques captures d'écran qui le démontrent.
La première étape consiste à vous abonner au modèle de données ned.yang pour qu’il s’affiche dans la section Explorer à gauche de l’interface utilisateur graphique du YANG Explorer.
En faisant défiler les options disponibles dans la section Explorer sur le côté gauche de l’application YANG Explorer, l’interface graphique utilisateur affiche une longue liste de fonctionnalités configurables du commutateur Catalyst 3850 dans le modèle de données ned.yang.
Par exemple, ces captures d'écran montrent comment afficher la configuration de routage OSPF du Catalyst 3850 après avoir fait défiler la liste des options de configuration du modèle de données end.yang disponibles dans la section Explorer sur le côté gauche de l'interface utilisateur graphique de l'application YANG Explorer. La sous-option ospf est située à l’intérieur de l’option router (routeur). L’appel RPC get-config associé est généré lorsque vous sélectionnez le bouton RPC.
Ensuite, Run (exécuter) est sélectionné afin d’envoyer le message d’appel RPC au commutateur Catalyst 3850 au moyen de NETCONF. Le Catalyst 3850 répond avec sa configuration de routage OSPF.
Voici une extension de la configuration de routage OSPF renvoyée par le commutateur Catalyst 3850 en réponse à l’opération d’appel RPC get-config.
<rpc-reply message-id="urn:uuid:0e2c04cf-9119-4e6a-8c05-238ee7f25208" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<native xmlns>
<router>
<ospf>
<id>100</id>
<redistribute>
<connected>
<redist-options>
<subnets/>
</redist-options>
</connected>
</redistribute>
<network>
<ip>10.10.0.0</ip>
<mask>0.0.255.255</mask>
<area>0</area>
</network>
<network>
<ip>10.20.0.0</ip>
<mask>0.0.255.255</mask>
<area>0</area>
</network>
<network>
<ip>10.100.0.0</ip>
<mask>0.0.255.255</mask>
<area>0</area>
</network>
</ospf>
</router>
</native>
</data>
</rpc-reply>
La configuration de routage OSPF formatée YANG qui a été récupérée à partir du Catalyst 3850 via NETCONF est lisible par l'homme et correspond à ce qui est vu lorsque vous regardez la configuration du Catalyst 3850 via l'interface de ligne de commande du Catalyst 3850.
3850-1# show running-config | section ospf
router ospf 100
redistribute connected subnets
network 10.10.0.0 0.0.255.255 area 0
network 10.20.0.0 0.0.255.255 area 0
network 10.100.0.0 0.0.255.255 area 0
3850-1#
Si vous le souhaitez, le modèle de données ned.yang peut également être utilisé pour modifier la configuration de routage OSPF. Dans cet exemple, de nouveaux paramètres réseau sont ajoutés à la configuration de routage OSPF existante sur le Catalyst 3850 en entrant d'abord les paramètres souhaités dans la section Explorer de l'interface utilisateur graphique de l'application Yang Explorer sur la gauche (l'ID de routeur OSPF 100 a également été entré mais n'est pas vu en raison du défilement de l'écran Explorer), puis en générant le RPC formaté YANG associé et en appuyant sur le bouton RPC.
Ensuite, Run (exécuter) est sélectionné afin d’envoyer le message d’appel RPC au commutateur Catalyst 3850 au moyen de NETCONF. Le commutateur Catalyst 3850 répond par un message OK pour informer l’utilisateur que l’opération a réussi.
Cette opération NETCONF/YANG RPC de modification de la configuration de routage OSPF au moyen du modèle de données ned.yang est reflétée dans la configuration du commutateur Catalyst 3850 comme vu via l’interface de commande en ligne du commutateur Catalyst 3850. Un message syslog s’affiche également sur le commutateur Catalyst 3850, afin d’indiquer qu’une modification de configuration a été effectuée au moyen de NETCONF.
3850-1#
*Jan 30 14:13:41.659: %DMI-5-CONFIG_I:Switch 1 R0/0: nesd: Configured from NETCONF/RESTCONF by cisco1, transaction-id 23143
3850-1# show running-config | section ospf
router ospf 100
redistribute connected subnets
network 10.10.0.0 0.0.255.255 area 0
network 10.20.0.0 0.0.255.255 area 0
network 10.30.0.0 0.0.255.255 area 0 ------> new line added to OSPF configuration
network 10.100.0.0 0.0.255.255 area 0
3850-1#
Référez-vous à l’opération save-config mentionnée dans la section précédente de modèle de données cisco-ia.yang pour plus de détails sur la façon de sauvegarder le running-config dans la configuration de démarrage sur le commutateur Catalyst 3850 au moyen de NETCONF/YANG.
Script Python
Générez un script Python à partir de l’interface graphique utilisateur de l’application Yang Explorer
L’interface graphique utilisateur de l’application Yang Explore peut également servir à générer un script Python pour une opération NETCONF/YANG donnée. Un avantage clé des scripts Python est qu’ils permettent l’orchestration et l’automatisation des opérations NETCONF/YANG.
Dans cet exemple, une opération de sauvegarde de configuration est sélectionnée dans la fenêtre de l'explorateur sur le côté gauche de l'interface utilisateur graphique de l'application Yang Explorer sur la plate-forme de gestion centralisée (ordinateur portable). Ensuite, le bouton Script est sélectionné pour générer le script Python. Le bouton Copy (copier) peut ensuite être sélectionné pour copier le script afin qu’il puisse à son tour être collé dans un fichier qui peut être enregistré sur la plateforme de gestion centralisée (ordinateur portable) avec une extension de fichier Python..py. Pour cet exemple, (non représenté) ce fichier a été nommé example.py.
Voici une extension du script Python qui a été généré puis copié et collé dans un fichier appelé example.py sur la plateforme de gestion centralisée (ordinateur portable).
"""
Netconf python example by yang-explorer (https://github.com/CiscoDevNet/yang-explorer)
Installing python dependencies:
> pip install lxml ncclient
Running script: (save as example.py)
> python example.py -a 172.16.167.174 -u cisco1 -p cisco1 --port 830
"""
import lxml.etree as ET
from argparse import ArgumentParser
from ncclient import manager
from ncclient.operations import RPCError
payload = """ <save-config xmlns
"""
if __name__ == '__main__':
parser = ArgumentParser(description='Usage:')
# script arguments
parser.add_argument('-a', '--host', type=str, required=True,
help="Device IP address or Hostname")
parser.add_argument('-u', '--username', type=str, required=True,
help="Device Username (netconf agent username)")
parser.add_argument('-p', '--password', type=str, required=True,
help="Device Password (netconf agent password)")
parser.add_argument('--port', type=int, default=830,
help="Netconf agent port")
args = parser.parse_args()
# connect to netconf agent
with manager.connect(host=args.host,
port=args.port,
username=args.username,
password=args.password,
timeout=90,
hostkey_verify=False,
device_params={'name': 'csr'}) as m:
# execute netconf operation
try:
response = m.dispatch(ET.fromstring(payload)).xml
data = ET.fromstring(response)
except RPCError as e:
data = e._raw
# beautify output
print(ET.tostring(data, pretty_print=True))
Exécutez un script Python à partir de la plateforme de gestion centralisée (ordinateur portable)
Voici la vérification de l'interface de ligne de commande du Catalyst 3850 avant d'exécuter le script Python example.py qui peut enregistrer la configuration en cours dans la configuration initiale. À ce stade, la commande shutdown est dans la configuration en cours mais pas dans la configuration de démarrage pour l'interface GigabitEthernet1/0/10.
3850-1# show running-config interface gigabitEthernet 1/0/10
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/10
shutdown
end
3850-1# show startup-config | begin 1/0/10
interface GigabitEthernet1/0/10
!
interface GigabitEthernet1/0/11
!
interface GigabitEthernet1/0/12
!
interface GigabitEthernet1/0/13
!
À partir d’une invite de terminal régulière sur la plateforme de gestion centralisée (ordinateur portable), le fichier Python example.py généré par l’interface graphique utilisateur de l’application Yang Explorer est d’abord copié dans le répertoire yang-explore sur l’ordinateur portable.
USER1-M-902T:~ USER1$ pwd
/Users/USER1
USER1-M-902T:~ USER1$ cp /Users/USER1/Desktop/example.py /Users/USER1/yang-explorer
USER1-M-902T:~ USER1$ cd yang-explorer
USER1-M-902T:yang-explorer USER1$ ls -l
total 112
-rw-r--r-- 1 USER1 staff 11358 Jan 4 17:59 LICENSE
-rw-r--r-- 1 USER1 staff 13635 Jan 4 17:59 README.md
drwxr-xr-x 12 USER1 staff 408 Jan 4 17:59 YangExplorer
drwxr-xr-x 7 USER1 staff 238 Jan 4 17:59 default-models
drwxr-xr-x 3 USER1 staff 102 Jan 4 17:59 docs
-rw-r--r-- 1 USER1 staff 72 Jan 4 17:59 env.sh
-rw-r--r--@ 1 USER1 staff 1990 Jan 30 17:50 example.py
-rw-r--r-- 1 USER1 staff 207 Jan 4 17:59 requirements.txt
drwxr-xr-x 11 USER1 staff 374 Jan 5 14:37 server
-rwxr-xr-x 1 USER1 staff 4038 Jan 4 17:59 setup.sh
-rwxr-xr-x 1 USER1 staff 640 Jan 4 17:59 start.sh
drwxr-xr-x 5 USER1 staff 170 Jan 4 18:00 v
USER1-M-902T:yang-explorer USER1$
Ensuite, à partir d'une invite de terminal régulière sur la plate-forme de gestion centralisée (ordinateur portable), ces deux commandes sont exécutées, qui ont été fournies dans la section des commentaires au début du fichier example.py qui a été généré par l'interface utilisateur graphique de l'application Yang Explorer (référez-vous à la section précédente, Génération d'un script Python à partir de l'interface utilisateur graphique de l'application Yang Explorer).
USER1-M-902T:yang-explorer USER1$ pip install lxml ncclient
Collecting lxml
Downloading lxml-3.7.2.tar.gz (3.8MB)
100% |████████████████████████████████| 3.8MB 328kB/s
Collecting ncclient
Downloading ncclient-0.5.3.tar.gz (63kB)
100% |████████████████████████████████| 71kB 3.5MB/s
Requirement already satisfied: setuptools>0.6 in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages (from ncclient)
Collecting paramiko>=1.15.0 (from ncclient)
Downloading paramiko-2.1.1-py2.py3-none-any.whl (172kB)
100% |████████████████████████████████| 174kB 3.1MB/s
Collecting six (from ncclient)
Using cached six-1.10.0-py2.py3-none-any.whl
Collecting cryptography>=1.1 (from paramiko>=1.15.0->ncclient)
Using cached cryptography-1.7.2-cp27-cp27m-macosx_10_6_intel.whl
Collecting pyasn1>=0.1.7 (from paramiko>=1.15.0->ncclient)
Using cached pyasn1-0.1.9-py2.py3-none-any.whl
Collecting cffi>=1.4.1 (from cryptography>=1.1->paramiko>=1.15.0->ncclient)
Using cached cffi-1.9.1-cp27-cp27m-macosx_10_10_intel.whl
Collecting enum34 (from cryptography>=1.1->paramiko>=1.15.0->ncclient)
Using cached enum34-1.1.6-py2-none-any.whl
Collecting ipaddress (from cryptography>=1.1->paramiko>=1.15.0->ncclient)
Using cached ipaddress-1.0.18-py2-none-any.whl
Collecting idna>=2.0 (from cryptography>=1.1->paramiko>=1.15.0->ncclient)
Using cached idna-2.2-py2.py3-none-any.whl
Collecting pycparser (from cffi>=1.4.1->cryptography>=1.1->paramiko>=1.15.0->ncclient)
Downloading pycparser-2.17.tar.gz (231kB)
100% |████████████████████████████████| 235kB 2.6MB/s
Installing collected packages: lxml, six, pycparser, cffi, pyasn1, enum34, ipaddress, idna, cryptography, paramiko, ncclient
Running setup.py install for lxml ... -
done
Running setup.py install for pycparser ... done
Running setup.py install for ncclient ... done
Successfully installed cffi-1.9.1 cryptography-1.7.2 enum34-1.1.6 idna-2.2 ipaddress-1.0.18 lxml-3.7.2 ncclient-0.5.3 paramiko-2.1.1 pyasn1-0.1.9 pycparser-2.17 six-1.10.0
USER1-M-902T:yang-explorer USER1$
La deuxième commande exécute le script Python example.py sur le commutateur Catalyst 3850 à l’adresse IP 172.16.167.174 avec le nom d’utilisateur/mot de passe cisco1/cisco1 via le port TCP 830 (netconf-ssh). Le commutateur Catalyst 3850 renvoie une réponse à l’appel RPC à la plateforme de gestion centralisée (ordinateur portable) indiquant que l’opération save-config a réussi.
USER1-M-902T:yang-explorer USER1$ python example.py -a 172.16.167.174 -u cisco1 -p cisco1 --port 830
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:31e0fdee-b72f-4695-9e03-91ec771b37f5"><result xmlns>Save running-config successful
</result>
</rpc-reply>
USER1-M-902T:yang-explorer USER1
Voici la vérification de l’interface de commande en ligne du commutateur Catalyst 3850 après l’exécution du script Python example.py qui a enregistré running-config dans la configuration de démarrage. La commande shutdown (arrêt) est maintenant présente à la fois dans running-config et dans startup-config pour l’interface GigabitEthernet1/0/10 en raison de l’opération réussie de save-config NETCONF/YANG.
3850-1# show running-config interface gigabitEthernet 1/0/10
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/10
shutdown
end
3850-1# show startup-config | begin 1/0/10
interface GigabitEthernet1/0/10
shutdown
!
interface GigabitEthernet1/0/11
!
interface GigabitEthernet1/0/12
!
interface GigabitEthernet1/0/13
!
Dépannage
Cette section fournit des informations que vous pouvez utiliser pour dépanner votre configuration.
Messages d’erreur NETCONF
Le protocole NETCONF définit un ensemble d’opérations et de messages échangés entre le client NETCONF (plateforme de gestion centralisée (ordinateur portable)) et l’implémentation NETCONF sur le périphérique serveur (Catalyst 3850). Les opérations NETCONF couramment utilisées comprennent :
<get>, <get-config>, <edit-config>, et <rpc>
Le format et les autres contraintes sur le contenu du message NETCONF sont définis par les modèles de données YANG. Le client et le serveur NETCONF interagissent en envoyant des appels RPC.
S'il y a une erreur dans le format du message NETCONF, ou si le contenu du message ne correspond pas aux définitions dans les modèles de données YANG implémentés par le périphérique, le serveur NETCONF sur le périphérique peut renvoyer une erreur RPC.
<error-type>application</error-type>
Ces erreurs d’appels RPC n’indiquent pas que l’interface NETCONF ne fonctionne pas, mais plutôt que le client tente d’effectuer une opération qui n’est pas prise en charge par les modèles de données YANG mis en œuvre sur le périphérique serveur. Les utilisateurs doivent examiner les modèles de données YANG mis en œuvre sur le périphérique serveur pour déceler et résoudre les causes de ces erreurs.
Exemple d’erreur relative à un appel de procédure à distance (RPC)
Dans cet exemple, un type d’interface incorrect ianaift: fastEtherFX est utilisé pour générer le message d’appel RPC NETCONF au format<edit-config> YANG à envoyer au moyen de NETCONF au commutateur Catalyst 3850.
Une fois que Run (exécuter) est sélectionné pour envoyer le message d’appel RPC au commutateur Catalyst 3850, le commutateur répond par un message d’erreur.
Voici l’erreur renvoyée par le commutateur Catalyst 3850. Notez qu'il contient une balise d'erreur « operation-failed » et un détail supplémentaire concernant l'erreur indique « Unsupported - value must be ethernetCsmacd or softwareLoopback »</nc : error-message> ».
<nc:rpc-error xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:error-type>application</nc:error-type>
<nc:error-tag>operation-failed</nc:error-tag>
<nc:error-severity>error</nc:error-severity>
<nc:error-path xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">/rpc/edit-config/config/if:interfaces/if:interface[if:name='GigabitEthernet1/0/16']/if:type</nc:error-path>
<nc:error-message lang="en" xmlns="https://www.w3.org/XML/1998/namespace">/interfaces/interface[name='GigabitEthernet1/0/16']/type: "Unsupported - value must be ethernetCsmacd or softwareLoopback"
<nc:error-info>
<nc:bad-element>type</nc:bad-element>
</nc:error-info>
</nc:rpc-error>
Corrigons ensuite l'erreur et spécifions le type d'interface ianaift:ethernetCsmacd correct dans le message RPC envoyé au Catalyst 3850 afin que le Catalyst 3850 réponde avec un message ok au lieu d'une erreur.
Cette fois, une fois que Run (exécuter) est sélectionné pour envoyer le message d’appel RPC au commutateur Catalyst 3850, ce dernier répond par un message ok pour indiquer que l’opération a réussi.
Une fois que Run (exécuter) est sélectionné pour envoyer le message d’appel RPC au commutateur Catalyst 3850, ce dernier répond avec la configuration d’interface au format YANG qui indique que le type d’interface est ianaift:ethernetCsmacd.
Autres exemples de type d’erreur relative à un appel de procédure à distance (RPC)
1. Message de réponse d'erreur RPC « In-use » (config-locked)
Ceci est une réponse d’erreur NETCONF à une requête <edit-config>. La balise <error-tag> indique « en cours d'utilisation ». La réponse indique que le périphérique de serveur (Catalyst 3850) NETCONF exécutant le magasin de données est actuellement verrouillé et que l’opération NETCONF <edit-config> n’a pas pu être effectuée pour le moment. Cela n’indique pas une erreur dans la mise en œuvre de l’interface NETCONF. Si un client NETCONF tente une écriture dans le magasin de données NETCONF en cours d’exécution lorsque le magasin de données est en cours d’utilisation, le client reçoit cette réponse d’appel RPC. Le client NETCONF peut réessayer le message de configuration d’édition NETCONF. Cette réponse peut être reçue lorsque le périphérique effectue une opération interne de synchronisation à partir du périphérique pour synchroniser le datastore NETCONF en cours avec la configuration IOSd du périphérique.
Réponse NETCONF du serveur (Catalyst 3850) au client (plateforme de gestion centralisée [ordinateur portable]).
<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3">
<rpc-error>
<error-type>application</error-type>
<error-tag>in-use</error-tag>
<error-severity>error</error-severity>
<error-app-tag>config-locked</error-app-tag>
<error-info>
<session-id>0</session-id>
</error-info>
</rpc-error>
</rpc-reply>
2. Message de réponse d'erreur RPC « Données manquantes »
Dans cet exemple, un RPC <edit-config> a été envoyé au Catalyst 3850 pour une interface de bouclage qui n'a pas été configurée. Une erreur a été renvoyée, car vous ne pouvez pas configurer une interface qui n’existe pas sur le commutateur Catalyst 3850.
<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3">
<rpc-error>
<error-type>application</error-type>
<error-tag>data-missing</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">/rpc/edit-config/config/if:interfaces/if:interface[if:name='Loopback1111']/if:type</error-path>
<error-message xml:lang="en">/interfaces/interface[name='Loopback1111']/type is not configured</error-message>
<error-info>
<bad-element>type</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
3. Message de réponse d'erreur RPC « Modèle de données manquant »
Si une demande est faite pour un modèle de données qui n'existe pas sur le Catalyst 3850 ou une demande est faite pour un leaf qui n'est pas implémenté dans un modèle de données, le serveur (Catalyst 3850) répond avec une réponse de données vide. C’est un comportement attendu.
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>
4. Message de réponse d'erreur RPC « Invalid-value »
Dans certains cas, un message NETCONF peut contenir un contenu valide basé sur les modèles de données YANG. Cependant, le périphérique (Catalyst 3850) n'est pas en mesure d'implémenter ce qui est demandé. Lorsque l’interface NETCONF du commutateur Catalyst 3850 envoie des configurations à IOSd que l’IOSd ne peut pas appliquer, une réponse d’erreur spécifique à l’appel RPC est renvoyée au client NETCONF.
Dans cet exemple, une valeur incorrecte tamponnée de journalisation incorrecte est envoyée dans le message d’appel RPC au commutateur Catalyst 3850. La balise d’erreur dans la réponse du commutateur Catalyst 3850 indique une valeur non valide. Le message d’erreur indique que l’analyseur d’IOS Catalyst 3850 n’a pas pu configurer le niveau de gravité de la mémoire tampon de journalisation comme étant faux, car cette valeur n’est pas valide.
<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="6">
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-message xml:lang="en">inconsistent value: Device refused command "logging buffered bogus" at column 20 </error-message>
</rpc-error>
</rpc-reply>
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
3.0 |
21-Dec-2023 |
Mise à jour des exigences de personnalisation, orthographe et formatage. |
2.0 |
01-Dec-2022 |
PII supprimées.
Texte de remplacement ajouté.
Rétablir les informations RPC corrigées.
Titre, introduction, traduction automatique, géronds, exigences de style et mise en forme mis à jour. |
1.0 |
17-Sep-2021 |
Première publication |
Commentaires