Review a Router Snapshot

Use the snapshot review page to inspect what ISP-OS found on a connected router before you import brownfield data. The canonical review URL is /routers/{router}/snapshots/{snapshot}.

You usually land here automatically after a router connects for the first time. You can also return later from the Routers list whenever a router has an unreviewed snapshot.

1. Open the snapshot review page

Open the page from either of these entry points:

• the automatic redirect after router onboarding finishes
• Routers -> Review snapshot on a router that already has a captured snapshot

The summary card at the top shows:

• router model and RouterOS version
• whether the snapshot completed cleanly
• how many plans and subscriber candidates were detected
• whether anything still needs operator review

2. Check for blockers before importing

Before you rename plans or import subscribers, scan the warning surfaces near the top of the page:

• partial scan warnings: some RouterOS endpoints could not be read
• manual mapping items: ISP-OS found subscriber-like data that still needs human judgement
• blocking WireGuard conflicts: the current tunnel subnet overlaps with real router state
• already imported rows: candidates were already brought into ISP-OS earlier

If the page shows a blocking subnet conflict, choose one of the suggested replacement /29 ranges and follow the re-provision flow the page gives you. Do not confirm import until that conflict is resolved.

3. Review the plans ISP-OS wants to create

The Plans to import section is where you decide which PPPoE profiles become ISP-OS plans:

1. Keep or clear the Include toggle for each detected profile.
2. Rename the plan if the raw RouterOS profile name is too cryptic.
3. Set the plan price.
4. Choose the billing type for the import run.

If a detected profile is only an unpaid or suspension mechanism and not a customer-facing product, leave it out of the import set.

4. Review IPoE subscribers

The IPoE subscribers section is for customers who appear through DHCP leases, hotspot IP bindings, or simple queues instead of PPPoE secrets.

ISP-OS groups IPoE candidates by detected queue rate so common plan assignments can be handled together. Before assigning a group, use the visible evidence to confirm that the DHCP lease, hotspot binding, queue, and comments describe real subscribers rather than stale devices or infrastructure.

The evidence line under each speed group summarizes what ISP-OS found:

• DHCP shows static lease evidence and the server name, such as dhcp-vlan205.
• Queue shows whether the candidates matched simple queues. Queue speeds are useful plan evidence, but they are still router evidence, not a guarantee that traffic is currently being shaped.
• Hotspot shows IP binding evidence. bypass means the binding allows the device through, regular means the device still goes through hotspot auth, and blocked means the binding denies access.
• Already imported means a candidate's MAC address matches an existing ISP-OS service. The row stays visible for context, but importing the snapshot will not create a duplicate.

Candidate rows show the same evidence in order. DHCP-sourced rows lead with the DHCP lease, and hotspot-only rows lead with hotspot binding evidence. This source priority keeps the durable identity first while still preserving the queue and hotspot details that explain speed and access behavior.

If the card warns you to Verify these speeds on the router, ISP-OS found an enabled FastTrack firewall rule. FastTrack can skip the speed limits set in Queues, so the detected queue speeds may be different from actual customer speeds. Open Queues on the MikroTik and check whether traffic counters are moving for the customer queue entries before relying on those speeds.

For each group, either:

• choose an existing active plan
• create a new plan from the detected speed and a price you enter
• leave the group unassigned

Unassigned IPoE candidates are not imported. This is intentional. A brownfield router can contain stale leases, test devices, unmanaged hosts, or infrastructure devices that should not become subscribers.

When an IPoE candidate is imported, ISP-OS keeps the durable service identity in the service record and keeps router-specific details as evidence. A DHCP lease, hotspot binding, and simple queue can all describe the same real subscriber; they should not become three separate services.

When these router artifacts overlap, ISP-OS treats the DHCP static lease as the strongest identity evidence. Hotspot bindings explain access behavior, and queues explain speed or plan evidence.

After import, IPoE services follow the same service lifecycle as PPPoE services. Billing and operator actions decide whether the service should be active or suspended; ISP-OS applies that decision through the service's access mode.

For Kiko-style IPoE support to be complete, imported IPoE services must work through the same lifecycle paths as other internet services: billing restore, suspension, temporary reconnect, and operator-driven reactivation.

This IPoE support is intentionally scoped to brownfield MikroTik workflows that use DHCP leases, hotspot bindings, queues, or address lists. It does not imply full BNG, Option 82, VLAN/QinQ, or multi-vendor DHCP RADIUS support yet.

The long-term direction is broader than this import screen: ISP-OS should own billing, subscriber services, AAA, bandwidth policy, router automation, accounting, and reconciliation through one service model. This screen is the brownfield adoption step for that model.

Future IPoE identity strategies, such as DHCP Option 82, circuit IDs, VLANs, or BNG policy, belong in that broader model. They are not required for Kiko-style import unless the router workflow already uses them.

RADIUS-based IPoE is also a separate operational mode. This brownfield import flow can preserve IPoE service identity and enforcement metadata without requiring DHCP/RADIUS authorization to be enabled for IPoE.

IPoE services should only participate in RADIUS when the router is explicitly configured for RADIUS IPoE. Importing IPoE candidates from a snapshot does not enable that mode by itself.

5. Inspect the subscriber candidates

Each plan row includes a subscriber preview. Expand it to verify:

• usernames look real
• comments and names match your expectations
• the grouping by raw RouterOS profile makes sense
• active vs inactive subscribers match what you know about the router

Manual mapping rows are the ones that usually need operator intervention. Common reasons include:

• missing network identity
• unmapped MAC addresses
• masked PPPoE passwords that cannot be imported safely

If a candidate cannot be imported confidently, leave it unresolved and handle it manually later.

6. Configure enforcement hooks

The review page also lets you align brownfield enforcement with ISP-OS:

• unpaid PPPoE profile
• suspension address list
• hotspot interface

Use these fields when ISP-OS detected existing enforcement conventions on the router and you want the platform to continue using them. If you are onboarding a clean router, it is normal for these to be empty.

For IPoE services, enforcement depends on the router setup. ISP-OS treats the service status as the source of truth, then applies it through the relevant router mechanisms such as queues, address lists, or hotspot bindings.

7. Re-snapshot if the data looks stale or incomplete

Use Re-snapshot router when:

• the first scan was partial
• you changed router state outside ISP-OS and want a fresh read
• you resolved access issues and want a cleaner import candidate set

Re-snapshotting keeps the router connected but asks ISP-OS to capture a new router snapshot for review.

8. Confirm the import or defer it

When the page looks correct, click Import into ISP-OS. ISP-OS will:

• create the selected plans
• create subscribers and services from importable candidates
• queue reconciliation for the created services

If the router is connected but you are not ready to import yet, click Skip for now. That keeps the router managed by ISP-OS and lets you return to snapshot review later.

When to skip

Skipping is the right move when:

• this is a brand-new router with no brownfield subscribers to import
• you want to finish router connectivity first and clean up data later
• the snapshot surfaced unresolved items that need field validation

See also

• How to Connect a MikroTik Router via WireGuard
• Router Onboarding Reference

Was this helpful?