日本語フォーラム

#show cpuload  user 0.7%, system 2.1%, idle 97.2%#show cpuload current top2 - 20:01:47 up 37 days,  2:04,  0 users,  load average: 0.15, 0.17, 0.17Tasks: 491 total,   1 running, 489 sleeping,   0 stopped,   1 zombieCpu(s):  1.1%us,  2.5%sy,  0.2%ni, 96.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stMem:   5167744k total,  3411200k used,  1756544k free,   355520k buffersSwap:  2621312k total,        0k used,  2621312k free,  1438912k cached  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            29756 root      20   0  4800 3136 1856 R   12  0.1   0:00.15 top2                3473 root      20   0  5568 2496 1792 S    2  0.0  16:23.73 dbstart_pgsql       3594 root      20   0 40704  14m 8576 S    2  0.3  39:39.30 lagm                3609 root      20   0 88512  20m 8320 S    2  0.4  39:44.60 licensemgr          4270 root      20   0 53824  21m 9.9m S    2  0.4  34:15.50 central_agent       4617 root      20   0 68032  12m 7040 S    2  0.3 115:11.56 osapiTimer             1 root      20   0  5504 2368 1792 S    0  0.0   0:08.06 init                   2 root      20   0     0    0    0 S    0  0.0   0:00.12 kthreadd     ​

#show datapath utilization  Datapath Network Processor Utilization+---------+-----+---------+---------+----------+|       Cpu     |  Cpu utilization during past ||   Type  |  Id |  1 Sec     4 Secs    64 Secs |+---------+-----+---------+---------+----------+     SPGW |   8 |      0% |      0% |       0% |       SP |   9 |      2% |      1% |       1% |       FP |  10 |      0% |      0% |       0% |     FPGW |  11 |      0% |      0% |       0% |       FP |  12 |      0% |      0% |       0% |       FP |  13 |      0% |      0% |       0% |       FP |  14 |      0% |      0% |       0% |       FP |  15 |      0% |      0% |       0% |Datapath CPU Allocation Summary  Slow Path (SP) : 1,  Slow Path Gateway (SPGW) : 1   Fast Path (FP) : 5,  Fast Path Gateway (FPGW) : 1   DPI : 0, Crypto (CRYP) : 0  Slow Path Spare (SPSPARE) : 0​

Datapath CPU の中で、主にFP (Fast Path) CPU がトラフィック処理に利用されています。
トラフィックが非常に多い環境では、このFP CPUの負荷が高くなり、ユーザ通信に影響がでることがあるので、
以下でご紹介するような設定で、負荷を下げるようにしましょう。


1. ブロードキャストとマルチキャストの最適化
一番効果的な対応が、ブロードキャストとマルチキャストの最適化です。（以下、Broadcast, MulticastをBC/MCと記載します）
最適化というよりも、不要なVLANやSSIDで、BC/MCを使えなく（Drop）してしまいましょう。
フレームをコピーするときにFPへの負荷がかかりますし、ネットワーク全体のパフォーマンスを考えても、
不要なBC/MCはいいことがありません。（あくまで不要な場合です）
ArubaのControllerは主に2つの方法でBC/MCを止めることができます。

1-1 VLAN 単位で設定
VLAN単位で指定したいときは、VLAN Interfaceで以下のコマンドを設定します。
これだけで、対象VLANでのBC/MCの転送を止めることができます。

(config) #interface vlan xxx(config-submode)#bcmc-optimization

もちろん、ARPやDHCPなど、止めては困るフレームもあり、bcmc-optimizationではこれらの通信は対象外です。
詳細は、マニュアルに記載されているのでこちらをご確認下さい。

1-2 SSID 単位で設定
SSID単位でBC/MCを止める場合は、Virtual AP Profile で、broadcast-filter all を設定します。

(config) #wlan virtual-ap your-profile(Virtual AP profile "your-profile") #broadcast-filter all(Virtual AP profile "your-profile") #broadcast-filter arp

この設定を使う場合は、必ずbroadcast-filter arpも設定するようにします。（broadcast-filter arp はデフォルトで有効です）
broadcast-filter arpの設定は、ブロードキャスト ARP Requestをユニキャストに変換してくれます。DHCP Response も同様です。
broadcast-filter はAP→端末向けに適用されるので、端末→APへのBC/MCをブロックするわけではありません。
詳細はこちらのマニュアルをご参照下さい。


2. Suppress ARP 
この機能は、デフォルトで有効なので、特別設定していなければそのままで問題ありません。
VLAN Interfaceで設定し、Unknown ARP を無線LANクライアントに転送しなくなります。
有線には転送します。
Unknownかどうかは、Controller のユーザエントリの有無で判断します。
Suppress ARP の有無での動作の違いは以下のようになります。

以下が設定例です。

(config) #interface vlan xxx(config-submode)#suppress-arp

こちらのマニュアルもご参照下さい。


3.  Cluster Load Balancing の最適化
こちらは、Mobility Conductor (MCR) を使ったクラスタ機能を使っている場合の対応方法になります。
MCRは複数のMobility Controller (MC) を集中管理し、さらにクラスタ構成を取ることで、
クラスタ内のController間で収容するAPやクライアントの動的な負荷分散をすることができます。

ここでのクライアントの負荷分散は、トラフィック量には関係無く接続クライアント数に基づいて行われます。
基本的には特に設定変更せずとも、ある程度MC毎の接続クライアント数が同程度になると思いますが、
特定のMCへ接続クライアントが偏るようなケースがあれば、
ロードバランスが実行される閾値を変更してみて下さい。
以下がデフォルトの閾値と、大規模環境での推奨値です。

クライアント負荷（client load）はMCに接続しているクライアント数➗MCのサポートしている最大クライアント数です。
Active Client Rebalance Threshold と Unbalanced Threshold の両方が満たされたときにクライアントの移動が実行されます。
以下の例はだいぶ極端な例ですが、クライアント負荷が53% （>20%）、Unbalanced Threshold が53-6.2 = 46.8 （>5%）なので、
接続クライアントが7240から7210 に移動します。
詳細はマニュアルをご参照下さい。


4. ユーザ毎の帯域制御

こちらの設定は要件次第になるとは思います。
社内（学内）で、特定にユーザだけが、インターネットから大容量ファイルをダウンロードしていたり、動画をひたすら視聴し、
他のユーザに影響が出ているような場合には検討してみる価値があると思います。
ArubaはUser Roleで色々するのが得意です。一番の例はアクセス制御ですが、
ユーザ毎の帯域制御もUser Roleの設定で簡単に行うことができます。

aaa bandwidth-contract upstreamper-user mbits 300aaa bandwidth-contract downstreamper-user mbits 300user-role student   bw-contract downstreamper-user per-user downstream   bw-contract upstreamper-user per-user upstream

上記は、user-role studentのユーザ毎の帯域を300Mbps（上り／下り）に制限する設定例です。
詳細はマニュアルもご参照下さい。


今回は主に設定の観点でいくつか紹介しました。
また機会があれば、トラブルシューティングの観点での確認ポイントなども解説できたらなと思っています。
サボっていつになるかわからない可能性もあるので、今すぐ知りたいってお声があれば、是非ここでコメント下さい！

#show cpuload  user 0.7%, system 2.1%, idle 97.2%#show cpuload current top2 - 20:01:47 up 37 days,  2:04,  0 users,  load average: 0.15, 0.17, 0.17Tasks: 491 total,   1 running, 489 sleeping,   0 stopped,   1 zombieCpu(s):  1.1%us,  2.5%sy,  0.2%ni, 96.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stMem:   5167744k total,  3411200k used,  1756544k free,   355520k buffersSwap:  2621312k total,        0k used,  2621312k free,  1438912k cached  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            29756 root      20   0  4800 3136 1856 R   12  0.1   0:00.15 top2                3473 root      20   0  5568 2496 1792 S    2  0.0  16:23.73 dbstart_pgsql       3594 root      20   0 40704  14m 8576 S    2  0.3  39:39.30 lagm                3609 root      20   0 88512  20m 8320 S    2  0.4  39:44.60 licensemgr          4270 root      20   0 53824  21m 9.9m S    2  0.4  34:15.50 central_agent       4617 root      20   0 68032  12m 7040 S    2  0.3 115:11.56 osapiTimer             1 root      20   0  5504 2368 1792 S    0  0.0   0:08.06 init                   2 root      20   0     0    0    0 S    0  0.0   0:00.12 kthreadd     ​

#show datapath utilization  Datapath Network Processor Utilization+---------+-----+---------+---------+----------+|       Cpu     |  Cpu utilization during past ||   Type  |  Id |  1 Sec     4 Secs    64 Secs |+---------+-----+---------+---------+----------+     SPGW |   8 |      0% |      0% |       0% |       SP |   9 |      2% |      1% |       1% |       FP |  10 |      0% |      0% |       0% |     FPGW |  11 |      0% |      0% |       0% |       FP |  12 |      0% |      0% |       0% |       FP |  13 |      0% |      0% |       0% |       FP |  14 |      0% |      0% |       0% |       FP |  15 |      0% |      0% |       0% |Datapath CPU Allocation Summary  Slow Path (SP) : 1,  Slow Path Gateway (SPGW) : 1   Fast Path (FP) : 5,  Fast Path Gateway (FPGW) : 1   DPI : 0, Crypto (CRYP) : 0  Slow Path Spare (SPSPARE) : 0​

Datapath CPU の中で、主にFP (Fast Path) CPU がトラフィック処理に利用されています。
トラフィックが非常に多い環境では、このFP CPUの負荷が高くなり、ユーザ通信に影響がでることがあるので、
以下でご紹介するような設定で、負荷を下げるようにしましょう。


1. ブロードキャストとマルチキャストの最適化
一番効果的な対応が、ブロードキャストとマルチキャストの最適化です。（以下、Broadcast, MulticastをBC/MCと記載します）
最適化というよりも、不要なVLANやSSIDで、BC/MCを使えなく（Drop）してしまいましょう。
フレームをコピーするときにFPへの負荷がかかりますし、ネットワーク全体のパフォーマンスを考えても、
不要なBC/MCはいいことがありません。（あくまで不要な場合です）
ArubaのControllerは主に2つの方法でBC/MCを止めることができます。

1-1 VLAN 単位で設定
VLAN単位で指定したいときは、VLAN Interfaceで以下のコマンドを設定します。
これだけで、対象VLANでのBC/MCの転送を止めることができます。

(config) #interface vlan xxx(config-submode)#bcmc-optimization

もちろん、ARPやDHCPなど、止めては困るフレームもあり、bcmc-optimizationではこれらの通信は対象外です。
詳細は、マニュアルに記載されているのでこちらをご確認下さい。

1-2 SSID 単位で設定
SSID単位でBC/MCを止める場合は、Virtual AP Profile で、broadcast-filter all を設定します。

(config) #wlan virtual-ap your-profile(Virtual AP profile "your-profile") #broadcast-filter all(Virtual AP profile "your-profile") #broadcast-filter arp

この設定を使う場合は、必ずbroadcast-filter arpも設定するようにします。（broadcast-filter arp はデフォルトで有効です）
broadcast-filter arpの設定は、ブロードキャスト ARP Requestをユニキャストに変換してくれます。DHCP Response も同様です。
broadcast-filter はAP→端末向けに適用されるので、端末→APへのBC/MCをブロックするわけではありません。
詳細はこちらのマニュアルをご参照下さい。


2. Suppress ARP 
この機能は、デフォルトで有効なので、特別設定していなければそのままで問題ありません。
VLAN Interfaceで設定し、Unknown ARP を無線LANクライアントに転送しなくなります。
有線には転送します。
Unknownかどうかは、Controller のユーザエントリの有無で判断します。
Suppress ARP の有無での動作の違いは以下のようになります。

以下が設定例です。

(config) #interface vlan xxx(config-submode)#suppress-arp

こちらのマニュアルもご参照下さい。


3.  Cluster Load Balancing の最適化
こちらは、Mobility Conductor (MCR) を使ったクラスタ機能を使っている場合の対応方法になります。
MCRは複数のMobility Controller (MC) を集中管理し、さらにクラスタ構成を取ることで、
クラスタ内のController間で収容するAPやクライアントの動的な負荷分散をすることができます。

ここでのクライアントの負荷分散は、トラフィック量には関係無く接続クライアント数に基づいて行われます。
基本的には特に設定変更せずとも、ある程度MC毎の接続クライアント数が同程度になると思いますが、
特定のMCへ接続クライアントが偏るようなケースがあれば、
ロードバランスが実行される閾値を変更してみて下さい。
以下がデフォルトの閾値と、大規模環境での推奨値です。

クライアント負荷（client load）はMCに接続しているクライアント数➗MCのサポートしている最大クライアント数です。
Active Client Rebalance Threshold と Unbalanced Threshold の両方が満たされたときにクライアントの移動が実行されます。
以下の例はだいぶ極端な例ですが、クライアント負荷が53% （>20%）、Unbalanced Threshold が53-6.2 = 46.8 （>5%）なので、
接続クライアントが7240から7210 に移動します。
詳細はマニュアルをご参照下さい。


4. ユーザ毎の帯域制御

こちらの設定は要件次第になるとは思います。
社内（学内）で、特定にユーザだけが、インターネットから大容量ファイルをダウンロードしていたり、動画をひたすら視聴し、
他のユーザに影響が出ているような場合には検討してみる価値があると思います。
ArubaはUser Roleで色々するのが得意です。一番の例はアクセス制御ですが、
ユーザ毎の帯域制御もUser Roleの設定で簡単に行うことができます。

aaa bandwidth-contract upstreamper-user mbits 300aaa bandwidth-contract downstreamper-user mbits 300user-role student   bw-contract downstreamper-user per-user downstream   bw-contract upstreamper-user per-user upstream

上記は、user-role studentのユーザ毎の帯域を300Mbps（上り／下り）に制限する設定例です。
詳細はマニュアルもご参照下さい。


今回は主に設定の観点でいくつか紹介しました。
また機会があれば、トラブルシューティングの観点での確認ポイントなども解説できたらなと思っています。
サボっていつになるかわからない可能性もあるので、今すぐ知りたいってお声があれば、是非ここでコメント下さい！

#show cpuload  user 0.7%, system 2.1%, idle 97.2%#show cpuload current top2 - 20:01:47 up 37 days,  2:04,  0 users,  load average: 0.15, 0.17, 0.17Tasks: 491 total,   1 running, 489 sleeping,   0 stopped,   1 zombieCpu(s):  1.1%us,  2.5%sy,  0.2%ni, 96.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stMem:   5167744k total,  3411200k used,  1756544k free,   355520k buffersSwap:  2621312k total,        0k used,  2621312k free,  1438912k cached  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            29756 root      20   0  4800 3136 1856 R   12  0.1   0:00.15 top2                3473 root      20   0  5568 2496 1792 S    2  0.0  16:23.73 dbstart_pgsql       3594 root      20   0 40704  14m 8576 S    2  0.3  39:39.30 lagm                3609 root      20   0 88512  20m 8320 S    2  0.4  39:44.60 licensemgr          4270 root      20   0 53824  21m 9.9m S    2  0.4  34:15.50 central_agent       4617 root      20   0 68032  12m 7040 S    2  0.3 115:11.56 osapiTimer             1 root      20   0  5504 2368 1792 S    0  0.0   0:08.06 init                   2 root      20   0     0    0    0 S    0  0.0   0:00.12 kthreadd     ​

#show datapath utilization  Datapath Network Processor Utilization+---------+-----+---------+---------+----------+|       Cpu     |  Cpu utilization during past ||   Type  |  Id |  1 Sec     4 Secs    64 Secs |+---------+-----+---------+---------+----------+     SPGW |   8 |      0% |      0% |       0% |       SP |   9 |      2% |      1% |       1% |       FP |  10 |      0% |      0% |       0% |     FPGW |  11 |      0% |      0% |       0% |       FP |  12 |      0% |      0% |       0% |       FP |  13 |      0% |      0% |       0% |       FP |  14 |      0% |      0% |       0% |       FP |  15 |      0% |      0% |       0% |Datapath CPU Allocation Summary  Slow Path (SP) : 1,  Slow Path Gateway (SPGW) : 1   Fast Path (FP) : 5,  Fast Path Gateway (FPGW) : 1   DPI : 0, Crypto (CRYP) : 0  Slow Path Spare (SPSPARE) : 0​

Datapath CPU の中で、主にFP (Fast Path) CPU がトラフィック処理に利用されています。
トラフィックが非常に多い環境では、このFP CPUの負荷が高くなり、ユーザ通信に影響がでることがあるので、
以下でご紹介するような設定で、負荷を下げるようにしましょう。


1. ブロードキャストとマルチキャストの最適化
一番効果的な対応が、ブロードキャストとマルチキャストの最適化です。（以下、Broadcast, MulticastをBC/MCと記載します）
最適化というよりも、不要なVLANやSSIDで、BC/MCを使えなく（Drop）してしまいましょう。
フレームをコピーするときにFPへの負荷がかかりますし、ネットワーク全体のパフォーマンスを考えても、
不要なBC/MCはいいことがありません。（あくまで不要な場合です）
ArubaのControllerは主に2つの方法でBC/MCを止めることができます。

1-1 VLAN 単位で設定
VLAN単位で指定したいときは、VLAN Interfaceで以下のコマンドを設定します。
これだけで、対象VLANでのBC/MCの転送を止めることができます。

(config) #interface vlan xxx(config-submode)#bcmc-optimization

もちろん、ARPやDHCPなど、止めては困るフレームもあり、bcmc-optimizationではこれらの通信は対象外です。
詳細は、マニュアルに記載されているのでこちらをご確認下さい。

1-2 SSID 単位で設定
SSID単位でBC/MCを止める場合は、Virtual AP Profile で、broadcast-filter all を設定します。

(config) #wlan virtual-ap your-profile(Virtual AP profile "your-profile") #broadcast-filter all(Virtual AP profile "your-profile") #broadcast-filter arp

この設定を使う場合は、必ずbroadcast-filter arpも設定するようにします。（broadcast-filter arp はデフォルトで有効です）
broadcast-filter arpの設定は、ブロードキャスト ARP Requestをユニキャストに変換してくれます。DHCP Response も同様です。
broadcast-filter はAP→端末向けに適用されるので、端末→APへのBC/MCをブロックするわけではありません。
詳細はこちらのマニュアルをご参照下さい。


2. Suppress ARP 
この機能は、デフォルトで有効なので、特別設定していなければそのままで問題ありません。
VLAN Interfaceで設定し、Unknown ARP を無線LANクライアントに転送しなくなります。
有線には転送します。
Unknownかどうかは、Controller のユーザエントリの有無で判断します。
Suppress ARP の有無での動作の違いは以下のようになります。

以下が設定例です。

(config) #interface vlan xxx(config-submode)#suppress-arp

こちらのマニュアルもご参照下さい。


3.  Cluster Load Balancing の最適化
こちらは、Mobility Conductor (MCR) を使ったクラスタ機能を使っている場合の対応方法になります。
MCRは複数のMobility Controller (MC) を集中管理し、さらにクラスタ構成を取ることで、
クラスタ内のController間で収容するAPやクライアントの動的な負荷分散をすることができます。

ここでのクライアントの負荷分散は、トラフィック量には関係無く接続クライアント数に基づいて行われます。
基本的には特に設定変更せずとも、ある程度MC毎の接続クライアント数が同程度になると思いますが、
特定のMCへ接続クライアントが偏るようなケースがあれば、
ロードバランスが実行される閾値を変更してみて下さい。
以下がデフォルトの閾値と、大規模環境での推奨値です。

クライアント負荷（client load）はMCに接続しているクライアント数➗MCのサポートしている最大クライアント数です。
Active Client Rebalance Threshold と Unbalanced Threshold の両方が満たされたときにクライアントの移動が実行されます。
以下の例はだいぶ極端な例ですが、クライアント負荷が53% （>20%）、Unbalanced Threshold が53-6.2 = 46.8 （>5%）なので、
接続クライアントが7240から7210 に移動します。
詳細はマニュアルをご参照下さい。


4. ユーザ毎の帯域制御

こちらの設定は要件次第になるとは思います。
社内（学内）で、特定にユーザだけが、インターネットから大容量ファイルをダウンロードしていたり、動画をひたすら視聴し、
他のユーザに影響が出ているような場合には検討してみる価値があると思います。
ArubaはUser Roleで色々するのが得意です。一番の例はアクセス制御ですが、
ユーザ毎の帯域制御もUser Roleの設定で簡単に行うことができます。

aaa bandwidth-contract upstreamper-user mbits 300aaa bandwidth-contract downstreamper-user mbits 300user-role student   bw-contract downstreamper-user per-user downstream   bw-contract upstreamper-user per-user upstream

上記は、user-role studentのユーザ毎の帯域を300Mbps（上り／下り）に制限する設定例です。
詳細はマニュアルもご参照下さい。


今回は主に設定の観点でいくつか紹介しました。
また機会があれば、トラブルシューティングの観点での確認ポイントなども解説できたらなと思っています。
サボっていつになるかわからない可能性もあるので、今すぐ知りたいってお声があれば、是非ここでコメント下さい！