Multiple WANs. One resilient transport.
Connect independent internet links, build encrypted paths between gateways, and choose how important traffic uses them. Caged combines WAN load balancing, path policies, and packet-level tunnel modes in one managed branch network.
Caged AI · technical brief · updated October 3, 2026
Choose what the extra links should do.
Load balancing, bonding, and failover solve different problems. Load balancing spreads connections; packet-level bonding carries selected traffic through cooperating endpoints; failover supplies another usable route.
| Approach | How traffic moves | What it is for |
|---|---|---|
| Load balancing | Distributes separate connections across available WANs. A normal connection stays on its selected link. | Share the workload of many users or applications across internet links. |
| Packet-level bonding | Carries a selected flow over multiple paths between cooperating tunnel endpoints. | Use a common transport for capacity or resilience, according to the selected tunnel mode. |
| Failover | Moves eligible traffic to an available path when the preferred path becomes unusable. | Provide an alternative route; session survival depends on addressing and application behavior. |
A single transfer using ordinary session-based load balancing normally uses one WAN. A configured packet-level tunnel can carry a flow across several member paths. Its useful throughput depends on the mode, both endpoints, link conditions, and overhead; adding port speeds is not a throughput measurement.
Background: Mushroom Networks' explanation of bonding and load balancing ↗.
A bonded tunnel needs a receiving gateway.
For the Caged tunnel modes described here, provision cooperating Caged gateways at the branch and remote site or hub. Select the WAN interfaces and encrypted member paths in the Portal, then choose the traffic that will use them. The receiving gateway reconstructs or deduplicates traffic for the selected mode.
WAN B ⇄ remote gateway
Local internet load balancing can use the branch's own ISP connections without a remote Caged gateway. Internet traffic carried through an overlay needs an egress arrangement at the remote hub. Caged's configured hub internet egress handles selected public IPv4 traffic through a chosen hub WAN, with an optional backup hub WAN.
Plan the remote gateway's capacity, return routing, firewall/NAT rules, and public IP requirements alongside the branch links. Branch WAN redundancy alone does not remove a shared hub, power, or upstream dependency.
Balance capacity, redundancy, and recovery.
Caged's ordinary overlay path policies and its packet-level replication and reliability modes offer different tradeoffs. Select the policy for the application and confirm that both devices support the required mode, software, and license features.
- Path selection
- Use configured weights and health information to select usable overlay paths. A failover policy favors an available preferred path.
- Replication
- Send copies of selected packets across member paths. The receiving gateway removes duplicates and handles ordering within its configured window. Extra copies consume extra bandwidth.
- Reliability / FEC
- Distribute encoded traffic and repair data across member paths. Forward error correction helps the receiver recover missing data when enough encoded data arrives within the recovery window.
Replication prioritizes redundant delivery; it does not turn duplicated packets into extra useful capacity. FEC adds repair traffic and buffering to help tolerate loss. Set recovery and ordering windows with the application's latency needs in mind, especially when terrestrial and satellite paths have different delays.
Watch the path, then test the application.
Configure WAN and overlay health checks, failure/recovery thresholds, and path policies. A connected cable or modem does not establish that the upstream service is usable. Check both interface health and the encrypted path to the remote endpoint.
Local ISP failover can change the public source IP, so an existing internet session may need to reconnect. A tunnel retains a common inner network path while its WAN members change, but continuity still depends on usable member paths, endpoint state, routing, and the application. A hub-WAN change can also affect public internet sessions.
Replication and FEC can help traffic tolerate path loss within their configured recovery behavior. Detection thresholds, remaining capacity, and buffering affect the interruption seen by users. Measure an ongoing call, video stream, or transfer in your actual topology.
Combine wired, cellular, and satellite access.
Use compatible fiber, cable, DSL, satellite, 4G, or 5G services presented through supported WAN interfaces and modems. The appliance manages the resulting network links; the access service, modem, and carrier determine their available speed and coverage.
The Small / Portable office model has four 2.5GbE WAN ports and two 2.5GbE LAN ports, with optional up to two built-in 5G modems. Medium office and Large office configurations provide other interface and power options. Confirm modem/carrier compatibility and the selected hardware configuration when planning the site.
Prefer links with different failure dependencies where practical. Two services can still share an access network, power supply, or carrier outage. Include cellular data allowances and the extra traffic from replication or FEC in the operating plan.
Validate the exact workload and topology.
Start with representative applications and an ordinary-routing baseline. Record both gateway models, software versions, WAN rates and conditions, topology, traffic policies, tunnel mode, and recovery settings. Keep the test workload and observation window consistent.
| Scenario | What to observe |
|---|---|
| All links healthy | Record useful throughput, application latency, jitter, loss, and WAN usage for the chosen traffic and tunnel mode. |
| A WAN fails or degrades | Test both a cable disconnect and an upstream outage while the local link remains up. Observe health detection, path changes, and application interruption. |
| The WAN returns | Check recovery thresholds, path reuse, traffic redistribution, and whether active applications remain stable. |
| The hub or all paths fail | Confirm the configured fallback or fail-closed behavior, public addressing, alerts, and application reconnection. |
Agree on useful throughput, acceptable application interruption, latency, and loss before approving the pilot. Record the workload and link conditions with the results so your team can compare deployments consistently.
Design around the remaining bottlenecks.
Useful capacity is bounded by both gateways, the usable paths, remote egress, application behavior, and encryption/repair overhead. Replication and FEC spend bandwidth to improve delivery; they cannot restore traffic when every usable path or a required endpoint is unavailable.
Path MTU, packet ordering, and large delay differences matter. Traffic must match the intended policy in both directions. Confirm the address family, remote reachability, feature availability, and hub egress configuration needed for the deployment. This brief makes no fixed failover-time, throughput, or uptime guarantee.
The same branch platform also provides AI API governance. WAN transport policy and AI request policy address different parts of the deployment.
Plan your resilient WAN path.
Bring the site locations, WAN services, remote endpoint, important applications, and continuity requirements. Compare the appliances and discuss a pilot with our team.