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