A previous company I worked at used private networks to connect all of its sites. That company had locations in the North American, the European, and the Asia-Pacific regions. As you can guess, the amount being spent on the WAN links was pretty high. Every few years, we would renegotiate these contracts while discussing possible alternatives to bring the costs down.
I had already built a DMVPN connection using Cisco routers, which worked well for some sites. DMVPN allowed for a relatively simple-to-deploy connection that used the Internet. Basically, I would build a template for a Cisco router (change some minor things like the tunnel interface IP address and the internal network) and someone could deploy it on a router at the site. Once that router was configured and connected to the Internet, the DMVPN tunnels would connect back to the head-end units I had deployed in our data centers and the site was now connected.
From a time perspective, this was a lot quicker than acquiring a private connection from a telco and a lot cheaper. But it had some disadvantages so it was not good enough for most of our sites. For starters, there was no real management interface (it was all CLI), troubleshooting was mainly through debug commands, and it was just a VPN connection so nothing like traffic prioritization. Also, while I could adjust the configuration to allow for a mesh-style connection, it would have been more like many point-to-point connections. This meant that scaling up may have meant purchasing better routers to support all those VPN tunnels, losing a little of the cost advantage. Something better would be needed to replace that expensive private connection at all of the sites.
First Experience with Riverbed
Fortunately, SD-WAN was just starting to get good. The concept was like a better version of DMVPN as it worked over the Internet and solved those pesky disadvantages. Of course, there were a lot of vendors selling their own version of SD-WAN. We were building a new site that was for support teams, such as IT, so it was decided that it was a good time to try SD-WAN instead of purchasing another expensive private connection. Riverbed was the first to offer us a proof of concept so we could try it with the new site. We just needed to order a business-class Internet connection, send the Riverbed SteelHead SD appliance to the site, and have someone connect all of the cables.
According to Riverbed, the appliance would reach out to the management service and we could configure it remotely to connect back to the ones we installed in our data centers. Unfortunately, it did not work as well as they claimed but they were there to help deal with the issues, which included remote firmware updates on all the appliances, cloud software updates, and tweaking the configurations. The good news was that none of the issues required replacing the appliances – just lots of patience while we worked with support. At that time, I would say that it was a viable solution but nothing made it stand out compared to others. Essentially, it was just good enough for our needs.
Revisiting Riverbed and Loving It
Fast forward to early 2020 and I visited Riverbed while attending Network Field Day 22. I wasn’t looking for anything in particular, but I was expecting their setup to be better – less of the problems I had experienced previously. Based on only their live demonstration, they lived up to this expectation and more. When I previously deployed the solution, it was just about the connection and getting the different sites to communicate. Since then, the world has become more cloud-connected and the Riverbed solution seems to have grown with it.
Some of the concepts they went over would have made my previous experience much better. Back then, we had to work with support after a connection went live to optimize traffic. While this worked, it was far from perfect. For instance, any new application could mean we would need to call support again to help optimize the traffic. However, according to the demo, Riverbed has added some easier tuning capabilities. They did not spend a lot of time on it but that is because it was not needed – some quick changes could be made by admins right in the console. It was almost like an equalizer on your stereo as you can make simple tweaks to the communications.
Introducing Adaptive SLA Monitoring
Another concept they introduced was Adaptive SLA monitoring. Riverbed gave us a visual on the network probes they use to respond to network events. An outage can halt business and these probes allow the service to respond when a problem occurs like switching automatically to a backup connection. Probes are like loose change: while a few is something you tend to overlook, they can add up to a huge amount if you let them go unchecked. But when sites do not communicate that often, do you still need all of those probes? Adaptive SLA Monitoring dials back on the number of probes needed with connections that are lighter on traffic.
A concept that Riverbed spent a good amount of time on was WAN acceleration as it is where the company started. Applications can complicate network traffic. When you add in latency due to physical separation over vast distances, it gets even more problematic. Plus, not all traffic is the same. For instance, HTTP traffic is designed very differently than CIFS traffic. By performing inline packet inspection, the Riverbed appliances can accelerate traffic. According to Riverbed, they can work on different traffic types like CIFS, SharePoint, Outlook traffic (MAPI over HTTPS), SSL/TLS, HTTP(S), and others.
How can they accelerate encrypted traffic like HTTPS and SSL/TLS? They can do some acceleration but with encrypted traffic, it is not possible to work on the entire stream without being able to decrypt it. Riverbed claims that if a company has its own PKI infrastructure then they can integrate it with their SD-WAN service to allow even better acceleration. On top of that, they have TCP Transport Streamlining which allows TCP handshakes to end at the local appliance rather than going over the WAN so clients can respond at LAN speeds rather than waiting for the far side device to respond.
All of this (plus other concepts they mentioned) make it appear that Riverbed has vastly improved since I have helped to deploy their SD-WAN solution in the past. Their presentations made me interested in doing a new review so I can see if what they showed us works the same way today. I am working with Riverbed on a new proof of concept, so stay tuned to see if it did get easier.
