Internet sources and multi-site network topology

Prerequisites and authority

Network/RouterOS authority, known topology and a recovery management path are required. Preserve existing router configuration before managed changes.

Select the physical and routed topology

Use neutral internet-source terminology. The source may be fiber, wireless, cellular, satellite or another upstream service. BryanNet's management requirement remains IP reachability to each router.

One site, one source, one router

The source connects to the MikroTik WAN; its customer-facing network serves access points/devices. A local BryanNet host reaches the management address. Keep its address stable and distinguish that path from the hotspot client network.

One source, several routers

Use a designed distribution network, such as routed Ethernet/fiber or a suitable wireless backhaul, to reach the routers. An upstream gateway/switch arrangement must define routes, NAT and management addressing. Do not blindly cascade customer hotspot ports through successive routers.

Each router needs a unique management address and individual BryanNet registration. Sharing an internet source does not combine them into one router record or multiply a subscriber's allowed concurrency.

Physically separated source and router

Provide a real link between them. A point-to-point backhaul or routed carrier connection can carry the required network path. If the remote router instead has its own internet source, manage it remotely through a VPN. A VPN for management alone does not distribute the original source's internet to it.

Multiple sites and sources

For two sites with three routers each, use distinct management subnets and one routed VPN gateway per site where that design suits the network. The central server routes through each gateway to its downstream routers. Individual-router tunnels are an alternative when site routing cannot be provided.

flowchart TD
  B["Central BryanNet"] --> G1["Site A VPN gateway"]
  B --> G2["Site B VPN gateway"]
  G1 --> R1["A routers: 10.61.0.0/24"]
  G2 --> R2["B routers: 10.62.0.0/24"]
  S1["Site A internet source"] --> G1
  S2["Site B internet source"] --> G2

The diagram shows the management arrangement and source association, not a requirement to tunnel customer traffic through BryanNet.

Address and validation plan

Example: server VPN 10.200.0.1, gateways 10.200.0.11/.12, router management networks 10.61.0.0/24 and 10.62.0.0/24. Allocate actual addresses to avoid overlap with Docker, VPN and customer networks. Define forward and return routes and restrict allowed sources.

For every model test host/runtime TCP API reachability, authentication, router event return traffic, provisioning, customer internet and outage recovery. A ping is supporting evidence only; ICMP may be blocked while API access works.

Failure	First isolation step
All routers at one site fail	Site gateway/source/VPN
One downstream router fails	Its address, route, firewall and API
VPN handshakes but API times out	Inner routing/return path and input/forward policy
API accepts TCP but rejects login	Account credentials/rights
Management healthy, customers offline	Customer distribution/upstream/hotspot

Test the selected design before finalizing site hardware or enabling customer sales.