$Date: 2014/06/10 10:57:08 $
RTX3500/RTX5000はマルチコアCPUを搭載しています。CPUスケジューリング(パケット転送)機能は、ルーターがパケットを受信したときに、 受信パケットの転送処理をどのCPUコアで実行するかを決定するための機能です。本機能により、以下のような受信パケットの転送処理を実行するCPUコアの割り当てを行うことができます。
本機能は、CPUスケジューリング方式によるCPUコア割り当てとCPUスケジューリングフィルターによるCPUコア割り当てに分類されます。 CPUスケジューリング方式は、受信パケットの転送処理をどのCPUコアで実行するかを決定するための機能で、 方式ごとに定められた観点から、パケットの転送処理をどのCPUコアで実行するかが決定されます。CPUスケジューリング方式には、以下の方式があります。
CPUスケジューリングフィルターは、受信パケットの転送処理を任意のCPUコアで実行できるようにするための機能で、パケットごとに転送処理を実行するCPUコアを固定することができます。 フィルターに合致した受信パケットはフィルターに従って決定されたCPUコアで転送処理が実行され、すべてのフィルターに合致しなかったパケットは CPUスケジューリング方式に従って決定されたCPUコアで転送処理が実行されます。
ノーマルパスの処理対象となるパケットは、本機能によって決定されたCPUコアでは受信処理のみが実行され、転送処理は常にCPU1で実行されます。
以下に本機能によるパケット転送処理の流れの例を示します。図1は表1のパケットを受信した場合のパケット転送処理の流れです。 パケット①はCPUスケジューリングフィルターに合致するファストパスのパケット、②はCPUスケジューリングフィルターに合致しないファストパスのパケット、 パケット③はCPUスケジューリングフィルターに合致するノーマルパスのパケット、④はCPUスケジューリングフィルターに合致しないノーマルパスのパケットです。
CPUスケジューリングフィルターに合致した受信パケットはフィルターに従って決定されたCPUコアで転送処理が実行され、 合致しなかった受信パケットはCPUスケジューリング方式に従って決定されたCPUコアで転送処理が実行されます。 ノーマルパス対象パケットは本機能により決定されたCPUコアでは受信処理のみが実行され、転送処理は常にCPU1で実行されます。
RTX3500/RTX5000では、以下のファームウェアで、CPUスケジューリング(パケット転送)機能をサポートしています。
| 機種 | ファームウェア |
|---|---|
| RTX3500 | Rev.14.00.13以降 |
| RTX5000 | Rev.14.00.13以降 |
本機能がサポートされていないファームウェアでは、ハッシュ方式で受信パケットの転送処理をどのCPUコアで実行するかが決定され、他の方式に変更することはできません。 また、同じヘッダ情報を持つ受信パケットであっても、本機能がサポートされているファームウェアとそうでないファームウェアではパケットの転送処理を実行するCPUコアが異なる可能性があります。
CPUスケジューリング方式は、ルーターが受信パケットの転送処理をどのCPUコアで実行するかを決定するための機能で、以下の中から選択することができます。
ルーターがパケットを受信すると、方式ごとに定められた観点から、受信パケットの転送処理をどのCPUコアで実行するかが決定されます。
ハッシュ方式では、受信パケットのヘッダ情報から算出されたハッシュ値を基にしてパケットの転送処理をどのCPUコアで実行するかが決定されます。 同じフローのパケットであれば、常に同じCPUコアで転送処理が行われます。ハッシュ値は以下のヘッダ情報より算出されます。
本機能がサポートされていないファームウェアでは、IPv4/IPv6送信元アドレスのみによってハッシュ値が算出されます。 そのため、同じヘッダ情報を持つ受信パケットであっても、本機能がサポートされているファームウェアとそうでないファームウェアではパケットの転送処理を実行するCPUコアが異なる可能性があります。
IPv4/IPv6ヘッダを持たない受信パケットの転送処理はCPU0で実行されます。
IPsecでは、ESPシーケンス番号の順序通りにESPパケットが送信されないことがあるため、対向側ルーターの受信処理でESPシーケンスエラーが発生し、ESPパケットが破棄される可能性があります。 ESPシーケンスエラーは、対向側ルーターの ipsec sa policy コマンドで anti-replay-check を off にして、ESPシーケンス番号のチェックを行わないようにすることで回避できます。
以下にハッシュ方式によるCPUコア割り当ての例を示します。図2は表2のパケットを受信した場合のCPUコア割り当ての流れです。 パケット①、②はUDPのパケット、パケット③、④はTCPのパケットです。 パケット⑤はパケット①と同じヘッダ情報を持つパケットです。 なお、ここではCPUスケジューリングフィルターは適用していません。
パケット①〜⑤の転送処理は、パケットのヘッダ情報から算出されたハッシュ値を基にして決定されたCPUコアで実行されます。 パケット①とパケット⑤はヘッダ情報が同じであるため、転送処理を実行するCPUコアも同じになります。
ロードバランス方式では、各CPUコアの負荷が均等になるようにパケットの転送処理をどのCPUコアで実行するかが決定されます。 転送処理を実行するCPUコアがパケット単位で変化するため、同じフローのパケットであっても、毎回同じCPUコアになるとは限りません。
受信パケットのヘッダ情報を意識しなくとも、パケットの転送処理をすべてのCPUコアで実行することができるようになるため、ハッシュ方式ではCPU負荷に偏りが生じてしまう場合などに、 全体のCPU負荷を分散させることができます。 同じフローのパケットの転送処理をすべてのCPUコアで実行するため、パケットの順番が入れ替わる可能性があります。 パケットの順番が入れ替わるとUDPを用いるアプリケーションで問題が発生する可能性があります。 パケットの順番の入れ替わりはCPUスケジューリングフィルターで該当パケットの転送処理を実行するCPUコアを固定することで抑制することができます。 なお、TCPではパケットの順番が入れ替わっても通常は問題は発生しません。 IPsecでは、ESPシーケンス番号の順序通りにESPパケットが送受信されないことがあるため、両側のルーターでESPシーケンスエラーが発生し、ESPパケットが破棄される可能性があります。 ESPシーケンスエラーは、両側のルーターの ipsec sa policy コマンドで anti-replay-check を off にして、ESPシーケンス番号のチェックを行わないようにすることで回避できます。
以下にロードバランス方式によるCPUコア割り当ての例を示します。図3は表3のパケットを受信した場合のCPUコア割り当ての流れです。 パケット①、②はUDPのパケット、パケット③、④はTCPのパケットです。 パケット⑤はパケット①と同じヘッダ情報を持つパケットです。 なお、ここではCPUスケジューリングフィルターは適用していません。
パケット①〜⑤の転送処理は、各CPUコアの負荷が均等になるように決定されたCPUコアで実行されます。 ここではパケット①の転送処理はCPU1で実行されていますが、パケット①と同じヘッダ情報を持つパケット⑤の転送処理はCPU2で実行されています。
LANインターフェース方式では、パケットを受信したLANインターフェースによってパケットの転送処理をどのCPUコアで実行するかが決定されます。 受信LANインターフェースごとの転送処理を実行するCPUコアは以下のようになっています。
| 受信LANインターフェース | CPUコア |
|---|---|
| LAN1 | CPU0 |
| LAN2 | CPU1 |
| LAN3 | CPU2 |
| LAN4 | CPU3 |
受信パケットのヘッダ情報を意識しなくとも、パケットの転送処理を意図したCPUコアで実行することができますが、ネットワーク構成によってはCPU負荷に偏りが生じる可能性があります。
IPsecでは、ESPシーケンス番号の順序通りにESPパケットが送信されないことがあるため、対向側ルーターの受信処理でESPシーケンスエラーが発生し、ESPパケットが破棄される可能性があります。 ESPシーケンスエラーは、対向側ルーターの ipsec sa policy コマンドで anti-replay-check を off にして、ESPシーケンス番号のチェックを行わないようにすることで回避できます。
以下にLANインターフェース方式によるCPUコア割り当ての例を示します。図4は表4のパケットを受信した場合のCPUコア割り当ての流れです。 パケット①、⑤はLAN2、パケット②はLAN3、パケット③はLAN4、パケット④はLAN1で受信したパケットです。 なお、ここではCPUスケジューリングフィルターは適用していません。
パケット①〜⑤の転送処理は、それぞれのパケットを受信したLANインターフェースに対応したCPUコアで実行されます。
CPUスケジューリングフィルターは、特定の受信パケットの転送処理を任意のCPUコアで実行できるようにするための機能で、パケットごとに転送処理を実行するCPUコアを固定することができます。
CPUスケジューリングフィルターは、転送処理を実行するCPUコアを固定する受信パケットの情報を示したフィルターを適用することで有効となります。 フィルターは複数適用することができます。 フィルターに合致した受信パケットはフィルターで指定したCPUコアで転送処理が実行され、 すべてのフィルターに合致しなかったパケットはCPUスケジューリング方式に従って決定されたCPUコアで転送処理が実行されます。
CPUスケジューリングフィルターに登録する受信パケットのヘッダ情報は、以下を組み合わせて指定します。
| ヘッダ情報 | 備考 |
|---|---|
| IPv4/IPv6送信元アドレス | ネットマスク/プレフィックス指定が可能 |
| IPv4/IPv6送信先アドレス | ネットマスク/プレフィックス指定が可能 |
| プロトコル | - |
| TCP/UDP送信元ポート | - |
| TCP/UDP送信先ポート | - |
以下にCPUスケジューリングフィルターによるCPUコア割り当ての例を示します。図5は表5のパケットを受信した場合のCPUコア割り当ての流れで、 表6のCPUスケジューリングフィルターが適用されています。 パケット①、②はUDPのパケット、パケット③、④はTCPのパケットです。 フィルター1はUDPのパケットの転送処理を実行するCPUコアを固定、フィルター2はICMPのパケットの転送処理を実行するCPUコアを固定、 フィルター3は特定のアドレスからアドレスへ転送されるFTPのパケットの転送処理を実行するCPUコアを固定します。 なお、ここではCPUスケジューリング方式としてロードバランス方式を採用しています。
パケット①、②はフィルター1、④はフィルター3と合致するため、各フィルターで指定したCPUコアで受信パケットの転送処理が実行されます。 パケット③は合致するフィルターがないため、CPUスケジューリング方式に従って転送処理を実行するCPUコアが決定されます。 ここではロードバランス方式を採用しているので、各CPUコアの負荷が均等になるようにCPUコアが決定されます。
| 設定値 | 説明 |
|---|---|
| hash | ハッシュ方式 |
| load-balance | ロードバランス方式 |
| lan-based | LANインターフェース方式 |
CPUスケジューリング方式を設定する。
hash を選択した場合、受信パケットから算出されたハッシュ値を基にしてパケットの転送処理を 実行するCPUコアが決まる。
load-balance を選択した場合、各CPUコアの負荷が均等になるようにパケットの転送処理を実行 するCPUコアがパケット単位で変化する。
| 受信LANインターフェース | CPUコア |
|---|---|
| LAN1 | CPU0 |
| LAN2 | CPU1 |
| LAN3 | CPU2 |
| LAN4 | CPU3 |
BRI/PRIインターフェースで受信したパケットは、本コマンドの設定の対象にならない。
本コマンドを実行すると、すべてのLANインターフェースの初期化処理が実行されるため、 すべてのLANインターフェースにおいて一時的にリンクダウンが発生する。
ノーマルパスの処理対象となるパケットは、本コマンドの設定に従って決定されたCPUコアでは 受信処理のみが実行され、転送処理は常にCPU1で実行される。これは、ip routing process コマンドで normal が設定されている場合はすべてのパケットが対象となる。
CPUスケジューリング方式に hash を選択した場合、IPv4/IPv6ヘッダを持たない受信パケットの 転送処理はCPU0で実行される。
CPUスケジューリング方式に load-balance を選択した場合、パケットの順番が入れ替わる可能性がある。 パケットの順番が入れ替わるとUDPを用いるアプリケーションで問題が発生する可能性がある。 パケットの順番の入れ替わりは system packet-scheduling filter コマンドで該当パケットの 転送処理を実行するCPUコアを固定することで抑制することができる。なお、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 にする必要がある。
| ニーモニック | プロトコル番号 |
|---|---|
| icmp | 1(IPv4の場合)、58(IPv6の場合) |
| tcp | 6 |
| udp | 17 |
| gre | 47 |
| esp | 50 |
| ニーモニック | ポート番号 |
|---|---|
| ftp | 21 |
| ftpdata | 20 |
| telnet | 23 |
| smtp | 25 |
| domain | 53 |
| gopher | 70 |
| finger | 79 |
| www | 80 |
| pop3 | 110 |
| sunrpc | 111 |
| ident | 113 |
| ntp | 123 |
| nntp | 119 |
| snmp | 161 |
| syslog | 514 |
| printer | 515 |
| talk | 517 |
| route | 520 |
| uucp | 540 |
| submission | 587 |
転送処理を実行するCPUコアを固定するためのフィルターを設定する。
フィルターに合致した受信パケットは、CPU_NUM で指定したCPUコアで転送処理が行われる。
BRI/PRIインターフェースで受信したパケットは、本コマンドの設定の対象にならない。
ノーマルパスの処理対象となるパケットは、本コマンドの設定に従って決定されたCPUコアでは 受信処理のみが実行され、転送処理は必ずCPU1で実行される。これは、ip routing process コマンドで normal が設定されている場合はすべてのパケットが対象となる。
IPv4/IPv6ヘッダを持たない受信パケットは、本コマンドの設定の対象にならない。
system packet-scheduling filter コマンドで設定したフィルターを適用する順番を設定する。
フィルターに合致した受信パケットは、フィルターで指定したCPUコアで転送処理が行われる。 すべてのフィルターに合致しなかった受信パケットは、 system packet-scheduling コマンドの 設定に従って転送処理を実行するCPUコアが決まる。
show status packet-scheduling
現在のCPUスケジューリング(パケット転送)機能の状態を表示する。
| 設定値 | 説明 |
|---|---|
| hash | ハッシュ方式 |
| load-balance | ロードバランス方式 |
| lan-based | LANインターフェース方式 |
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 パケット
system packet-scheduling load-balance system packet-scheduling filter list 1 2 system packet-scheduling filter 1 3 ip * * udp system packet-scheduling filter 2 3 ipv6 * * udp ip route 192.168.100.0/24 gateway 192.168.100.10 ip route 192.168.101.0/24 gateway 192.168.101.10 ip lan1 address 192.168.100.1/24 ip lan2 address 192.168.101.1/24
受信パケットの転送処理はロードバランス方式に従って決定されたCPUコアで実行します。
ロードバランス方式では、パケットの順番が入れ替わる可能性があり、UDPを用いるアプリケーションで問題が発生する可能性があるため、 CPUスケジューリングフィルターで、UDPの受信パケットの転送処理を実行するCPUコアをCPU3に固定することでパケットの順番の入れ替わりを抑制します。
CPUスケジューリングフィルターを適用します。
system packet-scheduling load-balance system packet-scheduling filter list 1 2 3 4 5 6 7 8 system packet-scheduling filter 1 0 ip 172.16.1.1 * system packet-scheduling filter 2 1 ip 172.16.1.2 * system packet-scheduling filter 3 2 ip 172.16.1.3 * system packet-scheduling filter 4 3 ip 172.16.1.4 * system packet-scheduling filter 5 0 ip * 192.168.101.0/24 system packet-scheduling filter 6 1 ip * 192.168.102.0/24 system packet-scheduling filter 7 2 ip * 192.168.103.0/24 system packet-scheduling filter 8 3 ip * 192.168.104.0/24 ip route default gateway pp 1 ip route 192.168.101.0/24 gateway tunnel 1 ip route 192.168.102.0/24 gateway tunnel 2 ip route 192.168.103.0/24 gateway tunnel 3 ip route 192.168.104.0/24 gateway tunnel 4 ip lan1 address 192.168.100.1/24 pp select 1 pp always-on on pppoe use lan3 pp auth accept pap chap pp auth myname ID PASSWORD ppp lcp mru on 1454 ppp ipcp ipaddress on ppp ipcp msext on ip pp mtu 1454 ip pp nat descriptor 1 pp enable 1 tunnel select 1 ipsec tunnel 1 ipsec sa policy 1 1 esp aes-cbc sha-hmac anti-replay-check=off ipsec ike keepalive use 1 on ipsec ike local address 1 192.168.100.1 ipsec ike pre-shared-key 1 text pass1 ipsec ike remote address 1 172.16.1.1 ipsec ike remote name 1 kyoten1 key-id tunnel enable 1 tunnel select 2 ipsec tunnel 2 ipsec sa policy 2 2 esp aes-cbc sha-hmac anti-replay-check=off ipsec ike keepalive use 2 on ipsec ike local address 2 192.168.100.1 ipsec ike pre-shared-key 2 text pass2 ipsec ike remote address 2 172.16.1.2 ipsec ike remote name 2 kyoten2 key-id tunnel enable 2 tunnel select 3 ipsec tunnel 3 ipsec sa policy 3 3 esp aes-cbc sha-hmac anti-replay-check=off ipsec ike keepalive use 3 on ipsec ike local address 3 192.168.100.1 ipsec ike pre-shared-key 3 text pass3 ipsec ike remote address 3 172.16.1.3 ipsec ike remote name 3 kyoten3 key-id tunnel enable 3 tunnel select 4 ipsec tunnel 4 ipsec sa policy 4 4 esp aes-cbc sha-hmac anti-replay-check=off ipsec ike keepalive use 4 on ipsec ike local address 4 192.168.100.1 ipsec ike pre-shared-key 4 text pass4 ipsec ike remote address 4 172.16.1.4 ipsec ike remote name 4 kyoten4 key-id tunnel enable 4 nat descriptor type 1 masquerade nat descriptor masquerade static 1 1 192.168.100.1 udp 500 nat descriptor masquerade static 1 3 192.168.100.1 esp ipsec auto refresh on dhcp service server dhcp scope 1 192.168.100.2-192.168.100.191/24 dns server 10.10.10.1 dns private address spoof on
ip route default gateway pp 1 ip route 192.168.100.0/24 gateway tunnel 1 ip lan1 address 192.168.101.1/24 ・・・(※) pp select 1 pp always-on on pppoe use lan2 pp auth accept pap chap pp auth myname ID PASSWORD ・・・(※) ppp lcp mru on 1454 ppp ipcp ipaddress on ppp ipcp msext on ip pp mtu 1454 ip pp nat descriptor 1 pp enable 1 tunnel select 1 ipsec tunnel 1 ipsec sa policy 1 1 esp aes-cbc sha-hmac anti-replay-check=off ipsec ike keepalive use 1 on ipsec ike local address 1 192.168.101.1 ・・・(※) ipsec ike local name 1 kyoten1 key-id ・・・(※) ipsec ike pre-shared-key 1 text pass1 ・・・(※) ipsec ike remote address 1 172.16.0.1 tunnel enable 1 nat descriptor type 1 masquerade nat descriptor masquerade static 1 1 192.168.101.1 udp 500 ・・・(※) nat descriptor masquerade static 1 2 192.168.101.1 esp ・・・(※) ipsec auto refresh on dhcp service server dhcp scope 1 192.168.101.2-192.168.101.191/24 ・・・(※) dns server 10.10.10.2 ・・・(※) dns private address spoof on (※)拠点に合わせて設定します。
受信パケットの転送処理はロードバランス方式に従って決定されたCPUコアで実行します。
拠点からの受信パケットの転送処理を実行するCPUコアを、拠点別に固定します。拠点1からのパケットはCPU0、 拠点2からのパケットはCPU1、拠点3からのパケットはCPU2、拠点4からのパケットはCPU3で転送処理を実行します。
CPUスケジューリングフィルターで、カプセル化されたパケットをIPアドレスでフィルタリングする場合は、外側IPアドレスが対象となります。
拠点へ向かう受信パケットの転送処理を実行するCPUコアを、拠点別に固定します。拠点1へ向かうパケットはCPU0、 拠点2へ向かうパケットはCPU1、拠点3へ向かうパケットはCPU2、拠点4へ向かうパケットはCPU3で転送処理を実行します。
CPUスケジューリングフィルターを適用します。
ロードバランス方式を使用する場合、IPsecではESPシーケンス番号の順序通りにESPパケットが送受信されず、 両側のルーターでESPシーケンスエラーが発生し、ESPパケットが破棄される可能性があるため、両側のルーターの anti-replay-check を off にして、ESPシーケンス番号のチェックを行わないようにすることで回避します。