netconf: protocole de configuration réseau ( né dans les années 2000 alors que les opérateurs réseaux sont confrontés à la multiplication des équipements et services à superviser).

Problématique:

• 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' é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.

Quelques besoins ( confère RFC3535 et RFC3139):

• 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 à affecter à tout équipement).
• Communication bidirectionnelle pour pouvoir retourner des informations au gestionnaire.
• 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 (juxtaposition de configurations).
• Sécurité.

Pour répondre à ces besoins l'IETF propose NETCONF. 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.

Il s'appuie sur des technologies existantes:

• RPC¹⁾ utilisant le formalisme XML.
• Connexion sécurisée principalement par tunnel SSH.

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.

Généralités sur l'initialisation d'une connexion.

1. 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).
2. Le serveur répond et envoie également ses capacités/fonctionnalités et l'identifiant de session (Hello serveur).
3. 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, 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é.

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 le langage YANG (RFC 6020). C'est YANG qui décrit et hiérarchise les différents éléments que NETCONF peut manipuler.

• Dans YANG tout est définit par des modules.
• On peut inclure d'autres modules/définitions via la déclaration “import”.
• Contient des types prédéfinis simples: entiers, chaînes, booléens.
• La déclaration typedef permet de définir de nouveaux types (types composés).

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.

Définition et utilisation d'une feuille.

leaf port{
    type inet:port-number;
    default 22;
    config true;
    description "port to listen to";
}

<port>2202</port>

Définition et utilisation d'une leaf-list:

leaf-list allow-user{
    type string;
    mandatory true;
}

<allow-user>admin</allow-user>
<allow-user>root</allow-user>
<allow-user>nagios</allow-user>

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.

list server{
    key "name";
    leaf name{type string;}
    leaf ip{type inet:ip-address;}
    leaf port{type inet:port-number;}
}

<serveur>
  <name>http</name>
  <ip>192.168.0.1</ip>
  <port>8080</port>
</serveur>
<serveur>
  <name>ftp</name>
  <port>2121</port>
</serveur>

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.

container system{
  container services{
    container "ssh"{
      presence "Enables SSH"
    }
  }
}

<system>
  <services>
    </ssh>
  </services>
</system>

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.

• 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.