老网工： SD-WAN运维经验及相关开源技术分享

作者简介：杨文斌，山东未来网络研究院（紫金山实验室工业互联网创新应用基地）专家；北京大地云网科技有限公司技术总监，在SDNLAB上发表了多篇“老网工”文章。

编者按

SD-WAN早已走过炒作进入应用，据IDC报告显示，2022上半年中国SD-WAN市场规模为1.2亿美元，同比增长45.8%。随着SD-WAN组网方案继续发展成熟，预计其后续部署仍有较大潜力。目前关于SD-WAN的文章多是从市场分析、技术方案等角度展开，本文作者独辟蹊径，根据其几十年的网络经验和几年的SD-WAN从业经历，介绍了SD-WAN运维相关经验。SD-WAN实际运维会面临哪些棘手问题？SD-WAN产品设计对运维会产生什么影响？SD-WAN有哪些开源工具？SD-WAN从业人员需要具备哪些技能？我们一起来看看。

尽管从部署和使用者角度来看SD-WAN非常简单， 但SD-WAN的运维却并不容易 ：SD-WAN运维过程中会涉及产品能力理解（产品能力或设计架构）、客户环境问题排障、互联网底层问题、组网设计、软件迭代开发和发布、服务流程的管理，以及和其它系统对接等诸多问题, 覆盖范围很广。

作为一个SD-WAN创业团队，我们需要支撑几十家大型基础运营商、服务商和企业的复杂SD-WAN二线运维。虽说是二线支持，但有时客户基础环境出问题（如互联网、防火墙配置的导致SD-WAN业务问题 ，通常80%以上都是基础环境相关），我们也需要参与分析排障。

作为网络领域浪漫又务实的技术，SD-WAN有着极简部署、一键组网和上云、统一的配策略管理和运维管理等特点，笔者非常看好。本文将重点聊聊笔者在SD-WAN运维过程中解决问题常用的网络技术、开源工具和心得体会，同时在此感谢这些年一起并肩战斗在第一线和第二线的SD-WAN运维网工和研发网工。

SD-WAN产品能力

产品本身的设计和自愈能力，尤其是控制器的架构设计在SD-WAN运维和支撑中至关重要：光鲜的SD-WAN光环下其实面临着艰巨的运维工作，SD-WAN多是大型服务商面向多租户场景使用，SD-WAN运维保障和后台支持压力很大。

在市场推销SD-WAN的时候，部署运维简化是一大亮点，但真正接手运维之后，客户环境千差万别，运维中各种问题层次不穷：CPE穿透防火墙问题，POP点NAT映射也会经常出错，而且还需要考虑基于互联网SD-WAN是否会不稳定的风险，客户SD-WAN系统会不会DOWN机，技术人员有限如何支撑成千上万的多租户CPE……

下面先聊聊几个SD-WAN产品能力对运维的影响：

• SD-WAN的架构设计至关重要

由于SD-WAN是基于互联网组网技术，CPE连接控制器和POP系统基本上基于互联网实现，互联网可靠性和尽力而为的机制有一定的局限性或薄弱环节，这就要求SD-WAN控制器系统尤其是CPE（承载租户业务）具有较强容忍性和自愈能力。可以说系统设计架构是决定SD-WAN 可靠性能力的重要因素。几年前谈过SD-WAN四种业务场景架构（https://www.sdnlab.com/22769.html），今天谈谈目前业界SD-WAN内部的几种典型转控分离设计架构，下面仅为作者个人分析 （不针对任何厂商，请勿对号入座）。

# 强控模式

数据流的包或第一个包的处理基于控制器的参与，典型的是基于OpenFlow的SDN/SD-WAN技术架构，这种设计属于强控模式，控制器出问题会直接影响流表转发，大大影响系统的稳定性和性能，基本上已经被淘汰。

# 中控模式

基于SD-WAN路由反射器设计组网，RR 是控制层的核心组件，主要负责网络控制，RR参与或负责租户VPN路由的分发和过滤、VPN 站点间Overlay隧道的创建和维护等。中控模式下，RR的稳定性和性能也会对全网造成很大影响（尽管RR有备份，如MPLS RR也很稳定，但互联网环境什么可能性都会有），对于大型服务商SD-WAN多租户网络建议慎重评估。

# 弱控模式-或者真正的转控分离模式

在规划设计SD-WAN架构的时候，控制器只负责配置策略、系统管理和监控等，转发层面租户VPN路由学习都是由CPE基于控制的配置策略在本地实现，类似数据中心SDN+ VXLAN/EVPN的思路。以大地云网TerraEdge为例，在可靠性设计有三个铁定原则和设计理念：

1）SD-WAN控制器不参与转发面

2）即使正常运行阶段控制器通讯失联，业务也不受影响

3）即使控制器断掉或失联，转发面（CPE和POP）设备有强大的自愈能力，客户CPE业务不受影响并且具有基于已有的策略进行自愈和选路的自动修复

• POP 智能探测和切换

经常和朋友讨论SD-WAN和传统路由器网络最大的区别，我会毫不犹豫说是基于POP站点的智能探测和选路算法。IP网络发展了几十年，但是服务保障SLA/QOS一直是个千年难题，传统网络是基于IP QoS技术当中的两种服务体系：IntServ和DiffServ。DiffServ是基于类的QoS技术，没有端到端QOS能力；IntServ是端到端的基于流的QoS技术，但是节点/网络管理和配置是一个复杂和艰巨的任务，导致很难大规模部署。

SD-WAN系统的POP点的探测和切换策略是SD-WAN系统成功的关键，客户设备CPE智能探测互联网网络服务质量，选择最佳POP站点（POP站点通常建议多运营商出口）以及实时监测和自动切换，这个机制目前可以很好地解决互联网SLA质量问题以及跨运营商瓶颈问题，确保核心业务访问获取更好体验。我们基于POP点的服务质量探测和切换策略研究了一个TerraFlow的网络机器算法模型，包括延时、抖动、丢包、带宽、路由切换、路由防泄漏、稳定性等约束条件进行自动化探测和隧道管理。同时POP算法中还引入了多隧道机制和Active/Active机制，不仅解决互联网SLA质量问题，同时也是对可靠性的很好保障。

• 租户CPE的几个特色运维功能

CPE 加密端口动态调整：由于各种情况，互联网经常会出现加密端口封杀、SD-WAN加密端口号协商、VPN加密端口自动调整等情况，如支持对IPSEC SSLVPN 端口动态调整，实现复杂环境下的业务上线。

CPE MTU动态探测和调整：通常VPN技术中的MTU问题是个头疼问题，我们在SD-WAN增加 MTU的检测和调整以及 DF-BIT清除，使网络更加健壮易用。

• 账号管理：分级分权账号和审计

基于多租户下分级分权分域管理在SD-WAN系统运维管理和安全至关重要。以TerraEdge账号管理为例，角色支持三级：系统管理员、合作伙伴管理员、租户管理员，不同账户可以有不同的可视化界面管理权限和资源管理能力。这个功能对大型服务商或者基础运营商非常有用，既有利于业务拓展更有利于系统的安全运维管理。

SD-WAN常用的开源工具

俗话说，工欲善其事必先利其器。SD-WAN开发设计通常会用到许多开源技术， 如：ODL、ONOS、RYU、SpringCloud、kafka 、mysql/mongodb、Grafana、K8S/Docker、Linux/Openwrt 、Nginx 、FRR、VPP/DPDK、NetConf/Yang Model等开源技术；CPE硬件开发还会涉及 Arm、x86、Wi-Fi、4G/5G 以及相关Linux Kernel/Driver等适配工作。SD-WAN作为NetDevops成功典范之一，对于SD-WAN运维和技术网工，不仅需要了解产品设计的相关开源技术，同时还需要了熟悉相关的开源工具包括Linux相关的网络工具，下面就一些常用的运维支撑开源工具加以介绍：

• Jumpserver：推荐指数 5星

简述：Jumpserver是使用python的Django开发的开源堡垒机系统，相对于普通的跳板机，堡垒机可以看作一个升级版的跳板机，为互联网企业提供了认证、授权、审计和自动化运维等功能。在SD-WAN系统中Jumpserver是一个很好的运维工具，利用Jumpserver堡垒机登陆控制台，POP节点等作为运维平台，对安全管理和追溯记录蛮好的。

另外SD-WAN系统是多租户设计，由于租户的CPE系统没有带外管理和公网地址，管理CPE成为了一个挑战，为此SD-WAN厂商通常会提供一些手段以在CPE有异常的情况下登录到CPE进行排障（专用CPE跳板机系统就是其中工具之一），考虑到安全，通常只有管理员账户在得到租户许可才具备登陆CPE权限。

简述：Jenkins 是一款业界最好的完成CI/CD持续集成持续部署的工具，用于自动化各种任务，包括自动编译、分发、部署和测试等。在SD-WAN系统中，除了软件的迭代开发持续测试，也可基于Jenkins做系统运维数据备份，防止灾难发生。别小看这个备份，SD-WAN控制系统管理全网的资源、POP和CPE配置，而SD-WAN控制平台又在互联网访问环境运行，自然风险会相对增加，因此，SD-WAN系统运维数据备份直接关系到生产业务，至关重要。另外SD-WAN软件版本灰度发布也可以用Jenkins进行管理。

简述：ZenMap是安全扫描工具NMap的一个官方图形用户界面，NMap是一个开放源代码的网络探测和安全审核的工具。使用Zenmap工具可以快速地扫描大型网络或单个主机的信息。如扫描主机提供了哪些服务，使用的操作系统等，它是SD-WAN网络管理员必用的软件之一，我强烈建议SD-WAN运维人员使用。

在SD-WAN 环境，CPE 通过互联网连接控制器和POP节点，建立到POP节点的IPSEC/SSL/国密安全隧道，我们碰到最多的问题是VPN隧道的建立，CPE在客户侧，客户环境有时“很复杂” 或做了很多复杂安全限制，或者客户侧的ISP服务商也会有些限制，如何判断到控制器和POP节点互联网协议和端口是否正常，ZenMap会是一个很好的手段或工具。如图：

简述：Postman是和研发人员对接很好的“沟通桥梁”。Postman是一个接口测试工具，在做接口测试的时候，Postman相当于一个客户端，它可以模拟用户发起的各类HTTP请求，将请求数据发送至服务端，获取对应的响应结果, 从而验证响应中的结果数据是否和预期值相匹配; 并确保开发人员能够及时处理接口中的问题，进而保证产品上线之后的稳定性和安全性。

SD-WAN系统中，功能在不断迭代开发，客户通常还会有自己的业务门户和编排系统，通过RestAPI调用SD-WAN控制器，实现业务统一管理和运维，Postman是一个偏向于开发的接口测试工具，SD-WAN网工如果掌握这个技能就可以方便和客户的业务系统开发人员有更多共同语言，展现SD-WAN网工的能力和强大魅力。

简述：在SD-WAN运维中，实际上也是将DevOps的理念引入到网络领域（NetDevOps）典型场景，利用技术与工具提高自动化运维水平，目标是实现网络的自动化管理。这就需要SD-WAN网工在传统复杂网络协议基础上增加可编程能力和自动化脚本技能，其中 Ansible和Python 成为SD-WAN运维网工的网工必备和技能之一，也是提高日常管理、系统备份、排障效率、运维效率重要手段和工具。

简述：TCPDump是根据使用者的定义对网络上的数据包进行截获的包分析工具，可以将网络中传送的数据包完全截获下来提供分析。它支持针对网络层、协议、主机、网络或端口的过滤。

SD-WAN系统中，控制器/POP节点以及CPE基本上在防火墙测都做了NAT，我们碰到很多次客户抱怨隧道建立不正常，或者非常奇怪的现象，排障到最后发现是防火墙NAT做的不对或者产生异步路径，这时候强烈推荐通过 TCPDump抓包看看源IP地址和NAT是否正确。

简述：iperf3是一个广泛使用的网络性能测量和调整工具, 用于主动测试IP网络上最大可用带宽的工具。它支持时序、缓冲区、协议（TCP，UDP，SCTP与IPv4和IPv6）有关的各种参数。可以创建数据流来测量两端之间单向或双向的网络吞吐量。典型的iperf输出包含一个有时间标记的数据传输量和吞吐量测量的报告。

SD-WAN有时候由于各种原因，CPE带宽很难达到客户期望，iperf3打流就成为网工必备技能，有时还需要调整TCP Window Size设置窗口大小。iperf3里面很多参数，如：其中一个-R反向模式运行（Server 端发送，Client 端接收），蛮有意思。

简述：iptables命令是Linux上常用的防火墙软件，是netfilter项目的一部分, iptables是采用数据包过滤机制工作的，所以它会对请求的数据包的包头进行分析，并根据我们预先设定的规则进行匹配来决定是否可以进入主机。

SD-WAN 场景：基本上SD-WAN大多基于Linux开发或部署，SD-WAN的系统安全极为重要，经常会遇到各种各样的补丁风险和漏斗。没有软件是完美无缺的，通常软件补丁更新有个滞后期，但有时不需要频繁修改，熟练使用iptables在风险或漏洞告警的时候对系统进行加固和访问策略调整也是SD-WAN网工的基本技能。

简述：Linux中可以使用命令行工具nc，判断指定端口的TCP和UDP连接是否通畅 。通常SD-WAN的系统基于Linux开发，nc命令使用起来相对简单。本人使用Mac电脑，Mac也可以使用nc命令作为客户端工具进行端口探测，但是感觉MACBOOK NC端口探测有时不准确，更喜欢用Zenmap。

网络技能和画象能力

简述：SD-WAN是基于网络技术的发展，基础网络技术尤其是WAN路由器和VPN技术是SD-WAN运维人员基础技能。

SD-WAN 技术的自动ZTP、自动探测、自动组网，从使用者看来只是一个简单配置，但是由于SD-WAN内部设计依赖复杂和健壮的BGP或IGP协议以及很多网络和VPN技术， SD-WAN的运维排障人员还需要对WAN路由技术和VPN安全技术有丰厚的底蕴，包括各种路由技术、GRE/VXLAN、DNS、MPLS SR(集成MPLS网络)、IP QOS、负载分担加速、FEC/BBR、VPN加密技术，DPI、SASE、安全/NAT、SDN等网络协议或技术全面理解，同时在大型多域云网环境还需要对云网融合有一定理解，通常懂网络技术尤其是动手经验的人，如CCIE/CCNP技术人员在支撑SD-WAN会更加得心应手。这个相信搞网络的都懂得，就不再赘述。

确定问题关键：善于运用以上的技术经验、开源工具，对产品由有深入了解的基础下，还需要有排障的逻辑思维能力，要能够根据合作伙伴或客户提供的片段信息，第一时间组织一个假象的若干可能和最可能的线索。如客户抱怨CPE隧道问题，是CPE和控制器的通讯问题，还是CPE到POP出现问题，还是CPE本身互联网的问题；是加密隧道端口问题、NAT防火墙或者MTU问题？这考验着工程师的经验和逻辑思维能力，能够根据问题快速逻辑画象，同时会根据初步判断结合Log进一步分析。除了逻辑思维能力，还可以建立研发、售前和售后的共享知识库，运维同事可以从研发获取第一手的产品设计原理资料和知识经验，快速解决客户的问题 。

结束语

作为一名老网工，经历网络发展30年来的起起伏伏，从X.25、IPX、SNA、ATM/MPoA，GE/IP，MPLS，VXLAN/EVPN，SRv6，SDN 到今天多云时代互联时代的 SD-WAN。SD-WAN作为在云网融合时代下一颗冉冉升起的新星，尽管没有带来划时代的新标准和协议，但SD-WAN融入了各种网络技术并打磨成组网极简新服务模式，使用者仅需点点鼠标就可实现自动上线、云接入、企业组网等一站式上云和组网的业务，他们不再担心复杂的路由协议配置、网络和路由环路、VPN加密策略、备份切换等，就可轻松实现全球分支机构的组网和上线（有时候我喜欢拿SD-WAN比作网络领域的“微信”） 。

但这背后要求SD-WAN后台网工具备更扎实的网络基础知识、多样性的开源技能和逻辑分析经验, 同时还需要具备一定的编程能力和脚本技能。本文提到的开源技术或网络工具也仅仅是我们日常运维中用到的冰山一角，篇幅有限很多细节无法展开。最后谈点对SD-WAN 技术未来发展的个人看法：

1）SD-WAN通用的协议或标准规范：实现多厂商控制器和POP/CPE分层解耦和多厂商互操作能力（目前基本上是厂商各管各的设备，这个估计短期很难实现）；

2）E2E端到端的智能探测和算法，如将机器学习和E2E的探测和算法深度结合， 将SD-WAN服务质量探测和确定性网络技术相结合，将E2E隧道延展到云内、SRv6流量工程，实现端到端的多域云网协同编排和服务能力；

3）基于机器学习的网络算法和模型、分析工具简化后台运维排障、风险监控和预警分析，解放SD-WAN运维网工，让支撑更加简单。

IT在发展，我们一直在努力。