## 1. Ground Verification in Documented Capabilities
When evaluating networking gear for a Kenyan ISP deployment, the starting point must be the manufacturer’s documented feature set, not promotional language. Regulatory compliance, power budgets, interface counts, and supported protocols should all be traceable to data sheets, firmware release notes, or the vendor’s support portal. Marketing claims such "up to" speeds or "cloud-managed" often omit context—such as aggregate bandwidth limits, NAT throughput under specific packet sizes, or the number of concurrent PPPoE sessions a platform can sustain. Before committing hardware, map each claimed capability to a concrete operational requirement, such as the number of Hotspot users per site or the PPPoE session limit required by the service plan.
## 2. Align Router Model with Provisioning Workflow
The CENTRANET provisioning guide makes clear that router onboarding is not a generic "import configuration" exercise. A MikroTik router must run RouterOS 7.20 or newer, must have internet access over HTTPS for the agent to connect outbound, and must have a protected management connection. When verifying specs, confirm that the device’s firmware version, available memory, and interface layout support the intended provisioning path. For example, a router intended for Hotspot and PPPoE must have at least one unprotected customer port and a separate management port, as the platform protects internet and management paths from customer-service assignment. Document these requirements early so that the enrollment command generated in CENTRANET can be applied without unexpected dependency pauses.
## 3. Validate Port Assignments and Service Separation
A common source of deployment failures is assuming that all router ports are interchangeable. The CENTRANET workflow distinguishes between protected ports (WAN, management) and customer-service ports used for Hotspot or PPPoE. When verifying gear, explicitly map which physical ports will carry internet uplinks, which will serve as the management channel, and which will be assigned to subscribers. Ambiguous assignments or existing configuration dependencies will pause the automated setup for manual review. Use the platform’s discovery step to read the current device configuration and confirm that clear customer ports are available, or that retained account dependencies are documented before proceeding.
## 4. Test Real Subscriber Journeys After Configuration
A provisioned configuration that passes readback checks does not guarantee that end-user service is functional. After the router configuration is installed, connect through a customer port and authenticate a test Hotspot login or PPPoE account. For paid access, verify that the provider configuration is correct, make an agreed test transaction, check the payment record, and confirm the router’s account-installation acknowledgement. Then test DNS resolution and internet browsing. Separately test expiry, suspension, and reconnection behaviours. This real-subscriber test is the only way to confirm that the gear’s documented capabilities match the actual service delivered.
## 5. Verify Backup and Recovery Readiness
Configuration drift is a risk whenever networking gear is deployed at scale. The CENTRANENT provisioning guide emphasizes that backups should be created before any configuration changes are applied, and that the recovery process is read-only—"Check repaired step and continue" performs a check against the approved setting, not a general retry button. When verifying specs, confirm that the router supports automated backup, that the backup includes the Hotspot files and PPPoE secrets, and that the recovery path preserves management access. If setup pauses, inspect the reported resource and latest device activity before deciding on next steps. A new review may be required if drift is detected.
## 6. Cross-Check Payment and Messaging Integrations
For ISPs that bundle billing with networking gear, it is essential to verify that any integrated payment gateway, SMS provider, or domain provider is actually operational. The CENTRANET workspace records provider readiness, transaction records, and message status—saved settings are not proof of a working external integration. When evaluating gear, cross-check that the router’s interface can communicate with the intended payment or SMS endpoint, and that the CENTRANET dashboard can read back the integration status. Any dependency on an external service should be documented with connection details, credentials (handled securely), and expected behaviour on failure.
## 7. Document Branding and Domain Setup Requirements
CENTRANET allows workspace and portal branding, including custom hostnames through a verified domain setup. When verifying networking gear, also confirm that the router can support the DNS and firewall rules required for a branded Hotspot portal. This includes ensuring that the device can resolve the custom domain, that firewall rules allow traffic on the required ports, and that the router’s system time is synchronized so that certificate validity is not compromised. These details should be recorded as part of the overall gear verification checklist, separate from pure performance specs.
## 8. Maintain a Living Verification Record
Verification is not a one-time checkbox. As router firmware evolves, as new subscriber packages are introduced, or as the ISP expands to new sites, the gear specification checklist should be updated accordingly. Keep a record of which firmware version was verified, which CENTRANET workflow steps were completed, and any observed deviations between documented capabilities and real-world behaviour. This living record becomes the reference point for future deployments and for troubleshooting recurring issues.
## 9. Assess Firmware Lifecycle and Upgrade Paths
Firmware stability directly impacts the reliability of provisioned services. When verifying gear, confirm the router's current RouterOS version, the date of the last security update, and whether the platform supports a in-place upgrade without erasing Hotspot files or PPPoE secrets. Check the vendor's release notes for known issues that affect session stability, NAT performance, or Hotspot authentication. If the device is near end-of-life, document the migration path to a newer model, including any required changes to port assignments or CENTRANET workflow steps. Maintaining an inventory of supported firmware ranges ensures that future deployments are not blocked by unsupported versions.
## 10. Measure Actual Throughput Under Representative Load
Marketing specifications often list maximum aggregate bandwidth, but real-world throughput depends on packet size, concurrent connections, and NAT processing. To validate performance, run throughput tests using a tool that simulates the expected traffic mix—such as a combination of large file transfers, VoIP packets, and small interactive requests. Record the achieved goodput, packet loss, and latency under load. Compare these results against the service level agreements (SLAs) promised to subscribers. If the device cannot sustain the required throughput at the expected connection count, consider a higher-capacity model or adjust the subscriber load limits.
## 11. Validate Power Budget and Environmental Ratings
For ISPs deploying equipment in outdoor or high-density indoor environments, power budget and environmental specifications are as critical as interface counts. Verify the router's PoE output capacity if passive PoE devices are used, and confirm the operating temperature range matches the installation site. Check that the power supply unit (PSU) rating provides sufficient headroom for simultaneous full-port utilization plus ancillary components such as LTE modems or GPS units. Document the power consumption figures and compare them against the available electrical circuit capacity at the deployment location.
## 12. Cross-Reference Interface Counts with Subscriber Scaling Plans
A frequent mismatch occurs when the number of physical ports does not align with the intended subscriber scaling plan. When verifying gear, map each physical port to a specific service role—uplink, management, or customer—and calculate the maximum number of concurrent Hotspot users or PPPoE sessions the platform can support given the interface layout. Remember that some ports may be reserved for protected paths and cannot be assigned to subscribers. Produce a port-utilization table that shows the available customer ports versus the planned subscriber count for each site, and flag any sites where the port count falls short of the target deployment size.
## 13. Record Integration Dependency Details for External Services
If the deployment relies on external payment gateways, SMS providers, or domain name services, record the exact connection parameters, credential storage method, and expected failover behaviour. The CENTRANET workspace logs provider readiness status, but the verification team must confirm that the router's DNS resolution and firewall rules allow outbound traffic to these endpoints. Create a dependency matrix that lists each external service, the router configuration required to reach it, and the steps to take if the service becomes unreachable during operation. This record supports both initial commissioning and ongoing incident response.
## 14. Establish a Rollback and Re-Verification Protocol
Even with thorough pre-deployment checks, a newly provisioned router may exhibit unexpected behaviour once live traffic is introduced. Define a rollback procedure that restores the last known good backup without losing management access. After a rollback, re-run the real-subscriber journey test (as described in the existing article) to confirm that service continuity is achieved. Document the conditions that triggered the rollback and the lessons learned, then update the living verification record. This protocol minimizes service downtime and provides a clear audit trail for future troubleshooting.
## 15. Align Cost and Warranty Terms with Deployment Risk
Finally, compare the unit cost, warranty length, and support terms against the operational risk profile of the deployment site. A lower-cost model may lack features such as redundant power supplies or extended temperature ranges, which could increase failure risk in certain environments. Warranty terms should cover the expected lifespan of the device in the given climate and usage pattern. Record the total cost of ownership, including potential replacement cycles, and ensure that the procurement process captures these factors before the hardware is committed to a site.
## 16. Integrate Verification Results into the CENTRANET Dashboard
Once all technical checks are complete, feed the verification outcomes back into the CENTRANET workspace. Mark each router as "verified," note any deviations observed during real-subscriber testing, and flag any integration dependencies that require monitoring. This structured data allows the operations team to generate reports on deployment health, identify sites that need re-verification after firmware updates, and track the overall maturity of the gear inventory. Linking verification results to the dashboard ensures that future onboarding steps can reference a single source of truth for each device's capabilities and status.
## References
- CENTRANET features: https://centranetispbilling.com/features
- CENTRANET MikroTik provisioning guide: https://centranetispbilling.com/docs/mikrotik-provisioning
## Contact
For questions about verifying networking gear specs or CENTRANET workflows, visit https://centranetispbilling.com/contact
Discuss your next step
Contact CENTRANET to discuss your network requirements before choosing equipment or changing a live service.