タグ付けされた質問 「aironet」

RADIUSサーバーを使用して、ユーザーごとに構成済みのSSIDへのアクセスを制限したいと思います。 上記のリンクされたドキュメントによると、テストユーザーに次の属性を追加します。 ospite-5vh Cisco-AVPair + = "ssid = Interactive_Ospiti" したがって、デバッグRADIUS認証を有効にすると、次のようになります。 6月12日08：30：08.266：RADIUS（00001A96）：212.183.164.38:1812 id 1645/128にアクセス要求を送信、len 177 6月12日08：30：08.266：RADIUS：オーセンティケーターCC C9 63 16 B0 62 74 52-A7 95 DF 1D 93 F3 08 37 6月12日08：30：08.267：RADIUS：ユーザー名[1] 12 "ospite-5vh" 6月12日08：30：08.267：RADIUS：Framed-MTU [12] 6 1400 6月12日08：30：08.267：RADIUS：Called-Station-Id [30] 16 "8478.acf0.9002" 6月12日08：30：08.267：RADIUS：Calling-Station-Id [31] 16 "2064.3267.44ca" 6月12日08：30：08.267：RADIUS：ベンダー、シスコ[26] 29 6月12日08：30：08.267：RADIUS：Cisco AVpair [1] 23 …

10 cisco  wireless  aironet  radius 

2つのCisco 2602E APと1つのCisco 3602E APが中国のある場所に配備されています。これらは、HP ProCurve 2910al PoEスイッチに接続されています。 スイッチを再起動すると3602Eは正常に起動します（つまり、停電、この都市では停電が発生します）が、2602E APはどちらも、電源を入れる前に誰かがモードボタンを押す必要があります。 モードボタンを押す前は、HPスイッチはポートにデバイスを表示しておらず、ポートに電力が供給されていません。APにはLEDアクティビティがなく、消灯しています。誰かがモードボタンを押すと、不思議なことに電源が入ります。HPスイッチに消費電力が表示され、LEDが点灯します。 それらへのケーブル配線は約200フィートです。スイッチはPoE +であるため、遠方での損失に対応できる十分なワット数があります。3602は実行時間が短く、問題はありません。 同じセットアップの中国に2番目の施設があり、この問題はありません。すべてのAPはモデルごとに同じブートローダーとIOSを持っています（つまり、各サイトの2602Eは同じブートローダーとIOSリビジョンを持っています）。 これと同じ問題は、Cisco 3560C PoE +スイッチと既存のケーブル設定を使用する場合にも発生します。 これは中国にあるため、現在のところトラブルシューティングの能力は少し制限されています。私は誰かが同様の問題を経験し、私を正しい方向に向けることができることを望んでいます。モードボタンを押すためにAPに到達するためにエレベーターを必要とする工場の天井にAPが取り付けられていなかった場合、これはそれほど大きな問題ではありません。 2602Eがスイッチで起動しない原因は何ですか？

9 cisco  wireless  hp-procurve  aironet  cisco-wireless 

シスコのアクセスポイントAIR-CAP1552Eを使用して、WiFi、802.11a / n（5 GHz）経由で建物を接続しています。通常、これらは垂直に取り付けられ、3つの3つの全方向性アンテナが下部にあります。ここで、非常に小さな建物の屋上にある1つのAPを検討し、はるかに高い建物に接続します。 私が作った写真のようにAPをある程度上げることは有益ですか、またはアンテナの角度が直立している他のAPと一致しない場合、WiFi品質を低下させますか？

9 cisco  ieee-802.11  aironet 

現在、7.0.240.0を実行しているWLC 4404があります。管理インターフェイスIPは10.128.55.10です。AP管理インターフェイスは10.128.55.15です。リモート施設（施設A）には、ワイヤレス（455）用に作成されたVLANと、IP 10.133.55.2で作成されたVLAN 455インターフェイスがあります。リモートスイッチ（スイッチB）のポートがVLAN 455に追加され、APがこれらのポートにパッチされています。APは、ローカル施設（施設B）に物理的に配置されているこのVLAN（10.133.55.0 / 24）用に特別に作成されたDHCPスコープを介してIPアドレスを受信して​​います。APは、このDHCPスコープからIPを正常に受信しています。このスイッチは、同じ建物内のスイッチAにトランクされます。スイッチAには、IP 10.133.55.1で構成されたVLAN 455インターフェイスがあります。このトランクポートではVLAN 455が許可されています。 リモートスイッチ（AとBの両方）から、VLAN 455インターフェイス（10.133.55.1、および10.133.55.2）からAP管理インターフェイス（10.128.55.15）にpingを正常に送信できます。ただし、同じVLAN 455インターフェイスから管理インターフェイス（10.128.55.10）にpingを正常に送信できません。 今日Cisco TACで6.5​​時間作業した後、私のワイヤレスコントローラーは所有されていると言われています。私はまだ超自然現象を合理的な説明として受け入れる準備ができていません。誰かが助けてくれることを期待していました！ 更新 既知の良好なAPをリモートファシリティまで降ろして、それを正しいVLANで起動し、正しいIPを受信して​​、コントローラに参加させます。機能していないAPの1つを持ち帰り、ここに接続しました。APは、IOSを15.2（2）JBから12.4（23c）JA7にダウングレードした後、コントローラに参加しました。リモートロケーションにあるAPは、ここでコントローラに接続して、正しいバージョンのIOSをインストールできる必要がありますか？それとも、リモートの場所にインストールする前に、初期構成のためにすべてをここに持ってくる必要がありますか？ 更新 APが通信するための回避策を見つけました。シスコは、これがMicrosoftの問題であり、オプション43を適切に押し出していないと述べています。また、MPLSをリモートサイトに移動するときにMTUの問題は発生しないとも述べています。ここでは、リモートAPのDHCPスコープを無効にし、リモートスイッチ（ios）をDHCPサーバーとして構成し、オプション43が10進数ではなく16進数を使用してコントローラーをポイントするようにしました。APに接続されたインターフェイスでシャットダウン/非シャットダウンを実行すると、スイッチからIPを取得してコントローラーに参加しました。参加したら、スイッチからDHCPを削除し、DHCPサーバーでスコープを再度有効にしました。APを再度バウンスし、アドレスをプルしてコントローラに参加しました。解決策ではありませんが、少なくともそれらは稼働しています。

7 cisco  wireless  ieee-802.11  aironet