Many organisations have moved workloads to the cloud, or are using SaaS applications like Office 365, Google Apps and others. When moving to these applications, the implications of the required bandwidth (and additional latency) are often overlooked, resulting in a poor user experience especially when the internet traffic is first being backhauled to a data centre, then out to the internet.
Disclaimer: I work for Riverbed, all views and expressions on this blog are entirely my own and don’t necessarily reflect the views of my employer. The internet connection in the data centre is never the problem, that’s often a high-speed, low-latency link. However, the bandwidth and latency from a branch site to the data centre is often the limiting factor.
What if that SaaS traffic could be steered directly out to the internet from a branch site, voice traffic over the MPLS and other business traffic over the VPN without relying on complex access control lists to do that? While it does require an internet link in the branch, internet breakout frees up valuable (MPLS) WAN bandwidth for the business-critical applications, and is often still cheaper than upgrading the WAN bandwidth.
Traffic can be steered not only by application (e.g. VoIP, Facebook, WebEx, O365) but also by site, user, host or subnet - again all from a cloud portal without any CLI required. It does also allow you very granular control on how traffic is steered as well as native integration into Zscaler, a cloud access security broker (CASB).
The feature in SteelConnect is called Traffic Rules, and you configure it under Rules -> Traffic Rules -> New Traffic Rule.
In the rule below I’ve specified a few SaaS and web applications, that will always be routed out to the internet directly. If the internet link becomes unavailable, it will get routed out over the MPLS link to still be able to access the internet. The QoS priority can also be modified or set if desired.
The easy thing is that I only have set this rule up once and by default it applies to all sites, although you can specify it per site.
The Users / Source can be many things, for example zones, specific hosts or networks, registered users or devices or guests.
The Applications / Target option can be many things, in the example above I’ve specified some applications that SteelConnect includes by default, you can obviously specify and include your custom apps as well.
The Path Quality profile uses path metrics to determine the health of a link. If path metrics like latency, jitter and packet loss deteriorate then new connections will automatically be setup on the secondary path till the path metrics return to normal. The difference between Interactive and Latency-sensitive is that the latter doesn’t take jitter into account.
Following the same process, I’ll create a few more rules to show the capabilities.
Here’s one if you just want to specify the path for a specific IP or network, in this case for the host with IP 192.168.16.10. This is useful for testing, when the default for the site for example is to use MPLS or RouteVPN, but you want to test internet breakout for a particular device or subnet:
Third example is one that is available in version 2.9 and up, and that’s native integration with Zscaler. You setup the integration once, then SteelConnect will automatically build tunnels to your nearest Zscaler Enforcement Nodes (ZEN) and continue to monitor the latency and health of those tunnels.
The rule below applies to only one site (Branch-Brisbane) and forwards all traffic to the ZEN nodes for inspection by Zscaler. Rule fall through is off, which means that if the connection to Zscaler fails no other uplinks will be tried, even though they might still be available.
Lastly I created a rule for VoIP traffic, to specify the primary path being MPLS and the second path being the RouteVPN, and marking the QoS as urgent (EF46) in this case. I’ve made that the top rule.
Looking at the traffic rules, I now have the following four rules:
Traffic rules are being used from top to bottom, like with ACLs. So if there’s a hit on a rule, the rules below won’t be used anymore.
Where the traffic rules determine the path(s) applications take, **Rules -> Outbound / Internal **is the layer 7 firewall that controls the access between networks, applications and users.
The setup is similar to the Traffic Rules, where you specify users, zones and/or applications that are allowed or denied access.
Here’s a simple example where Bittorrent traffic is blocked, everything else is allowed:
There’s a lot of granularity for both the traffic rules and outbound / internal rules, you can make it as simple or complex as required.
Next blog article in the series will be about SD-LAN and the integration of all this SD-WAN goodness with SteelConnect switches and access points for an end-to-end cloud-managed network.
If you want to test SteelConnect, head here for a free trial.
The complete series:
Part 1: SD-WAN for the masses
Part 2: Getting started with SteelConnect
Part 3: Native Amazon AWS & Microsoft Azure integration
Part 4: Intelligent traffic steering]
Part 5: SD-LAN
Part 6: Application visibility
Part 7: REST API
Part 8: SteelHead integration