CPUスケジューリング(パケット振り分け)機能

$Date: 2022/09/05 07:58:16 $

概要
注意事項
対応機種とファームウェアリビジョン
詳細
コマンド
関連文書

1. 概要

vRX シリーズはマルチコアCPUに対応しています。CPUスケジューリング(パケット振り分け)機能は、ルーターがパケットを受信したときに、受信パケットの転送処理をどのCPUコアで実行するかを決定するための機能です。本機能により、以下のような受信パケットの転送処理を実行するCPUコアの割り当てを行うことができます。

各CPUコアの負荷が均等になるように決定されたCPUコアで受信パケットの転送処理を実行する。
受信パケットのヘッダ情報から決定されたCPUコアで受信パケットの転送処理を実行する。

CPUスケジューリング方式は、受信パケットの転送処理をどのCPUコアで実行するかを決定するための機能で、方式ごとに定められた観点から、パケットの転送処理をどのCPUコアで実行するかが決定されます。CPUスケジューリング方式には、以下の方式があります。

ハッシュ方式
ロードバランス方式
LANインターフェース方式
固定方式

ノーマルパスの処理対象となるパケットは、本機能によって決定されたCPUコアでは受信処理のみが実行され、転送処理は常にCPU0で実行されます。

以下に vRX Amazon EC2版で、c5.xlargeインスタンス(CPUコア数が4つ)を使用した場合の、本機能によるパケット転送処理の流れの例を示します。

図1は表1のパケットを受信した場合のパケット転送処理の流れです。

図1. パケット転送処理の流れ

表1. 受信パケット一覧

受信パケットはCPUスケジューリング方式に従って決定されたCPUコアで転送処理が実行されます。ノーマルパス対象パケットは本機能により決定されたCPUコアでは受信処理のみが実行され、転送処理は常にCPU0で実行されます。

2. 注意事項

ロードバランス方式では受信パケットの振り分けをソフトウェアで行うため、NIC側で受信パケットの振り分けを行う他の方式の方が、スケーラビリティに優れています。他の方式を優先的に使用することを推奨します。
ノーマルパスの処理対象となるパケットは、本機能によって決定されたCPUコアでは受信処理のみが実行され、転送処理は常にCPU0で実行されます。
CPUスケジューリング方式を変更すると、すべてのLANインターフェースの初期化処理が実行されるため、すべてのLANインターフェースにおいて一時的にリンクダウンが発生します。
ロードバランス方式では、パケットの順番が入れ替わる可能性があります。パケットの順番が入れ替わるとUDPを用いるアプリケーションで問題が発生する可能性があります。なお、TCPではパケットの順番が入れ替わっても通常は問題は発生しません。
IPsecではどのCPUスケジューリング方式であっても、ESPシーケンス番号の順序通りにESPパケットが送信されないことがあるため、対向側ルーターの受信処理でESPシーケンスエラーが発生し、ESPパケットが破棄される可能性があります。ESPシーケンスエラーは、対向側ルーターの ipsec sa policy コマンドで anti-replay-check を off にして、ESPシーケンス番号のチェックを行わないようにすることで回避できます。なお、ロードバランス方式では、対向側ルーターがESPシーケンス番号の順序通りにESPパケットを送信している場合でも、受信時にESPパケットの順番が入れ替わる可能性があります。ロードバランス方式を使用する場合は、両側のルーターの ipsec sa policy コマンドで anti-replay-check を off にする必要があります。

3. 対応機種とファームウェアリビジョン

vRX シリーズでは、以下のファームウェアで、CPUスケジューリング(パケット振り分け)機能をサポートしています。

機種	ファームウェア
vRX VMware ESXi版	すべてのリビジョン
vRX Amazon EC2版	すべてのリビジョン

4. 詳細

4.1. CPUスケジューリング方式によるCPUコア割り当て

ルーターは system packet-scheduling コマンドで設定したCPUスケジューリング方式ごとに定められた観点から受信パケットの転送処理をどのCPUコアで実行するかを決定します。CPUスケジューリング方式は以下の中から選択することができます。

ハッシュ方式
ロードバランス方式
LANインターフェース方式
固定方式

ロードバランス方式では受信パケットの振り分けをソフトウェアで行うため、NIC側で受信パケットの振り分けを行う他の方式の方が、スケーラビリティに優れています。他の方式を優先的に使用することを推奨します。

4.1.1. ハッシュ方式

ハッシュ方式では、受信パケットのヘッダ情報から算出されたハッシュ値を基にしてパケットの転送処理をどのCPUコアで実行するかが決定されます。同じフローのパケットであれば、常に同じCPUコアで転送処理が行われます。

IPsecではESPシーケンス番号の順序通りにESPパケットが送信されないことがあるため、対向側ルーターの受信処理でESPシーケンスエラーが発生し、ESPパケットが破棄される可能性があります。ESPシーケンスエラーは、対向側ルーターの ipsec sa policy コマンドで anti-replay-check を off にして、ESPシーケンス番号のチェックを行わないようにすることで回避できます。

ハッシュ値の算出に使用されるヘッダ情報は以下のとおりです。

ヘッダー情報		vRX Amazon EC2版	vRX VMware ESXi版
プロトコル	パラメーター	vRX Amazon EC2版	vRX VMware ESXi版
IPv4/IPv6	送信元アドレス	○	○
IPv4/IPv6	送信先アドレス	○	○
IPv4/IPv6	プロトコル番号	○	×
TCP over IPv4/IPv6	送信元ポート番号	○	○
TCP over IPv4/IPv6	送信先ポート番号	○	○
UDP over IPv4/IPv6	送信元ポート番号	○	○ ※1
UDP over IPv4/IPv6	送信先ポート番号	○	○ ※1
ESP over IPv4	SPI	×	○ ※1

※1 : 仮想マシンバージョン 15 以降かつ VMware ESXi 6.7 Update 3以降: vRX VMware ESXi版のデプロイ時の仮想マシンバージョンは11です。仮想マシンバージョン 15以降で使用するためには、互換性のアップグレードが必要です。互換性のアップグレードの方法については「ヤマハ仮想ルーターvRX for VMware ESXi版ユーザーガイド」を参照してください。

IPv4/IPv6ヘッダを持たない受信パケットの転送処理はCPU0で実行されます。

以下に vRX Amazon EC2版で、c5.xlargeインスタンス(CPUコア数が4つ)を使用した場合の、ハッシュ方式によるCPUコア割り当ての例を示します。

図2は表2のパケットを受信した場合のCPUコア割り当ての流れです。

パケット①、②はUDPのパケット、パケット③、④はTCPのパケットです。パケット⑤はパケット①と同じヘッダ情報を持つパケットです。

図2. ハッシュ方式によるパケット転送処理の流れ

表2. 受信パケット一覧

パケット①～⑤の転送処理は、パケットのヘッダ情報から算出されたハッシュ値を基にして決定されたCPUコアで実行されます。パケット①とパケット⑤はヘッダ情報が同じであるため、転送処理を実行するCPUコアも同じになります。

4.1.2 ロードバランス方式

ロードバランス方式では、各CPUコアの負荷が均等になるようにパケットの転送処理をどのCPUコアで実行するかが決定されます。転送処理を実行するCPUコアがパケット単位で変化するため、同じフローのパケットであっても、毎回同じCPUコアになるとは限りません。

受信パケットのヘッダ情報を意識しなくとも、パケットの転送処理をすべてのCPUコアで実行することができるようになるため、ハッシュ方式ではCPU負荷に偏りが生じてしまう場合などに、全体のCPU負荷を分散させることができます。

同じフローのパケットの転送処理をすべてのCPUコアで実行するため、パケットの順番が入れ替わる可能性があります。パケットの順番が入れ替わるとUDPを用いるアプリケーションで問題が発生する可能性があります。なお、TCPではパケットの順番が入れ替わっても通常は問題は発生しません。

IPsecではESPシーケンス番号の順序通りにESPパケットが送受信されないことがあるため、両側のルーターでESPシーケンスエラーが発生し、ESPパケットが破棄される可能性があります。ESPシーケンスエラーは、両側のルーターの ipsec sa policy コマンドで anti-replay-check を off にして、ESPシーケンス番号のチェックを行わないようにすることで回避できます。

ロードバランス方式を指定した場合には、トラフィックが存在しない状況でも新たなパケットの到着確認にコア1以降を使用します。パケットの到着を確認できなかった場合に使用したCPU時間は、show environment コマンド、および、show environment detail コマンドで表示されるCPU使用率に計上されませんのでご注意ください。

以下に vRX Amazon EC2版で、c5.xlargeインスタンス(CPUコア数が4つ)を使用した場合の、ロードバランス方式によるCPUコア割り当ての例を示します。

図3は表3のパケットを受信した場合のCPUコア割り当ての流れです。

パケット①、②はUDPのパケット、パケット③、④はTCPのパケットです。パケット⑤はパケット①と同じヘッダ情報を持つパケットです。

図3. ロードバランス方式によるパケット転送処理の流れ

表3. 受信パケット一覧

パケット①～⑤の転送処理は、各CPUコアの負荷が均等になるように決定されたCPUコアで実行されます。ここではパケット①の転送処理はCPU1で実行されていますが、パケット①と同じヘッダ情報を持つパケット⑤の転送処理はCPU2で実行されています。

4.1.3. LANインターフェース方式

LANインターフェース方式では、パケットを受信したLANインターフェースによってパケットの転送処理をどのCPUコアで実行するかが決定されます。

受信パケットのヘッダ情報を意識しなくとも、パケットの転送処理を意図したCPUコアで実行することができますが、ネットワーク構成によってはCPU負荷に偏りが生じる可能性があります。

受信LANインターフェースごとの転送処理を実行するCPUコアは以下のようになっています。

受信LANインターフェース	CPUコア
LAN1	CPU1
LAN2	CPU2
LAN3	CPU3
LAN4	CPU1

ただし、CPUコア数が2、LANインターフェース数が3のときには、以下のようになります。

受信LANインターフェース	CPUコア
LAN1	CPU1
LAN2	CPU1
LAN3	CPU1

以下に vRX Amazon EC2版で、c5.xlargeインスタンス(CPUコア数が4つ)を使用し、LANインターフェース数が4つの場合の、LANインターフェース方式によるCPUコア割り当ての例を示します。

図4は表4のパケットを受信した場合のCPUコア割り当ての流れです。

パケット①、⑤はLAN2、パケット②はLAN3、パケット③はLAN4、パケット④はLAN1で受信したパケットです。

図4. LANインターフェース方式によるパケット転送処理の流れ

表4. 受信パケット一覧

パケット①～⑤の転送処理は、それぞれのパケットを受信したLANインターフェースに対応したCPUコアで実行されます。

4.1.4. 固定方式

固定方式では、すべてのパケットの転送処理がCPU1で実行されます。

以下に vRX Amazon EC2版で、c5.xlargeインスタンス(CPUコア数が4つ)を使用した場合の、固定方式によるCPUコア割り当ての例を示します。

図5は表5のパケットを受信した場合のCPUコア割り当ての流れです。

図5. 固定方式によるパケット転送処理の流れ

表5. 受信パケット一覧

パケット①～③の転送処理は、すべてCPU1で実行されます。

5. コマンド

CPU スケジューリング方式の設定

[書式]

system packet-scheduling MODE

no system packet-scheduling [MODE]

[設定値及び初期値]

MODE

[設定値]:CPUスケジューリング方式

設定値	説明
hash	ハッシュ方式
load-balance	ロードバランス方式
lan-based	LANインターフェース方式
fixed	固定方式

[初期値]:hash

[説明]

CPUスケジューリング方式を設定する。

hashを選択した場合、受信パケットから算出されたハッシュ値を基にしてパケットの転送処理を実行するCPUコアが決まる。

load-balance を選択した場合、各CPUコアの負荷が均等になるようにパケットの転送処理を実行するCPUコアがパケット単位で変化する。

lan-based を選択した場合、パケットを受信したLANインターフェースによって転送処理を実行するCPUコアが次のように決まる。

CPUコア数が4、LANインターフェース数が4のとき：

受信LANインターフェース	CPUコア
LAN1	CPU1
LAN2	CPU2
LAN3	CPU3
LAN4	CPU1

CPUコア数が2、LANインターフェース数が3のとき：

受信LANインターフェース	CPUコア
LAN1	CPU1
LAN2	CPU1
LAN3	CPU1

fixed を選択した場合、パケットを受信したLANインターフェースによらず、転送処理を常にCPU1で実行する。

[ノート]

本コマンドを実行すると、すべてのLANインターフェースの初期化処理が実行されるため、すべてのLANインターフェースにおいて一時的にリンクダウンが発生する。

ノーマルパスの処理対象となるパケットは、本コマンドの設定に従って決定されたCPUコアでは受信処理のみが実行され、転送処理は常にCPU0で実行される。これは、ip routing process コマンドで normal が設定されている場合はすべてのパケットが対象となる。

CPUスケジューリング方式に hash を選択した場合、IPv4/IPv6ヘッダを持たない受信パケットの転送処理はCPU1で実行される。

CPUスケジューリング方式に load-balance を選択した場合、パケットの順番が入れ替わる可能性がある。パケットの順番が入れ替わるとUDPを用いるアプリケーションで問題が発生する可能性がある。なお、TCPではパケットの順番が入れ替わっても通常は問題は発生しない。

IPsecではどのCPUスケジューリング方式であっても、ESPシーケンス番号の順序通りにESPパケットが送信されないことがあるため、対向側ルーターの受信処理でESPシーケンスエラーが発生し、ESPパケットが破棄される可能性がある。ESPシーケンスエラーは、対向側ルーターの ipsec sa policy コマンドで anti-replay-check を off にして、ESPシーケンス番号のチェックを行わないようにすることで回避できる。なお、ロードバランス方式では、対向側ルーターがESPシーケンス番号の順序通りにESPパケットを送信している場合でも、受信時にESPパケットの順番が入れ替わる可能性があるため、ロードバランス方式を使用する場合は、両側のルーターの ipsec sa policy コマンドで anti-replay-check を off にする必要がある。

CPUスケジューリング(パケット振り分け)機能の状態の表示

[書式]

show status packet-scheduling

[説明]

現在のCPUスケジューリング(パケット振り分け)機能の状態を表示する。

CPUスケジューリング方式

動作中のCPUスケジューリング方式

設定値	説明
hash	ハッシュ方式
load-balance	ロードバランス方式
lan-based	LANインターフェース方式
fixed	固定方式

CPU使用率
- CPUコアごとのCPUコア全体の使用率
フロー(IPv4/IPv6)
- 全体のIPv4/IPv6フロー数
- CPUコアごとのIPv4/IPv6フロー数
受信パケット
- CPUコアごとの受信パケット数

CPUスケジューリング方式がロードバランス方式である場合、CPUコアごとのIPv4/IPv6フロー数は表示されない。

受信パケット数は、system packet-scheduling コマンドを実行するとクリアされる。

[表示例]

# show status packet-scheduling
CPUスケジューリング方式:        hash
CPU使用率:
               CPU0:             57%(5sec)  56%(1min)  56%(5min)
               CPU1:             62%(5sec)  62%(1min)  62%(5min)
               CPU2:             88%(5sec)  89%(1min)  88%(5min)
               CPU3:             54%(5sec)  54%(1min)  54%(5min)
フロー(IPv4/IPv6):              2 エントリ / 2 エントリ
               CPU0:            0 エントリ / 1 エントリ
               CPU1:            1 エントリ / 0 エントリ
               CPU2:            1 エントリ / 0 エントリ
               CPU3:            0 エントリ / 1 エントリ
受信パケット:
               CPU0:            23155524 パケット
               CPU1:            14018842 パケット
               CPU2:            23624407 パケット
               CPU3:            22886347 パケット

6. 関連文書

ファストパスの実装