Aller au contenu

SDN : zones, VNets, VLAN, QinQ, VXLAN, EVPN

Day 1 · DéployerNiveau 3 · MaîtriserCours + labRédigé · à valider en lab

Le SDN de Proxmox VE définit les réseaux des VM une seule fois au niveau Datacenter : une zone décrit la technique de transport (VLAN, QinQ, VXLAN, EVPN), un VNet est le réseau que l'on attache aux VM, un subnet y ajoute l'adressage. Le cœur du SDN est pleinement supporté ; IPAM/DHCP et le routage via FRR (EVPN, contrôleurs) restent en aperçu technologique. Objectif : choisir le bon type de zone et le mettre en œuvre en lab.

Notions clés

Le modèle

Objet Rôle Équivalent vSphere
Zone Domaine réseau et technologie de transport, liste des nœuds concernés Distributed vSwitch
VNet Réseau virtuel (ID de 8 caractères au plus), avec un tag VLAN ou VXLAN Distributed port group
Subnet Plage IP, passerelle, SNAT, plage DHCP —
Contrôleur Plan de contrôle BGP (EVPN) NSX
IPAM / DNS Gestion des adresses (PVE, NetBox, phpIPAM) et DNS (PowerDNS) —

La configuration est stockée dans /etc/pve/sdn/, répliquée par pmxcfs, puis traduite en configuration ifupdown2 (et FRR pour EVPN). Les modifications restent en attente jusqu'à leur application depuis Datacenter → SDN. Prérequis sur chaque nœud : la ligne source /etc/network/interfaces.d/* à la fin de /etc/network/interfaces ; paquet libpve-network-perl, installé par défaut depuis PVE 8.1.

Les types de zones

Zone Principe Prérequis Cas d'usage
Simple Bridge isolé, local à chaque nœud, sans uplink Aucun Lab, réseau NAT/routé, DHCP intégré
VLAN Tag 802.1Q sur un bridge existant (vmbr0) Bridge présent sur chaque nœud, trunk côté switch Cas standard en entreprise
QinQ Double tag : VLAN de service + VLAN du VNet Bridge VLAN-aware, switchs QinQ ; MTU réduite de 4 octets Hébergement multi-clients
VXLAN Encapsulation UDP (port 4789) entre nœuds Liste des pairs ou fabric SDN ; MTU réduite de 50 octets Réseau de niveau 2 sur un réseau routé, multi-sites
EVPN VXLAN + BGP EVPN, routage anycast entre VNets Contrôleur EVPN, paquet frr-pythontools, ASN privé Grands environnements, multi-tenant (aperçu technologique)

PVE 9 ajoute les fabrics (underlay routé, OpenFabric ou OSPF ; PVE 9.2 ajoute WireGuard et BGP), qui servent notamment de transport aux zones VXLAN et EVPN.

flowchart TB
    Z[Zone zvlan<br/>type VLAN, bridge vmbr0] --> V30[VNet vnet30<br/>tag 30]
    Z --> V40[VNet vnet40<br/>tag 40]
    V30 --> S30[Subnet 10.30.0.0/24<br/>gw 10.30.0.1]
    V30 --> VM101[VM 101 net0 bridge=vnet30]
    V40 --> VM102[VM 102 net0 bridge=vnet40]

SDN ou tags VLAN classiques ?

Critère Tag sur la carte de VM VNet SDN de zone VLAN
Définition Sur chaque VM Une fois pour le Datacenter
Droits Accès au bridge entier Permission par VNet (SDN.Use)
Nom lisible Non Oui (vnet30, alias)
Risque d'erreur de tag Élevé Faible

Recommandations MSP

  • Zone VLAN pour la quasi-totalité des clients : simple, supportée, compatible avec les switchs existants.
  • QinQ, VXLAN, EVPN et fabrics : conception et mise en production par le MSP uniquement.
  • Le client peut créer un VNet dans une zone VLAN existante, sur un VLAN déjà autorisé sur les trunks, en contrat N2/N3 après validation du MSP.
  • L'application SDN touche tous les nœuds : faites-la en heures ouvrées, jamais pendant une sauvegarde.

Pièges vus en support

  • Ligne source /etc/network/interfaces.d/* absente sur un nœud : le VNet n'existe pas sur ce nœud, la VM ne démarre pas après migration.
  • Modifications SDN jamais appliquées : tout semble configuré dans la GUI, rien n'est actif.
  • MTU non réduite dans les VM sur VXLAN ou QinQ : petits paquets OK, gros transferts bloqués.
  • VLAN du VNet non autorisé sur le trunk d'un des switchs : la VM est isolée sur un seul nœud.
  • Option Isolate Ports activée sans redémarrer les VM : sans effet.

Lab : zone VLAN et VNet

Cluster de test uniquement

Ce lab se fait sur un cluster de lab. Jamais sur la production.

Prérequis : cluster de test de 2 ou 3 nœuds, bridge vmbr0 VLAN-aware identique sur chaque nœud, VLAN 30 autorisé sur les trunks, une VM de test sur chaque nœud.

Objectifs : créer une zone VLAN, un VNet tagué 30, l'appliquer, y attacher deux VM sur deux nœuds et vérifier la communication.

Scénario

  1. Vérifiez le prérequis sur chaque nœud : tail -n 3 /etc/network/interfaces.
  2. GUI : Datacenter → SDN → Zones → Add → VLAN. ID zvlan, Bridge vmbr0, Nodes tous.
  3. Datacenter → SDN → VNets → Create. Nom vnet30, zone zvlan, Tag 30, Alias Bureautique.

  4. Datacenter → SDN → Apply. Équivalent CLI :

    pvesh create /cluster/sdn/zones --zone zvlan --type vlan --bridge vmbr0
pvesh create /cluster/sdn/vnets --vnet vnet30 --zone zvlan --tag 30
pvesh set /cluster/sdn

  5. Sur chaque VM : Hardware → carte réseau → Bridge vnet30, sans tag.

  6. Pingez une VM depuis l'autre, puis migrez-en une sur un autre nœud et recommencez.
  7. Sur un nœud : ip -d link show vnet30 et bridge vlan show.

Questions

  1. Où le VNet apparaît-il sur un nœud après application ?
  2. Pourquoi ne faut-il pas de tag sur la carte de la VM ?
  3. Que se passe-t-il si vous retirez un nœud de la zone et migrez une VM dessus ?
Corrigé
  1. Comme une interface bridge vnet30 générée dans /etc/network/interfaces.d/sdn, et dans l'arborescence GUI sous chaque nœud (ressource SDN).
  2. Le VNet porte déjà le tag 30 : la zone VLAN étiquette le trafic à la sortie vers vmbr0. Un tag supplémentaire serait incohérent.
  3. Le VNet n'existe pas sur ce nœud : la migration échoue, ou la VM ne démarre pas. C'est le même symptôme que la ligne source manquante.

Testez-vous

  1. Quel type de zone choisir pour réutiliser les VLAN existants du réseau d'entreprise ?

    Réponse

    Une zone VLAN adossée au bridge vmbr0.

  2. De combien réduire la MTU sur une zone VXLAN ?

    Réponse

    De 50 octets par rapport à la MTU physique (1450 sur un lien à 1500).

  3. Quelles parties du SDN sont encore en aperçu technologique ?

    Réponse

    L'IPAM avec DHCP, ainsi que le routage via FRR et l'intégration des contrôleurs (EVPN).

Pour aller plus loin