Summary
- AFRINIC's public record identifies NETLAYER (PTY) LTD as the holder of AS328222, an IPv4 /22 and an IPv6 /32. Current route observation found both prefixes announced by that autonomous system, and both observed origin pairs had valid Route Origin Authorizations.
- PeeringDB records two operational 1 Gbps IPv4 connections for AS328222 at NAPAfrica Johannesburg. That is useful evidence of an interconnection presence, but it is not proof that every customer path stays local, has diverse physical routes or meets a particular latency or availability target.
- Netlayer presents itself as a business fibre, VoIP and managed IT provider serving Gauteng and the Western Cape. Its fibre page also says it uses third-party fibre-network and backhaul providers, making supplier handoffs part of the service rather than an incidental detail.
- The public company agreement establishes a South African legal identity and describes equipment, installation, notices, cancellation, supplier dependence and service suspension. It does not publish a universal service-level schedule, route-diversity design, incident-response target or migration plan for every offer.
- Buyers should judge Netlayer on a joined operating record: who owns the circuit and address resources, which party accepts an incident, what is monitored, how route and contact records are kept current, what evidence closes a fault, and how numbers, data, equipment and configurations can be recovered or moved.
Membership is an identity signal, not a service verdict
An entry in a regional internet registry can look conclusive. It has a legal name, an autonomous system number, address blocks, contacts, dates and status fields. Those attributes are more useful than a marketing slogan because they are tied to resources that participate in internet operations. They are not, however, a customer experience report.
AFRINIC's RDAP record for AS328222 names the registrant as NETLAYER (PTY) LTD, marks the autonomous system active, records its registration on 7 September 2017 and shows a last-change date of 12 November 2025. The same record exposes organisation and contact data connected to Netlayer's domain. That is strong evidence that this legal entity is associated with the number resource. It does not say how many customers use the network, whether a particular fibre circuit is live, how quickly a fault is repaired, or whether the advertised service matches a buyer's building.
This distinction is built into the registry itself. AFRINIC describes its WHOIS database as a public source about holders of internet number resources and says it may be used for operational and routing-policy purposes. Its terms also disclaim a guarantee of accuracy, completeness or availability. The maintainer is responsible for keeping associated personal data accurate enough to permit contact. A registry record is therefore an operational assertion with an owner and a maintenance obligation, not an audit opinion on the holder's entire business.
The record is valuable precisely because it can be tested against other evidence. Does the legal name recur in a customer agreement? Does the listed domain present the same company? Do independent routing observers see the ASN originate the registered prefixes? Are those origins authorized? Does an interconnection directory associate the ASN with an exchange point? Do the public telephone and address surfaces align? Each match increases confidence in the identity join. Each mismatch identifies a question that a buyer or operator should resolve.
The wrong way to read membership is as a badge that absorbs all those questions. The right way is to treat it as the first row in an accountability table. It says which organisation the registry associates with a resource. It gives the investigation somewhere to start when routing, abuse, contact or ownership questions arise. It cannot substitute for service-specific commitments, live monitoring or a tested escalation path.
For Netlayer, that difference matters because the public offer crosses several boundaries. The company markets internet access, voice services and managed IT. A business customer may experience those as one supplier relationship. Underneath, a circuit can involve a fibre-network operator, a backhaul provider, Netlayer's network, an exchange point, transit or peers, equipment at the customer site and applications managed by still other providers. AFRINIC membership establishes one entity in that chain. Reliability depends on whether the chain can be observed and governed as a whole.
The identity join is unusually well supported
The public records support a careful identification of the company without requiring a leap from a similar brand name. Netlayer's client services agreement defines Netlayer as a South African private company with registration number 2012/116665/07. It names IT support, internet service and VoIP as the relevant service classes. The agreement gives a Midrand address and a Netlayer email domain. AFRINIC's AS record uses the same legal name, domain-linked contacts and a Midrand address. PeeringDB's network entry for AS328222 joins the ASN to the Netlayer name and netlayer.co.za website.
These repeated fields make a stronger identity chain than a logo or search result. The company agreement establishes the contracting person. AFRINIC establishes the registered resource holder. PeeringDB associates that holder and ASN with an interconnection profile. Netlayer's public site supplies a telephone number, service descriptions, legal links and an ISPA complaints route. The ISPA member list includes NETLAYER (PTY) LTD among full members rather than in the provisional section.
There are still small inconsistencies worth noticing. Public address strings alternate between “Waterfall City” and “Waterval City,” and older contacts or addresses can remain attached to registry entities for legitimate historical or role reasons. Such differences do not by themselves show that the identity is wrong. They demonstrate why an operating record needs provenance and dates. A customer raising an outage should not have to decide whether an old technical contact, a current office address or an accounts mailbox is the correct escalation route.
AFRINIC explicitly tells members to verify legal names, addresses, phone numbers, general email addresses and administrative and technical contacts. Its member-information guidance says those details should remain accurate and describes consequences when contractual information is not kept current. The AS328222 record's 2025 change date is evidence that something in the record was updated; it is not evidence that each individual field was independently called, answered or recertified on that date.
Identity quality is operational because internet resources outlive employee roles. A technical contact leaves. An office moves. A supplier becomes responsible for part of the network. An incident arrives after hours. A resource transfer or routing change needs authorization. If the account, registry entity and support system disagree about who can act, the problem is not merely clerical. It can delay a route correction, an abuse response or a recovery request.
Netlayer therefore deserves neither automatic trust nor automatic suspicion from the registry row. It deserves credit for a public identity that joins across several records. The next step is to ask what those records describe and where their authority ends.
What Netlayer publicly offers
Netlayer's homepage presents three main service families: business internet, VoIP and managed IT support. It says the company serves businesses in Gauteng and the Western Cape, manages services under one brand and operates its own ISP and VoIP networks. It also says it can consolidate fibre, voice, support and application development. These are company claims, but they define a real operating proposition: one accountable supplier across connectivity and business technology.
The fibre offer is more concrete than the broad brand statement. Netlayer's internet service page lets a prospective buyer check an address, browse packages and filter by term, speed and service type. It describes packages as including line rental and data, and it presents a staged installation process. Netlayer first conducts a feasibility request, then submits paperwork and waits for an estimated date from the backhaul provider, after which a pre-site inspection and installation can occur. The company installs its router after the fibre line is in place.
That description reveals the service boundary more honestly than the phrase “own network” can on its own. Netlayer says it uses fibre-network operators to connect customers to its network and names different indicative installation windows for several providers. The access line and some installation work can therefore belong to third parties even when Netlayer owns the customer relationship and operates the routed service above it. A customer buying one invoice may still depend on several technical and commercial owners.
The managed IT page extends the boundary further. It lists Windows and Linux server management, network management, backup and disaster-recovery management, firewall management, Microsoft 365, Azure and AWS management, antivirus and endpoint management. The company says backup and recovery environments are maintained and tested at scheduled intervals and that firewalls receive scheduled audits. It also advertises remote support billed in 15-minute increments and unused block hours rolling over for 30 days.
Those statements describe activities, not measured outcomes. “Scheduled” does not disclose frequency. “Tested” does not reveal the recovery point achieved, the recovery time observed, the sample restored or whether the customer received evidence. “Managed” does not reveal which changes require approval, which alerts are watched after hours or who owns a cloud account. A buyer can use the statements to form questions, but should not convert them into unlisted guarantees.
The combination of access, voice and managed IT can nevertheless be commercially meaningful. When one team can see the circuit, router, firewall, endpoint and cloud service, it may diagnose cross-layer incidents faster than suppliers who each see one component. The same consolidation can increase concentration risk. If the account, monitoring and support state are weak, one provider can become the single place where several unresolved dependencies accumulate.
The key technical product is therefore not only bandwidth. It is a maintained operating record connecting location, feasibility, access supplier, circuit, router, address plan, autonomous system, routing policy, service entitlement, monitored assets, incidents, changes, invoices and exit obligations. The public registry provides a small but important part of that record. The commercial service succeeds when the rest remains as attributable and current.
AS328222 and the registered resource surface
An autonomous system number identifies a routing domain that presents a coherent policy to other networks. It is not a serial number for a company, and a company can operate more than one network or use resources supplied by others. In Netlayer's case, AS328222 is the clearest public handle for the network identity associated with the legal entity.
AFRINIC's AS record marks AS328222 active. Its IPv4 RDAP record associates NETLAYER (PTY) LTD with the range from 102.128.160.0 through 102.128.163.255, equivalent to 102.128.160.0/22, and marks it active with country code ZA. The record says that range was registered on 16 January 2019. AFRINIC's IPv6 record associates the company with 2c0f:7380::/32, also marked active and coded ZA, with a registration date of 16 January 2023.
These are registration facts. They show that AFRINIC's database connects the organisation to an ASN and address space. They do not show how every address is assigned, whether a particular customer receives provider-independent or provider-aggregatable space, where hosts sit, which applications use the addresses, or whether all capacity is active. The country field describes the registration context; it is not packet telemetry.
The distinction between allocation and use is easy to miss. An address block may be registered but not announced. It may be announced only in aggregate. It may be originated by an unexpected ASN. It may have a valid route origin but no reachable service at a particular address. It may carry customer access traffic, infrastructure, hosted systems or a mixture. Public routing tells an observer how networks advertise reachability, not what contractual service each address represents.
That is why resource size should not be used as a proxy for market share. A /22 contains 1,024 IPv4 addresses, but the count says nothing about subscribers, revenue, traffic volume or quality. An IPv6 /32 provides a very large addressing plan by IPv4 standards, but its scale reflects IPv6 architecture rather than an equivalent number of active endpoints. Any attempt to turn those blocks into customer counts would be fiction.
The useful operational questions are narrower. Is the resource still registered to the expected entity? Is the origin visible? Does the origin match authorization? Are reverse DNS and abuse contacts maintained where needed? Can staff with the right authority update the records? Are customer assignments represented in a way that supports incident response and migration? Public sources answer the first three in part. They do not expose Netlayer's internal assignment, change-control or recovery procedures.
For a buyer, the ASN matters most when it connects to a service design. A business may care whether Netlayer originates the addresses used for its service, whether another carrier supplies them, whether failover preserves the same addresses, and what happens during a provider change. The existence of AS328222 makes those questions answerable in principle. It does not predetermine the answers for every package.
Observed routes turn registration into bounded evidence
Routing observation adds a second layer. On the snapshot used for this assessment, the RIPEstat announced-prefixes result for AS328222 showed two origins: 102.128.160.0/22 and 2c0f:7380::/32. Both appeared throughout the observation window from 29 June to 13 July 2026. That matches the two blocks in AFRINIC's records.
The RIPEstat routing-status result reported one observed IPv4 prefix representing 1,024 addresses and one IPv6 prefix representing 65,536 /48 units. At the query time on 13 July 2026, all 325 listed IPv4 RIS peers and all 322 listed IPv6 RIS peers in that result saw the ASN. The service also recorded the IPv4 origin as first seen in February 2019 and last seen at the current query time.
This is materially stronger than membership alone. It shows that independent collectors observed the registered ASN originating the registered aggregate routes across a broad set of their peers at that moment. It rebuts a simple hypothesis that the ASN was merely registered but invisible. It does not prove universal reachability from every network, because RIS peers are observation points rather than every possible path. It does not measure packet loss, latency, jitter, application availability, congestion or restoration time.
Route presence is a coarse state. A prefix can remain visible while a customer's access circuit is down. It can be globally visible while one peer has a poor path. It can be stable as an aggregate while more-specific routes change. A route collector can show the control-plane announcement without testing whether packets reach the intended destination. The observation is therefore evidence of active routing, not a substitute for service monitoring.
Freshness matters as much as presence. The result has an explicit query time and observation window. A copied table without that time would decay quickly because routes can change. A buyer relying on public routing should capture the resource, origin, vantage source and timestamp together. The same discipline belongs in an operator's own monitoring: an alarm should identify what changed, compared with which expected state, and who owns the response.
The clean match among ASN, IPv4 block, IPv6 block and observed origins is a positive signal for Netlayer. It shows coherence among registration and public routing at the aggregate level. It still leaves customer-specific design questions open. Public evidence does not say whether a quoted business circuit uses these resources, whether it has a static address, whether failover uses another ASN, or whether voice and managed services traverse the same network.
That boundary is not pedantry. A procurement team can correctly state that AS328222 was actively originating both registered blocks in the observation. It cannot correctly state that the evidence demonstrates a customer's uptime or proves every service is delivered on Netlayer-owned infrastructure. One claim is supported by route data. The other requires service records and tests that are not public.
Valid origins reduce one class of uncertainty
Route Origin Authorization adds a third layer. A ROA is a signed statement that an address-space holder authorizes a particular autonomous system to originate a route for a prefix, subject to prefix-length rules. The IETF's guidance on route-origin validation is deliberately narrow: it binds an address prefix to an authorized origin AS and provides a validation outcome for that pair.
RIPEstat's IPv4 validation result marked the observed pair of AS328222 and 102.128.160.0/22 valid. It showed a validating authorization for AS328222, with a maximum length of /24. The corresponding IPv6 result marked AS328222 and 2c0f:7380::/32 valid as well.
That is a meaningful security and governance signal. It means the origin pairs observed in this snapshot matched published authorizations according to the validator. An operator performing route-origin validation can use such data as an input to routing policy. It reduces the uncertainty that would exist if an origin had no covering authorization or conflicted with one.
It does not authenticate the whole path. A valid origin says nothing about which intermediate networks carry the traffic, whether a route leak occurs beyond the origin check, whether the physical link is diverse, whether a router is correctly configured, or whether an application is secure. It does not guarantee that an authorized route will be announced, remain stable or deliver packets. Even a correctly signed authorization can be operationally risky if its prefix-length settings are broader than the routes the holder intends to announce.
The IPv4 maximum length is worth understanding. The observed /22 is authorized, and more-specific announcements down to /24 may also fit the listed authorization if originated by AS328222. That flexibility can support operational designs, but it also means a monitor should know which more-specifics are expected. “RPKI valid” should not end the review. The expected route inventory still matters.
The IPv6 result also exposes a data-quality lesson. PeeringDB's network profile reported no IPv6 prefixes and did not mark IPv6 support in its self-described fields, while the independent route observation showed the /32 and the RPKI result validated it. The PeeringDB exchange entries listed IPv4 addresses but no IPv6 addresses. These facts can coexist: a network can originate IPv6 without listing IPv6 at that exchange or updating every directory field. They also show why one directory should not be treated as a universal truth source.
For Netlayer, valid origin authorization is a positive fact with a precise scope. It supports the claim that the two observed aggregate routes were authorized to originate from AS328222 in the snapshot. It cannot establish customer security, full BGP path protection or service reliability. The honest conclusion is smaller and more useful than a security badge.
Peering in Johannesburg is locality evidence with limits
PeeringDB's current profile classifies Netlayer as a regional cable, DSL or ISP network with an open peering policy. Its public exchange entries show two operational IPv4 connections at NAPAfrica IX Johannesburg, each listed at 1 Gbps, using 196.60.8.157 and 196.60.8.154. The record was updated in March 2026.
This is useful evidence of a Johannesburg interconnection presence. An internet exchange allows participating networks to exchange traffic, and local peering can reduce dependence on distant transit for traffic between networks that actually peer there. Two listed connections may provide more attachment options than one. The record does not disclose whether they are on physically diverse routers, ports, cross-connect paths, buildings or power domains. It does not say which peers exchange traffic directly, through route servers or under private arrangements.
Local interconnection is also not the same as local delivery. Netlayer's website says it serves Gauteng and the Western Cape, while the PeeringDB evidence exposed here is for Johannesburg. A customer in Cape Town may reach local or remote destinations through a design that is not visible in this profile. A Johannesburg customer may still send some traffic outside the province or country because the destination, cloud region, upstream policy or failure state requires it. A route's registered country and an exchange-point location do not pin every packet to that geography.
This matters for the topic of data sovereignty. Network locality can improve latency and reduce some exposure to distant paths, but it does not answer where application data is stored, backed up, inspected or administered. Netlayer's managed IT page refers to Microsoft 365, Azure and AWS. Those platforms have their own account, region and support choices. A local access provider can carry traffic to an overseas service, while a globally branded cloud can host a workload in South Africa. Locality has to be specified by layer.
South Africa's Protection of Personal Information Act places conditions on transfers of personal information outside the Republic. That legal context makes transfer design and contractual accountability important, but the existence of a South African ASN does not demonstrate compliance. A customer needs to know what personal information the service processes, which party is responsible, where recipients and subprocessors operate, what safeguards apply and how further transfers are controlled.
The stronger locality claim for Netlayer is therefore bounded. The legal entity, registered address resources, operating contact surface and disclosed exchange presence all have South African anchors. The public evidence also shows a Johannesburg exchange attachment and a stated service focus on Gauteng and the Western Cape. It does not prove that all traffic, logs, backups, voice records or support access remain in South Africa.
A buyer should ask for a topology and data-location statement that uses exact nouns. Circuit handoff, routing point, voice platform, log store, backup copy, ticket system, cloud tenant and support location are different entities. A general promise of “local” can conceal those differences. A good answer identifies the entity, location, owner, normal path, failover path and evidence available after an incident.
Supplier handoffs are part of the product
Netlayer's fibre page says the company conducts feasibility, submits paperwork, waits for an estimated date from a backhaul provider and relies on a pre-site inspection before installation. It also says the company uses fibre-network operators to connect customers to its network. The client agreement states that Netlayer depends on third-party service providers and suppliers and will use reasonable endeavours to provide a reliable service.
These disclosures matter because they locate the exceptions. A building can fail feasibility. A landlord can delay or block access. A wayleave can remain outstanding. A fibre operator can change an installation date. A circuit can be installed while the customer router is not ready. Netlayer can activate its routed service while a voice port is still pending. A single order status such as “in progress” is too coarse to explain any of those states.
The operating record should separate at least the customer order, physical site, feasibility result, supplier order, route plan, approvals, equipment, installation appointment, optical handoff, router configuration, acceptance test and activation. Each needs an owner and timestamp. When a supplier changes an estimate, the customer-facing commitment should update without erasing the earlier promise. When a site move occurs, the new feasibility decision should not be confused with a transfer of an existing line.
Netlayer's public material does not reveal the system used to manage these records. There is no basis for claiming a particular service-management platform, network automation stack or inventory database. The absence of a disclosed brand is not itself a weakness. The question is whether the records reconcile under repeated use and whether support can explain the current state without asking the customer to retell the whole history.
Supplier dependence also changes incident ownership. A customer may buy from Netlayer while the physical fault belongs to a fibre operator. Good support accepts the incident, captures customer impact, opens the supplier case, preserves reference numbers, updates the customer and verifies restoration. Weak support merely forwards the customer to a company with which the customer has no contract. The technical cause may be external; accountability for communication remains part of the purchased service boundary.
The same principle applies to managed IT. Microsoft, AWS, Azure, an endpoint-security vendor or a hardware supplier may own part of the technical remedy. Netlayer's value is not that it controls every dependency. It is that it can maintain enough identity, entitlement, configuration and incident state to coordinate them. Consolidation is valuable when it reduces the customer's reconciliation labour. It is less valuable when it simply places more third-party queues behind one phone number.
A serious assessment should therefore ask for evidence from a recent cross-supplier incident, anonymized where necessary. How was the event detected? Which clock started the response? Who opened the supplier case? How were updates recorded? What proved restoration? What follow-up change was made? The answer would say more about operational quality than membership in any directory.
Support is a control plane made of people and records
Public network data is strongest when it can be joined to a reachable human process. AFRINIC lists administrative and technical contacts for the number resources. Netlayer publishes sales and service contact routes, a physical address, legal notices and an ISPA complaints route. ISPA lists the company as a full member. Together, these are useful contactability signals.
They are not a support performance test. A telephone number on a web page may lead to sales rather than a network operations team. A registry contact may be authorized to maintain resources without staffing customer incidents. A complaints channel is an escalation mechanism, not an ordinary repair desk. The evidence does not disclose support hours, severity levels, response targets, update intervals or after-hours staffing for each product.
Netlayer's managed-services page makes support labour commercially visible by describing remote billing in 15-minute increments and block-hour rollover. That is more concrete than saying support is “personal.” It also raises questions a buyer should settle before purchase. What starts the clock? Is monitoring response billable? Are supplier escalations charged? Does a major incident consume ordinary block hours? Who approves a change that may create downtime? Are reports itemized by asset, ticket and activity?
The support system should preserve four forms of truth. The first is identity: the customer, authorized requesters, sites, services and equipment. The second is entitlement: contract, support window, response target and included work. The third is operating state: alerts, configuration, dependencies, incidents and changes. The fourth is communication: what the customer reported, what support observed, what suppliers said and why a case was closed.
Automation can help by linking an alert to the correct circuit, opening a case, attaching route evidence and triggering an escalation. It can also amplify bad records. A stale contact sends the alert to the wrong person. A duplicate circuit creates two cases. An outdated supplier mapping sends the fault to the wrong carrier. A premature recovery event closes a case while the customer remains offline. Human supervision is not the opposite of automation; it is the mechanism that corrects uncertain or conflicting state.
Public evidence cannot show Netlayer's ticket quality or median repair time. No representative incident sample, severity report or independent customer benchmark was available for this assessment. Testimonials on a company site can illustrate what the company chooses to present, but they cannot establish a distribution of outcomes. The fair conclusion is that Netlayer exposes multiple accountability routes and sells managed support, while actual responsiveness remains a diligence item.
For a smaller provider, local labour can be a genuine advantage. Engineers may know customer sites and supplier quirks in detail. Decision paths can be shorter than at a national carrier. The corresponding risk is dependence on a small number of people and undocumented knowledge. A buyer should ask how cases are handed over, how registry credentials and network configurations survive staff changes, and how an incident proceeds when the usual engineer is unavailable.
The contract reveals the real commercial boundary
Marketing describes possibility; the agreement describes allocation of responsibility. Netlayer's public client agreement is therefore one of the most useful sources for evaluating the service, even though an individual order's annexures may contain the decisive service details.
The agreement defines the service classes broadly and says the applicable services are described more fully in an annexure. It provides for a fixed period indicated there, followed by continuation subject to written notice unless the parties agree otherwise. It describes initial installation and setup charges, monthly subscription charges, usage charges and supplier price increases. It also addresses equipment ownership, return, replacement and de-installation.
These terms show why migration cost is not just a porting fee. A customer exit may involve notice, remaining commitments, supplier charges, de-installation, equipment return, a new installation elsewhere and extension work. The fibre page separately says a move requires feasibility and can attract a new installation fee and extension costs. A landlord that blocks a new installation can create a commercial problem even when the technology works.
The agreement also states that Netlayer depends on third-party providers and suppliers. It describes reasonable endeavours for reliability and contains limitations around interruption and circumstances outside the company's control. It treats load shedding and some related power conditions as force majeure. These provisions do not tell a buyer what availability is offered in a specific annexure, whether service credits apply, or how a redundant design is priced.
That missing specificity should not be filled with assumptions. A universal public agreement is not necessarily the whole contract. A buyer should request the exact order form, service description, service-level schedule, acceptable-use terms, data-processing terms and equipment list for the proposed service. Any conflict among them should be resolved before activation, especially because the public agreement says annexures can take precedence.
The strongest commercial questions are measurable. What event marks activation? What evidence shows installation acceptance? Which outages are excluded? Does response time mean acknowledgement or engineer action? Does restoration time stop when an upstream says its link is clear or when the customer verifies service? Are planned changes notified? Are credits automatic? What happens to static addresses, telephone numbers, configurations, logs and backups at exit?
The answers determine whether consolidation reduces cost. A low monthly price can be expensive if the customer must coordinate every fibre operator, prove each outage or rebuild configurations during migration. A higher price can be rational if the provider owns diagnosis, gives timely evidence and makes exit states explicit. Public materials establish the categories of cost but not a complete comparative price or service model.
The contract also makes record quality financially important. A monthly statement can be evidence of charges; equipment remains chargeable or returnable according to defined conditions; written notices affect termination; supplier changes can affect fees. If service, asset and notice records are incomplete, the dispute moves from technology into money. A good provider should be able to export a clean account of circuits, devices, recurring charges, usage items, support work and commitments.
Locality must be specified across access, routing and data
“South African provider” can describe several different facts. The company can be incorporated in South Africa. Its office and support staff can be local. Its ASN and address blocks can be registered in the AFRINIC region with country code ZA. Its network can connect at a Johannesburg exchange. Its access suppliers can build fibre in Gauteng or the Western Cape. Its customers' applications and backups can still use global cloud regions and foreign support systems.
The evidence supports the first five in bounded form. It does not establish the last layer for any customer. Netlayer's managed IT offer explicitly includes administration of global cloud platforms, but the page does not identify default regions, subprocessors, ticket locations, log retention or cross-border access. The public agreement says the parties should comply with the lawful-processing conditions in POPIA and describes personal information used to execute the agreement. That is a contractual statement, not a technical data-flow map.
A buyer with locality requirements should divide them into control objectives. Access locality concerns where the physical circuit terminates and which fibre operator carries it. Routing locality concerns where Netlayer peers or buys transit and how normal and failure paths change. Workload locality concerns where compute and storage run. Operational-data locality concerns logs, tickets, call records, endpoint telemetry and backups. Administrative locality concerns where support staff and vendors can access systems.
Each objective needs evidence suited to it. A PeeringDB entry can support exchange presence. A route observation can support origin and visibility. A cloud account export can support configured region. A contract and subprocessor list can support legal responsibility. A restore report can support backup recovery. None can stand in for all the others.
This layered approach protects Netlayer from overclaim as well as the customer from overconfidence. A regional provider should not be judged as if it promised every packet would remain inside one city when it made no such promise. Equally, a buyer should not infer sovereign data handling from a local address and ASN. Precision allows the parties to price the real requirement.
Local support can be part of locality without being reduced to geography. The important property is accountable reachability during the customer's operating hours, with authority to act and access to the relevant records. A local number that transfers endlessly is less useful than a clearly owned remote escalation. A nearby engineer without supplier case authority may be unable to restore a circuit. The service design must join place, role and capability.
A practical acceptance test for the network-service record
The public evidence is enough to design diligence, not enough to replace it. A buyer considering Netlayer could ask for a controlled acceptance process that follows one service from quote to recovery.
Start with identity and authority. The order should use the same legal entity and registration number as the agreement. It should identify the customer, site, authorized requesters, billing owner, technical owner and escalation contacts. If addresses or telephone numbers differ across documents, the parties should state which one controls notices and which one handles incidents. The ASN and address source for the proposed service should be explicit rather than inferred from the company-wide network.
Then test feasibility provenance. The quote should identify the access supplier, product, building, demarcation point, expected construction, approvals and assumptions. A feasibility result should have a date and expiry because building access and supplier coverage change. If the service uses a third-party fibre operator, the customer should know whether that operator's reference will appear in incident updates.
At installation, record physical and logical acceptance separately. Physical evidence can include the handoff location, device identity, power responsibility and observed optical or link state. Logical evidence can include assigned addresses, gateway, DNS choice, routing behavior and the customer's agreed throughput or application test. Public route visibility is relevant to provider operations, but it does not prove that the customer's last mile is healthy.
Test failure rather than only steady state. Disconnect or isolate an agreed component in a maintenance window. Observe who receives the alert, how the service is identified, whether the customer is contacted, which supplier is engaged and what evidence marks restoration. If failover is part of the offer, verify the actual traffic path, address behavior, session impact and return to normal. A diagram without a controlled exercise is a design claim.
For managed IT, select a backup sample and restore it to an isolated destination. Record the requested recovery point, actual recovered point, start time, usable completion time, integrity check and any manual work. Netlayer says it maintains and tests recovery environments; a customer-specific report would turn that activity into outcome evidence. The same principle applies to firewall review and endpoint management: ask for findings, decisions, exceptions and closure, not only a statement that an agent is installed.
Test contactability in the hours that matter. Open a low-severity case through the normal route and an agreed urgent case through the escalation route. Confirm that the responder can see the site, circuit, equipment, entitlement and recent changes. Do not create a false emergency; schedule the exercise. The objective is to see whether the support record makes the customer recognizable without a long verbal reconstruction.
Finally, test exit before signing. Ask for an inventory export and a hypothetical termination plan. It should distinguish customer-owned and provider-owned equipment, identify notice dates and charges, describe number porting, address changes, configuration handover, data export, credential transfer, log retention and deletion. The company agreement already shows that equipment, supplier costs and notice periods matter. A specific exit schedule prevents those terms from becoming a surprise.
These tests should produce bounded evidence, not a single score. A valid route origin is one passed control. A successful restore is another. A reachable escalation is another. No result should be stretched beyond its layer. The value of the exercise is that the pieces can be joined into one service record and repeated after material change.
Reliability is the ability to reconcile exceptions
A connectivity service can look simple when nothing changes. The circuit is up, the route is visible, the invoice repeats and no one calls support. The engineering and labour become visible when an exception crosses ownership boundaries.
Consider a route that remains globally visible while one office loses access. Registry and BGP monitors may look healthy because the aggregate is still announced. The access supplier may see an optical fault. Netlayer may see the customer router offline. The customer may report that only voice failed because data moved to a mobile backup. Each statement can be true. The incident record has to preserve them without collapsing the event into “internet down.”
Now consider a site move. The customer thinks an existing service is relocating. Netlayer's public terms treat the new location as a fresh feasibility and installation question. The old circuit may remain billable during notice. Equipment may need de-installation and return. Static addresses may not move in the way the customer expects. Telephone numbers may have a separate porting process. A move is a bundle of state transitions, not an address edit.
Registry maintenance produces another class of exception. A contact leaves but remains in an entity. A new engineer can operate the network but cannot submit an authorized resource request. A valid ROA permits a more-specific route that monitoring did not expect. PeeringDB is not updated after IPv6 activation. None of these necessarily interrupts traffic immediately. All can increase recovery time later.
The small disagreement in Netlayer's public data is instructive. Route collectors saw an active IPv6 /32 with a valid origin, while the PeeringDB profile's summary fields said zero IPv6 prefixes and its exchange entries exposed no IPv6 address. That is not proof of a fault. It is a normal example of records maintained for different purposes and at different times. The operating task is to know which source is authoritative for each question and to reconcile material differences.
Automation should make those distinctions visible. It can compare expected and observed origins, flag stale contacts, relate an access alarm to the correct supplier and attach a contract entitlement to a support case. But automated correlation needs stable identifiers and human review. Similar company names, reused addresses and shared infrastructure can create false joins. An alert that confidently assigns the wrong owner is worse than an explicit unknown.
Reliability therefore includes recoverability of the record itself. Network configurations, address assignments, supplier references, customer authorizations and incident histories need backups, access controls and change history. A provider may restore traffic after a router replacement while losing the explanation of what changed. That can leave the next failure harder to diagnose. Technical restoration and operational memory are both part of continuity.
Public sources cannot show whether Netlayer has achieved that standard internally. They show that the company operates in a domain where it is necessary, and they expose enough coherent identifiers to make accountability possible. The buyer's task is to ask for repeatable evidence at the service boundary rather than infer quality from scale or membership.
The commercial comparison is consolidation versus retained control
Netlayer's offer competes with at least three alternatives. A business can buy access, voice and support separately from specialist providers. It can buy a broader managed package from a larger carrier or service company. Or it can retain more network and cloud operations in-house while purchasing only circuits and vendor support.
Consolidation can lower coordination cost. One provider can hold the site inventory, understand the router and firewall, see recurring incidents and manage supplier tickets. A small business without a network team may value a single accountable support route more than a long list of component prices. Netlayer's mix of fibre, VoIP and managed IT is designed for that need.
The economic risk is that consolidation hides pass-through dependence. A single invoice does not remove fibre-operator lead times, cloud-vendor incidents, licence terms or equipment constraints. It changes who reconciles them. The buyer should ask whether Netlayer absorbs that work inside the service or bills each coordination step. The managed-support page's 15-minute billing and block-hour language makes this a contract question rather than an abstract concern.
A larger provider may offer a wider footprint, more published metrics or deeper staffing. It may also have slower escalation and less knowledge of a small customer's environment. A self-managed model gives the customer direct control of accounts, configurations and monitoring, but requires skilled labour, after-hours coverage and disciplined record keeping. The cheapest circuit price does not settle the comparison.
Migration cost is a decisive part of the calculation. If Netlayer supplies the router, addresses, voice service, endpoint agents, cloud administration and backups, changing providers can touch many systems. That can be acceptable when ownership and export rights are clear. It becomes lock-in when the customer cannot obtain current configurations, asset lists, credentials, number-porting information or usable data without disruption.
The public agreement shows notice, equipment and supplier costs that a customer should model. It does not provide the figures for a particular service annexure. A fair commercial evaluation would calculate the total operating cost under normal service, a material outage, a site move and an exit. It would assign internal staff time as well as provider fees. It would also value faster recovery if a consolidated provider can demonstrate it.
The registry and routing evidence contributes to this comparison in a limited way. Operating an active ASN, originating IPv4 and IPv6 space, publishing valid origin authorizations and maintaining exchange connections all indicate real network responsibilities. They distinguish Netlayer from a brand with no visible routing identity. They do not quantify support quality or make the company automatically superior to a reseller, because a reseller can still deliver an excellent managed service and a network operator can still deliver poor customer support.
The best buying decision treats the visible network as one asset and the accountable service as another. AS328222 demonstrates that Netlayer has a public routing identity. The contract, acceptance tests, support record and exit design determine whether that identity creates value for the customer.
What the public record cannot establish
The limits are substantial and should remain explicit. No direct customer service was ordered or tested for this assessment. There is no representative sample of Netlayer circuit performance, fault response, voice quality, managed-service outcomes or recovery results. Public sources do not disclose customer counts, revenues, backbone topology, router configurations, physical diversity, capacity utilization, packet loss, latency distributions or incident history.
The route observation is a snapshot. It shows aggregate origins visible through RIPE RIS at a stated time. It cannot establish historical availability across a contract period or predict future routing. The RPKI results validate the observed origin pairs, not the full AS path, customer configuration or application security. PeeringDB fields are operator-contributed directory data and can be incomplete or stale. Its listed capacity is not a traffic measurement.
The legal and industry records have boundaries too. The company-hosted copy of a communications licence certificate and the licence identifiers on Netlayer's site were not a live regulator-status determination. ISPA membership indicates participation in that industry body's framework, not an endorsement of every service outcome. AFRINIC membership and active resource status do not certify business solvency, support quality or regulatory compliance.
The company website is evidence of what Netlayer offers and claims, not independent verification of those claims. Statements about reliability, experience, scheduled testing and service coverage need customer-specific documentation and results. The public agreement may be supplemented or superseded by annexures; it should not be assumed to contain every term offered to every buyer.
Data locality remains particularly uncertain. South African registration, address space and Johannesburg peering do not establish where customer content, backups, tickets, telemetry or voice records reside. No conclusion should be drawn about a specific customer's POPIA compliance without a mapped processing purpose, data flow, contract and legal assessment.
These limits do not make the evidence useless. They make it properly scoped. The public record can establish a coherent identity, registered resources, observed aggregate routes, valid origins, disclosed exchange attachments, service categories, supplier dependence and contact surfaces. It cannot transform those facts into an unmeasured promise.
The verdict: a credible network identity that still needs service proof
NETLAYER (PTY) LTD has more than an AFRINIC membership line. The legal entity joins convincingly to AS328222, a South African website and contract, registered IPv4 and IPv6 space, current route visibility, valid route-origin authorizations, PeeringDB records and an ISPA listing. Those are concrete, mutually reinforcing signals of an operating network identity.
The evidence also explains why membership should not carry the whole decision. Netlayer's service reaches customers through fibre operators and backhaul providers. Its managed offer reaches into cloud, endpoint, firewall and recovery systems. Its public interconnection record is useful but incomplete, and some fields disagree with observed IPv6 state. Its general agreement allocates important responsibilities without publishing a complete service schedule for every offer.
The technical test is whether Netlayer can keep the joined record fresh under change: legal identity, authorized contacts, resources, expected routes, origin authorization, supplier orders, circuits, equipment, incidents and recovery evidence. The commercial test is whether the company accepts enough of that reconciliation work to justify its price and the customer's migration exposure.
A buyer should credit the active routing and valid authorization. It should also ask for a service-specific topology, support schedule, acceptance test, incident example, data-location statement and exit inventory. If those artifacts agree with the public network identity, Netlayer's consolidation proposition becomes stronger. If they do not, an ASN and membership record cannot repair the gap.