Présentation du protocole de management du réseau NETCONF et le langage de modélisation de données YANG

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;
}
}
}
}