Le document discute du protocole NETCONF et de YANG pour la gestion des configurations réseau, soulignant la séparation entre l'état de configuration et l'état opérationnel et les mécanismes de gestion de la persistance. Il décrit des opérations clés tels que <get-config>, <edit-config>, et <commit> ainsi que l'architecture basée sur XML et les messages sécurisés. YANG est présenté comme un langage de modélisation des données pour décrire de manière hiérarchique la configuration et l'état des données.

1. NETCONF & YANG
M. ANTITENE
Laboratoire Informatique Paris VI (LIP6)

2. Motivations
 Un protocole pour le management du réseau
 Séparer entre un état de configuration et un état opérationnel
 Assurer la persistance des configurations
 Notifications, dump and restore

3. Configuration Management Protocol
 SNMP
Largement utilisé, monitoring
Complexité de la gestion des configurations
 NETCONF
XML-based encoding protocol
Mécanisme RPC
Sécurisé (SSH, SSL …)
Utilise un modèle pour structurer les données (YANG)

4. Configuration Management Protocol
Description SNMP NETCONF
Config vs operationnel state - +
Multiple Configs - +
Persistance of config state ° +
Configs change & Notification Events - +
Config dump & restore - +
Support of standard tools - +

5. NETCONF
 Protocole en couches
Couches Exemple
Content
Operations
RPC
Transport Protocol
Configuration Data
<get-config>, <edit-
config>
<rpc>, <rpc-reply>
BEEP, SSH, SSL,
console

6. NETCONF Transport
 Messages encodé en XML
 Messages crypté en SSH
Netconf over SSH, SOAP, BEEP
Authentification, intégrité et confidentialité
 Orienté connexion TCP
Plusieurs ports TCP sont définit : 830, 831, 832, 833, 6513 / tcp
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>]]>]]>

7. NETCONF RPC Model
 Les méthodes RPC sont insérées dans le corps d’un message XML
 RPC Elements:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<some-method>
<!-- method parameters here... -->
</some-method>
</rpc>
<rpr-reply>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0«
xmlns:ex="http://example.net/content/1.0" ex:user-id="fred">
<data>
<!-- contents here... -->
</data>
</rpc-reply>
<rpr-error>
<rpc-reply
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>rpc</error-type>
<error-tag>missing-attribute</error-tag>
<error-severity>error</error-severity>
<error-info>
<bad-attribute>message-id</bad-attribute>
<bad-element>rpc</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
<ok Element>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>

8. NETCONF Configuration Data Store
 Etats du système
 Définit par des Capabilities
:running, :startup, :candidate, :writable-running
Informe sur les capacités supportées par la database
Startup
Running
Candidate

9. NETCONF Configuration Data Store
 <running/>
Représente l’état active des configurations actuelles
Permet à cette base de donnée d’être directement modifée
Contient les informations sur l’état de l’équipement
 <candidate/>
Regroupe les configurations à appliquer après qu’elle soient validé par le serveur
Les changements fait sur cette BDD ne s’applique pas immédiatement
Utilisation d’opérations: <lock>, <commit> pour validation
 <Startup/>
Représente les Configs à appliquer lors du prochain redémarrage
Opération <copy-config> pour copier la dernière sauvegarde de config

10. NETCONF Base Operations
Opérations Description
get Récupérer les infos de configs à partir de la running database ou des
statistiques
get-config Récupérer les infos de configs à partir de la running database
edit-config Modifier les configurations dans la database
copy-config Copier les configurations
delete-config Supprimer les configurations
commit Commit du contenu de la config de <candidate/> ver <running/>
database
lock Bloquer l’écriture sur la database par d’autres sessions
unlock Débloquer l’écriture sur la database par d’autres sessions
validate Valider tout le contenu de la database
close-session Fermer la session active
kill-session Fermer d’autres sessions

11. NETCONF Base Operations
 Before Editing: Quelle database utilisé ?
 Options de sauvegarde
if ':candidate' capability supported:
target = <candidate/>
else if ':writable-running' capability supported:
target = <running/>
else if ':url' capability supported:
target = <url>file://path/to/file</url>
else:
target = None # Server is non-complaint
if ':startup' capability supported:
save_fn = <copy-config>
<target><startup/></target>
<source><running/></source>
</copy-config>
Else
save_fn = None # automatic NV-update

12. Candidate Configuration Example
<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>
<config>
<interface xmlns= " urn:ietf:params:xml:ns:yang:ietf-interfaces "
<name>eth1</name>
<ipv4-address>192.168.1.3</ipv4-address>
<macaddr>ab:cd:ef:gh:ij:kl</macaddr>
</config>
</edit-config>
</rpc> # server returns <ok/> status
#Commit then Unlock Candidate and Running DataBase
L’ensemble des RPC à exécuter:
1. lock <running/> database
2. lock <candidate/> database
3. edit <candidate/> database
4. commit <candidate/> database
5. unlock <candidate/> database
6. unlock <running/> database
NETCONF Base Operations

13. YANG
 Langage pour la modélisation des données
 Utilisé par NETCONF (couche content)
• Configuration data
• State data
 Description hiérarchique des données
 Interaction entre les modules et sous-modules
• Include
• import
Module 1
Submodule A
Module 2
Submodule ZSubmodule YSubmodule X
Include
import

14. Modules & Submodules
Header Information
Imports & Includes
Type definition
Config, operational data declaration
RPC, notification declaration
YANG Module Content

15. Data Modeling
 Data nodes:
 leaf, leaf-list, container, list
 Yang data types :
 Base types : Int8/16/32/64, uint8/6/32/64, string, enumeration, boolean …
 Derived types (typedef), reusable nodes (grouping) …
container system {
list user {
key name;
leaf name {
type string;
}
leaf uid {
type uint32;
}
leaf full-name {
tyoe string;
}
leaf hostname{
type string;
mandatory true;
config true;
}
user
name uid full-name
hostname
system

16. YANG module example
module acme-system {
namespace "http://acme.example.com/system";
prefix "acme";
organization "ACME Inc.";
contact "joe@acme.example.com";
description
"The module for entities implementing the ACME system.";
revision 2007-11-05 {
description "Initial revision.";
}
container system {
leaf host-name {
type string;
description "Hostname for this system";
}
leaf-list domain-search {
type string;
description "List of domain names to search";
}
list interface {
key "name";
description "List of interfaces in the system";
leaf name {
type string;
}
leaf type {
type string;
}
leaf mtu {
type int32;
}
}
}
}