tx netconf gestion de configuration demianville

68
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

Upload: vingtage

Post on 25-Jul-2015

810 views

Category:

Documents


6 download

DESCRIPTION

In french, Network configuration management with NETCONF

TRANSCRIPT

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 [email protected]> //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 [email protected]> 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 [email protected] 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

2

TX Gestion de Réseaux et gestion de la configuration avec NETCONF Benoît de Mianville

3

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