SD WAN

SD WAN

Ransnet Cloud Managed SD-WAN Solution Design


Download SD-WAN presentation

SD-WAN combines a full suit of advanced cloud networking, security and WAN connectivity features to form an end-to-end WAN solution for large enterprises to connect remote branches/outlets securely and resiliently, particularly as a more cost-effective alternative to traditional MPLS or VSAT solutions.

The key features of RansNet SD-WAN solution include below:

  1. Flexible connectivity options to any WAN technologies, eg. fiber Internet, PPPoE, Single/Dual LTE, MPLS, Metro-Ethernet
  2. Multi-WAN load balancing for high resiliency
  3. Multi-VPN protocol with dual/multiple VPN bonding for better security and higher WAN capacity
  4. Multi-VLAN for traffic separation for local devices sharing the same connectivity with different security policies
  5. Dynamic routing (OSPF & BGP) for auto fail-over and intelligent path selection
  6. QoS for traffic prioritization
  7. Policy-based routing for more granular traffic control
  8. Advanced "Ethernet over SSLVPN" for seamless network expansion
  9. Built-in dual-band AC Wi-Fi to offer guest hotspot access with monetization opportunity for retail outlets
  10. mfusion cloud platform for central network visibility and control

With all above features packed into a powerful platform, customers or service providers enjoy the benefits of

  1. easy to deploy, easy to configure, easy to operate
  2. cost effective
  3. higher resiliency
  4. better security

This section covers a typical SD-WAN scenario. We use a 3-layer design approach. 


Access layer (HSA)

The Access layer is powered by our HSA appliance (HotSpot Access). It sits at each remote network as a CPE device to connect to different WAN technologies, eg. Fiber, MPLS, VSAT, PPPoE, or LTE. It's capable of connecting to multiple WAN options, at the same time with load balancing and auto fail-over. It has 4 x GE LAN ports to connect local devices and if there are more devices, we can simply extend with a typical LAN switch.


Through resilient WAN connectivity, the HSA will build dual SSLVPN tunnel to the CMG gateways sitting at WAN distribution layer, for highest resiliency. The HSA advertises it's local LAN network to CMG via OSPF across the VPN tunnels. It's possible to run active-active VPN tunnels, or active-standby tunnel, simply by tweaking OSPF costs, eg. by default if the tunnel cost is the same, OSPF will load balance traffic across both tunnels; else we can increase the OSPF costs over the less preferred (backup) tunnel. Typically if the backup link is less reliable we'd recommend to configure active-standby mode.

The secure SSLVPN tunnels can run across any IP networks, through dynamic or static WAN links or even from behind other routers/firewall, as long as HSA is able to reach to CMG across provider networks.

WAN Distribution layer (CMG)

The WAN distribution layer is powered by Cloud Managed Gateway (CMG). The CMG acts as VPN concentrator to terminate SSLVPN tunnels with remote HSA. The CMG runs OSPF inside the SSLVPN tunnel to learn remote routes; it runs BGP with core routers to learn upstream (core) routes. It then redistributes BGP into OSPF for the remote HSA to learn routes for core networks; and redistributes OSPF into BGP for core network to learn remote networks. So the CMG forms a very important aggregation layer between the core and remote networks.

If we need to support large amount of remote sites, it's recommended to use multiple virtual CMG hosted on typical hypervisor (VM-Host), eg. VMWare, KVM, etc. Then split remote HSA into multiple groups to tunnel with different virtual CMG. 

Typical design guide:

  • Min resource per virtual CMG: 4GB RAM, 8 core CPU, 40GB HDD
  • Up to 300 SSLVPN tunnels (remote HSA) per virtual CMG. This is to ensure tunnel stability and speed up OSPF routing convergence. It also simplifies operations.
  • Up to 100 virtual CMG per VM-Host, with specs of 512GB of RAM, 2/4 CPU, 5TB usable HDD (RAID-10), 2 x 10G interfaces.

With above design, a hypervisor (VM-Host) can support up to 30,000 remote HSA. For redundancy, we will need two VM-host, to form dual tunnels with the same HSA. It is highly recommended to locate each VM-Host at two different physical locations.

Core Layer

The core layer consist of customer or provider core switches or core routers. The core routers form BGP with CMG to learn remote routes and advertises server routes/networks to CMG (redistributed to HSA). It's possible to use any other 3rd-party high performance routers or customer preferred selection of routers, as long as they support standard BGP protocols. But a physical CMG-5000 with 10G interfaces would be a good choice too.

mfusion cloud

The mfusion platform can be a VM or physical server sitting in the cloud, or any location/networks that are reachable by both CMG and HSA.

The mfusion provides below key functions

  1. remote configuration provisioning for both HSA and CMG. This empowers zero-touch configuration for HSA. Once the device is on-line, it auto "call-home" back to mfusion to push its configuration provisioned by NOC engineers remotely, without the need for any certified engineers onsite.
  2. firmware and patch management. If needed, firmware or software patches can be remotely pushed by mfusion to target HSA.
  3. real-time monitoring, alerting and scheduled historical reporting. 

Cloud Managed Public hotspot over SD-WAN

All-in-one Chain Stores Solution (Hotspot + SD-WAN)

CMG VPN- Gateway
HSG- Hotspot Analytics, Captive portal, AAA WIFI AD pushing Monetisation Gateway

HSA - VPN /MultiWAN/ SD-WAN Bonding 11ac WIFI router with Hotspot Captive portal  ready

 

Key Components (@HQ)

  • Static Internet line(s)
  • CMG-3000 SD-WAN VPN gateways
  • HSG Captive Portal gateways (optional, for Captive portal/social wifi Login/guest WiFi/Wifi AD pushing/email harvesting)

Key Components (@store)

  • HSA-500, SD-WAN Router, Multi WAN Bonding/Failover/Hotspot ready Router 1 x WAN (primary), 2 x LTE (optional, for backup)

Solution Features:

  • Redundant WAN with bonding (active/active, or active/standby)
  • Multiple LAN ports for local terminals (eg. POS, IPT, PC, etc).
  • Secure VPN tunnel as alternative to traditional MPLS
  • Integrated Wireless 802.11b/g/n/ac for guest WiFi and monetization
  • Social media integration to capture guest profiles
  • CRM/POS integration for premium Wi-Fi
  • WiFi user data analytics and database collection
  • Landing page and in-session ads streaming
  • POS/Business traffic will route through VPN tunnel
  • Guest Wi-Fi traffic will locally breakout
  • Stateful firewall inspection for perimeter security protection
  • Integration with mfusion for large SD-WAN deployments

Solution Benefits:

  • Resilient, secure and cost-effective all-in-one SD-WAN solution
  • Integrated wireless for Wi-Fi monetization
  • Service visibility and easy operational control

HSA-500 Mobile SD-WAN MultiWAN bonding/Failover Router with 11AC WiFi Hotspot Captive Portal (Optional LTE 4G backup) 


This design leverages on our SD-WAN device (HSA-500) to extend its Wi-Fi capability to offer staff or guest WiFi.
The HSA-500 comes with full suit of SD-WAN features, including Multi-WAN connectivity support, load balancing, VPN bonding, optional Dual LTE SIM, dynamic routing etc, at the same time it comes with 802.11ac wave 2 Wi-Fi capability with built-in hotspot access controller, capable of redirecting guest Wi-Fi users to external captive portal for authentication.


HSA-500 is an ideal all-in-one device for multi-purposes for a retail outlets.


Target environments:

  • Retail outlets
  • F&B chains
Features:
  • Redundant WAN with bonding (active/active, or active/standby)
  • Multiple LAN ports for local terminals (eg. POS, IPT, PC, etc).
  • Secure VPN tunnel as alternative to traditional MPLS
  • Integrated Wireless 802.11b/g/n/ac for guest WiFi and monetization

    • Social media integration to capture guest profiles
    • CRM/POS integration for premium Wi-Fi
    • WiFi user data analytics and database collection
    • Landing page and in-session ads streaming
  • POS traffic will route through VPN tunnel
  • Guest Wi-Fi traffic will local breakout
  • Stateful firewall inspection for perimeter security protection
  • Integration with mfusion for central management and monitoring

Ransnet SD-WAN with OSPF VPN bonding


VPN "bonding" is part of our SD-WAN deployment technique for connecting multiple remote sites to HQ/DC securely, over redundant WAN connections  at remote sites. It uses our CMG at hub end as VPN concentrator, and HSA at each remote end.

There're three main options for achieving VPN "bonding", depending on the exact requirements.

  1. Use Multi-WAN (MWAN) to achieve WAN link redudancy, then build VPN tunnel across MWAN, with link redundancy. (see more details on MWAN, and SSLVPN). 
    • This approach achieves link redundancy, but because it still builds a single VPN tunnel only, so the failover can be quite long, since VPN tunnel is persistent and can't be "balanced" across multiple links at the same time. 
    • So at any point of time, the VPN tunnel can only use one of the active link, and after MWAN detects link failover, VPN tunnel needs to re-establish VPN tunnel across the failover/new link. The total failover delay = MWAN link detection delay + VPN re-establishment delay. 
    • This option is more suitable for deployments with small amount of remote sites, where each site network routes can be learnt from SSLVPN configuration (eg. from client net command). 
    • NOTE: MWAN doesn't work well with dynamic routing, because each time when routes are learnt dynamically (via OSPF or BGP), MWAN is unaware of the newly learnt routes and will not deny traffic passing to new routes. For large deployments, we recommend to use option #2 below.
  2. Use OSPF load balancing/failover across dual/multiple VPN tunnels. This feature combines our Multi-VPN tunneling and dynamic routing capabilities. 
    • We build dual/multiple tunnels, one VPN tunnel per WAN link, then run OSPF dynamic routing protocols across the tunnels. 
    • use OSPF to dynamically learn routes for each remote sites, load balance traffic across multiple paths (VPN tunnels), and auto failover between paths/tunnels. 
    • To switch between active/active or active/standby mode, we simply tweak OSPF link costs (eg. set "tap ospf cost xx" higher for backup tap).
    • This design is the most scalable and recommended for large deployment.
    • Another advantage of this approach is that the VPN gateways can be separated on two physical CMG, for gateway redundancy
    • We use PBR to map each tunnel/tap traffic to the respective physical/LTE interfaces
  3. Use layer-2 LACP protocol to "bond" multiple VPN tunnels. This features utilizes our Multi-VPN tunneling and Layer-2 bonding capabilities. 
    • The HSA builds dual/multiple tunnels to CMG, one VPN tunnel per WAN link, then use LACP to "bond" these tunnels as one logical link.
    • Traffic will be load balanced across the tunnels as if we have a logical link with aggregated bandwidth.
    • But do note that if any of the link/tunnel has lower speed (or inconsistent performance), it will impact overall bonding link performance. 
    • And unlike #2 approach, where the hub end SSLVPN server can have one VPN instance to terminate many remote tunnels, this approach requires dedicated VPN instance per remote end, because LACP bonding is "point-to-point". So if you have many remote sites/tunnels, you need to run many VPN instances on the server.
    • NOTE: unlike #2 approach, LACP bonding requires both VPN tunnels to terminate on the same VPN gateway (CMG).
    • This approach is good for smaller deployments, requiring large throughput (aggregated bandwidth) between sites, and the WAN link performance are consistent and identical.

In this section, we focus on VPN bonding using OSPF, for large deployment scenario. We will have a separate topic on VPN bonding with LACP.

In this design, we're using HSA with dual LTE/SIM to provide multiple WAN connections to tunnel to the hub CMG. Then build VPN tunnel across each LTE connection. But in real live deployment, we can also have different WAN connections (eg. MPLS, Fiber, PPPoE) to the HSA WAN port.

A few key points to NOTE:

  1. SSLVPN must run in tap mode (layer 2 tunnel) to support OSPF
  2. On CMG (SSLVPN server)
    • configure two VPN server instances (if both tunnel sharing the same gateway), under "security sslvpn-server x" configure unique port number for each instance, so that remote client (HSA) will import two profiles and built separate tunnels to each instance.
    • when configuring "server address xxx", it's recommended to use DNS name instead of public IP, so that client profile uses DNS name to connect to SSLVPN server. This allows potential change of server public IP without clients re-importing VPN profiles.
    • assign tunnel-pool for the tap interfaces, to advertise OSPF routes
    • Use "tap ospf priority 255" to make sure OSPF must ALWAYS be in DR state, so that it can receive/push routes from/to all remote ends.
    • Use "tap ospf cost xx" to tweak tap cost for each tunnel if you want to run active/standby taps, otherwise both taps will have ospf cost of 10 and load sharing (load balance) traffic across both taps. NOTE: If you are changing "tap ospf cost xx", please do it on both ends, both CMG and HSA, for the same VPN instance, to avoid asymmetric routing problems.
    • configure firewall-input and firewall-access rules to permit VPN tunnel and internal traffic to pass through
  3. On HSA
    • Set OSPF priority to 0 to make sure OSPF must NOT be DR state. 
    • Use GUI (or mfusion) to configure tap interfaces, and put them into the correct "lan" firewall zone

NOTE:

  1. We can use OSPF load balancing features (equal path, equal costs) across dual/multiple tunnels, but if one of the link is slow or has poor performance,it will impact the overall performance. You can use "tap ospf cost" to change the link cost, to switch between active/active or active/standby mode. tap with lower cost will be the active path.
  2. Each CMG VPN instance can support hundreds of remote tunnels (remote OSPF neighbours). But since each tunnel is in layer2 mode, we recommend no more than 200 remote peers per instance, to reduce broadcast domains.
  3. if you have large remote sites, it's recommended to put each tap into different OSPF area ID, to minimize OSPF topology update overheads.
Drop items here to shop
Product has been added to your cart

Oops, no products have been added to this category yet.

Go back to the Home page