TX Netconf Gestion de Configuration DEMIANVILLE

Etudiant : DE MIANVILLE Benot Responsables : PLOIX Alain, DOYEN Guillaume
Branche : SIT5 Anne : 2011
Semestre : A11
TX Gestion de Rseaux et gestion de la configuration avec NETCONF
Ce travail dexprimentation a pour but davoir une vue globale sur la gestion des rseaux de tlcommunication et dexprimenter un protocole rcent apportant des rponses une partie spcifique de la gestion des rseaux : la gestion de la configuration. Nous aborderons donc les grandes approches de la gestion de rseau, ensuite nous nous intresserons plus prcisment la gestion de la configuration puis nous exprimenterons en dtail le protocole NETCONF au travers de limplmentation de Cisco et des clients NETCONF YUMA et MGSoft Netconf browser. Un scnario mettra en vidence lintrt du protocole et la dernire partie prsente une solution plus large dans laquelle la gestion de la configuration est intgre la gestion globale du rseau
Sommaire
1 2 Introduction ..................................................................................................................................... 1 Cheminement pour le choix dune plateforme de gestion ............................................................. 2 2.1 2.2 2.3 2.4 Le contexte rseau .................................................................................................................. 2 Les acteurs ............................................................................................................................... 2 Les aires fonctionnelles ........................................................................................................... 3 Interfaage avec le rseau....................................................................................................... 3 Plan de donnes .............................................................................................................. 3 Plan de contrle .............................................................................................................. 3 Plan de gestion ................................................................................................................ 4 Conclusion ....................................................................................................................... 4
2.4.1 2.4.2 2.4.3 2.4.4 2.5
Les grandes approches de gestion de rseau.......................................................................... 4 Introduction ..................................................................................................................... 4 SNMP ............................................................................................................................... 4 WBEM .............................................................................................................................. 5 Gestion avec Java : JMAPI et JMX.................................................................................... 6 TMN ................................................................................................................................. 7 Gestion par politique ....................................................................................................... 9 Conclusion ..................................................................................................................... 10
2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.5.6 2.5.7 3
NETCONF ....................................................................................................................................... 12 3.1 3.2 3.3 3.4 3.5 La gestion de la configuration ............................................................................................... 12 Le protocole ........................................................................................................................... 14 YANG...................................................................................................................................... 20 Les implmentations indpendantes des constructeurs ...................................................... 22 Les quipementiers rseaux.................................................................................................. 24
NETCONF en pratique.................................................................................................................... 25 4.1 Premiers pas avec Netconf .................................................................................................... 25 Les clients Netconf utiliss ............................................................................................ 25 Les serveurs Netconf utiliss ......................................................................................... 27 Configuration dun routeur Cisco .................................................................................. 27 Le cas de limplmentation de Cisco ............................................................................. 30
4.1.1 4.1.2 4.1.3 4.1.4 4.2
Scnario salle de travaux pratiques de services rseaux lUTT .......................................... 38 Schma dadressage du rseau de test ......................................................................... 39 Schma physique du rseau de test .............................................................................. 40
4.2.1 4.2.2
4.2.3 4.2.4 4.2.5 4.2.6 4.2.7 4.2.8 4.3 5 6 7
Tests prouvant la bonne configuration du rseau ........................................................ 40 Equipements configurer avec Netconf ....................................................................... 40 Configuration des quipements configurer avec Netconf ......................................... 41 Prrequis la configuration avec Netconf .................................................................... 43 Dploiement de la configuration................................................................................... 46 Analyse du scnario ....................................................................................................... 53
Scnario oprateur tlcom avec gestion de la QoS ............................................................ 55
Conclusion ..................................................................................................................................... 57 Bibliographie.................................................................................................................................. 58 Annexe ............................................................................................................................................. 1
Benot de Mianville
1 Introduction
Le but dun travail dexprimentation comme celui-ci est la dmonstration de lacquisition de connaissances grce lexprimentation dune technique, en loccurrence je me propose dtudier en quoi NETCONF, un protocole du monde de lInternet, lIETF1, apporte des nouvelles solutions en terme de gestion de la configuration du rseau. Il ntait pas pensable de dcrire de manire directe le protocole sans aborder le paysage de la gestion de la configuration et de la gestion de rseau en gnral pour comprendre dans quelles circonstances le protocole est venu au jour. La premire partie de ce document dcrira donc dune manire gnrale les questions se poser pour pouvoir faire le choix dune solution de gestion rseau ; la premire partie dcrira galement les grandes approches dans la gestion de rseau, ces approches seront dcrites dans leur gnralit puisquil ne sagit pas ici dexposer les dtails prcis de chaque approche. Une fois que la gestion de rseau sera bien situe nous verrons plus en dtail la gestion de la configuration avec NETCONF, dans un premier temps nous verrons la partie thorique du protocole, ses messages et la faon qui a t propose de structurer le modle de donne : YANG. Nous pourrons ensuite dtailler la faon dont nous procderons en dcrivant les outils techniques que nous utiliserons : le matriel, les logiciels, nous verrons comment configurer ces outils spcifiques. Enfin nous verrons au travers dun scnario pratique la dmonstration du protocole en dtail et nous pourrons conclure, objet de ce travail dexprimentation, si NETCONF rvolutionne la manire de grer la configuration du rseau.
IETF : Internet Engineering Task Force
Benot de Mianville
2 Cheminement pour le choix dune plateforme de gestion

Cette partie est une forme de guide pour apprhender le choix dune plateforme de gestion.
2.1 Le contexte rseau

Il faut, dans une premire approche, savoir dfinir le contexte rseau, afin de cibler au mieux le type de rseau que lon veut maitriser. Mieux on connaitra notre rseau mieux on pourra ajuster des outils pour mesurer son tat et interagir avec. Une liste de critres simples est claircir pour mieux connaitre son rseau : La finalit du rseau : un fournisseur daccs internet naura pas les mmes besoins de gestion quune entreprise. Ltendue du rseau : un petit rseau sur un site gographique unique ou un rseau international. Les technologies et larchitecture : utilise-t-on le protocole IP, ATM, Sonet, X25 ou une autre technologie (ou plusieurs la fois) ? Les quipements : quels types dquipement faonnent le rseau, des modems, des switchs, des routeurs, et quelles sont les faons dinteragir avec ces quipements ?
2.2 Les acteurs

Dans cette partie nous nous intressons aux diffrents acteurs, on regarde une partie du rseau, les quipements, les flux, linfrastructure et on dtermine quels sont les propritaires, les diffrents acteurs qui suivant leurs exigences vont nous permettre de spcifier ensuite leurs besoins en terme de gestion. Pour identifier les acteurs, regardons linfrastructure : qui appartient-elle ? Est-ce compose de lignes loues un oprateur, est-ce une infrastructure compltement prive que vous allez exploiter ou bien louer des clients ? Le tableau ci-dessous donne 3 exemples o lon peut identifier suivant le cas qui appartient linfrastructure, lexploitation ou les donnes. Qui FAI louant linfrastructure FAI propritaire de linfrastructure Rseau priv dentreprise Infrastructure Exploitation X X X X Donnes
X X
Tableau 1 : Mise en vidence de l'appartenance des lments composants le rseau
Lintrt didentifier les acteurs est de pouvoir prciser dune part o les informations qui nous intressent se situent et dautre part si il y a possibilit accder ces informations suivant notre pouvoir sur linfrastructure, lexploitation et les donnes.
Benot de Mianville
2.3 Les aires fonctionnelles

LITU-T (International Telecomunication Union Standardization Sector) a dfini une approche de gestion de rseaux : le TMN (Telecommunications Management Network) qui dfinit 5 aires fonctionnelles. Ici on ne sintressera pas spcifiquement au TMN mais aux 5 aires fonctionnelles qui sont censes tre essentielles dans la gestion de rseaux et permettent une approche facilite. Faults : cest la gestion des pannes, elle doit permettre didentifier les pannes et leur type, leur origine. Configuration : la gestion de la configuration, o est la configuration du rseau, y-a-t-il des procdures pour changer la configuration, pour revenir un tat antrieur ? La rponse ces questions entre autres est le but de cette aire. Accounting : il sagit ici dtablir 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 rseau en relevant les informations permettant de mesurer les performances du rseau. Security : la gestion de la scurit permettra de dfinir des mthodes pour garantir le niveau de scurit exig dans le rseau.
Lintrt des aires fonctionnelles dans notre cas est de dfinir lavance les fonctionnalits importantes mettre en uvre avec la plateforme de gestion : le niveau de scurit exigera t- il des mthodes pointues afin de garantir chaque moment la scurit du rseau (exemple dune banque) ou alors nos clients auront-ils conclu un contrat qui exigera une performance minimum du rseau (exemple dun fournisseur daccs internet). Autant de questions auxquelles il est important de rpondre tt pour faciliter le choix dune plateforme de gestion.
2.4 Interfaage avec le rseau

Dans cette partie nous allons nous intresser aux diffrents moyens dinteragir avec le rseau. On aura une approche par plan. 2.4.1 Plan de donnes Le plan de donnes concerne les donnes qui sont vhicules dans le rseau et qui sont la raison mme du rseau, dans le plan de donnes on retrouvera des paquets de donnes qui transporteront de la voix, des parties dune page web, un transfert de fichier etc. suivant lutilisation faite du rseau. Dans ce plan on va pouvoir analyser les flux eux mme en les caractrisant : nombre de paquets sortant dune interface rseau par rapport son maximum, pourcentage de flux dun certain type, horaires des pics de trafic, etc. Un bon exemple de mise en uvre de caractrisation des flux dans le plan de donnes est une sonde. 2.4.2 Plan de contrle Le plan de contrle sert assurer la signalisation, par exemple dans le cas dune communication voix sur IP, le trafic servant tablir la communication et la fermer, dans le cas dATM, la procdure douverture de circuits etc. 3
Benot de Mianville
Dans le plan de contrle dun rseau IP, on pourra utiliser le protocole ICMP (Internet Control Message Protocol) afin de dterminer si la destination est atteignable, mesurer les temps de traverse du rseau et identifier les chemins pris. 2.4.3 Plan de gestion Le plan de gestion assure des fonctions de surveillance du rseau, on aura par exemple le protocole de gestion de lIETF (Internet Engineering Task Force) : SNMP (Simple Network Management Protocol) ou alors CMIP/CMIS propos par lISO (lorganisation internationale de normalisation). Des mthodes ddies des protocoles de gestion sont alors mises en uvre afin dassurer la gestion de rseau. On pourra aussi utiliser des protocoles comme SSH afin dinteragir avec les quipements rseau pour lire et modifier leur configuration. Des grands constructeurs proposent aussi des protocoles de gestion propritaires. 2.4.4 Conclusion Ce quil est important de retenir ici est lhtrognit des interfaages avec le rseau, quelle soit de par les diffrents plans quon va utiliser ou par les grandes approches du monde de lInternet ou des tlcoms que nous allons voir plus en dtail dans le chapitre suivant.
2.5 Les grandes approches de gestion de rseau

2.5.1 Introduction Nous allons nous intresser des approches de gestion de rseau slectionnes suivant plusieurs critres .Tout dabord ont t retenues : les approches du monde des tlcoms et du monde de linternet, rfrences en matire de gestion ; dautres approches trs labores et trs intressantes tudier mais pas forcment largement dployes.
2.5.2 SNMP SNMP (Simple Network Management) est la fois un protocole, une mthode de gestion et un modle de donnes, provenant dun groupe de travail de lIETF et fait pour les rseaux TCP/IP. Le principe de SNMP fonctionne selon le mode agent-manager. Un processus SNMP sera excut sur les agents (par exemple un routeur, un switch,) et un autre processus SNMP sera excut par le manager (un serveur). Le processus SNMP du manager pourra ensuite rcolter les informations grce des messages SNMP qui sont dtaills ci-dessous : GetRequest et GetNextRequest permettent au manager de venir interroger un agent. GetResponse est la rponse envoye par lagent au manager. Trap est une alarme envoye linitiative de lagent au manager, il se dclenche lors dun vnement, par exemple une interface en panne ou un seuil atteint.
SNMP envoie ses messages grce au protocole de transport UDP pour plusieurs raisons : Un message SNMP est court et tient dans un seul datagramme UDP ;
Benot de Mianville
On prfre UDP TCP pour viter que le trafic de gestion ne prenne trop de place compar au trafic de donnes.
SNMP reprsente les donnes dans une base appele MIB (Management Information Base). La premire version de cette MIB appele aussi MIB 1 est organise hirarchiquement avec des OID (Object IDentifier) enregistrs par lISO qui est une mthode gnrique de classement dobjets. Les premiers nuds de la MIB 1 sont les suivants [Pujolle et al., 2004] : System : pour la gestion du nud lui-mme interfaces : pour les ports et interfaces rseau ; address translation : pour la traduction dadresses 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 supplmentaires : transmissions et SNMP. Pour conclure sur les MIB, il existe la MIB RMON (Remote Monitor Network) qui permet des quipements SNMP danalyser des informations sur les flux et de les stocker : les sondes. La nouveaut la plus importante de SNMPv3, la dernire version, est la scurit qui permet lauthentification et le cryptage. SNMP tait la base trs utilis dans les rseaux locaux IP, il est aujourdhui plus largement utilis et est devenu un standard de la gestion rseau de par sa simplicit et son acceptation par tous les grands constructeurs. 2.5.3 WBEM WBEM (Web-based enterprise management) est lorigine dun 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 reprsentation de donnes XML) pour dfinir un environnement de gestion dentreprise ouvert. WBEM repose sur une modlisation des donnes : CIM (Common information model) : orient objet, associations entre les objets et est conu pour pouvoir tre indpendant dune implmentation de technologie de gestion particulire. Le modle de donnes CIM est structur en diffrents modles qui permettent de dcrire dune part laspect gestion des objets reprsents (grce au modle noyau) et dautre part les objets euxmmes ; les principaux modles sont prsents ci-dessous :
2
Rseau Physique Support
DMI : Distributed Management Interface, protocole de gestion de rseau du DMTF (Distributed Management Task Force) pour permettre des machines de diffuser des informations les concernant. 3 CMIP : expliqu dans le chapitre dcrivant la gestion TMN
TX Gestion de Rseaux et gestion de la configuration avec NETCONF Systme Utilisateurs Applications DAP (Directory Access Protocol) Priphriques
Benot de Mianville
Laspect web concerne la faon dont les donnes sont transportes, le protocole WBEM HMMP (Hypermedia Management Protocol) se sert de http (hypertext transfer protocol) pour transporter les messages ; dailleurs, la scurit repose sur celle de http cest--dire que lon profite du protocole HTTPS (http Secure). Une premire conclusion possible est laspect gestion systme qui est trs dveloppe dans WBEM et qui dlaisse les problmatiques rseaux sans apporter de mthodes valeur ajoute pour ce domaine. En effet dans les modles on va trs loin dans la description des systmes : description des priphriques, mmoire, processeur, applications, systme dexploitation, threads, mais il reste limplmentation de la gestion rseau avec les problmatiques quapporte lOSI (les aires fonctionnelles, dcrites dans la partie 1). 2.5.4 Gestion avec Java : JMAPI et JMX Java est un langage de dveloppement portable nativement sur diffrents systmes dexploitations, il est orient objet, trs populaire et dvelopp par ORACLE (anciennement par SUN Microsystems). SUN a dvelopp une bibliothque de dveloppement ddie la gestion : JMAPI (Java Management API), qui sest au fil du temps amlior 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 reprsentation des donnes se fait via des objets grables appels MBean, Des API4 spcifiques font le rle dadaptateurs pour les diffrentes technologies de gestion (SNMP, TMN,), Un agent est compos dun serveur MBean et un ensemble de MBeans.
Il existe des MBeans standards et gnriques, les gnriques permettent de reprsenter des ressources grables alors mme quon na pas encore dinformation sur leur nature, on pourra spcialiser ces objets plus tard tandis que les MBeans standards ont des caractristiques spcialises qui sont censes ne pas changer dans le temps. Les constructeurs devraient fournir des MBeans pour pouvoir grer leurs quipements. Les applications de gestion vont interagir avec les objets grables MBeans via les agents. La valeur ajoute de JMX : La notification dvnements : Un modle de notification dvnements est mis en place suivant les modles push et pull, en push lapplication de gestion va recevoir les notifications de manire asynchrone tandis quen pull cest lapplication de gestion qui dcide du moment o elle rcupre les informations.
API : Application Programming Interface, interface de programmation
Benot de Mianville
Les services de gestion : ce sont des tches de gestion effectues par les agents, cela rduit le trafic de gestion et dcharge le gestionnaire qui effectuait lorigine ces tches. Linteroprabilit avec les solutions actuelles : des API fonctionnant comme des adaptateurs permettent dintgrer les solutions de gestion actuelles, les API proxy sinterfacent avec les technologies suivantes : o SNMP, o TMN, o Corba, o CIM/WBEM o DEN/LDAP
Finalement JMX apporte une solution gnrique de gestion, couplable aux technologies de gestion existantes et trs ouverte au dveloppement de fonctionnalits, malheureusement sa grande force est aussi une faiblesse puisque la gnricit est telle quil reste structurer des mthodes propres la gestion de rseau et aux problmatiques mises en vidence par LISO : les besoins FCAPS (dcrits au dbut de ce document). En outre nous navons pas dinformations sur le passage lchelle, quelles sont les performances si on a besoin de grer des millions dobjets MBeans? JMX nest donc pas exclure en termes de gestion de rseau mais coupler des solutions qui rsolvent lactivit de gestion. 2.5.5 TMN TMN est lorigine de lITU-T T (International Telecomunication Union Standardization Sector), et fait partie de la recommandation M.3010 ce monde des tlcoms propose une solution voulue prenne qui sadapte aux changements de technologies des oprateurs. TMN organise la gestion de rseau de manire hirarchique, reprsente les donnes de manire oriente objet et propose un protocole de communication entre les agents et les managers. Le protocole de communication est CMIP (common management information protocol) et linterface de gestion native est appele interface Q3, linteroprabilit avec les protocoles de gestion est possible grce des adaptateurs (fonctionnalits de QAdaptation) : SNMP, TL1 ou propritaire. Au niveau du modle de donne, le modle objet est bas sur GDMO (guidelines for description of managed objects). TMN est adapt aux grands rseaux : Distribution des tches de gestion sur diffrents systmes. Dcomposition en domaines de gestion : pour grer les fonctionnalits (pannes, configuration, performance,)
Linteroprabilit avec les autres oprateurs a t prvue : Mcanisme dchange dinformations entre les domaines de gestion scuris
Les diffrentes architectures TMN : Larchitecture fonctionnelle : elle structure diffrents blocs fonctionnels (Pannes, Configuration, Comptabilit,) et prcise leurs interactions avec les diffrentes interfaces en prenant comme rfrence linterface CMIP Q3. 7
Benot de Mianville
Larchitecture physique : elle concrtise larchitecture 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. Larchitecture organisationnelle : Elle permet de hirarchiser la gestion en partant dune couche globale de gestion de lentreprise jusquaux couches de gestion des lments du rseau comme montr sur le schma ci-dessous ; ainsi les couches suprieures ont une vue synthtique et simplifie des couches infrieures. Chaque couche est en pratique ralise par un ensemble de blocs physiques comme montr sur le second schma ci-dessous (OS : Operations System, ralise lopration de gestion ; Q3, X ou M : interface de gestion).
Gestion de l'entreprise Gestion des services Gestion des rseaux Gestion des lments du rseau Elments du rseau
Figure 1 : TMN, couches logiques [Agoulmine et al., 2003]
Benot de Mianville
Figure 2 : TMN, architecture organisationnelle [Agoulmine et al., 2003]
Larchitecture informationnelle : cest la couche dabstraction qui permet de grer le rseau de manire gnrique, cest--dire sans avoir besoin de connaitre exactement les protocoles et techniques utiliser jusquaux quipements. Pour ce faire larchitecture informationnelle utilise un modle orient objet (GDMO, guidelines for definition of managed objects) et dcrit comment un bloc physique va organiser sa base de donnes dinformation (MIB, Management Information Base), et identifier les objets de manire unique.
TMN introduit des notions trs intressantes en prenant nativement en compte les fonctions de gestion de rseau, en apportant de la gnricit avec la sparation hirarchique et fonctionnelle et en permettant ladaptabilit des interfaces aux autres protocoles de gestion ; laspect hirarchique et le modle orient objet ont t adopt cependant les protocoles spcifiques et les interfaces nont pas t largement adopts du fait de la complexit du systme.
2.5.6 Gestion par politique La gestion par politique provient du monde des oprateurs tlcoms et est un paradigme qui vise industrialiser, automatiser grande chelle la gestion de rseau en ayant plusieurs niveaux dabstractions en partant de lutilisateur qui voudrait que sa visioconfrence passe bien jusquaux quipements sur lesquels on rglerait une qualit de service spcifique.
Benot de Mianville
Le rseau est organis hirarchiquement en nuds, des nuds spcifiques (Policy Decision Point, PDP) qui prennent en compte les spcifications et dautres critres et diffusent ensuite leurs dcisions des autres nuds (Policy Enforcement Point, PEP) qui appliquent les dcisions en traduisant en langage technique. La communication entre les PDP et les PEP se fait grce au protocole COPS (Common Open Policy Service). Le nud de dcision PDP prend en compte les critres qui se trouvent dans des serveurs : Le serveur de politiques, Policy Repository dans lequel les politiques sont stockes BandwitdthBrocker, gestionnaire de bande passante, il a une vue globale sur les ressources alloues MobilityBrocker, gestionnaire de mobilit, il permet de grer la continuit de la qualit de service Security Brocker, gestionnaire de scurit qui comprend un serveur AAA5 pour grer le contrle daccs (au moment de la connexion au rseau) et galement la scurit des informations transportes sur le rseau. Billing, serveur de facturation, gre la facturation du service procur
Il y a deux modles de gestion et de contrle par politique, loutsourcing et le provisioning. Loutsourcing consiste ce que les clients via les nuds dapplication des politiques (PEP) demandent aux nuds de dcision (PDP) sils peuvent utiliser le rseau, gnralement via une demande RSVP6 (RSVP entre le client et le PEP, COPS entre le PEP et le PDP), le PDP vis rpond et autorise ou non la connexion. Le provisioning : le client ngocie avec loprateur un Service Level Agreement (SLA) qui indique en langage non technique la qualit de service dsire, ce SLA se traduit en spcification 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 diffrentes approches de la gestion de rseaux ; la plus pragmatique et la plus dploye tant SNMP qui elle-mme sinspire de la gestion CMIP en simplifiant (do le S de SNMP : Simple) sans tre simpliste pour proposer une gestion de rseau rapide dployer et supportant des grandes tailles de rseau. Nous avons vu la gestion par le Web WBEM et son modle de donnes CIM qui est trs complet mais malgr tout conu nativement pour la gestion des systmes comme des serveurs plutt que la gestion de rseau. La vision de la gestion de rseau avec Java, JMX introduit un systme gnrique de gestion sans apporter de mthodes propres aux problmatiques de la gestion de rseau (FCAPS, voir les aires fonctionnelles) ; malgr tout JMX reste trs intressant de par ses possibilits multiples et son interoprabilit avec les autres systmes. Lapproche TMN est ncessairement intressante puisquelle est lorigine du succs quest SNMP, elle nest cependant pas largement dploye dans son intgralit cause de sa complexit. La gestion par politique apporte une rponse intressante aux oprateurs tlcoms en
5 6
AAA, Authentication, Accounting, Authorization, cest un modle de scurit RSVP, Resource Reservation Protocol, protocole de rservation de ressource
10
Benot de Mianville
apportant nativement le principe de SLA (Service Level Agreement) et SLS (Service Level Specification)
11
Benot de Mianville
3 NETCONF
Cette partie aborde NETCONF en commenant par dcrire la gestion de la configuration de manire gnrale puis elle prsente la partie protocolaire de NETCONF, son modle de donnes YANG et les implmentations du protocole.
3.1 La gestion de la configuration

La gestion de la configuration regroupe lensemble des activits qui consistent grer les actions ncessaires effectuer pour contrler le comportement du rseau. Dans la gestion de la configuration dun rseau, on doit tre capable de rcuprer des informations sur ltat actuel de la configuration des quipements et aussi pouvoir diter ces configurations. Lors de la rsolution de problmes il est souvent ncessaire de mettre en relation un changement rcent de configuration avec lapparition du problme, il est aussi ncessaire de pouvoir repasser dans une version stable de la configuration, la dernire bonne configuration connue . On remarque dans les besoins noncs ci-dessus la ncessit de mettre en place des bonnes pratiques, on citera : Garder un historique des configurations Ecrire une description concernant lobjet de la modification de la configuration
Ces bonnes pratiques sont garantes dun bon fonctionnement du rseau mais elles sont lourdes appliquer dans un environnement comportant des dizaines voire des centaines dquipements rseau. En effet on distingue diffrents types dinterface de configurations dont laccs est standard : Interface en ligne de commande o Via un port console o Via le rseau par SSH (SecureShell) ou telnet Interface Web
Malgr tout, les commandes et les donnes ne sont pas standard, et ce mme au sein des produits dun constructeur. De plus certains quipements ont la possibilit de grer une seule configuration, celle en mmoire volatile, dautres peuvent en grer 2 mais pas plus en gnral. Une autre limitation provient du fait quen gnral il ny a pas de possibilit de retour en arrire au niveau de la configuration (sauf de manire manuelle). Afin de fournir des solutions aux problmes voqus, des logiciels et des mthodes associes ont vu le jour, nous allons voir quelques solutions populaires. CFEngine (Configuration Engine) a t cr en 1933 par Mark Burgess, alors doctorant luniversit dOslo. Le but est lautomatisation de la gestion de la configuration de machines telles que des ordinateurs, mais aussi des terminaux mobiles (smartphones et tablettes). Lentreprise CFEngine AS assure le support des utilisateurs et propose une version commerciale : CFEngine Nova. CFEngine a 12
Benot de Mianville
t conu pour des machines base Unix, il a aussi t port sur Windows. Le principe est de dcrire ltat final des machines, CFEngine se chargeant de latteindre.7 Dun point de vue technique, la base est la synchronisation de fichiers textes laide doutils Linux prexistants, un ensemble de mthodes qui font le cur de CFEngine et la possibilit dutilisation dun systme de gestion de version (CVS) permettant de commenter les changements et de revenir dans des versions antrieures. RANCID8, Really Awesome New Cisco Config Differ est un logiciel freeware, il permet la supervision de la configuration dquipements rseaux. Loutil 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/
Loutil se connecte lquipement monitorer via le rseau par telnet ou SSH (un fichier, router.db, contient la liste des adresses des quipements), il effectue des actions spcifiques au matriel pour rcuprer sa configuration logicielle et matrielle, si une version prcdente de la configuration existe et quelle est diffrente, lauteur de la modification est pri de commenter la modification et une notification est envoye par mail. Le point faible de ce type doutil est la ncessit de maintenir des mthodes daccs spcifiques chaque constructeur voire chaque quipement puisque il ny a pas de protocole standardis, malgr tout sa simplicit est sa force et des retours trs plaisants ont t faits comme par exemple le fait que lajout systmatique de commentaires la modification dune configuration permette de rsoudre bien plus facilement les pannes. Ces outils prsents sont fort pratique, mais il y a encore des manques dans laspect gestion de la configuration, en tmoigne la RFC 3535 Overview of the 2002 IAB Network Management Workshop 9 publie en mai 2003, qui a runi des acteurs de lIETF et des oprateurs, le but tait de faire un point sur la manire dinteragir avec les quipements rseau et de mettre en avant les manques. Le constat a t que SNMP tait trs utilis et trs pratique pour rcuprer des informations grce des MIB trs bien fournie mais du ct de lcriture de donnes SNMP ntait pas trs adapt pour certaines raisons. La principale raison est que les MIB standard et les MIB des constructeurs ne fournissent pas assez dobjets permettant lcriture. Une autre constatation est le fait que la majorit des quipements rseau ont une interface en ligne de commande accessible via telnet ou ssh mais que celle-ci nest pas standardise, 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
13
Benot de Mianville
interfaces web celles-l aussi encore moins automatisables. Les oprateurs ont formul leur demande : des protocoles permettant la gestion en masse des quipements (et, idalement, permettant de configurer le rseau, plutt que chaque quipement isolment) . Le souhait est un langage standard pour la gestion de la configuration des quipements rseau, permettant de sauvegarder compltement une configuration et aussi den injecter une complte ou une partie. La conclusion prconise pour SNMP labandon dobjets permettant lcriture et la normalisation dun protocole de configuration bti sur XML, ce qui a donn NETCONF dans le RFC 4741.
3.2 Le protocole
Nous avons vu dans la partie prcdente ce qutait la gestion de la configuration, ses enjeux, des exemples doutils connus et les recommandations dun groupe de travail de lIETF qui prconise un protocole standardis pour la gestion de la configuration btie sur XML, cest donc ce protocole, NETCONF, que nous allons tudier en dtail, la premire version a t dcrite dans le RFC 4741 en dcembre 2006, le modle de donnes qui reprsente les configurations bties sur XML est YANG, publi dans la RFC 6020 en octobre 2010 et une deuxime version de NETCONF a t publie en juin 2011 dans la RFC 6241. Nous allons donc voir dans cette partie le protocole NETCONF et son modle de donnes YANG tels quils sont dcrits par lIETF puis nous nous intresserons aux implmentations.
Reprsentation des donnes standardise

Les configurations sont reprsentes dans le langage XML.
Mode de communication
Les communications se font suivant le modle client-serveur, le serveur tant le logiciel rsidant sur lquipement grer et le client tant le logiciel rsidant sur la machine centrale qui gre les configurations des quipements.
Technique de communication
Les changes de donnes sont encods en XML et envoyes via une procdure dappel distant (RPC, Remote Procedure Call) travers une session en mode connecte et scurise.
Partitionnement en 4 couches
NETCONF peut tre conceptuellement partitionn en 4 couches :
14
Benot de Mianville
Figure 3 : couches protocolaires de NETCONF [Enns et al., 2011]
1. 2. 3. 4.
La couche scurise de transport sert acheminer les messages entre le client et le serveur. La couche Messages fournit un mcanisme denvoi indpendant de la couche transport. Un ensemble doprations de base existe et les paramtres sont encods en XML. Le contenu est spcifique la reprsentation de la configuration et sera reprsent laide de YANG (dcrit dans la partie suivante).
Fonctionnalits (capabilities)
Une fonctionnalit est un ensemble de fonctionnalits qui supplmente les fonctions de base de NETCONF. Le client peut dcouvrir les fonctionnalits du serveur et donc utiliser les oprations dcrites dans ces fonctionnalits. Certaines fonctionnalits ont des dpendances dautres fonctionnalits qui sont obligatoires. Echange des fonctionnalits Les entits NETCONF changent leurs fonctionnalits lors de ltablissement de la session. Fonctionnalits Fonctionnalit writable-running Signification Il est possible dcrire directement dans la configuration actuelle. Cela signifie que lquipement supporte edit-config et copy-config sur la configuration en cours (la running 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 15
Candidate Configuration
TX Gestion de Rseaux et gestion de la configuration avec NETCONF configuration en cours
Benot de Mianville
Confirmed Commit
Rollback on Error
Validate Distinct Startup
URL XPath
Tableau 2 : Description des fonctionnalits de Netconf
Il est possible pour plusieurs sessions NETCONF de modifier la mme configuration candidate, il va de soi quil est prfrable de verrouiller la configuration avant de la modifier Permet de confirmer un commit. Si un commit ncessitant une confirmation ne la pas t durant un timeout de 600 secondes (10 minutes), lancienne configuration en cours doit tre remise en service Permet deffectuer un rollback lors dune erreur ; en dautres mots cela remet lancienne configuration en cours en service Permet de vrifier la bonne syntaxe dune configuration avant de la mettre en service Indique que lquipement supporte une configuration en cours et une configuration de dmarrage distincte Lquipement supporte lutilisation dune url dans les paramtres source et target Indique que lquipement supporte les expressions XPath dans llment filter
Oprations
Comme nous avons pu le voir, des messages sont envoys entre le client et le serveur, ces messages sont des oprations, NETCONF spcifie un ensemble doprations de base que nous allons voir, cependant un quipement peut annoncer quil supporte dautres oprations qui sont alors spcifiques celui-ci. Les oprations de base Get Permet de rcuprer la configuration active et des informations sur le statut de lquipement, on peut passer par le paramtre filter un filtre qui permettra de restreindre la partie de la configuration rcuprer ; par dfaut toute la configuration sera envoye. 16 get get-config edit-config copy-config delete-config lock unlock close-session kill-session
TX Gestion de Rseaux et gestion de la configuration avec NETCONF Get-config
Benot de Mianville
Lopration get-config accepte 2 paramtres, le premier se nomme source et permet de spcifier le nom de la configuration que lon veut rcuprer, le second se nomme filter et permet de spcifier la partie de la configuration que lon veut rcuprer, par dfaut toute la configuration est rcupre. Il est important de considrer que toutes les oprations ne seront pas forcment russies et quil faut traiter la rponse pour vrifier si elle est positive, par exemple une erreur rsultera en une balise <rpc-error> contenu dans la rponse <rpc-reply>. Un exemple contenu dans la RFC 4741 pour rcuprer 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 rponse 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>  </users> </top> </data> </rpc-reply>
Edit-config Sert charger une partie ou une nouvelle configuration dans lquipement. On peut choisir de fusionner, remplacer, supprimer ou crer une configuration. Il est possible de tester laction que lon va effectuer en spcifiant le paramtre test et en regardant la rponse. Les erreurs sont gres avec 17
Benot de Mianville
loption error-option ou lon peut spcifier ds quune erreur est dtecte des actions effectuer, savoir larrt de lopration, la poursuite de lopration et le rollback qui permet de revenir ltat avant opration. Copy-config Permet de crer ou dcraser une configuration avec une configuration existante. Delete-config Permet de supprimer une configuration, en sachant que la configuration active ne peut tre supprime. Lock et unlock Permet de verrouiller la configuration que lon passe en paramtre afin quaucune autre tentative de modification ne vienne interfrer (utilisation par une autre session NETCONF, un administrateur avec linterface en ligne de commande,). Unlock permet de dverrouiller la session si elle ne la pas dj 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 dverrouiller. Close-session Permet de terminer normalement une session NETCONF. Aprs une requte close-session, le serveur va relcher les verrous en cours et nacceptera plus de nouvelles requtes de la session. Kill-session Permet de terminer une session NETCONF. Toutes les oprations du serveur en cours sont arrtes, les verrous sont relchs et si un commit tait en cours, un roll back est effectu pour revenir ltat antrieur.
Exemple de messages changs

(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 dverrouille la candidate et la configuration en cours : 1. 2. 3. 4. 5. 6. lock <running/> database lock <candidate/> database edit <candidate/> database commit <candidate/> database unlock <candidate/> database unlock <running/> database
Les messages XML suivants seront alors changs : 18

<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
Benot de Mianville
19
Benot de Mianville
3.3 YANG
Introduction
NETCONF ne donne pas de directives quant la reprsentation des donnes de configuration que lon voit sur la figure ci-dessous en couche 4 . Cest donc YANG qui va dfinir cette couche.
Figure 4: couches protocolaires de NETCONF
Ci-dessous une illustration explicite de Andy Bierman (http://www.netconfcentral.org) qui nous prcise que YANG est utilis dans la couche de donnes ainsi que dans la dfinition des donnes NETCONF au sein des agents.
Figure 5 : YANG et NETCONF, Andy Bierman
Un exemple dutilisation de YANG consiste donner un logiciel client Netconf le module YANG dun serveur Netconf, ainsi le logiciel client pourra interroger le serveur avec les fonctionnalits spcifiques dcrites dans le module YANG. YANG est un langage de dfinition de donnes utilis pour modliser les donnes de configuration de NETCONF. YANG a t cr par le groupe de travail NETCONF Data Modeling Language (netmod) de lIETF spcifiquement pour NETCONF. YANG est dcrit dans la RFC 6020. 20
Benot de Mianville
Pourquoi YANG
YANG a t cr car aucun autre langage ne correspondait sa destination tout en tant simple demploi. YANG possde donc les qualits suivantes : Simple lire et apprendre Ecrit pour NETCONF et la gestion de rseau Extensible Une communaut technique ouverte aux nouveaux arrivants Commence tre utilis dans dautres groupes de travail
Types
La structure des donnes est ralise en utilisant des types : Boolean String Uint32 () Si un type spcial est dsir on peut le construire, par exemple pour reprsenter un pourcentage on utilise le type uint32 et on le restreint pour quil soit compris entre 0 et 100 : typedef percent { type uint8 { range "0 .. 100"; } }
On peut galement dfinir un type comme la runion de deux autres, cest le cas de ladresse ip qui est la runion des adresses ipV4 et ipV6 comme illustr ci-dessous.
typedefip-address { type union { type ipv4-address; type ipv6-address; }
21
Benot de Mianville
3.4 Les implmentations indpendantes des constructeurs

Netconf tant un protocole assez rcent, un nombre limit dimplmentations est disponible, nous allons parler ici des implmentations indpendantes des constructeurs, les implmentations clientes de Netconf et les implmentations serveurs installer sur des serveurs gnriques architecture x86 pour les configurer. Nous aborderons les possibilits de gestion de configuration dquipements rseau dans les parties suivantes. Une prsentation de Netconf de Carl Moberg (Tail-f) prsente une liste des principales implmentations de Netconf, Tail-f est une entreprise sudoise fonde en 2005 par un groupe de vtrans de lindustrie , elle propose des solutions logicielle de gestion gnrique de rseau en intgrant une multitude de protocoles de gestion, Tail-f a dailleurs une politique de promotion des standards et notamment celle de Netconf et Yang. Cette liste a t complte par des dtails et est prsente ci-dessous. Les premires implmentations de la liste sont des logiciels commerciaux, les autres sont open source. La plupart des implmentations clientes sont des bibliothques 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 ltat de prototype.
22
TX Gestion de Rseaux et gestion de la configuration avec NETCONF Solution NETCONF Browser Professional Edition (client) POCO Netconf (serveur) NOCVue ConfigMan NETCONF MindAgent (serveur) EPIC NETCONF (serveur) ConfD (serveur) NCS (client) NetconfX (client) Type Shareware Editeur MG-SOFT Corporati on Applied informati cs Velankani Oracle/G oAhead Prix 1428 TTC Plateforme Windows/Mac OS/Linux (Java)
Benot de Mianville Adresse www.mgsoft.si
Shareware
Sur demande
Framework C++
www.appinf.c om www.nocvue. com/ goahead.com
ShareWare Shareware
Sur demande Sur demande
Non communiqu Inclus dans le framework embeddedMIND Non prcis Framework Framework Java
Shareware Shareware Open Source, payant si dans une solution commerciale ShareWare
SNMP Research Tail-f Systems Centered Logic
Sur demande Sur demande Sur demande
www.snmp.co m/ www.tailf.com centeredlogic. com
WebNMS Framework (client) Ncclient (client) Netopeer (client/serveur) YencaP (client/server)
WebNMS
Sur demande
Framework
www.webnms .com schmizz.net/n cclient/ code.google.c om/p/netope er/ ensuite.source forge.net/
Open Source Open Source
Shikhar Bhushan Radek Krej LORIAINRIA Lorraine, Emmanue l Nataf et Frederic Beck (autheur original : Vincent Cridlig) Netconf central (Andy Bierman)
Open Source Open Source
Librairie python Linux
Open Source
Open Source
Linux, web UI
Yuma(client/ser ver)
Open Source
Open Source
Linux
www.netconfc entral.org/
Tableau 3 : Les diffrents clients NETCONF
23
Benot de Mianville
3.5 Les quipementiers rseaux

La mme prsentation10 de Carl Moberg (Tail-f) qui prsente les implmentations clientes de Netconf prsente galement une liste des principaux constructeurs implmentant Netconf. Il sagit principalement dquipements rseaux tels que des switch et des routeurs mais galement des quipements plus spcifiques adapts la distribution de vidos, la messagerie lectronique, entre autres. Constructeur Alaxala Cisco Ericsson Juniper Networks RuggedCom Taseon Verivue Edgeware Nexor Telco Systems Dtails Ethernet switches Routeurs et switch IOS 12.4(9)T et suprieurs, IOS XE 2.1 et suprieurs Equipements rseaux JUNOS 7.5 and later Routeurs et switch, RX5000 et MX5000 Intelligent optical networks, TN 320 Next-generation video distribution, MDX 9020 Servers on-demand TV, WTV-2X Messaging Gateways Carrier Ethernet Multiservice Aggregation, T-Metro 7224
Tableau 4 : Les quipements implmentant NETCONF
10
Prsentation de Carl Moberg : http://www.slideshare.net/cmoberg/a-30minute-introduction-to-netconfand-yang
24
Benot de Mianville
4 NETCONF en pratique
Nous avons dcrit les problmatiques de la gestion de la configuration dans un rseau. Nous avons dcrit Netconf, son modle de donnes Yang, ses implmentations clientes et serveurs et les implmentations des quipementiers rseaux, nous avons dit que Netconf tait LA solution innovante et gnrique pour pallier aux dfauts des outils et mthodes actuelles de gestion de configuration, tentons de le dmontrer, allons regarder dans des scnarios concrets la valeur ajoute de cette nouvelle mthode. Nous aborderons cette partie par une approche pratique en dcrivant les clients et les serveurs que nous allons utiliser et les configurations ncessaires, ensuite nous dcrirons en dtail limplmentation de Cisco puisque cest celle-ci qui a t choisie pour lexprimentation, enfin nous montrerons Netconf dans des cas pratiques au travers de scnarios.
4.1 Premiers pas avec Netconf

4.1.1 Les clients Netconf utiliss
Connexion brute en SSH

Afin de bien comprendre le protocole Netconf, une communication avec un tunnel SSH et des donnes 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 fonctionnalits du protocole. Le tunnel se fait depuis un ordinateur sous Linux en tapant la commande suivante depuis un terminal : ssh -2 -s <nom dutilisateur>@<serveur Netconf> netconf
Loption -2 spcifie la version 2 de SSH utiliser, <nom dutilisateur> est le nom dutilisateur habilit lancer une session Netconf sur le serveur, <serveur> est ladresse IP ou le nom rsoudre via le protocole DNS (Domain Name Server) du serveur, loption s avec le mot cl netconf la fin de la ligne spcifie le sous-systme utiliser sur lhte distant.
Yuma Yangcli
Le logiciel Yuma est maintenu par Andy Bierman, co-auteur de la dernire RFC dcrivant Netconf, aussi auteur du site Netconf central. Yuma est une suite logicielle contenant un serveur (netconfd), un client (Yangcli) et dautres 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 aprs de nombreuses amliorations, il est maintenu par un expert du protocole et il prsente une finition exemplaire avec de la documentation trs bien fournie, une communaut de dveloppeurs et dutilisateurs active qui ma rendu service pour cette exprimentation. Yuma fonctionne sur les systmes Linux en mode ligne de commande trs aboutie. Nous utiliserons donc la partie cliente de Yuma : Yangcli. La partie ci-dessous dcrit linstallation de Yangcli. Installation de Yuma Tlcharger le paquet correspondant votre distribution sur le site de lditeur:
25
TX Gestion de Rseaux et gestion de la configuration avec NETCONF http://www.netconfcentral.org/download
Benot de Mianville
Nous allons dcrire linstallation pour Ubuntu 11.10 32 bits et Yuma en version 2.1-2. Aprs avoir tlcharg le paquet nomm yuma-2.1-2.u1104.i386.deb, ouvrez un terminal et placezvous dans le mme rpertoire que le paquet. Assurez-vous que les librairies externes requises sont prsentes: mydir> dpkg --list libxml2 Si ces librairies sont installes, vous verrez ce rsultat safficher : benoit@benoit-Vostro-1520:~/Tlchargements$ dpkg --list libxml2 Souhait=inconnU/Install/suppRim/Purg/H= garder | tat=Non/Install/fichier-Config/dpaqUet/chec-conFig/H=semi-install/W=attend-traitementdclenchements |/ Err?=(aucune)/besoin Rinstallation (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 laide de la commande suivante : mydir> sudo apt-get install libxml2 Une fois cette tape prliminaire 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 rpertoire /usr/bin : -rwxr-xr-x 1 root root 294180 2011-09-28 20:38 /usr/bin/yangcli
MGSoft Netconf Browser

Lentreprise MGSoft travaille depuis 1998 avec le protocole SNMPv3, ils ont dvelopp le logiciel Netconf Browser en partenariat avec Tail-F (dcrit dans les parties prcdentes) et lont test avec le logiciel dcrit prcdemment, Yuma ainsi quun autre, yencap. Netconf Browser est un client, propose une interface graphique sous Windows et permet de charger des modules Yang adapts au serveur avec lequel on interagit, il permet galement dutiliser les fonctionnalits propres au matriel et les fonctionnalits de base avec un simple clic, le logiciel se chargeant de gnrer le code XML appropri. Il est possible de voir les codes XML envoys et reus en allant regarder les fichiers de log, cest ceux-ci qui ont t utiliss pour comprendre comment le logiciel et le routeur communiquaient entre eux.
26
TX Gestion de Rseaux et gestion de la configuration avec NETCONF 4.1.2 Les serveurs Netconf utiliss
Benot de Mianville
Routeur Cisco
Les quipements rseaux de la salle de TP tant du constructeur Cisco, nous allons nous intresser limplmentation de Netconf que propose ce constructeur. Cisco dtaille la disponibilit de la fonctionnalit Netconf over SSHv2 dans le tableau ci-dessous11 : Nom de la fonctionnalit Netconf over SSHv2 Version de systme 12.2(33)SRA 12.4(9)T Information sur la fonctionnalit La fonctionnalit Netconf over SSHv2 permet de grer la configuration rseau via linterface en ligne de commande (CLI) travers une couche transport chiffre. Le protocole Netconf dfinit un mcanisme simple travers lequel un quipement rseau peut tre gr, les informations de configuration peuvent tre rcupres et des nouvelles donnes de configuration peuvent tre places et manipules. Netconf utilise XML pour reprsenter ses donnes de configuration et les messages du protocole. Cette fonctionnalit a t introduite dans lIOS 12.4(9)T.
Tableau 5 : Disponibilit de Netconf dans le systme de Cisco
Les routeurs utiliss sont les suivants : Cisco 2801 IOS 12.4(15) T1 Cisco 1841 IOS 12.4(24) T2
4.1.3 Configuration dun routeur Cisco Il faut en premier lieu sassurer davoir un IOS compatible, ceci est dcrit dans la partie prcdente. 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 27

2. 3. 4. 5. 6. 7. configure terminal hostname hostname ip domain-name name crypto key generate rsa ip ssh [timeout seconds | authentication-retries integer] ip ssh version 2
Benot de Mianville
Ensuite :
#aaa new-model #username cisco password 0 cisco
On peut ds prsent tester la connectivit SSH avec Putty par exemple.
Configuration de NETCONF :
1. 2. 3. 4. 5. enable configure terminal netconf ssh [acl access-list-number] netconf lock-time seconds netconf max-sessions session
Une fois la configuration effectue, on peut tester avec succs Netconf, cependant si on copie la configuration du routeur dans un fichier, et quon la remet dans un routeur sans configuration, il ne faudra pas oublier de retaper manuellement linstruction de gnration des cls RSA (crypto key generate rsa).
Vrifier la configuration
Pour visualiser ltat du protocole Netconf sur le routeur, les commandes suivantes sont disponibles : Show netconf counters Show Netconf session
Les copies dcran ci-dessous montrent les sorties de ces commandes.
28
Benot de Mianville
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 unknownattribute 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 operationfailed 1 partial-operation 0
On voit sur la sortie ci-dessus que deux tentatives de connexion ont t effectues, 2 ont russi. Dans les transactions, on en compte 3 dont une en erreur et 2 qui ont russi ; lerreur est operation-failed cest effectivement un client qui a effectu une opration 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 quune session Netconf est active et que 5 peuvent ltre au maximum. On remarque que la session active est avec ladresse IP 192.168.10.1 qui est mon ordinateur portable et lutilisateur cisco a t utilis pour lauthentification, en effet ce nest pas le mot de passe du mode privilgi qui est utilis, il nest pas pris en compte. On remarque galement lid de la session, (Session id:1697800880) qui est gre par le serveur Netconf donc le routeur dans notre cas.
Afficher le schma du modle de donnes

Sur certaines versions dIOS il est possible dafficher le schma du modle de donnes de lquipement, la commande est la suivante : Show netconf schema
On peut voir en annexe un exemple de schma. 29
Benot de Mianville
4.1.4 Le cas de limplmentation de Cisco Les premiers tests avec les routeurs Cisco (dcrits prcdemment) ont t quelque peu dcourageants, en effet aucun client ne parvenait tablir une communication ni avec le protocole de base 1.0 qui est la premire RFC ni avec le protocole de base 1.1 qui est la dernire RFC dcrivant le protocole Netconf. Les changes ont donc t tests en ligne de commande avec un tunnel ssh depuis une machine UNIX et jai dcouvert que le protocole Netconf ntait pas respect, les messages ntant pas bien forms. De plus Cisco ne fournissant pas le modle de donnes spcifique au matriel au format YANG, jai continu les essais ttons, je suis parvenu en madaptant au matriel tablir une session Netconf avec succs, rcuprer la configuration au format CLI de Cisco ainsi quau format XML. Une discussion par mail avec Juergen Schoenwaelder, co-auteur de la dernire RFC dcrivant Netconf ma indiqu que malgr les amliorations de Cisco sur Netconf, ce ntait pas la meilleure plateforme dapprentissage de ce protocole. Une autre discussion avec le dveloppeur du logiciel client Netconf (et galement serveur) YUMA, galement co-auteur de la dernire RFC dcrivant Netconf : Andy Bierman, a mis en vidence la non compatibilit de limplmentation de Cisco notamment en montrant un bug dcrit dans les annonces de fonctionnalits du routeur. Lquipe de MG-Soft ayant bien voulu me faire essayer leur logiciel Netconf Browser, je leur ai fait part des incompatibilits rencontres et ils ont t trs ractifs pour essayer de les comprendre, dans un autre temps ils mont envoy une version modifie de leur logiciel qui acceptait de recevoir un message non standard de la part du serveur, malgr cette modification, un change complet avec rcupration ou dition de la configuration nest pas possible puisque le modle de donnes YANG de lquipement Cisco nest pas fourni ; de plus mme les oprations standards ne ncessitant pas de connaitre le modle de donnes spcifique chouent, en effet le parseur XML ne parvient pas interprter les messages non standards. Lquipe de MG-Soft tant trs encline pouvoir adapter son logiciel limplmentation de Cisco pour tre complte, elle ma propos daccder distance au routeur pour comprendre les adaptations effectuer, seulement cette solution na pas t choisie pour la raison que je vais vous expliquer. La raison de mon choix de ne pas persvrer adapter un client limplmentation Netconf de Cisco a t prise en fonction de recherches sur ladite implmentation. Un document rcent12 dcrivant un des routeurs de Cisco publi en octobre 2009 et mis jour en fvrier 2011 indique que limplmentation de Cisco se base sur le draft-ietf-netconf-prot-07 [Enns, 2005] publi le 29 juin 2005, brouillon qui a servi rdiger la premire version de la RFC de Netconf. Le document de Cisco indique galement quun modle de donnes bas sur XML est disponible et spcifique un quipement, ce nest donc pas le standard YANG qui est sorti plus tard. Sachant que les dernires versions des quipements de Cisco utilisent une version ancestrale du protocole Netconf (le brouillon indique quil expirera le 31 dcembre 2005), et que les logiciels clients utilisent les dernires versions du protocole Netconf avec le modle de donnes YANG, une rtro compatibilit dun client serait trop spcifique dvelopper 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
30
Benot de Mianville
Avant den arriver cette conclusion, beaucoup de temps a t pass essayer de faire communiquer un logiciel client avec limplmentation routeur de Cisco, nous dtaillons maintenant cette partie. La partie ci-dessous dcrit 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 spcifiant dutiliser 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 lon utilisera la premire version de la RFC de Netconf (autre valeur possible : 1.1) base:1.0 // Indique que lquipement supporte une configuration en cours et une configuration de dmarrage distincte startup:1.0 Server Module Capabilities None Server Enterprise Capabilities // Il est possible dcrire directement dans la configuration actuelle. Cela signifie que lquipement supporte edit-config et copy-config sur la configuration en cours (la running configuration ) Cependant cest un bug de Cisco, lURI correcte est urn:ietf:params:netconf:capability:writablerunning:1.0 urn:ietf:params:netconf:capability:writeable-running:1.0 // Lquipement supporte lutilisation dune url dans les paramtres 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 dfaut nest pas initialise, il ny aura pas ddition 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... 31
Benot de Mianville
Warning: skipping enterprise capability for URI 'urn:ietf:params:netconf:capability:writeablerunning:1.0' Warning: skipping enterprise capability for URI 'urn:ietf:params:netconf:capability:url:1.0' Warning: skipping enterprise capability for URI 'urn:cisco:params:netconf:capability:notification:1.0' yangcli cisco@192.168.10.254> //A ce point-l, Yangcli na 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 rpertoire des modules puis utiliser la commande mgrload <nom du module> .
Malgr les incompatibilits rencontres (Cisco ne fournit pas de module Yang, le routeur utilise une version brouillon publie avant la premire RFC et il ya un bug de nom de fonctionnalit), nous allons continuer et tenter deffectuer une fonctionnalit standard get .
Yangcli, rcupration de donnes

Le raccourci pour la fonctionnalit get est simplement get . yangcli cisco@192.168.10.254> get Afin de voir les changes XML, on peut lancer Yangcli en mode debug avec les commandes suivantes : //On utilisera le niveau 4 qui est le niveau maximum de dtails de dbogage --log-level=<debug> //La commande ci-dessous sert spcifier 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 mme temps. On peut alors voir la sortie XML du logiciel lors de lappel 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 caractre spcial 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.ht ml#wp1054570) On remarque que Yangcli crit galement cette suite de caractres special. </rpc>]]>]]>
32
Benot de Mianville
<?xml version="1.0" encoding="UTF-8"?><rpc-reply message-id="1" xmlns="urn:ietf:params:netconf:base:1.0"><data><cli-config-datablock>! 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 ny a pas la suite de caractres spciaux, 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 na pas russi a obtenir la fin du message et ceci rsulte en une coupure brutale de la session et en un arrt du logiciel, on ne verra apparaitre la configuration du routeur que dans le log Shutting down yangcli
Etant donn quil nest pas possible deffectuer des actions de base avec Yangcli, je ne persvrerai pas avec celui-ci, le logiciel MGSoft Netconf browser ntant 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 dcrit les clients, nous verrons directement les sorties XML. Comme lindique la RFC6241 de Netconf, lors de ltablissement de la session, le client et le serveur senvoient un message hello et schangent leurs fonctionnalits. Les messages Hello sont envoys ds ltablissement de la session, sans attendre aucun message, de la part du serveur et du client. Un message Hello scrit en XML de la faon suivante :
33
TX Gestion de Rseaux et gestion de la configuration avec NETCONF <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>
Benot de Mianville
Le support de la capacit base est obligatoire, il indique la version de Netconf qui sera utilise 1.0 ou 1.1. Le client et le serveur doivent obligatoirement utiliser la mme version de base, si deux versions sont communment annonces par le client et le serveur, la version la plus haute sera utilise. Le serveur doit annoncer le numro de session dans la balise session-id et le client ne doit pas annoncer de numro de session (dixit la RFC). Voyons dans ce tableau rcapitulatif les messages que doivent senvoyer le client et le serveur : Contenus des messages Hello envoys lors de ltablissement de la session : Session id Description Numro de session Base Capacit obligatoire, indique la version de Netconf qui sera utilise Oui Oui Autres fonctionnalits
Client Serveur
Non oui
Le message hello que nous allons envoyer comportera donc le paramtre base 1.0. Voici le message hello envoyer selon la RFC :
Seulement, pour sadapter au routeur, nous allons lui envoyer un message hello comme lui les forme et comme la documentation de Cisco le prconise :
34
Benot de Mianville
Le message hello du routeur devrait faire apparaitre le paramtre base, lid de session ainsi que le support dautre fonctionnalits :
On voit bien le paramtre base 1.0, on se basera donc sur la premire version de la RFC, on a galement dautres fonctionnalits qui sont dcrites dans la partie prcdente de manire dtaille (partie Yuma). On voit galement lid de session, cest ce que prconise la RFC. Jusque ici, la connexion sest correctement effectue, le client et le serveur se sont correctement changs les messages hello et on peut vrifier dans le routeur avec la commande show netconf session quune session est bien active.
SSH brut, rcupration de donnes

Nous allons maintenant effectuer une action de base : rcuprer la configuration, pour ce cas prsent, on na pas besoin du schma du routeur car cest une opration standard dont la syntaxe est la suivante :
La syntaxe est reprise la RFC, il faut encapsuler la requte dans un message RPC et donner un message-id en attribut afin quon puisse identifier la rponse dans le cas o plusieurs requtes seraient en cours. La rponse est la suivante :
35
Benot de Mianville
//Le milieu a t tronqu pour des raisons de lisibilit
On voit bien dans la rponse lid rpc qui correspond la requte 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 schma de lquipement (voir annexe), on voit que dans le nud source figure la type de donnes CLI en bloc vu prcdemment mais galement <xml-config-data> qui reprsente la configuration du routeur en XML, nous allons donc selon ce schma extraire du routeur sa configuration en XML. Le message form sera le suivant :
On utilisera la balise filter et on spcifiera le format qui est dcrit dans le schma. La rponse du routeur est la suivante :
36
Benot de Mianville
//Le milieu a t tronqu pour des raisons de lisibilit
Vous pouvez retrouver la rponse non tronque au format XML dans lannexe. Cette partie a expliqu en dtails limplmentation Netconf de Cisco, nous avons remarqu que celleci utilisait une version pr-RFC et qu lheure actuelle les clients se basant sur les RFC rcentes ne pouvaient communiquer avec lIOS de Cisco, il est possible que Cisco ait dvelopp une nouvelle version de son implmentation mais les quelques documentations de Netconf sont assez anciennes et les rcentes documentations des quipements ne parlent pas dune autre version. Evidemment il va sans dire que dautres quipementiers sont sans doute plus jour dans ce domaine et cest vers eux quil faudra se tourner si on veut absolument utiliser Netconf avec des clients standards, dans le cas contraire il faudra dvelopper un outil exclusivement adapt au matriel Cisco comme le dcrit la documentation Cisco enhanced device interface, Netconf GUI13 . Nous allons donc continuer nos tests sans client autre que des messages XML changs travers un tunnel SSH en ligne de commande, et cela au travers de scnarios.
13
Cisco EDI Netconf GUI http://www.cisco.com/en/US/docs/net_mgmt/enhanced_device_interface/2.2/developer/guide/ntcfapp.html
37
Benot de Mianville
4.2 Scnario salle de travaux pratiques de services rseaux lUTT

Notre exprience va consister utiliser Netconf pour configurer un environnement rseau. Lenvironnement rseau choisi est celui dune salle de TP dont larchitecture est dcrite sur le schma ci-dessous :
Figure 6 : Architecture du scnario
Larchitecture est compose dun routeur central connect un Switch sur lequel tous les binmes dtudiants viennent connecter leur architecture qui est dcrite dans le schma logique ci-dessus. Pour focaliser notre travail sur Netconf et simplifier larchitecture, on ne configurera pas le lien qui part du routeur central vers lInternet, il nest dailleurs pas reprsent sur le schma ci-dessus. La premire tape va consister reproduire le rseau de test sans mettre en place Netconf, on utilisera le logiciel de simulation de rseau Cisco Packet Tracer. Ensuite on dcrira les tests qui permettent dattester de la bonne configuration du rseau. Ensuite on prcisera quels quipements pourront tre grs avec Netconf et on donnera leur configuration. Ltape suivante consiste dcrire les prrequis la configuration avec Netconf de manire littraire puis de manire technique. Enfin on pourra dployer la configuration et effectuer les tests.
38
TX Gestion de Rseaux et gestion de la configuration avec NETCONF 4.2.1 Schma dadressage du rseau de test
Partie centrale
Benot de Mianville
.2
.2
172.16.1.0/30
172.16.2.0/30
Binme 1
.1 .1
Binme 2
.126
.254
.126
.254
192.168.1.0/25 192.168.1.128/25 192.168.2.0/25
192.168.2.128/25
.129 .1
.1
.129
Figure 7 : Schma d'adressage du rseau
39
TX Gestion de Rseaux et gestion de la configuration avec NETCONF 4.2.2 Schma physique du rseau de test Partie centrale
Benot de Mianville
RT CENTRAL
Fa0/1 Fa0/24
SW CENTRAL
Fa0/1 Fa0/2
Binme 1
Binme 2
Fa0/1
Fa0/1
RT Binome1
Fa0/0 Fa0/24 Fa0/1 Fa0/2
RT Binome 2
Fa0/0 Fa0/24 Fa0/1 Fa0/2
SW Binome 1
SW Binome 2
Server 1
PC 1
Server 2
PC 2
Figure 8 : Schma physique du rseau
4.2.3 Tests prouvant la bonne configuration du rseau On utilisera des ping icmp pour vrifier la bonne configuration du rseau. 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 gre avec Netconf est la suivante : Le routeur central, Cisco 1841, IOS 12.4(24)T2 Les routeurs des binmes, Cisco 2801, IOS 12.4(15)T1 Le switch central, Cisco 2950, IOS 12.1(22)EA4 Les switch des binmes, Cisco 2960, IOS 12.2(25)SEE3 40
TX Gestion de Rseaux et gestion de la configuration avec NETCONF 4.2.5 Configuration des quipements configurer avec Netconf
Benot de Mianville
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
41
TX Gestion de Rseaux et gestion de la configuration avec NETCONF Configuration du routeur du binme 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
Benot de Mianville
Configuration du Switch du binme 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 42
Benot de Mianville
La configuration du switch du binme 2 est la mme que celui du binme 1, la configuration du routeur du binme 2 est la mme que celle du binme 1 lexception prs de ladressage qui est respecter, la seule instance dOSPF est galement dans la zone 30. 4.2.6 Prrequis la configuration avec Netconf Les IOS implmentant Netconf sont dcrits dans les parties prcdentes, il est ncessaire que les quipements grer avec Netconf implmentent Netconf. Afin que le client Netconf puisse configurer les quipements rseau, les lments suivants sont requis : Une connectivit rseau entre lquipement et le client Netconf Le paramtrage Netconf de lquipement (dcrit en dtail dans la partie configuration dun routeur )
Ensuite il est ncessaire que le client Netconf connaisse la version de Netconf de lquipement ainsi que le modle de donnes de lquipement ; dans notre cas la version de Netconf des quipements Cisco respecte le draft-ietf-netconf-prot-0714 et le modle de donnes utilis sera la version CLI de la configuration. Pour que le client Netconf puisse avoir une connectivit rseau avec les quipements, jai choisi de placer les quipements dans un segment ddi et de placer galement le client dans le mme segment :
14
http://tools.ietf.org/html/draft-ietf-netconf-prot-07
43
Benot de Mianville
.2 192.168.100.0/24
.3
.4
.1 .7
VLAN 100
.5
Serveur NETCONF
Client NETCONF
.6
Figure 9 : Segment ddi NETCONF
On remarquera que les routeurs utiliss nont que deux interfaces rseau 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 dinterfaces ddies la fonction principale des routeurs. La configuration prrequis des quipements rseau est donc la suivante :
44
TX Gestion de Rseaux et gestion de la configuration avec NETCONF 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
Benot de Mianville
On remarque quon a indiqu la sous interface de marquer ses trames avec le VLAN 100 et quon a configur Netconf avec SSH comme indiqu dans les parties prcdentes. Les autres routeurs ont la mme configuration de Netconf et du VLAN, ils ont une adresse IP diffrente que lon peut voir dans le schma ci-dessus. Il ne faut pas oublier de gnrer les cls SSH la premire fois, comme le dcrit la partie configuration dun routeur (crypto key generate rsa). Les switch utiliss en salle de TP nimplmentant pas Netconf, on manipulera donc leur configuration de manire classique (avec une connexion srie ou avec une connexion SSH ou encore Telnet), cependant la configuration de Netconf aurait t la mme et on aurait donn les adresses IP respectives aux Switch en mettant une adresse IP linterface VLAN 100 . Une fois que les routeurs sont configurs selon le prrequis, il est ncessaire denregistrer cette configuration dans la mmoire de dmarrage, appele startup configuration, la commande cidessous effectue cet enregistrement : Write memory La commande suivante est aussi possible : copy running-config startup-config 45
Benot de Mianville
Remarque : le besoin denregistrer les configurations en mmoire non volatile est justifi si on veut grer de manire systmatique les quipements avec Netconf. 4.2.7 Dploiement de la configuration Ltape finale qui va consister dployer la configuration est maintenant possible. Le prrequis qui impose que les routeurs aient une connectivit rseau avec le client Netconf et qui indirectement nous a amen crer une sous interface supplmentaire 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
46
Benot de Mianville
Ce qui change cest la configuration prrequis , lactivation de Netconf avec SSH. Cest donc cette configuration que lon injectera dans le routeur central. La configuration des routeurs binme 1 et binme 2 change galement, en effet dans le scnario de base sans Netconf, linterface 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 dorigine et une autre qui assurera la connectivit rseau jusquau 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 47
TX Gestion de Rseaux et gestion de la configuration avec NETCONF ! 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
Benot de Mianville
La configuration du routeur binome 2 diffre dans ladressage rseau. Etant donn que limplmentation de nos routeurs Cisco na 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 quil est possible de prenniser la configuration dans une mmoire non volatile, nous allons verrouiller la configuration active, lditer puis la dverrouiller. Il aurait cependant t intressant de voir le scnario avec une configuration candidate ou on aurait pu tester les fonctions de commit et de roll back (retour en arrire) en cas derreur. La procdure va tre la suivante : 1. 2. 3. 4. 5. 6. Connexion au serveur Envoi du message Hello Verrouillage de la configuration en cours (running) Edition de la configuration en cours Retrait du verrou sur la configuration en cours Fermeture de la session
Ces oprations vont tre appliques 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 ladresse IP se terminant en .4) : ssh -2 -s cisco@192.168.100.4 netconf
48
TX Gestion de Rseaux et gestion de la configuration avec NETCONF 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>]]>]]> Rponse du routeur :
Benot de Mianville
<?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 vrifier que la configuration en cours est bien verrouille 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 verrouille.
49
Benot de Mianville
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 reprsentation 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 rponse 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>]]>]]>
50
TX Gestion de Rseaux et gestion de la configuration avec NETCONF 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 nest pas ncessaire. 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>]]>]]> Rponse 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>]]>]]>
Benot de Mianville
Rponse 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 mmes tapes sont rpter sur les routeurs binome 1 et binome 2 en changeant la configuration envoye. La fonction notification de Netconf na pas t illustre, elle permet au serveur denvoyer des messages au client Netconf lors dun vnement particulier, dans lexemple ci-dessous on inscrit notre client auprs du serveur pour quil reoive ses notifications puis on modifie la configuration et on observe la notification envoye :
51
TX Gestion de Rseaux et gestion de la configuration avec NETCONF Enregistrement auprs du serveur pour recevoir les notifications : <?xml version="1.0" encoding="UTF-8"?> <rpc message-id="1"> <notification-on/> </rpc>]]>]]>
Benot de Mianville
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>]]>]]>
Rponse : <?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>
52
TX Gestion de Rseaux et gestion de la configuration avec NETCONF Puis la notification :
Benot de Mianville
Remarque : jai volontairement color la notification pour plus de lisibilit. On observe dans la notification les dtails : la commande effectue, lancien tat puis le nouvel tat. On a galement des informations sur lauteur de la modification, son adresse IP ainsi que lheure prcise. 4.2.8 Analyse du scnario On peut tout dabord noter que lexprience est un succs. En effet malgr le manque dinteroprabilit avec un logiciel client Netconf et limplmentation Netconf Cisco qui se base sur un brouillon sur lequel il est indiqu quil expirera le 31 dcembre 2005, nous avons russi dployer les configurations. Cependant le dploiement na pas t ais et on peut se baser sur la ncessit de connaitre le protocole Netconf, limplmentation de Cisco et le modle de donnes particulier du routeur pour conclure sur le fait que dployer la configuration avec Netconf sur du matriel Cisco est long, ncessite une configuration de base qui peut gner la cration de certaines topologies et napporte pas une grande valeur ajoute dans notre scnario prcis de salle de TP rseau . Le ct trs dynamique dans le changement de la topologie de cette salle de rseau partage nest pas trs adapt pour Netconf. 53
Benot de Mianville
En grant la configuration de manire classique, on doit se connecter de manire physique un par un chaque routeur puis chaque switch pour copier-coller une configuration, avec Netconf, une fois ltape de prrequis effectue, un seul poste peut, sans avoir besoin dautre branchement, envoyer les configurations. La consquence dun changement de matriel sil est diffrent obligerait sintresser son implmentation de Netconf pour pouvoir lutiliser. En omettant la partie configuration prrequis pour Netconf, si on compare le temps de dploiement de configuration avec et sans Netconf, cest sensiblement la mme chose. La valeur ajoute pourrait rsider dans les notifications puisquune personne intresse pourrait sinscrire pour recevoir le dtail des nouveaux vnements de lquipement. Je pense quavec du matriel standard suivant les RFC rcentes de Netconf et un logiciel client Netconf rcent, on amliorerait la gestion de la configuration, une quipe rseau pourrait savoir qui a effectu une modification sur un matriel, quelle date et connaitre lancienne configuration, cest vraiment une trs grande valeur ajoute davoir cette fonctionnalit de manire standard.
54
Benot de Mianville
4.3 Scnario oprateur tlcom avec gestion de la QoS

Ce scnario na pas t pratiqu mais il est l pour illustrer un cas dutilisation de Netconf qui aurait plus de sens, ce scnario illustre une gestion de la configuration avec plus de valeur ajoute compar une gestion de la configuration classique, sans outils adapts ou avec des outils trs manuels comme des fichiers textes dans des rpertoires avec des mthodes de gestion de lhistorique contraignantes en terme de temps et de rptition. Ce scnario prsente donc la gestion de la configuration au sein dun rseau simplifi doprateur qui fournit ses clients des contrats de qualit de service nomms SLA (Service Level Agreement) qui se traduisent en termes techniques nomms SLS (Service Level Specification). On prend lexemple o le trafic achemin par le routeur du client, reprsent en bas gauche sur le schma 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 dbit total 10Mb/s. Ce contrat dure une dure dtermine. Le principe sera dans un premier temps dcrire la configuration des routeurs, dans un second temps on pourra la dployer puis enfin la retirer si le contrat arrive chance. Les notifications qui permettent davertir le client qui sy est inscrit prviendraient les administrateurs rseau des modifications de configuration de manire dtaille, et on peut facilement imaginer un outil dautomatisation de gestion de la configuration se reposant sur la gnricit de linterface que propose Netconf. En effet auparavant il nexistait pas doutil standardis, des outils permettait de faire du scripting avec linterprteur de commande de Cisco mais alors on tait li ce constructeur ou une version du matriel, avec Netconf on peut esprer unifier linterface avec laquelle on modifiera la configuration des quipements, condition que les constructeurs dquipement soit du mme avis car ils prfreront peut tre commercialiser une mthode unifie de grer la configuration de leurs quipements.
55
Benot de Mianville
Figure 10 : Schma logique du scnario
56
Benot de Mianville
5 Conclusion
Nous avons dcrit les diffrentes approche de la gestion de rseau, nous avons ensuite dcrit Netconf de manire thorique, nous avons vu que ctait un protocole jeune compar aux autres protocoles de la gestion de rseau mais que celui-ci sinspirai des faiblesses des autres protocoles pour proposer une solution simple et standardise de gestion de la configuration. Notre scnario a illustr la mise en uvre de ce protocole et a mis en vidence les faiblesses de NETCONF : sa jeunesse qui pose des problmes de compatibilit au niveau des versions car les acteurs rseau notamment Cisco na pas encore confirm son adoption du protocole, du moins il propose dans ses quipements rcents une implmentation expire depuis 2005. Ces problmes de compatibilit sont importants dans le domaine des systmes ferms comme les constructeurs rseau mais le sont moins en revanche dans le domaine des systmes (des serveurs par exemple) puisque YUMA propose une version serveur trs aboutie de NETCONF. Pour ceux qui ne voudraient pas attendre pour utiliser NETCONF en production avec des quipements rseau, il semblerait que les auteurs de NETCONF prconisent le constructeur JUNIPER puisquun document de J.Schnwalder illustrant la pratique de NETCONF lors dune session pratique luniversit de Zurich15 dcrit les fonctionnalits 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 premire RFC publie en 2006, NETCONF a beaucoup mri, dautres RFC ont t publie, notamment sur lutilisation de protocoles de transport (SSH, SOAP et BEEP), les notifications, le modle de donnes YANG, la seconde version de NETCONF parue en juin 2011 ainsi que la RFC 6244 qui dcrit une architecture de gestion de rseau avec YANG et NETCONF. Les brouillons en cours de rdaction concernent des amliorations au niveau de la scurit, des nouveauts pour le contrle daccs. A lheure de la rdaction de ce document il nest pas possible de prvoir les tendances de NETCONF, un protocole bien tablit, fournissant des mthodes novatrices et standards avec une documentation de grande qualit ne suffisent pas toujours son adoption, le ct standard nest un atout que sil est adopt de manire gnrale. Dans tous les cas NETCONF est un protocole complet, scuris, dont des implmentations commerciales et libres sont disponibles et a t reconnu par des leaders des constructeurs dquipements rseau, si ceux-ci continuent le reconnaitre, il ny a pas de raison que NETCONF ne devienne pas une rfrence dans la gestion de la configuration rseau de manire prenne.
15
http://www.aims-conference.org/issnsm-2008/06-netconf-Exercises.pdf
57
Benot de Mianville
6 Bibliographie
[Pujolle et al., 2004] Guy Pujolle, Olivier Salvatori, Jacques Nozick, Les Rseaux, dition 2005, Eyrolles, 2005 [Agoulmine et al., 2003] Nazim Agoulmine, Omar Cherkaoui, Pratique de la gestion de rseau Solutions de contrle et de supervision d'quipements rseau pour les entreprises et les oprateurs tlcoms, 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
58
Benot de Mianville
7 Annexe
Sortie de la commande get avec filtre XML sur routeur Cisco :
Benot de Mianville
Benot de Mianville
Benot de Mianville
Affichage du schma du modle de donnes NETCONF dun routeur

Commande : show netconf schema Ci-dessous le schma 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 4
TX Gestion de Rseaux et gestion de la configuration avec NETCONF <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
Benot de Mianville
TX Gestion de Rseaux et gestion de la configuration avec NETCONF <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
Benot de Mianville

TX Netconf Gestion de Configuration DEMIANVILLE

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

TX Netconf Gestion de Configuration DEMIANVILLE

Загружено:

Авторское право:

Доступные форматы

Etudiant : DE MIANVILLE Benot Responsables : PLOIX Alain, DOYEN Guillaume

Branche : SIT5 Anne : 2011

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

2.4.1 2.4.2 2.4.3 2.4.4 2.5

2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.5.6 2.5.7 3

4.1.1 4.1.2 4.1.3 4.1.4 4.2

4.2.3 4.2.4 4.2.5 4.2.6 4.2.7 4.2.8 4.3 5 6 7

Scnario oprateur tlcom avec gestion de la QoS ............................................................ 55

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

IETF : Internet Engineering Task Force

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

2 Cheminement pour le choix dune plateforme de gestion

2.1 Le contexte rseau

2.2 Les acteurs

Tableau 1 : Mise en vidence de l'appartenance des lments composants le rseau

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

2.3 Les aires fonctionnelles

2.4 Interfaage avec le rseau

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

2.5 Les grandes approches de gestion de rseau

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

Rseau Physique Support

API : Application Programming Interface, interface de programmation

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

Figure 2 : TMN, architecture organisationnelle [Agoulmine et al., 2003]

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

3.1 La gestion de la configuration

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

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 Rseaux et gestion de la configuration avec NETCONF

Reprsentation des donnes standardise

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

Figure 3 : couches protocolaires de NETCONF [Enns et al., 2011]

TX Gestion de Rseaux et gestion de la configuration avec NETCONF configuration en cours

Validate Distinct Startup

TX Gestion de Rseaux et gestion de la configuration avec NETCONF Get-config

Un exemple de rponse serait alors:

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

Exemple de messages changs

Les messages XML suivants seront alors changs : 18

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

Figure 4: couches protocolaires de NETCONF

Figure 5 : YANG et NETCONF, Andy Bierman

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

typedefip-address { type union { type ipv4-address; type ipv6-address; }

TX Gestion de Rseaux et gestion de la configuration avec NETCONF

3.4 Les implmentations indpendantes des constructeurs

Benot de Mianville Adresse www.mgsoft.si

www.appinf.c om www.nocvue. com/ goahead.com

Sur demande Sur demande

SNMP Research Tail-f Systems Centered Logic

Sur demande Sur demande Sur demande

www.snmp.co m/ www.tailf.com centeredlogic. com

WebNMS Framework (client) Ncclient (client) Netopeer (client/serveur) YencaP (client/server)

www.webnms .com schmizz.net/n cclient/ code.google.c om/p/netope er/ ensuite.source forge.net/

Open Source Open Source

Open Source Open Source

Librairie python Linux

Tableau 3 : Les diffrents clients NETCONF