Topologies, Ports & Field Playbooks

Part Nineteen: SpeedFusion Topologies

The topic

How the SpeedFusion endpoints connect to each other, the topology, shapes the whole deployment. There are three standard patterns, and most real networks are a deliberate mix.

Star (hub-and-spoke) routes all sites through a central hub (an HQ router or, increasingly, a FusionHub in the cloud). It is the most common pattern for a headquarters with branches: simple to manage, centralized for egress and security, at the cost of all traffic passing through the hub.

Mesh connects every site directly to every other site. It is resilient and gives the most direct path between any two sites, at the cost of many more tunnels to configure and manage.

Point-to-point is two endpoints joined by one bonded path, for maximum throughput between exactly two locations, a studio to a data center, a vessel to shore.

 The three SpeedFusion topologies, point-to-point, star (hub-and-spoke), and full mesh.

How it works on Peplink

You choose the topology when you design the SpeedFusion profiles, and InControl can orchestrate organization-wide tunnels that implement it. Star is the default mental model and the right starting point for most customers, because it centralizes management and security and pairs naturally with a FusionHub hub. You add direct mesh links only where two specific sites exchange enough traffic to justify bypassing the hub, and you use point-to-point where the entire job is one fat reliable pipe between two places.

Why it matters

Topology is a management-versus-directness tradeoff, and naming it explicitly prevents the two common failures: a star that funnels heavy site-to-site traffic through a distant hub and adds needless latency, or a full mesh that nobody can keep configured correctly as it grows. Start star, add mesh links surgically, reserve point-to-point for the dedicated-pipe case.

Field note

For a mobile fleet, the right answer is almost always star with a cloud hub: each unit tunnels independently back to a hosted endpoint, which is what lets a fleet of moving things present a stable, consistent identity regardless of where any individual unit is or which towers it is using. Units do not mesh to each other at Layer 2, which keeps stretched-L2 loop risk out of the fleet entirely.

Part Twenty: Ports and Firewall Requirements

The topic

When a SpeedFusion tunnel will not form, or a second sub-tunnel flaps while the base tunnel is fine, the cause is very often a firewall that is not passing the right ports. Knowing exactly which ports SpeedFusion needs, and that each sub-tunnel needs its own pair, resolves a large share of “the tunnel won’t come up” tickets.

SpeedFusion ports

The SpeedFusion tunnel uses two port families, 4500 and 32015, and the safe practice is to open both TCP and UDP across the ranges, because the data port is selectable per sub-tunnel and the device will negotiate what works through the firewall and NAT in front of it. The ranges extend as you add sub-tunnels (base 4500/32015, then 4501/32016, 4502/32017, and so on), so opening the full range up front saves you from chasing a flapping sub-tunnel later.

The rules must be bidirectional between hub and endpoints. When SpeedFusion sits behind another firewall (a Palo Alto, for instance), forward these ports to the Peplink WAN interface. For the routing protocols from Parts Thirteen and Fourteen, also allow OSPF (IP protocol 89) and BGP (TCP 179) through any firewall in the path. (West Networks Visio deployment diagrams annotate these as “SpeedFusion VPN Ports U/T 4500–4504, U/T 32015–32019” on the WAN interface, exactly the “full” row above.)

WAN Analysis is the built-in link-quality measurement between two Peplink endpoints (throughput, latency, loss, jitter), the tool you use to characterize a circuit before and after tuning. It needs TCP and UDP 6000–6008 open between the endpoints; if WAN Analysis reports nothing or stalls, those ports are the first thing to check.

InControl 2 ports

For a device to reach the InControl 2 cloud for Zero Touch, management, and monitoring, its outbound firewall must permit traffic to the InControl hosts ac1.peplink.com and ac2.peplink.com on the following:

These are outbound from the device, so most networks already permit them, but a locked-down or default-deny edge will block InControl silently: the device works locally but never appears in InControl, and Zero Touch never completes. When a new device will not check in, confirm these four are allowed outbound to ac1/ac2.peplink.com before suspecting anything else.

 A real West Networks design showing both port sets at once: the SpeedFusion ranges to the FusionHub, and the InControl outbound ports through the customer firewall (West Networks Visio library, 2023).

Why it matters

This is the single most mechanical, most checkable cause of SpeedFusion problems, and the one most often overlooked precisely because the base tunnel comes up fine and masks it. An engineer adds a third sub-tunnel for a new real-time lane, it flaps, and the network looks broken, when in fact UDP 32017 / 4502 was simply never opened. A two-minute port check saves an hour of theorizing.

Field note

The verification signal is clean: a healthy sub-tunnel shows reachable and stable; a port problem shows the classic “established / disconnected” cycling. When you add sub-tunnels, extend the firewall rules in the same change, it is the most common thing forgotten. And when MTU is the suspect instead of ports (the tunnel is up but specific apps fail), that is the MSS/MTU issue from the fundamentals paper: toggle the packet DF flag, test with a lower MSS clamp (drop it ~40 bytes and retest), and confirm fragmentation is being handled rather than blackholed.

Part Twenty-One: Common Mistakes and Field Playbooks

The topic

The mistakes new SpeedFusion deployers make are consistent and avoidable. Collecting them in one place, alongside the fast diagnostic workflows that catch them, turns hard-won field experience into something a newer engineer can use on day one.

The recurring mistakes

The ones that come up again and again: overlapping subnets between sites (two sites both on 192.168.1.0/24 cannot route to each other through the tunnel, decide a coherent, non-overlapping addressing plan up front); MTU/MSS not accounted for (the tunnel adds overhead, so traffic that assumes a full 1500-byte MTU stalls, the classic “ping works, real traffic hangs”); expecting bonding with only one endpoint (no tunnel partner means failover and load-balancing only, never true bonding); bonding links that fail together (two circuits from the same provider or sharing one physical path are not real diversity); putting everything on the tunnel, or nothing (bond the sessions that must not drop, let ordinary browsing use plain load-balanced links); forgetting outbound persistence (apps that break when their public IP changes need a persistence or enforced rule); forgetting per-sub-tunnel firewall ports; enabling global Layer 2 and per-VLAN Layer 2 at the same time; leaving OSPF enabled on an L2 segment; and adding a WAN to the router but never adding it to the SpeedFusion tunnel (a newly added WAN defaults to a disabled priority inside the SpeedFusion profile, so it carries no tunnel traffic and provides no failover until you explicitly add and prioritize it — the classic Synergy-mode surprise, detailed below).

The playbooks

A handful of fast, field-proven workflows cover most SpeedFusion trouble:

1. DWB behaving oddly (uneven throughput, oscillation): inspect RTT threshold, congestion criteria, bufferbloat mitigation, and cut-off latency; compare per-WAN RTT and loss graphs; adjust thresholds.
2. Smoothing vs. latency budget (reliable but too slow): step smoothing down (High → Medium → Normal), trim the jitter buffer, consider FEC instead for micro-loss.
3. Fragmentation / MTU / DF (VPN up but specific apps fail): toggle the packet DF flag, test varying MTU/MSS clamp, capture on the data port to confirm ICMP “fragmentation needed” is not being suppressed.
4. OSPF over SpeedFusion (routes missing, adjacency flaps): confirm OSPF only on untagged and user VLANs over the L3 sub-tunnel, verify multicast over the SF policy, check that link-failure-detection sensitivity is not fighting the OSPF adjacency timers.
5. Port / firewall mismatch (base tunnel forms, additional sub-tunnels flap): open the per-sub-tunnel UDP pairs (32016/4501, 32017/4502, …), validate bidirectional rules, confirm the data-port choice.
6. STP and L2 loops (broadcast storms, intermittent reachability): ensure STP is enabled on the L2 sub-tunnel, set path cost and root bridge correctly.
7. Added a WAN but no failover / no extra throughput (new link is “up” on the dashboard but the tunnel ignores it): open each SpeedFusion profile’s WAN list and confirm the new interface is added and its priority is enabled (it defaults to disabled). Common right after Synergy, a new modem, or a second ISP.

Why it matters

Every item here is something a customer will eventually hit, and every one has a known fix. An engineer who has internalized this list diagnoses in minutes what would otherwise be an afternoon of guessing, and, more importantly, avoids most of these by designing them out from the start.

Field note

Notice how many of these trace straight back to the fundamentals paper: addressing plans, MTU/MSS, spanning tree, multicast, persistence. SpeedFusion does not replace the fundamentals; it sits on top of them, and the fastest SpeedFusion troubleshooters are the ones who know the fundamentals cold and recognize them wearing Peplink clothing.

The remaining parts are the complete-edition additions — first the access layer the links actually ride on, then the operational and platform topics. They are numbered after the core parts above; the course map near the front shows the recommended teaching order (the access layer is best taught first).