inlinetoc

Openvswitch est un commutateur virtuel destiné aux environnements virtualisés pour la commutation de trafic entre ordinateurs virtuels.

Voici les composants critiques de Openvswitch.

• ovs-vswitchd: un démon qui implémente le commutateur, ainsi qu'un module de noyau Linux associé pour la commutation basée sur le flux. Nous pouvons parler à ovs-switchd en utilisant le protocole Openflow.
• ovsdb-server: un serveur de base de données léger qui ovs-vswitchd interroge pour obtenir sa configuration. Les clients externes peuvent parler à ovsdb-server via le protocole de gestion ovsdb.
• Le cluster de contrôle et de gestion: contient des outils client permettant de dialoguer avec ovsdb-server et ovs-vswitchd.

OpenFLow est un protocole de communication qui permet d’accéder directement au plan de données des périphériques réseau tels que les routeurs et les switch, à la fois physiques et virtuels à travers le réseau. Autrement dit, il permet de contrôler le comportement du plan de données (la partie des commutateurs et routeurs qui assure effectivement le mouvement des données) d’une façon centralisée, dynamique et programmable.

L’interface de gestion OVSDB est utilisée pour effectuer la gestion des opérations de configuration sur l'instance OVS.

Voici des exemples d'opérations prises en charge par OVSDB:

• Création, modification et suppression de chemins de données OpenFlow (ponts), dont il peut y en avoir beaucoup dans une seule instance OVS;
• Configuration de l'ensemble des contrôleurs auxquels un OpenFlow datapath devrait se connecter;
• Configuration de l'ensemble des gestionnaires sur lesquels le serveur OVSDB devrait se connecter;
• Création, modification et suppression de ports sur un OpenFlow datapath;
• Création, modification et suppression des interfaces de tunnel sur un OpenFlow datapath;
• Création, modification et suppression de files d'attente;
• Configuration des règles de qualité de service (QoS) et attachement de ces politiques aux files d'attente;
• Collection de statistiques.

OVSDB n’effectue pas d’opérations par flux, laissant celles-ci à OpenFlow.

OVS diffère des offres commerciales de VMware et de Cisco en ce qu’il n’existe pas de contrôleur ou de gestionnaire SDN natif, tel que le VSM (Virtual Supervisor Manager) dans le Cisco 1000V ou le vCenter dans le cas du commutateur distribué de VMware. Open vSwitch est conçu pour être contrôlé et géré par des contrôleurs et des gestionnaires tiers.

Bien que cela ne fasse pas partie des composants Open vSwitch, il est important de savoir à quoi il sert, car tous les flux conservés dans ovs-vswitchd seront perdus en cas de redémarrage ou de crash. Donc, pour garder les flux importants persistants, un contrôleur OpenFlow est généralement utilisé.

Il est courant de le trouver installé sur un serveur distant (c'est pourquoi il est placé dans un “espace” différent dans le dessin) bien qu'il puisse être installé sur le même serveur.

Le tableau suivant répertorie les versions d'OpenFlow prises en charge par chaque version d'Open vSwitch:

1. -Non supporté.
2. oui Pris en charge et activé par défaut
3. (*) Pris en charge, mais fonctionnalités manquantes et doit être activé par l'utilisateur.
4. (%) Mise en œuvre expérimentale et non sécurisée.

Dans tous les cas, l'utilisateur peut remplacer la valeur par défaut:

Pour activer OpenFlow 1.0, 1.1, 1.2 et 1.3 sur le pont br0:

ovs-vsctl set bridge br0 \
      protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13

Pour activer OpenFlow 1.0, 1.1, 1.2, 1.3, 1.4 et 1.5 sur le pont br0:

ovs-vsctl set bridge br0 \
      protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13,OpenFlow14,OpenFlow15

Pour activer uniquement OpenFlow 1.0 sur le pont br0:

ovs-vsctl set bridge br0 protocols=OpenFlow10

Toutes les versions actuelles de ovs-ofctl activent uniquement OpenFlow 1.0 par défaut. Utiliser l'option -O pour activer la prise en charge des versions ultérieures d'OpenFlow dans ovs-ofctl. Par exemple:

ovs-ofctl -O OpenFlow13 dump-flows br0

Depuis CentOS 6 un module openvswitch est déjà fournit dans le noyau (kernel) il n'y a donc pas besoin de construire et installer openvswitch-kmod, pour s'en assurer taper la commande :

modinfo openvswitch

Qui doit retourner la version du module embarqué

filename:       /lib/modules/3.10.0-327.28.3.el7.x86_64/kernel/net/openvswitch/openvswitch.ko
license:        GPL
description:    Open vSwitch switching datapath
rhelversion:    7.2
srcversion:     F4BC74559C24C3F264B0F4B
depends:        libcrc32c
intree:         Y
vermagic:       3.10.0-327.28.3.el7.x86_64 SMP mod_unload modversions
signer:         CentOS Linux kernel signing key
sig_key:        15:64:6F:1E:11:B7:3F:8C:2A:ED:8A:E2:91:65:5D:52:58:05:6E:E9
sig_hashalgo:   sha256

Il est donc possible d'installer openvswitch depuis les dépôts

yum install openvswitch

Si tel n'était pas le cas il faut construire du Module openvswitch du noyau

# Installer les outils de coonfection d'un rpm

yum groupinstall "Development Tools" -y
yum install rpmdevtools openssl-devel kernel-devel gcc redhat-rpm-config -y

# Créer l'utilisateur ovswitch

adduser ovswitch

# Télécharger openvswitch 

su ovswitch -c "wget http://openvswitch.org/releases/openvswitch-2.3.0.tar.gz -O /home/ovswitch/openvswitch-2.3.0.tar.gz"
su ovswitch -c "cd ~ && tar xvfz openvswitch-2.3.0.tar.gz"

# Préparer l'environnement rpmbuild 

su ovswitch -c "mkdir -p /home/ovswitch/rpmbuild/SOURCES"
su ovswitch -c "cp /home/ovswitch/openvswitch-2.3.0.tar.gz /home/ovswitch/rpmbuild/SOURCES/"
su ovswitch -c "cp /home/ovswitch/openvswitch-2.3.0/rhel/openvswitch-kmod.files /home/ovswitch/rpmbuild/SOURCES/"

# Préparer le build sans le module kmod 

su ovswitch -c "sed 's/openvswitch-kmod, //g' /home/ovswitch/openvswitch-2.3.0/rhel/openvswitch.spec > /home/ovswitch/openvswitch-2.3.0/rhel/openvswitch_no_kmod.spec"

# Construire le rpm 

su ovswitch -c "rpmbuild -bb /home/ovswitch/openvswitch-2.3.0/rhel/openvswitch_no_kmod.spec"

# Installer le module 

yum localinstall -y /home/ovswitch/rpmbuild/RPMS/x86_64/openvswitch-2.3.0-1.x86_64.rpm

# Activer le module du noyau

modprobe openvswitch

Chaque installation standard de libvirt fournit une connectivité NAT aux machines virtuelles prêtes à l'emploi. C'est ce qu'on appelle le “réseau virtuel par défaut”. Vérifier qu'il est disponible avant d'activer openvswitch avec

virsh net-list --all
Name                 State      Autostart 
-----------------------------------------
default              active     yes

S'il est manquant, recharger la configuration XML et activer le réseau virtuel

virsh net-define /usr/share/libvirt/networks/default.xml
virsh net-autostart default
virsh net-start default

/etc/init.d/openvswitch start

Créer un bridge dans /etc/sysconfig/network-scripts (par ex. ovs-br0)

vi/etc/sysconfig/network-scripts/ifcfg-ovs-br0

avec le contenu suivant (adapter IPADDR NETMASK et GATEWAY avec les valeurs voulues)

DEVICE=ovs-br0
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
IPADDR=192.168.122.4
NETMASK=255.255.255.0
HOTPLUG=no

Rattacher les ports virtuels au bridge, par exemple pour utilise libvirt/kvm ajouter le port virbr0 créé par kvm (net=192.168.122.0/24)

ovs-vsctl add-port ovs-br0 virbr0

OpenDaylight est un projet open source collaboratif hébergé par The Linux Foundation. L'objectif du projet est de promouvoir la virtualisation des fonctions de réseau et des fonctions réseau définies par logiciel (Software-defined networking). Le logiciel est écrit en langage de programmation Java.

Installer la dernière version disponible sur https://nexus.opendaylight.org/content/repositories/

par exemple pour centos7

rpm -ivh https://nexus.opendaylight.org/content/repositories/opendaylight-epel-7-x86_64-devel/org/opendaylight/integration-packaging/opendaylight/0.1.20170718snap120.el7.noarch/opendaylight-0.1.20170718snap120.el7.noarch.rpm

Ryu Controller est un contrôleur de réseau (SDN) ouvert conçu pour accroître l'agilité du réseau en facilitant la gestion et l'adaptation de la gestion du trafic. En général, le contrôleur SDN est le cerveau de l’environnement SDN. Il transmet les informations aux commutateurs et aux routeurs avec les API southbound, ainsi qu’aux applications et à la logique métier avec les API northbound.

L'installation avec la commande pip est l’option la plus simple:

pip install ryu

Ou installer à partir du code source:

git clone git://github.com/osrg/ryu.git
cd ryu; Python ./setup.py install

FlowManager est une application de contrôleur RYU qui permet à l'utilisateur de contrôler manuellement les tables de flux dans un réseau OpenFlow. L'utilisateur peut créer, modifier ou supprimer des flux directement à partir de l'application. L'utilisateur peut également surveiller les commutateurs OpenFlow et afficher des statistiques. FlowManager est idéal pour apprendre OpenFlow dans un environnement de laboratoire ou en conjonction avec d'autres applications pour modifier le comportement des flux de réseau dans un environnement de production.

Principales Caractéristiques

• Ajouter/modifier/supprimer des entrées de flux dans les tables de flux.
• Ajouter/ modifier/supprimer des tables de groupe et des compteurs.
• Sauvegarde/restauration des tables de commutation vers/depuis le lecteur local.
• Afficher les tables de flux, les tables de groupes et les compteurs.
• Voir les statistiques du commutateur.
• Voir la topologie du réseau.

  Téécharger FlowManager en procédant comme suit:

git clone https://github.com/martimy/flowmanager 

FowManager peut être utilisé seul :

ryu-manager ~/flowmanager/flowmanager.py 

ou avec une autre application RYU:

ryu-manager ~/flowmanager/flowmanager.py ryu.app.simple_switch_13 

et pour afficher la topologie:

ryu-manager --observe-links ~/flowmanager/flowmanager.py ryu.app.simple_switch_13 

Utiliser un navigateur pour accéder au manger http://localhost:8080/home/index.html

Un Switch Open Flow contient une ou plusieurs tables de Flux et une Table de Groupe, qui traitent les paquets entrants et les commutent vers la destination, il s’appuie sur un Canal sécurisé pour communiquer avec le contrôleur externe.

Le contrôleur gère le Switch en utilisant le protocole OpenFLow, qui lui permet d’ajouter, d’effacer et de mettre à jour les entrées dans la ou les Table de Flux.

La correspondance des paquets commence par la première entrée et peut continuer ainsi, dans le cas où plusieurs Tables de Flux existent. Les entrées font la correspondance selon la priorité, si une correspondance est trouvée les instructions associées à cette entrée sont exécutées.

S’il n’y a pas de correspondance dans la table de Flux :

• Le paquet est commuté vers le Contrôleur via le canal sécurisé OpenFLow.
• Le paquet sera Abandonné.
• Le paquet va continuer vers la table de Flux qui suit (Traitement Pipeline)

Les instructions associées à chaque entrée décrivent l’acheminement du paquet, la modification, et les traitements dans le pipeline.

Les instructions permettent :

• lors d’un traitement par pipeline d'envoyer le paquet vers la prochaine Table de Flux et la communication d’information entre elles sous forme de Meta-data.
• Le traitement s’arrête quand l’ensemble des instructions associées à une entrée ne spécifie plus de table, généralement arrivé à ce stade le paquet est modifié et acheminer vers la destination.

Cette section décrit les composants de tables OpenFLow à savoir, les Table de Flux, les Tables de groupes, ainsi que les mécanismes de correspondance.

Chaque Table de Flux dans un Switch contient un ensemble d’entrées.

Les principaux éléments d’une entrée dans une table de Flux :

• Le champ de correspondance ‘Match Fields’: c’est la partie sur laquelle le contrôleur se base pour faire correspondre les paquets, cela consiste à vérifier le port d’entrée ou l’entête du paquet afin d’y appliquer une action X.
• Compteurs: Il est possible de disposer d'un certain nombre de statistiques. Dont on sert pour la gestion des entrées dans les tables de flux.
• Instructions: c’est une opération pouvant contenir en elle-même un ensemble d’actions à appliquer sur le paquet.

A la réception d’un paquet, le Switch OpenFLow commence par faire une recherche dans la première table de Flux, et, en se basant sur le traitement par pipeline, il peut aussi effectuer une recherche dans les autres tables de Flux.

Chaque Entrée dans la table de flux contient un ensemble d’instructions qui seront exécutées quand un paquet correspond à cette entrée. Parmi les instructions supportées on trouve :

• Apply-Action: appliquer l’action spécifique immédiatement, sans aucun changement du Action set. Cette instruction peut être utilisée pour modi-fier le paquet entre deux tables de flux ou pour exécuter plusieurs ac-tions du même type. Les actions sont spécifiées comme un action set.
• Clear-Actions: Effacer toutes les actions dans l’action set immédiate-ment.
• Write-Actions: Fusionner les actions dans l’action set actuel, si une des actions du même type existe déjà dans l’action set actuel, l’écraser, au-trement l’ajouter.
• Write Metadata: Ecrire la valeur dans le champ Meta-data.
• Goto-Table: Indique la prochaine table de Flux dans le traitement pipe-line.

Un ensemble d’actions associées qui s’accumulent au fur et à mesure que le paquet avance dans la chaine de traitement Pipeline est traité par chaque table de flux. Quand une instruction ne contient pas un Goto-Table, le traitement pipeline s’arrête et les actions dans le set actions sont exécutées.

Ce set est vide par défaut. Une entrée dans la table de Flux peut modifier l’action set en utilisant l’instruction Write-Action ou Clear-Action associée à un match. Quand plusieurs actions du même type sont requises, l’instruction Apply-Actions peut être utilisée.

La table de groupe contient des entrées, et chaque entrée une liste d’actions appelée Conteneur D’actions les actions d’un ou plusieurs Conteneurs d’actions sont appliquées sur les paquets envoyés au groupe.

Chaque entrée dans la table de groupe contient :

• L’identifiant de groupe: c’est un entier de 32 bits.
• Le Type de groupe: sert à déterminer le type du groupe ‘All – Select – Indirect – Fast Failover ’
• Les compteurs: mis à jour quand un paquet est traité par un groupe.
• Conteneur d’action: un ensemble d’actions et de paramètres associés, qui sont définies pour les groupes.

1. Chaque Switch contient plusieurs tables de Flux, et chaque table contient plusieurs entrées. Le traitement pipeline OpenFLow décrit et définit comment les paquets interagissent avec les Tables de Flux
2. Les tables de Flux d’un Switch OpenFLow sont séquentiellement énumérées, commençant par 0.
3. Le traitement par Pipeline commence toujours avec la première table de Flux : on fait correspondre le paquet selon les entrées de la table de Flux 0. D’autres tables de Flux peuvent être utilisées selon le résultat obtenu lors de la première correspondance faite dans la première table de Flux.
4. Si le paquet correspond à une entrée dans la table de Flux, l’instruction en question sera exécutée. Les instructions dans les tables de Flux peuvent explicitement diriger le paquet vers une autre table de Flux utilisant l’instruction Goto.
5. Une entrée x dans une Table de Flux n peut enchainer le traitement du paquet en l’envoyant vers une autre table de Flux si seulement cette dernière dispose d’un numéro n supérieur à celui de la table où l’entrée x se trouve. Ainsi la dernière table du pipeline ne peut inclure l’instruction Goto. Si l’entrée dans la table de Flux ne redirige pas le paquet à une autre table de Flux, le traitement pipeline s’arrête. Arrivé à ce stade le paquet est traité avec l’action associée.