After numerous false starts, begging, cajoling and a minor tantrum, I finally got myself on a Riverbed Steelhead training course. I’ve worked with Juniper WX (formally Peribit for those of you with long memories) for a number of years. This gave me my first production experience with dynamic routing which, as a security specialist, was pretty scary. During the Steelhead course, I could not help but contrast the two and think about the subtle differences between how the technologies go about achieving the same thing: accelerating traffic across the WAN.
Finally in October 2012, Juniper announced the “End of life” (EOL) of the entire WX Branch portfolio. Unusually, Juniper also came out and recommended the Riverbed Steelhead as a replacement technology, directing existing customers to the Riverbed WX trade-in program. And so, many long-term Juniper/Peribit customers find themselves staring at a platform refresh in the face; suddenly the “minor” differences between the two products cease to be academic. So, the goal of this pair of posts is to cover some aspects on how the products differ, and how they are similar. But first, some basics:
For traffic to be optimised by any WAN-X, it needs to enter the unit. Both the Steelhead and the WX only start the optimisation process once they successfully intercept the start of the flow: the TCP-SYN packet. The “easy” way to deploy both technologies is as a transparent bridge in “in-line” mode. In larger and especially data-centre environments, you tend to see “off-path” deployments such as Policy Based Routing, WCCPv2 or in the case of the WX, route injection. These off-path deployments tend to be more scalable and reliable, but require more forethought than the “drop-in” approach of the “in-line”.
Once the packet enters the device, we run into our first significant difference between the technologies. The first TCP packet (assuming a completely cold start) to transit the Steelhead injects a header into the TCP-Option field before forwarding the packet otherwise unmolested. Assuming the modified TCP-SYN reaches the WAN port of another Steelhead, the header is stripped, and the packet forwarded onto the original destination. In parallel, an “adjacency” is formed between the client-side Steelhead (CSH) and server-side Steelhead (SSH). An “out-of-band splice” management back-channel between the CSH and SSH devices is also formed. Things get really crazy when there is more than two Steelheads between the client and server, but that’s a topic for another day. Consider the Steelhead method as “send and hope we find another Steelhead on the network”. This makes configuration very easy and the box can be up and running very quickly; it also means that network mapping every corner of your network is not necessary.
The WX approach is somewhat different; the most straightforward comparison is with IPSEC VPN tunnels. One device is designated a registration server into which all the other devices report. Each device (hub, spoke, or mesh node) is configured by the administrator with a list of LAN-speed local subnets which can be optimised. This is achieved by either punching in static routes or learning them dynamically via RIP or OSPF. These routes are pushed to the registration server to allow all other nodes to build a “remote routing table” which looks a lot like an IPSEC Secure Association table, matching remote subnets to remote WXs. This creates an “overlay” routing table to the real one, which can be confusing if you don’t know the WXs are there and how they behave. When a packet enters a WX, it performs a route-table lookup on the source-destination pair; if the packet is headed for a destination it has a matching entry for, it enters the tunnel to go through the various compression and acceleration stages. Otherwise, it’s put back on the wire in pass-through mode and unchanged.
The network level knowledge required to configure the WX means that it is not an especially straightforward product to configure in comparison to the Steelhead. I have run into deployments where an end-user (or even a reseller) has attempted to deploy them without so much as reading the “getting started” guide, working on the premise that, “It’s Juniper. How hard can it be?”. The result was significantly less than an optimised WAN.
So, the Steelhead can pretty much be thrown into the network (indeed, Riverbed has a cheesy video of just this happening) without much effort and it will have a good stab at optimising traffic. The default policy excludes traffic which cannot be optimised without further configuration (Exchange 2010, HTTPs etc.). By default, the WX comes with virtually no configuration, it has to be “told” the location of its registration server, fed the local routes for which it is responsible and which other devices it is allowed to form tunnels with. Frankly, this is a lot of faffing and takes about 30 minutes from cold start to get a device properly interacting with other nodes and optimising traffic flows. However, this is not all bad and does force you to PLAN your deployment properly. Both technologies can fall flat on their respective shiny metal faces unless consideration is given to the proper deployment. Do that with a Steelhead and you’ll kinda/sorta get it working and optimising *some* traffic. With WX, if you don’t plan or understand the target network properly, it’ll spray dropped packets around the place like a leaf blower. This is not rocket science; deploy any technology which messes with the traffic in the way that WAN Optimisation does, and it’s going to end in tears sooner or later.
In my next post, “Riverbed Steelhead vs. Juniper WX Part II – When a tunnel is not a tunnel,” I’ll dig down into the packet-level detail of the different transports used by the two technologies.