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 ?