YYC Net Lab and the registry evidence behind a network-lab identity

Summary

• YYC Net Lab's strongest public identity is a Calgary/Alberta network-training organization rather than a conventional cloud platform or access provider. Its own site emphasizes cost-effective CCNA training through Cisco Networking Academy, instructor-training products, course checkout, account login, contact intake and an Alberta not-for-profit mission.
• AS396302 gives the organization a real network-resource anchor, but the route evidence is deliberately narrow. PeeringDB records describe an educational/research network with one IPv4 prefix, one IPv6 prefix, a mostly inbound 0-20Mbps profile, YYCIX presence and a "primarily IPv6" note, while BGP.Tools and Hurricane Electric show current or recent global-route visibility limits.
• The operating question is synchronization, not scale: course enrollment, payment, account access, physical lab scheduling, instructor support, Cisco/NetAcad course activation, ARIN-derived contacts, PeeringDB fields, YYCIX exchange details and route status all need to stay fresh enough for learners and network operators to know what boundary they are dealing with.
• The main risks are registry-only ambiguity, lab-versus-service confusion, stale contact and address records, dormant-route interpretation, unsupported service claims, data-locality uncertainty and support capacity that cannot be measured from public pages alone.

The name is a clue, not a service guarantee

YYC Net Lab sounds like a place where networks are learned, tested and made visible. The public evidence supports that reading more than any broader infrastructure-service story. The organization's homepage says YYC Net Lab offers cost-effective CCNA training through the Cisco Network Academy program. Its About page says the mission is to encourage personal development in computer networking by giving Alberta residents cost-effective access to training, and it describes the organization as an Alberta-registered not-for-profit.

The site presents course collections, an online store, a login surface, a cart, a contact form and a small body of technical education material. That is a concrete public surface, but it is not the same thing as a cloud platform, a commercial transit network, a managed service provider or a public internet access operator.

This distinction matters because the assigned operating question is about records. YYC Net Lab is visible in at least two worlds. In the education world, it has course records, learner records, instructor-training records, contact records, payment or checkout records, and possibly handoffs into Cisco Networking Academy systems. In the network-resource world, it has AS396302, ARIN-derived identity, PeeringDB data, a YYCIX exchange point, an IPv4 exchange address, an IPv6 exchange address, public AS-set references and third-party BGP pages. The two worlds reinforce each other only if the boundary is understood.

A learner buying CCNA course access should not infer internet-service resilience from AS396302. A network operator seeing AS396302 should not infer a large transit network from the course catalogue. A reader seeing "Net Lab" should not infer that every training, routing and support record is automatically synchronized.

The company is therefore best understood as a network-lab and registry-boundary record. That phrase is less glamorous than "cloud service," but it is more useful. The evidence shows a public educational mission tied to networking practice and a public autonomous-system identity tied to Calgary interconnection. It also shows several limits. The course surface is not a measured learning outcome. The cart is not proof of successful enrollment. The contact form is not proof of support response. The PeeringDB entry is not proof of live traffic. The BGP summaries are not proof of current global reachability.

The ARIN-derived displays do not all agree on address freshness. The correct article is therefore not a review and not a promotion. It is an audit of what the public records can support.

That audit has a simple structure. First, the public training business has to be read on its own terms: courses, labs, accounts, contact and local learning support. Second, the autonomous-system record has to be read on its own terms: registration, PeeringDB, YYCIX, prefix counts, route visibility and contact governance. Third, the overlap between those surfaces has to be kept honest. Network education becomes more credible when it is attached to real network-resource literacy; network-resource evidence becomes more legible when the operator explains its educational purpose. But neither surface proves the other.

The training surface is the public operating center

YYC Net Lab's site is built around courses. The top navigation separates free beginner courses, certification courses, CCNA courses and courses for instructors. The CCNA collection shows three courses priced at $250.00 CAD each: Introduction to Networks; Switching, Routing, and Wireless Essentials; and Enterprise Networking, Security, and Automation. The certification collection adds IT Essentials, also at $250.00 CAD. The free beginner collection shows Cybersecurity Essentials, NDG Linux Essentials, NDG Linux Unhatched and Networking Essentials at $0.00 CAD.

The instructor-training collection is more expensive: four instructor-training products at $500.00 CAD each, covering Network Security and the three CCNA course segments.

Those records matter because they define the service that a learner or instructor actually experiences. A course is not only a web page. It is a bundle of prerequisites, course access, content activation, simulation tools, physical-lab or exam access, learner support, mentor advice, checkout, cancellation or fulfillment terms, and identity handoff into a broader education platform. YYC Net Lab's CCNA course pages make several of those dependencies visible.

The first CCNA course says learners begin preparing for a networking career by studying network architectures, models, protocols and elements, and that they build simple local area networks. It lists skills such as configuring routers and switches, IPv4 and IPv6 addressing, Packet Tracer practice, real equipment and troubleshooting small-network connectivity. It describes a 70-hour course.

The second CCNA page focuses on switching, routing and wireless essentials. It emphasizes small-to-medium business networks, WLANs, VLANs, inter-VLAN routing, redundancy with STP and EtherChannel, Packet Tracer, dynamic addressing and first-hop redundancy. The third CCNA page moves into enterprise design, security, operations, troubleshooting, WAN technologies, quality of service, secure remote access, software-defined networking, virtualization and automation. Its skills list includes OSPF, access-control lists, Packet Tracer, virtualization, SDN, APIs and configuration-management tools.

These are course claims rather than company-operations claims, but they explain why YYC Net Lab belongs in a technology monitoring frame. The organization is not merely reselling generic videos. Its catalogue is pointed at network operation, automation literacy and hands-on troubleshooting.

The course pages also expose the boundary between online and physical records. They say the CCNA curriculum is delivered as online self-study modules, while quizzes and practice exams are run using simulation software provided with the course. They say final exams are conducted on physical equipment, with locations and available times to be posted during the course. They also say early enrollment gives instant access to course material and that a learner can ask an instructor to activate an exam early. Certification exams themselves are described as Pearson Vue processes, with course mentors able to advise on local certification options.

That is a record-synchronization problem in plain sight. A learner who pays for a course needs the storefront order, course-material access, instructor activation, simulation environment, final physical-equipment schedule, local guidance and certification-exam boundary to line up. If any record lags, the educational service becomes confusing. The learner may have paid but not received access. The learner may have access but no visible exam schedule. The learner may be ready for a final but need instructor activation.

The course may prepare the learner for a Cisco certification path, but the actual certification exam sits outside YYC Net Lab's own store. The company's public value depends on how clearly those boundaries are explained and how reliably support resolves record mismatches.

The free-course surface adds a different layer. Networking Essentials is shown as free, intermediate and 70 hours. It is aimed not only at students but also at developers, data scientists, cybersecurity specialists and other professionals who want broader network knowledge. It lists skills such as planning and installing a home or small-business wireless network, connecting it to the internet, using Packet Tracer, verifying and troubleshooting connectivity, and recognizing home-network security threats. That is valuable local workforce training if it is actually supported. Public evidence can say the course is listed and priced at zero.

It cannot say how many learners complete it, whether mentoring is available, whether local support exists for every learner, or whether the listed free path remains available under the same terms after the access window.

The IT Essentials page further emphasizes the mix of simulation and physical practice. It describes computer fundamentals, networking, Cisco Networking Academy advanced simulation tools, multiple hands-on labs, troubleshooting, security-threat awareness, real equipment and CompTIA A+ preparation. It also displays a recurring or deferred purchase disclosure in the product flow. That detail matters less for the course topic than for the account surface.

If a product can involve deferred fulfillment or recurring payment language, the customer record must be especially clear about what is being purchased, when fulfillment happens, how cancellation works and which party resolves billing questions.

The public training surface, then, is operationally rich. It involves education, payments, course activation, account access, lab access, exam timing and human support. That is why the relevant automation topic is not abstract. The hard work is making the course state visible to the right person at the right time: learner, instructor, course mentor, store administrator and possibly external platform operator. Public pages show the parts. They do not prove the glue.

Account and contact records are the learner's control plane

The storefront mechanics are easy to dismiss as ordinary e-commerce. For a network training organization, they are more than that. YYC Net Lab's pages show login and cart links, product quantities, "add to cart" controls and Shopify footer language. The contact page exposes a simple form with name, email, phone number and comment fields. The course pages describe instant access after early enrollment and instructor-controlled exam activation. These are the public signs of the learner's control plane.

The word "control" is important. A student does not experience the organization as a static course catalogue. A student experiences it as a sequence of states: browsing, selecting, paying, receiving access, asking questions, taking quizzes, using simulation software, waiting for physical equipment time, requesting early exam activation, getting mentor advice, preparing for an external certification exam and resolving account or billing questions. Each state has a record. If the records agree, the course feels simple. If they do not, the student has to become the system integrator.

YYC Net Lab's About page says the organization generally uses a flipped classroom approach. That implies a particularly strong record burden. In a flipped classroom, learners do a substantial amount of preparation outside the live or hands-on session. The live support layer then depends on knowing what the learner has already seen, which module they are in, which quiz or practice exam they are approaching, and whether they need equipment access or instructor help. A flipped model can be efficient, but only when the course platform, learner communication and instructor attention stay aligned.

The instructor-training collection increases the stakes. Instructor accreditation is not just a purchase. It touches identity, eligibility, course completion, evaluation, platform access, institution affiliation and responsibility for teaching others. YYC Net Lab's homepage says it is a NetAcad Instructor Training Center offering CCNA instructor accreditation, and the instructor collection lists products for people who want to teach at a Cisco Network Academy. The article can state those public claims.

It cannot certify that a particular purchaser will become accredited, or that every credential boundary sits under YYC Net Lab's sole control. A prudent buyer would ask how the course purchase maps to Cisco Networking Academy instructor requirements, what records are shared, who confirms completion, and what happens if a learner's external account does not match the store order.

The contact page is modest, but its simplicity is revealing. Name, email, phone number and comment are enough for a first inquiry, not enough for a full course support system. That is not a criticism. It is a boundary. Public readers can see that a published contact points exists. They cannot see whether submissions create case numbers, whether responses are tracked, whether course questions are routed to instructors, whether billing questions are separated from technical questions, or whether urgent exam-access issues receive priority.

For small education organizations, support can be personal and effective, but public pages rarely show its internal discipline.

This is where local support labour enters the analysis. YYC Net Lab's mission is framed around Alberta residents, and the Volunteer Connector listing places it in Calgary's nonprofit and learning categories with a phone number and email address. Course pages mention mentor advice on local certification options. Final exams on physical equipment also imply a local or scheduled support layer. The value of local labour is not simply friendliness.

It is the ability to reconcile human context with records: "this student paid," "this student needs early activation," "this student is ready for equipment time," "this instructor candidate needs a credential path," "this account is confused," "this exam is outside our control."

The risk is that small organizations often hold too much of that knowledge in human memory. Human memory is helpful until a person is unavailable, a course cohort grows, a platform changes, or a support request crosses from education into payment or identity. Good local support needs records that survive absence. The public record cannot show whether YYC Net Lab has that depth. It can show why the question matters.

AS396302 makes the lab inspectable

The network-resource evidence gives YYC Net Lab an unusually concrete technical anchor for a training organization. PeeringDB lists YYC Net Lab with ASN 396302, the route set AS-YYCNETLAB, a website override pointing to yycnetlab.org, network type Educational/Research, one IPv4 prefix, one IPv6 prefix, traffic level of 0-20Mbps, mostly inbound traffic ratio, regional geographic scope and a note that the network is primarily IPv6. It lists RIR status as ok, with that status updated on June 26, 2024.

It also shows an operational public peering exchange point at YYCIX with 1G capacity and the exchange addresses 206.126.225.9 and 2001:504:2f::39:6302:1.

This is not the footprint of a large commercial carrier. It is the footprint one would expect from a small educational or research network that has enough public network identity to participate in a local exchange and expose a teachable routing surface. That matters. Network education can be entirely simulated, and simulation is useful. But an autonomous-system record connected to a real exchange gives instructors and learners a different kind of accountability.

It lets the public ask who the network is, what registry records point to it, what exchange fabric it appears on, what route set it declares and whether the public routing table sees it.

The ASN also gives readers a way to separate brand from resource. A brand can say "network lab" without holding or operating any public internet resources. YYC Net Lab's AS396302 record means the organization is not only a course storefront in the public record. It has a resource identity that technical observers can inspect. PeeringDB identifies the network as educational/research, not as a general cloud, content or access network. That classification is useful because it prevents overreading. The network-resource record supports educational and research interpretation.

It does not support a claim that YYC Net Lab sells transit, operates a cloud region, hosts customer workloads or provides production connectivity at commercial scale.

The ARIN-derived records add accountability, but also show the need for freshness. BGP.Tools identifies AS396302 as registered on May 2, 2017, allocated under ARIN, registered to AL-770 and tied to YYC Net Lab. It shows an organization address at 1740 1 Avenue NW, Calgary, AB, updated November 25, 2024, and technical, abuse and NOC handles associated with Mark Leonard. Robtex and Hurricane Electric show older ARIN-style address fields at 14704 Deer Ridge Dr SE, Calgary. Volunteer Connector also lists the Deer Ridge address, phone and info email. These are not necessarily contradictions in any operationally dramatic sense.

Organizations move, public listings age and third-party views refresh at different times. But they are exactly the kind of contact and address drift that a network-resource record has to manage.

During an incident, stale contact records are not harmless. If a route object is wrong, if an exchange port changes, if an abuse report needs handling, if a learner or partner wants to verify legitimacy, or if another network operator needs a NOC contact, the public record is where the first attempt often starts. Small networks can be perfectly legitimate and still be hard to reach if registry, exchange, website and local listings point to different contact histories.

YYC Net Lab's case is valuable because it shows a low-stakes version of a high-stakes internet governance problem: the routing system depends on boring contact data being current.

The resource evidence also helps explain what should not be claimed. An ASN is not service quality. A PeeringDB entry is not uptime. A YYCIX port is not global reachability. A route set is not a support commitment. Prefix counts are not customer count. A "primarily IPv6" note is not proof of an IPv6 training environment or current global IPv6 announcement. The evidence makes YYC Net Lab inspectable; it does not make every public claim true.

Route visibility is the central caveat

The most important technical caution in the evidence pack is route visibility. BGP.Tools states that AS396302 is not currently in the global routing table and shows zero IPv4 and zero IPv6 prefixes originated. Hurricane Electric's page says AS396302 had not been visible in the global routing table since January 29, 2026 and warns that some information displayed is from that time. It shows one originated IPv4 prefix, 23.156.160.0/24, but zero prefixes announced and zero RPKI-originated-valid counts in the current summary.

PeeringDB, by contrast, still declares one IPv4 prefix and one IPv6 prefix, while IPregistry associates an IPv6 range, 2604:4140::/32, with YYC Net Lab.

The correct response is not to force these displays into one clean story. The correct response is to respect the uncertainty. PeeringDB is an operator-maintained interconnection database. BGP.Tools and Hurricane Electric are public routing views. IPregistry is a public resource summary. They answer related but different questions. PeeringDB can say what the network declares and where it participates. A BGP view can say whether routes appear in the global table from that vantage. A historical display can preserve older route information. A registry-derived page can show allocation and contact details.

If one says "one prefix" and another says "not currently in the global routing table," that is not automatically scandalous. It is a sign that current route state should be checked before making operational claims.

For YYC Net Lab, the route gap is especially important because the network appears educational. A dormant or intermittently visible route may be acceptable for a lab, training, exchange presence, experiment or low-traffic educational use. It would be unacceptable as evidence for a production connectivity claim. The article therefore treats route visibility as a boundary condition. AS396302 gives the organization a real public network identity. The public evidence does not show a currently active global routing footprint at the access time.

That distinction is commercially and technically useful. A student may care that the organization understands routing well enough to hold an ASN and appear at YYCIX. A network operator may care that AS396302 is not visible in the current global table before attempting to test reachability. A grantmaker or partner may care that the resource record exists but is not proof of active service. A customer looking for cloud hosting or access service should not treat the ASN as a production-service endorsement. The same fact can mean different things depending on the question.

It also shows why route-resource monitoring is an automation problem. If a network is dormant by design, the public record should make that easy to understand. If a network is temporarily withdrawn, someone should know why. If PeeringDB still lists prefix counts while global route views show no current announcement, the operator should know whether the divergence is expected. If an AS-set includes the ASN in exchange route-server client lists, prefix limits should match the intended route policy. If RPKI records exist or do not exist, the route-origin story should not be guessed from a stale table.

These are small chores, but they are exactly the chores that make network-resource evidence trustworthy.

The route-visibility caveat also protects YYC Net Lab from unfair criticism. A training lab does not need to look like a carrier. It may withdraw routes when not teaching or testing. It may preserve an exchange presence for local community learning. It may hold resources for controlled use rather than public service. The problem is not dormancy. The problem would be letting readers, learners or partners infer active service from stale or ambiguous records. The evidence supports caution, not condemnation.

YYCIX turns locality into a visible boundary

The Calgary Internet Exchange is the strongest locality signal in the network evidence. PeeringDB places YYC Net Lab at YYCIX with 1G capacity, operational status and IPv4/IPv6 exchange addresses. BGP.Tools' YYCIX page lists YYC Net Lab among exchange entities at 206.126.225.9 and 2001:504:2f::39:6302:1 with 1000Mbps speed. Packet Clearing House describes YYCIX as the Calgary Internet Exchange, active, Ethernet-based, managed by YYCIX Internet Exchange Community Ltd and established in 2012.

This does not prove that YYC Net Lab provides local connectivity service. It proves something narrower: the organization's network-resource identity is visible in the ecosystem of a local exchange. For an Alberta training entity, that is a meaningful kind of locality. The ASN is not floating as an abstract number with no regional surface. It is tied, through public interconnection records, to Calgary's exchange community. That matters because training about routing, peering, IPv6, exchange fabrics and network operations becomes more concrete when a local example exists.

The public course pages make that educational relevance obvious. CCNA course 2 teaches switching, routing, VLANs, WLANs, redundancy and dynamic addressing. CCNA course 3 introduces enterprise WAN, QoS, remote access, SDN, virtualization and automation. Networking Essentials covers home and small-business networks, internet connectivity and troubleshooting. The routing record gives those topics a local reference point, not a guarantee that the course uses AS396302 in class. It is a public anchor around which a reader can understand why a network lab might hold an ASN and appear at an exchange.

Locality also shapes support. YYC Net Lab's mission is explicitly focused on Alberta residents. The Volunteer Connector listing places it in Calgary, gives a local phone number and email, and classifies it under nonprofit services and learning. The course pages describe local certification advice from a course mentor and physical-equipment final exams with locations and times to be posted during the course. These are not the markers of a faceless online course reseller. They are markers of a local training service that has to coordinate online content with local human help.

The data-sovereignty and locality theme should still be handled cautiously. The public evidence supports Alberta/Canada locality for the organization, Calgary locality for several contact and exchange signals, and a Canadian resource-registry context under ARIN. It does not show where all Shopify checkout data, course-progress data, Cisco Networking Academy identity data, support messages, email records or instructor records are stored. It does not show a privacy architecture, data-processing agreement, retention schedule or cross-border data flow.

The presence of Canadian address records and a local exchange does not mean every learner record stays in Canada.

That does not make locality meaningless. It makes locality a question to ask precisely. Which parts of the service are local? The mission and community focus appear local. Some physical equipment and final-exam scheduling may be local or locally coordinated. The exchange identity is Calgary-linked. The course content and certification ecosystem connect to Cisco and other external systems. The store/account surface is Shopify-backed. A learner or institutional partner should ask which record lives where, who can access it, how it can be recovered, and what happens if the learner leaves the course or changes email identity.

For a network education organization, these questions are not bureaucratic. They are part of the lesson. Networks are made of boundaries, and education services are too. YYC Net Lab's public record is useful because it makes several boundaries visible at once: local mission, global internet resource numbering, exchange interconnection, course commerce, external certification and support labour.

Cloud-service language must stay bounded

The article sits in a cloud-service category, but YYC Net Lab's public evidence should not be stretched into a cloud-platform story. The company's own pages reviewed in the evidence pack do not present compute instances, object storage, managed databases, backup products, hosted application services, cloud regions, data-center locations, uptime commitments, APIs for customers, service-level agreements or cloud pricing. They present networking education, course products, contact intake and a small educational network-resource identity.

That limitation is important because technology categories can seduce readers into assuming more than the source supports. A "cloud-service" label might make sense in a broad directory system that groups companies with internet-resource, software, network or service surfaces. It does not mean every company in that category sells infrastructure cloud. In YYC Net Lab's case, the more accurate service boundary is training and network-lab operations.

The cloud-relevant discussion is about the software and external platforms that support that work: the course store, account login, checkout, Cisco Networking Academy access, simulation tools, possible remote or physical lab scheduling, and route-resource records that have to remain queryable.

The NETLAB+ context source helps illustrate the general boundary without proving YYC Net Lab uses that product. NETLAB+ describes how Cisco Networking Academies can host Cisco training equipment over the internet for blended learning, remote academy access, instructor-led training, student-team access and individual equipment access. That is exactly the kind of remote-lab model that makes network education operationally complex. But the source is not a YYC Net Lab source. It should not be used to claim YYC Net Lab operates NETLAB+, or that its lab equipment is remotely accessible in that way.

It can only show why network-lab education often spans physical equipment, online curricula and platform records.

The safer cloud-adjacent question is therefore this: how does YYC Net Lab coordinate software-mediated learning with physical and registry-backed networking practice? The evidence gives hints. Course material can be instantly available after early enrollment. Quizzes and practice exams use simulation software. Final exams are conducted on physical equipment. Instructor activation can move an exam earlier. The public store is Shopify-backed. Cisco certification exams are outside the course store. AS396302 and YYCIX records exist in public network databases. That is enough to analyze an operating surface.

It is not enough to claim a cloud product.

This restraint protects buyers and the company alike. A learner should not shop YYC Net Lab as if it were a hosting provider. A partner should not evaluate AS396302 as if it were a production cloud network. A directory reader should not infer cloud maturity from a category label. The company should be judged on the service it actually makes visible: network education and network-resource accountability.

Registry freshness is the quiet governance test

The registry and routing records around YYC Net Lab are useful precisely because they are imperfect. PeeringDB shows one set of declarations and update timestamps. BGP.Tools shows ARIN-derived organization data with a newer Calgary address and a 2024 organization update. Hurricane Electric and Robtex show an older Calgary address in their ARIN-style WHOIS panels. Volunteer Connector also uses the older Deer Ridge address. PeeringDB contact information is partly hidden to unauthenticated users, and its contact info updated timestamp is older than its RIR status update.

BGP.Tools gives technical, abuse and NOC handle names but hides email addresses unless the user is logged in.

None of this proves that YYC Net Lab is unreachable or badly maintained. It does prove that public-record freshness cannot be assumed. Small networks often have long tails of old address records and community listings. If the organization moved, updated ARIN, left older third-party pages untouched and kept operating normally, that would be ordinary. But from the outside, record drift looks like uncertainty. Which address should a learner trust? Which address should a network operator use during an abuse report? Which phone number is active? Which email belongs to course support and which belongs to registry contact?

Which PeeringDB fields are current enough for route-server expectations?

The governance test is whether these questions can be answered without private knowledge. Registry data exists to make network responsibility discoverable. Educational mission pages exist to make service intent discoverable. Contact pages exist to make help discoverable. When they disagree or go stale, each record may still be individually understandable, but the public picture becomes harder to use. That is especially relevant for an educational organization because it teaches the importance of clean addressing, routing and troubleshooting records.

Freshness is also part of recovery. If the site account breaks, the learner needs a contact path. If the course record fails to activate, the instructor needs a way to reconcile payment and course access. If an exchange route is misconfigured, another operator needs a NOC path. If an ARIN contact is outdated, the recovery process starts badly. If PeeringDB says one prefix and a current route view says none, a student or partner needs an explanation before treating the network as live.

The public evidence suggests a practical improvement target rather than a verdict. YYC Net Lab can benefit from keeping address, contact, route-set, prefix-limit, exchange and course-support records aligned across its own site, ARIN-derived views, PeeringDB and local listings. That work is unglamorous, but it is the exact kind of operational hygiene a network lab can model.

What public evidence can and cannot establish

The evidence can establish a strong public identity. YYC Net Lab presents itself as a cost-effective Cisco Networking Academy training provider with an Alberta not-for-profit mission. It lists course products across free beginner courses, paid certification courses, CCNA segments and instructor training. It describes online self-study modules, simulation software, physical equipment for final exams, instructor activation and mentor guidance. It exposes a contact form, login and cart. It has public technical-education signals such as a blog post on TTL. External public pages place it in Calgary/Alberta learning and nonprofit contexts.

The evidence can also establish a real network-resource identity. AS396302 is associated with YYC Net Lab across PeeringDB, BGP.Tools, Hurricane Electric, Robtex and IPregistry. PeeringDB identifies it as educational/research, with one IPv4 prefix, one IPv6 prefix, mostly inbound traffic, regional scope, YYCIX presence and a "primarily IPv6" note. BGP.Tools and BGP.he.net identify YYCIX exchange addresses. Public IXP sources identify YYCIX as an active Calgary exchange. ARIN-derived displays tie AS396302 to YYC Net Lab, Canadian location and contact handles.

The evidence cannot establish course outcome. No student account was created. No course was purchased. No free course was activated. No instructor-training process was entered. No final exam was scheduled. No Cisco Networking Academy identity was linked. No mentor was contacted. No physical equipment was inspected. No learner completion, accreditation result, student satisfaction, instructor response time or refund process was measured.

The evidence cannot establish network outcome. No route was announced, withdrawn or tested. No looking-glass command was run. No ping, traceroute, speed, latency, loss, IPv6 reachability or route-server query was submitted. No packet crossed AS396302 as part of this review. No exchange port was inspected. No RPKI or IRR record was mutated. Public route tools were read only. That means the article can discuss route visibility and public records, not live network performance.

The evidence cannot establish data residency or privacy controls. Public pages show a Shopify storefront/account surface and course boundaries involving external platforms. They do not show where all personal data, payment metadata, course-progress records, instructor records, support messages or certification-related records are held. They do not show retention, deletion, export, access control or incident response. Alberta locality and Canadian resource records are meaningful, but they are not data-residency proof.

These limits are not incidental. They define the article's value. Public-record analysis is useful when it says what can be known without pretending to know more. YYC Net Lab's public record supports a careful, bounded conclusion: it is a local network-education organization with a visible ASN and exchange presence, and its operational trust depends on keeping training, account, support and network-resource records fresh.

The failure modes are ordinary enough to matter

The first failure mode is lab-versus-service confusion. A network lab may hold real resources without offering production connectivity. A course store may teach enterprise automation without operating enterprise automation for customers. An instructor-training product may support a path toward accreditation without itself guaranteeing that an external authority grants a credential. If readers collapse those distinctions, they will overstate both the company's technical service role and its educational guarantees.

The second failure mode is registry-only ambiguity. AS396302 is real public evidence, but it is not self-explaining. Without current route visibility, plain-language notes and fresh contact fields, an ASN can become a label rather than an operational entity. PeeringDB's educational/research classification helps, but it is not a full operating manual. A route viewer saying "not currently in the global routing table" is a critical caveat that should travel with any discussion of the network.

The third failure mode is stale contact and address records. Public sources showed both 1740 1 Avenue NW and 14704 Deer Ridge Dr SE in Calgary contexts. They also showed different update moments and contact surfaces. That does not prove an error in any current official record, but it does mean external readers should not treat every public listing as equally fresh. For a network-resource entity, stale records can slow abuse handling, peer coordination, learner support and local trust.

The fourth failure mode is unsupported service expansion. The training catalogue includes networking, cybersecurity, Linux, IT Essentials, CCNA, automation concepts and instructor training. Those are educational products, not proof that YYC Net Lab sells managed security, Linux support, automation consulting, enterprise networking service or cloud hosting. The article should not convert a course topic into a company product line.

The fifth failure mode is route-visibility drift. PeeringDB may continue to declare prefix counts while global route views show no current announcements. Hurricane Electric may preserve historical data after an ASN disappears from current visibility. BGP.Tools may show zero originated prefixes. Each record can be useful, but the difference is the story. A monitoring process should ask whether the divergence is intended, temporary or stale.

The sixth failure mode is account-state drift. A learner may believe payment equals access, access equals exam eligibility, exam eligibility equals accreditation progress, and accreditation progress equals external certification readiness. The public course pages show that the chain is more complex. Online modules, simulation software, instructor activation, physical equipment, mentor advice and Pearson Vue certification exams are separate pieces. If the records are not reconciled, the learner feels the friction.

The seventh failure mode is locality overclaim. YYC Net Lab has a strong Alberta mission and Calgary network evidence, but public pages do not prove all data stays local, all support is local, all equipment access is local or all certification processes are local. Locality is a strength only when it is precise.

A record-first scorecard for YYC Net Lab

A useful evaluation of YYC Net Lab begins with identity. Does the organization name on the course store match the name in the network records? Does the learner understand the not-for-profit mission and the course provider boundary? Do local listings, the website and ARIN-derived records point to consistent current contact paths? If not, which record is treated as authoritative for learner support, registry contact and exchange coordination?

The second category is course definition. Is the learner buying a free online course, a paid certification course, a CCNA segment, IT Essentials or instructor training? What does the price include? How is access delivered? Which platform hosts the material? Which quizzes and practice exams are simulation-based? Which final exams require physical equipment? How are locations and available times communicated? What happens if a learner enrolls early and wants exam activation before a normal cohort moment?

The third category is account and payment state. The public store shows login, cart and product pages. A buyer should ask how a course order maps to course access, what record confirms activation, how refunds or cancellations are handled, how recurring or deferred purchase language applies to products where it appears, and how support distinguishes billing questions from course-content questions.

The fourth category is instructor and accreditation boundary. Instructor-training products should be understood as part of a path, not as a magic credential. A prospective instructor should ask what prerequisites apply, what Cisco Networking Academy records are required, who confirms instructor readiness, which steps are under YYC Net Lab's control and which steps depend on external platform or program rules.

The fifth category is network-resource evidence. AS396302, AS-YYCNETLAB, PeeringDB fields, YYCIX exchange addresses, prefix limits, route visibility and contact handles should be monitored as public records. If the network is intentionally quiet, say so in appropriate public records. If a prefix is expected to be visible, route tools should show it. If PeeringDB lists one IPv4 and one IPv6 prefix, the route policy and route-server configuration should make that meaningful.

The sixth category is local support labour. The public mission is Alberta-focused. The course pages point to mentors and physical equipment. The contact page is simple. A learner or partner should ask how support is staffed, how messages are tracked, how urgent exam or account issues are escalated, and whether local support records survive staff absence or volunteer turnover.

The seventh category is data locality and recovery. Which records are in the store, which are in Cisco Networking Academy, which are in email or support systems, which are tied to physical lab scheduling, and which are in registry or exchange databases? How can a learner recover access if their email changes? How can an instructor candidate prove progress? How can a network operator reach the right person? These are all different recovery paths.

This scorecard is intentionally record-first because YYC Net Lab is record-rich and outcome-light in public evidence. The public record is good enough to ask disciplined questions. It is not good enough to award a performance grade.

Why this small case matters

YYC Net Lab is not a global infrastructure giant, and that is precisely why it is analytically useful. The internet is full of small organizations whose public importance is not measured by traffic volume. A community training group, research network, local exchange entity or not-for-profit education provider can carry a modest ASN and still matter. It matters because it teaches people. It matters because it participates in a local internet community. It matters because it models whether public records are kept clean.

It matters because learners who enter the networking field through such organizations inherit habits about attribution, troubleshooting and responsibility.

The public evidence shows a rare overlap: a learning organization that teaches networking concepts and a network-resource record that can itself be used as a lesson. AS396302 can illustrate the difference between an ASN and a prefix, between PeeringDB declarations and global BGP visibility, between an exchange port and internet-wide reachability, between registry contact and support contact, between IPv6 aspiration and current announcement state. Those are not side details. They are the material of network literacy.

The same overlap creates reputational responsibility. If YYC Net Lab teaches routing and troubleshooting, its own public records become part of the classroom whether or not they are formally used in class. Learners may look up the ASN. Network operators may look up PeeringDB. Local partners may look up the address. A mismatch does not make the organization bad, but it does make the lesson more complicated. A clean record teaches clean operations. A stale record teaches that public infrastructure data is messy and must be verified.

The commercial question is modest but real. Does reliability, locality, support and migration cost justify the service boundary versus alternatives or self-managed records? For a learner, the alternative may be free Cisco courses directly, a college program, a commercial boot camp, self-study, or another local academy. YYC Net Lab's public value proposition appears to be cost-effective access, local mission, CCNA structure, instructor support and hands-on or physical-equipment components. For an instructor candidate, the value may be access to instructor training through a local NetAcad Instructor Training Center.

For a technical community, the value may be a local educational network entity. Each value depends on records being clear enough that the buyer or partner knows what is included.

This is why unsupported service claims would be harmful. Inflating YYC Net Lab into a cloud provider would obscure the real value. Dismissing it because its ASN is not currently visible in the global routing table would also miss the point. The useful judgment is narrower: YYC Net Lab appears to be a network-education and network-lab entity whose public operating surface depends on course records, support records, local mission records and network-resource records staying synchronized.

Final judgement

YYC Net Lab should be treated as a network-lab and registry-boundary record, not as a broad cloud or connectivity provider. Its public pages support an educational identity: cost-effective CCNA training, free beginner courses, paid certification courses, instructor-training products, a flipped-classroom claim, local Alberta mission, contact intake, account/cart surfaces and references to simulation software, real equipment and physical final exams.

Its public network records support a technical identity: AS396302, ARIN-derived registration, PeeringDB educational/research classification, AS-YYCNETLAB, YYCIX exchange presence, one declared IPv4 and one declared IPv6 prefix, mostly inbound low-traffic profile and current route-visibility caveats.

The strongest positive reading is that YYC Net Lab has a real and inspectable public footprint for a small network-education organization. It can be read through the four monitoring themes: enterprise-software automation in course activation, checkout, account and instructor-support records; network-resource evidence in AS396302, PeeringDB, YYCIX and route-viewer records; data sovereignty and locality in Alberta mission, Calgary contact/exchange signals and unresolved platform data boundaries; and local support labour in the mentor, contact, physical-equipment and community-learning surfaces.

The strongest caution is that the public record cannot prove outcomes. It cannot prove course quality, support response, accreditation success, lab availability, payment handling, data residency, route health, uptime, redundancy or active global reachability. It can only show the records that should be kept fresh if the organization wants learners, partners and network operators to understand the boundary.

That is enough to make YYC Net Lab worth watching. Small network-lab entities sit at the edge of education and infrastructure, where public records become teaching tools and operational safeguards. If YYC Net Lab keeps course, support, registry and route records aligned, its modest footprint can carry real community value. If those records drift, the same modest footprint becomes harder to trust. The evidence points to an organization whose significance is not scale, but discipline: the discipline of showing what it is, what it is not, and which records make the difference.