alexfray SD-WAN, VeloCloud

SD-WAN – VMware SD-WAN by VeloCloud – Part 2

velocloud-casestudy

VeloCloud is a leading SD-WAN product which was procured by VMware 2 years ago and has since been rebranded VMware SD-WAN by VeloCloud. VeloCloud along with Viptela were the first pure players which really kick started the SD-WAN revolution so its no surprise really that both were scooped up by VMware and Cisco respectively.

Note. For background info on VeloCloud please read my Part 1 blog.

Cisco’s purchase of Viptela was a no-brainer with Cisco’s I-WAN effort not really making the cut but VMware’s purchase of VeloCloud seemed odd to me at the time. What is the virtualization giant going to do with a WAN product? Turns out it was a great purchase. VeloCloud comes as a hardware or virtual appliance and is supported on Azure, AWS and GCP. VMware have now partnered with all three of these public cloud providers enabling VMware customers to move their virtual machine workloads from on-premise to the cloud and also between cloud providers, enabling customers to optimize workloads. And what can you use as the transit mechanism for this? Yep, you’ve guessed it, VMware SD-WAN by VeloCloud.

The key advantages of using SD-WAN and the Internet as transit when you are moving workloads to the cloud are:

  • Single WAN platform – Using SD-WAN you have one platform to manage as opposed to using a combination of products, VPNs and circuits (e.g. expressroute and direct connect) which often don’t interoperate. This also creates a routing nightmare with a mix of dynamic and static routing and often manual intervention. Using SD-WAN means you have any-to-any connectivity (Mesh VPN) between all your sites and cloud environments, simplifying your WAN.
  • Time to Deliver – One benefit I have seen first hand of using SD-WAN and the Internet as transit is that when I have introduced a new cloud region, for example in Azure, I have deployed a virtual VeloCloud Edge in the new VNET and within minutes the VNET is part of my VPN overlay and routable from any site and cloud environment. It finally feels like you can deploy a network as easily as you have been able to deploy virtual machines for all these years.
  • Multi Cloud Strategy – If you are planning on a multi-cloud strategy and by this i mean multiple public cloud providers and potentially private cloud in the mix then it really doesn’t make sense to use expressroute or direct connect circuits. The Internet is the next corporate network. Wedding yourself to your MPLS network/provider by installing expressroute or direct connect circuits shouldn’t even be entertained in most instances (there are always exceptions).
  • Internet is the next corporate network  – Now if you have already started using Software as a Service such as Office 365 then you have already started to adopt this premise. If you are using a mixture of on-premise, SaaS and IaaS then using the Internet as your corporate network starts to make sense as the balance starts to shift as you migrate applications from your on-premise data centres to the cloud. SD-WAN is an enabler to use the Internet as your corporate network by securing your sites and enabling connectivity between them and your cloud environments. Want proof? You don’t see Service Providers investing in MPLS anymore they are partnering with VeloCloud and Viptela, among others, to provide managed SD-WAN solutions.

Using VMware SD-WAN by VeloCloud has enabled me to design solutions which are optimal for hybrid and mutli cloud deployments and deliver real business and technical benefits. For more information about why SD-WAN and vendor selection please see my other blogs.

Alex

SD-WAN – A New Hope

SD-WAN – Vendor/Platform Selection

alexfray SD-WAN, VeloCloud

SD-WAN – VMware SD-WAN by VeloCloud – Part 1

I’ve been using VMware NSX SD-WAN by VeloCloud (and that mouthful for the remainder of the post will be referred to as VeloCloud), for the last 4 months. I thought it would be useful to provide an unbiased technical evaluation of the product with a lot of network architects and engineers beginning to dip their toe into the SD-WAN market either this year or next hardware refresh.

I’ve covered why SD-WAN in another blog but in short the key driver for SD-WAN is Cloud service adoption. The shift of traffic patterns from on-premise data centres to the Internet (SaaS/PaaS/IaaS) and SD-WAN’s ability to provide simple deployment, VPN and secure local Internet breakout either by itself, Virtual Network Function (such as a Palo Alto) or service chaining to a cloud security service such as Zscaler.

Product Features

VeloCloud stood out to me when compared to rivals for a few reasons. I’ve covered SD-WAN product selection in another blog so these are the features having now productionised an SD-WAN environment that I think VeloCloud excels at.

Deployment – Once you have designed and piloted your SD-WAN environment deploying branch VCEs is simple. It takes the stress out of a site migration for an engineer and time to deliver is much quicker. In one instance I arrived at small branch site, migrated, tested and left in less an hour. This isn’t always the case as with larger or more complex branch sites requiring more testing but the VeloCloud deployment was never the issue and in most cases I could deploy the VCE in parallel of the existing WAN so that the downtime was minimal when cutting across.

QoE (Quality of Experience) – If you intend to use multiple WAN links for all or some of your branch sites, the QoE monitoring and VeloCloud’s Dynamic MultiPath Optimization (DMPO) protocol is seriously impressive. DMPO enables per packet steering across the best WAN link and QoE reports on why it moved the traffic whether it detected packet loss, increased latency or jitter. It also has the ability to buffer, duplicate packets or perform error correction on the fly. Sounds good right? I’m currently running Voice over IP over the Internet, granted my bandwidth and latency are good but this is typically a reason why enterprises are looking to deploy SD-WAN in hybrid mode (Internet and MPLS), my experience so far is that even with contention on the WAN links there has yet to be any call degradation.

QoS (Quality of Service) – Referred to as the business policy, this has application recognition and the ability for an administrator to move applications to different queues to fit the customer’s traffic pattern. VeloCloud kindly provide a starter policy which to be fair doesn’t need that much altering to get you started. The VOIP traffic as mentioned above is categorized as Real Time Protocol and put in the realtime queue which gives it outbound and inbound priority over other traffic, so even if you only have a single WAN link the VCE will still perform error correction. buffering, duplication and QoS.

Monitoring – Having used CA Spectrum and SolarWinds for years network engineers are used to fairly basic monitoring systems. The VeloCloud monitoring is mind blowing. You get all your typical statistics on bandwidth, latency, jitter etc however you also get appflow data to see what applications are being used and how much bandwidth they are using so you can see how much bandwidth a SQL query takes up one hour to the extent that you can see how much bandwidth Windows Updates have used over a year. That’s right almost instantly you can go back up to a year to that level of granularity. And then you can do something about it, for example I could see Windows updates continually using a significant amount of Internet bandwidth so instead of letting it impact users I created a business policy rule for Windows updates and put it in the low priority queue, I did this at the profile level which meant once I finished, the rule got pushed out by the Orchestrator to all branch VCEs. This visibility into the WAN and simplicity to implement application layer QoS is awesome and will benefit many enterprises.

Product Integration

VeloCloud was bought by VMware just over a year ago. In terms of product integration, there doesn’t seem to have been many announcements. I Instantly think of Viptela’s integration with Cisco and how it is already available as a container on the Cisco ISR router. But is this like-for-like? Yes and no, VMware doesn’t do routers so that was never going to be their market, so I can only surmise that VeloCloud will integrate with their existing NSX portfolio to improve their workload management capabilities between on-premise, private and public cloud providers.

While VeloCloud’s integration into VMware appears a bit slow, its integration with Microsoft and their Azure Virtual WAN has been quick. Azure Virtual WAN offers an alternative to spinning up a VeloCloud Edge virtual appliance in Azure which if you are already using Virtual WAN or a have a mixed bag of WAN solutions maybe worth investigating. Myself, I prefer a full stack, having VeloCloud throughput provides end-to-end QoS (within the VPN) using the Business Policy and excellent traffic visibility in a single dashboard. However if you have many Azure locations or subscriptions this might not be cost effective in which case Azure Virtual WAN should be strongly considered.

If I had to ask for an integration feature I would like the ability to use an external Identity Provider (IdP) such as Azure AD or Okta to control management access to the VeloCloud Orchestrator, leveraging an existing identity source and conditional based access policies.

Product Development

VeloCloud is still a developing product, like all SD-WAN products out there. I am currently using the latest version as it allows me to have direct IPsec tunnels from a branch site VeloCloud Edge (VCE) to a Cloud Security Service (Zscaler). Before this release the tunnel to Zscaler was from the cloud hosted VeloCloud Gateways (VCG). The idea of a single, resilient egress point from your VPN overlay to your cloud security service seems like a good design however, remember that IPsec tunnels to Zscaler are limited to 200Mbps so depending on the size of your organisation this may not be suitable. To be fair this isn’t a VeloCloud issue but it is something to be mindful of if you are integrating with a Cloud Security Service. Direct Tunnels from a VCE to Zscaler allow me to pick and choose which sites should use Zscaler and whether it should be used as the default route (using the Zscaler Cloud Firewall) or just for web traffic. The profile functionality of VeloCloud is very good for this and enables you to configure at scale.

One area that still needs improvement is the tunnel failover, which is planned to use IP SLA soon (IP SLA is used if using the Cloud Gateway method today).

Having used earlier versions of the code it does seem to have stabilized which is good with more emphasis on stability as opposed to rushing new features into a release, which shows a maturing product. Getting hold of release notes however was not easy, it would be good if these were made available publicly or in the VeloCloud Orchestrator.

Product Documentation

When down selecting VeloCloud it was very difficult to find any technical documentation, just the sales and solution briefs on the website which made it hard to compare the product to its rivals; although Cisco made a good mess of their website with a mix of I-WAN and Viptela (now resolved). The technical documentation is located in the VeloCloud Orchestrator which is great once you have access but trying to ascertain whether the product met a customer’s technical requirements prior to an evaluation was a bit painful and may put off some potential customers if they can’t find the information.

Now the help documentation is a mixed bag. I hold the Zscaler help documentation to be one of the better public help document repositories as it is easy to navigate and the instructions, whether is be design, implement or troubleshoot are clear and inline with the current version at that time. The VeloCloud technical documentation needs some work.

Product Support

VeloCloud Support are very responsive and the engineers I have dealt with so far are very knowledgable about the product. In some scenarios I wish I was able to SSH into the VCEs like the support engineers do to troubleshoot but then I remember this isn’t a Cisco router, its a cloud managed service. It would be good to have a cloud health status page and I believe that service providers have this kind of visibility but for enterprise customers it would be good to know if there are live issues with the underlying cloud service.

Summary

The above is my opinion based on my experience of the VeloCloud ecosystem. I look forward to see how it evolves and i’m sure my minor gripes will be resolved at some point. If you would like to discuss SD-WAN or VeloCloud please reach out to me.

Alex

alexfray SD-WAN

SD-WAN – Vendor/Platform Selection

Choosing an SD-WAN vendor/platform has become increasingly difficult as the WAN edge market rapidly expands. This blog provides a summary of my thought process when down selecting SD-WAN vendors/platforms.

SD-WAN Vendors/platforms typically fall into one of four categories:

  • Pure Players – are start-ups such as VeloCloud and Viptela which are the two main disrupters in the WAN edge market. Both start-ups were acquired by VMware and Cisco respectively and lead the Gartner magic quadrant for WAN edge 2018.
  • WAN Optimization – This category includes companies such as Riverbed, Silverpeak and Citrix, essentially businesses which out of necessity to survive have diversified from the dying WAN Op market to SD-WAN. In my opinion Riverbed should have bought Silverpeak to boost there market share as Silverpeak has a decent amount of customers and a very solid platform. That’s not to say Riverbed’s acquisition of Ocedo was bad as the Riverbed platform is pretty good from what I have evaluated and will get better over time. However unless you already have a Riverbed WAN Op deployment would you consider Riverbed over a pure player which is designed from the ground up to be cloud driven SD-WAN not WAN OP with a SD-WAN bolt-on.
  • Security – This category includes traditional security vendors such as Barracuda, Fortinet and Palo Alto Networks. NGFW’s already have VPN capabilities so SD-WAN is a natural feature to provide. What puzzles me is why Checkpoint haven’t ventured into the fray when the other NGFW leaders have. While these vendor offerings will be secure they lack a mature cloud management platform and similarly to the WAN Op category feels like a bolt-on feature to try and maintain existing customers.
  • Managed Service – As organisations start to move away from MPLS, providers are pivoting to provide managed SD-WAN services. Now this is an interesting and valid proposition depending on your business requirements and operating model. Orange Business Services offer some good solutions here if you are looking at a managed service (Note. I don’t work for OBS). The managed services I have seen are using Viptela or VeloCloud under the hood which I think says a lot about the strength of the pure player category.

Your existing network architecture and/or experience in some of the above vendors may influence your decision or at least help narrow down the field. However your decision should be based on which vendor/platform meets your business and technical requirements. I’ve pulled together some key technical requirements below when evaluating SD-WAN vendors/platforms. This is not an exhaustive list by any means.

  • Virtual Appliance – Whilst all SD-WAN vendors will have a physical appliance available, ensure that their range of appliances meet all your site and bandwidth requirements. However not all SD-WAN vendors have a cloud based appliance. Most organisations will have a public cloud presence so it is important to ensure your SD-WAN vendor has an appliance available in the respective cloud’s marketplace. VeloCloud and Viptela both support both AWS and Azure so it is relatively easy to extend your WAN to the cloud. If your SD-WAN vendor doesn’t have a public cloud appliance then what are your options? Well from a Microsoft perspective they have recently released Azure Virtual WAN which integrates with a number of SD-WAN vendors such as Citrix, Riverbed and VeloCloud among others so you don’t need a dedicated virtual appliance. The downside is that you don’t get complete visibility of your SD-WAN environment, you loose out on network and application visibility statistics and any QoS or application prioritization you may want to configure. I see this integration for smaller enterprise customers or perhaps Dev/Test and Pre-Production environments to reduce cost.
  • VPN Throughput – Typically most SD-WAN vendors have a range of physical appliances which will fit most organisation’s bandwidth/throughput requirements however their respective virtual appliance can often be quite poor with regards to VPN throughput. Now if your public cloud deployment is quite large then is a key requirement. I have been provided with some truly terrible solutions (workarounds by Vendors) by spreading the load across multiple appliances using IP prefixes which would be a routing nightmare in Azure or AWS and this is just masking their problem.
  • Cloud Management – You would assume this was a given but even big players like Citrix don’t have a cloud management platform. My main considerations around cloud management are typically, where is it? Working in the UK/EU you want to ensure that your cloud management is in the same region to ensure data compliance. Most vendors will host you on your nearest Orchestrator, for example VeloCloud’s EU Orchestrator is hosted in AWS in Frankfurt and I believe London is on the road map but if you are a multi-national organisation you may want to consider which region you want your orchestrator. The next consideration is what data is held and does this have GDPR implications. Ensure your SD-WAN vendor has GDPR information available and that you engage your legal department to ensure you are compliant.
  • Cryptography – Having evaluated a number of leading SD-WAN vendors, I was surprised how lacking some were in terms IPsec variables such as IKE version, encryption and hashing algorithms. Typically I hold NCSC’s IPsec foundation profile as the benchmark. VeloCloud can meet this profile which is a big tick if you are working with UK defence and public sector customers. Not only does it meet the criteria but some parameters are meet the PRIME profile which is like the unicorn of crypto security.

NCSC Foundation Profile – IKEv1, AES-128 CBC, SHA-256, DH group 14 and Certificate based authentication.

Most secure VeloCloud Profile – IKEv2, AES-256 GCM, SHA-256, DH group 14 and Certificate based authentication.

https://www.ncsc.gov.uk/guidance/using-ipsec-protect-data

  • PKI – Use of certificates for authentication requires a PKI. Certificate based authentication is the preferred method of authentication because it is more scalable and secure than pre-shared keys. Most organisations will have a PKI (of sorts) however it is doubtful this will be exposed to the Internet, assuming your SD-WAN will be configured in Internet or hybrid mode. The VeloCloud Orchestrator has a CA baked in which makes deploying certificate authentication very easy. Upon activating a VeloCloud Edge device the Edge is issued a 90 day RSA 2048 bit certificate. This certificate is renewed at 80% to ensure continued connectivity. You can revoke certificates in the Orchestrator or by deleting an Edge the certificate is also revoked.

You can use a mix of PSK and Certificates in the VeloCloud platform if you wish, sometimes integration with 3rd parties doesn’t allow for certificate authentication so you can fallback to PSK. VeloCloud give you the option of Certificate disabled, Optional or Required. Disabled is fairly obvious but Optional means a VPN device/edge using PSK can communicate to Edges using PSKs or Certificates which allows for flexibility but does reduce security somewhat. Required means that if an edge uses certificate authentication it can only communicate to other edges that use certificates, this is very secure but not as flexible so really depends on your requirements.

  • Ease of Deployment – One of the big selling points of SD-WAN is the ease of deployment. Most Pure Players and WAN Op SD-WAN vendors offer this. What I have found though is that when you do have deployment issues they have very little local troubleshooting capabilities which is very frustrating when you can’t even run a ping to your gateway or do a DNS lookup.
  • Service Chaining – Depending on which SD-WAN vendor you’ve chosen and how you are going to break out to the Internet this may or may not be a consideration for you. However if you already use a cloud security service like Zscaler then tunnelling your local branch Internet traffic to the Zscaler cloud is a no-brainer as it is no additional cost (depending on your bundle). Large enterprises like Siemens do this as opposed to running local branch firewalls or VNFs. With over 2200 branch sites that’s a very scalable solution.
  • Dynamic Routing – As I have said before SD-WAN appliances are not Cisco routers. If you need routing resilience or integration with your Interior Gateway Protocol (IGP) be sure your chosen SD-WAN vendor supports your IGP fully. Viptela and VeloCloud supports OSPF and BGP but a lot of SD-WAN vendors have pretty poor IGP support so ensure you research this. In particular when they say OSPF supported it is typically only in passive mode, yeah thanks for that.

There are lots of other considerations when choosing an SD-WAN vendor/platform, there is no one-size fits all so spend your time building your requirements, engaging with vendors and do a or multiple proof of concepts. What the vendor says and how the platform performs can differ considerably.

Alex

alexfray SD-WAN, VeloCloud, Zscaler

SD-WAN – A New Hope

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.

Key Drivers

  • 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.

SD-WAN

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.

Benefits

  • 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.

Negatives

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?

Summary

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.

alexfray SD-WAN, Zscaler

Zscaler – Zenith Live 2018 – SD-WAN

We are at Zenith Live at Heathrow this week to check out the latest Zscaler features and roadmap as well as to give them some grief on some of the issues we’ve had on customer implementations.

21/10/18 – SD-WAN Integration Training

Spending my Sunday configuring IPSec VPNs to Zscaler from Cisco Viptela and Riverbed SD-WAN appliances, now that’s dedication. I’m at the SD-WAN training session today to get a feel for other SD-WAN providers and see how they compare to VeloCloud.

Roadmap – Zscaler allows SD-WAN vendors to link in via API calls. Both Riverbed and VeloCloud should have this integration in Q1 2019. What does this give you? Well it means the VeloCloud Orchestrator can automatically configure the VPN Credentials and Location in the Zscaler admin portal using an API call. Another provisioning step automated.

Riverbed Lab

13:04 Brandon Carroll, Senior Technical Evangelist from Riverbed is up next. I’m excited to hear the visionary imaginearing he’s been doing in his role 😀 To be fair Riverbed are pushing SD-WAN hard, and so they should or they will fold with the WAN Optimisation market dying, if not already dead. Companies who have already invested in Riverbed will probably be looking at their platform but I can’t see why you would otherwise.

Initial thoughts, the Riverbed Steelhead Manager, which is the Riverbed Orchestrator, looks pretty good. Their network map shows all the sites status and the VPN tunnels between the sites, which is really neat when compared to the VeloCloud network map which is really basic and lacking info. The map might get messy on a large deployment but does look cool and handy to see established tunnels. The Zscaler configuration is very simple and you get a lot of information such as events and latency to the chosen Zen nodes. There is a balance here, the manager is rather cluttered and overwhelming with tabs and options, there is a lot going on but also a lot of useful information so it really depends on what you want. It looks very complicated in comparison to VeloCloud however I do wish VeloCloud had more information and stats.

The Riverbed lab was pretty good to get some hands on the Riverbed SD-WAN. Like VeloCloud it is very easy to connect to Zscaler. The dashboard is pretty slick to be fair (screenshot below).

river-1.png

Ok speaking to the evangelist, its starting to fall apart. The Riverbed solution is full mesh only or to the hub only. Now this means in full mesh mode the smallest site would need to connect to every site. So the hardware spec of your smallest site depends on how many sites you have so you may need a large appliance at a small site because you have so many sites/tunnels to support. That doesn’t seem very scalable for a large deployment. How much branch-to-branch traffic do you really have? Its only voice these days really so why not make it dynamic tunnels to reduce the overhead.

Cisco Viptela Lab

15:02 No representative from Cisco to push Viptela which is a shame but nonetheless we deep dive into Viptela configuration. If you want an SD-WAN solution which is pretty much the same as configuring a Cisco ISR router then this is for you. Personally I don’t see the point. One of the main goals of moving to SD-WAN is to simplify branch site administration and yes I know you can use templates but there are a lot of templates. If you need this type of granularity then maybe this is for you. Viptela is really aimed at Service Providers / Large Enterprises and it has the price tag to match. It is cool to see exactly what code is being pushed to the devices instead of just hitting a button and just hoping the magic happens as with VeloCloud and Riverbed and the Cisco geek in me loves to reminisce over DMVPN rollouts and CLI but I just don’t see it for SMBs or small to mid enterprises.viptela-1

The integration with Zscaler was fairly easy but a lot more convoluted then VeloCloud and Riverbed. I had to create two feature templates and modify my routing feature template then bind to my device template. When you have more templates than devices the dynamic is wrong.