Multiple flavors of SD-WAN are available on the market today. One area of differentiation amongst them is whether or not there is a vendor-hosted traffic handling component in the architecture. In cases where there is no vendor hosting of traffic handling SD-WAN components, devices owned by the business, or, the existing network, are expected to handle all traffic. In cases where there is a vendor providing hosting of some traffic handling components – such as in a cloud access point of presence (POP) – devices owned by the vendor are responsible for handling some traffic. While on the surface this seems to be an unimportant detail, there are several subtleties that must be considered. Knowing which architecture an SD-WAN solution requires can mean quite a bit when it comes to not only realizing the full benefit of your SD-WAN solution, but also the business implications.
POPs are commonplace in telco architectures and especially telco-provided SD-WAN solutions. This would be advantageous if the provider had them located in all areas within 1 to 2 hops of the end sites. However, even in Metro areas, where most POPs are located, you still must deal with oversubscription at the aggregation layer, as well as inefficient routing due to upstream provider peering.
To give a brief example of this, I only have to go back a few years in my career when I was working as a network engineer. We had 2 ISPs coming into our company and they were peered via BGP with full tables. Well, we had an issue where we lost one provider and only half of our staff could access the corporate network via VPN. After peering through route-servers on the internet we found that all users on only one ISP could not reach our office. The problem was due to preferential routing being used by that ISP for traffic routing. Their routing preference was configured statically and not considering the failure at corporate; thus, BGP was not re-converging to address the lost connectivity. They were sending all traffic destined to our office into a black hole. Unfortunately, all our users that were experiencing the issue were customers of that ISPs DSL service.
POPs aggregate your solution onto the provider or vendor’s backbone. This backbone is generally a shared MPLS network being used alongside multiple customers. Any aggregation
across a shared infrastructure can lead to problems with oversubscription of the base network. In addition, QoS within the POP SD-WAN devices can be completely ignored, or prioritization may not properly employed across flows for the same customer – and even worse, across flows from different customers. In short, your traffic is comingled with traffic from other customers on the same links and same SD-WAN devices. From a performance perspective, this raises the questions “when there’s congestion, do I get better performance than your other customers?” and “can activity from other customers affect the performance I would otherwise expect if I owned the device?”
Further complicating the issue, SD-WAN solutions that include a vendor-hosted POP can create legal and compliance concerns. Most businesses deal with some kind of regulation – be it from payment processing, healthcare, federal/state/local law, or otherwise – and the WAN itself is generally under scrutiny to meet certain requirements. These businesses must consider whether or not the POP itself presents a potential compliance violation, whether or not the vendor has access to unencrypted data on the wire or even in memory on the SD-WAN devices, and the relative security of those systems and the networks to which they attach. Even if those systems and networks are secure, they extend the surface area of the compliance scope and evaluation, penetration testing, and vulnerability management, which adds time and cost to the organization’s process. Whether a business is under regulation from PCI, Sarbanes-Oxley, HIPAA, GLBA, or others, these items must be considered when deploying an SD-WAN solution, particularly those that employ vendor-owned and vendor-hosted POPs.