はじめに
このドキュメントでは、BFD HelloパケットとApp-Aware Routing Tunnel(AOT)統計情報の間に存在する関係について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Cisco Catalystソフトウェア定義型ワイドエリアネットワーク(SD-WAN)。
- アプリケーション認識型ルーティング
- BFDを使用します。
使用するコンポーネント
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
- Cisco Catalyst SD-WAN Managerを使用します。
- Cisco IOS® XE Catalyst SD-WANエッジ
背景説明
双方向フォワーディング検出(BFD)プロトコルは、Cisco IOS-XE Catalyst SD-WANデバイス間のすべてのデータプレーントンネルで実行されます。このプロトコルは、損失、ジッタ、遅延として報告されるトンネルのパフォーマンスなど、トンネルの活性とパス特性を監視するために使用されます。
エッジデバイスは、BFD Helloプローブを使用して、トンネル上のパケット損失、ジッター、および遅延の測定を行います。これらの統計情報は、BFD Helloプローブごとに計算され、ポーリング間隔と呼ばれるスライディングウィンドウに取り込まれます。
これらの損失、遅延、およびジッタの統計情報は、SLAクラスと呼ばれるポリシーで設定された要件に基づいてトラフィックを配信するためにApp-Aware Routingによって使用され、データを配信するために選択されたトンネルで許可される最大損失、ジッタ、および遅延を決定します。
このため、メジャーの計算方法と、BFD値の変更がトンネルのパフォーマンス計算に与える影響(主に損失)を理解しておくことが非常に重要です。BFDパラメータは次のとおりです。
パラメータ |
デフォルト値 |
範囲 |
利用 |
BFD hello間隔
|
1 秒 |
1 ~ 65535秒 |
トンネル接続の活性を検出し、トンネルの障害を検出するパケット。 |
ポーリング間隔 |
10 分 (600,000ミリ秒) |
1 ~ 4,294,967ミリ秒 |
統計を提供するためにバケットメジャーが計算される頻度。 |
割増率 |
6 |
1 ~ 6 |
ポーリング間隔を乗算して、平均損失、平均遅延、および平均ジッターを計算する時間を指定する値。 この値によってバケットの数が決まります。 |
トンネルパフォーマンス統計情報の計算
デフォルトとして設定されているBFDパラメータの場合、統計情報の計算は次のように行われます。
ポーリング間隔/ BFD Hello間隔= 600,000ミリ秒/ 1000ミリ秒= 600 BFD Hello/バケット
乗数が6に設定されているため、平均遅延、ジッタ、および損失の計算には6バケットが使用されることを意味します。デフォルト値では、1時間になります。この合計時間は、app-routeインターバルとも呼ばれます。
アプリルート間隔=ポーリング間隔*乗数= 600,000 ms x 6 = 3,600,000 msは1時間と等しくなります。
App-route統計情報の計算は、App-Aware Routingがデータプレーンの変更を判断するために使用されます。エッジデバイスがアプリルート統計情報を利用できるようにするには、最大許容パケットジッタ、損失、および遅延が設定されているAARポリシーでSLAクラスを指定する必要があります。これらのSLAクラスは、AARポリシーで使用され、SLAに従って指定されたアプリケーションのトラフィックをルーティングします。
エッジデバイスで設定されたAAR統計情報は、すべてのバケットで(アプリケーションのルート間隔全体で)計算された統計情報によって提供される平均損失、平均遅延、および平均ジッターと比較するために使用されます。また、SLAはポーリング間隔ごとに更新され、デフォルトでは10分ごとに更新されることにも注意してください。
平均損失、平均ジッター、および平均遅延を取得するために、使用される式は次のとおりです。
平均損失=(すべてのバケットの合計損失* 100)/パケット合計。
平均遅延=(すべてのバケットの合計損失)/バケットの量。
平均ジッタ=(すべてのバケットの合計ジッタ)/バケットの量。
これらの値の計算は、各バケットの平均とともに、CLIで次のように確認できます。
vEdge#show app-route stats
cEdge#show sdwan app-route stats
GUIでは、平均損失、平均遅延、および平均ジッターのみをMonitor > Overview > Application-Aware Routingセクションで確認できます。
これは、Monitor > Devices > Select Device > WAN > Tunnelセクションでも確認できます。
損失を伴うBFD値の関係の例
BFD Helloは設定可能な値であるため、要件に基づいて変更できます。ただし、慎重に検討した上で変更することが重要です。そうしないと、平均損失計算の精度がBFD値に依存するため、偏った計算やfalse positiveの統計情報が受信される可能性があります。たとえば、次のデフォルト値を使用します。
パラメータ |
デフォルト |
BFD helloパケット |
1 秒 |
ポーリング間隔 |
(600,000ミリ秒) 10 分 |
割増率 |
6 |
vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346
remote-system-ip 10.1.1.1
local-color private1
remote-color private1
mean-loss 1
mean-latency 110
mean-jitter 51
sla-class-index 0,2
IPV6 TX IPV6 RX
TOTAL AVERAGE AVERAGE TX DATA RX DATA DATA DATA
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS PKTS PKTS
----------------------------------------------------------------------------
0 596 7 110 50 0 0 0 0
1 596 5 111 50 0 1 0 0
2 597 13 111 53 0 0 0 0
3 594 4 111 53 0 0 0 0
4 596 5 110 50 0 0 0 0
5 594 12 111 50 0 2 0 0
平均損失= ((7+5+13+4+5+12)100)/ (596+596+597+594+596+594)
= 4600/3573
= 1.28 ~ 1%
平均遅延時間= (110+111+111+111+110+111)/6
= 110.66 ~ 110ミリ秒
平均ジッター= (50+50+53+53+50+50) / 6
= 3 /6 = 51ミリ秒
注:計算が完了するたびに、整数値のみが表示されます。10進数が正確な結果である場合でも、整数値は最も低い整数に丸められます。
通常は、これらの値を変更して計算の頻度を上げるのに適していますが、これによって重大な影響が出る可能性があります。たとえば、デフォルト値の代わりにポーリング間隔が次のように変更される場合などです。
パラメータ |
デフォルト |
BFD helloパケット |
1 秒 |
ポーリング間隔 |
(60,000ミリ秒) 1分 |
割増率 |
6 |
この変更は、デフォルトで600パケットではなく、バケットごとに1 x 60 = 60パケットを使用することを意味します。平均損失の結果は次のようになります。
vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346
remote-system-ip 10.1.1.1
local-color private1
remote-color private1
mean-loss 3
mean-latency 112
mean-jitter 51
sla-class-index 0,2
IPV6 TX IPV6 RX
TOTAL AVERAGE AVERAGE TX DATA RX DATA DATA DATA
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS PKTS PKTS
----------------------------------------------------------------------------
0 59 1 113 53 0 0 0 0
1 60 3 111 52 0 1 0 0
2 59 1 111 51 0 1 0 0
3 60 3 111 50 0 1 0 0
4 60 2 115 50 0 0 0 0
5 59 1 111 50 0 2 0 0
平均損失= ((1+3+1+3+2+1)*100)/(59+60+59+60+60+59)
= (1100)/ 357
= 3.08 ~ 3%
この時点で、たとえばSLAクラスが最大損失3に設定されている場合、トンネルはSLA違反の制限下にあります。ただし、ポーリング間隔を次のように変更した場合、
パラメータ |
デフォルト |
BFD helloパケット |
1 秒 |
ポーリング間隔 |
(6,000ミリ秒) 1 秒 |
割増率 |
6 |
この変更は、デフォルトで600パケットではなく、バケットごとに1 x 6 = 6パケットを使用することを意味します。平均損失の結果は次のようになります。
vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346
remote-system-ip 10.1.1.1
local-color private1
remote-color private1
mean-loss 17
mean-latency 110
mean-jitter 0
sla-class-index None
IPV6 TX IPV6 RX
TOTAL AVERAGE AVERAGE TX DATA RX DATA DATA DATA
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS PKTS PKTS
----------------------------------------------------------------------------
0 5 1 113 2 0 0 0 0
1 6 1 110 1 0 1 0 0
2 6 1 111 2 0 0 0 0
3 6 0 111 0 0 0 0 0
4 6 1 111 0 0 0 0 0
5 6 1 111 0 0 2 0 0
平均損失= ((5)100)/(5+6+6+6+6+6)
= (500)/29
= 17.24 ~ 17%
測定に使用するパケットの数を正しく検証せずにポーリング間隔を短くすると、平均損失に影響する場合があります。プール間隔を長くせずにbfd hello-intervalを増やした場合も、同様です。
最後の例では、計算に使用されるパケットはごくわずかであり、損失したパケットは1つだけなので、平均損失に大きな影響を与える可能性があります。 これらの計算の結果、複数のフェールオーバーが非常に頻繁に発生する、アプリケーション認識型のポリシー動作が発生します。
この説明の目的は、これらの値の変更を避けることではなく、多くの状況で、これらのプローブを変更する必要があります。これはネットワーク要件によって完全に異なりますが、これらのhelloパケットをどれだけ減らすことができるかを確認することが非常に重要です。
ポーリング間隔をグローバルに変更する設定コマンドは次のとおりです。
vEdge(config)# bfd app-route poll-interval 600000