Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Informations générales

Modèles de données - Configuration et surveillance programmatiques et normalisées

Un autre langage de modélisation de données de nouvelle génération (YANG) (RFC 6020)

Protocole de configuration réseau (NETCONF) (RFC 6241)

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

2. Configuration supplémentaire (facultative) pour permettre la surveillance des événements NETCONF/YANG Syslog et SNMP

3. Configuration de la connectivité réseau du Catalyst 3850 utilisé dans cet exemple

Vérifiez NETCONF/YANG sur le Catalyst 3850

Configurez la plateforme de gestion centralisée (ordinateur portable)

1. Installer l'application Yang Explorer sur un ordinateur portable

2. Utiliser l'application Yang Explorer

3. Abonnez-vous aux notifications NETCONF (facultatif)

Exemples opérationnels de base NETCONF/YANG

1. Exemple de récupération de données

Demandez une liste de noms d’interface auprès du commutateur Catalyst 3850

2. Exemple de configuration

Mettez hors tension une interface Ethernet sur le commutateur Catalyst 3850

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

Enregistrez la configuration sur un commutateur Catalyst 3850

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

Configurez le commutateur Catalyst 3850 à partir de l’interface de commande en ligne

3. Vérifiez les données opérationnelles SNMP MIB disponibles via les opérations de requête GET

Chargez des modèles de données YANG supplémentaires

1. Charger les différents fichiers de modèles de données YANG individuellement

2. Chargement en masse de tous les fichiers du modèle de données YANG en une seule fois

Modèles de données YANG notables

Modèle de données cisco-ia.yang

Modèle de données ned.yang

Script Python

Générez un script Python à partir de l’interface graphique utilisateur de l’application Yang Explorer

Exécutez un script Python à partir de la plateforme de gestion centralisée (ordinateur portable)

Dépannage

Messages d’erreur NETCONF

Exemple d’erreur relative à un appel de procédure à distance (RPC)

Autres exemples de type d’erreur relative à un appel de procédure à distance (RPC)

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 basés sur des normes, la même procédure peut être utilisée pour configurer ou recueillir des données à partir d’appareils autres que ceux de Cisco, ce qui les rend idéaux pour les clients qui prennent en charge plusieurs fournisseurs. Une plateforme 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 au moyen de scripts Python (deux avantages supplémentaires clés).

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 plateforme de gestion centralisée (par exemple un ordinateur portable) pour créer ces demandes de données de configuration et d’exploitation.

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 et XML (Extensible Markup Language) codé qui fournit le transport pour communiquer la configuration au format YANG ou la demande de données opérationnelles d’une application qui fonctionne sur une plateforme de gestion centralisée (par exemple un ordinateur portable) vers le périphérique Cisco que l’utilisateur souhaite configurer ou pour lequel il veut demander des données opérationnelles (affichage de commande). 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 l'on souhaite activer AAA (authentication, authorization, and accounting) en configurant "aaa new-model" alors cette configuration est aussi requise au minimum. Vous pouvez également développer ceci pour utiliser AAA avec une configuration TACACS+ ou RADIUS, mais cela dépasse le 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.

Notez que bien que ces paramètres soient le minimum requis, des entrées « snmp-server enable » supplémentaires peuvent également être présentes. Un client (plateforme de gestion centralisée) s’inscrit pour recevoir le flux de notification NETCONF d’un serveur (Catalyst 3850) et envoyer un appel RPC d’abonnement précis (voir la section 3 de « Configuration de la plateforme 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 d’interruption SNMP, utilisez cette interface de commande en ligne « 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

Démarrez l’application Yang Explorer – à partir d’une invite de terminal sur l’ordinateur portable, exécutez la commande e./start.sh & à 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érer les capacités du commutateur Catalyst 3850 – saisissez les détails du commutateur Catalyst 3850 (adresse IP, nom d’utilisateur/mot de passe, port TCP 830 pour ssh-netconf) et cliquez sur Capabilities (capacités) 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 copier-coller dans l’interface graphique utilisateur de l’application Yang Explorer en tant que Custom RPC (appel 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 commutateur Catalyst 3850 et la plateforme 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 commutateur Catalyst 3850 répond par une liste au format YANG (lisible par un humain) des noms d’interface du commutateur 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, la configuration d’une interface (fermeture d’une interface) est requise sur le commutateur Catalyst 3850, de sorte que Config (pour « configuration ») est sélectionné, suivi des paramètres opérationnels requis dans 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 commutateur Catalyst 3850 répond 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.

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 indiqué est une bonne façon de déterminer ce qu'elles sont avant de tenter de les modifier. 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. Pour découvrir les données MIB disponibles dans les requêtes GET, trois options sont proposées. 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èle de données YANG supplémentaires.Ces fichiers permettent d'exécuter des 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.

https://github.com/YangModels/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.

https://github.com/YangModels/yang/tree/primary/standard/ietf/RFC

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.

https://github.com/YangModels/yang/tree/primary/vendor/cisco/xe/1632

Ces fichiers peuvent être téléchargés sur la plateforme de gestion centralisée (ordinateur portable) puis chargés à leur tour 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é à partir de github sur la plateforme 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. Puis 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 se distinguent par le fait qu’ils engagent des opérations telles que la sauvegarde de la configuration du commutateur Catalyst 3850, la synchronisation de l’exécution de la configuration du commutateur Catalyst 3850 avec le magasin de données DMI (Data Model Interface) local et la réinitialisation de l’interface DMI du commutateur 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 que le modèle de données cisco-ia est développé dans la section Explorateur à gauche de l’interface graphique utilisateur de l’application YANG Explorer, les différentes options opérationnelles sont affichées. Par exemple, pour utiliser l’une des options de modèle de données cisco-ia.yang disponibles, l’opération save-config est sélectionnée et l’appel 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 amène l'interface NETCONF à changer le temporisateur de retour du RPC de retour arrière, ceci annule le retour arrière temporisé et déclenche le retour arrière immédiatement ou réinitialise les paramètres pour le retour arrière temporisé.

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) comme 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="http://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.

À titre d’exemple, ces captures d’écran montrent comment afficher la configuration de routage OSPF du commutateur Catalyst 3850 après avoir fait défiler la liste des options de configuration de modèle de données ned.yang disponibles dans la section Explorer sur le côté gauche de l’interface graphique utilisateur 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 formulée par YANG qui a été récupérée à partir du commutateur Catalyst 3850 via NETCONF est lisible par l’humain et correspond à ce qui est vu lorsque vous regardez sa configuration via l’interface de commande en ligne du commutateur 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 commutateur Catalyst 3850 en saisissant d’abord les paramètres souhaités dans la section Explorer de l’interface graphique utilisateur de Yang Explorer à gauche (notez que l’ID de routeur OSPF 100 a également été saisi, mais n’est pas visible à cause du défilement de l’Explorer), puis de la génération de l’appel RPC associé au format YANG associé au 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 save-config est sélectionnée dans la fenêtre Explorer sur le côté gauche de l’interface graphique utilisateur de l’application Yang Explorer sur la plateforme 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 illustré), ce fichier a été nommé example.py.

Note : Dans l'exemple suivant qui utilise "Platform", le type other dans l'interface graphique a généré une erreur lors de l'exécution du script Python. Par conséquent, le type de plateforme a été remplacé par csr, car le routeur Cisco CSR exécute également le logiciel Cisco IOS-XE, tout comme le commutateur 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).

Note : 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 nécessaires à l'exécution du 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 (arrêt) se trouve dans running-config, 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 plateforme de gestion centralisée (ordinateur portable), ces deux commandes sont exécutées et ont été fournies dans la section des commentaires au début du fichier example.py qui a été généré par l’interface graphique utilisateur de l’application Yang Explorer (consultez la section précédente « Génération d’un script Python à partir de l’interface graphique utilisateur 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.

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>. Le <error-tag> indique « In-use » (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 « sync-from-device » 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 appel RPC <edit-config> a été envoyé au commutateur Catalyst 3850 pour une interface de boucle avec retour non 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 de modèle de données manquant

Si une demande est faite pour un modèle de données qui n’existe pas sur le commutateur Catalyst 3850 ou qu’une demande est faite pour une feuille qui n’est pas mise en œuvre dans un modèle de données, le serveur (Catalyst 3850) donne 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>