RansNet Docs

SD-WAN Topology

RansNet SD-WAN supports comprehensive VPN topologies and network modes to adapt to different customers’ traffic flow requirements. Please review the options below and choose the most suitable topology options for your deployment.

VPN Topology

VPN topology defines how the traffic will flow between locations. There’re mainly 3 types of topology:

Hub-and-Spoke. This is the most typical topology in real live deployments. The traffic only flows between spoke/branch and hub site, where the central applications are hosted. For this topology, only the hub gateway must be statically accessible (direct static IP or NATed static IP); the branch sites can have static or dynamic or private IP (eg. 4G/5G connection), as long as the branch routers can reach to the gateway static IP.
Spoke-to-Spoke. For this topology, the traffic can flow between spoke/branch sites, eg. there’s VoIP application. Note the traffic between spokes/branches still needs to route through the hub site, and this cause extra latency and bandwidth usage at Hub site. However, the IP addressing requirement is the same as hub-and-spoke, eg. only hub site needs static IP.
Full-Mesh. For some rare situations, you need all sites to be able to communicate directly. In this scenario, the hub site must have static IP, and branch sites must be directly accessible between each other (eg. either static IP, or dynamic IP with forward forwarding)

Network Mode

Layer-3 network means each location (hub and/or spoke) have different LAN networks (different network subnets).

Layer-2 network emulates a flat LAN/switched network among all locations (eg. all location networks are in the same subnet), despite the physical underlay WAN connectivity being routed/L3.

Encrytion Protocols

Each topology can use different combinations of encryption protocols:

WireGuard – Recommended if both gateway and branch routers are using RansNet. It’s faster and more tolerant to link latency/instability issues.
IPSec – Recommended if gateway is a 3rd-party product. Some compliance also requires IPSec only.
OpenVPN/SSL – Recommended if both SD-WAN and remote access (client VPN) are required.

Encapsulation Protocols

Depends on the topology used, we usually overlay another encapsulation tunnel on top of the encryption tunnel using below protocols:

GRE – This is typically used to establish layer-3 network topology between locations.
VXLAN – This is used to emulate layer-2 ethernet connections to bridge LAN networks between locations. But it can also be configured with an IP address to run as a layer-3 interface to build Layer-3 topology.

The encapsulation protocols are auto selected based on the selected combination of VPN toplogy and network modes.

SD-WAN Topology

Each topology can combine with different network modes and use different protocols to suit different usage case requirements. Below sections elaborate more details of each topology and the pros and cons of each option.

Hub-and-Spoke (L3)

This is the simplest and most widely used VPN topology for most organizations.

Business applications are hosted centrally at hub/cloud side (HQ or DC) and each branch router just needs to tunnel to the hub gateway to route branch traffic to/from the central applications.

This topology can natively use either of the three VPN protocols (WireGuard, IPSec, SSL).

Hub-and-Spoke (L2)

This topology is for organization that require LAN extentions. It is assumed that business applications are hosted centrally at hub/cloud side (HQ or DC) and each branch router needs to tunnel to the hub gateway to emulate a layer-2 ethernet connectivity between the hub and spoke, then we will bridge the layer-2 tunnel with each local LAN.

This topology requires encapsolution tunnel and can combine with either VPN protocols:

VXLAN over WireGuard
VXLAN over IPSec
SSLVPN in bridge mode (rarely used now)

Spoke-to-Spoke (L3)

This is an extension to the Hub-and-Spoke topology, to allow spoke-to-spoke communication. Each branch only tunnels to the hub gateway, and advertises its local networks via dynamic routing, so that the spokes are aware of other branch networks and able to forward traffic between each other.

Since there’s no direct tunnel between spokes, the traffic between branches will be routed via the hub gateway.

This topology requires encapsolution tunnel and can use either of below VPN technologies:

VXLAN over WireGuard (with BGP)
GRE over IPSec (with BGP)
OpenVPN/SSL (with BGP)

Spoke-to-Spoke (L2)

This is an extension to the Hub-and-Spoke topology, to allow spoke-to-spoke communication, in layer-2 mode. Each branch only tunnels to the hub gateway and emulates a layer2 ethernet connectivity between the hub and spoke, then we will bridge the layer-22 tunnel with each local LAN.

Since there’s no direct tunnel between spokes, the traffic between branches will be forwarded via the hub gateway. Alternatively, if the branch/spoke routers are able to reach to each other directly, it would be simpler to use Full-Mesh (L2) topology.

This topology combines multiple technologies:

VXLAN over GRE over WireGuard (with BGP-EVPN)
VXLAN over GRE over IPSec (with BGP-EVPN)
SSLVPN in bridge mode (allow branch-to-branch)

Full-Mesh (L3)

This topology offers the most flexible access between all sites. All the sites (hub and/or spoke) will establish direct tunnels between each other, and traffic will be passing directly between branch routers without routing through the hub site.

This topology requires that each spoke can reach each other directly (minimally having direct public IP address, static or dynamic).

In this topology, the hub router only acts as a controller to enable branch sites to establish direct tunnels, but there’ll be many VPN tunnels on each router. This can be a scalability problem if there’re many sites within the organization. Only use this topology if it’s absolutely necessary.

If an organization has several sites that need mesh access, and many other sites just need hub-and-spoke only, it’s recommended to use a hybrid topology (partial mesh). For example, create one VPN instance with “Full Mesh” topology for the limited sites that require mesh access, and another VPN instance using “Hub-and-Spoke” topology for the remaining branches.

Only WireGuard is supported for full-mesh topology.

Report abuse