Cisco WLC を Act-Act で運用する話

こんにちは、IT 基盤部ネットワークグループの寺増です。

前回の無線 LAN の通信品質を見える化する話に続き、今回はヒカリエ本社における Act - Act 構成の WLC 運用とその中での自動化手法を紹介します。内容はネットワークエンジニア、特にエンタープライズの無線 LAN を運用中の方、これから構築を行われる方、そして無線 LAN に興味をお持ちの方向きになっています。

はじめに

まずは、ヒカリエ本社の無線 LAN 基盤に関するネットワーク構成を簡単に紹介します。

主要な機器は以下の通りです。

無線 LAN コントローラ (以下、WLC)
- Cisco Catalyst 9800 2 台
アクセスポイント (以下、AP)
- Cisco Aironet AP4800 127 台 (1 フロアあたり 16 - 20 台)

全 VLAN とも CAPWAP を用いた Central Switching モデルで、二台の WLC に AP を分散して帰属させた所謂 Act - Act 構成を採用しています。

この Act - Act 構成にはメリットとデメリットが存在しています。本記事ではここから紹介していきます。

補足：本記事で紹介する運用は全て Catalyst 9800 / AP4800 の前身にあたる Cisco CT Series ならびに Lightweight AP でも有効です。

メリット／デメリット

最初にメリットです。これらは実際に我々が肌で感じているポイントです。

費用面 / Cost
- HA 構成時の N+1 スタンバイ WLC に類する予備機が不要
運用面 / Quality
- 実質スタンドアローン 2 台で、AP の片寄せが容易に可能
- 同上の理由につき、トラフィックの負荷分散が可能
- 同上の理由につき、段階的なバージョンアップ／ダウンが可能
- 同上の理由につき、HA 構成に関連するバグの回避が可能
- トラフィックが常に流れているので通信区間の異常に気づき易い
- HA 構成運用で発生する設定変更による全断と無縁
- WLC 障害時の切り替えが比較的高速 (最大約 10 秒程度)

いずれも運用コストや通信品質を重要視する環境では捨てがたい特性となっています。次にデメリットを見ていきます。

費用面 / Cost
- HA 構成に比べて二倍の AP ライセンスが必要
運用面 / Quality
- 複数の AP が別々の WLC に帰属するため全体を俯瞰することが困難 (*図2)
- 端末の移動等でそのデータを持つコントローラが不規則に変動する (*図3)
  
  図2: メトリクス (Channel Utilization) データが分散
  
  図3: 端末の移動によってデータを持つ WLC が変動

補足：2 台の WLC 両方で同じ設定変更を実行する必要がある点はデメリットではないと考えています。これは CUI 運用においてさほど大きな手間ではなく、それよりも全断無しで設定変更作業を行えるメリットが大きいと感じているためです。

先述のうち、費用面については Cisco Smart Account の登場によって解消されました。従来は WLC が AP ライセンスを持つモデルでしたが、2019/9E 現在、最新の WLC + AP の構成では AP 自身がライセンスを持つモデルとなっています。つまり Secondary WLC 用の余分なライセンス購入は不要です。

一方の運用面については変わらずで、これらは長期的に見て大きな手間となりえます。解決策として、別途アプライアンス Prime Infrastructure や DNA Center を利用する手もありますが、これらはいずれも一長一短です。「可能な限りリアルタイム に 全体を俯瞰 する」目的においては、どちらも最善の一手と言い辛い部分が残っていました。

DeNA では、これを補う CLI を内製し、運用に組み込むことで Act - Act 構成の環境を成立させています。次項ではこれを紹介していきます。

内製 CLI について

1. 概要

CLI は wlap (cli wrapper for WLC and APs) と命名しています。主たる責務は「WLC を意識せず AP を管理すること」です。

実装について述べる前に、この CLI の利用で改善されているポイントを 3 つほど紹介します。

(1) 判読性の向上

無線 LAN は構成要素やメトリクスが非常に多く、かつ複数台の AP で 1 つのネットワークを構成するという特徴があります。このため、単一コマンドの実行結果だけで全体を俯瞰することが困難です。そしてこれは AP が 2 台の WLC に分散して帰属している Act - Act 構成の環境では尚の事となります。

例えば、単一のカバレッジ (ヒカリエ本社では「1 フロア」が該当します) を構成する AP の設定値と主要メトリクスを網羅的に確認したい場合、通常は以下の 3 ステップが必要になります。

1. 各 WLC で帰属する AP のリストを取得

(例) show advanced 802.11a summary

# WLC1

(Cisco Controller) >show advanced 802.11a summary

Member RRM Information
AP Name  MAC Address        Slot  Admin    Oper   Channel     TxPower
-------- ------------------ ----- -------- ------ ----------- -------------
AP1      6c:9c:ed:eb:e0:a0   1    ENABLED  UP     (136,132)*  *1/7 (17 dBm)
AP3      24:b6:57:5b:6f:70   1    ENABLED  UP     (136,132)*  *1/7 (17 dBm)

# WLC2

(Cisco Controller) >show advanced 802.11a summary

Member RRM Information
AP Name  MAC Address        Slot  Admin    Oper   Channel     TxPower
-------- ------------------ ----- -------- ------ ----------- -------------
AP4      24:b6:57:35:0d:90   1    ENABLED  UP     (36,40)*    *2/7 (14 dBm)
AP2      24:b6:57:35:22:70   1    ENABLED  UP     124*        *2/7 (14 dBm)

表示は AP の帰属順です、sort 相当の機能は提供されていないため視認性に難があります
Radio に関する各種ステータスは確認出来ますが、RF の主要なカウンタは確認出来ません

2. 各 WLC で取得した AP それぞれで 802.11a の情報を取得

(例) show ap auto-rf 802.11a AP1

(Cisco Controller) >show ap auto-rf 802.11a AP1
Number Of Slots.................................. 2
AP Name.......................................... AP1
MAC Address...................................... 6c:9c:ed:eb:e0:a0
  Slot ID........................................ 1
  Radio Type..................................... RADIO_TYPE_80211a
  Sub-band Type.................................. All
  Noise Information
    Noise Profile................................ PASSED
    Channel 36...................................  -94 dBm
    Channel 40...................................  -97 dBm
    Channel 44...................................  -95 dBm
    Channel 48...................................  -96 dBm
    Channel 52...................................  -96 dBm
    Channel 56...................................  -96 dBm
    Channel 60...................................  -96 dBm
    Channel 64...................................  -96 dBm
    Channel 100..................................  -96 dBm
    Channel 104..................................  -95 dBm
    Channel 108..................................  -96 dBm
    Channel 112..................................  -96 dBm
    Channel 116..................................  -96 dBm
    Channel 120..................................  -95 dBm
    Channel 124..................................  -93 dBm
    Channel 128..................................  -93 dBm
    Channel 132..................................  -96 dBm
    Channel 136..................................  -95 dBm
    Channel 140..................................  -96 dBm
  Interference Information
    Interference Profile......................... PASSED
    Channel 36................................... -128 dBm @  0 % busy
    Channel 40................................... -128 dBm @  0 % busy
    Channel 44................................... -128 dBm @  0 % busy
    Channel 48................................... -128 dBm @  0 % busy
    Channel 52................................... -128 dBm @  0 % busy
    Channel 56................................... -128 dBm @  0 % busy
    Channel 60................................... -128 dBm @  0 % busy
    Channel 64................................... -128 dBm @  0 % busy
    Channel 100.................................. -128 dBm @  0 % busy
    Channel 104.................................. -128 dBm @  0 % busy
    Channel 108.................................. -128 dBm @  0 % busy
    Channel 112.................................. -128 dBm @  0 % busy
    Channel 116.................................. -128 dBm @  0 % busy
    Channel 120.................................. -128 dBm @  0 % busy
    Channel 124.................................. -128 dBm @  0 % busy
    Channel 128.................................. -128 dBm @  0 % busy
    Channel 132.................................. -128 dBm @  0 % busy
    Channel 136.................................. -128 dBm @  0 % busy
    Channel 140.................................. -128 dBm @  0 % busy
  Rogue Histogram (20/40/80/160)
    .............................................
    Channel 36...................................  0/ 1/ 0/ 0
    Channel 40...................................  0/ 0/ 0/ 0
    Channel 44...................................  0/ 1/ 0/ 0
    Channel 48...................................  1/ 0/ 0/ 0
    Channel 52...................................  0/ 0/ 0/ 0
    Channel 56...................................  0/ 2/ 0/ 0
    Channel 60...................................  0/ 0/ 0/ 0
    Channel 64...................................  0/ 0/ 0/ 0
    Channel 100..................................  0/ 2/ 0/ 0
    Channel 104..................................  0/ 0/ 0/ 0
    Channel 108..................................  0/ 0/ 0/ 0
    Channel 112..................................  0/ 0/ 0/ 0
    Channel 116..................................  0/ 0/ 0/ 0
    Channel 120..................................  0/ 0/ 0/ 0
    Channel 124..................................  0/ 0/ 0/ 0
    Channel 128..................................  0/ 0/ 0/ 0
    Channel 132..................................  0/ 3/ 0/ 0
    Channel 136..................................  0/ 0/ 0/ 0
    Channel 140..................................  0/ 0/ 0/ 0
  Load Information
    Load Profile................................. PASSED
    Receive Utilization.......................... 0 %
    Transmit Utilization......................... 0 %
    Channel Utilization.......................... 22 %
    Attached Clients............................. 31 clients
  Coverage Information
    Coverage Profile............................. PASSED
    Failed Clients............................... 2 clients
  Client Signal Strengths
    RSSI -100 dbm................................ 0 clients
    RSSI  -92 dbm................................ 0 clients
    RSSI  -84 dbm................................ 1 clients
    RSSI  -76 dbm................................ 1 clients
    RSSI  -68 dbm................................ 0 clients
    RSSI  -60 dbm................................ 12 clients
    RSSI  -52 dbm................................ 17 clients
  Client Signal To Noise Ratios
    SNR    0 dB.................................. 0 clients
    SNR    5 dB.................................. 0 clients
    SNR   10 dB.................................. 1 clients
    SNR   15 dB.................................. 1 clients
    SNR   20 dB.................................. 0 clients
    SNR   25 dB.................................. 0 clients
    SNR   30 dB.................................. 3 clients
    SNR   35 dB.................................. 9 clients
    SNR   40 dB.................................. 8 clients
    SNR   45 dB.................................. 9 clients
  Nearby APs
    AP 00:08:30:d7:30:bf slot 1..................  -86 dBm on  44  40MHz (172.24.54.161)
    AP 6c:9c:ed:eb:c9:2f slot 1..................  -72 dBm on 128  40MHz (172.24.54.161)
    AP 7c:95:f3:74:a3:9f slot 1..................  -62 dBm on 128  40MHz (172.24.54.161)
    AP 7c:95:f3:fc:88:1f slot 1..................  -70 dBm on  36  40MHz (172.24.54.161)
  Radar Information
  Channel Assignment Information
    Current Channel Average Energy...............  -50 dBm
    Previous Channel Average Energy..............  -50 dBm
    Channel Change Count......................... 21
    Last Channel Change Time..................... Tue Sep 19 14:52:55 2019
    Recommended Best Channel..................... 128
  RF Parameter Recommendations
    Power Level.................................. 1
    RTS/CTS Threshold............................ 2347
    Fragmentation Threshold...................... 2346
    Antenna Pattern.............................. 0

  Persistent Interference Devices
  Class Type                 Channel  DC (%%)  RSSI (dBm)  Last Update Time
  -------------------------  -------  ------  ----------  ------------------------
  All third party trademarks are the property of their respective owners.

表示が冗長です、egrep 相当の機能は提供されていないため判読性に難があります
RF の主要なカウンタは確認出来ますが、Radio に関する各種ステータスは確認出来ません

3. 取得した全 AP の情報をマージおよび整形

この作業を手動で行った場合、慣れていても 5 分 - 10 分程度の時間を要してしまいます。

このようなステップが以下のようなワンライナーで処理出来るようになっています。

$ wlap show overview --hostname AP1 -i 11a
This process takes about 4 seconds. Please wait...
 
  +----------+-------------------+------------+---------------+----------------+-------------+--------------------+--------------+-------------+
  | Hostname | MAC               | OperStatus | ChannelNumber | TxPower        | ClientCount | ChannelUtilization | APGroupName  | Controller  |
  +----------+-------------------+------------+---------------+----------------+-------------+--------------------+--------------+-------------+
  | AP1      | 6c:9c:ed:eb:e0:a0 | UP         | (136,132)*    | *1/7 (17 dBm)  | 31 clients  | [#####     ] 53 %  | Group6       | WLC1        |
  | AP2      | 24:b6:57:35:22:70 | UP         | 124*          | *2/7 (14 dBm)  | 1 clients   | [          ] 9 %   | Group3       | WLC2        |
  | AP3      | 24:b6:57:5b:6f:70 | UP         | (136,132)*    | *1/7 (17 dBm)  | 39 clients  | [######    ] 63 %  | Group4       | WLC1        |
  | AP4      | 24:b6:57:35:0d:90 | UP         | (36,40)*      | *2/7 (14 dBm)  | 13 clients  | [#         ] 16 %  | Group2       | WLC2        |
  +----------+-------------------+------------+---------------+----------------+-------------+--------------------+--------------+-------------+

WLC の存在を意識していないことはもちろん、利用頻度の高いメトリクスに表示を限定した上でテーブル形式とすることで判読性を高め、かつ文字整形の手間も完全に省いた形です。本来数分かかる作業が数十秒で完了することは非常に効率的です。

図4: メトリクス (Channel Utilization) データが集約

(2) 操作性の向上

単一 AP の設定変更操作を行う場合、Act - Act 構成の環境では最初にログインする WLC を選択する必要があります。しかし、運用で生じる 100 台以上の AP の帰属先変更に、人間の脳で追従することは非常に困難です。そしてこの結果、どうしても「AP1 の設定変更のため WLC1 にログインしたが、実際の帰属先は WLC2 だった」という時間のロスが発生してしまいます。

加えて対象の WLC にログインした後も、複数のコマンドを実行して初めて目的の設定変更を完了出来る場合があります。例えば、従来の CT シリーズでは、特定 AP の Channel を変更するために以下の 3 コマンドを実行する必要がありました。

(Cisco Controller) > config 802.11a disable AP1
(Cisco Controller) > config 802.11a channel ap AP1 48
(Cisco Controller) > config 802.11a enable AP1

補足：Catalyst 9800 では syntax が改善され 1AP あたりワンラインで完結出来るようになっています。

この書式では Channel 番号が二行目にあたるため、100 台以上の AP に対する流し込みコマンドを作成すると設定の見通しが非常に悪くなります。また、事前の設定状態を確認するには更に別のコマンドも必要です。

このようなステップが以下のようなワンライナーで処理出来るようになっています。

$ wlap set channel --hostname AP1 -i 11a --channel 48 --width 20
AP1 found on WLC1.

Current : Global (36,+1ch)
New     : 48


****** CAUTION: AP will STOP PROPAGATION ******

 - Associating devices will be disassociate.

Are you really sure? (y/n)y
Applying...

先程と同様 WLC の存在を意識せず、事前・事後の差分と影響範囲を正しく認識した上で変更作業が実行出来る形です。対話式で影響範囲を明示しているのは「コマンド 1 つであっても必ず処理内容を確認し、影響範囲を理解した上で実行する」という我々 IT 基盤の運用文化が背景にあります。AP の設定変更は局所的な瞬断を伴うケースが非常に多いため、これにより改めてリスクに対する警戒を促しています。

(3) 自動化のサポート

無線 LAN コントローラに限らず、元来ネットワーク機器には以下のような特徴があります。

スイッチやルータにカテゴライズされる機器のメモリは数百 MB ~ 数 GB 程度
nice や ionice のようにプロセスの優先度を制御するコマンドが存在しない
通信における中間に位置する機器であるため、有事の際の影響範囲が非常に広い

これらの仕様から、ネットワーク機器における無闇なメモリの使用は控えたほうが良い、というのが通説です。対して、サーバサイドで実行速度を制御出来る CLI を使うことで、ここにある程度の融通が利かせられるようになります。

補足：この通説には近い将来動きがあると予測しています。これはコンテナ技術の普及によって、ユーザに提供するメモリを厳格に制限出来るようになったことが背景です。

加えて、サーバ起点でオペレーションが行えるということは、他サーバとの連携も可能であるということを意味します。実際に我々は監視サーバと連携して一定数のオペレーションを自動化しています、後述でその一部を紹介します。

図5: 監視と連動して設定変更を行うモデル

2. 処理フロー

CLI の処理フローは至って単純です。以下の 3 ステップで完結しています。

AP の帰属する WLC を特定
その WLC に対して所定の CLI のコマンドを発行 (TTY)
コマンドの実行結果をパースして必要な情報を表示

1 つだけ、Act - Act 構成の運用に大事な事前準備を要するのでまずはこちらを紹介します。

事前準備

Act - Act 構成の環境では AP の帰属先 WLC が運用によって変動します。これに順応するため、前もって WLC の SNMP Agent が公開する情報から AP のリストを生成しています。

この処理は以下のワンライナーで実現しています。

$ wlap init wlcapmap -C <SNMP Community Name>

情報収集の対象となる WLC は予め YAML で定義しています。

---
production:
  controllers:
    - WLC1
    - WLC2

SNMP Agent のアクセス先は AIRESPACE-WIRELESS-MIB に含まれる OID: 1.3.6.1.4.1.14179.2.2.1.1.3 (bsnAPName) です。

サンプルの値を snmpwalk で取得してみます。バージョン、コミュニティ名等の引数は $SNMP_OPTIONS でまとめて渡しています。

$ snmpwalk $SNMP_OPTIONS WLC1 1.3.6.1.4.1.14179.2.2.1.1.3
SNMPv2-SMI::enterprises.14179.2.2.1.1.3.0.167.66.226.0.32 = STRING: "AP1"
SNMPv2-SMI::enterprises.14179.2.2.1.1.3.92.90.199.97.218.128 = STRING: "AP3"

$ snmpwalk $SNMP_OPTIONS WLC2 1.3.6.1.4.1.14179.2.2.1.1.3
SNMPv2-SMI::enterprises.14179.2.2.1.1.3.92.90.199.75.186.160 = STRING: "AP2"
SNMPv2-SMI::enterprises.14179.2.2.1.1.3.92.90.199.129.183.224 = STRING: "AP4"

<AP MAC を 10 進数に変換した値> (以下、AP OID) とともに、value として AP のホスト名が取得出来ました。 AIRESPACE-WIRELESS-MIB は、このように <OID>.<AP OID> の配下で値を持つことが特徴です。

ここで取得した AP OID とそのホスト名および帰属先コントローラ情報を、以下のような YAML として保存しています。

---
- host: WLC1
  name: AP1
  apoid: 0.167.66.226.0.32
- host: WLC1
  name: AP3
  apoid: 92.90.199.97.218.128
- host: WLC2
  name: AP2
  apoid: 92.90.199.149.23.64
<snip>

このマップファイルをオペレーションの起点に照会することで、帰属先 WLC を意識しない AP 運用が可能になっています。

続いて、CLI 実行時の処理を見ていきます。

1. AP の帰属する WLC を特定

実際にオペレーションを行う CLI の基本書式は以下のようになっています。

$ wlap <動詞 (init|show|set|exec)> <目的語 (channel|txpower|overview|...)> --hostname <AP ホスト名>

何かしらのコマンドが実行されると、まずは --hostname を元に先のマップで帰属先 WLC を逆引きします。

2. WLC に対して所定のコマンドを発行

次に、逆引きで特定した帰属先 WLC に対して TTY 経由で所定のコマンドを実行し、その結果を取得します。

現在稼働している多くのネットワーク機器は未だ十分なプログラマブルインタフェースを持ちません。このため、情報の取得には TTY + expect を採用しています。例えば、先に紹介した show advanced 802.11a summary の取得は以下のような関数で処理しています。

def show_adv_a_sum(controller, username, password)
    commands = [
      { read: 'Password:',               input: password },
      { read: '\(Cisco Controller\) \>', input: 'config paging disable' },
      { read: '\(Cisco Controller\) \>', input: 'show advanced 802.11a summary' }
    ]
    { management: "ssh #{username}@#{controller}", operation: commands }
  end
end

この実装には、以下のようなメリットも内包しています。

Infrastructure as Code

Chef や Ansible 等と同じく、定義がそのまま操作手順になります。これにより一部の手順書作成は不要になります。
学習コストの低減

CLI のコマンドだけ覚えておけば OS 別にコマンドを学習する必要が無くなります。これは他社製品への乗り換えはもちろん、Cisco 製品における AireOS から IOS-XE への乗り換えでも効果を発揮しています。

3. コマンドの結果をパースして必要な情報を表示

最後に、取得した結果から必要な情報を抽出、フォーマットを調整しつつ標準出力して処理完了です。

show 系コマンドの処理は以上となります。set や exec 系コマンドの場合は、再度 (2) / (3) を繰り返して変更／実行までを実施しています。

3. 自動化への応用

先に紹介している set channel は対話式でしたが、この set 系コマンドにはそれをスキップする --quiet オプションを実装しています。そして、これを監視と連携させることで障害からの復旧をある程度自動化しています。

監視に関する詳細は説明を省きますが、例えば以下のようなケースがこの対象となっています。

1. レーダーによる停波状態からの自動回復

ヒカリエ本社のある渋谷は、西から W53、南東から W56 のレーダーが多く飛来する RF 環境です。AP はこのレーダーを受信すると法規的な仕様に基づき無線の電波を停波し、利用可能な Channel が無ければ最短 30 分間はそのままの状態となります。

図6: レーダーによって電波が停波

これに対する一般的な対策には以下のようなものが挙げられますが、いずれも一長一短です。

カバレッジにローミング用の W52 AP を混ぜ込む手法

レーダー検知時にある程度のカバレッジロスを許容することになります。レーダーの受信頻度が低い、または安定したスループットが不要な RF 環境では最適解と考えています。
RF Profile の Channel List に W52 Channel を混ぜ込む手法

DCA 任せになるので、レーダーを受信していない状況下でもより混雑の激しい W52 が選定する可能性があります。W52 が比較的クリーンな RF 環境では有効な手法と考えています。

DeNA では、通信品質の観点からこれらを採用することが困難でした。このため、別途 Radio ダウン時、周囲の AP と干渉しない W52 Channel に固定化する仮復旧処理 と W53/W56 の Blacklisting 開放後、Channel の固定化を解除する切り戻し処理 を自動で実行しています。

図7: レーダーによって停波した AP #2 の電波伝搬を再開

Hook のトリガーとしている監視は、切り替え時が OID: 1.3.6.1.4.1.14179.2.2.2.1.12 (bsnAPIfOperStatus)、切り戻り時は OID: 1.3.6.1.4.1.14179.2.2.24.1.1 (bsnAPIfRadarDetectedChannelNumber) が返す合計 Channel 数の閾値監視です。

2. クライアント超過状態からの自動回復

無線 LAN の CSMA/CA は半二重通信です。クライアントが増えれば増えるほど通信待ち時間、つまり遅延の発生する可能性が高くなります。

図8: AP #2 のクライアントが超過

これを未然に防ぐため、クライアント接続数が一定数を超えた AP に対して 特定 ESSID に接続する端末を deauth し、再接続を促すことでクライアント数を平準化する処理 を自動で実行しています。

図9: AP #2 のクライアントを分散

Hook のトリガーとしている監視は、OID: 1.3.6.1.4.1.14179.2.2.2.1.15 (bsnApIfNoOfUsers) の閾値監視です。

最後に

以上、ヒカリエ本社を例に Cisco WLC の Act - Act 構成運用手法と関連する自動化を紹介させて頂きました。

無線 LAN はまだまだ発展途上の技術です。2020 年に予定されている 802.11ax の標準化もさることながら、その後も更に変化が続いていくものと予想されています。そして、この需要増とともに品質に対する要求が増加することもまた必然です。我々の持つナレッジが、少しでもより良い無線 LAN 構築、より良い運用環境整備の参考になれば嬉しく思います。

最後までお読み頂きありがとうございました。