Set-OPS-Public/docs/sdn-evpn.md

SDN EVPN : le routage passe aux hyperviseurs

Décision d'architecture du 2026-08-02. Elle remplace le routage inter-zone sur les commutateurs L3 par des zones EVPN de Proxmox SDN. Complète docs/frontiere-opnsense.md (la bordure, inchangée) et underlay.yml.example (la fabric, très allégée).

Rien n'est encore éprouvé. Ce document fixe la cible et la projection du modèle ; le spike vient avant toute génération.

1. Ce que la décision résout

Les commutateurs Binardat ne savent pas lier une ACL à une interface de routage : l'isolation inter-tenant ne pouvait pas vivre sur la fabric. On l'a d'abord assumé — tout sur les nftables d'hôte — en notant ce qu'on perdait : le plan de gestion n'avait plus de protection réseau contre les tenants, une VM émettant vers 10.0.0.x étant routée localement vers le mgmt des commutateurs, celui de Proxmox et l'OOB/IPMI.

Une zone EVPN est un VRF. Le tenant n'a plus de route vers l'underlay — celui-ci n'est pas dans sa table de routage. Son seul chemin vers l'extérieur passe par le nœud de sortie, donc par l'OPNsense, qui filtre. Le plan de gestion redevient protégé par construction, pas par une règle qu'on pourrait oublier.

C'est le VRF qu'on regrettait de ne pas avoir dans le matériel, obtenu en logiciel.

2. La projection du modèle

Vérifiée sur les deux tenants fédérés, elle ne demande aucun changement de dérivation :

Objet Proxmox SDN	Vient de	Exemple (Chezlepro, zone Services-infra)
zone (un VRF)	le tenant	CHEZ17
VNet	la zone de sécurité	chez17-services-infra
tag (VNI)	vlan_de(index, zone)	1174
subnet	sous_reseau_de(index, zone)	10.27.19.0/24
gateway	passerelle_de(index, zone)	10.27.19.1

Le seed index reste la source unique. Le .1 ne change pas d'adresse, il change de porteur : du SVI d'un commutateur vers la passerelle anycast du VNet, présente sur chaque hyperviseur — donc plus proche de la VM, et sans point unique de défaillance.

Effet de bord favorable : un VNI est codé sur 24 bits là où un VLAN plafonne à 4094. La limite du nombre de tenants n'est plus l'espace de VLAN mais le second octet IPv4 du supernet — le plafond de 245 tenants reste, sa cause change.

3. Ce que le devis switch devient

Il maigrit beaucoup. Disparaissent : les VLAN tenants, les SVI de zone, les ACL d'isolation, et les VLAN tenants dans les trunks. En EVPN, aucun VLAN de tenant ne circule sur le fil — seulement du VXLAN encapsulé dans de l'IP.

Restent : les VLAN d'underlay, le SVI de management, les trunks qui ne portent plus qu'eux, les routes, le spanning-tree. La fabric redevient ce qu'elle aurait dû être — un transport IP.

underlay.routeur garde son sens, mais son rôle se réduit : il route l'underlay, plus les tenants.

4. Ce que ça change ailleurs

Le nœud de sortie remplace le prochain saut. En EVPN, le trafic quitte le VRF par un ou plusieurs exit nodes désignés. Ce sont eux, et non plus le commutateur, que l'OPNsense voit comme voisins. underlay.passerelle_sortie changera de nature : il désignera l'entrée du tenant vers la bordure, côté hyperviseur.

Le MTU devient un prérequis, pas un détail. VXLAN ajoute 50 octets. Le transport doit passer à 1550 au minimum, jumbo de préférence. C'est le premier mur, et le plus déroutant : il ne casse pas franchement, il casse partiellement — le ping passe, les transferts échouent.

Ce qui ne change pas : le plan, le registre des flux, les nftables d'hôte, la frontière OPNsense et ses règles dérivées, la voûte, les preuves. La cible d'émission change ; le modèle non.

5. Ce qui reste à éprouver — avant toute génération

Le principe du dépôt s'applique : éprouver l'outil avant d'écrire le rôle. L'EVPN est la partie la plus jeune de Proxmox SDN, et c'est là que vivent les bogues.

Un tenant de labo, une zone EVPN, deux VNet, une VM dans chacun — et vérifier dans l'ordre :

1. le MTU de bout en bout, avec des paquets pleins et le bit don't fragment ;
2. le routage entre VNet d'une même zone (c'est ce qui remplace le SVI du commutateur) ;
3. l'absence de route vers l'underlay depuis le tenant — c'est le gain principal, il se vérifie par une tentative qui doit échouer ;
4. la sortie par le nœud de sortie, jusqu'à la bordure ;
5. le comportement à la perte d'un nœud : la passerelle anycast est censée survivre.

Ce n'est qu'après que la question « comment générer cette configuration » se pose.

6. Ce qui reste à trancher

• Où vit la configuration SDN. Elle est par cluster, donc propriété de l'hébergeur — comme underlay.yml, et par le même raisonnement.
• Le contrôleur EVPN : ASN, voisins, et si l'on fait du BGP avec la bordure ou des routes statiques comme aujourd'hui.
• Le nombre de nœuds de sortie et leur redondance.
• La migration depuis l'existant : le tenant Chezlepro tourne déjà sur des VLAN. Passer à EVPN est un changement de plan de transport pour des VM en service — la recette de docs/migration-tenant.md s'applique-t-elle, ou faut-il un chemin plus court ?