Résumé

  • Les points d'accès du JANOG58 ont détecté 1 925 adresses MAC le premier jour, dont environ 1 580 adresses aléatoires, tandis que la fréquentation atteignait 2 578 personnes.
  • Pendant la phase de préparation réservée au NOC, quelque 60 utilisateurs actifs et environ 120 terminaux estimés ont laissé 275 adresses dans l'historique, soit 2,3 fois l'estimation des terminaux.
  • Les tables MAC des commutateurs sont restées très loin de leur capacité maximale: la première difficulté concernait la continuité de l'identité et de l'observation, pas la commutation.
  • Le NOC a aussi mis en service un chemin expérimental VESPA sur EVPN/VXLAN, sans publier de comparaison de performance démontrant qu'il était nécessaire à cette échelle.

Le réseau du JANOG58 n'a pas manqué de place. Il a manqué d'une unité de compte stable.

Le compte rendu technique publié après la rencontre du Japan Network Operators' Group à Matsuyama apporte une conclusion plus intéressante qu'une saturation évitée. Au premier jour, les points d'accès ont vu 1 925 adresses MAC et les commutateurs environ 2 000. Près de 1 580 adresses observées par les AP, soit environ 82 %, étaient des adresses privées aléatoires.

Le nombre de entités, 2 578, donne l'échelle de l'événement mais pas un dénominateur directement comparable. Tous les visiteurs ne se sont pas forcément connectés au Wi-Fi; un même entité pouvait utiliser plusieurs appareils ou apparaître sous plusieurs adresses. La mesure décrit donc l'état du réseau, non un ratio universel d'adresses par personne.

La marge matérielle cachait le vrai coût

La planification partait de 50 points d'accès accueillant chacun 100 clients, soit un besoin d'environ 5 000 adresses. Face à cette hypothèse, les capacités annoncées étaient confortables: 160 000 entrées pour le 7050SX3 utilisé comme passerelle de couche 3, 64 000 pour le 720XP et 32 000 pour le 710P.

Cette marge a permis une architecture de couche 2 plate. Surtout, le rapport du NOC précise que le réseau n'a pas atteint la saturation de la table MAC. Il ne signale ni panne, ni pertes de paquets, ni congestion dues à la randomisation.

Ce résultat négatif est utile. Une table plus grande répond à la question « combien d'entrées le matériel peut-il mémoriser ? ». Elle ne dit pas si une entrée représente encore le même terminal, si une règle d'accès suit l'utilisateur ni si l'adresse observée hier aidera à diagnostiquer l'incident d'aujourd'hui.

Autrement dit, la capacité de commutation restait abondante alors que la qualité de l'identifiant se détériorait déjà.

Une adresse n'est plus une identité durable

La phase de préparation réservée au NOC rend cette rupture plus visible. Environ 60 utilisateurs actifs représentaient, selon l'hypothèse de deux appareils par personne, quelque 120 terminaux. L'historique des points d'accès contenait pourtant 275 adresses, dont 245 aléatoires. L'état observé atteignait ainsi environ 2,3 fois le parc estimé.

Les auteurs évoquent comme explication possible le passage entre plusieurs SSID — NOC, invités et OpenRoaming. Ce n'est pas une attribution causale mesurée, et les 120 terminaux restent une estimation. Mais la direction du phénomène est robuste: le volume d'identifiants historiques peut croître plus vite que le nombre de clients physiques.

Cela affecte plusieurs fonctions d'exploitation. L'authentification ou les listes de contrôle fondées sur la MAC perdent de la continuité. Les baux DHCP et les enregistrements ARP peuvent s'accumuler. Les statistiques risquent de compter des adresses plutôt que des appareils. Lors d'un incident, l'équipe doit relier le témoignage d'un utilisateur, le journal d'un AP et la table d'un commutateur malgré une succession d'identifiants éphémères.

La randomisation répond à un besoin légitime de protection contre le suivi d'un appareil entre réseaux sans fil. La solution opérationnelle ne consiste donc pas à supprimer cette protection, mais à cesser de faire de la MAC une clé d'identité permanente.

VESPA déplace l'endroit où réside l'état

Le NOC a profité de l'événement pour activer un chemin sans fil expérimental comprenant deux passerelles VESPA, un VPN de couche 2 EVPN/VXLAN et des points d'accès Wi-Fi 6, 6E et 7.

La présentation technique associée décrit VESPA, « Virtual Ethernet Segment with Proxy ARP », comme une mise en œuvre d'Arista qui étend le multihoming EVPN aux segments Ethernet rattachés par tunnel. Les points d'accès agissent comme mandataires de couche 2; les passerelles conservent l'état d'adressage des clients et partagent une identité de groupe ainsi qu'un point de terminaison de tunnel virtuel.

Les briques de base ont un ancrage normatif. Le RFC 7432 définit les segments Ethernet et la mobilité MAC dans EVPN. Le RFC 9161 explique comment le proxy ARP/ND peut diffuser les associations IP-MAC et réduire l'inondation de résolution d'adresses dans de grands domaines de diffusion.

VESPA n'est toutefois pas une norme IETF. Et les chiffres du JANOG58 ne prouvent pas que ce mécanisme était indispensable pour éviter la saturation: la capacité brute était largement suffisante. L'expérience teste plutôt un choix d'architecture — à quel endroit conserver un état client devenu volatil — qu'elle ne valide un produit.

Le rapport ne fournit aucune comparaison avant/après sur la latence, les pertes, la charge du plan de contrôle, les tables ARP ou DHCP, ni le temps de dépannage. Il s'agit d'une preuve de fonctionnement, pas encore d'une preuve de bénéfice.

Le prochain test doit mesurer le renouvellement

Pour transformer cette photographie en référence d'exploitation, le prochain rapport devrait séparer clients simultanés et adresses historiques, mesurer le nombre de changements par terminal, suivre les baux DHCP, les entrées ARP, la charge CPU et le trafic de diffusion, puis comparer ces indicateurs avant et après l'activation du proxy.

Les achats devraient intégrer la même leçon. La taille maximale d'une table MAC reste nécessaire, mais elle ne suffit plus. Il faut aussi connaître les règles de rétention, l'intégration avec une identité supérieure à la couche 2, le comportement par SSID et le mode de défaillance lorsque l'état du proxy devient obsolète.

Le JANOG58 n'a pas documenté la catastrophe annoncée. Il a révélé une question plus durable: lorsqu'une adresse est conçue pour changer, quel système garantit la continuité entre l'appareil, la politique et la preuve opérationnelle ?

Sources