View
810
Download
6
Category
Preview:
DESCRIPTION
In french, Network configuration management with NETCONF
Citation preview
TX Gestion de Réseaux et gestion de la configuration avec NETCONF
Ce travail d’expérimentation a pour but d’avoir une vue globale sur la gestion des réseaux de
télécommunication et d’expérimenter un protocole récent apportant des réponses à une partie spécifique de la
gestion des réseaux : la gestion de la configuration.
Nous aborderons donc les grandes approches de la gestion de réseau, ensuite nous nous intéresserons plus
précisément à la gestion de la configuration puis nous expérimenterons en détail le protocole NETCONF au
travers de l’implémentation de Cisco et des clients NETCONF YUMA et MGSoft Netconf browser. Un scénario
mettra en évidence l’intérêt du protocole et la dernière partie présente une solution plus large dans laquelle la
gestion de la configuration est intégrée à la gestion globale du réseau
Etudiant : DE MIANVILLE Benoît
Responsables : PLOIX Alain, DOYEN Guillaume
Branche : SIT5
Année : 2011
Semestre : A11
Sommaire
1 Introduction ..................................................................................................................................... 1
2 Cheminement pour le choix d’une plateforme de gestion ............................................................. 2
2.1 Le contexte réseau .................................................................................................................. 2
2.2 Les acteurs ............................................................................................................................... 2
2.3 Les aires fonctionnelles ........................................................................................................... 3
2.4 Interfaçage avec le réseau ....................................................................................................... 3
2.4.1 Plan de données .............................................................................................................. 3
2.4.2 Plan de contrôle .............................................................................................................. 3
2.4.3 Plan de gestion ................................................................................................................ 4
2.4.4 Conclusion ....................................................................................................................... 4
2.5 Les grandes approches de gestion de réseau .......................................................................... 4
2.5.1 Introduction ..................................................................................................................... 4
2.5.2 SNMP ............................................................................................................................... 4
2.5.3 WBEM .............................................................................................................................. 5
2.5.4 Gestion avec Java : JMAPI et JMX .................................................................................... 6
2.5.5 TMN ................................................................................................................................. 7
2.5.6 Gestion par politique ....................................................................................................... 9
2.5.7 Conclusion ..................................................................................................................... 10
3 NETCONF ....................................................................................................................................... 12
3.1 La gestion de la configuration ............................................................................................... 12
3.2 Le protocole ........................................................................................................................... 14
3.3 YANG ...................................................................................................................................... 20
3.4 Les implémentations indépendantes des constructeurs ...................................................... 22
3.5 Les équipementiers réseaux .................................................................................................. 24
4 NETCONF en pratique .................................................................................................................... 25
4.1 Premiers pas avec Netconf .................................................................................................... 25
4.1.1 Les clients Netconf utilisés ............................................................................................ 25
4.1.2 Les serveurs Netconf utilisés ......................................................................................... 27
4.1.3 Configuration d’un routeur Cisco .................................................................................. 27
4.1.4 Le cas de l’implémentation de Cisco ............................................................................. 30
4.2 Scénario salle de travaux pratiques de services réseaux à l’UTT .......................................... 38
4.2.1 Schéma d’adressage du réseau de test ......................................................................... 39
4.2.2 Schéma physique du réseau de test .............................................................................. 40
4.2.3 Tests prouvant la bonne configuration du réseau ........................................................ 40
4.2.4 Equipements à configurer avec Netconf ....................................................................... 40
4.2.5 Configuration des équipements à configurer avec Netconf ......................................... 41
4.2.6 Prérequis à la configuration avec Netconf .................................................................... 43
4.2.7 Déploiement de la configuration ................................................................................... 46
4.2.8 Analyse du scénario ....................................................................................................... 53
4.3 Scénario opérateur télécom avec gestion de la QoS ............................................................ 55
5 Conclusion ..................................................................................................................................... 57
6 Bibliographie .................................................................................................................................. 58
7 Annexe ............................................................................................................................................. 1
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
1
1 Introduction Le but d’un travail d’expérimentation comme celui-ci est la démonstration de l’acquisition de
connaissances grâce à l’expérimentation d’une technique, en l’occurrence je me propose d’étudier
en quoi NETCONF, un protocole du monde de l’Internet, l’IETF1, apporte des nouvelles solutions en
terme de gestion de la configuration du réseau. Il n’était pas pensable de décrire de manière directe
le protocole sans aborder le paysage de la gestion de la configuration et de la gestion de réseau en
général pour comprendre dans quelles circonstances le protocole est venu au jour. La première
partie de ce document décrira donc d’une manière générale les questions à se poser pour pouvoir
faire le choix d’une solution de gestion réseau ; la première partie décrira également les grandes
approches dans la gestion de réseau, ces approches seront décrites dans leur généralité puisqu’il ne
s’agit pas ici d’exposer les détails précis de chaque approche. Une fois que la gestion de réseau sera
bien située nous verrons plus en détail la gestion de la configuration avec NETCONF, dans un premier
temps nous verrons la partie théorique du protocole, ses messages et la façon qui a été proposée de
structurer le modèle de donnée : YANG. Nous pourrons ensuite détailler la façon dont nous
procèderons en décrivant les outils techniques que nous utiliserons : le matériel, les logiciels, nous
verrons comment configurer ces outils spécifiques. Enfin nous verrons au travers d’un scénario
pratique la démonstration du protocole en détail et nous pourrons conclure, objet de ce travail
d’expérimentation, si NETCONF révolutionne la manière de gérer la configuration du réseau.
1IETF : Internet Engineering Task Force
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
2
2 Cheminement pour le choix d’une plateforme de gestion Cette partie est une forme de guide pour appréhender le choix d’une plateforme de gestion.
2.1 Le contexte réseau Il faut, dans une première approche, savoir définir le contexte réseau, afin de cibler au mieux le type
de réseau que l’on veut maitriser. Mieux on connaitra notre réseau mieux on pourra ajuster des
outils pour mesurer son état et interagir avec.
Une liste de critères simples est à éclaircir pour mieux connaitre son réseau :
La finalité du réseau : un fournisseur d’accès à internet n’aura pas les mêmes besoins de
gestion qu’une entreprise.
L’étendue du réseau : un petit réseau sur un site géographique unique ou un réseau
international.
Les technologies et l’architecture : utilise-t-on le protocole IP, ATM, Sonet, X25 ou une autre
technologie (ou plusieurs à la fois) ?
Les équipements : quels types d’équipement façonnent le réseau, des modems, des switchs,
des routeurs, et quelles sont les façons d’interagir avec ces équipements ?
2.2 Les acteurs Dans cette partie nous nous intéressons aux différents acteurs, on regarde une partie du réseau, les
équipements, les flux, l’infrastructure et on détermine quels sont les propriétaires, les différents
acteurs qui suivant leurs exigences vont nous permettre de spécifier ensuite leurs besoins en terme
de gestion.
Pour identifier les acteurs, regardons l’infrastructure : à qui appartient-elle ? Est-ce composée de
lignes louées à un opérateur, est-ce une infrastructure complètement privée que vous allez exploiter
ou bien louer à des clients ?
Le tableau ci-dessous donne 3 exemples où l’on peut identifier suivant le cas à qui appartient
l’infrastructure, l’exploitation ou les données.
Qui Infrastructure Exploitation Données
FAI louant l’infrastructure
X
FAI propriétaire de l’infrastructure
X X
Réseau privé d’entreprise
X X X
Tableau 1 : Mise en évidence de l'appartenance des éléments composants le réseau
L’intérêt d’identifier les acteurs est de pouvoir préciser d’une part où les informations qui nous
intéressent se situent et d’autre part si il y a possibilité accéder à ces informations suivant notre
pouvoir sur l’infrastructure, l’exploitation et les données.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
3
2.3 Les aires fonctionnelles L’ITU-T (International Telecomunication Union Standardization Sector) a défini une approche de
gestion de réseaux : le TMN (Telecommunications Management Network) qui définit 5 aires
fonctionnelles.
Ici on ne s’intéressera pas spécifiquement au TMN mais aux 5 aires fonctionnelles qui sont censées
être essentielles dans la gestion de réseaux et permettent une approche facilitée.
Faults : c’est la gestion des pannes, elle doit permettre d’identifier les pannes et leur type,
leur origine.
Configuration : la gestion de la configuration, où est la configuration du réseau, y-a-t-il des
procédures pour changer la configuration, pour revenir à un état antérieur ? La réponse à ces
questions entre autres est le but de cette aire.
Accounting : il s’agit ici d’établir la mesure du trafic et dans certains cas de le facturer.
Performance : la gestion de la performance permet de confirmer ou non le bon
dimensionnement du réseau en relevant les informations permettant de mesurer les
performances du réseau.
Security : la gestion de la sécurité permettra de définir des méthodes pour garantir le niveau
de sécurité exigé dans le réseau.
L’intérêt des aires fonctionnelles dans notre cas est de définir à l’avance les fonctionnalités
importantes à mettre en œuvre avec la plateforme de gestion : le niveau de sécurité exigera t- il des
méthodes pointues afin de garantir à chaque moment la sécurité du réseau (exemple d’une banque)
ou alors nos clients auront-ils conclu un contrat qui exigera une performance minimum du réseau
(exemple d’un fournisseur d’accès à internet). Autant de questions auxquelles il est important de
répondre tôt pour faciliter le choix d’une plateforme de gestion.
2.4 Interfaçage avec le réseau Dans cette partie nous allons nous intéresser aux différents moyens d’interagir avec le réseau. On
aura une approche par plan.
2.4.1 Plan de données
Le plan de données concerne les données qui sont véhiculées dans le réseau et qui sont la raison
même du réseau, dans le plan de données on retrouvera des paquets de données qui transporteront
de la voix, des parties d’une page web, un transfert de fichier etc. suivant l’utilisation faite du réseau.
Dans ce plan on va pouvoir analyser les flux eux même en les caractérisant : nombre de paquets
sortant d’une interface réseau par rapport à son maximum, pourcentage de flux d’un certain type,
horaires des pics de trafic, etc.
Un bon exemple de mise en œuvre de caractérisation des flux dans le plan de données est une
sonde.
2.4.2 Plan de contrôle
Le plan de contrôle sert à assurer la signalisation, par exemple dans le cas d’une communication voix
sur IP, le trafic servant à établir la communication et à la fermer, dans le cas d’ATM, la procédure
d’ouverture de circuits etc.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
4
Dans le plan de contrôle d’un réseau IP, on pourra utiliser le protocole ICMP (Internet Control
Message Protocol) afin de déterminer si la destination est atteignable, mesurer les temps de
traversée du réseau et identifier les chemins pris.
2.4.3 Plan de gestion
Le plan de gestion assure des fonctions de surveillance du réseau, on aura par exemple le protocole
de gestion de l’IETF (Internet Engineering Task Force) : SNMP (Simple Network Management
Protocol) ou alors CMIP/CMIS proposé par l’ISO (l’organisation internationale de normalisation).
Des méthodes dédiées des protocoles de gestion sont alors mises en œuvre afin d’assurer la gestion
de réseau. On pourra aussi utiliser des protocoles comme SSH afin d’interagir avec les équipements
réseau pour lire et modifier leur configuration.
Des grands constructeurs proposent aussi des protocoles de gestion propriétaires.
2.4.4 Conclusion
Ce qu’il est important de retenir ici est l’hétérogénéité des interfaçages avec le réseau, qu’elle soit de
par les différents plans qu’on va utiliser ou par les grandes approches du monde de l’Internet ou des
télécoms que nous allons voir plus en détail dans le chapitre suivant.
2.5 Les grandes approches de gestion de réseau
2.5.1 Introduction
Nous allons nous intéresser à des approches de gestion de réseau sélectionnées suivant plusieurs
critères .Tout d’abord ont été retenues :
les approches du monde des télécoms et du monde de l’internet, références en matière de
gestion ;
d’autres approches très élaborées et très intéressantes à étudier mais pas forcément
largement déployées.
2.5.2 SNMP
SNMP (Simple Network Management) est à la fois un protocole, une méthode de gestion et un
modèle de données, provenant d’un groupe de travail de l’IETF et fait pour les réseaux TCP/IP.
Le principe de SNMP fonctionne selon le mode agent-manager. Un processus SNMP sera exécuté sur
les agents (par exemple un routeur, un switch,…) et un autre processus SNMP sera exécuté par le
manager (un serveur). Le processus SNMP du manager pourra ensuite récolter les informations grâce
à des messages SNMP qui sont détaillés ci-dessous :
GetRequest et GetNextRequest permettent au manager de venir interroger un agent.
GetResponse est la réponse envoyée par l’agent au manager.
Trap est une alarme envoyée à l’initiative de l’agent au manager, il se déclenche lors d’un
évènement, par exemple une interface en panne ou un seuil atteint.
SNMP envoie ses messages grâce au protocole de transport UDP pour plusieurs raisons :
Un message SNMP est court et tient dans un seul datagramme UDP ;
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
5
On préfère UDP à TCP pour éviter que le trafic de gestion ne prenne trop de place comparé
au trafic de données.
SNMP représente les données dans une base appelée MIB (Management Information Base). La
première version de cette MIB appelée aussi MIB 1 est organisée hiérarchiquement avec des OID
(Object IDentifier) enregistrés par l’ISO qui est une méthode générique de classement d’objets. Les
premiers nœuds de la MIB 1 sont les suivants [Pujolle et al., 2004] :
System : pour la gestion du nœud lui-même
interfaces : pour les ports et interfaces réseau ;
address translation : pour la traduction d’adresses IP ;
IP (Internet Protocol) ;
ICMP (Internet Control Message Protocol) ;
TCP (Transmission Control Protocol) ;
UDP (User Datagram Protocol) ;
EGP (Exterior Gateway Protocol).
La MIB 2 étend la MIB 1 avec deux groupes supplémentaires : transmissions et SNMP. Pour conclure
sur les MIB, il existe la MIB RMON (Remote Monitor Network) qui permet à des équipements SNMP
d’analyser des informations sur les flux et de les stocker : les sondes.
La nouveauté la plus importante de SNMPv3, la dernière version, est la sécurité qui permet
l’authentification et le cryptage. SNMP était à la base très utilisé dans les réseaux locaux IP, il est
aujourd’hui plus largement utilisé et est devenu un standard de la gestion réseau de par sa simplicité
et son acceptation par tous les grands constructeurs.
2.5.3 WBEM
WBEM (Web-based enterprise management) est à l’origine d’un Consortium de constructeurs (BMC
Software, Cisco Systems, Compaq computer corporation, Intel corporation et Microsoft corporation
[Agoulmine et al., 2003]). WBEM est dit comme « une solution de gestion via le web », WBEM
reprend les technologies des solutions de gestions (DMI2, SNMP, CMIP3 et de représentation de
données XML) pour définir un environnement de gestion d’entreprise ouvert.
WBEM repose sur une modélisation des données : CIM (Common information model) : orienté objet,
associations entre les objets et est conçu pour pouvoir être indépendant d’une implémentation de
technologie de gestion particulière.
Le modèle de données CIM est structuré en différents modèles qui permettent de décrire d’une part
l’aspect gestion des objets représentés (grâce au modèle noyau) et d’autre part les objets eux-
mêmes ; les principaux modèles sont présentés ci-dessous :
Réseau
Physique
Support
2 DMI : Distributed Management Interface, protocole de gestion de réseau du DMTF (Distributed Management
Task Force) pour permettre à des machines de diffuser des informations les concernant. 3 CMIP : expliqué dans le chapitre décrivant la gestion TMN
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
6
Système
Utilisateurs
Applications
DAP (Directory Access Protocol)
Périphériques
L’aspect « web » concerne la façon dont les données sont transportées, le protocole WBEM HMMP
(Hypermedia Management Protocol) se sert de http (hypertext transfer protocol) pour transporter
les messages ; d’ailleurs, la sécurité repose sur celle de http c’est-à-dire que l’on profite du protocole
HTTPS (http Secure).
Une première conclusion possible est l’aspect gestion système qui est très développée dans WBEM
et qui délaisse les problématiques réseaux sans apporter de méthodes à valeur ajoutée pour ce
domaine. En effet dans les modèles on va très loin dans la description des systèmes : description des
périphériques, mémoire, processeur, applications, système d’exploitation, threads,… mais il reste
l’implémentation de la gestion réseau avec les problématiques qu’apporte l’OSI (les aires
fonctionnelles, décrites dans la partie 1).
2.5.4 Gestion avec Java : JMAPI et JMX
Java est un langage de développement portable nativement sur différents systèmes d’exploitations, il
est orienté objet, très populaire et développé par ORACLE (anciennement par SUN Microsystems).
SUN a développé une bibliothèque de développement dédiée à la gestion : JMAPI (Java Management
API), qui s’est au fil du temps amélioré et transformé en JMX (Java Management Extension). SUN
propose un produit commercial de gestion basé sur JMX : JDMK (Java Dynamic Management Kit).
La gestion JMX introduit plusieurs concepts :
La représentation des données se fait via des objets gérables appelés MBean,
Des API4 spécifiques font le rôle d’adaptateurs pour les différentes technologies de gestion
(SNMP, TMN,…),
Un agent est composé d’un serveur MBean et un ensemble de MBeans.
Il existe des MBeans standards et génériques, les génériques permettent de représenter des
ressources gérables alors même qu’on n’a pas encore d’information sur leur nature, on pourra
spécialiser ces objets plus tard tandis que les MBeans standards ont des caractéristiques spécialisées
qui sont censées ne pas changer dans le temps. Les constructeurs devraient fournir des MBeans pour
pouvoir gérer leurs équipements.
Les applications de gestion vont interagir avec les objets gérables MBeans via les agents.
La valeur ajoutée de JMX :
La notification d’évènements : Un modèle de notification d’évènements est mis en place
suivant les modèles push et pull, en push l’application de gestion va recevoir les notifications
de manière asynchrone tandis qu’en pull c’est l’application de gestion qui décide du moment
où elle récupère les informations.
4 API : Application Programming Interface, interface de programmation
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
7
Les services de gestion : ce sont des tâches de gestion effectuées par les agents, cela réduit le
trafic de gestion et décharge le gestionnaire qui effectuait à l’origine ces tâches.
L’interopérabilité avec les solutions actuelles : des API fonctionnant comme des adaptateurs
permettent d’intégrer les solutions de gestion actuelles, les API « proxy » s’interfacent avec
les technologies suivantes :
o SNMP,
o TMN,
o Corba,
o CIM/WBEM
o DEN/LDAP
Finalement JMX apporte une solution générique de gestion, couplable aux technologies de gestion
existantes et très ouverte au développement de fonctionnalités, malheureusement sa grande force
est aussi une faiblesse puisque la généricité est telle qu’il reste à structurer des méthodes propres à
la gestion de réseau et aux problématiques mises en évidence par L’ISO : les besoins FCAPS (décrits
au début de ce document). En outre nous n’avons pas d’informations sur le passage à l’échelle,
quelles sont les performances si on a besoin de gérer des millions d’objets MBeans? JMX n’est donc
pas à exclure en termes de gestion de réseau mais à coupler à des solutions qui résolvent l’activité de
gestion.
2.5.5 TMN
TMN est à l’origine de l’ITU-T T (International Telecomunication Union Standardization Sector), et
fait partie de la « recommandation M.3010 » ce monde des télécoms propose une solution voulue
pérenne qui s’adapte aux changements de technologies des opérateurs. TMN organise la gestion de
réseau de manière hiérarchique, représente les données de manière orientée objet et propose un
protocole de communication entre les agents et les managers.
Le protocole de communication est CMIP (common management information protocol) et l’interface
de gestion native est appelée interface Q3, l’interopérabilité avec les protocoles de gestion est
possible grâce à des adaptateurs (fonctionnalités de QAdaptation) : SNMP, TL1 ou propriétaire. Au
niveau du modèle de donnée, le modèle objet est basé sur GDMO (guidelines for description of
managed objects).
TMN est adapté aux grands réseaux :
Distribution des tâches de gestion sur différents systèmes.
Décomposition en « domaines de gestion » : pour gérer les fonctionnalités (pannes,
configuration, performance,…)
L’interopérabilité avec les autres opérateurs a été prévue :
Mécanisme d’échange d’informations entre les domaines de gestion sécurisé
Les différentes architectures TMN :
L’architecture fonctionnelle : elle structure différents blocs fonctionnels (Pannes,
Configuration, Comptabilité,…) et précise leurs interactions avec les différentes interfaces en
prenant comme référence l’interface CMIP Q3.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
8
L’architecture physique : elle concrétise l’architecture fonctionnelle en mettant en
correspondance aux blocs fonctionnels un ou plusieurs bloc physique ; un bloc physique va
donc assurer une ou plusieurs fonctionnalité de gestion.
L’architecture organisationnelle : Elle permet de hiérarchiser la gestion en partant d’une
couche globale de gestion de l’entreprise jusqu’aux couches de gestion des éléments du
réseau comme montré sur le schéma ci-dessous ; ainsi les couches supérieures ont une vue
synthétique et simplifiée des couches inférieures. Chaque couche est en pratique réalisée par
un ensemble de blocs physiques comme montré sur le second schéma ci-dessous (OS :
Operations System, réalise l’opération de gestion ; Q3, X ou M : interface de gestion).
Figure 1 : TMN, couches logiques [Agoulmine et al., 2003]
Gestion de l'entreprise
Gestion des services
Gestion des réseaux
Gestion des éléments du réseau
Eléments du réseau
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
9
Figure 2 : TMN, architecture organisationnelle [Agoulmine et al., 2003]
L’architecture informationnelle : c’est la couche d’abstraction qui permet de gérer le réseau
de manière générique, c’est-à-dire sans avoir besoin de connaitre exactement les protocoles
et techniques à utiliser jusqu’aux équipements. Pour ce faire l’architecture informationnelle
utilise un modèle orienté objet (GDMO, guidelines for definition of managed objects) et
décrit comment un bloc physique va organiser sa base de données d’information (MIB,
Management Information Base), et identifier les objets de manière unique.
TMN introduit des notions très intéressantes en prenant nativement en compte les fonctions de
gestion de réseau, en apportant de la généricité avec la séparation hiérarchique et fonctionnelle et
en permettant l’adaptabilité des interfaces aux autres protocoles de gestion ; l’aspect hiérarchique
et le modèle orienté objet ont été adopté cependant les protocoles spécifiques et les interfaces n’ont
pas été largement adoptés du fait de la complexité du système.
2.5.6 Gestion par politique
La gestion par politique provient du monde des opérateurs télécoms et est un paradigme qui vise à
industrialiser, automatiser à grande échelle la gestion de réseau en ayant plusieurs niveaux
d’abstractions en partant de l’utilisateur qui voudrait que sa « visioconférence passe bien » jusqu’aux
équipements sur lesquels on règlerait une qualité de service spécifique.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
10
Le réseau est organisé hiérarchiquement en nœuds, des nœuds spécifiques (Policy Decision Point,
PDP) qui prennent en compte les spécifications et d’autres critères et diffusent ensuite leurs
décisions à des autres nœuds (Policy Enforcement Point, PEP) qui appliquent les décisions en
traduisant en langage technique.
La communication entre les PDP et les PEP se fait grâce au protocole COPS (Common Open Policy
Service).
Le nœud de décision PDP prend en compte les critères qui se trouvent dans des serveurs :
Le serveur de politiques, Policy Repository dans lequel les politiques sont stockées
BandwitdthBrocker, gestionnaire de bande passante, il a une vue globale sur les ressources
allouées
MobilityBrocker, gestionnaire de mobilité, il permet de gérer la continuité de la qualité de
service
Security Brocker, gestionnaire de sécurité qui comprend un serveur AAA5 pour gérer le
contrôle d’accès (au moment de la connexion au réseau) et également la sécurité des
informations transportées sur le réseau.
Billing, serveur de facturation, gère la facturation du service procuré
Il y a deux modèles de gestion et de contrôle par politique, l’outsourcing et le provisioning.
L’outsourcing consiste à ce que les clients via les nœuds d’application des politiques (PEP)
demandent aux nœuds de décision (PDP) s’ils peuvent utiliser le réseau, généralement via une
demande RSVP6 (RSVP entre le client et le PEP, COPS entre le PEP et le PDP), le PDP visé répond et
autorise ou non la connexion.
Le provisioning : le client négocie avec l’opérateur un Service Level Agreement (SLA) qui indique en
langage non technique la qualité de service désirée, ce SLA se traduit en spécification technique
(Service Level Specification, SLS) qui est stocké dans le Policy Repository et qui sera lu par le PDP lors
de la demande de connexion du client.
2.5.7 Conclusion
Nous avons maintenant abordé les différentes approches de la gestion de réseaux ; la plus
pragmatique et la plus déployée étant SNMP qui elle-même s’inspire de la gestion CMIP en
simplifiant (d’où le « S » de SNMP : Simple) sans être simpliste pour proposer une gestion de réseau
rapide à déployer et supportant des grandes tailles de réseau. Nous avons vu la gestion par le Web
WBEM et son modèle de données CIM qui est très complet mais malgré tout conçu nativement pour
la gestion des systèmes comme des serveurs plutôt que la gestion de réseau. La vision de la gestion
de réseau avec Java, JMX introduit un système générique de gestion sans apporter de méthodes
propres aux problématiques de la gestion de réseau (FCAPS, voir les aires fonctionnelles) ; malgré
tout JMX reste très intéressant de par ses possibilités multiples et son interopérabilité avec les autres
systèmes. L’approche TMN est nécessairement intéressante puisqu’elle est à l’origine du succès
qu’est SNMP, elle n’est cependant pas largement déployée dans son intégralité à cause de sa
complexité. La gestion par politique apporte une réponse intéressante aux opérateurs télécoms en
5 AAA, Authentication, Accounting, Authorization, c’est un modèle de sécurité
6 RSVP, Resource Reservation Protocol, protocole de réservation de ressource
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
11
apportant nativement le principe de SLA (Service Level Agreement) et SLS (Service Level
Specification)
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
12
3 NETCONF Cette partie aborde NETCONF en commençant par décrire la gestion de la configuration de manière
générale puis elle présente la partie protocolaire de NETCONF, son modèle de données YANG et les
implémentations du protocole.
3.1 La gestion de la configuration La gestion de la configuration regroupe l’ensemble des activités qui consistent à gérer les actions
nécessaires à effectuer pour contrôler le comportement du réseau.
Dans la gestion de la configuration d’un réseau, on doit être capable de récupérer des informations
sur l’état actuel de la configuration des équipements et aussi pouvoir éditer ces configurations. Lors
de la résolution de problèmes il est souvent nécessaire de mettre en relation un changement récent
de configuration avec l’apparition du problème, il est aussi nécessaire de pouvoir repasser dans une
version stable de la configuration, la « dernière bonne configuration connue ».
On remarque dans les besoins énoncés ci-dessus la nécessité de mettre en place des bonnes
pratiques, on citera :
Garder un historique des configurations
Ecrire une description concernant l’objet de la modification de la configuration
Ces bonnes pratiques sont garantes d’un bon fonctionnement du réseau mais elles sont lourdes à
appliquer dans un environnement comportant des dizaines voire des centaines d’équipements
réseau.
En effet on distingue différents types d’interface de configurations dont l’accès est standard :
Interface en ligne de commande
o Via un port console
o Via le réseau
par SSH (SecureShell) ou telnet
Interface Web
Malgré tout, les commandes et les données ne sont pas standard, et ce même au sein des produits
d’un constructeur.
De plus certains équipements ont la possibilité de gérer une seule configuration, celle en mémoire
volatile, d’autres peuvent en gérer 2 mais pas plus en général. Une autre limitation provient du fait
qu’en général il n’y a pas de possibilité de retour en arrière au niveau de la configuration (sauf de
manière manuelle).
Afin de fournir des solutions aux problèmes évoqués, des logiciels et des méthodes associées ont vu
le jour, nous allons voir quelques solutions populaires.
CFEngine (Configuration Engine) a été créé en 1933 par Mark Burgess, alors doctorant à l’université
d’Oslo. Le but est l’automatisation de la gestion de la configuration de machines telles que des
ordinateurs, mais aussi des terminaux mobiles (smartphones et tablettes). L’entreprise CFEngine AS
assure le support des utilisateurs et propose une version commerciale : CFEngine Nova. CFEngine a
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
13
été conçu pour des machines à base Unix, il a aussi été porté sur Windows. Le principe est de décrire
l’état final des machines, CFEngine se chargeant de l’atteindre.7 D’un point de vue technique, la base
est la synchronisation de fichiers textes à l’aide d’outils Linux préexistants, un ensemble de méthodes
qui font le cœur de CFEngine et la possibilité d’utilisation d’un système de gestion de version (CVS)
permettant de commenter les changements et de revenir dans des versions antérieures.
RANCID8, Really Awesome New Cisco Config Differ est un logiciel freeware, il permet la supervision
de la configuration d’équipements réseaux. L’outil fonctionne avec:
Cisco (routeurs et switch Catalyst),
Juniper (routeurs),
Catalyst (switch),
Foundry (switch),
Redback (NASs),
ADC EZT3 (multiplexer),
MRTd (et IRRd “like”),
Alteon (switch),
HP (switch ProCurve).
Liste de modules non officiels : ftp://ftp.shrubbery.net/pub/rancid/contrib/
L’outil se connecte à l’équipement à monitorer via le réseau par telnet ou SSH (un fichier, router.db,
contient la liste des adresses des équipements), il effectue des actions spécifiques au matériel pour
récupérer sa configuration logicielle et matérielle, si une version précédente de la configuration
existe et qu’elle est différente, l’auteur de la modification est prié de commenter la modification et
une notification est envoyée par mail.
Le point faible de ce type d’outil est la nécessité de maintenir des méthodes d’accès spécifiques à
chaque constructeur voire à chaque équipement puisque il n’y a pas de protocole standardisé,
malgré tout sa simplicité est sa force et des retours très plaisants ont été faits comme par exemple le
fait que l’ajout systématique de commentaires à la modification d’une configuration permette de
résoudre bien plus facilement les pannes.
Ces outils présentés sont fort pratique, mais il y a encore des manques dans l’aspect gestion de la
configuration, en témoigne la RFC 3535 « Overview of the 2002 IAB Network Management
Workshop »9 publiée en mai 2003, qui a réuni des acteurs de l’IETF et des opérateurs, le but était de
faire un point sur la manière d’interagir avec les équipements réseau et de mettre en avant les
manques. Le constat a été que SNMP était très utilisé et très pratique pour récupérer des
informations grâce à des MIB très bien fournie mais du côté de l’écriture de données SNMP n’était
pas très adapté pour certaines raisons. La principale raison est que les MIB standard et les MIB des
constructeurs ne fournissent pas assez d’objets permettant l’écriture. Une autre constatation est le
fait que la majorité des équipements réseau ont une interface en ligne de commande accessible via
telnet ou ssh mais que celle-ci n’est pas standardisée, enfin les équipements ont aussi souvent des
7 Sources : http://articles.mongueurs.net/magazines/linuxmag95.html, http://en.wikipedia.org/wiki/CFEngine
et http://cfengine.com 8 Source : http://www.shrubbery.net/rancid/
9 Source : http://www.bortzmeyer.org/3535.html
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
14
interfaces web celles-là aussi encore moins automatisables. Les opérateurs ont formulé leur
demande : « des protocoles permettant la gestion en masse des équipements (et, idéalement,
permettant de configurer le réseau, plutôt que chaque équipement isolément) ». Le souhait est un
langage standard pour la gestion de la configuration des équipements réseau, permettant de
sauvegarder complètement une configuration et aussi d’en injecter une complète ou une partie. La
conclusion préconise pour SNMP l’abandon d’objets permettant l’écriture et la normalisation d’un
protocole de configuration bâti sur XML, ce qui a donné NETCONF dans le RFC 4741.
3.2 Le protocole Nous avons vu dans la partie précédente ce qu’était la gestion de la configuration, ses enjeux, des
exemples d’outils connus et les recommandations d’un groupe de travail de l’IETF qui préconise un
protocole standardisé pour la gestion de la configuration bâtie sur XML, c’est donc ce protocole,
NETCONF, que nous allons étudier en détail, la première version a été décrite dans le RFC 4741 en
décembre 2006, le modèle de données qui représente les configurations bâties sur XML est YANG,
publié dans la RFC 6020 en octobre 2010 et une deuxième version de NETCONF a été publiée en juin
2011 dans la RFC 6241. Nous allons donc voir dans cette partie le protocole NETCONF et son modèle
de données YANG tels qu’ils sont décrits par l’IETF puis nous nous intéresserons aux
implémentations.
Représentation des données standardisée
Les configurations sont représentées dans le langage XML.
Mode de communication
Les communications se font suivant le modèle client-serveur, le serveur étant le logiciel résidant sur
l’équipement à gérer et le client étant le logiciel résidant sur la machine centrale qui gère les
configurations des équipements.
Technique de communication
Les échanges de données sont encodés en XML et envoyées via une procédure d’appel distant (RPC,
Remote Procedure Call) à travers une session en mode connectée et sécurisée.
Partitionnement en 4 couches
NETCONF peut être conceptuellement partitionné en 4 couches :
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
15
Figure 3 : couches protocolaires de NETCONF [Enns et al., 2011]
1. La couche sécurisée de transport sert à acheminer les messages entre le client et le serveur.
2. La couche Messages fournit un mécanisme d’envoi indépendant de la couche transport.
3. Un ensemble d’opérations de base existe et les paramètres sont encodés en XML.
4. Le contenu est spécifique à la représentation de la configuration et sera représenté à l’aide
de YANG (décrit dans la partie suivante).
Fonctionnalités (capabilities)
Une fonctionnalité est un ensemble de fonctionnalités qui supplémente les fonctions de base de
NETCONF. Le client peut découvrir les fonctionnalités du serveur et donc utiliser les opérations
décrites dans ces fonctionnalités. Certaines fonctionnalités ont des dépendances à d’autres
fonctionnalités qui sont obligatoires.
Echange des fonctionnalités
Les entités NETCONF échangent leurs fonctionnalités lors de l’établissement de la session.
Fonctionnalités
Fonctionnalité Signification
writable-running Il est possible d’écrire directement dans la configuration actuelle. Cela signifie que l’équipement supporte edit-config et copy-config sur la configuration en cours (la « running configuration »)
Candidate Configuration Permet de manipuler une configuration candidate sans effet sur la configuration en cours ; à tout moment un commit peut être effectué ce qui aura pour effet de placer la configuration candidate en tant que
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
16
configuration en cours Il est possible pour plusieurs sessions NETCONF de modifier la même configuration candidate, il va de soi qu’il est préférable de verrouiller la configuration avant de la modifier
Confirmed Commit Permet de confirmer un commit. Si un commit nécessitant une confirmation ne l’a pas été durant un timeout de 600 secondes (10 minutes), l’ancienne configuration en cours doit être remise en service
Rollback on Error Permet d’effectuer un rollback lors d’une erreur ; en d’autres mots cela remet l’ancienne configuration en cours en service
Validate Permet de vérifier la bonne syntaxe d’une configuration avant de la mettre en service
Distinct Startup Indique que l’équipement supporte une configuration en cours et une configuration de démarrage distincte
URL L’équipement supporte l’utilisation d’une url dans les paramètres « source » et « target »
XPath Indique que l’équipement supporte les expressions XPath dans l’élément « filter »
Tableau 2 : Description des fonctionnalités de Netconf
Opérations
Comme nous avons pu le voir, des messages sont envoyés entre le client et le serveur, ces messages
sont des opérations, NETCONF spécifie un ensemble d’opérations de base que nous allons voir,
cependant un équipement peut annoncer qu’il supporte d’autres opérations qui sont alors
spécifiques à celui-ci.
Les opérations de base
get
get-config
edit-config
copy-config
delete-config
lock
unlock
close-session
kill-session
Get
Permet de récupérer la configuration active et des informations sur le statut de l’équipement, on
peut passer par le paramètre « filter » un filtre qui permettra de restreindre la partie de la
configuration à récupérer ; par défaut toute la configuration sera envoyée.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
17
Get-config
L’opération get-config accepte 2 paramètres, le premier se nomme « source » et permet de spécifier
le nom de la configuration que l’on veut récupérer, le second se nomme filter et permet de spécifier
la partie de la configuration que l’on veut récupérer, par défaut toute la configuration est récupérée.
Il est important de considérer que toutes les opérations ne seront pas forcément réussies et qu’il
faut traiter la réponse pour vérifier si elle est positive, par exemple une erreur résultera en une balise
<rpc-error> contenu dans la réponse <rpc-reply>.
Un exemple contenu dans la RFC 4741 pour récupérer le sous arbre « users » :
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top
xmlns="http://example.com/schema/1.2/config"><users/>
</top>
</filter>
</get-config>
</rpc>
Un exemple de réponse serait alors:
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<type>superuser</type>
<full-name>Charlie Root</full-name>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>
<!-- additional <user> elements appear here... -->
</users>
</top>
</data>
</rpc-reply>
Edit-config
Sert à charger une partie ou une nouvelle configuration dans l’équipement. On peut choisir de
fusionner, remplacer, supprimer ou créer une configuration. Il est possible de tester l’action que l’on
va effectuer en spécifiant le paramètre test et en regardant la réponse. Les erreurs sont gérées avec
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
18
l’option « error-option » ou l’on peut spécifier dès qu’une erreur est détectée des actions à effectuer,
à savoir l’arrêt de l’opération, la poursuite de l’opération et le rollback qui permet de revenir à l’état
avant opération.
Copy-config
Permet de créer ou d’écraser une configuration avec une configuration existante.
Delete-config
Permet de supprimer une configuration, en sachant que la configuration active ne peut être
supprimée.
Lock et unlock
Permet de verrouiller la configuration que l’on passe en paramètre afin qu’aucune autre tentative de
modification ne vienne interférer (utilisation par une autre session NETCONF, un administrateur avec
l’interface en ligne de commande,…).
Unlock permet de déverrouiller la session si elle ne l’a pas déjà été par un timeout ou un unlock
implicite (coupure de la session brutale par exemple).
Seul un client NETCONF qui a verrouillé une configuration peut demander à la déverrouiller.
Close-session
Permet de terminer normalement une session NETCONF. Après une requête close-session, le serveur
va relâcher les verrous en cours et n’acceptera plus de nouvelles requêtes de la session.
Kill-session
Permet de terminer une session NETCONF. Toutes les opérations du serveur en cours sont arrêtées,
les verrous sont relâchés et si un commit était en cours, un roll back est effectué pour revenir à l’état
antérieur.
Exemple de messages échangés
(Source : http://www.netconfcentral.org/netconf_docs)
On suppose que la configuration cible est la « candidate », on verrouille donc la configuration active
puis la candidate, on édite la candidate, on la « publie » puis on déverrouille la candidate et la
configuration en cours :
1. lock <running/> database
2. lock <candidate/> database
3. edit <candidate/> database
4. commit <candidate/> database
5. unlock <candidate/> database
6. unlock <running/> database
Les messages XML suivants seront alors échangés :
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
19
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target><running/></target>
</lock>
</rpc>
# server returns <ok/> status
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target><candidate/></target>
</lock>
</rpc>
# server returns <ok/> status
<rpc message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target><candidate/></target>
<default-operation>none</default-operation>
<test-option>test-then-set</test-option>
<error-option>stop-on-error</error-option>
<nc:config
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns="uri-for-my-data-model-namespace">
<some-existing-node>
<my-new-node nc:operation="create">
<my-new-leaf>7</my-new-leaf>
</my-new-node>
</some-existing-node>
</nc:config>
</edit-config>
</rpc>
# server returns <ok/> status
<rpc message-id="104"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit/>
</rpc>
# server returns <ok/> status
<rpc message-id="105"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target><candidate/></target>
</unlock>
</rpc>
# server returns <ok/> status
<rpc message-id="106"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target><running/></target>
</unlock>
</rpc>
# server returns <ok/> status
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
20
3.3 YANG
Introduction
NETCONF ne donne pas de directives quant à la représentation des données de configuration que
l’on voit sur la figure ci-dessous en « couche 4 ». C’est donc YANG qui va définir cette couche.
Figure 4: couches protocolaires de NETCONF
Ci-dessous une illustration explicite de Andy Bierman (http://www.netconfcentral.org) qui nous
précise que YANG est utilisé dans la couche de données ainsi que dans la définition des données
NETCONF au sein des agents.
Figure 5 : YANG et NETCONF, Andy Bierman
Un exemple d’utilisation de YANG consiste à donner à un logiciel client Netconf le module YANG d’un
serveur Netconf, ainsi le logiciel client pourra interroger le serveur avec les fonctionnalités
spécifiques décrites dans le module YANG.
YANG est un langage de définition de données utilisé pour modéliser les données de configuration de
NETCONF. YANG a été créé par le groupe de travail NETCONF Data Modeling Language (netmod) de
l’IETF spécifiquement pour NETCONF. YANG est décrit dans la RFC 6020.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
21
Pourquoi YANG
YANG a été créé car aucun autre langage ne correspondait à sa destination tout en étant simple
d’emploi.
YANG possède donc les qualités suivantes :
Simple à lire et à apprendre
Ecrit pour NETCONF et la gestion de réseau
Extensible
Une communauté technique ouverte aux nouveaux arrivants
Commence à être utilisé dans d’autres groupes de travail
Types
La structure des données est réalisée en utilisant des types :
Boolean
String
Uint32
(…)
Si un type spécial est désiré on peut le construire, par exemple pour représenter un pourcentage on
utilise le type uint32 et on le restreint pour qu’il soit compris entre 0 et 100 :
typedef percent {
type uint8 {
range "0 .. 100";
}
}
On peut également définir un type comme la réunion de deux autres, c’est le cas de l’adresse ip qui
est la réunion des adresses ipV4 et ipV6 comme illustré ci-dessous.
typedefip-address { type union { type ipv4-address; type ipv6-address; }
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
22
3.4 Les implémentations indépendantes des constructeurs Netconf étant un protocole assez récent, un nombre limité d’implémentations est disponible, nous
allons parler ici des implémentations indépendantes des constructeurs, les implémentations clientes
de Netconf et les implémentations serveurs à installer sur des serveurs génériques à architecture x86
pour les configurer. Nous aborderons les possibilités de gestion de configuration d’équipements
réseau dans les parties suivantes.
Une présentation de Netconf de Carl Moberg (Tail-f) présente une liste des principales
implémentations de Netconf, Tail-f est une entreprise suédoise fondée en 2005 par un groupe de
« vétérans de l’industrie », elle propose des solutions logicielle de gestion générique de réseau en
intégrant une multitude de protocoles de gestion, Tail-f a d’ailleurs une politique de promotion des
standards et notamment celle de Netconf et Yang.
Cette liste a été complétée par des détails et est présentée ci-dessous. Les premières
implémentations de la liste sont des logiciels commerciaux, les autres sont open source.
La plupart des implémentations clientes sont des bibliothèques de code pouvant servir de base à des
applications finales. Les applications clientes finales, comprennent MG-SOFT Netconf Browser,
Netopeer, Yencap et Yuma. MG-SOFT et Yencap fournissent une interface graphique, respectivement
le premier via un client lourd multi plateforme Java et le second via une interface web en sachant
que Yencap est encore à l’état de prototype.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
23
Solution Type Editeur Prix Plateforme Adresse
NETCONF Browser Professional Edition (client)
Shareware MG-SOFT Corporation
1428€ TTC Windows/Mac OS/Linux (Java)
www.mg-soft.si
POCO Netconf (serveur)
Shareware Applied informatics
Sur demande Framework C++ www.appinf.com
NOCVue ConfigMan
ShareWare Velankani Sur demande Non communiqué www.nocvue.com/
NETCONF MindAgent (serveur)
Shareware Oracle/GoAhead
Sur demande Inclus dans le framework « embeddedMIND »
goahead.com
EPIC NETCONF (serveur)
Shareware SNMP Research
Sur demande Non précisé www.snmp.com/
ConfD (serveur) NCS (client)
Shareware Tail-f Systems
Sur demande Framework www.tail-f.com
NetconfX (client)
Open Source, payant si dans une solution commerciale
Centered Logic
Sur demande Framework Java centeredlogic.com
WebNMS Framework (client)
ShareWare WebNMS Sur demande Framework www.webnms.com
Ncclient (client) Open Source Shikhar Bhushan
Open Source Librairie python schmizz.net/ncclient/
Netopeer (client/serveur)
Open Source Radek Krejčí
Open Source Linux code.google.com/p/netopeer/
YencaP (client/server)
Open Source LORIA-INRIA Lorraine, Emmanuel Nataf et Frederic Beck (autheur original : Vincent Cridlig)
Open Source Linux, web UI ensuite.sourceforge.net/
Yuma(client/server)
Open Source Netconf central (Andy Bierman)
Open Source Linux www.netconfcentral.org/
Tableau 3 : Les différents clients NETCONF
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
24
3.5 Les équipementiers réseaux La même présentation10 de Carl Moberg (Tail-f) qui présente les implémentations clientes de Netconf
présente également une liste des principaux constructeurs implémentant Netconf. Il s’agit
principalement d’équipements réseaux tels que des switch et des routeurs mais également des
équipements plus spécifiques adaptés à la distribution de vidéos, à la messagerie électronique, entre
autres.
Constructeur Détails
Alaxala Ethernet switches
Cisco Routeurs et switch IOS 12.4(9)T et supérieurs, IOS XE 2.1 et supérieurs
Ericsson Equipements réseaux
Juniper Networks JUNOS 7.5 and later
RuggedCom Routeurs et switch, RX5000 et MX5000
Taseon Intelligent optical networks, TN 320
Verivue Next-generation video distribution, MDX 9020
Edgeware Servers on-demand TV, WTV-2X
Nexor Messaging Gateways
Telco Systems Carrier Ethernet Multiservice Aggregation, T-Metro 7224 Tableau 4 : Les équipements implémentant NETCONF
10
Présentation de Carl Moberg : http://www.slideshare.net/cmoberg/a-30minute-introduction-to-netconf-and-yang
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
25
4 NETCONF en pratique Nous avons décrit les problématiques de la gestion de la configuration dans un réseau. Nous avons
décrit Netconf, son modèle de données Yang, ses implémentations clientes et serveurs et les
implémentations des équipementiers réseaux, nous avons dit que Netconf était « LA » solution
innovante et générique pour pallier aux défauts des outils et méthodes actuelles de gestion de
configuration, tentons de le démontrer, allons regarder dans des scénarios concrets la valeur ajoutée
de cette nouvelle méthode. Nous aborderons cette partie par une approche pratique en décrivant les
clients et les serveurs que nous allons utiliser et les configurations nécessaires, ensuite nous
décrirons en détail l’implémentation de Cisco puisque c’est celle-ci qui a été choisie pour
l’expérimentation, enfin nous montrerons Netconf dans des cas pratiques au travers de scénarios.
4.1 Premiers pas avec Netconf
4.1.1 Les clients Netconf utilisés
Connexion brute en SSH
Afin de bien comprendre le protocole Netconf, une communication avec un tunnel SSH et des
données brutes transmises a été choisie. Dans cette configuration nous recevons directement un
message hello en XML du serveur et nous devons lui envoyer également un message hello bien
formé avant de commencer à exploiter les fonctionnalités du protocole. Le tunnel se fait depuis un
ordinateur sous Linux en tapant la commande suivante depuis un terminal :
ssh -2 -s <nom d’utilisateur>@<serveur Netconf> netconf
L’option -2 spécifie la version 2 de SSH à utiliser, <nom d’utilisateur> est le nom d’utilisateur habilité
à lancer une session Netconf sur le serveur, <serveur> est l’adresse IP ou le nom à résoudre via le
protocole DNS (Domain Name Server) du serveur, l’option –s avec le mot clé netconf à la fin de la
ligne spécifie le sous-système à utiliser sur l’hôte distant.
Yuma Yangcli
Le logiciel Yuma est maintenu par Andy Bierman, co-auteur de la dernière RFC décrivant Netconf,
aussi auteur du site Netconf central. Yuma est une suite logicielle contenant un serveur (netconfd),
un client (Yangcli) et d’autres outils servant par exemple à valider la syntaxe de modules Yang. Yuma
a été choisi car il commence à prendre de la maturité, il en est à sa version 2 après de nombreuses
améliorations, il est maintenu par un expert du protocole et il présente une finition exemplaire avec
de la documentation très bien fournie, une communauté de développeurs et d’utilisateurs active qui
m’a rendu service pour cette expérimentation. Yuma fonctionne sur les systèmes Linux en mode
ligne de commande très aboutie.
Nous utiliserons donc la partie cliente de Yuma : Yangcli. La partie ci-dessous décrit l’installation de
Yangcli.
Installation de Yuma
Télécharger le paquet correspondant à votre distribution sur le site de l’éditeur:
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
26
http://www.netconfcentral.org/download
Nous allons décrire l’installation pour Ubuntu 11.10 32 bits et Yuma en version 2.1-2.
Après avoir téléchargé le paquet nommé yuma-2.1-2.u1104.i386.deb, ouvrez un terminal et placez-
vous dans le même répertoire que le paquet.
Assurez-vous que les librairies externes requises sont présentes:
mydir> dpkg --list libxml2
Si ces librairies sont installées, vous verrez ce résultat s’afficher :
benoit@benoit-Vostro-1520:~/Téléchargements$ dpkg --list libxml2 Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder | État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements |/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais) ||/ Nom Version Description +++-==============-==============-============================================ ii libxml2 2.7.8.dfsg-4 GNOME XML library
Dans le cas contraire, installez les librairies manquantes à l’aide de la commande suivante :
mydir> sudo apt-get install libxml2
Une fois cette étape préliminaire remplie, vous pouvez installer Yuma :
mydir> sudo dpkg -i yuma-1.13-3.u1004.i386.deb
Le programme client dont nous nous servirons se nomme Yangcli et est dans le répertoire /usr/bin :
-rwxr-xr-x 1 root root 294180 2011-09-28 20:38 /usr/bin/yangcli
MGSoft Netconf Browser
L’entreprise MGSoft travaille depuis 1998 avec le protocole SNMPv3, ils ont développé le logiciel
Netconf Browser en partenariat avec Tail-F (décrit dans les parties précédentes) et l’ont testé avec le
logiciel décrit précédemment, Yuma ainsi qu’un autre, yencap.
Netconf Browser est un client, propose une interface graphique sous Windows et permet de charger
des modules Yang adaptés au serveur avec lequel on interagit, il permet également d’utiliser les
fonctionnalités propres au matériel et les fonctionnalités de base avec un simple clic, le logiciel se
chargeant de générer le code XML approprié. Il est possible de voir les codes XML envoyés et reçus
en allant regarder les fichiers de log, c’est ceux-ci qui ont été utilisés pour comprendre comment le
logiciel et le routeur communiquaient entre eux.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
27
4.1.2 Les serveurs Netconf utilisés
Routeur Cisco
Les équipements réseaux de la salle de TP étant du constructeur Cisco, nous allons nous intéresser à
l’implémentation de Netconf que propose ce constructeur.
Cisco détaille la disponibilité de la fonctionnalité Netconf over SSHv2 dans le tableau ci-dessous11 :
Nom de la fonctionnalité Version de système Information sur la fonctionnalité
Netconf over SSHv2 12.2(33)SRA 12.4(9)T
La fonctionnalité Netconf over SSHv2 permet de gérer la configuration réseau via l’interface en ligne de commande (CLI) à travers une couche transport chiffrée. Le protocole Netconf définit un mécanisme simple à travers lequel un équipement réseau peut être géré, les informations de configuration peuvent être récupérées et des nouvelles données de configuration peuvent être placées et manipulées. Netconf utilise XML pour représenter ses données de configuration et les messages du protocole. Cette fonctionnalité a été introduite dans l’IOS 12.4(9)T.
Tableau 5 : Disponibilité de Netconf dans le système de Cisco
Les routeurs utilisés sont les suivants :
Cisco 2801 IOS 12.4(15) T1
Cisco 1841 IOS 12.4(24) T2
4.1.3 Configuration d’un routeur Cisco
Il faut en premier lieu s’assurer d’avoir un IOS compatible, ceci est décrit dans la partie précédente.
La marche à suivre est la suivante :
Configuration de SSH version 2 (obligatoire)
Configuration de NETCONF avec SSH
Configuration de SSH v2 :
1. enable
11 Source du tableau :
http://www.cisco.com/en/US/docs/ios/12_2sr/12_2sra/feature/guide/srnetcon.html#wp1068708
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
28
2. configure terminal
3. hostname hostname
4. ip domain-name name
5. crypto key generate rsa
6. ip ssh [timeout seconds | authentication-retries integer]
7. ip ssh version 2
Ensuite :
#aaa new-model
#username cisco password 0 cisco
On peut dès à présent tester la connectivité SSH avec Putty par exemple.
Configuration de NETCONF :
1. enable
2. configure terminal
3. netconf ssh [acl access-list-number]
4. netconf lock-time seconds
5. netconf max-sessions session
Une fois la configuration effectuée, on peut tester avec succès Netconf, cependant si on copie la
configuration du routeur dans un fichier, et qu’on la remet dans un routeur sans configuration, il ne
faudra pas oublier de retaper manuellement l’instruction de génération des clés RSA (crypto key
generate rsa).
Vérifier la configuration
Pour visualiser l’état du protocole Netconf sur le routeur, les commandes suivantes sont disponibles :
Show netconf counters
Show Netconf session
Les copies d’écran ci-dessous montrent les sorties de ces commandes.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
29
routeur-netconf#show netconf counters
NETCONF Counters
Connection Attempts:2: rejected:0 no-hello:0 success:2
Transactions
total:3, success:2, errors:1
detailed errors:
in-use 0 invalid-value 0 too-big 0
missing-attribute 0 bad-attribute 0 unknown-
attribute 0
missing-element 0 bad-element 0 unknown-element 0
unknown-namespace 0 access-denied 0 lock-denied
0
resource-denied 0 rollback-failed 0 data-exists
0
data-missing 0 operation-not-supported 0 operation-
failed 1
partial-operation 0
On voit sur la sortie ci-dessus que deux tentatives de connexion ont été effectuées, 2 ont réussi.
Dans les transactions, on en compte 3 dont une en erreur et 2 qui ont réussi ; l’erreur est
« operation-failed » c’est effectivement un client qui a effectué une opération non compatible.
routeur-netconf#show netconf session
Netconf Sessions: 1 open, maximum is 5
Remote connection via SSH by user(cisco) from 192.168.10.1:35536,
connect
Tx 478 bytes (1 msg), Rx 321 bytes (1 msg, 0 segmented)
Established at *10:00:28.291 UTC Thu Nov 24 2011
Last operation at *00:00:00.000 UTC Mon Jan 1 1900
Last successful operation at *10:00:28.291 UTC Thu Nov 24 2011
Session id:1697800880
Connection waiting for transactions
Sur la sortie ci-dessus, on voit qu’une session Netconf est active et que 5 peuvent l’être au maximum.
On remarque que la session active est avec l’adresse IP 192.168.10.1 qui est mon ordinateur portable
et l’utilisateur « cisco » a été utilisé pour l’authentification, en effet ce n’est pas le mot de passe du
mode privilégié qui est utilisé, il n’est pas pris en compte.
On remarque également l’id de la session, (Session id:1697800880) qui est gérée par le serveur
Netconf donc le routeur dans notre cas.
Afficher le schéma du modèle de données
Sur certaines versions d’IOS il est possible d’afficher le schéma du modèle de données de
l’équipement, la commande est la suivante :
Show netconf schema
On peut voir en annexe un exemple de schéma.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
30
4.1.4 Le cas de l’implémentation de Cisco
Les premiers tests avec les routeurs Cisco (décrits précédemment) ont été quelque peu
décourageants, en effet aucun client ne parvenait à établir une communication ni avec le protocole
de base 1.0 qui est la première RFC ni avec le protocole de base 1.1 qui est la dernière RFC décrivant
le protocole Netconf. Les échanges ont donc été testés en ligne de commande avec un tunnel ssh
depuis une machine UNIX et j’ai découvert que le protocole Netconf n’était pas respecté, les
messages n’étant pas bien formés. De plus Cisco ne fournissant pas le modèle de données spécifique
au matériel au format YANG, j’ai continué les essais à tâtons, je suis parvenu en m’adaptant au
matériel à établir une session Netconf avec succès, à récupérer la configuration au format CLI de
Cisco ainsi qu’au format XML.
Une discussion par mail avec Juergen Schoenwaelder, co-auteur de la dernière RFC décrivant Netconf
m’a indiqué que malgré les améliorations de Cisco sur Netconf, ce n’était pas la meilleure plate-
forme d’apprentissage de ce protocole.
Une autre discussion avec le développeur du logiciel client Netconf (et également serveur) YUMA,
également co-auteur de la dernière RFC décrivant Netconf : Andy Bierman, a mis en évidence la non
compatibilité de l’implémentation de Cisco notamment en montrant un bug décrit dans les annonces
de fonctionnalités du routeur.
L’équipe de MG-Soft ayant bien voulu me faire essayer leur logiciel Netconf Browser, je leur ai fait
part des incompatibilités rencontrées et ils ont été très réactifs pour essayer de les comprendre, dans
un autre temps ils m’ont envoyé une version modifiée de leur logiciel qui acceptait de recevoir un
message non standard de la part du serveur, malgré cette modification, un échange complet avec
récupération ou édition de la configuration n’est pas possible puisque le modèle de données YANG
de l’équipement Cisco n’est pas fourni ; de plus même les opérations standards ne nécessitant pas de
connaitre le modèle de données spécifique échouent, en effet le parseur XML ne parvient pas à
interpréter les messages non standards. L’équipe de MG-Soft étant très encline à pouvoir adapter
son logiciel à l’implémentation de Cisco pour être complète, elle m’a proposé d’accéder à distance au
routeur pour comprendre les adaptations à effectuer, seulement cette solution n’a pas été choisie
pour la raison que je vais vous expliquer.
La raison de mon choix de ne pas persévérer à adapter un client à l’implémentation Netconf de Cisco
a été prise en fonction de recherches sur ladite implémentation. Un document récent12 décrivant un
des routeurs de Cisco publié en octobre 2009 et mis à jour en février 2011 indique que
l’implémentation de Cisco se base sur le draft-ietf-netconf-prot-07 [Enns, 2005] publié le 29 juin
2005, brouillon qui a servi à rédiger la première version de la RFC de Netconf. Le document de Cisco
indique également qu’un modèle de données basé sur XML est disponible et spécifique à un
équipement, ce n’est donc pas le standard YANG qui est sorti plus tard.
Sachant que les dernières versions des équipements de Cisco utilisent une version ancestrale du
protocole Netconf (le brouillon indique qu’il expirera le 31 décembre 2005), et que les logiciels
clients utilisent les dernières versions du protocole Netconf avec le modèle de données YANG, une
rétro compatibilité d’un client serait trop spécifique à développer et serait contre-productif.
12
Cisco 3945 Integrated Services Router manageability Bulletin http://www.cisco.com/en/US/prod/collateral/routers/ps10537/product_bulletin_ISRG2_Manageability.pdf
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
31
Avant d’en arriver à cette conclusion, beaucoup de temps a été passé à essayer de faire
communiquer un logiciel client avec l’implémentation routeur de Cisco, nous détaillons maintenant
cette partie.
La partie ci-dessous décrit une connexion à un routeur Cisco avec le client Yangcli :
Yangcli, Connection au serveur
On lance yangcli :
>yangcli
On entre en mode interactif.
On va se connecter au routeur en spécifiant d’utiliser le port 22 :
yangcli> connect 192.168.10.254 ncport 22 Enter string value for leaf <user> [cisco] yangcli:connect> cisco Enter string value for leaf <password> [****] yangcli:connect> yangcli: Starting NETCONF session for cisco on 192.168.10.254 mgr_hello: no writable target found for session 1 (a:1698708704) NETCONF session established for cisco on 192.168.10.254 Client Session Id: 1 //ID de la session du serveur, obligatoire Server Session Id: 1698708704 Server Protocol Capabilities //Cela signifie que l’on utilisera la première version de la RFC de Netconf (autre valeur possible : 1.1) base:1.0 // Indique que l’équipement supporte une configuration en cours et une configuration de démarrage distincte startup:1.0 Server Module Capabilities None Server Enterprise Capabilities // Il est possible d’écrire directement dans la configuration actuelle. Cela signifie que l’équipement supporte edit-config et copy-config sur la configuration en cours (la « running configuration ») Cependant c’est un bug de Cisco, l’URI correcte est « urn:ietf:params:netconf:capability:writable-running:1.0 » urn:ietf:params:netconf:capability:writeable-running:1.0 // L’équipement supporte l’utilisation d’une url dans les paramètres « source » et « target » urn:ietf:params:netconf:capability:url:1.0 urn:cisco:params:netconf:capability:notification:1.0 Protocol version set to: RFC 4741 (base:1.0) //Etant donné le bug de “writeable-running” plus haut, la configuration cible par défaut n’est pas initialisée, il n’y aura pas d’édition standard de la cible Default target set to: none Save operation mapped to: none Default with-defaults behavior: unknown Additional with-defaults behavior: unknown Checking Server Modules...
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
32
Warning: skipping enterprise capability for URI 'urn:ietf:params:netconf:capability:writeable-running:1.0' Warning: skipping enterprise capability for URI 'urn:ietf:params:netconf:capability:url:1.0' Warning: skipping enterprise capability for URI 'urn:cisco:params:netconf:capability:notification:1.0' yangcli cisco@192.168.10.254> //A ce point-là, Yangcli n’a pas de module YANG du serveur pour interagir avec lui (autrement que par des actions standard basiques ; si Cisco les fournissait, il faudrait les mettre dans le répertoire des modules puis utiliser la commande « mgrload <nom du module> ».
Malgré les incompatibilités rencontrées (Cisco ne fournit pas de module Yang, le routeur utilise une
version brouillon publiée avant la première RFC et il y’a un bug de nom de fonctionnalité), nous
allons continuer et tenter d’effectuer une fonctionnalité standard « get ».
Yangcli, récupération de données
Le raccourci pour la fonctionnalité get est simplement « get ».
yangcli cisco@192.168.10.254> get
Afin de voir les échanges XML, on peut lancer Yangcli en mode debug avec les commandes
suivantes :
//On utilisera le niveau 4 qui est le niveau maximum de détails de débogage --log-level=<debug> //La commande ci-dessous sert à spécifier le chemin et le nom du fichier de logS --log=~/test.log
Ces commandes sont à rajouter lors du lancement du logiciel Yangcli si on fait la connexion en même
temps.
On peut alors voir la sortie XML du logiciel lors de l’appel de la commande get :
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="1"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>
//indications de Cisco sur le caractère spécial en fin de ligne : "All NETCONF requests must end with ]]>]]> which denotes an end to the request. Until the ]]>]]> sequence is sent, the device will not process the request." (source : http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_cns_netconf.html#wp1054570) On remarque que Yangcli écrit également cette suite de caractères special. </rpc>]]>]]>
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
33
<?xml version="1.0" encoding="UTF-8"?><rpc-reply message-id="1"
xmlns="urn:ietf:params:netconf:base:1.0"><data><cli-config-data-
block>!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname routeur-netconf
!
boot-start-marker
boot-end-marker
!
logging message-counter syslog
!
//Pour des raisons de lisibilité, le milieu de la sortie a été tronqué !
!
!
!
scheduler allocate 20000 1000
netconf max-sessions 5
netconf lock-time 60
netconf ssh
end
</cli-config-data-block></data></rpc-reply>
//On Remarque que sur cette fin de ligne, il n’y a pas la suite de caractères spéciaux, est-ce un bug du routeur? mgr_top: get node failed (xml reader EOF); session dropped
//Dans tous les cas le parseur XML du logiciel Yangcli n’a pas réussi a obtenir la fin du message et ceci résulte en une coupure brutale de la session et en un arrêt du logiciel, on ne verra apparaitre la configuration du routeur que dans le log Shutting down yangcli
Etant donné qu’il n’est pas possible d’effectuer des actions de base avec Yangcli, je ne persévèrerai
pas avec celui-ci, le logiciel MGSoft Netconf browser n’étant pas non plus en mesure de
communiquer avec le routeur, nous allons effectuer nos tests en mode ligne de commande avec un
tunnel SSH sous Linux.
SSH brut, connexion
La ligne de commande pour se connecter en SSH a été vue dans la partie qui décrit les clients, nous
verrons directement les sorties XML.
Comme l’indique la RFC6241 de Netconf, lors de l’établissement de la session, le client et le serveur
s’envoient un message « hello » et s’échangent leurs fonctionnalités.
Les messages Hello sont envoyés dès l’établissement de la session, sans attendre aucun message, de
la part du serveur et du client.
Un message Hello s’écrit en XML de la façon suivante :
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
34
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.1 </capability> <capability> urn:ietf:params:netconf:capability:startup:1.0 </capability> <capability> http://example.net/router/2.3/myfeature </capability> </capabilities> <session-id>4</session-id> </hello>
Le support de la capacité « base » est obligatoire, il indique la version de Netconf qui sera utilisée 1.0
ou 1.1. Le client et le serveur doivent obligatoirement utiliser la même version de base, si deux
versions sont communément annoncées par le client et le serveur, la version la plus haute sera
utilisée.
Le serveur doit annoncer le numéro de session dans la balise « session-id » et le client ne doit pas
annoncer de numéro de session (dixit la RFC).
Voyons dans ce tableau récapitulatif les messages que doivent s’envoyer le client et le serveur :
Contenus des messages Hello envoyés lors de l’établissement de la session :
Session id Base Autres fonctionnalités
Description Numéro de session
Capacité obligatoire, indique la version de Netconf qui sera utilisée
Client Non Oui
Serveur oui Oui
Le message hello que nous allons envoyer comportera donc le paramètre base 1.0.
Voici le message hello à envoyer selon la RFC :
Seulement, pour s’adapter au routeur, nous allons lui envoyer un message hello comme lui les forme
et comme la documentation de Cisco le préconise :
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
35
Le message hello du routeur devrait faire apparaitre le paramètre base, l’id de session ainsi que le
support d’autre fonctionnalités :
On voit bien le paramètre base 1.0, on se basera donc sur la première version de la RFC, on a
également d’autres fonctionnalités qui sont décrites dans la partie précédente de manière détaillée
(partie Yuma).
On voit également l’id de session, c’est ce que préconise la RFC.
Jusque ici, la connexion s’est correctement effectuée, le client et le serveur se sont correctement
échangés les messages hello et on peut vérifier dans le routeur avec la commande show netconf
session qu’une session est bien active.
SSH brut, récupération de données
Nous allons maintenant effectuer une action de base : récupérer la configuration, pour ce cas
présent, on n’a pas besoin du schéma du routeur car c’est une opération standard dont la syntaxe est
la suivante :
La syntaxe est reprise à la RFC, il faut encapsuler la requête dans un message RPC et donner un
message-id en attribut afin qu’on puisse identifier la réponse dans le cas où plusieurs requêtes
seraient en cours.
La réponse est la suivante :
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
36
//Le milieu a été tronqué pour des raisons de lisibilité
On voit bien dans la réponse l’id rpc qui correspond à la requête et on remarque que le routeur a mis
la configuration dans les balises « cli-config-data-block » qui est une sous balise de « data ».
En regardant dans le schéma de l’équipement (voir annexe), on voit que dans le nœud « source »
figure la type de données CLI en bloc vu précédemment mais également « <xml-config-data> » qui
représente la configuration du routeur en XML, nous allons donc selon ce schéma extraire du routeur
sa configuration en XML.
Le message formé sera le suivant :
On utilisera la balise filter et on spécifiera le format qui est décrit dans le schéma.
La réponse du routeur est la suivante :
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
37
//Le milieu a été tronqué pour des raisons de lisibilité
Vous pouvez retrouver la réponse non tronquée au format XML dans l’annexe.
Cette partie a expliqué en détails l’implémentation Netconf de Cisco, nous avons remarqué que celle-
ci utilisait une version pré-RFC et qu’à l’heure actuelle les clients se basant sur les RFC récentes ne
pouvaient communiquer avec l’IOS de Cisco, il est possible que Cisco ait développé une nouvelle
version de son implémentation mais les quelques documentations de Netconf sont assez anciennes
et les récentes documentations des équipements ne parlent pas d’une autre version. Evidemment il
va sans dire que d’autres équipementiers sont sans doute plus à jour dans ce domaine et c’est vers
eux qu’il faudra se tourner si on veut absolument utiliser Netconf avec des clients standards, dans le
cas contraire il faudra développer un outil exclusivement adapté au matériel Cisco comme le décrit la
documentation Cisco « enhanced device interface, Netconf GUI13 ». Nous allons donc continuer nos
tests sans client autre que des messages XML échangés à travers un tunnel SSH en ligne de
commande, et cela au travers de scénarios.
13
Cisco EDI Netconf GUI http://www.cisco.com/en/US/docs/net_mgmt/enhanced_device_interface/2.2/developer/guide/ntcfapp.html
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
38
4.2 Scénario salle de travaux pratiques de services réseaux à l’UTT Notre expérience va consister à utiliser Netconf pour configurer un environnement réseau.
L’environnement réseau choisi est celui d’une salle de TP dont l’architecture est décrite sur le
schéma ci-dessous :
Figure 6 : Architecture du scénario
L’architecture est composée d’un routeur central connecté à un Switch sur lequel tous les binômes
d’étudiants viennent connecter leur architecture qui est décrite dans le schéma logique ci-dessus.
Pour focaliser notre travail sur Netconf et simplifier l’architecture, on ne configurera pas le lien qui
part du routeur central vers l’Internet, il n’est d’ailleurs pas représenté sur le schéma ci-dessus.
La première étape va consister à reproduire le réseau de test sans mettre en place Netconf, on
utilisera le logiciel de simulation de réseau Cisco Packet Tracer. Ensuite on décrira les tests qui
permettent d’attester de la bonne configuration du réseau. Ensuite on précisera quels équipements
pourront être gérés avec Netconf et on donnera leur configuration. L’étape suivante consiste à
décrire les prérequis à la configuration avec Netconf de manière littéraire puis de manière technique.
Enfin on pourra déployer la configuration et effectuer les tests.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
39
4.2.1 Schéma d’adressage du réseau de test
Binôme 1 Binôme 2
Partie centrale
172.16.1.0/30 172.16.2.0/30
192.168.1.0/25
192.168.1.128/25 192.168.2.0/25192.168.2.128/25
.2 .2
.1.1
.126.254
.126.254
.1.129
.1 .129
Figure 7 : Schéma d'adressage du réseau
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
40
4.2.2 Schéma physique du réseau de test
RT CENTRAL
RT Binome 2RT Binome1
SW CENTRAL
SW Binome 1SW Binome 2
Binôme 1Binôme 2
Partie centrale
Server 1 Server 2PC 1 PC 2
Fa0/24
Fa0/1 Fa0/2
Fa0/24Fa0/24
Fa0/1
Fa0/1Fa0/1
Fa0/1 Fa0/2Fa0/1 Fa0/2
Fa0/0Fa0/0
Figure 8 : Schéma physique du réseau
4.2.3 Tests prouvant la bonne configuration du réseau
On utilisera des ping icmp pour vérifier la bonne configuration du réseau.
La liste des ping est la suivante :
De PC1 à PC2
De PC1 à Server2
De PC1 à Server 1
4.2.4 Equipements à configurer avec Netconf
La liste des équipements dont la configuration pourra être gérée avec Netconf est la suivante :
Le routeur central, Cisco 1841, IOS 12.4(24)T2
Les routeurs des binômes, Cisco 2801, IOS 12.4(15)T1
Le switch central, Cisco 2950, IOS 12.1(22)EA4
Les switch des binômes, Cisco 2960, IOS 12.2(25)SEE3
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
41
4.2.5 Configuration des équipements à configurer avec Netconf
Configuration du routeur central :
version 12.4 hostname RT-Central ! interface FastEthernet0/1 no ip address duplex auto speed auto ! interface FastEthernet0/1.1 encapsulation dot1Q 1 native ip address 172.16.1.2 255.255.255.252 no shutdown ! interface FastEthernet0/1.2 encapsulation dot1Q 2 ip address 172.16.2.2 255.255.255.252 no shutdown ! router ospf 10000 network 172.16.1.0 0.0.0.3 area 30 network 172.16.2.0 0.0.0.3 area 30 ! ip classless ! end
Configuration du Switch central :
version 12.2 hostname SWCentral ! interface FastEthernet0/1 switchport mode access ! interface FastEthernet0/2 switchport access vlan 2 switchport mode access ! interface FastEthernet0/24 switchport mode trunk ! end
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
42
Configuration du routeur du binôme 1 :
version 12.4 ! hostname RT-Binome1 ! interface FastEthernet0/0 no ip address duplex auto speed auto ! interface FastEthernet0/0.1 encapsulation dot1Q 1 native ip address 192.168.1.126 255.255.255.128 ! interface FastEthernet0/0.2 encapsulation dot1Q 2 ip address 192.168.1.254 255.255.255.128 ! interface FastEthernet0/1 ip address 172.16.1.1 255.255.255.252 duplex auto speed auto ! router ospf 10 redistribute connected subnets network 172.16.1.0 0.0.0.3 area 30 ! ip classless ip route 0.0.0.0 0.0.0.0 172.16.1.2 ! end
Configuration du Switch du binôme 1:
version 12.2 ! hostname Switch ! interface FastEthernet0/1 switchport access vlan 1 switchport mode access ! interface FastEthernet0/2 switchport access vlan 2 switchport mode access ! interface FastEthernet0/24 switchport mode trunk ! end
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
43
La configuration du switch du binôme 2 est la même que celui du binôme 1, la configuration du
routeur du binôme 2 est la même que celle du binôme 1 à l’exception près de l’adressage qui est à
respecter, la seule instance d’OSPF est également dans la zone 30.
4.2.6 Prérequis à la configuration avec Netconf
Les IOS implémentant Netconf sont décrits dans les parties précédentes, il est nécessaire que les
équipements à gérer avec Netconf implémentent Netconf.
Afin que le client Netconf puisse configurer les équipements réseau, les éléments suivants sont
requis :
Une connectivité réseau entre l’équipement et le client Netconf
Le paramétrage Netconf de l’équipement (décrit en détail dans la partie « configuration d’un
routeur »)
Ensuite il est nécessaire que le client Netconf connaisse la version de Netconf de l’équipement ainsi
que le modèle de données de l’équipement ; dans notre cas la version de Netconf des équipements
Cisco respecte le draft-ietf-netconf-prot-0714 et le modèle de données utilisé sera la version CLI de la
configuration.
Pour que le client Netconf puisse avoir une connectivité réseau avec les équipements, j’ai choisi de
placer les équipements dans un segment dédié et de placer également le client dans le même
segment :
14
http://tools.ietf.org/html/draft-ietf-netconf-prot-07
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
44
.2
.3
.4.7
.6
.5
.1
192.168.100.0/24
VLAN 100
Serveur NETCONF Client NETCONF
Figure 9 : Segment dédié à NETCONF
On remarquera que les routeurs utilisés n’ont que deux interfaces réseau physique et on en utilise
une pour la gestion Netconf, on utilisera donc une sous interface logique sur les routeurs pour ne pas
limiter le nombre d’interfaces dédiées à la fonction principale des routeurs.
La configuration « prérequis » des équipements réseau est donc la suivante :
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
45
Configuration des routeurs :
! aaa new-model ! username cisco password 0 cisco ! ip domain name domain1.com ! ip ssh version 2 ! netconf max-sessions 5 netconf lock-time 300 netconf ssh ! interface FastEthernet0/1 no ip address duplex auto speed auto ! interface FastEthernet0/1.100 encapsulation dot1Q 100 ip address 192.168.100.4 255.255.255.0 ! ! end
On remarque qu’on a indiqué à la sous interface de marquer ses trames avec le VLAN 100 et qu’on a
configuré Netconf avec SSH comme indiqué dans les parties précédentes.
Les autres routeurs ont la même configuration de Netconf et du VLAN, ils ont une adresse IP
différente que l’on peut voir dans le schéma ci-dessus.
Il ne faut pas oublier de générer les clés SSH la première fois, comme le décrit la partie
« configuration d’un routeur » (crypto key generate rsa).
Les switch utilisés en salle de TP n’implémentant pas Netconf, on manipulera donc leur configuration
de manière classique (avec une connexion série ou avec une connexion SSH ou encore Telnet),
cependant la configuration de Netconf aurait été la même et on aurait donné les adresses IP
respectives aux Switch en mettant une adresse IP à l’interface « VLAN 100 ».
Une fois que les routeurs sont configurés selon le prérequis, il est nécessaire d’enregistrer cette
configuration dans la mémoire de démarrage, appelée startup configuration, la commande ci-
dessous effectue cet enregistrement :
Write memory
La commande suivante est aussi possible :
copy running-config startup-config
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
46
Remarque : le besoin d’enregistrer les configurations en mémoire non volatile est justifié si on veut
gérer de manière systématique les équipements avec Netconf.
4.2.7 Déploiement de la configuration
L’étape finale qui va consister à déployer la configuration est maintenant possible.
Le prérequis qui impose que les routeurs aient une connectivité réseau avec le client Netconf et qui
indirectement nous a amené à créer une sous interface supplémentaire amodifié la configuration des
routeurs, voici la nouvelle configuration du routeur central :
! hostname RT-Central ! ! aaa new-model ! username cisco password 0 cisco ! ip ssh version 2 ! netconf max-sessions 5 netconf lock-time 60 netconf ssh ! interface FastEthernet0/1 no ip address duplex auto speed auto ! interface FastEthernet0/1.1 encapsulation dot1Q 1 native ip address 172.16.1.2 255.255.255.252 ! interface FastEthernet0/1.2 encapsulation dot1Q 2 ip address 172.16.2.2 255.255.255.252 ! interface FastEthernet0/1.100 encapsulation dot1Q 100 ip address 192.168.100.4 255.255.255.0 ! router ospf 10000 log-adjacency-changes network 172.16.1.0 0.0.0.3 area 30 network 172.16.2.0 0.0.0.3 area 30 ! ip classless ! ! end
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
47
Ce qui change c’est la configuration « prérequis », l’activation de Netconf avec SSH.
C’est donc cette configuration que l’on injectera dans le routeur central.
La configuration des routeurs « binôme 1 » et « binôme 2 » change également, en effet dans le
scénario de base sans Netconf, l’interface des routeurs allant vers le switch central était unique, on a
maintenant besoin de la diviser en deux interfaces logiques, une qui assurera la fonction d’origine et
une autre qui assurera la connectivité réseau jusqu’au client Netconf.
La configuration du routeur « binome 1 » sera donc la suivante :
! hostname RT-Binome1 ! ip domain name domain1.com ! aaa new-model ! username cisco password 0 cisco ! ip ssh version 2 ! netconf max-sessions 5 netconf lock-time 300 netconf ssh ! interface FastEthernet0/0 no ip address duplex auto speed auto no shutdown ! interface FastEthernet0/0.1 encapsulation dot1Q 1 native ip address 192.168.1.126 255.255.255.128 no shutdown ! interface FastEthernet0/0.2 encapsulation dot1Q 2 ip address 192.168.1.254 255.255.255.128 no shutdown ! interface FastEthernet0/1 no ip address duplex auto speed auto no shutdown ! interface FastEthernet0/1.1 encapsulation dot1Q 1 native ip address 172.16.1.1 255.255.255.252 no shutdown
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
48
! interface FastEthernet0/1.100 encapsulation dot1Q 100 ip address 192.168.100.2 255.255.255.0 no shutdown ! interface Vlan1 no ip address shutdown ! router ospf 10 log-adjacency-changes redistribute connected subnets network 172.16.1.0 0.0.0.3 area 30 ! ip classless ip route 0.0.0.0 0.0.0.0 172.16.1.2 ! end
La configuration du routeur « binome 2 » diffère dans l’adressage réseau.
Etant donné que l’implémentation de nos routeurs Cisco n’a pas la fonctionnalité « candidate », et a
la fonctionnalité « writable running » ainsi que la fonctionnalité « startup » ce qui signifie que la
configuration active est directement éditable et qu’il est possible de pérenniser la configuration dans
une mémoire non volatile, nous allons verrouiller la configuration active, l’éditer puis la déverrouiller.
Il aurait cependant été intéressant de voir le scénario avec une configuration candidate ou on aurait
pu tester les fonctions de commit et de roll back (retour en arrière) en cas d’erreur.
La procédure va être la suivante :
1. Connexion au serveur
2. Envoi du message Hello
3. Verrouillage de la configuration en cours (running)
4. Edition de la configuration en cours
5. Retrait du verrou sur la configuration en cours
6. Fermeture de la session
Ces opérations vont être appliquées sur les trois routeurs.
Nous nous connectons donc au routeur central avec la commande suivante (le fait que le routeur
auquel on se connecte ce soit le routeur central est arbitraire, on choisira celui avec l’adresse IP se
terminant en .4) :
ssh -2 -s cisco@192.168.100.4 netconf
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
49
On envoie le message Hello suivant :
<?xml version="1.0" encoding="UTF-8"?> <hello> <capabilities> <capability>urn:ietf:params:netconf:base:1.0</capability> </capabilities> </hello>]]>]]>
Verrouillage de la configuration en cours :
<?xml version="1.0" encoding="UTF-8"?> <rpc message-id="101"> <lock> <target><running/></target> </lock> </rpc>]]>]]>
Réponse du routeur :
<?xml version="1.0" encoding="UTF-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:netconf:base:1.0"> <ok /> </rpc-reply>]]>]]>
Remarque : on peut vérifier que la configuration en cours est bien verrouillée en essayant de la
modifier en mode ligne de commande classique, ça ne devrait pas être possible :
On change le lock time de netconf (exemple parmi un autre) routeur-netconf(config)#netconf lock-time 280 Configuration mode locked exclusively by user 'unknown' process '141' from terminal '0'. Please try later.
On remarque que la configuration est bien verrouillée.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
50
On édite la configuration avec le message edit-config, on choisit le mode <cli-config-data>, on aurait
pu choisir <cli-config-data-block> qui est le format brut (comme à la sortie de la commande show
running configuration) ou bien le mode <xml-config-data> qui est la représentation sous forme de
balises de la configuration.
<?xml version="1.0" encoding="UTF-8"?> <rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target><running/></target> <config> <cli-config-data> <cmd>hostname RT-Central</cmd> <cmd>aaa new-model</cmd> <cmd>ip domain name domain1.com</cmd> <cmd>username cisco password 0 cisco</cmd> <cmd>ip ssh version 2</cmd> <cmd>netconf max-sessions 5</cmd> <cmd>netconf lock-time 300</cmd> <cmd>netconf ssh</cmd> <cmd>interface FastEthernet0/1</cmd> <cmd> no ip address</cmd> <cmd> duplex auto</cmd> <cmd> speed auto</cmd> <cmd>interface FastEthernet0/1.1</cmd> <cmd> encapsulation dot1Q 1 native</cmd> <cmd> ip address 172.16.1.2 255.255.255.252</cmd> <cmd>interface FastEthernet0/1.2</cmd> <cmd> encapsulation dot1Q 2</cmd> <cmd> ip address 172.16.2.2 255.255.255.252</cmd> <cmd>interface FastEthernet0/1.100</cmd> <cmd> encapsulation dot1Q 100</cmd> <cmd> ip address 192.168.100.4 255.255.255.0</cmd> <cmd>router ospf 10000</cmd> <cmd> log-adjacency-changes</cmd> <cmd> network 172.16.1.0 0.0.0.3 area 30</cmd> <cmd> network 172.16.2.0 0.0.0.3 area 30</cmd> <cmd>ip classless</cmd> </cli-config-data> </config> </edit-config> </rpc>]]>]]>
La réponse sur serveur:
<?xml version="1.0" encoding="UTF-8"?> <rpc-reply message-id="102" xmlns="urn:ietf:params:netconf:base:1.0"> <ok /> </rpc-reply>]]>]]>
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
51
Si le mode candidate avait été disponible, on aurait pu faire un “commit”:
<?xml version="1.0" encoding="UTF-8"?> <rpc message-id="103"> <commit/> </rpc>]]>]]>
Dans notre cas ce n’est pas nécessaire.
On peut retirer le verrou de la configuration en cours :
<?xml version="1.0" encoding="UTF-8"?> <rpc message-id="104"> <unlock> <target><running/></target> </unlock> </rpc>]]>]]>
Réponse du serveur :
<?xml version="1.0" encoding="UTF-8"?> <rpc-reply message-id="104" xmlns="urn:ietf:params:netconf:base:1.0"> <ok /> </rpc-reply>]]>]]>
Et pour finir on peut clore la session :
<?xml version="1.0" encoding="UTF-8"?> <rpc message-id="105"> <close-session/> </rpc>]]>]]>
Réponse du serveur :
<?xml version="1.0" encoding="UTF-8"?> <rpc-reply message-id="105" xmlns="urn:ietf:params:netconf:base:1.0"> <ok /> </rpc-reply>]]>]]> Connection to 192.168.100.4 closed by remote host.
Le routeur “Routeur central” est maintenant configuré comme voulu.
Les mêmes étapes sont à répéter sur les routeurs « binome 1 » et « binome 2 » en changeant la
configuration envoyée.
La fonction « notification » de Netconf n’a pas été illustrée, elle permet au serveur d’envoyer des
messages au client Netconf lors d’un évènement particulier, dans l’exemple ci-dessous on inscrit
notre client auprès du serveur pour qu’il reçoive ses notifications puis on modifie la configuration et
on observe la notification envoyée :
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
52
Enregistrement auprès du serveur pour recevoir les notifications :
<?xml version="1.0" encoding="UTF-8"?> <rpc message-id="1"> <notification-on/> </rpc>]]>]]>
Modification de la configuration :
<?xml version="1.0" encoding="UTF-8"?> <rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target><running/></target> <config> <cli-config-data> <cmd>hostname test</cmd> </cli-config-data> </config> </edit-config> </rpc>]]>]]>
Réponse :
<?xml version="1.0" encoding="UTF-8"?> <rpc-reply message-id="102" xmlns="urn:ietf:params:netconf:base:1.0"> <ok /> </rpc-reply>]]>]]> <?xml version="1.0" encoding="UTF-8"?> <editConfigNotification xmlns="urn:ietf:params:netconf:base:1.0"> <notificationId>16</notificationId> <target><running /></target>
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
53
Puis la notification :
Remarque : j’ai volontairement coloré la notification pour plus de lisibilité.
On observe dans la notification les détails : la commande effectuée, l’ancien état puis le nouvel état.
On a également des informations sur l’auteur de la modification, son adresse IP ainsi que l’heure
précise.
4.2.8 Analyse du scénario
On peut tout d’abord noter que l’expérience est un succès. En effet malgré le manque
d’interopérabilité avec un logiciel client Netconf et l’implémentation Netconf Cisco qui se base sur
un brouillon sur lequel il est indiqué qu’il expirera le 31 décembre 2005, nous avons réussi à déployer
les configurations.
Cependant le déploiement n’a pas été aisé et on peut se baser sur la nécessité de connaitre le
protocole Netconf, l’implémentation de Cisco et le modèle de données particulier du routeur pour
conclure sur le fait que déployer la configuration avec Netconf sur du matériel Cisco est long,
nécessite une configuration de base qui peut gêner la création de certaines topologies et n’apporte
pas une grande valeur ajoutée dans notre scénario précis de « salle de TP réseau ». Le côté très
dynamique dans le changement de la topologie de cette salle de réseau partagée n’est pas très
adapté pour Netconf.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
54
En gérant la configuration de manière classique, on doit se connecter de manière physique un par un
à chaque routeur puis à chaque switch pour copier-coller une configuration, avec Netconf, une fois
l’étape de prérequis effectuée, un seul poste peut, sans avoir besoin d’autre branchement, envoyer
les configurations. La conséquence d’un changement de matériel s’il est différent obligerait à
s’intéresser à son implémentation de Netconf pour pouvoir l’utiliser.
En omettant la partie configuration prérequis pour Netconf, si on compare le temps de déploiement
de configuration avec et sans Netconf, c’est sensiblement la même chose.
La valeur ajoutée pourrait résider dans les notifications puisqu’une personne intéressée pourrait
s’inscrire pour recevoir le détail des nouveaux évènements de l’équipement.
Je pense qu’avec du matériel standard suivant les RFC récentes de Netconf et un logiciel client
Netconf récent, on améliorerait la gestion de la configuration, une équipe réseau pourrait savoir qui
a effectué une modification sur un matériel, à quelle date et connaitre l’ancienne configuration, c’est
vraiment une très grande valeur ajoutée d’avoir cette fonctionnalité de manière standard.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
55
4.3 Scénario opérateur télécom avec gestion de la QoS Ce scénario n’a pas été pratiqué mais il est là pour illustrer un cas d’utilisation de Netconf qui aurait
plus de sens, ce scénario illustre une gestion de la configuration avec plus de valeur ajoutée comparé
à une gestion de la configuration classique, sans outils adaptés ou avec des outils très manuels
comme des fichiers textes dans des répertoires avec des méthodes de gestion de l’historique
contraignantes en terme de temps et de répétition.
Ce scénario présente donc la gestion de la configuration au sein d’un réseau simplifié d’opérateur qui
fournit à ses clients des contrats de qualité de service nommés SLA (Service Level Agreement) qui se
traduisent en termes techniques nommés SLS (Service Level Specification). On prend l’exemple où le
trafic acheminé par le routeur du client, représenté en bas à gauche sur le schéma ci-dessous, aura
une classification DiffServ pour son trafic, une garantie de service pour les flux visioconference, une
priorité en dessous pour le trafic Web et le reste en best-effort avec une limitation du débit total à
10Mb/s. Ce contrat dure une durée déterminée. Le principe sera dans un premier temps d’écrire la
configuration des routeurs, dans un second temps on pourra la déployer puis enfin la retirer si le
contrat arrive à échéance.
Les notifications qui permettent d’avertir le client qui s’y est inscrit préviendraient les
administrateurs réseau des modifications de configuration de manière détaillée, et on peut
facilement imaginer un outil d’automatisation de gestion de la configuration se reposant sur la
généricité de l’interface que propose Netconf. En effet auparavant il n’existait pas d’outil
standardisé, des outils permettait de faire du scripting avec l’interpréteur de commande de Cisco
mais alors on était lié à ce constructeur ou à une version du matériel, avec Netconf on peut espérer
unifier l’interface avec laquelle on modifiera la configuration des équipements, à condition que les
constructeurs d’équipement soit du même avis car ils préfèreront peut être commercialiser une
méthode unifiée de gérer la configuration de leurs équipements.
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
56
Figure 10 : Schéma logique du scénario
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
57
5 Conclusion Nous avons décrit les différentes approche de la gestion de réseau, nous avons ensuite décrit
Netconf de manière théorique, nous avons vu que c’était un protocole jeune comparé aux autres
protocoles de la gestion de réseau mais que celui-ci s’inspirai des faiblesses des autres protocoles
pour proposer une solution simple et standardisée de gestion de la configuration. Notre scénario a
illustré la mise en œuvre de ce protocole et a mis en évidence les faiblesses de NETCONF : sa
jeunesse qui pose des problèmes de compatibilité au niveau des versions car les acteurs réseau
notamment Cisco n’a pas encore confirmé son adoption du protocole, du moins il propose dans ses
équipements récents une implémentation expirée depuis 2005. Ces problèmes de compatibilité sont
importants dans le domaine des systèmes fermés comme les constructeurs réseau mais le sont
moins en revanche dans le domaine des systèmes (des serveurs par exemple) puisque YUMA
propose une version serveur très aboutie de NETCONF. Pour ceux qui ne voudraient pas attendre
pour utiliser NETCONF en production avec des équipements réseau, il semblerait que les auteurs de
NETCONF préconisent le constructeur JUNIPER puisqu’un document de J.Schönwalder illustrant la
pratique de NETCONF lors d’une session pratique à l’université de Zurich15 décrit les fonctionnalités
de configuration candidate et de commit sur des routeurs Juniper J6300 et Junos 9.0R1.10, chose
non possible avec les routeurs de Cisco. Depuis la première RFC publiée en 2006, NETCONF a
beaucoup mûri, d’autres RFC ont été publiée, notamment sur l’utilisation de protocoles de transport
(SSH, SOAP et BEEP), les notifications, le modèle de données YANG, la seconde version de NETCONF
parue en juin 2011 ainsi que la RFC 6244 qui décrit une architecture de gestion de réseau avec YANG
et NETCONF. Les brouillons en cours de rédaction concernent des améliorations au niveau de la
sécurité, des nouveautés pour le contrôle d’accès. A l’heure de la rédaction de ce document il n’est
pas possible de prévoir les tendances de NETCONF, un protocole bien établit, fournissant des
méthodes novatrices et standards avec une documentation de grande qualité ne suffisent pas
toujours à son adoption, le côté standard n’est un atout que s’il est adopté de manière générale.
Dans tous les cas NETCONF est un protocole complet, sécurisé, dont des implémentations
commerciales et libres sont disponibles et a été reconnu par des leaders des constructeurs
d’équipements réseau, si ceux-ci continuent à le reconnaitre, il n’y a pas de raison que NETCONF ne
devienne pas une référence dans la gestion de la configuration réseau de manière pérenne.
15
http://www.aims-conference.org/issnsm-2008/06-netconf-Exercises.pdf
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
58
6 Bibliographie [Pujolle et al., 2004] Guy Pujolle, Olivier Salvatori, Jacques Nozick, Les Réseaux, édition 2005, Eyrolles,
2005
[Agoulmine et al., 2003] Nazim Agoulmine, Omar Cherkaoui, Pratique de la gestion de réseau -
Solutions de contrôle et de supervision d'équipements réseau pour les entreprises et les opérateurs
télécoms, Eyrolles, 2003
[Farrel, 2008] Adrian Farrel (Sous la direction de), Network Management: Know It All, Morgan
Kaufmann Publishers, 2008
[Enns, 2005] R. Enns, NETCONF Configuration Protocol, draft-ietf-netconf-prot-07, IETF, 2005
[Enns, 2006] R. Enns, NETCONF Configuration Protocol, RFC 4741, IETF, 2006
[Enns et al., 2011] R. Enns, M. Bjorklund, J. Schoenwaelder, A. Bierman, Network Configuration
Protocol (NETCONF), RFC 6241, IETF, 2011
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
1
7 Annexe Sortie de la commande get avec filtre XML sur routeur Cisco :
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
4
Affichage du schéma du modèle de données NETCONF d’un routeur
Commande : show netconf schema
Ci-dessous le schéma avec un routeur Cisco 1841 IOS 12.4(24)T2.
New Name Space 'urn:ietf:params:xml:ns:netconf:base:1.0'
<VirtualRootTag> [0, 1] required
<rpc-reply> [0, 1] required
<ok> [0, 1] required
<data> [0, 1] required
<rpc-error> [0, 1] required
<error-type> [0, 1] required
<error-tag> [0, 1] required
<error-severity> [0, 1] required
<error-app-tag> [0, 1] required
<error-path> [0, 1] required
<error-message> [0, 1] required
<error-info> [0, 1] required
<bad-attribute> [0, 1] required
<bad-element> [0, 1] required
<ok-element> [0, 1] required
<err-element> [0, 1] required
<noop-element> [0, 1] required
<bad-namespace> [0, 1] required
<session-id> [0, 1] required
<hello> [0, 1] required
<capabilities> 1 required
<capability> 1+ required
<rpc> [0, 1] required
<close-session> [0, 1] required
<commit> [0, 1] required
<confirmed> [0, 1] required
<confirm-timeout> [0, 1] required
<copy-config> [0, 1] required
<source> 1 required
<config> [0, 1] required
<cli-config-data> [0, 1] required
<cmd> 1+ required
<cli-config-data-block> [0, 1] required
<xml-config-data> [0, 1] required
<Device-Configuration> [0, 1] required
<> any subtree is allowed
<candidate> [0, 1] required
<running> [0, 1] required
<startup> [0, 1] required
<url> [0, 1] required
<target> 1 required
<candidate> [0, 1] required
<running> [0, 1] required
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
5
<startup> [0, 1] required
<url> [0, 1] required
<delete-config> [0, 1] required
<target> 1 required
<candidate> [0, 1] required
<running> [0, 1] required
<startup> [0, 1] required
<url> [0, 1] required
<discard-changes> [0, 1] required
<edit-config> [0, 1] required
<target> 1 required
<candidate> [0, 1] required
<running> [0, 1] required
<startup> [0, 1] required
<url> [0, 1] required
<default-operation> [0, 1] required
<test-option> [0, 1] required
<error-option> [0, 1] required
<config> 1 required
<cli-config-data> [0, 1] required
<cmd> 1+ required
<cli-config-data-block> [0, 1] required
<xml-config-data> [0, 1] required
<Device-Configuration> [0, 1] required
<> any subtree is allowed
<get> [0, 1] required
<filter> [0, 1] required
<config-format-text-cmd> [0, 1] required
<text-filter-spec> [0, 1] required
<config-format-text-block> [0, 1] required
<text-filter-spec> [0, 1] required
<config-format-xml> [0, 1] required
<oper-data-format-text-block> [0, 1] required
<show> 1+ required
<oper-data-format-xml> [0, 1] required
<show> 1+ required
<get-config> [0, 1] required
<source> 1 required
<config> [0, 1] required
<cli-config-data> [0, 1] required
<cmd> 1+ required
<cli-config-data-block> [0, 1] required
<xml-config-data> [0, 1] required
<Device-Configuration> [0, 1] required
<> any subtree is allowed
<candidate> [0, 1] required
<running> [0, 1] required
<startup> [0, 1] required
<url> [0, 1] required
<filter> [0, 1] required
TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville
6
<config-format-text-cmd> [0, 1] required
<text-filter-spec> [0, 1] required
<config-format-text-block> [0, 1] required
<text-filter-spec> [0, 1] required
<config-format-xml> [0, 1] required
<kill-session> [0, 1] required
<session-id> [0, 1] required
<lock> [0, 1] required
<target> 1 required
<candidate> [0, 1] required
<running> [0, 1] required
<startup> [0, 1] required
<url> [0, 1] required
<unlock> [0, 1] required
<target> 1 required
<candidate> [0, 1] required
<running> [0, 1] required
<startup> [0, 1] required
<url> [0, 1] required
<validate> [0, 1] required
<source> 1 required
<config> [0, 1] required
<cli-config-data> [0, 1] required
<cmd> 1+ required
<cli-config-data-block> [0, 1] required
<xml-config-data> [0, 1] required
<Device-Configuration> [0, 1] required
<> any subtree is allowed
<candidate> [0, 1] required
<running> [0, 1] required
<startup> [0, 1] required
<url> [0, 1] required
<notification-on> [0, 1] required
<notification-off> [0, 1] required
Recommended