Configuration de NETCONF/YANG pour les plates-formes Cisco IOS XE 16.X

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.

Remarque : aucune expérience préalable avec les scripts NETCONF, YANG ou Python n'est requise pour utiliser ce document.

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

Remarque : il s'agit de la configuration complète requise sur le Catalyst 3850 pour prendre en charge la modélisation de données NETCONF/YANG, mais elle suppose qu'aucun nouveau modèle aaa n'est également configuré globalement (par défaut). Si vous souhaitez activer AAA (authentication, authorization, and accounting) en configurant un nouveau modèle, cette configuration est également requise au minimum. Vous pouvez également développer cette option pour utiliser AAA avec une configuration TACACS+ ou RADIUS, mais cela sort du cadre de cet exemple.

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.

Conseil : si ce test SSH ne fonctionne pas, assurez-vous que tout pare-feu entre l'ordinateur portable et le Catalyst 3850 autorise le port TCP 830 (référence RFC 4742 : Tools 4742).

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

Remarque : l'application YANG Explore est également prise en charge sur les systèmes Linux.

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.

Remarque : laissez cette session de terminal ouverte, sinon l'application Yang Explorer peut s'arrêter et doit être redémarrée. Il peut également servir de journal de console de l'activité des applications.

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.

Conseil : il s'agit également d'un bon test pour confirmer que la communication NETCONF fonctionne entre l'application Yang Explorer sur la plate-forme de gestion centralisée (ordinateur portable) et le 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.

Remarque : la version actuelle de Yang Explorer utilisée dans cet exemple n'a pas d'option pour examiner les notifications NETCONF reçues. Elles sont généralement stockées dans un journal de notification sur lequel il est possible de cliquer dans le menu principal de l’application.

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.

Conseil : En général, lorsqu'il n'est pas clair quel format les valeurs peuvent être dans la section Explorer de l'application Yang Explorer, le vidage de la configuration du Catalyst 3850 formatée YANG, comme illustré, est une bonne façon de déterminer ce qu'elles sont avant qu'une tentative de les modifier soit faite. La partie droite des écrans suivants fournit des descriptions et des dépendances pour ces valeurs, ainsi que dans les colonnes Propriété et Valeur.

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#

Remarque : la configuration n'a pas encore été enregistrée (copiée de la configuration en cours vers la configuration initiale) sur le Catalyst 3850.

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&amp;revision=2007-04-27</capability> 
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CONTEXT-MAPPING-MIB?module=CISCO-CONTEXT-MAPPING-MIB&amp;revision=2008-11-22</capability> 
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-DATA-COLLECTION-MIB?module=CISCO-DATA-COLLECTION-MIB&amp;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.

Modèles GitHub Yang

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

Conseil : rawgit peut être nécessaire pour télécharger les fichiers depuis Github. Pour télécharger des fichiers depuis github, sélectionnez le bouton Raw associé au fichier YANG. Si une URL est donnée au lieu d'une option de téléchargement de fichier, l'URL peut être collée dans rawgit qui peut à son tour fournir une URL de production. Collez cette nouvelle URL de production dans un navigateur et elle peut fournir l'option de téléchargement de fichier.

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.

Conseil : la fonctionnalité NETCONF permet de déterminer les modèles de données pris en charge par le logiciel Catalyst 3850. Reportez-vous à la section 2. de Configuration de la plate-forme de gestion centralisée (ordinateur portable).

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.

Conseil : la fonctionnalité des fonctionnalités NETCONF peut être utilisée pour déterminer quels modèles de données sont pris en charge par le logiciel Catalyst. Reportez-vous à la section 2. de Configuration de la plate-forme de gestion centralisée (ordinateur portable).

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>

Remarque : certaines plates-formes Cisco ou versions du logiciel Cisco IOS ne peuvent pas prendre en charge toutes les fonctionnalités données pour le moment. Par exemple, lorsque vous envoyez la réinitialisation précédente à un Catalyst 3850 exécutant IOS 16.3.3, l'erreur « Reset not supported » (Réinitialisation non prise en charge) est renvoyée par le Catalyst 3850 à la plate-forme de gestion centralisée (ordinateur portable) en tant que réponse 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.

Remarque : dans l'exemple suivant qui utilise le type de plate-forme other dans l'interface graphique utilisateur, une erreur s'est produite lors de l'exécution du script Python. Par conséquent, le type de « plate-forme » a été remplacé par csr puisque le routeur Cisco CSR exécute également le logiciel Cisco IOS XE, tout comme le Catalyst 3850. L'erreur a été évitée.

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).

Remarque : Les commentaires au début du fichier example.py qui a été généré par l'interface graphique de l'application Yang Explorer incluent les étapes requises pour exécuter le script Python. La charge utile inclut l'opération NETCONF/YANG que le script peut exécuter. Dans cet exemple, il s’agit d’une opération save-config .

""" 
    
   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-message> 
   <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.

Conseil : si vous n'êtes pas sûr du format correct des valeurs de l'explorateur, vous pouvez vérifier la configuration existante avant d'essayer de modifier ses paramètres. Cela peut être fait à l’aide de l’opération get-config (Oper), comme ici.

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.

Conseil : utilisez la fonctionnalité NETCONF pour déterminer quels modèles de données sont pris en charge par le logiciel Catalyst. Reportez-vous à la section 2. de Configuration de la plate-forme de gestion centralisée (ordinateur portable).

<?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>