SD-WAN带宽怎么规划？从业务流量到链路选型
简答：SD-WAN带宽不能只按员工人数或套餐峰值估算。正确做法是先统计业务高峰期的上下行流量，再加入隧道与策略开销、增长预留和故障切换条件，最后同时校验链路、加密吞吐、并发会话与应用SLA。本文给出可套用的计算公式和上线前检查步骤。
定义：SD-WAN带宽规划，是把各站点在业务高峰、链路故障和增长场景下的应用流量需求，转换为可验收的上下行链路与设备容量。
结论速查：先按峰值算，再按故障场景验收
SD-WAN带宽规划与普通宽带估算的区别，在于它不仅关注“买多少兆”，还要关注应用优先级、链路质量、流量方向、隧道封装、选路策略和单链路故障后的剩余容量。厂商资料普遍建议先建立站点与应用流量基线，再持续观察接口利用率和业务时段变化，而不是直接使用全天平均值。Broadcom容量规划白皮书明确区分了业务时间与非业务时间的利用率。
| 规划对象 | 先看什么 | 验收标准 |
|---|---|---|
| 站点总带宽 | 业务高峰上下行合计 | 高峰期不因持续拥塞影响关键应用 |
| 主备链路 | 主链路故障后的关键业务流量 | 单条存活链路仍能承载关键应用 |
| 双活链路 | 两条链路的有效容量与选路方式 | 不能把简单相加当成单会话速度 |
| 设备规格 | 加密吞吐、并发会话、接口和策略能力 | 设备能力不成为链路瓶颈 |
| 业务质量 | 丢包、延迟、抖动和应用SLA | 带宽足够且关键应用满足目标SLA |
先试这一步：从每个站点导出至少一个完整业务周期的接口利用率、应用流量、上下行峰值和链路质量数据；如果没有历史数据，先用业务清单和并发假设计算初版，并把假设标注为“待实测”。
前置条件：规划前必须收集的输入数据
建议按站点建立一张容量表，不要只填写员工人数。至少收集以下字段：
- 用户与终端：常驻用户数、同时在线人数、无线终端、摄像头、电话、云桌面终端和物联网设备数量。
- 应用并发：办公SaaS、文件传输、视频会议、语音、远程桌面、备份、监控回传等应用在高峰时的并发数。
- 流量方向：分别记录下载和上传，不要用一个总带宽掩盖上行瓶颈。视频会议、备份和监控回传通常需要单独核对上行。
- 时间窗口：业务高峰、午间、月末、批处理、备份窗口和非业务时段。全天平均值可能掩盖短时拥塞。
- 链路条件：运营商标称速率、实际交付速率、是否共享接入、SLA、计费方式、可用性以及不同线路的物理分集。
- 设备限制：WAN接口速率、加密转发能力、启用QoS或安全策略后的吞吐、并发会话上限、许可限制和控制面带宽要求。具体数值必须以目标设备当前规格书或控制台为准。
- 质量目标：关键应用允许的丢包、延迟和抖动范围，以及故障切换允许的中断时间。SD-WAN可以根据链路质量选择路径，但不会把低质量链路自动变成高质量链路。Cisco文档说明，其应用感知选路会依据丢包、延迟和抖动等指标执行策略。Cisco Catalyst SD-WAN Design Guide
如果暂时没有流量监控数据，可以先做“保守初版”：列出所有关键应用、并发数和上下行方向，使用供应商或应用厂商给出的目标速率；不能核实的应用速率不要写成固定标准，应标记为待测。
最短流程：用公式把业务需求换算成带宽
- 按应用计算峰值需求。
应用峰值带宽 = 并发数 × 单会话目标速率
分别计算下载和上传，再按业务高峰时间相加。单会话目标速率是规划输入，不是本文提供的统一性能基准。 - 区分关键业务与普通业务。
语音、视频会议、远程桌面等交互业务应单独列出；文件同步、备份和系统更新可放入普通或批量业务。不要用QoS替代容量规划，QoS只能在拥塞时决定谁优先。 - 加入隧道、加密和策略预留。
有效需求 = 应用峰值总和 × (1 + 开销预留)
开销来自隧道封装、加密、QoS、纠错、复制和管理流量。不同协议、设备和功能的开销不同，不能直接套用一个固定百分比；应以设备文档、接口统计或实测结果校准。 - 加入目标利用率与增长预留。
采购参考带宽 = 有效需求 ÷ 目标利用率 × (1 + 增长预留)
目标利用率不是行业统一值，应根据业务突发、运营商交付方式、SLA和故障策略设定。增长预留也应写明周期，例如未来半年或一年，而不是无限放大。 - 上下行分别取值。
下载和上传需要分别计算。最终采购规格应满足：下载链路不低于下载参考带宽，上行链路不低于上传参考带宽。
示例：某分支在业务高峰假设有12路视频会议，每路按3 Mbps规划；20个SaaS并发会话，每路按0.5 Mbps规划；批量传输按20 Mbps规划；10路语音按每路0.1 Mbps规划。应用峰值合计为67 Mbps。若项目暂按20%的隧道及管理预留、70%的目标利用率计算，则参考带宽约为114 Mbps；工程上可把150 Mbps作为待核实的采购档位，再通过监控数据和故障测试校准。这个例子只是计算演示，不是视频、语音或SaaS的通用速率承诺。
场景对比：不同业务怎样影响上下行规划
| 场景 | 主要风险 | 规划方法 |
|---|---|---|
| 普通分支办公 | 网页、SaaS和文件流量叠加 | 按高峰并发计算，并单列系统更新与大文件传输 |
| 视频会议 | 上下行同时持续，占用对实时质量敏感 | 按会议并发数分别计算上下行，配合丢包、延迟和抖动监测 |
| 语音办公 | 单流量不大，但对抖动和丢包敏感 | 单独划分优先级，确认QoS、队列和故障路径 |
| 云桌面或远程桌面 | 交互延迟影响体验，突发图像流量明显 | 按并发会话和高峰操作场景测试，不能只看平均流量 |
| 备份与监控回传 | 容易挤占上行或跨站点出口 | 计算持续传输窗口，必要时限速或安排非业务时段 |
| 多云与跨区域办公 | 出口位置、路径质量和跨区域时延成为瓶颈 | 分别核对云出口、跨区域链路和应用实际路径，不只看接入带宽 |
SD-WAN的价值通常不只是叠加链路，而是结合应用识别、QoS、路径质量和策略进行转发。Cisco资料将应用感知选路、QoS、FEC和数据包复制列为不同的性能优化能力；这些功能可能增加设备处理量或实际链路消耗，因此启用前要重新核算有效容量。Cisco SD-WAN QoS说明
双链路与故障切换：不要只验证正常状态
带宽规划至少要计算三种状态：
- 正常状态：两条链路按既定策略承载普通与关键业务，检查每条链路的峰值利用率。
- 单链路故障：把关键业务和必须继续运行的普通业务放到剩余链路，确认剩余链路在目标利用率下仍有足够容量。
- 双链路质量下降：链路未完全中断但丢包、延迟或抖动超标时，确认应用感知选路、QoS和告警是否按预期工作。
可用以下公式做故障校验：
故障后需求 = 关键业务峰值 + 故障时仍需保留的普通业务
故障后可承载量 = 存活链路实际可用带宽 × 目标利用率
只有当“故障后需求”不大于“故障后可承载量”时，单链路方案才具备容量上的可行性。主动主动负载均衡也不能简单把两条链路的标称带宽相加，因为单会话分配、哈希、路径质量和设备实现都会影响实际结果。H3C资料可作为理解链路带宽、隧道和会话选路关系的厂商技术参考，但具体字段和能力仍需按目标设备版本核实。H3C SD-WAN技术白皮书
上线验证步骤：
- 记录两条链路在正常状态下的下载、上传、丢包、延迟和抖动。
- 安排业务低风险窗口，逐条断开主链路或模拟链路质量下降。
- 确认关键应用是否按策略切换，普通业务是否按预期降级。
- 观察剩余链路接口利用率、设备CPU、加密吞吐和会话数。
- 恢复链路后检查路由回切、会话恢复、告警清除和策略状态。
验证与持续调整：用95分位和业务结果校准
没有实测数据时，本文只提供核验框架，不提供任何固定测速、可用性或性能保证。部署后建议同时保存以下数据：
- 接口下载与上传利用率，至少按业务时段分组。
- 关键应用的并发量、吞吐、响应时间和失败率。
- 隧道丢包、延迟、抖动，以及链路切换前后的变化。
- QoS队列丢弃、整形、限速和重传数据。
- 设备加密吞吐、CPU、内存、并发会话和接口错误。
可以用95分位利用率观察持续容量压力，再结合最高峰、故障测试和业务投诉判断是否扩容。95分位不是所有项目都必须采用的唯一标准，它只是比单次最大值更适合观察长期趋势的一种统计方式。Broadcom资料建议通过一段时间的接口利用率变化识别正常使用、过载接口和低利用率接口，并把容量规划作为持续监控过程。Broadcom SD-WAN Capacity Planning and Optimization
调整时按顺序处理：先确认是否为真实容量不足，再排除DNS、MTU、丢包、错误选路、QoS配置和设备性能问题；只有在链路和策略均正常、且高峰持续接近上限时，才把扩容作为主要方案。
边界与延伸：采购前的联合检查清单
- 链路：确认标称带宽、实际交付带宽、上下载方向、共享比、SLA和故障报修边界。
- 路径：确认不同运营商、不同接入方式和不同出口是否真正具备物理或逻辑分集。
- 设备：分别核对未加密与加密转发能力、启用安全策略后的吞吐、并发会话和接口速率。
- 功能：确认QoS、FEC、复制、流量整形、应用识别和路径探测是否支持目标版本与型号。
- 许可：确认功能许可证、控制器规模、站点数量和集中管理能力，未核实的版本与价格不要写入采购结论。
- 全球站点：把跨区域时延、云出口位置、运营商覆盖和当地线路可用性作为独立条件，不用“带宽足够”代替网络质量验收。
- 回退：为每项策略保留原配置、变更窗口、回退命令或控制台路径；动态菜单名称应以当前版本界面为准。
最终交付物至少包括：站点带宽表、应用流量假设、正常与故障计算、设备能力核对、链路质量基线、验收记录和扩容触发条件。
常见问题
SD-WAN带宽是不是两条线路相加？
不一定。两条链路的标称带宽可以作为站点总容量的输入，但实际可用容量还受流量分配、单会话哈希、路径质量、QoS、设备加密吞吐和业务方向影响。故障规划必须单独验证剩余一条链路。
SD-WAN带宽规划应该看平均值还是峰值？
应以业务高峰和关键应用峰值为主，全天平均值只能用于观察趋势。非业务时段流量较低，直接与业务高峰平均可能掩盖拥塞风险。
视频会议带宽应该重点看下载还是上传？
两者都要看。视频会议通常存在持续的双向媒体流，必须分别统计上下行并发；如果多人同时开会，还要额外检查上行链路、丢包、延迟和抖动。
启用QoS后还需要增加带宽吗？
可能需要。QoS可以让关键业务在拥塞时优先，但不能消除总容量不足；如果关键业务本身超过链路有效容量，仍会出现排队、丢弃或业务降级。
没有历史流量数据，怎样开始规划？
先建立应用清单，记录用户数、并发数、上下行方向和高峰时段，再用明确标注的假设值计算初版；上线后通过接口利用率、应用流量和故障测试校准，不要把估算值当成实测结果。
设备加密吞吐为什么必须和带宽一起检查？
因为链路采购带宽不等于设备能够处理的有效吞吐。启用IPsec、QoS、纠错、复制或安全策略后，设备的转发、加密和会话处理能力可能成为瓶颈，具体能力必须以目标型号和当前版本资料核实。