Technologies et exemples d’architectures

SDN et VXLAN

Emmanuel Pinsard

08 Avril 2019
PUB !

• La liste des stages au CEA

http://www.cea.fr/emploi/Pages/stages/offres-stage.aspx
• !TODO !

E.Pinsard Infrastructure D at ac enters 2 / 49

Bibliographie

Besta, M. and Hoefler, T. (2014). Slim fly : A cost effective

low-diameter network topology. In Proceedings of the International
Conference for High Performance Computing, Networking, Storage
and Analysis, SC ’14, pages 348–359, Piscataway, NJ, USA. IEEE
Press.
Dally, W. and Towles, B. (2003). Principles and Practices of
Interconnection Networks. Morgan Kaufmann Publishers Inc., San
Francisco, CA, USA.

E.Pinsard Infrastructure D at ac enters 3 / 49

Plan du cours

SDN

VXLan

E.Pinsard Infrastructure D at ac enters 4 / 49

Plan du cours

SDN

VXLan

E.Pinsard Infrastructure D at ac enters 5 / 49

Qu’est-ce que le Software-Defined Networking ?

• Rendre les réseaux « intelligents »

• Les rendre plus flexibles
• Les rendre programmables
• Mieux répondre aux problématiques de qualité de service des
réseaux d’entreprise, notamment en environnement datacenters
• Permettre d’avoir une meilleure vision de l’ensemble du réseau
• Ajouter des fonctionnalités aux équipements
• Avoir des outils interopérables quelque soient les modèles
d’équipements employés

E.Pinsard Infrastructure D at ac enters 6 / 49

Pourquoi le SDN ?

• Problématique de coût : débits, é́quipements, infrastructures, etc.

• L’agilité des réseaux : on veut pouvoir déployer rapidement des
configurations spécifiques, on veut pouvoir le faire de façon
automatique
• Les réseaux actuels ne sont pas assez proches des services qu’ils
transportent
• Configurations statiques et parfois peu adaptables
• Politiques statiques
• Manque d’information contextuelle
• Pas de connaissance précise du client et de son besoin

E.Pinsard Infrastructure D at ac enters 7 / 49

Objectifs du SDN

• Abaisser les coûts : virtualisation des réseaux, automatisation et

simplification
• Personnalisation des réseaux en fonction du besoin
• Réduction du temps de déploiement
• Déployer un réseau avec une qualité de service adaptée aux
services transportes

E.Pinsard Infrastructure D at ac enters 8 / 49

Objectifs du SDN

• Séparation des plans

• Le plan de données comprend des commutateurs (ou des
routeurs) pour transférer les paquets.
• Le plan de contrôle déporté dans un serveur programme les tables
de commutation ou de routage
• Équipements simples
• Pas d’algorithme de contrôle
• Abstraction du réseau
• Virtualisation des fonctions réseau (NFV)
• Tout é́quipement compatible SDN peut ê̂tre utilise pour assurer
l’ensemble des fonctions réseau
• Ouverture
• Projet en open source
• Standards ouverts pour assurer une interopérabilité
• Modèle implémenté par un grand nombre de constructeurs

E.Pinsard Infrastructure D at ac enters 9 / 49

Objectifs du SDN

• Changements importants
• Mise à jour des é́quipements
• Remplacement des é́quipements pour supporter le protocole
OpenFlow
• De nouvelles compétences à développer
• Le contrôleur SDN devient un é́lément critique et central pour la
disponibilité et la sécurité des réseaux
• Sécurité du contrôleur
• Disponibilité du contrôleur

E.Pinsard Infrastructure D at ac enters 10 / 49

Comparaison des modes de switch 1/2

• Actuellement, les commutateurs utilisent des règles simples pour

prendre des décisions
• Adresse MAC
• VLAN id
• Mapping des VLANs
• Toutes ces décisions sont statiques et déterminées par la
configuration du commutateur
• Une seule base de décision dynamique : la table d’adresses MAC

E.Pinsard Infrastructure D at ac enters 11 / 49

Switch legacy

MAC-A VLAN A Port 1 MAC-A VLAN A Port 5

MAC-B VLAN A Port 2 MAC-B VLAN A Port 3

Port 1 Port 5
Machine A Machine B
Port 2 Port 3

switch switch

Fig.: Switch Legacy

E.Pinsard Infrastructure D at ac enters 12 / 49

Comparaison des modes de switch 2/2

• On aimerait pouvoir prendre des décisions sur différents critères

suivant la situation rencontrée.
• Adresses MAC/IP source/destination
• VLAN id
• Protocole
• Marqueur de qualité de service (DSCP)

E.Pinsard Infrastructure D at ac enters 13 / 49

Switch OpenFlow

OpenFlow Controller

OpenFlow Protocol

OpenFlow channel Group Table

Flow table Flow table

Network device

Fig.: switch OpenFlow

E.Pinsard Infrastructure D at ac enters 14 / 49

Infrastructure SDN

• On définit 3 couches (layers)

• Application Layer
• Communique avec le contrôleur depuis l’interface SDN, cette
couche permet d’envoyer des requetés au contrôleur SDN
• On y retrouve un Orchestrateur SDN ou des applications
spécifiquement développées
• Control Layer
• Couche récupérant les instructions pour les communiquer aux
périphériques SDN
• Couche contenant le contrôleur SDN
• Infrastructure Layer
• Transmet les instructions du contrôleur
• Couche contenant les périphériques physiques (ou virtuels) SDN

E.Pinsard Infrastructure D at ac enters 15 / 49

Infrastructure SDN
Application Layer

SDN Orchestrator Application

Control Layer

SDN controller

Infrastructure Layer

Network device Network device Network device

E.Pinsard Infrastructure D at ac enters 16 / 49

L’architecture du contrôleur SDN

• Composé de 4 interfaces
• Nord : interface d’administration, elle permet d’interagir
(configuration/interrogation) avec le contrôleur au travers d’une
API (généralement de type REST)
• Sud : Interface de communication avec les é́quipements OpenFlow
• Est/Ouest : Interface de communication entre contrôleurs
La plupart des contrôleurs sont développés en JAVA

E.Pinsard Infrastructure D at ac enters 17 / 49

Architecture contrôleur SDN

Application

North

SDN Controller East/West SDN Controller

South

Device Device Device

Fig.: Architecture contrôleur SDN

E.Pinsard 20 / 49
L’interface NORD

• Interface du contrôleur permettant de l’administrer et de

l’interroger
• Dans la plupart des cas, accessible via une API REST
• Protocole HTTP (PUT, GET, DELETE)
• Envoie des configurations par JSON/XML
• Interrogation par langage s c r i p t a b l e : python, java, bash
• Possibilité de configurer des groupes/team de contrôleur pour la
redondance/disponibilité des contrôleurs
• On envoie des instructions génériques qui seront ensuite
converties par l’é́quipement OpenFlow final.

E.Pinsard Infrastructure D at ac enters 19 / 49

L’interface SUD

• Interface du contrôleur avec le plan de données : discussion avec

les é́quipements
• Protocoles supportes (liste non exhaustive)
• OpenFlow
• SNMP
• NetConf
• SSH
• Ansible

E.Pinsard Infrastructure D at ac enters 20 / 49

Les interfaces EST/OUEST

• Interfaces de communication entre les contrôleurs SDN

• Plusieurs modes sont prévus/implémentés suivant les é́diteurs :
• Stand Alone : chaque contrôleur est indépendant des autres
• Maitre/Esclave : une architecture classique maitre/esclave
• Les équipements interrogent en priorité le maitre et
interrogent l’esclave lorsque le maitre ne répond plus (un
timeout à définir). L’esclave réplique sa configuration sur celle
du maitre.
• Teaming : Un ensemble de contrôleurs (généralement 3) est vu
comme é́tant un seul contrôleur, avec une IP virtuelle pour les 3
(mais chaque contrôleur à sa propre adresse IP pour ê̂tre
contacte/configuré indépendamment). Le switch interroge l’IP
virtuelle de manière transparente.

E.Pinsard Infrastructure D at ac enters 21 / 49

OpenFlow

• Protocole défini par l’Open Network Foundation

• Première spécification : 31 décembre 2009
• Protocole d’abstraction de configuration des é́quipements réseaux
• Les actions OpenFlow sont stockées dans des tables de flux
• Un é́quipement réseau peut ê̂tre à la fois OpenFlow et Legacy
• De tels é́quipements peuvent avoir des ports/VLANs configurés
en OpenFlow et d’autres en Legacy

E.Pinsard Infrastructure D at ac enters 22 / 49

OpenFlow : configuration des équipements

• Le switch doit ê̂tre compatible OpenFlow

• Il peut avoir 3 modes :
• Legacy : pas de configuration OpenFlow
• OpenFlow : tous les ports sont configurés en OpenFlow
• Hybrid : un mélange des deux
• Il est nécessaire de déclarer le contrôleur SDN dans chaque switch
• C’est donc le switch qui initie la connexion vers le contrôleur
SDN
• Soit il récupère des tables de flux p e r s i s t e n t e s (mais avec une
limite dans le temps)
• Soit le switch va interroger le contrôleur SDN à chaque fois qu’il
n’a pas d’action associée à un match de flux
• En cas de perte totale des contrôleurs, il est nécessaire d’avoir
une stratégie : soit le switch repasse en mode legacy, soit il
coupe tout.

E.Pinsard Infrastructure D at ac enters 23 / 49

OpenFLow : les tables de flux

• Les actions que doit réaliser le switch sont associées à un flux.

• Chaque flux doit ê̂tre associe à 0 ou plusieurs actions définissant
le comportement du switch vis-à-vis des paquets constituant ce
flux
• Vide : si aucune règle de forward n’est explicitement déclarée,
alors le paquet est dropé
• Forward : définit le comportement du paquet : règle c ourante
décrite dans le slide suivant
• Enqueue : place le paquet dans une file d’attente, il sera ensuite
transmis par la politique de QoS
• Drop : on peut définir l’action drop
• Modify-Field : offre la possibilité de modifier les métadonnées des
paquets
• Les tables de flux possèdent un ordre d’application (une priorité)
et c’est la première qui matche qui est appliquée.

E.Pinsard Infrastructure D at ac enters 24 / 49

OpenFLow : la règle forward

• Les règles de forward (obligatoire)

• ALL : envoie le paquet sur toutes les interfaces, excluant
l’interface d’entrée
• CONTROLLER : encapsule et envoie le paquet au contrôleur
• LOCAL : envoie le paquet à la stack legacy du switch
• TABLE : Le paquet est envoyé vers une seconde table qui
définira l’action suivante
• IN PORT : envoie le paquet sur le port d’entrée
• Les règles optionnelles (suivant les versions d’OpenFlow)
• NORMAL : traite le paquet classiquement
• FLOOD : envoie le paquet sur le minimum spanning tree,
excluant l’interface d’entrée

E.Pinsard Infrastructure D at ac enters 25 / 49

Contenu d’une table

• Match field : les éléments qui vont déclencher la règle

• Instruction Set : l’action à appliquer
• Counters : compte le nombre de fois que la règle match
• Priority : définit la priorité dans le table
• Timeout : définit le timeout avant que la règle soit supprimé de
l’équipement
• Cookie : permet que la règle soit unique

E.Pinsard Infrastructure D at ac enters 26 / 49

Tables de flux sur un équipement

• Le switch récupère ces tables de flux et les applique

• La table 0 est toujours une table hardware. Parfois la table 1
aussi. Sinon les suivantes sont software
• Cela signifie que les règles appliquées en hardware sont réalisées
par des ASICs et sont donc plus efficaces (au niveau performance)
• Lorsque le paquet arrive pas l’interface d’entrée, il va passer par
la table 0.
• Si une règle matche sur les critères du paquet, alors l’action
associée est appliquée. Sinon, le paquet passe dans la table
suivante.
• On peut avoir des règles qui renvoie sur une table spécifique.

E.Pinsard Infrastructure D at ac enters 27 / 49

Tables de flux

Ingress Port
Header Packet
Metadata

Paquet In Paquet Out

Table 0 Table 1 Table n

E.Pinsard Infrastructure D at ac enters 28 / 49

Au niveau de l’équipement SDN

• Le switch SDN fonctionne donc sur la base d’un ensemble de

règles
• A chaque règle est associée une action spécifique
• Toutes ces règles et ces actions sont définies par l’intermédiaire
du contrôleur SDN
• On place généralement à la fin une règle générique permettant de
traiter les cas non spécifique

E.Pinsard Infrastructure D at ac enters 29 / 49

Sur l’équipement SDN

SDN Controller

Match rules Actions

MAC A Forward to controller

Port TCP 1234 Match rules

* Forward normal

E.Pinsard Infrastructure D at ac enters 30 / 49

Exemple de règle OpenFlow

<? xml v er sio n= ” 1 . 0 ” e n c o d i n g= ” UT F− 8” st a nd a lone= ” y e s ” ?>

< f l o w x m l n s= ” u r n : o p e n d a y l i g h t : f l o w : i n v e n t o r y ”>
< i d >1 0 1</ i d >
< i n s t r u c t i o n s>
< i n s t r u c t i o n>
< o r d e r>0</ o r d e r >
<a p p l y − a c t i o n s>
<a c t i o n>
< o r d e r>1</ o r d e r>
<o u t p u t − a c t i o n >
<o u t p u t − n o d e− c o n n e c t o r
</ o u t p u t − a c t i o n >
</ a c t i o n >
</ a p p l y − a c t i o n s>
</ i n s t r u c t i o n >
</ i n s t r u c t i o n s>
< t a b l e i d >0</ t a b l e i d >
< p r i o r i t y >1 0 0</ p r i o r i t y >
<fl o w − n a m e>P o r t 1 s u r P o r t 2</ f l o w − n a m e>
<m a t c h>
<i n − p o r t > o p e n f l o w : 1 : 1</ i n − p o r t >
</ m a t c h>
</ f l o w>

E.Pinsard Infrastructure D at ac enters 31 / 49

Quelques contrôleurs SDN
• NOX : NOX a été le premier contrôleur OpenFlow
• FlowVisor : Contrôleur OpenFlow en Java qui qui se comporte
comme un proxy transparent entre un commutateur OpenFlow et
de multiple contrôleur OpenFlow
• POX : Contrôleur OpenFlow orienté Python avec une interface
de haut niveau SDN
• Floodlight : Contrôleur OpenFlow Java-based
• OpenDaylight : OpenDaylight est un projet open source pour une
plate-forme modulable qui contient un contrôleur en interne
• O.N.O.S : Open Network Operating System est un système
d’exploitation réseau distribué en open source ce qui est
presque equivalent à un contrôleur distribué
• Open Contrail : Contrail a développé en open source un
contrôleur repris par Juniper
• LOOM, Ryu, Trema.

E.Pinsard Infrastructure D at ac enters 32 / 49

Plan du cours

SDN

VXLan

E.Pinsard Infrastructure D at ac enters 33 / 49

Qu’est-ce que le VXLAN ?

Virtual Extensible LAN

VXLAN : RFC 7348
Proposé par Cisco et VMWARE
Permet d’encapsuler du niveau 2 dans du niveau 3
”Ethernet in IP”

E.Pinsard Infrastructure D at ac enters 34 / 49

Pourquoi le VXLAN ?

• On souhaite étendre un Réseau Ethernet tout en conservant les

avantages du protocole IP (absence de problématique de boucles,
Abstraction des couches 1 & 2).
• Les VLAN sont limités à 4096 virtual lan
• Dans un datacenter, on veut pouvoir faire beaucoup plus de
VLANs
• Avec les VXLANs, on dispose de 24 bits d’adressage possible
(16 millions de possibilités)
• Ajout ensuite d’un champ UDP de 64 bits (comme on le verra
par la suite)
• On veut aussi pouvoir automatiser les éléments de configuration
des VLAN que l’on va créer

E.Pinsard Infrastructure D at ac enters 35 / 49

Fonctionnement du VXLAN

• On veut pouvoir déployer un réseau Ethernet sur un ensemble de

sous-réseaux IP
• Cette communication doit pouvoir se faire au travers de
n’importe quel réseau
• Pour cela, on a besoin d’utiliser la couche transport
• Par conséquent, la trame Ethernet est :
• Encapsulée dans un segment UDP, lui-même encapsulé dans un
paquet IP, lui-même encapsulé dans une trame Niveau 2
(Ethernet par ex)

E.Pinsard Infrastructure D at ac enters 36 / 49

Protocole VXLAN

E.Pinsard Infrastructure D at ac enters 37 / 49

Terminologie

• Virtual Tunnel End-point : VTEP

• Virtual Tunnel Identifier : VTI
• Virtual Network Identifier : VNI
• VXLAN Header

E.Pinsard Infrastructure D at ac enters 38 / 49

VTEP

• Le VTEP peut être vu comme le point d’entrée dans un VXLAN

• La tâche du VTEP est d’encaspuler/désencapsuler les VXLAN
headers.
• Le composant faisant office de VTEP peut être soit une
application virtuelle soit un équipement physique

E.Pinsard Infrastructure D at ac enters 39 / 49

VTI et VNI

• VTI : Interface IP utilisée comme adresse IP source pour

encapsuler le trafic VXLAN
• VNI : Un champs de 24 bits ajouté dans le header VXLAN
• VNI : Equivalent du VLAN ID dans le monde Ethernet

E.Pinsard Infrastructure D at ac enters 40 / 49

VTEP, VTI et VNI

VXLAN + IP/UDP HEADER

SRC IP: 1.1.1.1 Fabric IP
DEST IP: 1.1.1.2

VTEP A VNI 1000 VTEP B

VTI IP : 1.1.1.1 VTI IP : 1.1.1.2

IP : 192.168.1.100
IP : 192.168.1.101

E.Pinsard Infrastructure D at ac enters 41 / 49

Frame format

• Header Ethernet utilise la local VTEP MAC et la MAC du

routeur : 14 bytes + 4 optional 802.1q
• Encapsulation VXLAN Ip source/destination sont ceux du
local/remote VTI
• UDP Header avec
• 24-bits VNI pour atteindre 16 millions de VLAN

E.Pinsard Infrastructure D at ac enters 42 / 49

Trame VXLAN

Dest Src 802.1Q Dest IP Src IP UDP VNI Payload FCS

MAC addr MAC addr addr addr

Dest Src 802.1Q Original

MAC addr MAC addr Payload

E.Pinsard Infrastructure D at ac enters 43 / 49

Intégration dans un datacenter

• On se place dans une architecture de type Fabric IP avec

leaf/spine
• Les liens entre les leafs et les spines sont des liens L3 P2P
• Un VLAN n’est présent que sur les leafs
• ECMP permet la réprtition des flux au sein de la fabric
• Chaque switch participe au routage
• Le L3 peut se faire en OSPF, BGP, ISIS

E.Pinsard Infrastructure D at ac enters 44 / 49

Intégration dans un datacenter

• Routage Unicast au sein de la Fabric IP

• Routage dynamique Unicast avec les protocoles
habituels (OSPF et BGP notamment)

• Routage Multicast au sein de la Fabric IP

• Routage Dynamique Multicast avec IGMP et PIM -SM
• IGMP permet d’identifier les ressources à abonner à
un groupe multicast au sein d’un sous -réseau IP
• PIM-SM permet de diffuser des groupes multicast
entre plusieurs sous-réseaux IP
• PIM-SM utilise un protocole de routage (BGP, ODSPF)
pour découvrir la topologie du Réseau
• Un RP (Rendez-vous Point) est élu pour chaque
groupe Multicast par le protocole PIM -SM

E.Pinsard Infrastructure D at ac enters 45 / 49

Intégration dans un datacenter

• Retrouver les fonctions de Niveau 2 au sein d’un domaine

VXLAN
• Les messages Broadcast sont envoyés à une adresse
Multicast
• Chaque VTEP associé a un domaine VXLAN est abonné au
groupe multicast correspondant
• Les communications en broadcast (requêtes ARP par ex)
sont ainsi diffusés sur un groupe multicast

• Chaque VTEP maintient une « forwarding table »

• Permet d’identifier le VTEP à joindre pour atteindre une
adresse MAC donnée
• Table dynamique basée sur le trafic observé (à l’instar d’un
switch classique)

E.Pinsard Infrastructure D at ac enters 46 / 49

Intégration dans un datacenter

• Le routage inter-VXLAN est opéré par un ou plusieurs VTEP

• Permettre une communication entre deux domaines

VXLAN distincts

• Permettre une communication entre un domaine VXLAN

et le reste du Réseau

• Plusieurs modes d’implémentation possibles :

• Un seul VTEP fait office de passerelle pour chaque
domaine VXLAN
• VRRF : l’adresse IP de la passerelle est uniquement sur une
des deux passerelles (actif/passif)
• vARP (actif/actif VRRF) chaque VTEP partage la même
IP/MAC, le premier switch qui voit le paquet la mac de
destination correspondante à la GW le route

E.Pinsard Infrastructure D at ac enters 47 / 49

Intégration dans un datacenter

• Certains constructeurs permettent de faire du MLAG (multi

chassis link aggregation group)

• Support aussi de LACP (link aggregation control protocol)

• Auto IP management configuration

• Validation de la topologie grâce à la découverte des voisins

(LLDP)

• Déploiement de template automatique suivant le type de switch

• Intégration dans un système de supervision

E.Pinsard Infrastructure D at ac enters 48 / 49

Pour aller plus loin

• Ethernet VPN : Application du VXLAN à l’interconnexion de datacenters

distants

• Présentation RENATER aux JRES 2015 : Data Center Interconnect :

Ethernet-VPN

• https://conf-ng.jres.org/2015/document_revision_1859.html?download

E.Pinsard Infrastructure D at ac enters 49 / 49