Zusammenfassung
- Das Netzwerk des ersten Tages von JANOG58 verzeichnete 1.925 MAC-Adressen an seinen Zugangspunkten, darunter etwa 1.580 randomisierte Adressen, während die Teilnehmerzahl 2.578 betrug.
- Während der Nur-NOC-Phase (Hot Stage) hinterließen etwa 60 aktive Benutzer und geschätzte 120 Endgeräte 275 Adressen im Verlauf – etwa das 2,3-fache der Endgeräteschätzung.
- Die Switches erreichten ihre MAC-Tabellen-Grenzen nicht. Das operative Problem zeigte sich zuerst in Identität, Richtlinie und Telemetrie, nicht in der Weiterleitungskapazität.
- Das NOC führte auch ein experimentelles VESPA-Design über EVPN/VXLAN durch, aber das veröffentlichte Material enthält keine Vorher-Nachher-Leistungsergebnisse, die belegen, dass der Veranstaltungsort dies erforderte.
Die MAC-Adresstabelle explodierte bei JANOG58 nicht. Die Bedeutung einer MAC-Adresse jedoch schon.
Ein nach dem Treffen der Japan Network Operators' Group in Matsuyama veröffentlichter Feldbericht zeigt, dass das Veranstaltungsnetzwerk über reichlich Switching-Kapazität verfügte. Er zeigt auch, warum freie Kapazität Betreiber in falscher Sicherheit wiegen kann, wenn mobile Betriebssysteme private Adressen rotieren.
Am ersten Tag erkannten die Zugangspunkte 1.925 MAC-Adressen und die Switches etwa 2.000. Von den APs waren etwa 1.580 – etwa 82 % – randomisiert und nicht global zugewiesen. Das Treffen verzeichnete 2.578 Teilnehmer, obwohl diese Zahlen nicht als Eins-zu-eins-Verhältnis betrachtet werden dürfen: Nicht jeder Teilnehmer hat sich unbedingt mit dem WLAN verbunden, während eine Person mehrere Geräte mit sich führen oder unter mehr als einer Adresse auftauchen konnte.
Das neue Ergebnis ist wichtig, weil die Betreiber von JANOG ein vertrautes technisches Problem erwartet hatten: eine Tabelle, die voll läuft. Was sie maßen, war ein viel früher auftretendes Abrechnungsproblem.
Kapazität war nicht die Einschränkung
Die Planungsannahme des NOC war einfach: 50 Zugangspunkte multipliziert mit 100 Clients ergab einen Bedarf von etwa 5.000 Adressen. Die angegebenen Switch-Kapazitäten waren weitaus größer. Der als Layer-3-Gateway eingesetzte 7050SX3 unterstützte eine MAC-Tabelle mit 160.000 Einträgen; die Access-Switches 720XP und 710P wurden mit 64.000 bzw. 32.000 Einträgen aufgeführt.
Diese Reserve half dem Team, ein flaches Layer-2-Design für den Veranstaltungsort zu wählen. Der Ergebnisbericht sagt explizit, dass das Adresswachstum nicht den Punkt des Tabellenüberlaufs erreichte.
Dies ist ein nützlicher negativer Befund. Ein Betreiber, der nur auf die Kopfzahl schaut, könnte einen größeren Switch kaufen und nichts lösen. Die Tabellenkapazität gibt an, wie viele Weiterleitungseinträge ein Gerät aufnehmen kann. Sie beantwortet nicht, ob ein Eintrag noch ein stabiles Gerät darstellt, ob die Richtlinie dem Benutzer folgt oder ob die gestrige Adresse für die heutige Fehlersuche noch nützlich ist.
JANOGs Daten belegen auch nicht, dass die Randomisierung zu Überlastung, Paketverlust oder Ausfällen führte. Der Bericht enthält keine solche Leistungsbehauptung. Sein Wert liegt darin zu zeigen, dass die Beobachtungseinheit volatil geworden war, während die Weiterleitungshardware sich wohlfühlte.
Ein Gerät kann mehrere Betriebsidentitäten hinterlassen
Die schärfere Messung erfolgte vor der Öffnung der Konferenz für alle Teilnehmer. Während der Nur-NOC-Phase (Hot Stage) zählte das Team etwa 60 aktive Benutzer. Bei Annahme von zwei Endgeräten pro Benutzer ergab sich eine Schätzung von etwa 120 Geräten. Der Verlauf der Zugangspunkte enthielt jedoch 275 MAC-Adressen, etwa 2,3-mal so viel, und 245 davon waren randomisiert.
Die Autoren vermuten, dass Bewegungen zwischen NOC-, Gast- und OpenRoaming-SSIDs beigetragen haben könnten. Das ist eine Hypothese, keine gemessene kausale Aufteilung. Die Anzahl der Endgeräte ist ebenfalls eine Schätzung. Die Richtung ist jedoch klar: Der historische Adresszustand kann schneller wachsen als die Population der physischen Clients.
Für Betreiber ändert dies mehrere Kontrollflächen auf einmal. MAC-basierte Authentifizierung und Zugriffsregeln können ihre Kontinuität verlieren. DHCP-Status und Adressverbrauch können ansteigen. Nutzungsanalysen können Adressen statt Personen oder Geräte zählen. Ein Incident Responder kann mehrere kurzlebige Identifikatoren für dasselbe Endgerät finden, was die Spur zwischen einem Benutzerbericht, einem AP-Protokoll und einer Switch-Tabelle schwächt.
Randomisierung existiert aus einem legitimen Datenschutzgrund: Eine dauerhafte Hardwarekennung kann verwendet werden, um ein Gerät über drahtlose Umgebungen hinweg zu verfolgen. Das Problem des Betreibers besteht daher nicht darin, die Privatsphäre abzuschaffen. Es besteht darin, aufzuhören, eine bewusst instabile Kennung als permanenten Identitätsschlüssel zu behandeln.
VESPA verlagert den Aufenthaltsort des Layer-2-Zustands
Das NOC von JANOG ging über Messungen hinaus und richtete einen experimentellen drahtlosen Pfad ein, der um zwei VESPA-Gateways, ein EVPN/VXLAN Layer-2-VPN und Zugangspunkte der Standards Wi-Fi 6, 6E und 7 aufgebaut war.
Der begleitende technische Bericht beschreibt VESPA – Virtual Ethernet Segment with Proxy ARP – als eine Arista-Implementierung, die das EVPN-Multihoming-Modell auf tunnelgebundene Ethernet-Segmente erweitert. Zugangspunkte fungieren als Layer-2-Proxys, während die Gateways den Client-Adresszustand verwalten und eine gemeinsame Gateway-Set-Identität sowie einen virtuellen Tunnel-Endpunkt verwenden.
Die zugrunde liegenden Ideen sind nicht willkürlich. RFC 7432 definiert EVPN-Ethernet-Segmente und MAC-Mobilität. RFC 9161 beschreibt, wie Proxy ARP und Neighbor Discovery IP-zu-MAC-Bindungen verteilen und die Adressauflösungsflutung in großen Broadcast-Domänen reduzieren können.
VESPA selbst sollte jedoch nicht als IETF-Standard dargestellt werden, und dieser Versuch belegt auch nicht, dass JANOG58 es zur Vermeidung von Erschöpfung benötigte. Die veröffentlichten Zahlen zeigen das Gegenteil: Die rohe MAC-Kapazität war reichlich vorhanden. Das Experiment ist besser als Test zu verstehen, wo flüchtige Client-Zustände gehalten werden sollten und wie ein großer Layer-2-Dienst betriebsfähig bleiben könnte, während die drahtlose Identitätsfluktuation zunimmt.
Das öffentliche Material enthält keinen Vorher-Nachher-Vergleich für Paketverlust, Latenz, Control-Plane-Last, ARP- oder DHCP-Zustand oder Fehlerbehebungszeit. Ohne diese Messungen ist der Versuch ein operativer Nachweis, kein Produkturteil.
Der nächste Maßstab ist die Fluktuation, nicht nur die Tabellengröße
Der nächste JANOG-Bericht könnte diese nützliche Momentaufnahme in einen aussagekräftigeren Betriebsmaßstab verwandeln. Er sollte gleichzeitige Clients von historischen Adressen trennen; erfassen, wie oft ein Endgerät seine Kennung ändert; DHCP-Leases, ARP-Einträge und Control-Plane-CPU messen; sowie Broadcast-Verkehr, Latenz und Fehlerraten vor und nach dem Proxy-Design vergleichen.
Die Beschaffung sollte derselben Logik folgen. Die maximale MAC-Anzahl eines Switches ist notwendige Kapazitätsangabe, aber nicht mehr ausreichend. Käufer benötigen auch Aufbewahrungskontrollen, Identitätsintegration, Verhalten pro SSID, Beobachtbarkeit über Adressänderungen hinweg und einen klaren Fehlermodus, wenn der Proxy-Zustand veraltet.
JANOG58s Ergebnis ist gerade deshalb wertvoll, weil der befürchtete Fehler nicht eintrat. Das Netzwerk ging nicht der Tabellenplatz aus. Stattdessen offenbarte es ein Governance-Problem innerhalb des Netzwerkbetriebs: Wen oder was repräsentiert eine Adresse, für wie lange, und welches System ist für die Wahrung der Kontinuität verantwortlich, wenn die Adresse dazu bestimmt ist, sich zu ändern?