In a previous article, I reviewed Riverbed’s time at Network Field Day. I listened to Riverbed discuss their SD-WAN solution and how they make the connection better. By adding their features, they can allow network traffic to traverse the Internet safely and at better speeds. After that post, I was able to get access to a POC environment including being able to deploy my very own branch device. Here is what I discovered.
I listened to some YouTube videos on the deployment before trying it. That made it seem a little complicated as there are a few different components. Then I realized it all makes sense once you understand what each component does. How you deploy the solution is the real key to success. Just like any other network deployment, it is extremely important to plan first. For instance, what do you expect your branch networks to look like? Small branches do not need much hardware but maybe you want to run supporting services (like DHCP) on the Riverbed appliance because there are no servers there. Resiliency is extremely important with WAN connections so designing your headend system is crucial. Plus, make sure you already have your network plan for things like IP addressing.
Deploying the Headend
Once planning is complete, the first thing you have to deploy is the headend. It controls the setup, performs all the logging, and connects and configures the branches – it’s the brains of the operation. There are three parts of the headend: the Director, the Analytics, and the Controller. As its name implies, the Director does all the administrative work. This is where you will log in to set up templates and make changes to the environment. Analytics handles search and logging. It is all behind-the-scenes stuff but really important – don’t cheap out on your Analytics. Finally, the Controller is what all the branches will connect back to. All three components can run with redundancy, which is something I recommend in production environments. Riverbed has a really good blog post that explains this better.
One of the things I found really interesting is that the headend components can run on different platforms including bare-metal, virtual machines, and even in a cloud service such as AWS and Azure. An easy way to get running quickly would be on a Riverbed appliance as they take care of all the hardware. Additionally, the components can run on the same box, across different boxes, or even a mix of virtual and physical appliances. For robust deployments, I recommend separating the Director, Analytics, and Controller components. If you want to save some money, run the Director on your existing virtual environment (or even in Azure) – just make sure to have two virtual appliances for redundancy. Do not skimp on the devices running as Analytics or Controllers. For ultra-redundancy, run a pair of Controllers in each of two data centers – four in total. All of these get placed behind your firewall, so don’t forget to set up rules to allow the tunneled traffic.
Building a Branch Unit
Each branch site gets its own device that connects back to the Controllers. Fortunately, there is not a lot of configuration that is needed on the branch device. It really depends on the networks at the site – how the Internet is connected and how your local network is setup. The process actually starts on the Director where you build a template for the site. The template actually has multiple purposes. First, it is used to deploy each appliance but later you can modify a template and the changes get pushed out to all devices using that template. After the template is created, you add the device in the Director using the template. The key piece is to use the serial number on the device as that is how the Director verifies the device. For any virtual appliances, you make up a serial number to use – it really can be anything as long as it is unique so try describing the site. For the branch device, you connect it physically making sure to match the ports as you did it in the template – one port goes towards the Internet and the other goes to the branch network. At that point, you can use a python script (supplied by Riverbed) to connect the branch unit back to the Director to grab the configuration. The device will contact the Controller and complete the setup. Riverbed mentions instant branch provisioning on their website but I did not try this feature. For a better explanation of all this, check out this video, which is what I used to help me build my branch unit.
Sometimes a company’s branches will not have server infrastructure nor does the company want to add servers just to run support services. Fortunately, you can add these services to the template. This includes DHCP services, firewalling security policies, and class of service (COS) policies. With the DHCP services, you can even add custom options. On top of that, you can set NTP, Syslog, TACACS, RADIUS, SNMP, and LDAP configurations in the template. Remember that I mentioned you can modify a template to change all of the branch devices? If you change something, like adding TACACS servers, you just need to modify the template and all the devices will get the change – that makes the Director a one-stop place for what used to be a possibly time-consuming change.
Conclusion
I mentioned my previous experience with Riverbed SD-WAN in my earlier post – it required lots of support help. This time, I was able to get my branch device working on my own using their documentation and some YouTube videos. I even did it using Hyper-V running on my Windows 10 laptop. While the performance was fine for what I was doing, I really do not recommend using that setup for anything but a POC. Regardless, what it did show me is that Riverbed has come a long way since my last time rolling out their SD-WAN solution. It really is a lot easier and something almost anyone should be able to deploy. But don’t take my word for it – give them a call to try it yourself.
