Summary
- JANOG58's first-day network recorded 1,925 MAC addresses at its access points, including about 1,580 randomised addresses, while attendance reached 2,578.
- During the NOC-only hot stage, about 60 active users and an estimated 120 endpoints left 275 addresses in history—roughly 2.3 times the endpoint estimate.
- The switches did not approach their MAC-table limits. The operational issue surfaced first in identity, policy and telemetry, not forwarding capacity.
- The NOC also ran an experimental VESPA design over EVPN/VXLAN, but the published material contains no before-and-after performance result proving that the venue required it.
The MAC address table did not explode at JANOG58. The meaning of a MAC address did.
A field-results deck published after the Japan Network Operators' Group meeting in Matsuyama shows that the venue network retained ample switching capacity. It also shows why spare capacity can give operators false comfort when mobile operating systems rotate private addresses.
On the first day, the access points detected 1,925 MAC addresses and the switches saw about 2,000. Of the AP population, approximately 1,580—about 82%—were randomised rather than globally assigned addresses. The meeting recorded 2,578 attendees, although these figures must not be treated as a one-to-one ratio: not every attendee necessarily joined Wi-Fi, while one person may have carried several devices or appeared under more than one address.
The new result matters because JANOG's operators had planned for a familiar engineering problem: a table filling up. What they measured was an accounting problem that arrives much earlier.
Capacity was not the constraint
The NOC's planning assumption was straightforward: 50 access points multiplied by 100 clients, producing a requirement of roughly 5,000 addresses. Its disclosed switch capacities were far larger. The 7050SX3 used as the Layer-3 gateway supported a 160,000-entry MAC table; the 720XP and 710P access switches were listed at 64,000 and 32,000 entries respectively.
That headroom helped the team choose a flat Layer-2 design for the venue. The results deck says explicitly that address growth did not reach the point of overflowing a table.
This is a useful negative finding. An operator looking only at the headline number could buy a larger switch and solve nothing. Table capacity answers how many forwarding entries a box can hold. It does not answer whether an entry still represents a stable device, whether policy follows the user, or whether yesterday's address remains useful for troubleshooting today.
JANOG's data also does not prove that randomisation created congestion, packet loss or an outage. The deck publishes no such performance claim. Its value lies in showing that the unit of observation had become volatile while the forwarding hardware remained comfortable.
One device can leave several operational identities
The sharper measurement came before the conference opened to all attendees. During the NOC-only hot-stage period, the team counted about 60 active users. Assuming two endpoints per user gave an estimate of roughly 120 devices. Yet the access-point history contained 275 MAC addresses, about 2.3 times that estimate, and 245 of them were randomised.
The authors suggest movement among NOC, guest and OpenRoaming SSIDs may have contributed. That is a hypothesis, not a measured causal split. The endpoint count is also an estimate. But the direction is clear: historical address state can grow faster than the population of physical clients.
For operators, this changes several control surfaces at once. MAC-based authentication and access rules can lose continuity. DHCP state and address consumption can grow. Usage analytics can count addresses rather than people or devices. An incident responder may find several short-lived identifiers for the same endpoint, weakening the trail between a user report, an AP log and a switch table.
Randomisation exists for a legitimate privacy reason: a durable hardware identifier can be used to follow a device across wireless environments. The operator's problem is therefore not to abolish privacy. It is to stop treating a deliberately unstable identifier as a permanent identity key.
VESPA moves where Layer-2 state lives
JANOG's NOC went beyond measurement and brought up an experimental wireless path built around two VESPA gateways, an EVPN/VXLAN Layer-2 VPN and access points representing Wi-Fi 6, 6E and 7.
The accompanying technical deck describes VESPA—Virtual Ethernet Segment with Proxy ARP—as an Arista implementation that extends the EVPN multihoming model to tunnel-attached Ethernet segments. Access points act as Layer-2 proxies, while the gateways maintain client address state and use a shared gateway-set identity and virtual tunnel endpoint.
The underlying ideas are not arbitrary. RFC 7432 defines EVPN Ethernet segments and MAC mobility. RFC 9161 describes how proxy ARP and neighbour discovery can distribute IP-to-MAC bindings and reduce address-resolution flooding in large broadcast domains.
But VESPA itself should not be presented as an IETF standard, nor does this trial establish that JANOG58 needed it to avoid exhaustion. The published figures show the opposite: raw MAC capacity was abundant. The experiment is better understood as a test of where volatile client state should be held and how a large Layer-2 service might remain operable as wireless identity churn rises.
The public material does not report a before-and-after comparison for packet loss, latency, control-plane load, ARP or DHCP state, or troubleshooting time. Without those measures, the trial is operational evidence, not a product verdict.
The next benchmark is churn, not just table size
The next JANOG report could turn this useful snapshot into a stronger operating benchmark. It should separate simultaneous clients from historical addresses; record how often one endpoint changes identifiers; measure DHCP leases, ARP entries and control-plane CPU; and compare broadcast traffic, latency and failure rates before and after the proxy design.
Procurement should follow the same logic. A switch's maximum MAC count is necessary capacity data, but it is no longer sufficient. Buyers also need retention controls, identity integration, per-SSID behaviour, observability across address changes and a clear failure mode when proxy state becomes stale.
JANOG58's result is valuable precisely because the feared failure did not happen. The network did not run out of table space. Instead, it exposed a governance problem inside network operations: who or what does an address represent, for how long, and which system is responsible for preserving continuity when the address is designed to change?