SoftEther Cascade: Link Two Virtual Hubs on Purpose
A cascade joins a local hub to a remote one under a configured identity. It is not an exit node, and it carries whatever else those hubs already bridge.
Two SoftEther hubs joined by a cascade share one broadcast domain, so a loop or a second DHCP server stops being a local mistake and becomes a shared one. That is the whole risk model. The cascade itself is a configured client relationship: the local Virtual Hub connects out to a remote server's hub under an identity that server authorises. It is a building block for a larger virtual network, never an internet exit.
1. Decide what the link must carry
Start from the requirement, not the feature. A cascade moves layer-two frames between hubs, which is what you want when two sites must look like one Ethernet segment. If the need is only routed access to a few subnets, a routed path is simpler and fails in ways that are easier to see. Choosing a cascade commits you to shared broadcast, shared discovery and one loop topology.
Write the requirement in one line before touching a server: which systems must appear to be on the same wire, and which ones only need a route. Anything that answers "a route" belongs outside the cascade. This single sentence prevents most of the designs that end up with duplicate address services.
2. Scope the identity that authorises it
The credentials that administer a server and the identity a cascade uses to connect are different secrets, and mixing them is a common shortcut with a long tail. The remote hub needs a user or policy entry that permits this cascade to connect. That entry is the authorisation; a successful login says nothing about what sits behind the remote hub.
Record which hub initiates, which remote hub it joins and what the remote identity may reach. Compare the two architectures before you commit:
| Requirement | Routed path | Cascaded segment |
|---|---|---|
| Broadcast domain | Separate on each side | Shared across the link |
| Address service | One DHCP server per side | Must not run two on one domain |
| Loop risk | Route loops only | Layer-two loops if segments overlap |
Keep both ends' credentials and recovery instructions current. A password change or policy edit on the remote hub breaks the cascade without touching your local users, and the failure usually appears as a link that is up but empty.
3. Inspect what the hub already carries
A hub is rarely isolated. It may already bridge to a physical adapter, route through a virtual router, or cascade somewhere else, and every one of those attachments is carried into the new relationship. That is why "we only joined two hubs" so often turns into "why are these two sites one segment now?".
Two hubs bridged into the same physical segment and then cascaded to each other form a loop. Add spanning tree or do not build it. The same test applies to a hub that already reaches the target through another cascade: a second link does not add capacity, it adds a path.
Do not add a link because one route is missing; fix the route. Draw the topology on paper first, including every bridge and cascade, because the diagram takes two minutes and catches most loops before they exist.
4. Sort out addressing before joining
Joined segments bring duplicate subnets, and duplicate DHCP servers are the classic symptom: clients take a lease from whichever server answers first, so behaviour looks random and moves between reboots. Decide in advance which side owns address assignment, and give the far segment a range that overlaps nothing local. Disable the other DHCP service before the cascade comes online, not after the first complaint.
DNS is a separate question. A cascade carries frames; it does not configure resolvers, and a name that resolves on the local side may not resolve across the link. Test the lookup separately from the IP path, because a working ping proves only one of the two.
5. Prove it with a real resource
Pick a permitted service on the intended remote segment and confirm the reply comes back through the cascade. Then repeat for name resolution. If the target relies on broadcast discovery, expect different behaviour across a bridged link than on a single wire, and plan for that instead of filing it as a defect.
Finally, write down the topology: which hub cascades where, which identity authorises it, which segments are bridged and who owns address assignment on each. That note is what lets the next person change a policy without taking down a segment they never knew existed.