First of all Happy New Year folks, to a great 2018! I’m starting the year with the last post in this series on SteelConnect, and to start the year on an easy note this is a short one about the SteelHead-SD platform.
The SteelHead-SD combines the best of both worlds: it provides you with all the SD-WAN goodness that SteelConnect has to offer as well as provide the application performance gains that a SteelHead is famous for, all in one converged package.
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 SteelHead-SD is ideal for branch locations with multiple WAN and/or internet links but limited bandwidth that would benefit from WAN optimisation.
It looks exactly the same as the equivalent physical SteelHead model, however under the covers it’s slightly different. In essence the SteelHead-SD is running a hypervisor with virtual services, primarily a SteelConnect virtual gateway and a virtual SteelHead.
Similar to the SteelConnect devices, the SteelHead-SD is built for zero-touch provisioning: plug a cable with internet access into the WAN port, register the serial number in SteelConnect Manager and a few minutes after you boot the device you’ll see it come online.
A typical deployment for a large organisation looks like this, with a SteelHead-SD in the branch and separate SteelHeads (for WAN optimisation) and SteelConnect devices (for SD-WAN) in the Data Centre.
Many customers that are using SteelHeads in their environment are using SteelCentral Controller for SteelHead (SCC, formerly CMC) to manage their fleet. The good news is: SCC 9.6.2 and up supports the SteelHead-SD, so you would manage WAN optimisation exactly the same on a SteelHead-SD as you would on a ‘traditional’ SteelHead. All the SD-WAN features are managed through SteelConnect Manager.
One thing that I often get asked is how it works when you have multiple WANs, as the ‘traditional’ SteelHead has a 1:1 mapping between LAN & WAN ports in in-path/inline mode.
Well, the answer is: there is no 1:1 mapping anymore on the SteelHead-SD, it’s all configured in SteelConnect Manager.
For example, a common setup is to have 1 LAN port in use, and 2 WAN ports (for internet and MPLS).
There is internal pinning happening to make sure that all traffic from LAN <-> WAN goes through the virtual SteelHead to ensure optimisation of traffic and increase the user experience.
Last but not least: the current SteelHead-SD models are 570-SD, 770-SD and 3070-SD. However, the ‘traditional’ SteelHead 570, 770 and 3070 are of course still available.
If the business needs WAN optimisation, but isn’t ready to go full SD-WAN yet, the 570/770/3070 SD-Ready devices are a good option. These are SteelHeads-only (no SD-WAN), but they have the capability to be software-upgraded to SteelHead-SD devices at a later stage to enable the SD-WAN functionality as well. Talk to your account team for more information on this if it’s of interest.
With that I’ll conclude the series on SteelConnect and wish you a happy 2018, stay tuned for more goodness this year!
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