Différences

Ci-dessous, les différences entre deux révisions de la page.

--- netadmin:supervision:reseau-services:s4:010_introduction_netconf_yang [2020/02/28 18:55] – yoann
+++ netadmin:supervision:reseau-services:s4:010_introduction_netconf_yang [2021/02/01 21:51] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 6: / Ligne 6: @@
 Problématique:
-  * Diversité des solutions propriétaires et scripts/patchs d'assemblage difficilement maintenable à cette nouvelle échelle.
+  * Diversité des solutions propriétaires et scripts/patchs d'assemblage difficilement maintenable à ce nouveaux passage à l' échelle.
 Nécessité croissante de normalisation. IETF via la délégation IAB (Internet Architecture Board) constate l'insuffisance des technologies et protocoles de gestion qui à l'époque n'atteignaient pas un niveau jugé satisfaisant (résumé par la RFC3535).
-  * Le passage à l'echelle via snmp reste problématique avec de nombreuses MIB restées propriétaires.
+  * Le passage à l' échelle via snmp reste problématique avec de nombreuses MIB restées propriétaires.
   * snmp permet de faire essentiellement du monitoring et non de la configuration (la plupart des MIBs ne prévoient pas ce cas). Les mécanismes de configuration sont plus complexes.
-les besoins (RFC3535 et RFC3139):
+Quelques besoins ( confère RFC3535 et RFC3139):
-  * Différencier les éléments configurables et les données de monitoring
+  * Différencier les éléments configurables et les données de monitoring.
-  * Interface et langage standards pour manipuler les mêmes éléments de configuration. (ex: décrire de la même manière une adresse IP a affecter a tout équipement).
+  * Interface et langage standards pour manipuler les mêmes éléments de configuration. (ex: décrire de la même manière une adresse IP à affecter à tout équipement).
-  * Communication bidirectionnelle pour pouvoir retourner des informations au le gestionnaire.
+  * Communication bidirectionnelle pour pouvoir retourner des informations au gestionnaire.
-  * Protocole en mode texte: car les protocoles de ce type ont fait leurs preuves: facilité des échanges, de la maintenance et développement collaboratif.
+  * Protocole en mode texte car les protocoles de ce type ont fait leurs preuves notamment pour la facilité des échanges, la maintenance et développement collaboratif.
   * Paralléliser les opérations.
-  * Faciliter la manipulation des configurations: opérations de dump, restauration, déploiement de configurations complètes sur des configuration en cours d’exécution et facilité de bascule.
+  * Faciliter la manipulation des configurations: opérations de dump, restauration, déploiement de configurations complètes sur des configuration en cours d’exécution et facilité de bascule (juxtaposition de configurations).
-  * Sécurité
+  * Sécurité.
-Pour répondre a ces besoins l'IETF propose NETCONF.
+Pour répondre à ces besoins l'IETF propose NETCONF.
-NETCONF: protocole de gestion ou supervision des réseaux qui pernet de manipuler les différentes données de configuration sur un équipement réseau physique ou virtuel. il est décrit dans de nombreuses RFCs dont la RFC 6241.
+NETCONF: protocole de gestion ou supervision des réseaux qui permet de manipuler les différentes données de configuration sur un équipement réseau physique ou virtuel. Il est décrit dans de nombreuses RFC dont la RFC 6241.
-s'appuie sur des technologies existantes:
+Il s'appuie sur des technologies existantes:
-  * **RPC**((**R**emote **P**rocédure **C**all)) utilisant le formalisme XML
+  * **RPC**((**R**emote **P**rocédure **C**all)) utilisant le formalisme XML.
-  * Connexion sécurisée principalement par tunnel SSH
+  * Connexion sécurisée principalement par tunnel SSH.
-La session NETCONF commence avec l'échange de messages "Hello" permettant de définir les capacités de l'appareil supervisé.
+La session NETCONF commence avec l'échange de messages "Hello" permettant de définir les fonctionnalités disponibles à la fois côté client et serveur.
 Un identifiant de session est alors fournit par le serveur.
-Protocole NETCONF
+===== Vue générale du protocole NETCONF =====
+Généralités sur l'initialisation d'une connexion.
 <note>
-C'est l'appareil à configurer qui exécute le serveur NETCONF
+C'est l'appareil configurable qui exécute le serveur NETCONF
 </note>
   - Le client contacte le serveur pour pousser les paramètres de configuration. Il initie donc la connexion en annonçant ses  capacités (Hello client).
   - Le serveur répond et envoie également ses capacités/fonctionnalités et l'identifiant de session (Hello serveur).
-  - Le client envoie des requêtes RPC, de façon à exécuter des traitements sur le serveur distant.
+  - Le client transmet des requêtes RPC, de façon à exécuter des traitements sur le serveur distant.
-Les messages Hello contiennent entre autre l'espace de nommage soit la définition des éléments de configuration utilisables.
+Les messages Hello contiennent entre autre l'espace de nommage, c'est à dire la définition des éléments de configuration utilisables/manipulable. L'espace de nommage utilise des définitions de base et peut être complété.
 ===== Modèle de données =====
-Pour réaliser des opérations NETCONF à besoin de s'appuyer sur un langage capable de définir différents types de données. NETCONF permet de les manipuler des données mais le les définit pas.
+Pour réaliser des opérations NETCONF à besoin de s'appuyer sur un langage capable de définir différents types de données. NETCONF permet de manipuler des données mais le les définit pas.
-Le modèle de données est définit par YANG (RFC 6020). C'est YANG qui décrit les différents éléments que NETCONF peut manipuler.
+Le modèle de données est définit par le langage YANG (RFC 6020). C'est YANG qui décrit et hiérarchise les différents éléments que NETCONF peut manipuler.
+==== Les types ====
   * Dans YANG tout est définit par des modules.
-  * On peut inclure des modules (import)
+  * On peut inclure d'autres modules/définitions via la déclaration "import".
-  * types prédéfinis simples: entiers, chaines
+  * Contient des types prédéfinis simples: entiers, chaînes, booléens.
-  * typedef pour définir de nouveaux types.
+  * La déclaration typedef permet de définir de nouveaux types (types composés).
+==== La hiérarchisation ====
+YANG permet de hiérarchiser les données.
+Pour hiérarchiser les données plusieurs éléments (Nodes) sont disponibles:
+Les feuilles (leaf):
+  * leaf: Une feuille représente une variable unique.
+  * leaf-list: ensemble de variables du même type (tableau).
+Pour assembler et hiérarchiser les feuilles YANG propose les conteneurs et les listes:
+  * container: ensemble de nœuds chacun étant présent une seule fois.
+  * list: ensemble d'éléments de types différents mais de même structure.
+Quelques mot clés largement utilisés:
+  * config: L'élément définit est une donnée de configuration ou une variable d'état si config est a false.
+  * mandatory: spécifie si un nœud doit être présent.
+==== Quelques exemples ====
+Définition et utilisation d'une feuille.
+^ Définition dans YANG      ^ Utilisation par NETCONF       |
+| <code>
+leaf port{
+    type inet:port-number;
+    default 22;
+    config true;
+    description "port to listen to";
+}
+</code>                     | <code xml>
+<port>2202</port>
+</code>  |
+Définition et utilisation d'une leaf-list:
+^ Définition dans YANG      ^ Utilisation par NETCONF       |
+| <code>
+leaf-list allow-user{
+    type string;
+    mandatory true;
+}
+</code>                     | <code xml>
+<allow-user>admin</allow-user>
+<allow-user>root</allow-user>
+<allow-user>nagios</allow-user>
+</code>  |
+Utilisation d'un node de type list. On notera que les feuilles ip et port ne sont pas obligatoires et peuvent ne pas être spécifiées dans le fichier de configuration NETCONF.
+^ Définition dans YANG      ^ Utilisation par NETCONF       |
+| <code>
+list server{
+    key "name";
+    leaf name{type string;}
+    leaf ip{type inet:ip-address;}
+    leaf port{type inet:port-number;}
+}
+</code>                     | <code xml>
+<serveur>
+  <name>http</name>
+  <ip>192.168.0.1</ip>
+  <port>8080</port>
+</serveur>
+<serveur>
+  <name>ftp</name>
+  <port>2121</port>
+</serveur>
+</code>  |
+Dernier exemple, définition d'un container system. On notera ici l'utilisation du mot clé **presence** dans la définition du container ssh qui apporte une sémantique au container. Sa présence dans le fichier de configuration NETCONF activera le service SSH.
+^ Définition dans YANG      ^ Utilisation par NETCONF       |
+| <code>
+container system{
+  container services{
+    container "ssh"{
+      presence "Enables SSH"
+    }
+  }
+}
+</code>                     | <code xml>
+<system>
+  <services>
+    </ssh>
+  </services>
+</system>
+</code>  |
+Pour résumer C'est le langage YANG qui modélise les différentes données d'état ou de configuration qui seront ensuite utilisées par le protocole netconf.
+===== Quizz =====
+  * Par défaut la sécurité des échanges du protocole NETCONF est garantie par SSH.
+  * NETCONF définie les primitives utilisées pour configurer les appareils réseau.
+  * YANG définit le modèle des données exploitables par le protocole NETCONF.
+  * Les "capabilities" du serveur correspondent aux fonctionnalités de configurations offertes par le serveur.
+  * La structure arborescente des données se définie avec YANG via les nodes de type container et list.
+  * Le mot clé "presence" est une valeur de configuration non obligatoire mais ayant une sémantique lorsque elle est spécifiée. A ne pas confondre avec mandatory.
+  * Il est possible de définir ces propres types de données de configuration.

wikinotes

Outils pour utilisateurs

Outils du site

Différences

Outils de la page