在Cisco IOS®；上配置TCP优化功能XE SD-WAN cEdge路由器
简介
本文档介绍Cisco IOS® XE SD-WAN路由器上的传输控制协议(TCP)优化功能，该功能于2019年8月在16.12版本中引入。涵盖的主题包括先决条件、问题描述、解决方案、Viptela OS(vEdge)和XE SD-WAN(cEdge)之间的TCP优化算法差异、配置、验证和相关文档列表。
先决条件
要求
本文档没有任何特定的要求。
使用的组件
本文档中的信息基于Cisco IOS® XE SD-WAN。
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。
问题
两个SD-WAN端之间的WAN链路上的高延迟会导致应用程序性能下降。您必须优化关键TCP流量。
解决方案
使用TCP优化功能时，可以改善两个SD-WAN站点之间关键TCP流的平均TCP吞吐量。
了解cEdge瓶颈带宽和往返传输(BBR)与vEdge(CUBIC)的TCP优化之间的概览和差异
在XE SD-WAN实施中（在cEdge上）使用快速BBR传播时间算法。
Viptela OS(vEdge)有一个不同的、较旧的算法，称为CUBIC。
CUBIC主要考虑丢包问题，并广泛适用于不同的客户端操作系统。Windows、Linux、MacOS、Android已经内置了CUBIC。在某些情况下，如果旧客户端运行不带CUBIC的TCP堆栈，在vEdge上启用TCP优化会带来改进。vEdge TCP CUBIC优化的其中一个例子是使用旧客户端主机和WAN链路出现严重延迟/丢弃的潜艇上。请注意，只有vEdge 1000和vEdge 2000支持TCP CUBIC。
BBR主要关注往返时间和延迟。在丢包时不会。如果您通过公共Internet将数据包从美国西海岸发送到东海岸，甚至发送到欧洲，在大多数情况下，您不会看到任何数据包丢失。公共Internet有时在丢包方面表现过于出色。但是，您看到的却是延迟/延迟。BBR解决了这个问题，BBR由Google在2016年开发。
简而言之，BBR对网络建模，查看每个确认(ACK)并更新最大带宽(BW)和最小往返时间(RTT)。 然后根据模型控制发送：探测最大BW和最小RTT，接近估计BW并保持在接近带宽延迟产品(BDP)的状态。 主要目标是确保高吞吐量和小的瓶颈队列。
Mark Claypool的此幻灯片显示了CUBIC工作所在的区域：
BBR的运营环境更佳，本幻灯片中还显示了Mark Claypool:
如果您想了解有关BBR 算法的更多信息，可以在bbr-dev邮件列表主页Here的顶部找到多个链接了有关BBR的出版物。
小结：
| 平台和算法 |
键输入参数 | 使用案例 |
| cEdge(XE SD-WAN):BBR | RTT/延迟 | 两个SD-WAN站点之间的关键TCP流量 |
| vEdge（Viptela操作系统）：CUBICP | 包丢失 | 没有任何TCP优化的旧客户端 |
支持的XE SD-WAN平台
在XE SD-WAN软件版本16.12.1d中，这些cEdge平台支持TCP优化BBR:
- ISR4331
- ISR4351
- CSR1000v，带8个vCPU，最少8 GB RAM
注意事项
- 当前不支持DRAM小于8 GB RAM的所有平台。
- 目前不支持具有4个或更少数据核心的所有平台。
- TCP优化不支持MTU 2000。
- 目前 — 不支持IPv6流量。
- 不支持对流向第三方BBR服务器的DIA流量进行优化。您需要在两端都安装一个cEdge SD-WAN路由器。
- 在数据中心方案中，每个控制节点(CN)仅支持一个服务节点(SN)。
- 16.12版本不支持在同一设备上同时使用具有安全（UTD容器）和TCP优化的使用案例。从17.2开始支持组合使用案例。操作顺序依次为TCP Opt和Security。数据包将被传送到TCP优化容器，然后服务被链接（无第二次传送）到UTD安全容器。TCP优化是针对整个数据流而完成的，而不是针对前几个字节。如果UTD丢弃，则整个连接被丢弃。
下表汇总了每个版本的警告，并重点说明了支持的硬件平台：
| 场景 |
使用案例 |
16.12.1 |
17.2.1 |
17.3.1 |
17.4.1 |
备注 |
| 分支机构到Internet |
DIA |
无 |
Yes |
Yes |
Yes |
在16.12.1中，互联网接口上未启用AppQoE FIA |
| SAAS |
无 |
Yes |
Yes |
Yes |
在16.12.1中，互联网接口上未启用AppQoE FIA |
|
| 分支机构到DC |
单边缘路由器 |
无 |
无 |
无 |
Yes |
需要支持多个SN |
| 多个边缘路由器 |
无 |
无 |
无 |
Yes |
需要流对称或Appnav流同步。16.12.1未经测试 |
|
| 多个SN |
无 |
无 |
无 |
Yes |
vManage增强功能，可接受多个SN IP |
|
| 分支机构到分支机构 |
全网状网络 （分支到分支） |
Yes |
Yes |
Yes |
Yes |
|
| 集中星型 （分支中心分支） |
无 |
Yes |
Yes |
Yes |
||
| BBR支持 |
带BBR的TCP选项 |
部分 | 部分 |
完全 |
完全 |
|
| 平台 |
支持的平台 |
仅4300和CSR |
除ISR1100外的所有产品 |
all |
all |
配置
SN和CN的概念用于TCP优化：
- SN是一个后台守护程序，负责实际优化TCP流量。
- CN称为AppNav控制器，负责流量选择以及与SN之间的传输。
SN和CN可以在同一路由器上运行，也可以作为不同节点单独运行。
主要使用案例有两个：
- 在同一ISR4k路由器上运行SN和CN的分支机构使用案例。
- 数据中心使用案例，其中CN在ASR1k上运行，SN在单独的CSR1000v虚拟路由器上运行。
本节介绍这两种使用案例。
使用案例1.在分支机构上配置TCP优化（全部在一个cEdge中）
此图显示了分支机构单个独立选项的整体内部架构：
步骤1.要配置TCP优化，您需要在vManage中为TCP优化创建功能模板。导航到配置>模板>功能模板>其他模板> AppQoE，如图所示。
步骤2.将AppQoE功能模板添加到Additional Templates:
以下是模板配置的CLI预览：
service-insertion service-node-group appqoe SNG-APPQOE
service-node 192.3.3.2
!
service-insertion appnav-controller-group appqoe ACG-APPQOE
appnav-controller 192.3.3.1
!
service-insertion service-context appqoe/1
appnav-controller-group ACG-APPQOE
service-node-group SNG-APPQOE
vrf global
enable
! !
interface VirtualPortGroup2
ip address 192.3.3.1 255.255.255.0
no mop enabled
no mop sysid
service-insertion appqoe
!
步骤3.使用所关注的TCP流量的定义创建集中数据策略以进行优化。
举个例子；此数据策略匹配IP前缀10.0.0.0/8（包括源地址和目标地址），并为它启用TCP优化：
下面是vSmart策略的CLI预览：
policy
data-policy _vpn-list-vpn1_TCPOpt_1758410684
vpn-list vpn-list-vpn1
sequence 1
match
destination-ip 10.0.0.0/8
!
action accept
tcp-optimization
!
!
default-action accept
!
lists
site-list TCPOpt-sites
site-id 211
site-id 212
!
vpn-list vpn-list-vpn1
vpn 1
!
!
!
apply-policy
site-list TCPOpt-sites
data-policy _vpn-list-vpn1_TCPOpt_1758410684 all
!
!
使用案例2.使用外部SN配置数据中心中的TCP优化
SN和CN的物理分离是BRANCH使用案例的主要区别。在一体化分支机构使用案例中，使用虚拟端口组接口在同一路由器内完成连接。在数据中心使用案例中，充当CN的ASR1k与作为SN运行的外部CSR1k之间存在AppNav GRE封装隧道。CN和外部SN之间不需要专用链路或交叉连接，简单IP可达性就足够了。
每个SN有一个AppNav(GRE)隧道。为了将来使用，如果支持多个SN，建议对CN和SN之间的网络使用/28子网。
建议在CSR1k上使用两个NIC充当SN。如果必须通过vManage配置/管理SN，则需要SD-WAN控制器的第2个NIC。如果要手动配置/管理SN，则第二个NIC是可选的。
此图显示数据中心ASR1k作为CN运行，CSR1kv作为服务节点SN运行：
ASR1k和外部CSR1k的数据中心使用案例的拓扑如下所示：
此AppQoE功能模板显示配置为控制器的ASR1k:
CSR1k配置为外部服务节点如下所示：
故障切换案例
当外部CSR1k发生故障时，数据中心使用案例中的故障切换（CSR1k充当SN）：
- 由于SN上的TCP会话被终止，已经存在的TCP会话将会丢失。
- 新的TCP会话将发送到最终目的地，但TCP流量未优化（绕行）。
- 如果SN发生故障，相关流量不会进入黑洞。
故障切换检测基于AppNav心跳，即每秒1次。在3或4个错误后，隧道被声明为down。
分支机构使用案例中的故障切换类似 — 如果SN发生故障，流量会直接以未优化的方式发送到目的地。
验证
使用本部分可确认配置能否正常运行。
使用此CLI命令验证CLI上的TCP优化，并查看优化流摘要：
BR11-CSR1k#show plat hardware qfp active feature sdwan datapath appqoe summary TCPOPT summary ---------------- optimized flows : 2 expired flows : 6033 matched flows : 0 divert pkts : 0 bypass pkts : 0 drop pkts : 0 inject pkts : 20959382 error pkts : 88
BR11-CSR1k#
此输出提供有关优化流量的详细信息：
BR11-CSR1k#show platform hardware qfp active flow fos-to-print all
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
GLOBAL CFT ~ Max Flows:2000000 Buckets Num:4000000
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Filtering parameters:
IP1 : ANY
Port1 : ANY
IP2 : ANY
Port2 : ANY
Vrf id : ANY
Application: ANY
TC id: ANY
DST Interface id: ANY
L3 protocol : IPV4/IPV6
L4 protocol : TCP/UDP/ICMP/ICMPV6
Flow type : ANY
Output parameters:
Print CFT internal data ? No
Only print summary ? No
Asymmetric : ANY
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
keyID: SrcIP SrcPort DstIP DstPort L3-Protocol L4-Protocol vrfID
==================================================================
key #0: 192.168.25.254 26113 192.168.25.11 22 IPv4 TCP 3
key #1: 192.168.25.11 22 192.168.25.254 26113 IPv4 TCP 3
==================================================================
key #0: 192.168.25.254 26173 192.168.25.11 22 IPv4 TCP 3
key #1: 192.168.25.11 22 192.168.25.254 26173 IPv4 TCP 3
==================================================================
key #0: 10.212.1.10 52255 10.211.1.10 8089 IPv4 TCP 2
key #1: 10.211.1.10 8089 10.212.1.10 52255 IPv4 TCP 2
Data for FO with id: 2
-------------------------
appqoe: flow action DIVERT, svc_idx 0, divert pkt_cnt 1, bypass pkt_cnt 0, drop pkt_cnt 0, inject pkt_cnt 1, error pkt_cnt 0, ingress_intf Tunnel2, egress_intf GigabitEthernet3
==================================================================
key #0: 10.212.1.10 52254 10.211.1.10 8089 IPv4 TCP 2
key #1: 10.211.1.10 8089 10.212.1.10 52254 IPv4 TCP 2
Data for FO with id: 2
-------------------------
appqoe: flow action DIVERT, svc_idx 0, divert pkt_cnt 158, bypass pkt_cnt 0, drop pkt_cnt 0, inject pkt_cnt 243, error pkt_cnt 0, ingress_intf Tunnel2, egress_intf GigabitEthernet3
==================================================================
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Number of flows that passed filter: 4
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
FLOWS DUMP DONE.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
BR11-CSR1k#
故障排除
以下CLI有助于识别特定TCP流的问题。
所有示例均取自ISR4431上运行的IOS XE SD-WAN 17.2.1映像。
- 查找VRF ID（与VRF名称不同）。 在本例中，我们在下面的输出中看到，服务VPN(VRF)1具有VRF ID 2:
AppQoE_R2#show vrf detail
VRF 1 (VRF Id = 2); default RD 1:1; default VPNID <not set>
New CLI format, supports multiple address-families
Flags: 0x180C
Interfaces:
Gi0/0/3
…
- 找出服务vpn中客户端的相应流ID — 此处我们看到在TCP端口445上使用SMB共享的两个Windows客户端之间有4个不同的流：
AppQoE_R2#show sdwan appqoe flow vpn-id 2 client-ip 192.168.200.50
Optimized Flows
---------------
T:TCP, S:SSL, U:UTD
Flow ID VPN Source IP:Port Destination IP:Port Service
15731593842 2 192.168.200.50:49741 192.168.100.50:445 T
17364128987 2 192.168.200.50:49742 192.168.100.50:445 T
25184244867 2 192.168.200.50:49743 192.168.100.50:445 T
28305760200 2 192.168.200.50:49744 192.168.100.50:445 T
AppQoE_R2#
- 有关相应的流，请参阅TCP选择统计信息：
AppQoE_R2#show sdwan appqoe flow flow-id 15731593842
VPN: 2 APP: 0 [Client 192.168.200.50:49741 - Server 192.168.100.50:445]
TCP stats
---------
Client Bytes Received : 14114
Client Bytes Sent : 23342
Server Bytes Received : 23342
Server Bytes Sent : 14114
TCP Client Rx Pause : 0x0
TCP Server Rx Pause : 0x0
TCP Client Tx Pause : 0x0
TCP Server Tx Pause : 0x0
Client Flow Pause State : 0x0
Server Flow Pause State : 0x0
TCP Flow Bytes Consumed : 0
TCP Client Close Done : 0x0
TCP Server Close Done : 0x0
TCP Client FIN Rcvd : 0x0
TCP Server FIN Rcvd : 0x0
TCP Client RST Rcvd : 0x0
TCP Server RST Rcvd : 0x0
TCP FIN/RST Sent : 0x0
Flow Cleanup State : 0x0
TCP Flow Events
1. time:2196.550604 :: Event:TCPPROXY_EVT_FLOW_CREATED
2. time:2196.550655 :: Event:TCPPROXY_EVT_SYNCACHE_ADDED
3. time:2196.552366 :: Event:TCPPROXY_EVT_ACCEPT_DONE
4. time:2196.552665 :: Event:TCPPROXY_EVT_CONNECT_START
5. time:2196.554325 :: Event:TCPPROXY_EVT_CONNECT_DONE
6. time:2196.554370 :: Event:TCPPROXY_EVT_DATA_ENABLED_SUCCESS
AppQoE_R2#
- 另请参阅通用TCP可选统计信息，其中还显示了4个优化流量：
AppQoE_R2#show tcpproxy statistics
==========================================================
TCP Proxy Statistics
==========================================================
Total Connections : 6
Max Concurrent Connections : 4
Flow Entries Created : 6
Flow Entries Deleted : 2
Current Flow Entries : 4
Current Connections : 4
Connections In Progress : 0
Failed Connections : 0
SYNCACHE Added : 6
SYNCACHE Not Added:NAT entry null : 0
SYNCACHE Not Added:Mrkd for Cleanup : 0
SYN purge enqueued : 0
SYN purge enqueue failed : 0
Other cleanup enqueued : 0
Other cleanup enqueue failed : 0
Stack Cleanup enqueued : 0
Stack Cleanup enqueue failed : 0
Proxy Cleanup enqueued : 2
Proxy Cleanup enqueue failed : 0
Cleanup Req watcher called : 135003
Total Flow Entries pending cleanup : 0
Total Cleanup done : 2
Num stack cb with null ctx : 0
Vpath Cleanup from nmrx-thread : 0
Vpath Cleanup from ev-thread : 2
Failed Conn already accepted conn : 0
SSL Init Failure : 0
Max Queue Length Work : 1
Current Queue Length Work : 0
Max Queue Length ISM : 0
Current Queue Length ISM : 0
Max Queue Length SC : 0
Current Queue Length SC : 0
Total Tx Enq Ign due to Conn Close : 0
Current Rx epoll : 8
Current Tx epoll : 0
Paused by TCP Tx Full : 0
Resumed by TCP Tx below threshold : 0
Paused by TCP Buffer Consumed : 0
Resumed by TCP Buffer Released : 0
SSL Pause Done : 0
SSL Resume Done : 0
SNORT Pause Done : 0
SNORT Resume Done : 0
EV SSL Pause Process : 0
EV SNORT Pause Process : 0
EV SSL/SNORT Resume Process : 0
Socket Pause Done : 0
Socket Resume Done : 0
SSL Pause Called : 0
SSL Resume Called : 0
Async Events Sent : 0
Async Events Processed : 0
Tx Async Events Sent : 369
Tx Async Events Recvd : 369
Tx Async Events Processed : 369
Failed Send : 0
TCP SSL Reset Initiated : 0
TCP SNORT Reset Initiated : 0
TCP FIN Received from clnt/svr : 0
TCP Reset Received from clnt/svr : 2
SSL FIN Received -> SC : 0
SSL Reset Received -> SC : 0
SC FIN Received -> SSL : 0
SC Reset Received -> SSL : 0
SSL FIN Received -> TCP : 0
SSL Reset Received -> TCP : 0
TCP FIN Processed : 0
TCP FIN Ignored FD Already Closed : 0
TCP Reset Processed : 4
SVC Reset Processed : 0
Flow Cleaned with Client Data : 0
Flow Cleaned with Server Data : 0
Buffers dropped in Tx socket close : 0
TCP 4k Allocated Buffers : 369
TCP 16k Allocated Buffers : 0
TCP 32k Allocated Buffers : 0
TCP 128k Allocated Buffers : 0
TCP Freed Buffers : 369
SSL Allocated Buffers : 0
SSL Freed Buffers : 0
TCP Received Buffers : 365
TCP to SSL Enqueued Buffers : 0
SSL to SVC Enqueued Buffers : 0
SVC to SSL Enqueued Buffers : 0
SSL to TCP Enqueued Buffers : 0
TCP Buffers Sent : 365
TCP Failed Buffers Allocations : 0
TCP Failed 16k Buffers Allocations : 0
TCP Failed 32k Buffers Allocations : 0
TCP Failed 128k Buffers Allocations : 0
SSL Failed Buffers Allocations : 0
Rx Sock Bytes Read < 512 : 335
Rx Sock Bytes Read < 1024 : 25
Rx Sock Bytes Read < 2048 : 5
Rx Sock Bytes Read < 4096 : 0
SSL Server Init : 0
Flows Dropped-Snort Gbl Health Yellow : 0
Flows Dropped-Snort Inst Health Yellow : 0
Flows Dropped-WCAPI Channel Health Yellow : 0
Total WCAPI snd flow create svc chain failed : 0
Total WCAPI send data svc chain failed : 0
Total WCAPI send close svc chain failed : 0
Total Tx Enqueue Failed : 0
Total Cleanup Flow Msg Add to wk_q Failed : 0
Total Cleanup Flow Msg Added to wk_q : 0
Total Cleanup Flow Msg Rcvd in wk_q : 0
Total Cleanup Flow Ignored, Already Done : 0
Total Cleanup SSL Msg Add to wk_q Failed : 0
Total UHI mmap : 24012
Total UHI munmap : 389
Total Enable Rx Enqueued : 0
Total Enable Rx Called : 0
Total Enable Rx Process Done : 0
Total Enable Rx Enqueue Failed : 0
Total Enable Rx Process Failed : 0
Total Enable Rx socket on Client Stack Close : 0
Total Enable Rx socket on Server Stack Close : 0
AppQoE_R2#
从17.2开始将TCPOpt与其他AppQoE/UTD功能配合使用
在16.12中，TCPOpt的主要使用案例是分支机构到分支机构。在16.12中有到TCP代理的独立重定向和到UTD容器的独立重定向，这就是为什么TCP选择不能与16.12的安全性配合使用的原因
在17.2中，实施了一个集中式策略路径，该路径将检测对TCP选择和安全性的需求。
关联的数据包将仅重定向到服务平面（投机）一次。
从17.2开始，可以使用不同的流量选项：
- 仅TCP选项
- 仅UTD
- TCP选择 — > UTD
- TCP选择 — > SSL代理 — > UTD
相关信息
修订历史记录
| 版本 | 发布日期 | 备注 |
|---|---|---|
1.0 |
29-Jan-2020 |
初始版本 |
反馈