Cisco IOS®、XE SD-WAN cEdgeルータでのTCP最適化機能の設定
はじめに
このドキュメントでは、2019年8月の16.12リリースで導入されたCisco IOS® XE SD-WANルータのTransmission Control Protocol(TCP)最適化機能について説明します。取り上げるトピックは、前提条件、問題の説明、ソリューション、Viptela OS(vEdge)とXE SD-WAN(cEdge)のTCP最適化アルゴリズムの違い、設定、検証、および関連資料のリストです。
前提条件
要件
このドキュメントに関する固有の要件はありません。
使用するコンポーネント
このドキュメントの情報は、Cisco IOS® XE SD-WANに基づくものです。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
問題
2つのSD-WANサイド間のWANリンクで高い遅延が発生すると、アプリケーションのパフォーマンスが低下します。重要なTCPトラフィックがあるため、最適化する必要があります。
解決方法
TCP最適化機能を使用すると、2つのSD-WANサイト間の重要なTCPフローの平均TCPスループットが向上します。
cEdge Bottleneck BandwidthとRound-trip(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 OPTIMIZATIONの利点となる例の1つは、大幅な遅延やドロップが発生している古いクライアントホストとWANリンクを使用する潜水艦です。vEdge 1000およびvEdge 2000のみがTCP CUBICをサポートすることに注意してください。
BBRは主にラウンドトリップ時間と遅延に重点を置いています。パケット損失は発生しません。米国西部から東海岸、さらにはヨーロッパまで、パブリックインターネットを介してパケットを送信する場合、ほとんどの場合、パケット損失は発生しません。パブリックインターネットは、パケット損失の点で優れすぎることがあります。しかし、遅延や遅延が発生します。そして、この問題は2016年にGoogleによって開発されたBBRによって対処されています。
BBRはネットワークをモデル化し、各確認応答(ACK)を確認して、最大帯域幅(BW)と最小ラウンドトリップ時間(RTT)を更新します。 次に、制御送信はモデルに基づいて行われます。最大BWと最小RTTのプローブ、概算BWに近いペーシング、およびBandwidth-Delay-Product(BDP)に近い状態の維持です。 主な目標は、ボトルネックキューを小さくして高いスループットを確保することです。
Mark Claypoolのこのスライドは、CUBICが活動しているエリアを示しています。
BBRはより良い場所で動作します。このスライドではMark Claypoolからも見ることができます。
BBR アルゴリズムの詳細を確認するには、bbr-devメーリングリストのホームページここの上部にリンクされているBBRに関する複数のドキュメントを参照してください。
ここまでの内容をまとめます。
| プラットフォームとアルゴリズム |
キー入力パラメータ | 使用例 |
| cEdge(XE SD-WAN):BBR | RTT/遅延 | 2つのSD-WANサイト間の重要なTCPトラフィック |
| vEdge(Viptela OS):CUBICP | パケット損失 | TCP最適化のない古いクライアント |
サポートされるXE SD-WANプラットフォーム
XE SD-WAN SWリリース16.12.1dでは、次のcEdgeプラットフォームがTCP最適化BBRをサポートします。
- ISR4331
- ISR4351
- CSR1000v（8 vCPUおよび最小8 GB RAM搭載）
警告
- 現在、DRAMが8 GB未満のプラットフォームはすべてサポートされていません。
- 4コア以下のデータコアを搭載したプラットフォームは、現在サポートされていません。
- TCP最適化はMTU 2000をサポートしていません。
- 現在、IPv6トラフィックはサポートされていません。
- サードパーティのBBRサーバへのDIAトラフィックの最適化はサポートされていません。両側にcEdge SD-WANルータが必要です。
- 現在のデータセンターのシナリオでは、1つのコントロールノード(CN)につき1つのサービスノード(SN)のみがサポートされます。
- セキュリティ（UTDコンテナ）とTCP最適化を同じデバイスで組み合わせた使用例は、16.12リリースではサポートされていません。17.2以降では、組み合わせたユースケースがサポートされています。操作の順序は、最初にTCP Opt、次にSecurityです。パケットはTCP最適化コンテナにパントされ、次にUTDセキュリティコンテナにサービスチェーン（2回目のパントなし）されます。TCP最適化は、最初の数バイトではなく、フロー全体に対して行われます。UTDがドロップすると、接続全体がドロップされます。
次の表に、リリースごとの注意事項をまとめ、サポートされているハードウェアプラットフォームを示します。
| シナリオ |
使用例 |
16.12.1 |
17.2.1 |
17.3.1 |
17.4.1 |
注釈 |
| ブランチからインターネット |
直径 |
いいえ |
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 |
複数のSN IPを受け入れるvManageの機能拡張 |
|
| ブランチ間 |
フルメッシュネットワーク （スポーク間） |
Yes |
Yes |
Yes |
Yes |
|
| ハブアンドスポーク （スポーク – ハブ – スポーク） |
いいえ |
Yes |
Yes |
Yes |
||
| BBRのサポート |
BBRを使用したTCP最適化 |
部分的 | 部分的 |
Full |
Full |
|
| プラットフォーム |
サポート対象プラットフォーム |
4300とCSRのみ |
ISR1100以外 |
すべて |
すべて |
設定
SNとCNの概念がTCP最適化に使用されます。
- SNはデーモンであり、TCPフローの実際の最適化を行います。
- CNはAppNav Controllerと呼ばれ、トラフィックの選択とSNとの間の転送を行います。
SNとCNは、同じルータ上で実行することも、異なるノードとして分離することもできます。
主な使用例は次の2つです。
- 同じISR4kルータ上で実行されているSNおよびCNを持つブランチユースケース。
- データセンターのユースケース。CNはASR1kで実行され、SNは別のCSR1000v仮想ルータで実行されます。
このセクションでは、両方の使用例について説明します。
使用例1:ブランチでのTCP最適化の設定（オールインワンのcEdge）
次の図は、ブランチの単一スタンドアロンオプションの全体的な内部アーキテクチャを示しています。
手順 1：TCP最適化を設定するには、vManageでTCP最適化用の機能テンプレートを作成する必要があります。図に示すように、Configuration > Templates > Feature Templates > Other Templates > 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の物理的な分離です。オールインワンのブランチの使用例では、接続は仮想ポートグループインターフェイスを使用して同じルータ内で行われます。データセンターの使用例では、CNとして動作するASR1kとSNとして動作する外部CSR1kの間にAppNav GREカプセル化トンネルがあります。CNと外部SNの間に専用リンクやクロスコネクトは必要なく、シンプルなIP到達可能性で十分です。
SNごとに1つのAppNav(GRE)トンネルがあります。複数のSNがサポートされている場合に今後使用するために、CNとSN間のネットワークには/28サブネットを使用することをお勧めします。
SNとして機能するCSR1kには2つのNICが推奨されます。SNをvManageで設定/管理する必要がある場合は、SD-WANコントローラ用の2つ目のNICが必要です。SNを手動で設定/管理する場合、2番目のNICはオプションです。
次の図は、CNとして動作するデータセンターASR1kと、サービスノードSNとして動作するCSR1kvを示しています。
ASR1kおよび外部CSR1kを使用するデータセンターの使用例のトポロジを次に示します。
次のAppQoE機能テンプレートは、コントローラとして設定されたASR1kを示しています。
外部サービスノードとして設定されたCSR1kを次に示します。
フェールオーバーケース
外部CSR1kに障害が発生した場合の、CSR1kがSNとして機能するデータセンターの使用例でのフェールオーバー：
- SN上のTCPセッションが終了するため、既存のTCPセッションは失われます。
- 新しいTCPセッションは最終的な宛先に送信されますが、TCPトラフィックは最適化されません（バイパス）。
- SN障害の場合、対象トラフィックに対するブラックホールは発生しません。
フェールオーバー検出はAppNavハートビートに基づいており、毎秒1ビートです。エラーが3回または4回発生すると、トンネルはダウンしていると宣言されます。
ブランチの使用例のフェールオーバーも同様です。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
…
- クライアントの適切なフローIDをサービスVPNで確認します。ここでは、TCPポート445を介したSMB共有を使用する2つの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 Opt statsを参照してください。
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以降の他のAppQoE/UTD機能でのTCPOptの使用
16.12では、TCPOptの主な使用例はBranch-to-Branchです。16.12には、TCPプロキシへの個別のリダイレクションとUTDコンテナへの個別のリダイレクションがあります。そのため、16.12ではTCP Optはセキュリティと連携しません
17.2では、中央集中型のポリシーパスが実装されており、TCPの選択とセキュリティの必要性が検出されます。
関連付けられたパケットは、サービスプレーン（パント）に1回だけリダイレクトされます。
17.2以降では、さまざまなフローオプションを使用できます。
- TCPオプションのみ
- UTDのみ
- TCP選択 – > UTD
- TCP選択 – > SSLプロキシ – > UTD
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
29-Jan-2020
|
初版 |
フィードバック