YEGIX Has Two Route Servers but Only One Publicly Listed Edmonton Site

Summary

• YEGIX has a credible live-network footprint in Edmonton, but public records identify only one exchange facility and do not demonstrate independently routed member access.
• Two route servers, route filtering and published port speeds strengthen operations, yet none of them proves a second switching site, measured traffic headroom or facility-level failover.
• The exchange becomes demonstrably resilient only when YEGIX and its members can show diverse physical paths, current operating capacity and a maintained recovery practice.

An Edmonton Packet Meets the City Before It Meets the Internet

Imagine a packet leaving a public library branch in Edmonton for a service hosted by another local network. The desirable trip is short: from the library’s network to its metro connection, into the YEGIX switching fabric, across a peering relationship, and out to the destination network. That is the practical promise behind the exchange’s own explanation of local interconnection on the YEGIX home page. It is also the policy case made by CIRA’s current guide to Canadian IXPs: networks can exchange appropriate traffic in Canada rather than automatically buying a longer path from a transit provider.

But “local” is not a property bestowed by an Edmonton IP address. It is the outcome of several independent decisions. The origin network has to select a YEGIX route. Its router has to remain powered and connected. Its fibre has to arrive at the exchange building. The exchange switch and the destination port have to work. A bilateral BGP session or the route-server path has to carry valid reachability information. The destination network then has to prefer and return that local route.

If any of those conditions fails, ordinary routing policy may move the packet to paid transit, possibly through another city or country, even though both endpoints remain in Edmonton.

There is a sound historical reason to care. A 2016 CIRA account of Packet Clearing House measurements reported that 64 per cent of the Canadian-to-Canadian traceroutes in that study crossed the United States. That finding is neither a current measurement of YEGIX nor proof that an Edmonton packet now leaves Canada. It is useful for a narrower point: geography and routing policy can diverge, and local exchange capacity matters only when networks actually use it. CIRA’s older local-peering explanation similarly describes the potential for lower latency and transit cost. Potential is the operative word.

The regional case also predates the exchange’s present roster. The Alberta Broadband Toolkit identifies YEGIX in Edmonton and YYCIX in Calgary while warning, in effect, that reaching an Alberta exchange is a network-design problem for communities outside the major centres. A Cybera digital-infrastructure report likewise places YEGIX among Alberta’s exchange assets. Neither document maps the ducts, leased waves or carrier circuits used by today’s members.

That distinction frames this assessment. YEGIX has enough network-resource evidence to be treated as operating infrastructure: an autonomous system, exchange prefixes, a published fabric, route servers and named entities. The unresolved issue is independence. A local exchange can reduce distance while still concentrating risk if most members enter the same room over related routes, if one switch remains the common data-plane junction, or if a small volunteer group carries all operational knowledge. The packet’s short logical path may therefore contain a long chain of physical and institutional dependencies.

The Company, the Fabric and the Facility Are Different Things

YEGIX Internet Exchange Community Ltd. describes its purpose as providing not-for-profit electronic infrastructure for Alberta-based networks and users. Its corporate-objectives page also names three directors, a network manager and a network operator. That is meaningful evidence of an organized community operator, but the page carries no visible resolution date, term dates or succession rules. It shows who the website identifies; it does not by itself establish the present legal standing of every office or the depth of the maintenance bench.

The network-resource boundary is clearer. ARIN’s RDAP record for AS62502 associates the autonomous system with YEGIX Internet Exchange Community Ltd. Separate ARIN records cover the exchange’s 206.53.140.0 IPv4 resources and 2001:504:46:: IPv6 resources. These registrations are strong evidence that YEGIX controls identifiable Internet number resources. They do not reveal switch inventory, rack power, fibre routes, spare parts, live BGP sessions or traffic load. An ASN is an administrative and routing identity, not a resilience certificate.

PeeringDB’s YEGIX organization record connects the legal name to the exchange and route-server records. The operator’s practical remit appears to cover exchange policy, the shared Ethernet fabric, route servers, monitoring and entity coordination. A entity, however, still owns or controls its router, its peering policy and the circuit that reaches the exchange. YEGIX is not presented as the general transit provider that carries a member’s traffic to the rest of the Internet.

The building boundary belongs to Wolfpaw. The published YEGIX–Wolfpaw memorandum assigns YEGIX half a rack and power for exchange equipment, while Wolfpaw controls cabling within the facility and retains services such as colocation, VLAN management and off-switch private peering. It also describes a no-charge cable or fibre for qualifying Wolfpaw customers and non-discriminatory list pricing for cross-connects. The document states an initial period from 2015 through 2025 and refers to subsequent five-year periods, but a reader cannot use that wording alone to verify present performance, amendments, termination rights exercised, or the condition of the hosted equipment.

The YEGIX participation rules define yet another boundary. Members must use BGP, respect limits on MAC addresses and avoid harming the shared fabric. Traffic can be forwarded between entities only with permission, and the published version says there is no mandatory multilateral peering agreement. These rules govern conduct on the exchange; they do not force any network to advertise all local routes, accept every other member’s routes or maintain two physical connections.

This separation matters during failure. If the route server distributes a bad route, YEGIX has a control-plane problem. If the shared switch fails, YEGIX has a data-plane problem. If power or access to the room fails, YEGIX and Wolfpaw must coordinate. If a entity loses its metro circuit, the repair sits with that entity and its carrier even while the YEGIX equipment remains healthy. A credible continuity claim must name those boundaries rather than compressing the company, facility and connected networks into a single box called “the exchange.”

The Public Map Converges on One Downtown Room

YEGIX’s progress and status page says the exchange selected Wolfpaw in downtown Edmonton, installed a switch, route servers and out-of-band management equipment there, obtained AS62502 and brought its first peers online. This is the clearest operator account of the physical start. It describes one selected location, not a distributed switching platform.

The independent interconnection record points to the same place. PeeringDB’s exchange entry lists one local facility: Wolfpaw Edmonton 1. The associated facility record places Wolfpaw Edmonton 1 at Scotia Place II, 10060 Jasper Avenue, Edmonton, and lists YEGIX as its sole local exchange. The facility page was updated much more recently than the exchange’s top-level profile, but neither record lists a second YEGIX site. Euro-IX’s IXP Database profile also places YEGIX in Edmonton, although its sparse and older fields are not useful evidence of present topology.

Names have shifted around the address. Wolfpaw’s material calls Rice Howard Place the former Scotia Place, while PeeringDB retains Scotia Place II. That looks like a building-name transition rather than evidence that the exchange moved, but the public material does not supply a dated YEGIX rack location statement that reconciles every label. Precision should stop at the publicly identified facility and street address; it should not extend to a guessed room, floor, meet-me area or cable path.

Wolfpaw’s Edmonton data-centre page advertises three facilities and says YEGIX is hosted on its Edmonton platform. For EDM 1, the page markets features including A and B cabinet power, redundant UPS, multiple carriers, cooling, generator support and round-the-clock monitoring. These are facility-owner claims, not measurements of the exact YEGIX feed or proof that both feeds terminate on independent power supplies inside YEGIX equipment. PeeringDB, notably, leaves diverse serving substations undisclosed for Wolfpaw Edmonton 1.

Wolfpaw also publishes an Edmonton fibre-ring page naming several points of presence, including Rice Howard Place, other downtown buildings, west Edmonton and an Alberta SuperNet location. It describes physically diverse segments, multiple vendors and services from 1 to 100 Gbps. This demonstrates that metro diversity can be purchased or engineered in the surrounding environment. It does not demonstrate that YEGIX has switches at those points, that every YEGIX member buys two paths, or that two apparently diverse services avoid the same entrance conduit near the exchange.

The defensible map is therefore modest. YEGIX’s publicly listed switching presence converges on Wolfpaw Edmonton 1 in downtown Edmonton. A wider fibre ecosystem surrounds that room, but the published materials do not trace member access circuits or show a second exchange node. No exact metro route should be drawn from a list of fibre-ring locations. For resilience, the missing map matters as much as the visible pin: without member-specific entrance diversity and exchange-site separation, one cannot tell whether independent networks remain physically independent on their last kilometres into the fabric.

Member Reach Is the Real Metro-Redundancy Test

YEGIX’s connection FAQ makes the access requirement plain. A entity needs its own ASN and has to extend its network into the Wolfpaw premises. On-site cross-connects are arranged through the facility, and the page describes supported port options ranging from lower-speed Ethernet through 1 and 10 Gbps interfaces. That is an understandable entry path for a community exchange. It also means the exchange’s resilience begins outside its rack.

Consider two members that each order a service described as diverse. Their carriers may use different commercial products while leasing strands in the same conduit. Their paths may approach downtown from different directions but merge at one bridge, manhole, building entrance or meet-me room. A entity may have two upstream Internet providers but only one lateral connection to Wolfpaw. Conversely, one member may build genuinely separate approaches and still face the common YEGIX switch once both circuits reach the room.

“Two providers,” “ring,” “A/B” and “redundant” describe useful designs, yet none is a substitute for a route-level failure-domain statement.

The Wolfpaw fibre-ring claim shows that multiple facilities and vendors are available around Edmonton. The YEGIX memorandum shows that cabling inside the facility remains Wolfpaw’s domain, while YEGIX bears responsibility for connectivity outside the facility when building the exchange. Public records do not show that YEGIX has extended its fabric to Wolfpaw’s other data centres. They also do not disclose which entities arrive over Wolfpaw’s ring, over a carrier wavelength, over city-owned fibre, through a colocated router, or through a single cross-connect.

That gap has operational consequences. If a construction cut severs a shared downtown approach, members riding that approach may lose YEGIX at once even when the exchange rack is fully powered. Their BGP sessions should fall, and their routers may restore reachability through transit. The applications may remain available, but paths could become longer, more expensive or geographically different. If the affected circuit also carries the member’s transit, the outcome can be much worse. YEGIX cannot determine that outcome on its own; each member’s routing and transport design does.

The right test is not whether a map contains two coloured lines. It is whether failures can be injected or observed without removing both access paths. A strong member record would identify two demarcations, two building entrances where available, distinct carrier or strand ownership, and the shared-risk link groups that remain. It would state whether both links are active, whether BGP runs across each, and what happened in the most recent maintenance or cut. Sensitive route detail need not be published at street level. An exchange can report diversity classes and tested outcomes without exposing security-sensitive coordinates.

Until such evidence appears, YEGIX should be described as locally situated rather than metro-diverse. Edmonton networks can reach a local switching fabric, and the surrounding carrier market offers choices. What cannot yet be shown publicly is that the community reaches that fabric over sufficiently independent paths to preserve local exchange during a meaningful metro failure.

Two Route Servers Do Not Make Two Exchanges

The strongest visible redundancy inside YEGIX’s control plane is the pair of route servers. The official peer table assigns AS62502 two addresses near the top of the IPv4 exchange range and two corresponding IPv6 addresses, with each server shown at 1 Gbps. PeeringDB’s AS62502 record identifies the network as “YEGIX Route Servers,” names the AS set used for clients and says the servers apply RPKI origin validation to reject invalid announcements. YEGIX’s news page records a 2020 replacement with two Dell servers plus a separate routing-analysis machine.

That is useful engineering. A entity can establish sessions with both servers so that loss of one route-server process or host need not eliminate all multilateral route distribution. YEGIX also says strict filters based on routing registries and PeeringDB, including RPKI-invalid rejection, were introduced in 2020. Those controls reduce certain route-leak and invalid-origin risks. They do not make route distribution risk-free, and they do not carry the packets exchanged between members.

The technical distinction is explicit in RFC 7947: an exchange route server brokers BGP reachability information and generally does not insert its own AS into the forwarding path. RFC 7948 explains why route servers reduce the administrative burden of maintaining a full mesh of bilateral sessions, while emphasizing careful operation, filtering, monitoring and client policy. RFC 7454 provides the broader BGP operations and security practices to which route-server operators must attend.

Two servers can still share one switch, one rack power event, one out-of-band path, one configuration error or one operator action. Public records do not say whether the YEGIX pair uses separate power supplies, separate rack units, different software versions, staggered maintenance, independent management paths or configuration rollback that has been exercised. Nor do they say whether both servers sit behind the same exchange port or switching component. “Two” is an inventory count, not a complete failure-domain description.

Members also retain a choice. YEGIX’s published rules do not compel a single multilateral arrangement, and PeeringDB labels at least one listed network as not using the route server in the Internet Society snapshot. Bilateral BGP sessions can preserve selected peerings during a route-server incident, provided the shared Ethernet fabric remains available and both parties configured them in advance. That makes bilateral sessions a control-plane alternative, not a second data plane.

The distinction matters when diagnosing an outage. If one route server fails and clients remain on the other, packet forwarding can continue. If both route servers fail, bilateral sessions may continue while multilateral reachability disappears. If the exchange switch fails, neither bilateral nor route-server sessions can move traffic across that fabric. If the facility fails, all equipment in the room is at risk. The pair of servers is therefore evidence of thoughtful control-plane redundancy, but it cannot answer the larger question posed by YEGIX’s one publicly listed site.

Port Speed Is Not the Same as Capacity a Packet Can Use

PeeringDB currently summarizes YEGIX as nine peers, 11 connections and 93 Gbps of total speed. The arithmetic is visible in its port list: several 10 Gbps entries, two 10 Gbps Edmonton Transit Service connections, a 20 Gbps Wolfpaw entry, 1 Gbps for AS112 and two 1 Gbps route-server entries. This is useful installed-port evidence. It is not a statement that 93 Gbps of member-to-member traffic can traverse the exchange continuously, survive a failure or reach every pair of entities.

The Internet Society Pulse profile illustrates the definition problem. Its 2026 snapshot describes eight ASNs and 92 Gbps, explicitly treating capacity as the cumulative speed of member ports. The one-gigabit difference from PeeringDB’s headline is consistent with a different choice about whether to count the AS112 service, while the peer count depends on whether infrastructure ASNs are treated as members. This is not evidence of an outage. It is evidence that the numerator and population must be defined before a capacity figure is repeated.

YEGIX’s own peer page presents a larger roster than PeeringDB, including several educational and network organizations not in the third-party table and a 3-by-10-Gbps Netskrt entry. Its status column uses the word “open” for entities and “active” for route servers, but the page does not define whether “open” means an operational port, an open peering policy, or another condition. Summing that page would produce a much higher nominal number, yet such a sum would mix unclear status with advertised interface rates. It would be less honest, not more current.

The aggregate graph page confirms that YEGIX publishes daily, weekly, monthly and yearly traffic images. That is valuable operating evidence because a changing graph indicates measurement and traffic activity. The page text, however, does not expose a durable table of peaks, averages, sampling method, missing intervals or per-failure capacity. A visual line cannot establish the usable headroom remaining after loss of a switch link or entity port, especially when the switching chassis and uplink architecture are not published.

Installed, lit, operational and usable capacity are separate states. A 10 Gbps port may be installed but idle. It may be operational while the member advertises only a small set of routes. It may carry substantial traffic yet have no alternate path. Total port speed also counts both sides of exchanges of traffic and does not reveal the switch backplane, oversubscription, packet-size performance, buffer behavior or maintenance reserve. Route-server ports mostly carry BGP messages and management traffic, not member payload at their nominal aggregate rate.

The responsible conclusion is bounded. YEGIX has multiple operationally described Ethernet connections, with a current PeeringDB headline of 93 Gbps and a 2026 Internet Society snapshot of 92 Gbps under a member-only convention. Public evidence does not disclose sold or reserved capacity, measured peak traffic in machine-readable form, switch forwarding limits, powered spare ports, failure-condition throughput or a capacity trigger for upgrade. Those unknowns prevent a defensible claim about usable capacity, but they do not erase the strong evidence that a live exchange fabric exists.

The Membership Evidence Does Not Reconcile Cleanly

Membership is the economic and operational substance of an exchange: a switch with no useful counterparties creates no local path. YEGIX’s official table currently names AS112, Axia Connect, Cybera, Edmonton Public Library, Edmonton Transit Service, Hurricane Electric, Hiperfi, Hybrid Wireless, MCSnet, MacEwan University, Netskrt, NorQuest College, the University of Alberta, Wolfpaw and two YEGIX route servers. Its news chronology records additions through Netskrt in June 2025, after Hiperfi in 2024 and Hybrid Wireless and NorQuest College in 2023. That chronology is a positive sign of continued attention.

PeeringDB shows a smaller set: nine peer records when infrastructure entries are included. Internet Society Pulse, deriving its view from PeeringDB, reports eight ASNs in its indexed 2026 snapshot. Euro-IX’s older profile reports no useful current member count. These sources are not necessarily contradicting the state of the wire at the same instant. They may apply different definitions, update schedules and participation requirements.

An organization can remain named on an exchange page while failing to maintain its PeeringDB entry; a reserved or configured port may not have a live BGP session; an infrastructure service may be included in one count and excluded from another.

The problem is not that one table must be wrong. The problem is that none supplies the timestamped session evidence needed to reconcile them. A current roster should distinguish organization, ASN, physical port, configured state, live state, route-server participation and last verification. It should explain whether multiple ports belong to one member and whether a named service such as AS112 is included in headline membership. That would allow readers to reproduce both member and connection counts without inferring activity from a marketing word.

There are also positive signals within the discrepancy. The official roster includes IPv4 and IPv6 addresses for many entries. PeeringDB exposes two ETS connections and two YEGIX route-server connections. Pulse reports seven of eight listed ASNs using the route server and six of eight with RPKI coverage in its snapshot. These details are too structured to look like a mere aspirational announcement. They support a medium-to-strong conclusion that YEGIX remains network-active, while leaving the exact present roster uncertain.

Unofficial route views and commercial ASN pages can suggest that AS62502 and the exchange addresses remain visible, but they cannot settle member status. A route collector may see a prefix while a entity’s local cross-connect is down; a cached company page may survive after a topology change. The decisive evidence would be a dated YEGIX export of configured and operational ports, ideally accompanied by aggregate BGP-session counts and a clear update cadence.

This is more than a disclosure nicety. Operators deciding whether to build into YEGIX need to know which counterparties are actually reachable, at what port rates and under what policies. Public institutions need to know whether a local path is an actively maintained route or a historical possibility. A clean, timestamped roster would convert several reasonable signals into a current operating fact.

Public Institutions Raise the Stakes but Not the Scope of the Claim

YEGIX’s published lists include Edmonton Public Library, Edmonton Transit Service and post-secondary institutions. Edmonton’s Digital Action Plan describes a city fibre network connected with the LRT system, post-secondary institutions, libraries, sensors and public Wi-Fi. That context shows why local interconnection can matter beyond commercial web delivery: municipal and educational networks support communications used by residents, staff, research systems and public places.

It would be a mistake, however, to turn a peering connection into a claim that YEGIX operates those public services. The exchange provides a place where participating autonomous systems can exchange selected traffic. The city, library, transit service, universities, application providers and their carriers remain responsible for their own networks and services. A YEGIX outage does not necessarily stop a bus, close a library system or disconnect a campus. Properly designed entities retain transit and other paths, and only traffic that preferred YEGIX must reconverge.

The likely effects are graduated. Loss of a local peering path can increase latency, transit consumption or the distance travelled by traffic. It can change which jurisdiction a route crosses. It can remove a direct path to a content or network partner while leaving general Internet access intact. Only if the entity has coupled its YEGIX circuit to a broader single failure domain, or lacks working alternatives for a necessary destination, does exchange loss become a service outage. Public evidence does not describe those entity-by-entity designs.

That is why continuity claims should be phrased around routing, not civic outcomes. YEGIX can help local networks preserve local paths, reduce dependence on distant transit and diversify interconnection choices. It cannot guarantee that all Edmonton public-sector traffic stays in Edmonton or Canada. BGP policy, destination membership, return routing and failures all influence the path. The historical Canadian measurements and Alberta reports establish the value of more local peering; they do not measure today’s routes between the named YEGIX entities.

For public institutions, the useful assurance would be a joint test. A member could withdraw or disable its primary YEGIX access path, observe whether a diverse secondary exchange path remains, then confirm that transit reconvergence works when the entire exchange is unavailable. Results could report convergence time and affected route classes without disclosing sensitive addresses. That would show what YEGIX contributes to continuity while respecting the boundary between the exchange and the public services connected to it.

Every Failure Has a Different Radius

A single label such as “YEGIX outage” hides several events with very different consequences. Start at the member edge. A failed router, optic or cross-connect removes that member’s port. Other entities can continue exchanging traffic, while the affected network falls back to whatever routes it has prepared. If the member’s YEGIX and transit circuits share the same chassis or fibre approach, the radius expands beyond peering. That shared risk belongs to the member design even though it appears at the exchange demarcation.

A metro fibre cut can remove several members together. Wolfpaw’s ring claims multiple vendors and diverse paths, but there is no public mapping between those paths and YEGIX entities. The cut may therefore affect one circuit, a carrier group or the common building entrance. Restoration depends on the carrier, splice access, winter conditions, permits and the availability of an alternate lit path. YEGIX can coordinate and communicate, but it cannot splice a carrier’s cable simply because the traffic was headed to its switch.

A switch or line-card failure is more central. The rules characterize the service as a shared switched Ethernet LAN. Public material does not identify a second production switch, a dual-fabric design or a second site. If all member ports terminate on one chassis, a chassis event can remove every peering session at once. If there are hidden redundant components, their value cannot be assessed without knowing which failure domains they separate and whether failover has been tested. The cautious assumption is not that no redundancy exists, but that none beyond the published route-server pair is demonstrated.

A route-server failure has a narrower control-plane radius. One of two servers can fail with clients remaining on the other. Loss or misconfiguration of both can remove routes learned through them while bilateral BGP sessions persist. Bad filters can reject valid routes; permissive filters can distribute unwanted ones. The route servers’ stated RPKI-invalid rejection is a useful safeguard, yet route validity is not the same as route desirability. Change review, staged deployment and rollback remain necessary.

A facility event reaches every device in the room. Utility loss, UPS or generator trouble, cooling failure, fire suppression, water, physical access, security restrictions and building evacuation can all matter. Wolfpaw advertises redundant facility systems and round-the-clock support, but YEGIX does not publish the exact power chain for its equipment or a recent failover result. A and B cabinet feeds add little if a single-corded switch uses one feed, while dual supplies add less if both trace to a common upstream component.

Finally, there is organizational failure. Certificates, domains, ARIN fees, firmware, filters, spare hardware and emergency contacts all require people and money. The YEGIX news history documents donations of fees, equipment, rack space, power and volunteer effort. Community support is a strength; concentration of knowledge or funding is a risk if no succession and maintenance reserve exist. Unlike a fibre cut, this failure can develop quietly until a renewal, upgrade or incident is missed.

Who is affected depends on which layer breaks. One member may lose a preferred path; a group may lose metro access; all peers may lose the shared fabric; or route-server clients alone may lose convenient reachability. End users may notice nothing, a latency increase, degraded performance or a complete service loss. No public source supports a single universal consequence. The exchange’s resilience should therefore be reported as a matrix of components, alternatives and tested outcomes, not as one uptime percentage.

Recovery Is a Community Operation, Not Just a Spare-Parts Exercise

YEGIX has several signs of operational continuity. Its status history records remote out-of-band management from the initial installation. The news page documents route-server replacements, graph maintenance, filtering changes and recurring donations for number-resource and domain fees. The current website names network operators as well as directors. These facts show that people have maintained the service over years rather than merely announcing it once.

What is not public is a recovery objective. There is no stated time to restore the switching fabric, no current hardware inventory, no declared cold or hot spare for the YEGIX switch, no incident archive, no maintenance calendar and no test showing operation from another facility. Wolfpaw advertises cold spares for its own switching network, but that claim should not be transferred to YEGIX equipment without an explicit statement. Facility support and exchange repair are related responsibilities, not interchangeable ones.

Recovery begins with detection. Port and traffic graphs can reveal a fall, route-server sessions can show control-plane loss, and out-of-band access can allow diagnosis when the production LAN is unavailable. It then requires authority: someone must know whether to disable a port, roll back a filter, replace an optic, request a cross-connect check or enter the facility. The published rules let YEGIX disconnect harmful ports, but they do not describe escalation, peer notification or who can approve emergency change when a primary operator is unavailable.

The next requirement is a known-good state. Route-server configurations, prefix filters, switch configuration and contact lists should be backed up and reproducible. A second route server protects against a host failure only if its configuration is independently usable and operators can resist propagating a bad change to both. A spare switch helps only if firmware, optics, configuration, console access and cabling plans are ready. A second site helps only if members have reachable ports there and routing policy makes the alternate path real.

Community finance belongs in the same plan. YEGIX says the first port is free and management has been a volunteer effort. That lowers the barrier to local peering, but replacement hardware, audit work, facility access and emergency labour still cost money. Public donation records demonstrate generosity; they do not disclose a maintenance reserve or a multi-year capital plan. Sustainable independence means the operator can fund an unglamorous replacement before failure, not merely attract a donation afterward.

The most persuasive next step would be a compact annual resilience report. It could state the number of production sites, switches, powered ports and operational member sessions; summarize route-server and switch maintenance; describe whether backups were restored; record the duration and scope of significant incidents; and give the board and operations succession status. None of that requires publishing exploitable rack detail. It would show that the community’s institutional capacity is maintained with the same seriousness as its BGP configuration.

What Would Make YEGIX Demonstrably Independent

YEGIX already clears the first evidentiary threshold. The legal name recurs across its site, ARIN and PeeringDB. AS62502 and dedicated IPv4 and IPv6 exchange space are registered. Public tables expose member addresses and port rates. Two route servers are identified, routing-security controls are described, traffic graphs are published, and a named Edmonton facility hosts the exchange. That combination supports a strong network-resource finding and a credible conclusion that the exchange has operated beyond its 2015 launch.

It does not clear the independence threshold. Only one facility is publicly listed. The surrounding fibre ring is a facility-provider service, not proof of a multi-site YEGIX fabric. Member routes into the room are not disclosed even by diversity class. Port-speed totals differ by definition, the official and third-party rosters do not reconcile, and no public measurement shows usable capacity after a component loss. Two route servers reduce one control-plane risk while apparently remaining exposed to the same site and shared data plane.

Five disclosures would change that assessment. First, publish a dated topology statement: number of exchange sites, number and role of production switches, and whether any inter-site links carry the peering LAN. Second, publish a roster that separates configured, operational and route-server-active connections. Third, define capacity: member-port sum, switch forwarding limit, observed peak, upgrade threshold and post-failure headroom. Fourth, report access diversity in non-sensitive classes, including whether members can enter through independent facilities or physical approaches.

Fifth, publish a short annual operations record covering incidents, maintenance, recovery tests, spares and succession.

Routing security should remain part of the work. Internet Society Pulse says YEGIX was not participating in the MANRS IXP programme in its 2026 snapshot, while also reporting substantial RPKI use among listed members. The MANRS routing-security material describes route-server filtering, transparency and member information as mutually reinforcing practices. Non-participation is not proof of unsafe routing, and joining a programme would not prove physical resilience. A published explanation of existing controls and verification would be more valuable than a badge alone.

The decisive physical improvement would be a genuinely separate switching location that members can reach without traversing the first. It would need independent facility power and access, a protected inter-site design, clear behavior during partition, and enough member adoption to be useful. Merely placing a second switch elsewhere does not help a entity whose two circuits share the same downtown path. Likewise, a diverse member path does not preserve peering when both ends terminate on one failed chassis. Independence must exist on both sides of the demarcation.

For now, the most accurate description is neither “unproven project” nor “resilient metro exchange.” YEGIX is a real Edmonton community exchange with identifiable resources, a long operating history and valuable public-sector and network entities. Its public topology still converges on one listed facility, and its exact live membership and failure-condition capacity remain uncertain. The next level of credibility will come from showing that a packet can survive the loss of a route server, switch path, facility path and key operator without abandoning the local exchange. Locality is where the equipment sits.

Infrastructure independence is what remains working when one path no longer does.