Inside TahoeIX’s Reno Fabric: The Two-Site Test for Keeping Sierra Traffic Local

Summary

• Open TahoeIX during a Sierra transport interruption and test whether two regional networks can still exchange traffic in Reno without following the failed path out of the region.
• Public records confirm AS63212, two Reno exchange locations, route servers and active participation signals, but they do not establish physically independent member access, power autonomy or a tested site-failure procedure.
• TahoeIX becomes demonstrable resilience infrastructure only when members can document diverse entrances, failure-domain-separated transport, usable headroom and repeated failover results rather than relying on port totals and a two-dot facility map.

The interruption test TahoeIX has to pass

The useful way to open TahoeIX is not with a normal-day latency chart. Open it during a Sierra transport interruption. Choose two networks that serve the Reno–Tahoe region, withdraw or disable the route that normally carries their traffic toward a distant hub, and ask a plain question: can those two networks still exchange packets across the local fabric without touching the failed corridor? If the answer is yes, the exchange is doing something materially different from merely offering a convenient handoff on an ordinary afternoon.

If the answer is no because both members reach the exchange over the same carrier, conduit, building entrance, power system or mountain route that has failed, the local peering label has not produced local resilience.

That distinction matters because an internet exchange is a meeting place, not a force field. The Internet Society’s explanation of IXPs describes the physical ingredients clearly: a switch, routers, servers, a suitable location, power, cooling, security and people who can operate the system. Those ingredients can create shorter paths and reduce dependence on distant transit. They do not automatically make every path into the switch independent. A entity that buys one circuit from Lake Tahoe to Reno, then uses that same circuit both for transit and for its TahoeIX port, has gained a new routing relationship without necessarily gaining a new failure domain.

TahoeIX frames its own purpose in regional terms. The exchange’s public operating page says it exists to foster community routing, improve reliability and keep Northern Nevada traffic local. That is a credible and important objective. The page also contains the sentence that should govern any resilience assessment: the fabric is built with donated connectivity, space, power and infrastructure, and is intended as a peering fabric rather than a transport or carrier replacement. In other words, TahoeIX can provide a local place to meet, but entities remain responsible for reaching that place in a way that survives the event they care about.

Recent research on peering sharpens the point. The Peering Disconnect argues that a connection can look local at the commercial or logical layer while still depending on a remote physical path. That warning applies even without virtual peering. A Tahoe-area provider may appear beside another network in a Reno exchange table, yet both connections may traverse the same westbound or eastbound fiber corridor before they arrive. The packet is locally switched only after it has survived the shared approach.

Nor should an exchange failure be treated as binary. Internet Society Pulse research on IXP shutdown impacts found that some links have no short alternative while others can be diverted only at substantial capacity cost. The TahoeIX test therefore needs more than a successful ping. It needs sustained traffic under a defined failure, acceptable latency and loss, enough spare capacity on the surviving path, and evidence that routing converges without manual improvisation. That is the difference between a topology diagram and an operating capability.

The central finding is consequently conditional rather than dismissive. TahoeIX has enough public evidence to be treated as a real regional exchange. It has assigned network resources, visible entities, two published locations and long-running operational history. But resilience is a property of the whole path—from member router, through access transport and facility power, across the exchange switch, to the other member—not of the exchange name alone.

The rest of the assessment asks where that path is visible, where it remains opaque, and what would prove that local traffic can remain local when the Sierra stops behaving like a normal operating environment.

What AS63212 proves—and what it does not

TahoeIX’s strongest evidence begins with internet number resources. The ARIN registration for AS63212 identifies TAHOEIX-PEERING, records the autonomous system’s registration in September 2014 and provides a durable registry anchor for the exchange identity. Separate ARIN records identify the 206.41.109.0/24 IPv4 peering network and the 2001:504:3f::/48 IPv6 allocation. Those records are not promotional claims. They establish that the exchange has dedicated public number resources associated with its peering function.

The public records nevertheless stop well short of proving resilience. An ASN does not show whether a switch is powered today, whether two member ports share an optical shelf, whether a cross-connect follows a diverse riser, whether route-server backups sit in separate fault domains, or whether a regional ISP’s TahoeIX circuit rides the same cable as its upstream transit. An IP address responding, a BGP session being configured or a registry entity remaining current can show presence.

None by itself establishes that traffic will survive a fire closure, a utility shutoff, a cut long-haul route or the loss of the room containing the primary switch.

The ownership boundary is similarly narrower than the name may imply. Public descriptions characterize TahoeIX as a cooperative regional effort or association, supported by sponsors and donations. They do not establish that TahoeIX owns the buildings, the member access circuits or all transport between its locations. Its own history credits Roller Network with operational support, colocation and infrastructure, and High Desert Internet Services with transport to the downtown extension. That is a practical community arrangement, but it means the service depends on several organizations whose responsibilities have to line up during an incident.

The Packet Clearing House IXP entry calls TahoeIX active and records its Ethernet exchange subnets, founding date and switch information. That corroborates the exchange’s identity, although the entry’s entity and traffic fields should be treated as a directory snapshot rather than a real-time service report. It lists a Cisco Nexus 3548P-10G at the core and a Reno address, but it does not describe power autonomy, spare hardware, restoration targets or a full inter-site path.

This leads to a disciplined reading of AS63212. The number is strong evidence that TahoeIX is not merely a proposed project. The IPv4 and IPv6 records show purpose-built exchange resources. The entity addressing and independent listings reinforce current network presence. What remains unproven is not existence but behavior under stress. The relevant next questions are physical: where are the active switching components, how do members reach them, which dependencies are shared, how much traffic can move after a failure, and who has authority and access to restore the fabric when roads, power or building entry are constrained?

Two Reno rooms, one exchange surface

The exchange’s name evokes Lake Tahoe, but its published switching locations are in Reno. TahoeIX identifies its core and services location at Roller Network, 3545 Airway Drive, Suite 114, and an extension at 200 South Virginia Street. That geography is not a flaw; Reno is the regional interconnection center where local providers, long-haul networks and content systems can meet. It is, however, essential to describe the asset accurately. TahoeIX is a Reno-based regional exchange serving a Northern Nevada and wider Sierra network community, not a switch physically positioned on the lakeshore.

The Airway site has the clearest connection to the exchange’s operating identity. The PeeringDB facility record for Roller Network places the colocation facility at 3545 Airway Drive and lists TahoeIX among the in-building networks. It also lists Hurricane Electric, Verizon, Spectrum and AT&T as in-building networks, while leaving diverse utility substations undisclosed. TahoeIX says its Airway service offers 1G and 10GbE interfaces over single-mode fiber and names a donated Cisco Nexus 3548P-10G. Its two published route servers are both labelled at Airway. That is a meaningful inventory, but it also concentrates several visibly important functions in the same named location.

The downtown extension creates a second attachment point. The PeeringDB record for 200 South Virginia identifies Suite 650, lists TahoeIX as the local exchange and describes the building as a key Reno interconnection location. The record says the property has diverse serving substations and 480-volt service, and lists five networks present at the facility. Those fields are useful facility signals, not proof that the TahoeIX cabinet receives two independent power feeds or that every cross-connect uses a diverse building entrance.

The current facility operator’s own material adds detail. A CENTRA RNO1 facility sheet names TahoeIX among a broad group of networks and service providers at 200 South Virginia, describes a neutral meet-me room, says the site has four points of entry, and identifies a 250-kilowatt data-center facility tethered to a second Reno location at 265 Keystone Avenue. These are commercially published capabilities. They support the conclusion that 200 South Virginia is a substantial interconnection building; they do not demonstrate which entrances, risers, power systems or tether paths are actually used by TahoeIX.

The downtown facility has also changed operating context over time. A Data Center Dynamics report on Deep Edge Realty’s 2021 move described TahoeIX as present in a well-connected carrier hotel and relayed claims of diverse fiber, powered space and a meet-me room. A commercial data-center listing for the current CENTRA Reno site similarly describes multiple points of entry, long-haul routes and redundant infrastructure. Those accounts are useful corroboration of the building’s market role, but neither is an engineering attestation for the exchange. Marketing language such as “diverse” must be tied to route drawings, entrance identifiers, splice points and the exact service bought by the exchange before it can carry resilience weight.

The two locations therefore establish spatial separation, not fault-domain separation. They are different street addresses several miles apart. Each can give a entity a place to cross-connect. Public material also identifies a switch type at each site. What it does not show is the topology between those switches: whether there is one circuit or more than one, whether the circuits follow separate streets and bridge crossings, whether they enter through different building pathways, whether they terminate on independent optical equipment, and whether loss of the Airway switch or route-server area changes what the downtown switch can do.

This distinction should govern the phrase “two-site exchange.” Two sites can improve access and expand the pool of nearby networks. Two sites become a resilience design only when either site can continue a defined service after the other site or the link between them fails. The physical rooms are real. The public failover architecture connecting them remains an open question.

The missing map is the path between the rooms

Maps invite overconfidence because a pair of points looks like diversity. The public TahoeIX material gives precise endpoints but not a route. It says High Desert Internet Services provides transport to the 200 South Virginia extension and says entities may peer at only one location. That arrangement may be entirely sound for a small cooperative exchange. It also creates an obvious verification task: determine whether the extension depends on one donated transport path, what equipment terminates it, and what happens to downtown entities when that path or the Airway core fails.

No public evidence located for this assessment provides a street-level or conduit-level route between Airway Drive and South Virginia Street. There is no published shared-risk link group, no list of bridge or railroad crossings, no entrance-and-riser schedule, and no statement that two inter-site circuits use different carriers. Without those details, it would be irresponsible to draw a line on a map and call it the TahoeIX route. The honest map has two verified site points and an unverified logical relationship between them.

The same caution applies to the larger service area. California is building new middle-mile infrastructure around the lake, including a Caltrans State Route 28 project that specifies fiber and conduit between Tahoe City and Kings Beach. That is important evidence of regional broadband investment and of the continuing need for middle-mile facilities. It is not evidence that TahoeIX rides that fiber, that the route reaches either Reno site, or that a network using it has a diverse path to the exchange. A public road-corridor project should not be silently converted into a private exchange-route map.

For each member, resilience has to be evaluated from its own router to the exchange port. A north-shore provider, a Reno wireless ISP and a long-haul carrier face different approach paths. A circuit sold by two commercial brands can still share conduit, poles, regeneration huts or an upstream provider. Conversely, one provider may own genuinely diverse fiber on separate corridors. The exchange cannot infer independence from invoice count. It needs route-level attestations or confidential engineering review that identifies common structures without exposing sensitive detail publicly.

The entity-at-one-location rule makes this analysis more important. If a member cannot attach the same ASN at both TahoeIX sites, site diversity must come from some other mechanism: a separately connected partner network, a resilient inter-site fabric, bilateral sessions elsewhere, or alternate transit that preserves the required service. The rule may simplify operations and prevent the exchange from becoming free transport, but it means the exchange cannot point to dual-site member ports as a universal recovery answer. The public record should explain the intended failure behavior instead.

Membership signals activity, not independent reach

TahoeIX has substantial public participation evidence, but the current numbers do not line up neatly. The exchange’s own page lists 15 active peers or service entities in addition to its two route-server entries. The list spans local access providers, infrastructure services, a large transit network, root-server operators, content and TahoeIX’s own services. It places most entries at Airway and two access providers at 200 South Virginia. That mix supports the argument that the exchange has real regional utility: local networks can meet infrastructure and content systems without treating every packet as generic long-haul transit.

An independent Hurricane Electric exchange view also listed 15 members and showed an update date of April 14, 2026. It reproduced the IPv4 and IPv6 exchange ranges and member addressing, providing a useful third-party observation close to the article date. It remains an external directory view, not proof that every listed BGP session was established or passing traffic at the instant of publication.

The PeeringDB TahoeIX entry presented a different snapshot: 12 peers, 13 connections, 39 Gbps of total port speed, two local facilities, best-effort service and no commercial terms. PeeringDB’s exchange entity itself displayed an older last-updated date even though connected network data can change independently. That makes the page valuable but composite: some fields are operator-maintained exchange metadata, while membership and connection totals reflect records maintained across multiple network entities.

The Internet Society Pulse TahoeIX tracker reported PeeringDB-derived data for May 2026 showing 11 members and 38 Gbps, with no joins or departures in the preceding twelve months. Packet Clearing House showed still another view, including active status, 14 IPv4 entities, 13 IPv6 entities and a 150 Mbps traffic field without a clear current measurement timestamp. These are not necessarily contradictions in the sense of one party being wrong. They may count services, route servers, multiple connections, private entries and update times differently. But the spread is too large to treat any single total as an audited current member count.

The correct conclusion is that TahoeIX has a strong activity signal and a weak membership-control signal. Multiple independent pages see the exchange, the addresses and a nontrivial set of networks. The unresolved question is which entities are operational, which have active route-server or bilateral sessions, which are reachable in IPv6 as well as IPv4, and which connections are physically independent of one another. A peer list is not a resilience matrix.

For the regional interruption test, members should be grouped by failure domain rather than logo. If three access providers all reach Airway through the same upstream fiber, their three ports do not provide three independent ways into the exchange. If a downtown entity uses an inter-site extension that returns to Airway before it can reach most peers, its apparent second-site presence may still depend on the first site. A content cache at Airway can serve local users during an upstream outage only if those users’ providers can still reach Airway and the requested content is already available locally.

Root-server instances improve access to specific DNS functions, not the reachability of every public service.

Port totals are not usable emergency capacity

Capacity is the area in which public numbers are easiest to repeat and easiest to misunderstand. TahoeIX advertises 1G and 10GbE interfaces at both locations. Its active-peer table attaches nominal rates to individual ports, including a multiport content connection. PeeringDB reports an aggregate total, Pulse repeats a nearby PeeringDB-derived figure, and Packet Clearing House exposes a traffic number. These values describe different things.

A port rate is an access ceiling. It does not say how much traffic a entity normally sends, how much the switch can forward under every packet-size mix, how much inter-site transport is installed, whether a 10G member port is rate-limited elsewhere, or how much spare capacity remains after a failure. Adding all member port labels can describe the edge of the fabric, but traffic does not flow at every port’s maximum in both directions simultaneously. More importantly, an exchange can have abundant access-port capacity and a narrow inter-site link or shared backhaul that becomes the emergency bottleneck.

The 39 Gbps PeeringDB total and the 38 Gbps Pulse snapshot are close enough to suggest a one-port or one-record timing difference. They are much lower than the mechanical sum of all nominal rates visible on TahoeIX’s own active-peer page, which includes services and connections that may be counted differently or may not appear in public PeeringDB records. Packet Clearing House’s 150 Mbps field appears to be a traffic observation, not installed capacity, but its date and aggregation method are not evident on the page. None of these numbers should be labelled “TahoeIX capacity” without a qualifier.

Facility capacity is another separate layer. CENTRA’s 250-kilowatt figure describes its downtown data-center facility, not power reserved for TahoeIX. The claim of four points of entry describes the building, not necessarily the path used by the exchange. Data Center Map’s reference to high-speed services and redundant infrastructure likewise describes market availability. It does not show the purchased TahoeIX cross-connect, the inter-site circuit rate or the exchange cabinet’s protected power runtime.

Usable emergency capacity is the minimum that remains across the surviving end-to-end path after the selected failure. To calculate it, TahoeIX and each test entity would need at least five values: normal peak traffic, surviving member access rate, surviving switch and fabric rate, surviving inter-site rate where relevant, and alternate transit or peer capacity needed for destinations no longer local. Operators would then apply an engineering margin for bursts, route changes and maintenance. A 10G port attached to a 1G surviving transport path contributes at most 1G to that scenario, before overhead and headroom.

The exchange’s public traffic graphs are helpful evidence of operation, but screenshots or rolling graphs do not substitute for a dated capacity statement. A resilience report should publish normal 95th-percentile and peak aggregate traffic, the highest failover test load, the smallest surviving bottleneck, and the amount of headroom during the test. It should state whether figures are design, installed, lit, powered, operational or usable. It should also distinguish capacity sold or assigned to members from capacity available to carry rerouted traffic.

No public evidence reviewed here establishes the inter-site circuit count or rate, switch-stack failover behavior, reserve ports, spare optics, replacement-switch location, UPS runtime, generator runtime, fuel contract or maximum tested traffic after a site failure. Recording those values as unavailable is more useful than manufacturing a clean total. TahoeIX’s capacity case is therefore credible at the port-presence level, uncertain at the fabric-and-power level, and unproven at the defined regional-failure level.

Route servers solve adjacency, not common-mode failure

TahoeIX publishes two BIRD route servers, both shown at Airway. It requires a session to Route Server 1 for the looking glass and describes Route Server 2 as optional. Entities can use the route servers for broad open peering, apply communities to control announcements, and establish direct bilateral sessions where appropriate. This is a sensible structure for lowering the operational cost of joining a small exchange.

Route servers make many-to-many routing relationships manageable, but they do not forward user packets. A entity sends routes to the server; the server applies policy and distributes selected paths; the actual packet moves directly between entity routers across the exchange fabric. That means a route-server outage and a switch outage have different effects. Existing forwarding can continue for a time if routes remain installed, while session resets, withdrawals, maintenance and policy changes may be impaired. A failed switch or transport path, by contrast, interrupts the packet path itself.

The MANRS guidance on IXP route-server security explains why filtering matters. Route servers should validate announcements against routing registries and RPKI data, block invalid or special-use routes, and prevent a member mistake from being reflected across the exchange. The same guidance notes the value of multiple independent route-server instances. TahoeIX’s public communities and dual server addresses show policy capability, but the public page does not state whether it performs IRR-based filtering, RPKI origin validation, maximum-prefix controls or other current safeguards.

The location label raises a second question. Both route servers appear at Airway. They may still run on independent hardware, power supplies and software instances, but two IP addresses in one room are not geographic redundancy. If the Airway site is inaccessible or loses power beyond backup runtime, the downtown extension’s control-plane behavior depends on the unpublished fabric design. Can downtown members continue bilateral sessions locally? Can they reach a route server at another site? Does the downtown switch operate autonomously, or is it an extension whose useful peering state depends on Airway?

Best-effort service is not inherently inappropriate for a cooperative exchange. PeeringDB explicitly labels TahoeIX best effort and without an SLA. The mistake would be allowing users or public agencies to interpret “improves reliability” as a contractual recovery promise. If TahoeIX is expected to support continuity, the community needs a technical service objective even if it remains noncommercial: monitored availability, notification expectations, configuration backup frequency, spare-hardware readiness, route-server restoration order and a target for convening member engineers during a regional event.

Direct bilateral sessions are an important hedge. Two critical regional networks can maintain bilateral BGP even if a route server is unavailable. But bilateral policy cannot repair a dead switch, a severed shared access cable or a powerless room. Nor does it guarantee that the networks announce the local prefixes needed during an emergency. The resilience exercise should therefore validate the control plane and data plane separately: withdraw a route server, withdraw one inter-site path, isolate a switch, and then test selected local prefixes with enough load to expose congestion.

Routing security belongs in the same exercise. A chaotic incident is the worst time to discover that emergency route changes are rejected by stale filters, or that overly permissive policy accepts a leak. TahoeIX can turn its small scale into an advantage by coordinating route objects, RPKI status, maximum-prefix settings and named contacts with every active entity. The exchange’s route-server surface is real and useful. Its independence, filtering posture and recovery behavior require a dated technical disclosure or witnessed test.

Fire makes electricity part of the peering design

Wildfire threatens communications in more than one way. Flames can damage aerial plant, roadside cabinets and utility infrastructure. Evacuation orders can remove staff from a facility. Smoke and road closures can delay repair. Utilities may also de-energize lines deliberately to reduce ignition risk, turning an intact communications room into a backup-power problem. In the Tahoe region, this is not a hypothetical chain.

California’s emergency-services regulator has documented the communications consequences of the 2021 Caldor Fire. A Cal OES rulemaking document on outage reporting says significant telephone outages went unreported under the then-existing threshold, leaving users unable to make 911 calls or receive emergency notifications and depriving responders of adequate outage information. The document specifically describes the impact around South Lake Tahoe and explains why the state sought more sensitive reporting. The related Cal OES community-isolation reporting page defines when providers must report outages that limit 911 or emergency-notification access.

Those records do not say TahoeIX failed during the Caldor Fire. They show why regional network dependencies deserve a public-continuity lens. Local peering will not restore a damaged cellular tower or every path to a 911 center. It can, however, preserve selected local routes, cached content, DNS infrastructure, government services or coordination systems if the relevant networks and services remain powered and connected. The value is specific, not universal.

Power planning must cover both sides of the state line and both Reno facilities. A Liberty post-event report for a November 2025 public-safety power shutoff shows how shutoffs can be planned for many hours and require community resource centers. Liberty’s weather-station maintenance explanation connects field weather data to shutoff decisions, while its wildfire-mitigation project page describes covered conductor and other work intended to reduce fire risk and the need or severity of shutoffs.

On the Nevada side, NV Energy’s Public Safety Outage Management page includes the eastern Tahoe Basin among areas where extreme fire conditions can lead to preventive outages. A 2024 NV Energy emergency de-energization notice described outages affecting West Reno and Verdi during the Gold Ranch Fire. TahoeIX’s rooms are in Reno rather than the basin, but its entities and transport paths may cross the affected areas. An exchange cabinet with working utility power is of limited use if a member’s mountain access node has exhausted its batteries.

The wider risk context remains active. El Dorado County’s community wildfire protection planning page identifies community preparation, response and recovery as ongoing priorities and points to a 2025 Lake Tahoe Basin plan. The California Tahoe Conservancy’s May 2026 update again treated wildfire resilience as a basin-wide concern. These are hazard-context sources, not TahoeIX topology evidence, but they establish that fire should be a designed operating condition rather than a remote exception.

The dependency runs in both directions. CISA’s communications infrastructure primer describes communications as dependent on electricity and transportation, including fuel delivery for generators, while emergency services, energy and other sectors depend on communications. CISA’s Emergency Communications Systems Value Analysis Guide discusses batteries, uninterruptible power and generators as continuity measures. For TahoeIX, the practical questions are exact: protected load at each site, battery runtime, generator coverage, refuelling arrangements, transfer-test history, remote monitoring and the power autonomy of member transport equipment between the lake, Reno and the exchange ports.

Snow turns access time into network capacity

Winter changes the failure calculation even when every fiber remains buried and uncut. Heavy snow and wind can make roads difficult, bring down branches, interrupt commercial power and delay a technician carrying an optic or replacement switch. A National Weather Service warning for the Reno–Tahoe area in February 2026 forecast heavy snow, strong wind and difficult travel, including impacts in foothill areas. One warning does not quantify TahoeIX’s annual exposure, but it illustrates the operating condition that a mountain-region recovery plan must assume.

The Lake Tahoe Basin Management Unit also treats winter closures and seasonal access constraints as routine features of the basin. Exchange staff may be in Reno, but member infrastructure can sit along roads, ridges and communities where access is slower. The failure clock for local peering therefore begins at the most constrained component, not at the exchange cabinet. If an access provider’s aggregation site has four hours of battery and a replacement crew needs six hours to arrive, the effective resilience of that member’s TahoeIX path is four hours.

Snow also exposes the difference between remote recovery and physical recovery. BGP policy, route-server configuration and monitoring can often be changed remotely if management connectivity remains available. A failed power supply, damaged patch lead, flooded handhole or severed cable cannot. TahoeIX’s public material gives contact information and a physical shipping address, but not a winter staffing arrangement, remote-hands agreement, spares inventory or target response time at either site.

Two facilities can reduce this risk if spares, access and authority are distributed. A replacement switch stored in the same Airway room as the active switch does not help if the building is inaccessible. A downtown switch with independent local peers may preserve some traffic if Airway is isolated, but only if it can operate without the inter-site link and has its own routing path. A technician roster is only as resilient as the roads and credentials that let someone reach the equipment.

The winter proof is straightforward to define. Before the season, verify remote console access, configuration restoration, environmental alarms, spare optics and power supplies, after-hours facility entry, alternate contacts and the location of replacement hardware. During a controlled exercise, operate from the surviving site and have a second engineer who is not at the primary facility confirm routing and traffic. Record how long the exchange could run without utility power and how long member edge sites could remain attached.

Snow does not reduce a switch’s faceplate rate, but it can sharply reduce the amount of that capacity that remains reachable and repairable.

A failed exchange reaches beyond its member list

The immediate customers of TahoeIX are networks, not households. The consequence of failure travels through those networks to residents, businesses, visitors, public agencies and infrastructure operators. The impact is also uneven. A network that uses TahoeIX mainly for a content cache may see higher latency and more transit load when the exchange fails. A small provider whose affordable upstream design assumes substantial local offload may see congestion. Two public-sector networks exchanging a local application could lose the short path entirely if no alternate relationship exists.

The member mix indicates several categories of benefit. Local and regional access providers can exchange customer traffic. A large transit network can offer a nearby interconnection option. Root-server and AS112 services can answer particular DNS-related traffic locally. Content systems can serve cached entities. These functions do not equal a complete local internet, and a surviving exchange does not guarantee access to services hosted elsewhere. The right public claim is that TahoeIX can preserve the subset of traffic for which both endpoints, routes and required service components remain reachable through the local fabric.

That subset can still be consequential during an emergency. Cal OES’s Caldor findings show the public-safety cost of communications outages and incomplete outage visibility. A local exchange can help only if emergency-facing networks participate, if their critical prefixes are accepted, if authentication and upstream dependencies do not sit beyond the failed path, and if power survives at every required node. A county website cached elsewhere, a cloud dispatch application or a voice service whose control platform is distant may remain unavailable even while local BGP sessions are healthy.

This is why public-sector continuity should be tested service by service. Identify a small set of regional functions that ought to work during a transport isolation event: local government information, hospital-to-provider traffic, school or library systems, emergency coordination, authoritative DNS, or an operator status page hosted inside the region. Trace every dependency, including identity providers, certificate validation, DNS, time synchronization and content origins. Then test from two member networks while the chosen external route is unavailable.

The same exercise should measure what fails safely. If a local service cannot operate without a distant dependency, operators should know before an incident and publish an alternate access method. If TahoeIX cannot carry traffic between two agencies because one is not a entity, that is a membership gap, not an exchange outage. If both agencies attach through one carrier corridor, that is a transport-concentration problem. Precise attribution prevents a small cooperative exchange from being blamed for failures outside its boundary while also revealing where collaboration can improve continuity.

The exchange’s greatest public value may therefore be coordination. TahoeIX already convenes operators who otherwise compete. It can define regional failure scenarios, align contact trees, encourage accurate route registration, identify common transport risks and make local service dependencies visible. That work is less glamorous than a new 10G port, but it is what turns a collection of connections into a community capability.

The evidence that would turn TahoeIX into proven resilience

TahoeIX does not need to publish sensitive fiber coordinates or promise carrier-grade service it cannot fund. It does need a compact, dated proof package that separates what is installed from what has been tested. The current public evidence is strong enough to justify the effort: AS63212 and its peering subnets are established; two Reno facilities are named; independent observers see a live entity surface; the exchange publishes route servers, port labels and traffic graphs; and the regional hazard case is undeniable.

The first element should be a physical dependency statement. It would name the active switch and route-server location at each site, state whether the inter-site fabric uses one or more paths, describe path diversity at a non-sensitive corridor level, identify whether entrances and optical terminals are independent, and disclose which organization owns and repairs each segment. It should state whether downtown traffic can continue locally when Airway, the inter-site transport or a route server is unavailable.

The second should be a power and access statement. For each location, TahoeIX should publish whether its equipment is on UPS and generator-backed power, the last transfer-test month, a conservative runtime class rather than a precise fuel inventory, and the remote-hands and after-hours access arrangement. Members should perform the same exercise for the aggregation nodes that feed their exchange circuits. An exchange cabinet with excellent backup power cannot compensate for an unpowered member radio, roadside cabinet or optical amplifier.

The third should be a current operational roster and capacity statement. It should reconcile the 11-, 12-, 14- and 15-entity public views, distinguish active sessions from configured records, and explain what the aggregate port total includes. Capacity should be labelled as port, fabric, inter-site, normal traffic, surviving traffic and tested headroom. The absence of an SLA can remain explicit; best effort is more trustworthy when the effort and limits are visible.

The fourth should be a repeated failure exercise. At minimum, TahoeIX and volunteer members should test loss of Route Server 1, loss of the inter-site path, loss of the Airway switching function and loss of one member’s primary regional transport. For each event they should record route convergence, packet loss, latency, sustained throughput, prefixes still reachable, services that stayed local, manual actions and recovery time. A sanitized result can protect network security while proving that the exercise occurred.

The fifth should be a corrective-action cycle. If the test shows that most Tahoe-area entities share one corridor, the answer may be a second carrier, a microwave path, a different road alignment, a second local service location or a bilateral relationship that bypasses the failed component. If the bottleneck is power, the answer may be longer battery runtime or a generator agreement. If it is route policy, the answer may be better RPKI and registry hygiene. If no economically reasonable fix exists, the limitation should be stated plainly so users can plan an alternate service.

On the public record available in July 2026, TahoeIX merits a strong network-evidence grade and only a conditional resilience claim. It is a real exchange with durable number resources, visible peers and two Reno attachment points. It plausibly lowers latency, reduces some transit dependence and keeps a meaningful subset of regional traffic local. What it has not yet shown publicly is that members reach it over paths independent of the mountain transport, facility power and shared infrastructure risks it is supposed to mitigate.

That is not a verdict against a small exchange. It is a precise next step. TahoeIX’s most valuable demonstration would be a modest one: during a controlled Sierra-route interruption, two regional networks continue exchanging useful traffic in Reno, the surviving path has measured headroom, and operators can explain why the failed route, power domain or facility did not take both sides with it. Once that result is repeatable, “keep traffic local” becomes more than a normal-day routing benefit. It becomes evidence of regional continuity.