FAQs

Got Questions? Check out our most popular queries below. If you can’t find what you’re looking for, drop us a line.

Turnium SD-WAN features a capability called Private WAN (PWAN). This capability enables you to create a private virtual MPLS-like network connecting all sites securely. In addition, data can be encrypted using AES128/256 to ensure privacy. As another layer of security, our packet-based link load balancing distributes network traffic from sites over multiple circuits from multiple carriers (if deployed) connecting the site to the core. This means that the data stream is split up and man-in-the-middle intercepts are much less likely to succeed.

When you deploy Turnium SD-WAN, these IPsec tunnels and the professional services or support time needed for maintenance and changes is a thing of the past.

All configurations are created using the Management Server and are automatically pushed to the CPE at each site as well as to the Core Node Aggregation Servers. Adding a new multi-site network is simple. Create a “Space” for a network with Private WAN routing to keep customer traffic segregated and secure in three clicks and type in the Name and a Key. Then add site profiles to the space. Building a site profile takes about four minutes and consists of four mouse clicks and the typing a site name into a field with a final click to save. Then add the circuit details that will be used at each site and you are done.

Adding a new site to an existing network is also easy. Access the space for the network and simply build a new site profile. Generate a new node key and the CPE is ready to deploy at the site.

Turnium’s SD-WAN software automatically builds all the routing groups and tunnel configurations for you. Because this process is automated, there are no mistakes and there is no troubleshooting. No need to touch every piece of hardware or configuration to update routes or troubleshoot for possible errors, everything just works.

Using Turnium SD-WAN, you do NOT create VPNs for voice or other high priority traffic and there is no need to create a VPN for voice. Our Quality of Service (QoS) profile allows you to define and manage high priority data and place it in a priority queue or ‘Class of Service” that ensures that it gets prioritized by the network.

This depends on whether you are provisioning a single site or a multiple sites. Firewalls can be localized at each site between the LAN and the SD-WAN CPE or virtualized onto the CPE.

If you have a multiple site Private Wide Area Networks deployed for multiple customers, you can put the firewall in your data center and secure traffic at the WAN edge even before traffic enters the WAN.

Turnium Channel Partners that are hosting and managing Turnium’s Wholesale, White label SD-WAN software platform have the choice as to how to deploy Security and UTM services for your customers and whether to standardize on a single vendor or support multiple Security solutions. Turnium gives you the flexibility to build your service stack, your way, and even to build multiple solutions to address the needs of different customer segments.

Yes, Turnium’s Wholesale, White label SD-WAN platform can be branded with your brand. This enables you to differentiate your offers uniquely in the market and build your own unique value proposition.
A key part of Turnium SD-WAN is a centralized configuration server or Management Server. You manage your customers and their network connectivity using the Management Server, which also provides the ability to monitor and report on each Core Node, CPE, and customer network. The Management Server has a full REST API for integration to your existing network management, orchestration, or security environments.

You will need hardware or a virtual environment for a Management Server plus at hardware for at least two Aggregation Servers (the SD-WAN core nodes) and IP Addresses.

Aggregation Servers: A minimum of two is needed to provide High Availability (HA) in each Data Center. You’ll also need to provision sufficient Bandwidth in each DC so the Aggregators can support traffic from your customer base.

Management Server: The Management Server controls the configurations of the core node Aggregation Servers and the Edge CPE/Bonders at each site. The Management Server is not in the data path. It is recommended to locate the Management Server in a separate DC or Cloud environment from your Aggregation Servers.

IP Addresses: You’ll also need a /30 IP address for each customer. Note that a customer can have 1 or 5000 sites and it will still be sufficient to provision a single public /30 IP address per customer.

You’ll use the web interface/GUI of the Management Server to set up and configure the new customer plus their sites, service options, Internet connection info, and bonded IP address. The Management Server assigns an API key to each CPE. After you boot a CPE on the provisioning network and provide the API key when requested, that site’s configuration is automatically downloaded to the CPE. The whole process takes less than 20 minutes, most of which is the CPE configuring its operating system automatically. Some of our partners use the API to automate this process.
No, not if you resell DSL lines from a provider that forwards PPP authentication requests to your own Radius server. Our application integrates with the open-source FreeRadius server to completely manage PPP credentials for you. We will build API based integrations to other ISP operations systems as required.
Build the profile, image with the ISO or install on a supported Debian OS install. This can take as little as 10 minutes, excluding operating system install time.
Yes. Aggregation Servers can be configured to automatically build a Managed Mesh between each other. Bonds are assigned a primary and secondary Agg and failover is then inherently set up. We recommend a minimum of Two Aggregators to start and add additional Aggregators as demand or geographic coverage increases to build the infrastructure for support of your customer base. Multiple core Aggregators can be easily deployed in multiple data centers to locate them close to your customer concentrations, increasing performance. By the way – remember that you can deploy unlimited core nodes and our licensing model makes that easy and cost-effective (they’re free).
Best practice here for HA Management Server is to spin up the Mgt Server in a virtualized cloud environment. In this manner, if the Management Server fails it simply reboots in a new instance and all is good. Customer CPE devices and Aggregation Servers can live without a Management Server as long as they do not need to switch from a primary Aggregator or CPE to a secondary.
Yes, High Availability (HA) CPE are a standard configuration for many customer deployments and this is fully documented inn the Management Server under the Documentation Section.
As long as you have two or more circuits connected and configured at the site and at least one of these circuits remains active, no, your customer will not even know a circuit failed. The only indication is a reduction in overall bandwidth the customer has available. Even when using a circuit in failover mode, the customer will not experience anything as a circuit is removed from the SD-WAN tunnel more than a lost syllable or small audio anomaly in voice. Data transactions will not be affected at all in this instance.
One of the strengths of Turnium SD-WAN is that you can use multiple circuits from multiple carriers, including both wired and wireless circuits, at each site. You can provide the circuits or your customers can source their own. We haven’t found a limit to the number of circuits that can be used – the only limit is that imposed by the CPE that you deploy as it obviously must have a sufficient number of ports.

No, you do not need to use circuits from a single provider. In fact, we recommend diverse carrier circuits be used to provide better uptime for your customer.

The circuits do not have to be the same speed but there are reasonable limits. For instance, using a 100Mb and 10Mb circuit on the same CPE at the same time is not a good idea. Using the 100Mb as a primary and the 10Mb as a failover however is perfectly acceptable.

No. Turnium SD-WAN is longer supported on Red Hat OpenShift container deployments. Although this configuration was supported in the past, the version of Turnium software that was supported is now outdated and no longer supported. We have not certified any subsequent versions with Red Hat. Instead, we have chosen to focus our resources on rewriting Turnium software to support Multi-Gigabit speeds, infrastructure scalability, and CPE/Server performance as this functionality has been most requested by our channel partners to support end-customer use-cases. Should demand for RedHat OpenShift warrant, Turnium may consider recertification in the future.