Summary

  • APNIC identifies active AS131567, named DOUBLENET, and active portable IPv4 allocation 103.96.8.0/22 with Fnetlink International Co., Ltd. Both records publish a Shenzhen contact surface and were last changed in November 2023. That is strong resource-attribution evidence, but it is not a customer-service certification.
  • RIPEstat observed AS131567 originating the /22 through the two weeks ending July 13, 2026. Its routing snapshot showed the prefix to 37 of 325 listed IPv4 RIS peers and no IPv6 origin. The route was visible, but the evidence does not establish universal reachability, packet performance or customer uptime.
  • The observed prefix-origin pair was RPKI-valid. That reduces uncertainty about whether AS131567 was authorized to originate the route; it does not validate the full path, physical diversity, application security or operational recovery.
  • Every path in the returned BGP-state snapshot reached AS131567 through AS56040, while PeeringDB returned no public network entity for AS131567. Those are useful questions about interconnection and resilience, not proof of one physical circuit, one commercial supplier or an absence of private peering.
  • The Fnetlink website presents SD-WAN, cloud, security, managed operations and local support, but its footer names a different Fnetlink company. A buyer should require the contract, resource records, support team, service locations, monitoring evidence and exit obligations to identify which Fnetlink entity is accountable for each part of the service.

A network-service name is the beginning of the inquiry

Internet infrastructure produces unusually persuasive labels. An autonomous system has a number. An address block has clear boundaries. A registry record names contacts and a country. A route collector can show a path. These fields appear precise enough to stand in for the service itself. They should not.

The name DOUBLENET illustrates the problem. In the APNIC autonomous-system record, it is the name attached to AS131567, with Fnetlink International Co., Ltd. in the description. In ordinary commercial language, however, "double net" can suggest redundancy: two carriers, two paths, two devices or a resilient overlay. The public record does not define the name that way. It establishes a registered routing identity, not a dual-network architecture.

That distinction changes how the evidence should be used. A buyer should not ask whether the name sounds like a network provider. The buyer should ask which legal entity controls the number resources, which routes are observable, which organization supplies the access circuits, which platform sets routing policy, which team watches alarms, which party accepts a fault and which assets can be recovered when the relationship ends. The public evidence can answer parts of the first two questions. It gives only company-authored indications for the others.

This is not a reason to dismiss the records. They are among the most useful external facts available for a network-service assessment. They are structured, attributable and independently queryable. They can expose stale contacts, invisible routes, unexpected origins, authorization gaps and differences between a brand website and the network carrying the brand's service. Their value comes from respecting their scope.

For Fnetlink International Co., Ltd., the central finding is neither that the record is empty nor that it proves the whole service proposition. The registry and routing evidence form a coherent but small operating surface: one active ASN, one active portable IPv4 allocation, one observed IPv4 origin, one valid origin authorization and a narrow set of observed paths. Around that surface sits a much larger Fnetlink presentation involving SD-WAN, cloud management, security, offices, local engineers and a global backbone.

The analytical work lies in deciding where the narrow record supports the broader proposition and where the join remains unproven.

APNIC supplies a strong identity anchor

The best-supported statement about the assigned company is specific. APNIC's RDAP response marks AS131567 active, names it DOUBLENET, assigns country code CN and describes it as Fnetlink International Co., Ltd. The record gives a registration event dated 2 March 2020 and a last-change event dated 28 November 2023. It publishes one named administrative and technical contact, an abuse role, a Shenzhen address, a telephone number and email at fnetlink.com.

The address record makes a parallel assertion. It covers 103.96.8.0 through 103.96.11.255, the 1,024-address range expressed in routing as 103.96.8.0/22. APNIC calls the resource an active portable allocation, names it DOUBLENET, codes it CN and again describes Fnetlink International Co., Ltd. The address record shows a registration event dated 29 June 2017 and the same November 2023 last-change date as the autonomous-system record.

The repeated legal description, name, domain, address and contacts make the identity join stronger than a search result or a similar brand name. They support the proposition that the registry associates this company with these resources. The portable designation is also relevant. It describes the registration category of the address space rather than a block merely borrowed from the immediate visible network in a route path. It does not, by itself, grant a customer portability rights over an address assigned from the block.

Even this strong identity anchor has limits. APNIC's active field is a state in the resource database. It does not mean the company is actively selling a particular service, that every contact will answer, that the holder is in good financial standing, or that all addresses are being used. "Last changed" means the record was modified at that time; it does not say every field was separately recertified or every telephone and mailbox was exercised.

The difference between the dates also deserves restraint. The address allocation's 2017 registration event predates the autonomous system's 2020 event in the current responses. That does not reveal what commercial service existed at either date, whether another origin was used, or when a customer first received traffic. A resource can be allocated before it is announced through a particular ASN. A later registration event can also reflect administrative history that is not fully represented in a simple timeline.

What the records do provide is accountability at the resource layer. If an unexpected origin appears, if an abuse report concerns an address in the range, or if a route authorization needs correction, there is a named record and a set of roles from which to begin. A procurement team should preserve those identifiers in the service inventory. "Fnetlink internet" is too broad to diagnose. AS131567, 103.96.8.0/22, the contracted circuit identifiers, the supplying entity and the support entitlement are operationally useful.

Registration does not reveal how the addresses are used

A /22 is large enough to be visible as an aggregate but small enough to invite misleading arithmetic. It contains 1,024 IPv4 addresses. That count does not reveal 1,024 customers, devices, sites or services. Some addresses may be infrastructure; some may be assigned to customers; some may remain unused; some may be reserved; some may be hidden behind more complex designs. Public registration does not provide an allocation ledger.

Nor does the country code locate every endpoint. CN is a registry attribute attached to the resource record. The contact address is in Shenzhen. Those facts support a Chinese administrative context. They do not prove where routers are installed, where packets are inspected, where logs are stored, where a managed-service operator sits, or where an enterprise customer's applications and data reside.

The difference matters for data-sovereignty claims. An enterprise can buy one managed network whose access circuits, overlay controller, security inspection, monitoring, ticketing and cloud gateways operate in different jurisdictions. A registry country code may accurately describe the resource while saying almost nothing about those other layers. Conversely, a globally distributed service may intentionally use Chinese-registered resources at a defined edge. Neither architecture can be inferred from the code alone.

The address record also does not show whether a prospective customer's service would use this range. Fnetlink's brand pages discuss multiple forms of connectivity, cloud access and managed networking. A particular branch could receive carrier-supplied addresses, private overlay addresses, addresses from another Fnetlink-associated resource or customer-owned space. The existence of 103.96.8.0/22 makes a direct question possible: which addresses and origin apply to the quoted service? It does not answer it in advance.

That question should be resolved in an address plan connected to the contract and configuration record. The plan should identify address ownership, assignment, translation, advertisement, reverse DNS where relevant, authorized origins, filtering, renewal or retention conditions, and the consequences of changing supplier. Without that record, a portable allocation held by the provider can still produce a non-portable customer dependency.

Public reverse lookups for sample addresses at the start of each /24 within the allocation did not return names during the observation. That absence is not a finding of inactivity or poor management. Reverse DNS can be delegated, selectively populated or unnecessary for many uses. It simply means those sample checks supplied no public description of workload or location, reinforcing the need not to infer use from the block size.

The route was visible, but visibility was not universal

Registration becomes more informative when an independent observer sees a matching route. The RIPEstat announced-prefix response showed 103.96.8.0/22 throughout its returned interval from 29 June to 13 July 2026. The prefix overview marked the aggregate announced and associated it with origin AS131567, using the holder string "DOUBLENET - Fnetlink International Co., Ltd."

This agreement is meaningful. APNIC associates the company with the ASN and address range. RIPEstat observed that ASN originate that range. The records therefore align at the aggregate control-plane level. The simplest dormant-record hypothesis, in which resources remain registered but have no qualifying public route, does not fit the July snapshot.

The routing-status response supplies the necessary qualification. It counted one announced IPv4 prefix covering 1,024 addresses and no IPv6 announcement. At the snapshot time, 37 of 325 listed IPv4 RIPE RIS peers saw the route. The response's first qualifying sighting was 28 October 2021, and its current last sighting matched the 13 July 2026 query time.

Thirty-seven out of 325 is evidence of real propagation, but not broad enough to translate casually into "the internet could reach it." RIPE RIS peers are collector feeds, not a census of every network or user. Peers differ in location, connectivity and policy. Some may receive a route that others filter or never learn. A route can be deliberately limited. Collector methodology can also treat low-visibility information differently across endpoints and time.

The correct sentence is therefore narrow: RIPEstat saw the route from 37 of its 325 listed IPv4 peers at that snapshot. It is not correct to say that the remaining peers proved an outage, that 11.4 percent of the internet had reachability, or that the route was unavailable to the rest of the world. Collector ratios are not end-user market shares.

The observation also does not prove packet delivery. BGP distributes reachability information. A prefix can be visible while a router drops traffic, a customer access circuit is down, a firewall blocks an application, a DNS record is wrong or a service has failed. Conversely, a private service can operate without a globally visible customer prefix. The route establishes a control-plane state, not an application-level outcome.

Freshness is another part of the value. A route statement without its observation time decays rapidly. The same prefix could be withdrawn, propagated more widely, moved to another authorized origin or split into more-specific routes later. Operational use requires a time series and an expected-state model: which origins and prefixes should exist, how visible should they be, what changes are planned, and which deviations trigger action.

For a customer, the public snapshot should lead to service-specific evidence. A provider can show whether the quoted connection uses AS131567, whether the customer's addresses come from this aggregate, which monitoring points test reachability, which applications are probed, how loss and latency are measured, and how routing changes are approved. Public observation is valuable precisely because it gives the parties an external fact to reconcile with the internal service record.

A valid origin answers one security question

The RPKI result is the strongest positive security signal in the public routing evidence. The RIPEstat validation response marked the pair of AS131567 and 103.96.8.0/22 valid. It listed an authorization for the same origin and aggregate, with a maximum length of /24.

In practical terms, the observed origin matched a cryptographically verifiable statement about which autonomous system was permitted to originate the prefix. The maximum-length setting means qualifying more-specific routes down to /24 can also be valid when originated by AS131567. That supports legitimate traffic engineering or more-specific announcements within the authorization. It does not show that any such more-specific was present in the snapshot.

The IETF's Route Origin Authorization guidance and BGP origin-validation standard define a deliberately bounded mechanism. Origin validation checks the relationship among prefix, prefix length and origin ASN. It does not sign or validate every intermediate ASN in the path. It does not prove the router belongs in a stated building. It does not encrypt traffic, authenticate users, scan malware, protect a cloud account or guarantee that a route will remain visible.

That limitation should not obscure the benefit. A valid result removes one common ambiguity: the current origin was not merely an unexplained ASN announcing the range without a matching authorization. For a small public routing surface, maintaining a valid authorization is a concrete control. The alternative states, invalid or not found, would create different questions about authorization, prefix length, configuration and filtering.

The operational test is whether the authorization remains synchronized with intended routing. A route migration can fail if a new origin is announced before its authorization exists. A stale authorization can permit an old origin longer than intended. An overly broad maximum length can expand the set of technically valid more-specifics. A restrictive maximum length can make legitimate traffic engineering invalid. The public result shows a sound match at one moment; governance determines whether future changes preserve it.

A customer should therefore ask who owns the authorization process, who can approve a change, how expiry and repository health are monitored, what pre-change checks occur, and how an invalid state is reversed. Those are not ceremonial questions. Networks increasingly use route-origin validation in import policy. A mistake can change propagation even when the underlying fibre and routers are healthy.

For Fnetlink International Co., Ltd., the valid aggregate origin is evidence in favor of basic resource discipline. It is not a blanket "secure network" badge. Any commercial presentation that combines routing security, SD-WAN security, SASE, endpoint protection and service availability should keep their measurements separate. An authorized route can lead to an insecure application; a protected application can sit behind a route with poor resilience. Both layers matter, and neither substitutes for the other.

The observed path raises a diversity question, not a verdict

RIPEstat's BGP-state response returned 40 paths for the /22. In each displayed path, AS56040 appeared immediately before a repeated terminal sequence of AS131567 AS131567. Hurricane Electric's AS summary and the CIDR Report also presented one observed adjacent ASN. The latter explicitly warns that "upstream" in its report describes topology relative to the observation and should not be confused with a commercial relationship.

The repeated terminal ASN can be consistent with AS-path prepending, in which an origin repeats its own number to influence route selection. The public path does not expose the router policy or intent, so it should not be described more strongly. It is an observed path shape.

Likewise, the single immediate adjacency across the returned views is a concentration signal, not proof of a single physical dependency. Multiple circuits can connect the same pair of autonomous systems. They may use separate buildings, ducts, devices or suppliers, or they may share all of them. Private interconnections might not appear in the public route view. Backup arrangements may be withdrawn until needed. A different collector set may see more paths.

At the same time, a buyer should not allow those possibilities to dissolve the question. If every public path arrives through one adjacent ASN, the provider should be able to explain the resilience design for the service being sold. How many access circuits exist? Are edge routers separate? Which facilities, power domains and physical routes are involved? Is a backup route continuously exercised or merely documented? Does failover preserve addresses and sessions? What monitoring proves the alternate can carry the intended load?

The PeeringDB API query returned no discoverable network entity for AS131567 at the observation. That removes one convenient source of self-published exchange, facility and policy data. It does not prove the network has no peering or exchange presence. PeeringDB is voluntary, public entries can be incomplete, and private arrangements are not necessarily disclosed.

Absence still has a commercial effect: the buyer has less public information with which to cross-check interconnection claims. The provider may compensate with a current architecture summary, facility evidence, carrier letters, route-monitoring history and a clear statement of which details are confidential. "Not public" can be a legitimate boundary. "Not attributable" is a service-management weakness.

The narrow public route also puts the DOUBLENET name in perspective. Nothing in these observations establishes two autonomous upstreams, two independent internet paths or dual-site resilience. If the name is used commercially to imply redundancy, that design must be shown at the service level. If it is simply a registered network name, no redundancy claim follows from it.

The Fnetlink brand describes a much larger service surface

Fnetlink's English-language website presents six broad service families: SD-WAN, LAN/WAN convergence, MSP cloud services, cloud-network security, traditional networking and value-added services. It describes branch-to-branch, branch-to-data-centre and branch-to-cloud connectivity; centralized equipment management; cloud migration and maintenance; MPLS, IPSec, SSL and dedicated access; WAN optimization; IP services; hosting; DNS and managed operations.

That is an expansive proposition. It is not merely the sale of capacity from one ASN. It combines access sourcing, overlay policy, equipment, cloud services, security partners, monitoring, field delivery and human support. A customer may experience it as one managed network even though several companies and carriers contribute to it.

Huawei provides independent support for part of the brand story. In 2018, Huawei named Fnetlink among organizations choosing its SD-WAN solution. In 2025, Huawei described a SASE showcase launched with Fnetlink and called Fnetlink a strategic partner. These statements make a technology relationship more credible than a one-sided logo display.

They do not identify AS131567 as the transport for every deployment. They do not establish that Fnetlink International Co., Ltd. signed the partner agreement, owns the platform or contracts with each customer. They do not convert Huawei's product-level detection or automation claims into measured outcomes for Fnetlink's customers. Partner evidence, product evidence and service evidence remain separate.

The corporate naming on the website is especially important. Its footer names Shenzhen Fnetlink century Information Technology Co. Ltd. The APNIC resource description names Fnetlink International Co., Ltd. Macao public records name Fnetlink Technology Company Limited in connection with SD-WAN research. These may be related within a wider group, but the observed public pages do not establish the ownership and contracting chain among them.

That ambiguity is manageable when the contract is precise. A service schedule can name the contracting supplier, each important subcontractor, the resource holder, the platform provider, the support operator and the legal entity responsible for service credits, data processing and termination. It becomes risky when the brand name is used as if all entities, resources and commitments were interchangeable.

The website's own hosting provides a useful example of separation. During the observation, the fnetlink.com apex resolved to 47.107.231.203. RIPEstat associated the covering announced range with Alibaba origin AS37963, not AS131567. That is entirely plausible: a network company can host its public website on a cloud platform. It also proves why domain, brand and autonomous system should not be collapsed into one identity. The website can be available while the assigned ASN is not, and the reverse can also occur.

SD-WAN shifts the product from a route to an operating record

The Fnetlink SD-WAN page describes application-aware routing, intelligent acceleration, hybrid WAN connectivity, branch-to-cloud interconnection, monitoring and managed engineer service. These functions move decision-making above the public BGP route. A customer may have several underlay links while an overlay controller chooses paths by policy, application and measured state.

That architecture can improve flexibility, but it makes accountability more data-dependent. The service is no longer represented adequately by "circuit up" or "prefix visible." The provider needs a maintained model of sites, devices, links, tunnel endpoints, applications, policies, thresholds, alarms, changes, entitlements and dependencies. Automation acts on that model. If the record is wrong, automation can repeat the wrong action faster and across more sites.

Fnetlink's service-advantage page refers to visualized configuration management, customized intelligent detection, monitoring, programmable fault self-healing, IT service-management processes and task platforms. These are relevant capabilities. The public description does not show the control boundaries: which faults are eligible for automatic action, which changes require approval, how rollback is performed, how a false alarm is handled or how a customer can audit the result.

The technical diligence should therefore focus on repeatability and recovery. Can a new branch be created from an approved configuration pattern? Are device and controller versions recorded? Does the provider detect drift between intended and actual policy? Can it show who changed a routing rule and why? If an automated remediation worsens an incident, can the prior state be restored without reconstructing it from memory?

Monitoring also needs an explicit entity. The brand website refers to 24-hour operations and high backbone availability. A useful customer report would distinguish backbone components, underlay circuits, overlay tunnels, application probes, customer-premises devices, security functions and cloud gateways. An aggregate operations-centre percentage cannot tell a branch whether its critical path was healthy.

The support page offers illustrative scenarios involving congestion, customized alarms and temporary bandwidth changes. They reveal the intended operating experience: engineers can inspect traffic, customers can use a portal, thresholds can trigger notifications and service capacity can be changed. Because these are company-authored scenarios, they do not establish that every account receives the functions or that response is timely. They are useful as acceptance-test candidates.

A buyer could turn each scenario into a contractual demonstration. Show a controlled threshold breach and the resulting alert. Trace the alert into a ticket. Identify the device and circuit. Record acknowledgement, diagnosis, authorization, change and closure. Reverse a temporary bandwidth change at the promised time. Export the history. Demonstrate that a customer can distinguish its own actions from provider actions. Those steps test the operating record rather than trusting the adjective "intelligent."

No direct service demonstration was available for this assessment. There was no tenant, portal, customer circuit, device, support entitlement or private report. The public material can establish what the brand says it offers and what questions the design should answer. It cannot establish that an individual deployment is configured correctly, continuously monitored or recoverable.

Local support must be tied to authority and labour

The contact page publishes distinct channels for purchase consultation, after-sales service, security support, complaints and business cooperation. It lists a Shenzhen headquarters and offices or branches in several Chinese cities as well as Hong Kong, Macao, Taiwan and Vietnam. The about page describes a wider service-point network and a large technical team.

Published channels are better than a generic form because they suggest functional separation. A security incident should not depend on a sales inbox. A complaint should have a route outside the team handling an ordinary ticket. A field deployment needs different coordination from a routing-policy change. Yet the page proves only that the contact information was displayed and reachable by HTTP. No call was placed, no email was sent and no response was measured.

The APNIC record adds another contact surface. Its address differs from the current headquarters address on the website, and its named technical contact is not the same thing as a support queue. Differences can be benign: an office can move, a registry contact can retain a specialized role, and a group can operate multiple locations. They still need governance. When a route is wrong at 03:00, the team should know whether to use registry authority, network operations, a carrier escalation or an account contact.

"Local support" also needs definition. A local telephone number may be answered centrally. A listed office may house sales rather than network engineers. A field engineer may be a subcontractor. A 24-hour operations centre may monitor alarms globally but lack authority to approve a carrier change in one jurisdiction. None of these arrangements is inherently defective. The buyer needs to know which one applies.

Labour evidence should be attached to tasks. Who performs site surveys? Who installs and replaces customer equipment? Who can change an overlay policy? Who can update APNIC records or RPKI authorization? Which language is available during an incident? Which hours have on-site coverage? Which parts are stocked locally? Which subcontractor receives customer information? General headcount and office counts do not answer those questions.

The service model is strongest when responsibility survives organizational change. Named individuals are helpful for escalation but fragile as the sole control. Role accounts, documented authority, on-call rotation, ticket history, access review and handover records make support recoverable when an employee leaves or an office changes. The same principle applies to registry contacts: one person's name should not be the only path to control of a long-lived internet resource.

Procurement should ask for an escalation exercise before a critical rollout. Open a low-severity ticket through the contracted channel, confirm entitlement, follow the handoff between help desk and network team, and inspect the closure record. Then rehearse the emergency path without manufacturing a real outage. The aim is not to catch a supplier out. It is to make sure both parties know the boundary before pressure exposes it.

Locality claims require a layer-by-layer answer

Fnetlink's website presents a global network and local service coverage. Those concepts are commercially attractive because multinational enterprises need both reach and nearby support. They are also easy to overstate. A city on a website is not proof of a point of presence, and a point of presence is not proof that customer data stays in that city.

Locality has at least six layers. The access circuit has a physical path and handoff. The routed underlay has origins and interconnection. The overlay has controllers and gateways. The security service has inspection and policy locations. The management system has configuration, telemetry and ticket data. The support organization has people and subcontractors. Each can occupy a different jurisdiction.

APNIC supplies evidence for the administrative location of the resource. The website supplies company-originated claims about offices and network reach. The route collectors supply path visibility without a physical map. None identifies where a particular customer's payload, metadata, credentials, logs or backups reside. A buyer with sovereignty obligations needs a service-specific data-flow statement, not an inference from the ASN country.

That statement should name data classes and purposes. Packet payload may cross a gateway without being retained. Flow telemetry may be stored for analysis. Configuration can reveal network structure. Tickets can include employee names, addresses and incident details. Security logs can contain identifiers or content fragments. Backups and analytics copies may live longer or farther away than the live system.

The statement should also cover operational access. Data can remain in one jurisdiction while an engineer elsewhere can view or change it. Conversely, a local engineer can work on equipment whose controller and audit history are abroad. Sovereignty decisions often turn on access, control and disclosure as much as storage location.

Migration brings locality back into view. Moving away from an SD-WAN or managed-security service can require configuration exports, log retention decisions, replacement addressing, new circuits, DNS changes, certificate handling and deletion across several systems. If those assets are held by different Fnetlink entities or partners, the exit plan must assign each action and jurisdiction.

The public record does not establish a problematic location, nor does it prove an acceptable one. It establishes why the question cannot be answered with CN, a city list or a global-backbone graphic. The appropriate evidence is a contractually bounded architecture for the customer service, refreshed when topology or suppliers change.

Reliability must be measured across the whole service boundary

The Fnetlink site advertises a high backbone-availability figure and 24-hour monitoring. Those claims may refer to a defined internal service, but the public pages do not expose the denominator, observation period, exclusions or remedy. A percentage without the measured entity cannot be mapped to a customer's experience.

A branch connection can fail while the backbone remains available. The access carrier can cut fibre. Customer equipment can lose power. An overlay tunnel can fail authentication. A routing policy can steer an application onto a congested link. A cloud gateway can be healthy while the destination application is down. The provider may satisfy one component target while the business process remains unavailable.

The useful service level is therefore a chain of indicators. Access availability covers the circuit. Underlay measures cover loss, latency and reachability. Overlay measures cover tunnels and path selection. Application probes cover the destinations users need. Support measures cover acknowledgement, ownership, updates and restoration. Recovery measures show that configurations, logs and replacement equipment can be restored.

The public route offers one external indicator in that chain. Its limited collector visibility makes it particularly important to define the expected pattern. If the route is intentionally regional or selectively propagated, what observation points represent the intended users? If broader visibility is expected, what baseline and alarm threshold apply? Does the provider distinguish a route withdrawal from a collector anomaly? Who decides whether a change is planned?

RPKI status is another indicator. It can be continuously checked and tied to change management. Contact records can be reviewed on a schedule. DNS, portal and support endpoints can be observed. None alone demonstrates reliability. Together, they form a control surface that is more robust than a yearly availability claim.

Failure evidence should also have closure criteria. An incident should not close merely because a circuit changed to "up." The record should show that the affected application recovered, queued traffic cleared, temporary routing was removed where appropriate, monitoring returned to baseline, and the customer accepted or was informed of the outcome. Repeated faults should connect to a problem record rather than appearing as unrelated tickets.

No such customer history was public. It would be irresponsible to invent an outage rate, restoration time or service quality from route data. The public evidence can show that the aggregate route existed and had a valid origin. Reliability beyond that remains a matter for contract, monitoring history, acceptance exercises and customer-specific observation.

Commercial value depends on what the managed boundary replaces

Fnetlink's proposition is potentially valuable because enterprise WAN work is fragmented. A customer can otherwise coordinate local carriers, routers, security appliances, cloud gateways, monitoring systems and support teams separately. A managed provider may reduce that coordination burden, standardize deployments and create one operational view.

The relevant comparison is not simply the provider's fee against raw bandwidth. It is the total cost of obtaining and governing the same result. Self-management requires skilled labour, tools, on-call coverage, carrier relationships, spare equipment, security review, documentation and recovery capability. A provider can spread some of those costs across customers.

Consolidation also creates dependency. The more a provider controls routing policy, configurations, monitoring history, device licences, address assignments and support knowledge, the harder it may be to change provider. A low operating price can be offset by a costly or risky exit. The commercial question is whether reliability, locality, support and reduced coordination justify both the recurring price and the migration exposure.

Public evidence does not provide a standard Fnetlink price or contract. It does not show service credits, termination assistance, export formats, configuration ownership or address-transfer rights. Those omissions are not unusual for enterprise networking, where proposals are customized. They make the commercial schedule the decisive evidence.

The schedule should separate recurring and one-time costs. Access circuits, overlay licences, equipment rental, cloud gateways, security services, monitoring, field support and after-hours work should not be hidden inside one label if their renewal and exit rules differ. The customer should know which services continue when one component is terminated.

Migration costs should be estimated before signature. Can configurations be exported in a usable form? Who owns device credentials and certificates? How long are logs retained and in what format can they be delivered? Can the old and new overlays operate in parallel? Does the customer have to renumber? Are circuits transferable? Who removes equipment and certifies deletion? What support is available during the cutover?

The 103.96.8.0/22 allocation belongs at the provider-resource layer in this analysis. Its portable registry status does not mean a customer address from the range can leave with the customer. If stable public addresses matter, the contract should state whether the customer receives provider-assigned or customer-controlled space and how transition will work.

A managed boundary earns its premium when it is explicit. The provider accepts named responsibilities, supplies evidence, resolves cross-supplier faults and leaves the customer with a recoverable record. It loses value when the brand promises one-stop service but incidents still require the customer to discover which entity, carrier or partner owns each failure.

A practical diligence scorecard

The public record supports a structured assessment without pretending to answer private service questions. The first category is identity. The contract should use the exact legal name of the supplier and identify its relationship to Fnetlink International Co., Ltd., Shenzhen Fnetlink century Information Technology Co. Ltd., Fnetlink Technology Company Limited and any other involved company. It should state which one holds the network resources, operates the platform, invoices the customer and accepts liability.

The second category is resource governance. The supplier should list the ASNs and prefixes relevant to the service, identify registry and RPKI owners, document expected origins and maximum lengths, and show how contacts are reviewed. The observed valid origin is a positive starting point. The changed-in-2023 registry fields should be checked against current authority rather than assumed current forever.

The third category is route and physical resilience. Ask for intended propagation, upstream and interconnection design, facilities, edge devices, circuit diversity and test history. Reconcile that explanation with the public observation of one immediate adjacent ASN and limited RIS-peer visibility. A satisfactory answer can include non-public arrangements, but it should identify the evidence by which the customer can verify failover.

The fourth category is service automation. Inventory controllers, devices, templates, policies, alarms, runbooks, approvals and rollback. Demonstrate branch provisioning, alert creation, policy change and restoration. Define which actions are automatic and which require human approval. Require an audit trail that a customer can export.

The fifth category is support. Map sales, implementation, network operations, security response, carrier escalation, complaints and executive escalation to contracted channels and hours. Identify the countries and employment or subcontracting model of the people who can see customer data or change service. Exercise the path before launch.

The sixth category is locality and data governance. Obtain a data-flow description for payload, telemetry, configuration, credentials, logs, tickets and backups. Record storage, processing and remote-access locations. Require notice when a supplier, controller region or support location changes. Do not use the ASN country as a substitute.

The seventh category is service evidence. Define component and end-to-end measurements, observation points, maintenance, exclusions, incident updates and service credits. Ask for a representative historical report with customer information removed. Confirm that route, tunnel and application states are not collapsed into one percentage.

The eighth category is recovery and exit. Test configuration export and restoration, not merely backup creation. Define log delivery, credential transfer, certificate revocation, address transition, parallel operation, equipment return and deletion evidence. Price termination assistance and cutover work in advance.

The final category is change. The service record should identify who can alter routes, origin authorization, controller policy, security rules and support entitlement. Each material change needs an owner, purpose, approval, implementation evidence and rollback state. A network that is healthy on installation day can become fragile through undocumented accumulation.

This scorecard is intentionally more demanding than a brand comparison. It follows the actual operating surface. It also gives a capable provider room to demonstrate value. Strong answers about monitoring, local support, recovery and supplier coordination can justify a managed-service premium even when the public ASN is small. Weak answers cannot be rescued by a large office list or a technically valid route.

The evidence supports a bounded conclusion

Fnetlink International Co., Ltd. has a more substantive public network record than its name alone. APNIC associates it with active AS131567 and active portable allocation 103.96.8.0/22. RIPEstat observed the ASN originate the aggregate through the returned two-week interval. The origin authorization was valid. Those facts create a coherent chain from company description to number resource to observed route.

The chain is narrow. The route reached 37 of 325 listed RIPE RIS peers at the snapshot, no IPv6 origin was observed, the returned public paths shared one immediate adjacent ASN, and PeeringDB offered no public entity. None of those facts proves poor service. Together, they define the questions a buyer should resolve about propagation, diversity, IPv6, interconnection and recovery.

The larger Fnetlink service story is plausible in important respects. The brand publishes detailed service and support descriptions, and Huawei independently confirms a relationship around SD-WAN and SASE. But the website, partner statements, Macao research records and APNIC entry use different Fnetlink legal names. Public evidence does not show that the assigned company is the contracting or operating entity for every advertised capability.

The sensible judgment is therefore evidence-based and conditional. Credit the resource holder for an attributable, currently observed and origin-authorized IPv4 route. Do not turn that into an assumption about global reach, customer uptime, data locality, support performance or product ownership. Require the commercial service to join the legal entity, resources, platform, carriers, people, measurements and exit plan into one accountable record.

That is the real test behind DOUBLENET. Redundancy is not a name, and managed networking is not a collection of claims. It is the ability to show which path and team own a service now, detect when that state changes, recover when it fails, and let the customer leave without losing the information needed to operate.