The latest trend in the network world is Software Defined WAN (SD-WAN). By 2023 Gartner predicts 80% of organisations will have moved to SD-WAN so it’s worth taking note. So why SD-WAN? What are the drivers to bin your trusty Cisco routers and even your MPLS network.
- Applications have moved to the cloud. Traffic patterns have changed, Apps and data are moving from your on-premise data centre to the cloud, whether that be Infrastructure, Platform or Software as a Service (IaaS/PaaS/SaaS). The biggest game-changer here is Office 365.
- Office 365 adoption is a global phenomenon. Every business is either thinking, designing or implementing their Office 365 strategy. Office 365 provides a variety of services but the key ones from a network perspective are Exchange Online, Skype for Business, Sharepoint Online and Azure AD. The problem is that most businesses neglect the network and assume it will just work with the current network and security infrastructure that they have. Typical problems include, but are not limited to:
- Forward Proxy – Exchange Online uses multiple connections per user, typically two per mailbox and calendar. Average user probably requires 6 TCP connections. Doesn’t sound like much but times that by the number of concurrent users, then how many shared mailboxes and calendars and this can be a vast amount. Problem is your firewalls and proxies can only do between 25k to 50k NAT translations per IP so often you get port exhaustion. Note. I know the theoretical limit is 64k but check what your appliances can actually handle, its probably a lot lower when you take into account reservations. This problem is compounded as half of these connections are persistent and remain open for large periods of time not like typical web browsing behaviour. Add your general web browsing on top of this traffic and you have got between 20-30 connections per user.
- Bandwidth – Exchange Online is hungry. On average I’ve seen 1000 users require 50Mbps of Internet bandwidth just for exchange online. Times this by the number of concurrent users in your organisation and that could be a significant amount of bandwidth and potential uplift in network and security infrastructure.
- Microsoft best practice – Microsoft say not to proxy Office 365 traffic, no authentication, no SSL inspection as it adds latency which Exchange Online in particular does not like. If Outlook performance is poor and you raise a call with Microsoft and you have traffic traversing proxies they instantly blame your infrastructure. The only approved forward proxy is Zscaler and their one-click configuration. Microsoft also recommend 1 public IP address per 2000 users, this can also be an issue for some organisations and i’m not sure if this is still relevant now that Outlook 2013 SP1 and above uses MAPI-over-HTTPS as opposed to that piece of crap protocol RPC-over-HTTPS, so do your diligence on this point.
A new hope… We have been building data centres and centralising IT infrastructure for the last 20 years. The next IT cycle is a form of network decentralisation. This is in the form of local branch Internet breakout. For years we have backhauled Internet traffic to data centres, have it traverse expensive and complex network and security infrastructure (load balancers, forward proxies, DLP, AV, SSL inspection, NGFW) before the traffic even hit the Internet. Local Internet breakout and SD-WAN offer a decentralised solution to meet the business demand for utilising cloud services, reduce cost and reliance on on-premise data centres.
- SD-WAN enables local Internet breakout at branch sites. Leveraging local Internet improves latency, reduces data centre infrastructure costs and removes potential bandwidth bottlenecks attributed with backhauling.
- The Internet is the new corporate network. MPLS circuits are typically very expensive and have a long lead time. If most of your apps are moving or are already in the cloud why should you buy an MPLS circuit? Organisations can look to buy commodity Internet or broadband services cheaper and quicker to provide access directly to cloud services. SD-WAN helps your journey from MPLS to Internet by using a hybrid deployment (MPLS and Internet) or Internet only deployment., if you need to keep your MPLS circuits for certain traffic types such as on-premise VOIP or certain business applications you could run in hybrid mode until you completely transition to an Internet-only deployment. Most organisations see this as a phased approach but it really depends on your business requirements and existing traffic flows. If you can, move to Internet-only, it’s a lot simpler from a routing perspective and you can present a good saving in the move.
- SD-WAN can (in some Vendors) prioritise traffic. Vendors like VeloCloud, Silverpeak and Riverbed can prioritise traffic using application recognition so you can prioritise Office 365 traffic over productivity-loss applications like youtube. VeloCloud is particularly good at prioritising realtime traffic, measuring jitter and latency it will duplicate packets to fill the gaps and make the voice or video call smoother.
- Service Chaining. Most SD-WAN vendors do not bake a Next Gen Firewall into their product. Why would they when so many are on the market. VeloCloud for example allows a Palo Alto Networks NGFW as a Virtual Network Function (VNF) on an edge device so you could have a local NGFW firewall. This doesn’t really do it for me though, imagine you had 100+ sites, that’s 100+ NGFWs to manage. What is cool, is integration with cloud security services like Zscaler. You establish a tunnel (GRE or IPSEC depending on vendor) to the security service and all your Internet traffic is tunnelled via their security service. One policy to manage, no VNF to manage and maintain, now that’s cool.
- Bring QoS back from the dead. Yes, I know QoS is a key requirement for VOIP and Video but when we started moving to web apps and encrypting web traffic using SSL, WAN Optimization and QoS started to lose their value because all traffic looked the same, so how can you prioritise it at the network level? You can’t. SD-WAN, however can as it does it at layer-7 using application recognition and its also very easy to do using a business policy and profile as opposed to QoS which is just overly complex.
- Simplified management. Most SD-WAN vendors provide a cloud management platform which make it very easy to manage and deploy a new WAN. The key seller here is zero-touch deployment. This makes me cringe a little bit because its not like the DHL van man can rock up at your branch site and install it. Someone need to migrate your existing LAN/WLAN equipment to the SD-WAN appliance and inevitably some backend routing/firewall changes would be required so its not really zero touch its just perhaps you don’t need a CCNP certified engineer to attend and install at each site.
- Profiles. From a VeloCloud perspective, profiles allow you to configure a profile with a lot of standard settings that can be applied to all or a subset of edge devices so that there is minimal effort to get a new edge device up and running. Only unique config is required such as static WAN IP and VLANs.
- Integrated PKI. Having designed and implemented Cisco PKI’s in the past, I have a sigh of relief that your SD-WAN’s PKI can be handled automatically by the SD-WAN Orchestrator. Certificates are generated on activation, can be revoked and update much more frequently without having to worry about maintaining a PKI.
- Crypto. I reckon I’ve configured over 500 VPN tunnels over my career and the amount of time I’ve spent troublehooting mis-matched crypto settings with 3rd parties makes me sad. Not an issue with SD-WAN your crypto is set at the policy/system level so all the edge devices use the same IKE version, encryption, hashing and SA timeouts.
- In-sourcing. Another driver for simplified management is in-sourcing. A lot of organisations are moving away from big outsourced contracts and using their in-house IT department. Now, this team might not be Cisco DMVPN experts, so SD-WAN can really help them effectively manage the WAN with very little network skills. It does help if you have some though.
- Netflow. I love Netflow it gives some really good analytics into bandwidth usage. This is baked into the SD-WAN platform so you can see top talkers, applications used and then create your business policy to reflect conditions such as prioritising business collaboration applications and lowering file sharing applications to the bulk queue.
- Packet Capture. On VeloCloud Edges you can perform packet captures up to 120 seconds and download them from the Orchestrator and open the pcap in Wireshark to troubleshoot any issues. That’s handy.
Yes there are some negative to SD-WAN.
- Product Maturity. The code is riddled with bugs. The amount of code issues I have had on VeloCloud and Riverbed platforms makes me pine for my trusty Cisco router. Vendors need to focus on stability rather than more and more features to how do the competition. If it ain’t stable, i’m not putting into production. The only saviour here is that most code issues I have identified are fixed in days not months like traditional network vendors so they are a lot more agile.
- Expensive. Most SD-WAN vendors try and sell their product based on you reducing or removing your MPLS circuits for cheap Internet circuits. Fact is, you are unlikely to go and get broadband at all your sites its likely to be decent Internet circuits which aren’t that cheaper than MPLS circuits. SD-WAN appliances aren’t as cheap as a Cisco router. They typically have an OPEX model so you will typically buy a 3 or 5 year service as opposed to a one-off purchase of a router. Most license based on bandwidth so it really depends on the size and amount of circuits your organisation has.
- Service Chaining limits. Zscaler has a soft limit of 200Mbps for each IPsec tunnel and 1Gbps for each GRE tunnel. Bear in mind when choosing an SD-WAN vendor that most of them only do IPsec tunnels (Cisco Viptela, VeloCloud and Riverbed). Zscaler’s solution is to load balance tunnels if you require greater bandwidth. Now this may not be an issue for you, but some of my customers have 2000+ users in a campus so this is going to be an issue.
- Couldn’t I just do split-tunnel DMVPN with my Cisco routers? Yes you could, but as per the benefits I’ve mentioned, SD-WAN is not just split tunnelling. I’ve not even gone into the detail about bonding multiple Internet links, 4G resilience etc. You could change your DMVPN to some kind of IWAN type solution but even Cisco is ditching this so why design a solution that even the vendor is moving away from. Cisco’s proposition is Viptela for Service Provider and Large enterprise and Meraki for small to mid enterprise. If your business has no cash and you want to be a hero with an A-Team type solution then by all means “do up the van” 🙂
- Not everyone will be onboard. Believe it or not, not everyone is in love with the cloud. You really need key stakeholders on board for SD-WAN as it is a drastic change to typical enterprise network design. Some people want to hold onto their castle and moat network designs. This is no longer fit for purpose. Why protect the castle if your apps are outside of it?
It is very likely that your next WAN upgrade will involve SD-WAN, whether that be in hybrid mode or Internet only. Network design needs to evolve to user centric and not data centre centric. When making your product decision, make sure you gather your business and technical requirements. Not all SD-WAN vendors are the same, make sure they can do decent crypto, PKI, integration with routing protocols etc. Don’t assume anything, these device are not Cisco routers.