2014/10/7 Webcast 'Cisco Unified Wireless Network (CUWN) の技術紹介およびトラブルシューティング' エキスパートに質問

[CiscoJapanModerator]

このエキスパートに質問は2014/10/7に開催した Webcast のスピーカーが担当します。Webcast の内容や Wireless に関することでしたらできる限り回答いたしますので、どうぞご利用ください。

セミナー資料はこちらからダウンロードいただけます。

担当エキスパート: 大崎　秀行(Hideyuki Osaki)

開催期間: 2014年10月8日（水）~2014年10月19日（日）

[質問の投稿方法]

サポートコミュニティへ Cisco.com ID でログインすると、この説明の右下に「返信」ボタンが表示されます。クリックすると投稿欄が表示されますので、質問をご記入ください。最後に「メッセージの投稿」をクリックすると質問が送信され、完了となります。

もし１つの質疑応答が進行していても、他の新しい質問を同じスレッド内に投稿いただいて問題ありません。

エキスパートから返信が得られた質問については、評価機能でその回答が適切であったかをエキスパートへぜひ伝えてください。

[t-maeyama]

担当エキスパート: 大崎さん

CUWNの技術紹介およびトラブルシューティングの講演ありがとうございました。

WLCのDHCP Proxy機能について、質問させて頂きます。

現在、あるユーザでWLCのDHCP Proxyを有効にした場合、一部の無線クライアントでダイナミックVLANが期待通りの動きをしない事象が発生しております。

当該環境ではコンピュータ証明書とユーザー証明書を使用することで、PC起動時のVLANとログイン後のVLANを動的に割り当てております。

一部の無線クライアントにおいて、WLC上ではVLANが切替っているが、クライアントはログイン後もPC起動時の古いIPアドレスを使用し続けているため通信が出来なくなっております。

無線のOFF,ONを行うと、新たにIPアドレスを取得し通信可能になるのですが、ログイン時のDHCP更新に伴うDHCPパケットがDHCPサーバまで届いていない（WLCで止まっている）ようです。

パケットキャプチャの結果、ログイン後にIPアドレスが切替っているクライアントはDHCPパケットの宛先IPアドレスがブロードキャストで、ログイン後も古いIPアドレスを使い続けるクライアントはDHCPパケットの宛先IPアドレスがユニキャスト（WLCのアドレス）でした。

仕様として、WLCのDHCP Proxyを有効にした場合、ユニキャストのパケットは、DHCPサーバに転送しないのでしょうか？

また、似たような事例は御座いますでしょうか？

コントローラ：AIR-CT5508-12-K9（Release:  7.4.121.0）

アクセスポイント：AIR-CAP3602I-Q-K9（Release:  15.2）

認証サーバ：CSACS-5.4-VM-K9（Release:  5.4.0.46.0）

以上、よろしくお願いします。

[Hideyuki Osaki]

Maeyama 様

この度はご参加いただき、誠にありがとうございました。

> ログイン時のDHCP更新に伴うDHCPパケットがDHCPサーバまで届いていない（WLCで止まっている）ようです。

なるほど、これが原因のようですね。

結論から申し上げると、dhcp proxy を disable とするしか回避策は無い可能性があります。

まず、そのアドレス更新に失敗するクライアントは、なぜ WLC  のアドレスを宛先にして DHCP DISCOVER をしているのだろうか？という疑問がまず浮かびました。

WLC は DHCP Proxy Enabled の場合は DHCP OFFER の siaddr を Virtual IP (VIP) で置き換えるという動作をすることを私は経験上知っていましたので、そこを読み取ったクライアントが、VIP へ DHCP を投げてしまっているのではないか、と考えました。

そして色々と調べてみた結果、弊社でも次のように過去に DHCP の挙動について話し合ったことがあることがわかりました。

CSCsx75726    WLC DHCP proxy changes siaddr to virtual IP address in DHCP offer

siaddr は、RFC 1542 によればリレーエージェントが書き換えてはいけないとなっています。

また、そもそもの RFC 2131 によれば、クライアントは siaddr を使って DHCP パケットの送信先を決めるとなっています。

つまり WLC は DHCP Proxy Enable の場合は RFC2131/1542 に準拠しない動き(siaddr を VIP で書き換える)をしています。DHCP Proxy Enable ≠ DHCP Relay Agent (RFC 準拠) なのです。

そして前述の議論の中で、DHCP Proxy Enable の場合は RFC 非準拠の独自動作で動くことが、WLC 製品設計上は期待される動作であり、RFC 2131 等に準拠させたい場合は DHCP Proxy を Disable にする必要があると結論付けていました。なお準拠している状態を DHCP Bridge モードが有効である、と呼んでおります。

更新に失敗するクライアントについては、RFC 2131 に準拠した動作のみを受け付けるように動作しているのではないかと思います。

以上、RFC を読み解いて推察してみましたが、DHCP Proxy を Disable とした状態で、問題が解消されるか試してみていただけますでしょうか。

もしそれで解決しない場合は、お手数ですが TAC へ SR をご申請ください。

よろしくお願いいたします。

[hiroshi.yamashita]

大崎様

先日はセミナーの講演ありがとうございました。

セミナーの中でCleanAir Expressについて、

「追跡できる干渉源は１Radioあたり3つまで」

という制限がありましたが、干渉源を検知する数には制限はないのでしょうか？

「追跡できる」という部分が具体的に想像できませんでしたので、

ご確認させていただければと思います。

[Hideyuki Osaki]

山下 様

この度はご参加いただき、ありがとうございました。

CleanAir チップの基本的な動作として、検知して識別できる干渉源の数には制限はありません。（もちろん瞬間的なメモリの残量等の制限はありますが）

そのたくさん検知した干渉源の中から、特にシビラティ（影響度）の高い、対処を必要とするような干渉源について、WLC へ CAPWAP 経由で IDR という形式で定期報告をしています。ここで報告に上げる数が、AP1600/1700 の場合は 3つなのです。3700 等上位機種は一度に 10個の報告をあげます。

また、ユーザ側でシビラティに関係無く SECURITY TYPE に指定した干渉源については、検出された場合は常にこの定期 IDR レポートに含まれますので、SECURITY TYPE が3つ指定されていれば、AP1600/1700 はそれだけで上限に到達してしまい、他の影響度の高い干渉源を報告することができませんね。

なお、干渉源のタイムライン的な履歴 + 検出位置情報を管理するのは MSE の仕事ですので、その意味での「追跡」はまた異なった意味になってきます。

[hiroshi.yamashita]

ご回答ありがとうございます。

WLCに一度に報告できる干渉源の数が3つという事で了解いたしました。

[torukimura]

大崎様

クライアントをAPに接続、切断した際に bsnDot11StationAssociate と bsnDot11StationDisassociate

以外に以下のSNMP Trapを受信します。　ＯＳ　7.6.130.0

MIBファイル「CISCO-LWAPP-DOT11-CLIENT-MIB」に定義がされておらず

Trap内容の詳細が不明なため、内容を教えていただけますでしょうか。

enterprises.9.9.599.0.4;　　　　　←Associate時のTrapで合っておりますでしょうか？
enterprises.9.9.599.1.3.1.1.28.0='SSID-1',　　　　　←SSID名
enterprises.9.9.599.1.3.1.1.27.0='test01@test.co.jp',　　　　　←ユーザ名
enterprises.9.9.599.1.3.1.1.10.0='172.24.1.1',　　　　　←クライアントIPアドレス
enterprises.9.9.513.1.2.1.1.1.0='0',　　　　　←？
enterprises.9.9.599.1.3.1.1.8.0='50 67 AE AA AA AA',　　　　　←APのMACアドレス
enterprises.9.9.513.1.1.1.1.5.0='AP01',　　　　　←AP名
enterprises.9.9.599.1.3.1.1.1.0='BB BB BB BB BB BB',　　　　　←クライアントのMACアドレス
sysUpTimeInstance='1:2:15:38.00'　　　　　←WLC or APのUpタイムどちらでしょうか？
 
 
enterprises.9.9.599.0.6;　　　　　←Disassociate時のTrapで合っておりますでしょうか。
enterprises.9.9.599.1.4.1.1.28.164.78.49.215.25.72='116253',　　　　　←？
enterprises.9.9.599.1.4.1.1.27.164.78.49.215.25.72='1177',　　　　　←？
enterprises.9.9.599.1.4.1.1.26.164.78.49.215.25.72='249357',　　　　　←？
enterprises.9.9.599.1.4.1.1.25.164.78.49.215.25.72='800',　　　　　←？
enterprises.9.9.599.1.3.1.1.38.164.78.49.215.25.72='54378d9b/bb:bb:bb:bb:bb:bb/19',　←クライアントのMACアドレス
enterprises.9.9.599.1.3.1.1.28.164.78.49.215.25.72='SSID-1',　　　　　←SSID名
enterprises.9.9.599.1.3.1.1.27.164.78.49.215.25.72='test01@test.co.jp',　　　　　←ユーザ名
enterprises.9.9.599.1.3.1.1.37.164.78.49.215.25.72='1',　　　　　←？
enterprises.9.9.599.1.3.1.1.8.164.78.49.215.25.72='50 67 AE AA AA AA',　　　　　←APのMACアドレス
enterprises.9.9.599.1.3.2.1.3.0='AC 18 96 15',　　　　　←？
enterprises.9.9.599.1.3.2.1.2.0='1',　　　　　←？
enterprises.9.9.513.1.2.1.1.1.0='0',　　　　　←？
enterprises.9.9.513.1.1.1.1.5.80.103.174.65.170.64='AP01',　　　　　←AP名
sysUpTimeInstance='1:2:15:54.00'　　　　　←WLC or APのUpタイムどちらでしょうか？

 
  以上、よろしくお願いいたします。

[CiscoJapanModerator]

ご質問ありがとうございます。
ご質問の内容について大崎とも相談したのですが、この場ですぐに回答することが難しく
どうしても内部調査が必須となります。

ご期待に沿えず申し訳ないのですが、別途この件に関しましてはService Request でのご対応とさせていただけますでしょうか。
どうぞよろしくお願いいたします。

サポートコミュニティ　岩波
 

[torukimura]

ご返信ありがとうございます。

別途、Service Request をオープンさせていただきます。

[yrz462]

担当エキスパート: 大崎様

いつもお世話になっております。

capwap ap primary-baseコマンドにつきまして、

AP設定の High Availability設定として書き込むコマンドでもあると認識していますが、

先日、新品の AP2700 に対して設定したところ、確かに初回は JOINできるのですが、

その後イメージアップグレードした後の再起動によって、

この設定が失われているような状況で、次回JOINできなくなる事象が発生しました。

色々と検証した結果、新品のリカバリイメージ起動の場合に発生し、

リカバリイメージ起動ではない通常イメージの場合（使い回しの検証機）では、

アップグレードが発生しても、次回起動時は High Availability設定が残っているようで、

JOINできることの切り分けは試しました。

周りでも上手くJOINしない話を聞いており、これが原因かなと思いましたが、

結局、capwap ap controller ip addressコマンドを併用した方がいいように思い始めていますが、

このような事象の話は聞いていますでしょうか。

よろしくお願いします。

[Hideyuki Osaki]

こんにちは、お世話になっております。

それは「変」ですね。なんらかの不具合動作が絡んでるとしか思えません。

primary-base コマンドのみで priming できるのが仕様動作です。

少し既知のソフトウェア不具合を探してみましたが、ぴったり当てはまるものは見つかりませんでした。

AP2700 特有の不具合として、次のものがあります。

CSCup57618    2700 series AP send DHCP request with AUX MAC address on recovery image

これは、AP2700 は二つポートを持っているのですが、そのうち AUX ポートと呼ばれるポートの MAC アドレスを使って、DHCP Request/Discover をしてしまうという問題です。この結果 AP2700 はアドレスを取得できず、CAPWAP Discovery ができない、ということがあります。

これ以外ですとちょっと見当たりませんので、サービスリクエストをご申請いただくことをご検討ください。

以上、よろしくお願いいたします。

[yrz462]

担当エキスパート: 大崎様

いつもお世話になっております。

FlexConnect Local Switching構成において、ブロードキャスト通信の流れを確認したところ、
送信元が有線・無線端末に関わらず、1つのブロードキャストが同一セグメント内にある
全ての APから送信されていることを確認しました。

ブロードキャストは、最も高い Manadtoryレートで送信されるけれど、OFDM 54Mbpsレートよりも遅く、
同一セグメント上での大規模な Local Switching構成、つまり、AP台数や Client台数が多いと、
大量に発生するかもしれないブロードキャストで AirTime Utilizationの上昇につながる懸念を抱きました。

これら勝手に送信されるブロードキャストやマルチキャストは、一般的には軽微と考えていいのか、
今後は注意すべきことなのか、Voiceが含まれる場合は NGの構成なのか、
または、Local Switching構成で、同一セグメント上の AP/Client台数に上限目安を持った方がいいのか、
Converged Accessモデルでは影響ないのか、これら含め、いろいろアドバイス頂きたくよろしくお願いします

[Hideyuki Osaki]

こんにちは、お世話になっております。

ご懸念はごもっともです。ブロードキャスト、マルチキャストを利用したクライアントの通信は、ご認識のとおり数多く存在します。プラグアンドプレイによるデバイス検出や IPv6, DHCPv6 の通信等はよくある話です。もしそれらのサービスを全く使っていないのに、無線で送信しているということであれば、帯域が無駄になっているとも言えます。これは有線無線関わらず同じことが言えると思いますが、必要なものだけを残して、そもそも不要なブロードキャストの発生を GPO 等で制限しておくというのは IT 管理の面からも考慮しておくべきと考えます。

この影響が軽微かどうかは、残念ながら知見がありません。ユーザ数やクライアントの実装にも依存するところが大きいと思いますので、統一的な指針を出すのもなかなか難しいのではと思います。

Voice を使う場合は、CAC を併用すると思いますが、ローミングする場合にもローミング用の帯域を確保しておく必要がありますので、帯域が空いていればいるほど良いというのは当然です。どれだけ圧迫しているか、というのは実測を基に考えるのが現実的だと思います。

インフラ側でできる対策としては、次のようなものが考えられます。

• AP 接続スイッチのアップリンクポートで HSRP/OSPF 等を ACL でフィルタする
• BPDU をスイッチポートでフィルタする
• AP で ACL をかけて不要なプロトコルをフィルタする
• リンクローカル以外の通常の Multicast 通信については、IGMP snooping を有効にする。AP は IGMP Report の出ていない無線空間にはマルチキャストストリームを転送しません。FlexConnect Local Switching でも Videostream 機能が使えるようになりましたね。

以上、よろしくお願いいたします。