目前市场上有多种SD-WAN可供选择。其中一个区别在于架构中是否存在供应商托管的流量处理组件。如果没有供应商托管业务处理SD-WAN组件的供应商，则业务所拥有的设备或现有网络应该处理所有流量。如果有供应商提供某些流量处理组件的托管，例如在云访问接入点(POP)中，供应商拥有的设备负责处理某些流量。虽然从表面上看是一个微不足道的环节，但必须考虑几个细微之处。了解SD-WAN解决方案所需的架构，可以实现SD-WAN解决方案的全部优势。

　　POP在电信架构中很常见，尤其是电信公司提供的SD-WAN解决方案。如果提供商将它们放置在终点站点的1到2跳内的所有区域中，则这将是有利的。但是，即使在大多数POP所在的Metro区域，仍然必须处理聚合层的超额订阅，以及由于上游提供商对等而导致的低效路由。

　　不幸，POP会将您的解决方案聚合到提供商或供应商的主干上，该骨干通常是与多个客户一起使用的共享MPLS网络，跨共享基础架构的任何聚合都可能导致基础网络超额预订，网络通信不安全，完全忽略POP SD-WAN设备中的QoS，或者可能无法在同一客户的流之间正确使用优先级。更糟糕的是，来自不同客户的流，简而言之，您的流量来自同一链路和相同SD-WAN设备上的其他客户的流量。从性能的角度来看，这提出了“当出现拥塞时，我会比其他客户获得更好的性能吗?”以及“如果我拥有该设备，其他客户的活动会影响我预期的性能吗?”

　　此问题进一步复杂化，包含供应商托管POP的SD-WAN解决方案可能会产生法律和合规性问题。大多数企业都会处理某种监管，论是来自支付处理，医疗保健，联邦/州/地方法律还是其他，而且WAN本身通常都在严格审查以满足某些要求。这些企业必须考虑POP本身是否存在潜在的合规性违规，无论供应商是否可以访问SD-WAN设备上的无线数据甚至内存中的未加密数据，以及这些系统和网络的相对安全性的附件条件。即使这些系统和网络是安全的，它们也会扩展合规范围和评估，渗透测试和漏洞管理的表面区域，这会增加组织流程的时间和成本。

专栏文章内容及配图由作者撰写发布，仅供工程师学习之用，如有侵权或者其他违规问题，请联系本站处理。 联系我们