Cisco IOS リリース 12.4(24)YG2 向け Cisco ブロー ドバンド ワイヤレス ゲートウェイ リリース 2.2
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月14日
章のタイトル： Cisco ブロードバンド ワイヤレス ゲートウェ イの構成
Cisco ブロードバンド ワイヤレス ゲートウェイの構成
このフィーチャ モジュールでは、Cisco ブロードバンド ワイヤレス ゲートウェイ（BWG）の機能セットについて説明します。また、これらの機能を設定する方法について説明し、設定の例を適宜示します。
–
「イーサネット CS：R6 でデータとコントロールの両方」
• 「CPE 管理」
– 「IP CS」
• 「EAP 認証」
– 「認証の設定」
– 「サービス フローから DiffServ クラスへのマッピング」
– 「BWG から Attachment Response の遅延」
• 「AAA Accounting Start-Stop-Interim」
• 「AAA パケット オブ ディスコネクト メッセージ（PoD）」
• 「AAA ベースの固定 IP アドレスのプロビジョニング」
• 「ハンドオフ」
– 「BWG セッション冗長性とハイ アベイラビリティ インフラストラクチャ」
– 「加入者管理」
– 「認証」
– 「QoS」
– 「制限事項」
– 「動作モード」
– 「Cisco IOS SLB のロード バランシング設定」
• 「合法的傍受」
• 「制約事項」
– 「PMIP Authenticated Network Identifier（PANI）」
リリース 2.2 の新機能
リリース 2.2 では、次の機能が追加されました。これらは、メインの機能リストで相互参照にもなっています。
• Network Access Identifier（NAI）としての PMIP Authenticated Network Identifier（PANI）
• ローカル設定または AAA サーバから DNS およびデフォルト ゲートウェイ設定を送信するための PMIP DHCP プロキシ サポート
リリース 2.0 の新機能
リリース 2.0 では、次の機能が追加されました。これらは、メインの機能リストで相互参照にもなっています。
• 「プロキシ モバイル IP」 のサポート
• 「AAA パケット オブ ディスコネクト メッセージ（PoD）」
• 「AAA ベースの固定 IP アドレスのプロビジョニング」
• 「合法的傍受」
イーサネット コンバージェンス サブレイヤ（CS）
Wimax イーサネット Convergence Sublayer（CS; コンバージェンス サブレイヤ）を使用すると、WiMAX ネットワークでイーサネット サービスをお客様に直接提供できます。IP CS と比較した場合、イーサネット CS では IEEE 802.3 フレーム（上位レイヤの IP データグラムを伝送する）を 802.16 PDU でカプセル化できます。Cisco BWG 1.1 リリースでは、BS ローカル スイッチ（企業カスタマーの場合）と L2-L3 ブリッジング コンバージョン（ホームカスタマーの場合）というイーサネット CS の 2 つのオプションのみが実装されています。
イーサネット CS の要件として、BWG では Customer Premises Equipment（CPE; 顧客宅内機器）/MS/ホストに静的に割り当てられた IP アドレスをサポートします。BWG の次のサブ機能が含まれます。
• 加入者/CPE あたり最大数（8）のアクティブ ホストを強制使用します。
• ARP またはホストからのアップリンク パケットを通じて、ホストの L2/L3 の詳細を自動学習します。
• AAA からの Framed-Route による静的ホスト IP 検証
イーサネット CS：R6 コントロールのみ
Cisco 12.4(15)XL1 リリースでは、BWG と Base Station（BS; ベース ステーション）との間で WiMAX R6 インターフェイスがシグナリング目的のみで使用されます。BWG はトラフィックをローカルでスイッチするように BS に指示します。Generic Routing Encapsulation（GRE; 総称ルーティング カプセル化）によるカプセル化を行わないと、BWG は BS からのベアラ トラフィックを受信しません。ただし BS はイーサネット フレームを外部に接続されている L2 スイッチに切り替えまたは転送する必要があります。
（注） R6 コントロール プレーン専用の機能は、Cisco BWG R1.1 リリースのイーサネット CS のみで使用してください。
この設定ではデータ パケットが BWG を通過しなくなるため、BWG には次の調整が必要です。
• セッション アイドル タイマー：BWG は、パケットを受信しない場合や加入者に送信しない場合であっても、セッションが開いたままであるようにする必要があります。
• AAA でセッション タイマーが 0 に設定されている場合、無限であることを意味します。
• アカウンティング：BWG では、「Accounting Start」と「Accounting Stop」のみを実行します。これらはサービス フローの作成と削除に対応します。定期的な中間アカウンティング アップデートは実行されません。この場合、BWG はベアラ トラフィックを受信しないためです。
BWG が BS から登録解除要求を受信しない場合、ハングしているセッションを取り除くために、絶対セッション タイマーを使用して BWG 上の MS が登録解除されます。
R6 コントロール専用の機能におけるイベントのシーケンスを次の手順に示します。
ステップ 1 SS は登録メッセージを BS に送信します。BS は登録メッセージを BWG に転送します。
ステップ 2 BWG は user_name が「MSID@プロキシレルム」であるプロファイルを AAA サーバに要求します。プロキシレルムは、ユーザ グループで設定されます。
ステップ 3 AAA は、次の情報とともに SLA プロファイルを送り返します。
– SS は、SLA プロファイルに基づいて、ビジネスとして識別されます（BWG で encap-type none として設定）。この場合、そのトラフィックは BS でローカルにスイッチされ、エンタープライズとして識別されます。
– VLAN ID（同じ BS に接続するビジネス SS ごとに一意）。たとえば VLAN ID = 250 です。
ステップ 4 BWG はサービス フロー プロファイル情報を VLAN ID およびパケット分類ルールとともに BS に送信します。さらにアップリンク パケット分類ルールを SS に送信します。
ステップ 5 アップストリーム トラフィックが開始されます。たとえば CPE ルータがアップリンク .1q タグ付きトラフィックを次の VLAN で送信するとします。
ステップ 6 SS が VLAN 10 からのトラフィックをサービス フロー 1 に送るように PCR が設定されている場合、このサービス フローのタイプは BE です。SS が VLAN 20 からのトラフィックをサービス フロー 2 に送るように PCR が設定されている場合、このサービス フローのタイプは UGS です。SS はトラフィックを BS に送信します。
ステップ 7 BS は別の .1q タグをエンタープライズ x の着信トラフィック（たとえば VLAN ID = 250）に割り当てます。内部タグは変更されません。トラフィックは L2 ネットワークへスイッチされ、BWG へは転送されません。
ステップ 8 ダウンストリーム トラフィックの場合は、次のようになります。
– BS は L2 スイッチド ネットワークからトラフィックを受信します。
– エンタープライズ トラフィックは BWG を通過しません。
– PCR は、送信された SF トラフィックについて BS に通知します。
– BS は外部タグをすべて取り除き、残りのパケット トラフィックを SF1（BE）または SF2（UGS）として無線で転送します。
ステップ 9 SS はトラフィックを受信して、スイッチに転送します。内部タグは変更されません。
また、このシナリオでは BWG ではなく BS がアップリンク/ダウンリンク サービス フローを終了します。BWG はダウンリンク分類子を BS に送信して、BS がパケットの適切なダウンリンク サービス フローを選択できるようにします。BS は、ダウンリンク分類子で 802.16e エアーリンク接続 ID/サービス フローを選択する必要があります。また、BWG はアップリンク トラフィックに使用する VLAN タグを BS に通知します。
BWG の設計にはフロー単位で BS ローカル スイッチングを実行できる柔軟性がありますが、リリース 1.1 では、すべてのサービス フローがすべてを BS ローカルでスイッチするのか、または特定の加入者に対して BWG でスイッチするのか設定されている必要があります。
R6 コントロール専用の設定
この項では、Cisco BWG で R6 コントロール専用機能を設定する方法について説明します。R6 コントロール専用を有効にするには、次の作業を行います。
（注） BWG リリース 1.1 では、VLAN が同じ場合は同じ SLA プロファイルで設定しなければなりません。
（注） VLAN が AAA からダウンロードされると、すべてのサービス フローでローカルに設定された VLAN がその VLAN で上書きされます。
BWG は、R6 DP 登録要求メッセージのデータ パスの暗号化タイプ（NONE）とデータ パス ID（プライオリティ + VLAN ID）を使用して、BS のローカル スイッチングを制御します。ここで定義されている VLAN ID は、AAA から上書きされる可能性があることに注意してください。VLAN プライオリティ（VLAN タグで最上位 3 ビット）は、サービス フローに定義された DSCP/優先度が使用されます。DSCP/優先度がローカルで定義されていない場合は、サービス フローに使用される WiMAX QoS データ デリバリ サービス タイプを基に計算されます。
イーサネット CS：R6 でデータとコントロールの両方
WiMAX Forum の NWG 規格に合わせるため、Cisco の R6 インターフェイスではデータとコントロールでイーサネット CS をサポートします。前述のとおり、このリリースでは、BWG の L2-L3 ブリッジング オプションのみがサポートされています。
L2 アップリンク トラフィックは CPE/MS の背後にあるホストから送られます。パケットは 802.16 PDU でカプセル化され、R1 インターフェイスを介して CPE によって BS に送信されます。BS はイーサネット フレームを GRE パケットにカプセル化し（GRE トンネルは R6 シグナリング交換時に確立されている）、BWG に送信します。BWG は、R6 データ パスを介して GRE パケットを受信します。GRE ヘッダーと L2 ヘッダーが取り除かれたら、内側の IP パケットが目的の VRF で設定された適切なインターフェイスに転送されます。
BWG は、ダウンリンク パケットを受信すると、特定ホストに関する L2 情報が保存されているホストを探します。L2 情報は、パケットで伝送される L3 情報とともに、設定された分類子と比較するために使用されます。その結果、適切なサービス フローが選択されます。サービス フローが選択されると、保存されているホストの L2 情報を使用して、受信した IP パケットがカプセル化されます。
L2-L3 ブリッジングの VLAN - VRF マッピング
この機能では、特定の VLAN ID を持つアップリンク L2 トラフィックが VRF ルーティング ドメインにマッピングして、IP パケットを転送できます。一方、特定の VRF からのダウンリンク IP トラフィックは、同じ VLAN ID でカプセル化された MS に送信されます。MS の背後にあるホストごとに多くても 1 つの VLAN ID をサポートするように設計されていることに注意してください。
パケット フラグメンテーションの処理
BWG 上のバーチャル テンプレート インターフェイスは、R6 データ パスで GRE フラグメンテーションが不要になるような MTU を使用して設定される必要があります。推奨される MTU 値は 1440 未満です。
バーチャル テンプレート インターフェイス用に設定された MTU よりも大きいダウンリンク パケットの場合、IOS によってパケットが断片化されます。このとき、IOS は元のパケットの DF ビットをクリアすることが予想されます。その場合、BWG は 2 つの IP パケットを受信します。2 つの IP パケットは別々に GRE でカプセル化されて、BS に送信されます。BS は、2 つのパケットを構成してアプリケーションに渡すホストに対して、これらのパケットを透過的に渡します。
大規模なアップリンク パケットの場合、BS は DF ビットをクリアし、2 つのパケットに分割して BWG に送信します。BWG はパケットを再構成しませんが、別々に転送します。
ジャンボ フレームのサポート
この機能では、BWG がペイロードで最大 2000 バイトのジャンボ フレームをサポートできます。これまでは、1500 バイトがパケット断片化の上限でした。この機能により Maximum Transfer Unit（MTU; 最大伝送ユニット）は 2000 に高まります。
• BWG アプリケーションの mtu は 2000 に設定されています。バーチャル テンプレート インターフェイスで設定することにより、mtu の設定を変更できます。しかしバーチャル アクセス インターフェイスに反映されるのは BWG に対して 2000 です。
• バーチャル テンプレート インターフェイスにおいてデフォルトの mtu と ip mtu はそれぞれ 2000 と 1500 です。そのため、どちらも BWG の起動時に設定されていないと、running-config のバーチャル テンプレート インターフェイスの設定は次のようになります。
• mtu が設定されると、ip mtu は mtu 以下に設定でき、バーチャル アクセス インターフェイスで動的に反映されます。
no ip mtu により、バーチャル アクセス インターフェイスの ip mtu は mtu（2000）に設定されます。ip mtu に他の値を設定する場合は、バーチャル テンプレート インターフェイスで明示的に設定する必要があります。
DHCP Option 82 機能拡張
BWG がダウンリンク DHCP パケットの L2 ヘッダーを構成できるように、L2 ヘッダー全体が Option 82 内にコーディングされます。Option 82 は、DHCP サーバから反映されます。このサブオプションは、BWG と DHCP サーバとの間のみに適用されます。
DSCP の計算/マーキング/シグナリング
ダウンリンク トラフィックの場合、DSCP マーキングが BWG によって実行されます。外側 IP の DSCP 値は、優先度順に次から取得されます。
• SF のデータ デリバリ サービス タイプから計算（次表）
|
|
|
|
（注） 内側 IP の DSCP 値は、外側 IP の DSCP をマーキングするために使用できなくなりました。
（注） SF QoS から DSCP のマッピング テーブルは、DSCP が SF 向けに設定されていないときのみ使用されます。
アップリンク トラフィックの場合、BWG はダウンリンク サービス フローと同様の方法で DSCP 値を取得します。アップリンク DSCP 値は、データ パス情報 TLV で BS に通知されます。
内側のユーザ（アップリンク）パケットの DSCP マーキングは信頼できないことに注意してください。そのため、サービス フローについて BS に通知される同じアップリンク DSCP 値も R3 アップリンク パケットを再マーク付けするために使用されます。
DSCP マーキング
リリース 2.0 では、次の 2 つの方法で、BWG で外側 IP の DSCP 値をダウンリンク データ トラフィック用にマーキングできます。
• ダウンリンクのサービスフロー プロファイルで指定された DSCP 値を使用する
router(config-gw-sf-dir)#set dscp value
• インバウンド R3 IP パケットの DSCP 値を使用する
router(config-gw-sf-dir)#set dscp r3
次の 3 つの方法で、BWG で R3 IP の DSCP 値をアップリンク データ トラフィック用にマーキングできます。
router(config-gw-sf-dir)#set r3 dscp r6-outer
イーサネット フレームのサポート
BWG では、異なるホストに対して Ethernet II、LLC（802.2）、Ethernet SNAP フレーム タイプに対応できます。ただし、1 つのホストはセッション中に同じフレーム タイプを使用する必要があります。つまり、そのホストは同じイーサネット フレーム タイプを使用した場合のみ、パケットを送信できます。
イーサネット VLAN のサポート
イーサネット FCS（CRC）
制限事項
Cisco BWG リリース 1.1 以上では、CS イーサネットに次のような制限があります。
• ARP と DHCP 以外の MS から送信されるレイヤ 2 ブロードキャスト/マルチキャスト パケットは、BWG でドロップされます。
WiMAX NWG 仕様（1.2.2）への準拠
BWG では、Cisco R6 と NWG 仕様の両方を同時にサポートします。この機能を使用するに当たって、特別な設定は必要ありません。BWG はメッセージ ヘッダーの「Version」フィールドを使用して Cisco R6 と NWG R6 を区別します。この区別は、BWG の登録者単位で行われます。セッションの最初の WiMAX R6 メッセージの Version が 1 の場合、NWG R6 として指定されます。同様に、最初のメッセージで Version が 0x81 の場合は、Cisco R6 です。セッションではそのライフ スパンを通じて同種の R6 を使用する必要があります（ハンドオーバーを除く）。
L2-L2 ブリッジング
リリース 2.2 以降の BWG では L2-L2 ブリッジングをサポートします。BWG で L2-L2 ブリッジングを設定するには、IOS の Integrated Routing and Bridging（IRB）機能に関する知識が必要です。
L2-L3 ブリッジングに比べて L2-L2 ブリッジングでは、BWG でイーサネット CS パケットをそのまま通過させることができます。
L2-L2 ブリッジングは、ユーザ グループごとに個別にイネーブルです。L2-L2 機能があるユーザ グループに対してイネーブルの場合、そのユーザ グループに対して L2-L3 機能は自動的にディセーブルになります。
Wimax ユーザ グループでブリッジングをイネーブルにするには、グループをブリッジ グループに追加しておく必要があります。ユーザ グループがブリッジ グループに追加されると、仮想 Wimax インターフェイス（Wimax<bridge-group>）が作成されます。この仮想 Wimax インターフェイスは、ブリッジ グループ内のユーザ グループを表します。複数のユーザ グループを同一のブリッジ グループには追加できません。
ブリッジ グループを作成するには、 bridge-group コマンドを使用します。
イーサネット IP ホスト
イーサネット IP ホストでは、パススルー ARP パケットまたは他のアップリンク データ パケットに基づいて、BWG ホスト エントリが作成されます。ホストの IP アドレスは、BWG 内にある加入者のホスト エントリ テーブルに収集されます。
MS またはホストに送信される ARP パケットは、BWG（プロキシ ARP）によって応答されます。Wimax に送信される ARP パケット以外のパケット （ダウンリンク ブロードキャストまたはマルチキャスト L2 パケットなど）はドロップされます。
BWG は、ホストで生成される DHCP 要求に対してレイヤ 2 DHCP リレー エージェントとして動作します。BWG は、circuit-id および remote-id を含む DHCP Option 82 をアップストリーム DHCP パケットに追加します。ただしブリッジングでは、BWG にレイヤ 3 ネットワーク ID がないため、giaddr フィールドが設定されません。
PPPoE ホスト
PPPoE ホストでは、BWG は PPPoE Discovery（シグナリング）パケットを代行受信します。代行受信されるパケットは次のとおりです。
• PPPoE Active Discovery Initiation（PADI）
• PPPoE Active Discovery Offer（PADO）
• PPPoE Active Discovery Request（PADR）
• PPPoE Active Discovery Session-confirmation（PADS）
• PPPoE Active Discovery Terminate（PADT）
PADS に対応する BWG ホスト エントリは、BWG がネットワークからクライアントに送信された PADS を検出した後で作成されます。
加入者ごとに最大で 20 の PPP0E ホストを作成できます。新しいホストが受け入れられるのは、少なくとも 1 つの既存ホストのアイドル期間がしきい値を超えた場合のみです。アイドル時間が最も長かったホストが新しいホストに置き換わります。ホストのアイドルしきい値は、セッション アイドル タイマーの 75% です。
BWG では、ベンダー固有タグとリレー セッション ID タグも各 PADI および PADR パケットに追加します。ベンダー固有タグには、回線 ID（SF ID）およびリモート ID（MSID）サブオプションがあります。リレー セッション ID タグは、SFID を挿入するときに使用されます。BWG ではこれらのタグを PADO および PADS パケットから削除してから、PPPoE クライアントに転送します。
透過 VLAN
L2-L2 ブリッジングを使用すると、BWG では L2VPN を設定できます。
エンタープライズで L2VPN 機能をイネーブルにするために、BWG は ARP、DHCP、PPPoE の代理受信機能をディセーブルにし、アップリンクおよびダウンリンク方向で変更なしですべての L2 パケットをパススルーできるようにします。ARP、DHCP、PPPoE の代理受信機能がディセーブルになると、BWG は ARP プロキシ機能を実行できないため、ホスト情報を学習できません。そのため、BWG では、パケットが CPE からのものなのか、その背後にあるホストからのものなのかを特定できません。
VLAN ID とブリッジ グループの組み合わせは、BWG コンテキスト内の加入者ごとに一意でなければなりません。モバイル環境では、MS のモビリティ イベントが関連するときにこの一意性を保証するため、AAA VLAN と BWG の加入者のブリッジ グループ割り当てを設定するときは注意が必要です。
トランスペアレント ブリッジングがイネーブルの場合、BWG には加入者からのすべてのアップリンク トラフィックをブリッジ グループに送信する前に VLAN タグを設定できます。VLAN ID は、Cisco AVP である AAA から取得されます。VLAN 優先度値は、R6 アップリンク サービス フローの QoS データ デリバリ サービス タイプ（BE、UGS など）から明示的に設定またはマッピングされます。AAA が VLAN ID を提供しない場合は、セッションが拒否されます。
ダウンリンク パケットの場合、加入者はブリッジ グループ ID と VLAN ID の組み合わせで特定されます。外側の VLAN タグとそのイーサネット ヘッダーは、設定済みのパケット分類ルールに合わせ、R6 ダウンリンク サービス フローを選択するときに使用されます。このとき、アップリンク トラフィックが BWG によって VLAN タグが設定されている場合は、外側の VLAN タグが取り除かれます。
トランスペアレント ブリッジングがイネーブルであり、BWG の VLAN タギングがディセーブルの場合、加入者からのすべてのトラフィックは同じ VLAN ID を使用する必要があります。
次に、BWG でトランスペアレント ブリッジングをイネーブルにする例を示します。
CPE 管理
CPE 管理機能では、AAA を使用して Cisco WiMax ソリューション全体で加入者/CPE を集中管理できます。実際の導入では輻輳が発生する可能性や複数の AAA プロキシがあることを考慮すると、RADIUS Access Accept メッセージを AAA から受信するには最大で 10 秒かかります。そのため、特定 R6 プロトコル ステート マシンは、この AAA 応答遅延を許容するように設計されていなければなりません。
未認証 CPE 管理機能は、AAA と BWG に移動しました。具体的には、次の機能が含まれます。
• モバイル機能（ホーム BS リストによる非移動性、および移動性）
• 静的 IP の許可（### CPE で静的 IP が許可されるか）
• CPE サービス ステート（CPE がブラックリストに載っているかどうか）
未認証加入者の AAA アクセス
EAP ベース認証をサポートしないベース ステーション/CPE の場合、BWG は RADIUS を使用した PPP/PAP 認証方式を提供します。このような CPE は、一般に未認証の CPE として分類されます。また、未認証ユーザの場合、CPE からユーザ名を取得しません。
この場合、次の CLI に基づいてユーザ名、レルム、パスワードが作られます。
（注） aaa authentication method-list xxxx コマンドは、RADIUS Access Request がグループの BWG から開始するかどうかを示します。CLI が設定されていない場合、AAA クエリーは必要ありません。それぞれの認証方式リストはタイプ PPP であり、BWG は PAP ベースの認証を実行できます。
（注） PAP ユーザに対する再認証はサポートされていません。CPE/MS によって再認証が試みられると、セッションは登録解除されます。
（注） proxy realm sprint.com password ciscoway コマンドは、RADIUS Access Request メッセージの設定方法を BWG に指示します。設定された場合、ユーザ名は mac@realm（たとえば mac @sprint.com）のように構成されます。レルムが構成されていない場合のユーザ名は mac です。構成されていない場合、パスワードとして cisco が使用されます。aaa authentication method-list xxxx を使用して設定された方式リストは、Access-Requests で使用されません。PAP 認証では aaa authentication ppp default コマンドでグローバルに設定された default 方式リストを使用するためです。
（注） これら 2 つの CLI は、他のユーザ グループ（EAP ユーザ）にも適用できます。ただし EAP ユーザに proxy-realm を設定しても影響はありません。
AAA サーバからの応答には、ユーザの実際のドメイン名が含まれます。このドメイン名は、ローカル ユーザ グループを選択するために使用されます。前述のスキーマでは、EAP 認証ユーザを対象外にしないでください。つまり、BWG では EAP および非 EAP 認証されたユーザが共存できなければなりません。認証済みユーザの場合、ユーザ名は EAP 識別情報要求を通じて CPE から取得されます。EAP では、AAA に対するアクセス要求で NAI を使用します。AAA からの応答に SLA プロファイル名、および EAP ユーザのユーザ ドメイン名が含まれる場合、AAA からの結果が先に決定された情報を上書きします。
新しい AAA アトリビュート
CPE 管理をサポートするために、次の新しい AAA アトリビュートが導入されました。これらの新しいアトリビュートは、RADIUS Access-Accept メッセージで返される可能性があります。これらのアトリビュートはすべてオプションであり、cisco_vsa 下の AVP です。
（注） 上記の AAA アトリビュートは、PAP ユーザの場合ですが、EAP ユーザの場合も同様に機能します。
SLA プロファイルの設定
BWG でサービス レベル契約を設定するには、次のタスクを実行します。
上述の設定では、ユーザ グループの SLA プロファイルがデフォルトとして使用されます。AAA が返す SLA プロファイル名が優先されます。
加入者あたり複数 SLA プロファイルのサポート
これまで BWG での SLA プロファイル設定では、サービス パッケージを定義した WiMax サービス プロバイダーがサービス オファリング（フロー タイプ）を適切なプロファイル数に効率的に分類していました。
たとえば次のフロー（flow-voice、flow-data、flow-video、flow-hd-video、flow-premium-voice、flow-premium-data）は、2 つのパッケージに定義してパッケージ単位で加入者に販売できました。
しかし、サービス プロバイダーが前記のフローで考えられるすべての組み合わせでサービスを提供するには、BWG に同数の SLA プロファイルを設定する必要がありました。
この機能を使用すると、サービス プロバイダーは次のように SLA プロファイルを設定して、希望する組み合わせで顧客にサービスをパッケージ化できます。
BWG では、単一の SLA プロファイル名に対する既存のサポートに加えて、AAA から受信した複数の SLA プロファイル名に基づいてフローを作成できます。AAA は、カンマ、スペース、またはセミコロンで区切った SLA プロファイル名のリストを送信できます。
• BWG はこのリストを解析して、有効な設定済み SLA プロファイルを選択し、セッションのサービス フローを作成します。
• BWG は次のイベント シーケンスを使用してフローを作成します。
• BWG は、設定済み SLA プロファイル名のみをリストから選択します。
• BWG は、SLA プロファイル名のリスト全体から一意のフローのみを選択します。たとえば受信した SLA プロファイル名の下で定義されているすべてのフローから「Union」を選択します（ISF の例外あり）。
• 現在の実装では、フローの作成に成功するには、ISF が 1 つだけ必要です。その結果、BWG は、AAA から受信した SLA プロファイル名のリストにおける SLA プロファイル名の順序に基づいて ISF を選択します。受信した SLA プロファイルで別の ISF プロファイルが設定されている場合でも、受信したリストで最初に有効な設定済み SLA プロファイルから ISF を選択します。
• サービス フローの最大許容数の制限に達した場合、BWG は残りの SLA プロファイルと SF プロファイルをすべて破棄します。
• BWG は、AAA から受信したリストを解析するときに、SLA プロファイルの下にある SF の有効性（たとえば SF が正しく設定されているかどうか）を確認しません。その結果、BWG が SF を開こうとしたときに SF が無効または未設定であることが判明した場合、その SF はドロップされ、BWG は残りの SF プロファイルで処理を続けます。
• AAA から受信した SLA プロファイルに ISF が存在しない場合、セッションはクリアされます。
AAA から受信した SLA リストが「silver, gold, or platinum」である場合、セッションの SLA プロファイル名は「silver, or gold」に設定され、BWG で次のような 4 つのフローが作成されます。
AAA から受信した上記の設定 SLA リストが「platinum, unconfigured, gold」の場合、セッションのプロファイル名は「platinum, gold」に設定され、次のような 4 つのフローが作成されます。
「unconfigured」SLAは、BWG によって破棄されます。
AAA から受信した SLA リストが「platinum, unconfigured, gold」の場合、セッションのプロファイル名は「platinum, gold」に設定され、次のような 4 つのフローが作成されます。
• sec（SLA を受信した順序に基づいて、このフローは SLA platinum から採用されています）
「unconfigured」SLAは、BWG によって破棄されます。
AAA からの SLA がない場合、BWG はセッションのユーザ グループの下に定義された SLA プロファイルに従って、フローを作成します。これまでどおり BWG では AAA から送信された単一 SLA プロファイルもサポートします。
ユーザ自動プロビジョニング
AAA がユーザに対してプロビジョニングしない場合でも、短時間だけユーザがネットワークに参加できることがあります。この機能をイネーブルにするには、関連する未認証グループが正しく設定されていなければなりません。イネーブルにするときは、ユーザがネットワークを自由に使用できないように、ユーザ グループのセッション タイマーが小さい値に設定されている必要があります。
自動プロビジョニングを設定するには、次のタスクを実行します。
|
|
|
|
|---|---|---|
router(config)# wimax agw user group-list wimax |
AAA がユーザに対してプロビジョニングしない場合でも、指定した時間（設定可能）でユーザがネットワークに自動プロビジョニングできるようにします。 |
（注） 自動プロビジョニングは、EAP ユーザに対応していません。未認証以外のユーザ グループで設定しても影響はありません。
（注） 固定 IP および IPCS のホストに対する自動プロビジョニングは対応していません。
セッション キャッシング メカニズム
MS と BS との間でエアーリンクの障害が発生し、CPE/MS の背後にあるホストが見つからなくなることがあります。エアーリンク障害時は、CPE に代わって元の BS が R6 登録解除を送出することもしないこともあります。エアーリンク障害後に、CPE が同じ BS または異なる BS に再接続する可能性があります。これまではどちらの場合でも BWG 内のセッションが削除されて再作成されていたため、セッションとホストの情報が失われていました。セッション キャッシング メカニズムでは、CPE 障害時にセッションを保存（つまりキャッシュ）します。この機能には、2 つのシナリオがあります。
• 元の BS は、CPE 障害時に、R6 登録解除要求を BWG に送信します。この場合、BWG のセッションは、CACHED ステートになります。セッションが CACHED ステートのときに CPE が BWG に再参加すると、元のセッションはそのホストとともに保存されます。
• BWG のセッションが準備ステートになると、CPE は（Pre-Attachment Request を通じて同じまたは異なる BS 経由で）BWG に再参加します。この場合、セッションはホスト情報を失わずに再初期化され、再参加が許可されます。
CACHED ステートに入る前に、両方のフローとホストに対する課金は停止します。R6 Pre-Attachment Request を受信すると、CACHED セッションは以前のホストとともに復元されます。この時点でホストの課金は再開されます。その後、通常の手順に従って、加入者に事前定義済みのサービス フローを作成します。
（注） BWG CLI を使用してセッションをクリアすると、CACHED ステートにはなりません。
セッション キャッシュ タイマーの値は、user-group サブコンフィギュレーション モードで指定します。次のように指定できます。
– セッション キャッシュ タイムアウトの値は、1 ～ 259200 秒（3 日間）です。
– サブオプション follow-dhcp-lease は、セッション キャッシュ タイムアウトの値をすべてのダイナミック ホストにおける DHCP リースの最大残り時間に設定します。これがデフォルトのオプションです。
Session_Cache_timeout = MAX (ダイナミック ホスト [0] の DHCP リース残り時間,
ダイナミック ホスト [1] の DHCP リース残り時間,
ダイナミック ホスト [n] の DHCP リース残り時間)
前述のとおり、デフォルトでは follow-dhcp-lease オプションによって、セッション キャッシング機能がイネーブルです。詳細な show-subscriber コマンドは、セッションの CACHED ステートを表示します。
セッション キャッシングはデフォルトでイネーブルです。以下のいずれかのタスクで次の user-group コマンドを使用して、セッション キャッシュ機能をイネーブル/ディセーブルにします。
|
|
|
|
|---|---|---|
router(config-gw-ugl)# [no] timeout cache-session [1-259200] |
router(config-gw-ugl)# timeout cache-session follow-dhcp-lease |
セッション キャッシュ タイムアウトの値をすべてのダイナミック ホストにおける DHCP リースの最大残り時間に設定します。 |
加入者あたり 20 ホストのサポート
Cisco BWG リリース 1.3 以上では、CPE に最大で 20 のホストを使用できます。ただし、BWG に対するホストの合計数は、サポートされる加入者の合計数の 4 倍を超えないようにしてください。
CPE におけるホストのモビリティ
BWG リリース 1.2 では、ユーザはホット スポットと呼ばれる BWG を導入していました。各ホット スポットには WiMAX CPE があり、個人用のホスト/コンピュータは CPE の周辺を移動していました。これらのホストは DHCP ホストです。CPE から離れたホストは DHCP RELEASE を実行できませんでした。ホストが移動してしまったとしても BWG はそのホストに関する情報を保持していて、DHCP リース タイマーが期限切れになるまで情報は BWG から削除されませんでした。これまでの DHCP リースは 3 日間に設定されていました。そのため、BWG から見てホストの最大数に達してしまうと、BWG は新しいホストを拒否していました。
• 同じ DHCP ホスト（MAC アドレスに基づく）が CPE1 から CPE2 に移動した。
このような状況になると、ホストは CPE1 経由で DHCP リリースを実行できない可能性があります。そのため、BWG は CPE1 に関連付けられたこのホストを記憶し続けます。これまでは、BWG でこのホストが CPE1 に関連付けられていると記憶し続けている限り、このホストが CPE2 からアクセスしようとしても拒否されていました。
このリリースでは、同一のホストが別の CPE2 経由でネットワークに参加しようとしていることが BWG によって検出されると、そのホストと CPE1 の関連付けが削除されます。同一ホストがネットワークに再参加するときは、同じ IP アドレスでも異なる IP アドレスでもかまいません。また、同一ホストは同じ VRF でも異なる VRF でもネットワークに再参加できます。この手法を使用する場合、ホストの MAC アドレスはネットワーク全体で一意でなければなりません。
この機能の悪影響としては、スプーフされたホスト（有効な MAC と同じ MAC を持つ）が別の CPE から参加すると、有効なホストの通常サービスが中断される可能性があります。
• あるホストが同じ VRF と IP アドレスを持つ別のホストを追い出した
この場合、ホスト 1 はすでに BWG 内にあり、CPE と関連付けられています。ホスト 2（ホスト 1 と MAC が異なる）は同じまたは異なる CPE から BWG に参加します。ネットワーク（AAA サーバのユーザ レルム→ユーザ グループ→ VRF、および DHCP サーバ）はホスト 2 に同じ VRF と IP アドレスを割り当てます。このような状況は、通常は起こりません。DHCP サーバがホスト 1 で既に使用されている IP アドレスを割り当て直すことはないからです。しかし、DHCP サーバが情報を失った場合（非グレースフル リスタートの場合や、オペレータのミスでリースが意図せず削除された場合）は、このような状況になる可能性があります。
この新しい機能を使用すると、ネットワークの不整合や IP ルーティングの混乱を回避するために、ホスト 1 が削除されます。DHCP 手続きをもう一度実行しない限り、削除されたホストのサービスは復帰できません。
固定割り当て IP の MS/ホストのサポート
イーサネット CS に対する BWG の DHCP メカニズムは、IPCS の場合と似ていますが、Option 82 に追加のサブオプション（L2 ヘッダー）がある点が異なります。BWG は DHCP 手続きを通じてホストの L2 ヘッダー（フレーム タイプなど）と IP アドレスを収集できます。DHCP メカニズムだけでなく、IP アドレスが固定割り当てされた MS/ホストもサポートします。
固定 IP アドレスの処理は、IPCS とイーサネット CS のどちらを使用しているのかによって異なります。
IP CS
認証済み加入者に対しては、AAA 応答からの Framed-Route を使用してダウンリンク トラフィックのルーティングが可能です。この機能は BWG ですでにサポートされています。
BWG は、IP CS の場合の静的ホストをアップリンク データ パケット経由で学習します。BWG には L2 ヘッダー情報がないため、これらの静的ホストは MAC ID なしで作成されます。「イーサネット CS」で後述するエージング メカニズムは、IP CS の静的ホストにも当てはまります。
イーサネット CS
BWG が静的に設定されたホストから L2 ヘッダー情報と IP アドレスを学習するメカニズムは 2 つあります。BWG は、ホスト エントリ（テーブル ID（VRF と IP アドレス）でインデックス化）と L3 ルーティング エントリを作成します。BWG で作成される静的ホストは、加入者あたり 8 つのアクティブ ホストに制限されます。ただし、既存の静的ホストの 1 つでアイドル期間がしきい値を超えると、9 番目のホストが受け入れられます。この場合、アイドルだった時間が最も長い静的ホストが新しいホストによって追い出されます。ホストのアイドルしきい値は、セッション アイドル タイマーの 75% です。固定アイドル ホストが BWG から削除されるのは、新しいホストが BWG で検出された場合のみです。DHCP ホストは期限切れになりません。
学習されたすべての固定 IP は、AAA からの Framed-Route によって検証されます。現在のところ、BWG では CPE あたり 1 つの Framed-Route をサポートします。
（注） ユーザ グループに対してルート アグリケーション機能はディセーブルにしないでください。ルーティング テーブルで静的ホスト ルートを過剰に作成または削除することが避けられます。過剰に行うと、パフォーマンス低下の原因となります。
ホストからの ARP 要求
BWG は、ホストの IP および L2 ヘッダー情報（フレーム タイプを含む）を学習するために、ARP 要求パケットを常に代行受信できます。静的ホストを作成すると、加入者あたりのアクティブ ホスト数に制限が発生します。BWG がホストを許可できない場合、ARP 要求は応答を受信しません。
BWG は、DHCP メッセージの場合と似た ARP パケットを処理します。ARP 応答パケットは、要求元と同じサービス フローに返されます。BWG の MAC アドレス（ARP 要求を受信したインターフェイス）は、MS に対する ARP 応答メッセージで使用されます。
BWG は、自身に過剰な負担がかからないように ARP レート処理制限機能も実装しています。ARP パケットは、その到着レートが BWG の処理能力を超えると、ドロップされます。現在のところ、BWG のスロットリング メカニズムでは、5 秒ごとにアップストリーム ARP パケット 1 つが可能です。
本来の ARP プロキシになるために、BWG はパススルー ARP 要求パケットを代行受信できる必要があります。これらのパケットには、BWG の IP とは異なる Target Protocol Address（TPA）が設定されます。ARP 応答パケットでは、要求パケット内の TPA が使用されます。
ホストからのアップリンク パケット
アップリンク パケットが Cisco Express Forwarding（CEF; シスコ エクスプレス フォワーディング）パス内のホスト エントリなしで BWG によって受信されると、プロセス パスへ再ルーティングされて処理されます。その結果、新しいホストが作成される可能性があります。ホストを作成できない場合（8 つのアクティブ ホスト制限による）、パケットは自動的にドロップされます。
BWG に実装されたスロットリング メカニズムは、パケットをプロセス パスに再ルーティングして BWG に過剰な負荷がかからないようになっています。現在のところ、BWG のスロットリング メカニズムでは、5 秒ごとに 1 パケットを再ルーティングします。
制限事項
• ネットワークから追い出されたホストは、最初にアップリンク トラフィックを送信しないとダウンリンク トラフィックを受信できません。このような場合、CPE は実際にはその背後に 9 以上のホストを保持しています。
その他の機能拡張
Cisco BWG リリース 1.1 以降の機能をサポートするために、R6 プロトコル、MIB、統計情報、SR、CLI に関して BWG が強化されました。
R6 プロトコルの機能拡張
R6 Attachment Request
メッセージの Registration コンテキストにおける CS 機能は、BS または BS シミュレータによるイーサネット CS を示すように、適切な値に設定する必要があります。
（注） このメッセージに含まれる CS 機能では、MS がサポートするビットマップで単一の CS タイプまたは一連の CS タイプを示すことができます。どのような場合でも、MS の機能を表します。CS 機能の定義については、802.16 を参照してください。
R6 Attachment Response
このメッセージは BWG から BS に送信されます。このメッセージに対する変更は、R6 Attachment Request メッセージと同等です。
このメッセージ内の CS 機能ビットマップは、BWG が IPCS とイーサネット CS の両方をサポートしていることを示すようにエンコードされています。
R6 Data Path Registration Request
このメッセージは、通常の R6 データ パス設定で BWG から BS に送信されます。MSINFO TLV には、次のサブ TLV が含まれます。
• Anchor GW/DPF ID = ASN ゲートウェイの IPv4 アドレス
– CS Type：フローに IP CS、Eth CS、または VLAN CS を指定します。
Ethernet Src MAC：（任意）アップリンク SF 用。コントロールのみの場合は、ダウンストリーム用に送信されます。
Ethernet Dest MAC：（任意）アップリンク SF 専用
Data Path ID：GRE Key または VLAN ID
CS Type は、特定のサービス フローに適用されます。これは、MS の指定された CS 機能（Attachment Request 内）と BWG のサービス フロー CLI 設定の共通部分です。CPE と BWG の両方が IPCS とイーサネット CS の両方をサポートし、BWG で両方が同じ手順で設定されている場合は、IPCS が選択されます。
Ethernet Src MAC と Ethernet Dest MAC アドレスは、対応する BWG CLI 設定で any として設定されていない場合は含めてください。新しいタグ値は、Cisco R6 仕様に準拠しています。
イーサネットおよび VLAN 関連の分類子は、IPCS サービス フローでは通知されません。イーサネット CS の場合は、分類子 VLAN-ID および VLAN Priority Range がローカルで設定されている場合は、それらが BS に通知されます。
「Data Path ID」は既存の TLV です。VLAN タグの VLAN Priority 値（VLAN タグで最上位 3 ビット）は、フローに設定された DSCP/優先度、またはフローに設定された QoS データ デリバリ サービスから取得されます。
「Data Path Encapsulation Type」TLV は、カプセル化タイプが R6 ベアラ トラフィックを転送するために使用されるかどうかを指定します。
「Data Path Encap Type」のタグ値は、Cisco R6 仕様に準拠する必要があります。イーサネット CS の R6 コントロール専用の場合、この TLV は「none」に設定してください。「Data Path Encap.Type」が「none」に設定されると、BS は Data Path ID を VLAN ID として解釈します。設定がない場合、データ トラフィックを転送するために GRE で R6 データ パスを使用します。
アップリンク SF 用に BS に通知される DSCP 値は、SF 用にローカル設定された BWG から取得されるか、BWG が存在しない場合はフローに設定された QoS データ デリバリ サービスから取得されます。
また AAA を介して BS を利用できる場合は、ISF Path Registration Request によって新しく定義された CPE Settings TLV を BS に通知します。CPE 設定は、MS INFO TLV の下にあります。
R6 Data Path Registration Response
このメッセージは、通常のデータ パス設定時に BS から BWG に送信されます。メッセージに対する変更は、R6 Data Path Registration Request メッセージと同等です。Data Path Registration Request メッセージに定義される新しい TLV はすべて Path Registration Response メッセージで利用できます。
その他の R6 の変更
一貫性を持つために、すべての R6 シグナリング UDP パケット には DSCP 値 0x48 が設定されます。また、リリース 1.0 以上では、UDP チェックサムがすでに計算されています。
BWG は、サービス フローの数を 4、アクティブ ホストの数を加入者あたり 20 に制限します。上限を超えそうになると、BWG は失敗します。
（注） BWG では、SLA プロファイルあたり 4 つまでサービス フローを使用できます。
EAP 認証
BWG は、EAP リレーとして動作し、EAP 方式は問いません。BWG とベース ステーションの間では、コントロールの交換として EAP 転送が行われます。ベース ステーションは EAP リレーとして動作し、Pair-wise Master Key version 2（PKMv2）から BWG への EAP メッセージへと変換します。BWG は EAP パススルーであり、EAP 方式を生成するすべての鍵がサポートされます。
PKMv2 は、無線によるユーザ認証を実行するために使用されます。PKMv2 は、IEEE 802.16 エアー インターフェイスを使用して EAP を MS とベース ステーションの間で転送します。ベース ステーションは、EAP メッセージを BWG のオーセンティケータにリレーします。オーセンティケータ上の AAA クライアントは、EAP メッセージを AAA プロトコル パケットにカプセル化し、1 つ以上の AAA プロキシ経由でホーム NSP の CSN にある AAA サーバに転送します。ローミングの場合、AAA プロキシを使用する 1 つ以上の AAA ブローカがオーセンティケータと AAA サーバの間に存在する可能性があります。すべてのセッションは常にオーセンティケータと AAA サーバの間に存在し、オプションの AAA ブローカによって NAI レルムベースのルーティング用コンジットを提供します。
認証済みユーザのネットワーク許可
次の一連のイベントでは、ネットワークが認証済みユーザを許可する方法を示します。
1. オーセンティケータ（BWG 内）は、Pre-Attachment-Ack メッセージをベース ステーションから受信すると MS による EAP 認証手順を開始します。
2. オーセンティケータは、Authentication Relay プロトコル（AuthRelay-EAP-Transfer）を使用して EAP Request/Identity メッセージを BS に送信します。
3. BS は、PKMv2 EAP-Transfer/PKM-RSP メッセージで EAP Request/Identity ペイロードを MS にリレーします。
4. MS は、NAI を提供する EAP Response/Identity メッセージで応答します。このメッセージは、PKMv2 EAP-Transfer/PKM-REQ メッセージを使用して BS に転送されます。
5. BS は、Authentication Relay プロトコル（AuthRelay-EAP-Transfer メッセージ）を使用して、PKMv2 EAP-Transfer で受信したEAP ペイロードをオーセンティケータにリレーします。
6. EAP ペイロードは、訪問 AAA サーバ経由で MS のホーム AAA サーバに転送されます（オーセンティケータは、提供された NAI を分析して、ホーム AAA サーバの場所を解決します）。オーセンティケータは、Authentication Relay プロトコル（AuthRelay-EAP-Transfer）を使用して EAP Request/Identity メッセージを BS に送信します。
7. BS から受信した EAP ペイロードを AAA サーバに伝送するために、オーセンティケータは RADIUS Access-Request メッセージを使用し、コロケート AAA クライアントを介して EAP メッセージを転送します（EAP ペイロードが RADIUS の「EAP message」アトリビュートにカプセル化されます）。
8. EAP 認証プロセス（トンネリング EAP 認証方式）は、BWG のオーセンティケータを介して MS と認証サーバとの間で実行されます。
9. RADIUS Access-Challenge メッセージ内で AAA サーバから返された EAP ペイロードは、AuthRelay-EAP-Transfer メッセージでベース ステーションに転送されます。Mobile Subscriber Station に位置する EAP サプリカントと、AAA サーバに位置する EAP Authentication Server との間で、複数の EAP メッセージ交換が行われる可能性があります。
10. オーセンティケータは、Key Change Directive メッセージをベース ステーションに送信して、EAP 認証プロセスが完了したことを通知します。鍵は、AAA から Access Accept で受信した Master Secret Key（MSK）を使用して BWG が計算します。Key Change Directive には、AK Context のサブ TLV で MSINFO TLV が含まれ、EAP 成功を示す EAP Payload TLV も含まれます。
11. 認証が失敗した場合、加入者が Normal Mode Network-Initiated Network Exit の手順を使用してネットワークから登録解除されたことが AAA サーバから受信されます。
12. ベース ステーションは、Key Change Acknowledgement メッセージを使用して Key Change Directive メッセージの受信を確認します。
13. ベース ステーションは、PKMv2 EAP-Transfer メッセージを使用して、認証の結果を Mobile Subscriber Station に送信します。
未認証ユーザのサポート
次のような状況では、未認証ユーザのサポートが必要です。その場合は、プリペイド システムや緊急通話で使用できます。
• ヌル認証を通知するように Mobile Subscriber（MS）を選択できます。これは、緊急通話に限定された MS のように、特定タイプの MS にできます。このようなタイプの MS は、SBC_REQ でヌル認証サポートを通知します。BS は、NetEntry MS State Change Request を介してこの情報を BWG にリレーします。
• BWG はローカル ポリシーに基づいて、認証をスキップするように選択でき、加入者がネットワークに参加することを許可します。
• CLI を使用してヌル認証をイネーブルにするように BWG が設定されている場合、ヌル認証を要求する Subscriber Station（SS）/MSS が NULL-AUTH ユーザ グループにマッピングされます。これらの SS/MSS からの DHCP 要求は、設定済みの DHCP サーバにのみ送信されます。これにより、オペレータは未認証ユーザに対するアドレス割り当てを制御したり、そのようなユーザに対する制約事項を適用したりできます。また、SS/MSS からのトラフィックを特定の宛先のみに制限するようにアクセス コントロール リストを設定できます。
Cisco BWG リリース 1.1 では、EAP 認証をサポートします。BS/CPE が EAP 認証をサポートしない場合、その CPE は未認証として分類されます。BWG では、MAC ID とパスワードに基づいて認証される CPE に対して、非常に基本的な PAP タイプの認証をサポートします。RADIUS サーバは、CPE をプロビジョニングするようにあらかじめ設定してください。
BWG で PAP 認証をイネーブルにする AAA の設定
PPP/PAP 認証をイネーブルにするために BWG を設定するには、グローバル コンフィギュレーション モードで次のタスクを実行します。
|
|
|
|
|---|---|---|
router(config)# aaa authentication ppp default group {WORD | radius} |
PPP を実行しているシリアル インターフェイスで使用する Authentication, Authorization, and Accounting（AAA; 認証、認可、アカウンティング）認証方式を指定します。 |
PAP 認証を使用した CPE の AAA アクセス
RADIUS サーバに対する未認証ユーザ グループの PAP Access-Request を BWG で開始するには、次のタスクを実行します。
|
|
|
|
|---|---|---|
router(config-gw-ug)#aaa authentication method-list {WORD | default} |
RADIUS Access Request がユーザ グループの BWG から開始するかどうかを示します。コマンドが設定されていない場合、Access-Request は RADIUS に送信されません。 |
PAP 認証を使用した CPE のプロキシ レルム
未認証ユーザの場合、BWG は CPE からユーザ名を受信しません。この場合、BWG はプロキシ レルムとパスワードを指定するメカニズムを提供します。
ユーザ名、レルム、パスワードを設定するには、次のタスクを実行します。
|
|
|
|
|---|---|---|
BWG は、PAP Access-Request 内のユーザ名とパスワードとして、proxy realm と MACID の組み合わせ、およびパスワードを使用します。その後、要求を RADIUS サーバに送信します。 |
この設定では、BWG は MACID@cisco.com に設定されたユーザ名と cisco に設定されたパスワードを使用して、RADIUS サーバに Access-Request を送信します。
プロキシ レルムが設定されていない場合、BWG は MACID に設定されたユーザ名と cisco に設定されたパスワード（デフォルトのパスワード）を使用して、Access-Request を RADIUS サーバに送信します。
PAP 認証を使用した未認証 CPE 自動プロビジョニング
自動プロビジョニングを使用すると柔軟性が得られるほか、BWG で設定した場合は、AAA で CPE に対してプロビジョニングしない場合でも、CPE はネットワークに参加できます。
（注） 自動プロビジョニングは、PAP 認証を使用した CPE に限定されます。
未認証のユーザ グループに対する自動プロビジョニングを設定するには、次のタスクを実行します。
|
|
|
|
|---|---|---|
未認証のユーザ グループに対して自動プロビジョニングを設定します。イネーブルにするときは、ユーザがネットワークを自由に使用できないように、ユーザ グループのセッション タイマーが小さい値に設定されている必要があります。 |
認証の設定
この項では、Cisco BWG で認証および認可を設定する方法について説明します。BWG と加入者の間で認証されたコールをイネーブルにするには、BWG で次のタスクを実行します。
• 「認可の設定」
• 「認証の設定」
AAA でアカウンティング タイプの設定
BWG でアカウンティング タイプを設定するには、次のタスクを実行します。
|
|
|
|
|---|---|---|
新しいアクセス コントロール コマンドと機能をイネーブルにします （古いコマンドをイネーブルにします）。コマンドで no を使用すると、古いコマンドと機能を再開できます。 |
認可の設定
|
|
|
|
|---|---|---|
router(config)# aaa authorization network default group {server-group-name | radius} |
特定の認可リストに対して AAA サーバから設定をダウンロードする server-group を指定します。コマンドで no を使用すると、server-group の使用を取り除くことができます。 |
認証の設定
|
|
|
|
|---|---|---|
router(config)# aaa authentication dot1x {authentication-list-name | default} group {server-group-name | radius | tacacs+} |
AAA サーバから設定のダウンロードを指定するには、次のタスクを実行します。
|
|
|
|
|---|---|---|
router(config)# aaa authorization configuration default group {WORD | radius| tacacs+} |
RADIUS サーバ
BWG で RADIUS サーバ ホストを設定するには、次のタスクを実行します。
|
|
|
|
|---|---|---|
router(config)# radius-server host {host-name | ip-address} {auth-port | acct-port} key |
ip-address：RADIUS サーバの IP アドレス auth-port：RADIUS 認証サーバの UDP ポート（デフォルトは 1645） |
ユーザ グループの設定
BWG でユーザ グループを設定するには、次のタスクを実行します。
（注） AAA サーバ グループは方式リストの設定とリンクして、さまざまな AAA サーバを設定でき、その結果、さまざまなユーザ グループにマッピングできます。
設定の確認
加入者の認証方式では、コールが EAPで認証されたかそれぞれのユーザ グループ（any、unauthenticated、domain に固有）に対して未認証であったかどうかを表示します。
認証されたユーザの場合は、Auth Policy および AK Context も表示されます。
|
|
|
|
|---|---|---|
設定例
セキュリティ鍵交換
加入者の EAP 認証後、BWG はベース ステーションごとの Access Key（AK; アクセス鍵）を計算します。また、BWG は認証時に PMK をキャッシュし、SS/MSS が別の BS に移動したときに追加の AK を再計算します。
リリース 1.0 以上では、モバイルからトリガーされた Re-Authentication をサポートし、新しい PMK を生成します。
DHCP を使用した IP アドレス割り当て
Cisco BWG リリース 1.0 以上では、外部の Dynamic Host Configuration Protocol（DHCP）サーバベースのアドレス割り当てをサポートします。
（注） アドレスを SS/MSS に割り当てる唯一のメカニズムは、DHCP に基づいています。
SS/MSS は DHCP を使用して IP アドレスを割り当てできます。リリース 1.0 以上では、MIP や PMIP はありません。BWG は固定 IP とポータブル IP のみを対象にしているからです。DHCP リレーは BWG 内にあり、ユーザ グループが異なる VRF 上にある場合は DHCP サーバと相互作用します。
VRF の場合のみ、ユーザ グループとアドレスが重複してもかまいません。
最初のサービス フローの認証と設定に成功したら、MS が DHCP を開始して IP アドレスを取得します。DHCP サーバは、BWG でユーザ ドメイン グループごとに設定されます。DHCP メッセージは、BS と BWG の間で R6 データ パス上を透過的に転送されます。アドレスは、ユーザ ドメイン グループに関連している対応 DHCP サーバによって割り当てられることがあります。異なるユーザ グループにまたがってアドレスが重複してもかまいません。ループ バックを使用することが理想的な方法ですが、「dhcp gateway address」が設定されていない場合は、バーチャル テンプレートの IP が gi-address として使用されます。
最初のサービス フローでは、DHCP パケット以外のデータ トラフィックを許可しません。アドレス割り当てが正常に完了したら、SS/MSS に割り当てられた IP アドレスに対応する適切な分類子がインストールされます。
Subscriber Station の背後にある複数のホストをサポートするため、Subscriber Station からの複数の DHCP 要求がサポートされます。これらの要求は、同じまたは別のサービス フローで受信できます。
IP アドレス割り当ての設定
外部の DHCP サーバを使用して IP アドレスを設定するには、次のタスクを実行します。
（注） DHCP サーバとゲートウェイは、ユーザ グループの下に設定することもできます。ユーザ グループの下に DHCP サーバまたはゲートウェイのアドレスを設定しない場合は、グローバル コンフィギュレーション方式が使用されます。DHCP サーバのアドレスは、ゲートウェイのローカル インターフェイスのアドレスと一致しないようにしてください。
複数ホストのサポート
SS の背後にある複数ホストは、IPCS で DHCP リレー Option 82 または Option 82 加入者 ID を使用した場合にサポートされます。
Option 82 の Subscriber-id サブオプションは MS/SS の MSID に、Circuit-id サブオプションはダウンリンク サービス フロー識別子に設定できます。リモート ID は SS/MSS の認証済みユーザのユーザ名、VPNID はユーザの VRF 名に設定できます（設定済みの場合）。これには、L2 ヘッダーの新しいサブ オプション 200 が含まれます。
たとえばマルチホストをサポートするように、DHCP サーバは各 MAC に一意の IP アドレスを割り当てることができます。
加入者 ID にはユーザ名、リモート ID にはユーザの MACID が使用されます。
（注） リリース 1.0 以上では、リレー カスケーディングはサポートされていません。
（注） MS の背後で使用できるホストの最大数は 8 です。
SS の背後にある複数ホストのサポート
ステップ 1 CPE（SS）が最初のネットワーク参加と認証を実行すると、ベアラ パスが作成されます。
ステップ 2 BS と BWG の間には、基本的な R6 ベアラ パスが作成されます。基本的な R6 は、アップリンク/ダウンリンク用の GRE 鍵を共有します。この GRE 鍵は SFID と対応するエアーリンク接続にマッピングされることがあります。
ステップ 3 BWG で同じサービス フロー（R6 ベアラ）上のすべてのホストに対して、すべてのアップリンク パケットとダウンリンク パケットは CPE によって送受信されます。
DHCP Option 82
DHCP Option 82 は、加入者とホストに適用できます。このオプションは、任意のホストまたは加入者の DHCP メッセージで送信されます。
複数のホストは、DHCP Option 82 を使用してサポートできます。リレー エージェント情報オプションは、クライアントから発信された DHCP パケットが DHCP サーバに転送されるときに DHCP リレー エージェントによって挿入されます。リレー エージェント情報オプションを認識するサーバは、この情報を使用して IP アドレスまたはその他のパラメータ割り当てポリシーを実装できます。また、イーサネット CS の場合の L2 ヘッダーも Option 82 で挿入されます。
DHCP Options 82 は、加入者 ID、リモート ID、回線 ID を付加します。そして、すべての DHCP メッセージでサーバに送信されます。VRF の場合は、VPN ID も送信されます。DHCP サーバが Option 82 に対応しておらず、Option 82 をエコー バックしない場合、BWG はメッセージを DHCP サーバからドロップします。
• アクセス コントロール、QoS、およびセキュリティ ポリシーを設定する
DHCP Option 82 機能で発生するイベントのシーケンスは次のとおりです。
ステップ 1 ホストは、クライアントの識別情報フィールドに DHCP メッセージ内の MAC アドレスを設定します。
ステップ 2 CPE の IP アドレスを取得するために、DHCP メッセージのやりとりが ISF でのみ行われます。ホストの IP アドレスを取得する場合は、任意のフローで行えます。BWG からの DHCP パケットは、ホストからの着信 DHCP メッセージと同じフローで送出できます。
ステップ 3 BWG は、DHCP サーバが使用する Option 82 フィールドを挿入します。Option 82 は、DHCP サーバに対するすべての DHCP メッセージに挿入される必要があります。挿入するオプションのリストについては、 表 2-3 を参照してください。
ステップ 4 DHCP サーバは、着信 DHCP パケットの Option 82 フィールドの任意のオプションを使用して、IP アドレスを割り当てることができます。IP アドレスが割り当てられると、BWG では応答をモニタして割り当てられた IP アドレスを学習し、R6 ベアラにマッピングします。このプロセスはホストごとに繰り返され、アドレスが追跡されて同じ R6 ベアラにマッピングされます。
ステップ 5 BWG はすべての DHCP メッセージをモニタし、Option 82 フィールドが挿入されていることを確認します。
表 2-3 に、DHCP サーバのオプションを示します。
|
|
|
|
|
リリース 1.1 における DHCP Option 82 の機能拡張
BWG がダウンリンク DHCP パケットの L2 ヘッダーを構成できるように、L2 ヘッダー全体が Option 82 内にコーディングされます。Option 82 は、DHCP サーバから反映されます。このサブオプションは、BWG と DHCP サーバとの間のみに適用されます。
加入者単位の DHCP ホスト オーバーフロー メカニズム
この機能が実装されるまで、加入者単位で DHCP ホストの数は厳格にコントロールされていました。最大数に達すると、加入者宛の後続ホストはすべて拒否されていました。このような厳格なコントロールは、負荷の高いホットスポットには適切ではありません。この問題は、DHCP リース時間が長く、CPE を離れたホストが DHCP リリースを実行しなかった場合には、さらに深刻になります。
Least Recently Used（LRU;最低使用頻度）に基づく新しいホスト オーバーフロー メカニズムは、ホストの数が CPE の上限（20）を超えることがある問題に対処するために使用されます。新しいホストが加入者に参加するとき、その最大数に達している場合は、LRU ホストが選択されます（トラッシングを避けるため、最小のアイドル時間が適用されます）。このホストはアクティブ リストから削除されてオーバーフロー リストに移り、新しい加入者のために空きを用意します。オーバーフロー リストのホストからアップリンク データまたは DHCP メッセージを受信すると、そのホストはアクティブ リストに昇格します。
CLI を使用して、この機能をイネーブルにし、ホスト オーバーフロー リストのサイズを設定できます。デフォルトのサイズは 50 です。新しく追加されるホストは、常にリストの末尾に追加されます。オーバーフロー リストがいっぱいになると、最も古いオーバーフロー ホスト（リストの先頭）が削除され、新しい加入者を受け入れます。
アクティブ リストの LRU ホストがオーバーフローに押し出されると、そのホストのアカウンティングが停止します（アカウンティングがイネーブルの場合）。ダウンリンク ホスト ルートも削除され、オーバーフロー ホストはダウンリンク データを受信できないようになります。また、オーバーフロー ホストに対しては DHCP タイマーが実行されません。
メモリを節約するために、オーバーフロー ホストは、後でアクティブ リストに復帰するために必ず必要な情報のみを保存します。アクティブ ホストは約 300 バイトのメモリを確保するのに対して、オーバーフロー ホストが使用するメモリは 40 バイトにもなりません。
オーバーフロー ホストに対するアップリンク データまたは DHCP Renew メッセージを受信すると、BWG はオーバーフロー ホストをアクティブ ホストに復帰させようとします。しかしこの処理の結果は、2 つの要因に依存します。
• アクティブ リストがいっぱいの場合、BWG は別の認定済み LRU ホストをアクティブ リストから見つけ出せるか。認定済みホストは LRU ホストは、最小アイドル要件を満たさなければなりません。
復帰に成功すると、ホストはオーバーフロー リストから削除されて、アクティブ リストに追加されます。まるでずっとアクティブであったかのように、そのホストの残りライフタイムに対して DHCP リース タイマーが再開します。さらに、ホスト ルートが復元され、このプロセスにおけるホストのアカウンティングが再開します。アクティブ リストへの復帰に失敗すると、ホストはキャッシュ リストに残ります。
つまり、ホストがオーバーフロー リストから削除されるのは、次の 2 つの状況下です。
• 最古（リストの先頭）になり、かつリストがいっぱいのときに、別の加入者によって削除された場合。この場合、DHCP リリースが DHCP サーバに送信されます。キャッシュ リストから削除されたホストは、DHCP 手続きがホストでもう一度開始されるまでデータを送受信できなくなります。
冗長設定の場合は、オーバーフロー ホストのリスト自体はアクティブ BWG からスタンバイ BWG に同期されません。ただし、アクティブ ホストの追加や削除に関する情報は、動的に同期されます。この情報はスタンバイ側でオーバーフロー ホスト リストを再構築するために使用できることを想定しています。バルク同期を行うと、スタンバイ側のホスト オーバーフロー リストは再構築できなくなります。アクティブ ホストがリスト内のその位置を占めるに至った履歴が失われるためです。
BWG のホスト オーバーフロー機能は、DHCP クライアントにも DHCP サーバにも認識されません。これは新しい機能であり、CPE がアクティブ リストを超える数のホストにサービスを提供できます。
利用可能なメモリを効率的に使用できるようにするため、この機能はユーザ グループ単位で提供されます。ホットスポットのような CPE のユーザ グループでは、明示的にこの機能をイネーブルにする必要があります。デフォルトでは、この機能はイネーブルではありません。
加入者単位の DHCP ホスト オーバーフロー メカニズムを設定するには、次のタスクを実行します。
• データ パケットを受信した場合は MAC アドレスがないため、レコード配列は IP のみに基づいて突き合わせが行われます。動的ホストとスプーフした固定ホストを区別できません。推定される影響としては、スプーフしたホストがだましている間も、本物の DHCP ホストとスプーフしたホストの両方が、リースを更新している DHCP ホストとのトラフィックを送信し続けます。ただし、既存の動作に変更はなく、この問題は現在でも残っています。本物の IP ホストが CPE に接続されている場合、スプーフされた CPE もその CPE と同じアドレスを使用して開始できます。
• 固定 IP を使用できる場合、CPE から削除された DHCP ホストのレコードも配列から削除されます（別のレコードによって上書きされます）。DHCP ホストが復帰すると、代理受信した最初のデータ パケットによって固定ホストが開きます（固定 IP が許可されているため）。ホストが DHCP 更新を送信しない場合、そのホストは固定として扱われ、リストから追い出されるまで削除されません。ただし、これはユーザが選択した場合のことであり、既存の動作はまったく同じです。
• ホストのアカウンティングがイネーブルの場合、ホストに対するアカウンティングの開始/終了がオーバーヘッドになる可能性があります。
• ネットワークでホット スポット CPE の使用状況が高い場合、セッションあたりのメモリ要件が高くなります。
オーバーフロー ホストを表示するには、次のタスクを実行します。
router# show wimax agw subscriber internal |
サービス フローの作成と管理
802.16 では、任意の SS に対して複数のサービス フローをサポートします。サービス フローは、一連の分類規則をパケット ベアラに対してマッピングすることで識別されます。サービス フローはそれぞれ一方向のフローであり、エアーリンクとネットワークの両方で、QoS（Quality of Service）の扱いを個別に変えることができます。
Cisco BWG リリース 1.0 以上では、サービス フローの作成は、ネットワークによって開始した場合のみサポートされています。サービス フローを作成すると、SS/MSS 上の分類子もプロビジョニングされます。
また、事前にプロビジョニングされたサービス フロー テンプレートは、BWG のローカルに設定されます。AAA でのサービス フロー プロファイル ID のダウンロードは、BWG ではサポートしていません。
サービス フロー
BWG では、SS/MSS ごとにサービス フローを管理します。リリース 1.0 以上では、ネットワークでトリガーされたサービス フローのみをサポートします。BWG は各サービス フローの SFID を割り当て、サービス フローの作成をトリガーします。サービス フローにはそれぞれのデータ パスもあります（たとえば GRE 鍵、および各サービス フローに対応するパケットは、それに従って転送されます）。
事前にプロビジョニングされたすべてのフローは、SS/MSS セッションのライフタイム中は利用可能であることが想定されていて、削除されません。
サービス フローの複数作成
コントロール プレーンが開始すると、BWG はベース ステーションによる最初のサービス フローの作成を要求します。DHCP IP アドレスの割り当てとフローの作成は、BWG リリース 1.1 では並行して行われます。
ISF で発生した DHCP 割り当てと並行して、フローが次々に作成されます。サービス フロー作成が成功した後でのみ、その次のサービス フローの作成が開始します。サービス フローの作成に失敗したときに、その前に次のサービス フローの登録要求をリトライしていると、そのサービス フローの作成も失敗します。サービス フローの作成に失敗した場合、それがセカンダリ サービス フローの場合はそのサービス フローがバイパスされ、最初のサービス フローの場合はセッションが破棄されます。
リリース 1.0 以上の場合、BWG では最初のサービス フローと 3 つのセカンダリ サービス フローの合計 4 つのサービス フローを作成できます。
セカンダリ サービス フローの作成に失敗すると、次のフローが試され、失敗したサービス フローなしでセッションが続行します。
BWG サービスの設定
BWG サービスをイネーブルにするには、グローバル コンフィギュレーション モードを開始して次のコマンドを使用します。
|
|
|
|
|---|---|---|
カプセル化タイプ「ASNGW」でバーチャル アクセス インターフェイスのクローンを作成します。このコマンドは、バーチャル テンプレート コンフィギュレーション モードで設定します。 |
設定例
Gi アドレスは、デフォルトで仮想アドレスから使用されます。Gi アドレスを上書きするように user-group 設定を使用できます。
設定の確認
BWG サービスがイネーブルであることを確認するには、および MS State Change および Data Path 統計情報を表示するには、特権 EXEC モードで show wimax agw statistics コマンドを使用します。
サービス フローから DiffServ クラスへのマッピング
BWG は、個別のサービス フローを Diffserv クラスにマッピングします。マッピング規則は、ルータで設定されます。マッピング規則を 表 2-4 に示します。
|
|
|
|
|---|---|---|
サービス フローに相当するパケットのマーキング
各パケットは、関連するサービス フローに従って特定され、グループ化されます。そのパケットに対応するトランスポート ヘッダーは、BWGによって、前掲の表に基づき関連する Diffserv Code Point（DSCP; Diffserv コード ポイント）でマークされます。
BWG でサービス フローの設定
設定例
次に、サービス フロー コンフィギュレーション コマンドの例を示します。
サービス フロー パケット分類の設定
BWG でサービスフロー パケット分類規則プロファイルを設定するには、次のタスクを実行します。
設定例
サービス フロー パケット分類コンフィギュレーション コマンドの設定例を示します。
（注） パケット分類子は、指定されたユーザおよび各パケットのフロー方向に対して合計して表示されます。最高のマッチング優先度規則が適用されます（255 が最高の優先度です）。分類子が一致しない場合、選択されたデフォルトの フローがダウンリンク方向の ISF になります。
クリティカル サービス フロー
1 つ以上のセカンダリ フローの作成に失敗し、加入者が必要としているよりもフローの数が少ないまま加入者セッションが存続する場合があります。このような状況では、セッションを登録解除し、加入者が必要とするすべてのクリティカル フローでセッションを再作成できるようにしてください。たとえば、加入者にすべてのフロー（音声、ビデオ、およびデータ）を使用させたり、まったく使用させないようにしたい場合があります。この機能では、Service Flow（SF;サービス フロー）を加入者にとってクリティカルであるとマークできます。BWG は、「クリティカル」であるとマークされている各 SF が作成された場合に限り、加入者セッションを正常に作成します。
BWG では、SLA プロファイル設定において SF を追加するときに、その SF をクリティカルとマークできます。SF がクリティカルとマークされている場合、そのクリティカル SF の作成に失敗すると、セッションを開けません。重要なのは、セッションを開くには各クリティカル フローを正常に作成する必要があるということです。SF がクリティカルとマークされていない場合、または ISF である場合は、既存の動作に変更はありません。
コントロールされたハンドオーバー時にターゲット BS がクリティカル フローを含めることに失敗している場合、BWG はハンドオーバーに失敗します。ポイントは、「すべてのフローかそれともなしか」という考え方が加入者に常に適用されるようになることです。
デフォルトでは、SLA プロファイルで「クリティカル」であると指定されていない限り、SF はクリティカルではありません。
BWG でサービス フローをクリティカルとマークするように設定するには、次のタスクを実行します。
|
|
|
|
|---|---|---|
Router(config)#wimax agw sla profile bronze Router(config-gw-sla)#service-flow pre-defined secondary 2 profile sec2 critical |
SR 設定では、アクティブ BWG とスタンバイ BWG で同一の SF クリティカル設定にしている必要があります。
show wimax agw subscriber によるフローの詳細情報では、フローがクリティカルであるかどうかが示されます。
BWG から Attachment Response の遅延
Navini 製独自モデムの一部タイプでは、最初の電源オフ時に同期してネットワークに接続します。このプロセスにおいて、Surfer モデムのネットワーク ID が 0xFFFF（出荷時デフォルト）の場合、REG-RSP メッセージ時に新しいネットワーク ID をモデムのフラッシュに書き込みます。この ID は、書き込み後に変更できず、モデムが参加できるネットワークは、BS が同じネットワーク ID に属しているネットワークのみです。
Profile C では、未認証モデム（Surfer など）を使用する場合は AAA 認証（Accept）に時間がかかることがあり、BWG は AAA から Radius Accept を受信する前に MS Attachment Response を BS に送信できます。このとき、BS は成功 REG-RSP を Surfer モデムに送信し、その後そのモデムは AAA 認証に失敗する可能性があります。現在の実装では、認証に失敗したことを BWG 経由で AAA から学習したときに、BS がモデムをリセットします。モデムをリセットするのは、モデムがほかの BS にアクセスできるようにするためです。
• 新しい独自モデムは、モデムを販売したネットワーク オペレータに属していない BS にロックされます。この場合、モデムは使用不可能であり、オペレータに返送してプログラミングしなおしてもらう必要があります。
• 同じオペレータにアクティブ ネットワークとテスト ネットワークがあり、2 つの異なるネットワーク ID を使用している場合、新しいモデムは、初めて電源が入った場所によっては誤ったネットワークにロックされることがあります。その後、そのモデムはそのネットワークのみで動作します。ロックされた最初の BS は、意図したネットワークではない可能性があります。
この問題を解決するため、BWG は新しい CLI に基づいて Attachment Response の伝送を遅らせるように設計されています。このコマンドを使用すると、Attachment Response のタイムアウト値を設定できます。デフォルト値は 4 秒です。
ユーザグループにおいてタイムアウト値を設定すると、BWG はタイマーを設定し、適切な処理を実行します。次に、さまざまな状況について説明します。
1. このタイムアウトの前に AAA の応答を受信した場合、および
– CPE が認証済み（受け入れ済み）であり、サービス ステートの値が CPE がアクティブであることを示している場合、BWG は MS Attachment Response の処理を直ちに続行します。
– CPE が認証済みであり、サービス ステートの値が CPE がブラック リストに載っていることを示している場合、BWG は Deregistration Reason TLV で Path Deregistration Message を送信します。
2. このタイムアウトの前に AAA の応答を受信しない場合
– BWG は MS Attachment Response を送信して、（要求に TLV エラーがあるにもかかわらず）成功したことを通知します。
– AAA の応答を受信して Service Type アトリビュートが CPE がブラック リストに載っていることを示している場合、BWG は Deregistration Reason TLV で適切な Reason Code とともに Deregistration を送信します。
– AAA の応答を受信して Service Type アトリビュートが CPE がアクティブである（ブラックリストに載っていない）ことを示している場合、BWG は BS に対する Path Registration Request を続行します（現在の実装と同様）。
両方の場合とも、BWG は「Access-Reject」を受信すると、ユーザが自動プロビジョニングされた場合はセッションを開いたままにします。ユーザが自動プロビジョニングされていない場合、セッションは登録解除されます。
デフォルトでこの BWG は Attachment Response を遅延するように設計されています。BWG では、PAP 認証済みユーザに対してのみこの機能をサポートします。
Attachment Response の遅延を設定するには、次のタスクを実行します。
|
|
|
|
|---|---|---|
Attachment Response の遅延時間を設定します。 |
QoS サポート
QoS のサポートは、エアーリンク QoS とネットワーク上のマッピングの両方を意味します。BWG は、適切なサービス フローを作成するために使用する BS に対して、QoS パラメータを送信する責任があります。
ホストによっては、追加の QoS パラメータが与えられていることがあります。
ホストの IP アドレスに対応する新しい R6 ベアラ（サービス フロー）が作成されます。複数のホストがこのサービス フローを使用できます。
ホストから新しい R6 サービス フローへのマッピングが作成され、RR-Request を介して BS/MS に通知されます。
BWG リリース 1.0 以上では、次のサポートがあります。
• CLI を使用した事前プロビジョニング済み QoS のサポート
• 個別クラスとしてマークされたシグナリング トラフィックのサポート
• Diffserv クラスは、分類子に基づく各サービス フローに対応するように、BS および BWG によってマッピングされ使用されます。
QoS の設定
BWG で QoS の設定を行うには、次のタスクを実行します。
設定例
設定の確認
BWG の QoS 値を確認するには、show wimax agw subscriber コマンドを使用します。QoS の統計情報の出力の例は、次のとおりです。
表 2-5 および 表 2-6 に 802.16 の QoS クラスおよびサービス パラメータを示します。
|
|
|
|
|
|
|
|---|---|---|---|---|---|
|
|
|
|
|---|---|---|
| リアルタイムでは、パケットは固定サイズで定期的に送信されます（たとえば、ボイス コーデック、ATM CBR、E1/T1 over ATM）。 |
||
| 非リアルタイム サービス フローでは、可変サイズ、通常のデータ許可バーストが必要とされます（たとえば、インターネット アクセス、ATM GFR）。 |
||
ユーザ グループ管理
BWG でユーザ グループを設定するには、次のタスクを実行します。
設定例
アイドル タイマーのサポート
BWG では、ユーザ グループのアイドル タイマーが設定できます。タイマーの時間内にデータ トラフィックがない場合、SS/MSS が登録解除されます。認証フェーズ中に AAA サーバからアイドル タイムアウトがダウンロードされます。
ユーザ グループベースのメンテナンス モード、表示、および消去
特定のユーザ グループに関連付けられたすべてのユーザを消去し、AAA アトリビュートを更新したい場合があるとします。その場合、ユーザ グループ レベルの表示および消去コマンドが必要とされます。メンテナンス モードを使用すると、オペレータが必要に応じてすべての加入者を消去できるようにするために、新しい CPE が特定のユーザ グループに入らないようブロックできます。
ユーザ グループはセッション ハンドルのリストを保持しているため、内部でセッションを追跡できます。このハンドル リストが表示および消去に使用されます。
セッションがユーザ グループに割り当てられるたびに、ユーザ グループのメンテナンス モードが確認されます。セッションは常に 1 つのユーザ グループにしか割り当てられませんが、セッションは有効期間内に複数のユーザ グループを受け入れることができます。これは非 EAP セッションが本来、未認証のユーザ グループに割り当てられるものであり、AAA の応答によって BWG が他のユーザ グループをセッションに再割り当てできるようにするためです。この場合、受け入れたユーザ グループのいずれかのメンテナンス モードがオンになっている場合、CPE が拒否されます。
デフォルトでは、メンテナンス モードはディセーブルです。非 EAP の場合、各着信 CPE は最初に未認証のユーザ グループに割り当てられます。したがって、メンテナンス モードが未認証のユーザ グループでイネーブルになっている場合、新しい非 EAP の CPE が BWG に入ることはありません。
メンテナンス モード機能をイネーブルにするには、次のタスクを実行します。
|
|
|
|
|---|---|---|
ユーザ グループに割り当てられたセッションを表示するには、次のタスクを実行します。
router#show wimax agw user-group name user-group-name [brief] |
ユーザ グループに関連付けられたセッションを表示するには、次のように入力します。
router#clear wimax agw subscriber user-group name group-name [local] router#clear wimax agw subscriber user-group any [local] router#clear wimax agw subscriber user-group unauthenticated [local] |
セッション タイマーのサポート
BWG では、ユーザ グループのセッション タイマーまたは絶対タイマーを設定できます。タイマーの期限が切れると、加入者が登録解除されます。認証フェーズ中に AAA サーバからセッション タイムアウトがダウンロードされます。
Mobile Subscriber Station の登録解除
Cisco BWG リリース 1.0 以降では、Path Deregistration メッセージングの結果として Network Exit がサポートされます。
Mobile Subscriber Station を登録解除するには、次の 2 つの方法があります。
Mobile Subscriber Station による登録解除
ステップ 1 SS が DREG-REQ メッセージを BS に送信し、登録解除プロシージャを開始します。
ステップ 2 BS が Data Path De-Reg Request を BWG に送信します。
ステップ 3 BWG が、アクション コード（0x04 に設定）を持つ Data Path De-Reg Response を BS に送信し、登録解除プロシージャを許可します。
ステップ 4 BS が DREG-CMD を SS に送信し、SS を登録解除します。
ステップ 5 BS が Data Path De-Reg Ack を BWG に送信し、トランザクションを完了します。
ステップ 1 MS が削除されるよう指示する Data Path De-Reg Request メッセージを BWG が BS に送信します。
ステップ 2 BS がエアーリンク経由で DSD-REQ を送信し、特定のサービス フローを登録解除します。
ステップ 3 BS が SS からサービス フローの終了を指示する DSD-RSP を受信します。
ステップ 4 BS がサービス フローの終了を指示する Data Path De-Reg Response を BWG に送信します。
ステップ 5 BWG が Data Path De-Reg Acknowledgement を送信し、トランザクションを終了します。
登録解除要求での Deregistration Reason TLV
リリース 1.4 では、Path Deregistration Request が拡張され、次の論理に基づいた Registration Type TLV に加えて、追加の TLV である Deregistration Reason TLV が含まれています。
• 認証の失敗（つまり、Access-Reject の自動プロビジョニングがないか、AAA に到達できません）
• Access-Accept で受信された CPE サービス状態のアトリビュートによって、CPE がブラックリストに載るよう指示（非アクティブ）
• 内部エラー（つまり、保護タイマーのタイムアウト、セッション タイマーのタイムアウトなど）
表 2-7 に Deregistration Reason TLV の値の詳細を示します。
|
|
|
|
|
|
|
|
128：認証の失敗（AAA で CPE が見つからないか、自動プロビジョニングがイネーブルではありません） |
|
|
|
|
|
BWG は、EAP および PAP で認証された両方のユーザに対してこの機能をサポートします。
（注） Deregistration Reason TLV はオプションであり、6 および 130 以外の値に一致する場合に限り含まれます。
（注） アドレス割り当てのタイムアウトは、登録解除理由コードの「6：アドレス割り当てタイマーの終了」および「130：オペレータによる CPE リセットの指示」が使用されないため、BWG でサポートされません。
AAA Accounting Start-Stop-Interim
BWG は各サービス フローのアカウンティング情報をサポートします。時間ベースの Interim アカウンティングの更新だけがサポートされます。BWG は各サービス フローをサポートし、各サービス フローのタプル（Acct-Session-Id + Acct-Multi-Session-Id + PDFID）のアカウンティング レコードの一意のセットを生成します。各サービス フローは、GRE キーによって一意に識別されます。指定した MS には複数のサービス フローを作成できます。
（注） セッションごとのアカウンティングはこのリリースではサポートされていません。
BWG によって送信されるすべてのアカウンティング レコードでは、トラフィックの送信先のモバイルの背後にどのホストがあるかにかかわらず、Framed-IP-Address フィールドがモバイルの IP アドレスに設定されます。
• Accounting Start：新しいサービス フローが作成されたときに BWG がこのメッセージを AAA サーバに送信します。冗長 BWG 設定の場合、スタンバイ BWG がアクティブになったときに限り Accounting Start メッセージを送信します。Accounting Start がトリガーされるのは、サービス フローの作成が成功したときです。初期サービス フローの場合、アカウンティング開始レコードが送信されるのは IP アドレスがユーザに割り当てられた後です。補助サービス フローの場合、フローが BS で正常にオープンされるとすぐにアカウンティング レコードが送信されます。
BWG リリース 2.2 以降では、アカウンティング開始レコードの Framed-IP-Address フィールドの送信の遅延を設定できます。Framed-IP は多くの場合、フロー アカウンティングのアカウンティング開始レコードに含まれていません。初期サービス フローの場合、フローの作成時にアカウンティング開始レコードが送信されてから加入者のホストが作成されます。BWG リリース 2.2 以降では、ホストが作成されるまでアカウンティング開始レコードの送信を遅延させることができます。遅延を設定するには、 [no] aaa accounting flow start include-framed-ip [delay] コマンドを使用します。デフォルトでは、この機能はディセーブルです。イネーブルの場合、デフォルトの遅延は 3 秒に指定されています。遅延に指定できる値の範囲は 1 ～ 20 秒です。
• Accounting Interim Update：定期的なアカウンティング更新メッセージが設定されている場合、BWG は Accounting Update メッセージを生成します。アカウンティングの更新は、時間に応じてトリガーされるか、設定時に行われます。タイマーに指定できる最小の値は 1 分です。
• Accounting Stop：BWG は、サービス フローが削除されるか、MS が削除を完了したときに Accounting Stop メッセージを送信します。
アカウンティング レコードで送信されるアトリビュートを 表 2-8 に示します。
Cisco BWG リリース 1.4 では、AAA からの Service State アトリビュートのサポートが追加されています。アトリビュート タイプは「Cisco-VSA」で、フォーマット タイプは「string」です。このアトリビュートは、CPE がブラックリストに載っているかどうかを示します。
BWG は、Access-Accept に Service State アトリビュートが含まれていると見なします。BWG でこの実装を支援するために、AAA は Access-Accept だけを持った Service State アトリビュートを返すように設定されています。Access-Reject が送信されたときに Service Attribute は含まれていません。BWG は、EAP と PAP 認証済みユーザの両方に対してこのアトリビュートをサポートします。
AAA アカウンティングの設定
BWG でアカウンティング機能をイネーブルにするには、次のタスクを実行します。
Accounting Start 応答
現在、アカウンティング応答メッセージは BWG で処理されません。BWG リリース 2.0 では、フロー アカウンティングがイネーブルになっている場合、Accounting Start 応答が受信されないかぎり、フローはトラフィックの処理を開始しません。
この機能はユーザ グループ単位でイネーブルになります。デフォルトでは、この機能はイネーブルではありません。この機能をイネーブルにするには、次のタスクを実行します。
|
|
|
|
|---|---|---|
router(config)# wimax agw user group-list wimax |
Accounting Start 応答が受信されたあとに BWG をイネーブルにしてフロー アカウンティングのトラフィックを処理します。 |
設定例
設定の確認
次に、アカウンティング設定を確認するのに使用される、show wimax agw subscriber コマンドの例を示します。
次に、AAA のアカウンティング開始の RADIUS の出力例を示します。
次に、AAA のアカウンティング停止の RADIUS の出力例を示します。
WiMAX 固有の VSA
• Wimax 機能：WiMAX リリース、アカウンティング機能指定、ホットライン機能、および Access Request における AAA へのBWG のアイドル モード通知機能を表します。
• GMT タイムゾーン オフセット：GMT 時間に対して、NAS でのローカル時間の現在のオフセットを秒単位で表します。
• Packet Data Flow-Id（PDFID）：このアトリビュートの値は、同じパケット データ フローからのすべての記録に一致します。PDFID は CSN によって割り当てられ、すべての引き継ぎのシナリオを通じて変更されません。リリース 1.0 以降では、BWG はセッションでフローの PDFID を生成します。
• ベース ステーション ID：NAP およびその NAP 内のベース ステーションを一意に識別します。BWG はこのアトリビュートで R6 BS ID を転送します。
• AAA セッション ID：ネットワークに入るときにホーム ネットワークによって WiMAX セッションに割り当てられる、一意のレルム単位の ID。そのセッションのすべての後続の AAA パケットに値が含まれます。
AAA ベースのホットライン
ホットラインは、パケット データ サービスへのアクセスが認証されなくなる可能性のある問題をユーザに知らせる機能です。ユーザがホットラインを受信すると、パケット データ サービスがホットライン アプリケーション（Cisco ISG など）にリダイレクトされ、ユーザに理由が通知されます。ホットラインの理由がユーザに通知されると、通常のパケット データ サービスは再開されます。
ユーザがホットラインを受信できるのは、パケット データ サービスの開始時、または AAA ベースの Change of Authorization（CoA）があるセッションの途中です。セッションの起動時には、ユーザのセッションにホットラインを通知するのに AAA Access Accept が使用されます。セッションの途中でセッションがホットライン プロファイルの詳細を持つ AAA CoA を受信した場合、ユーザのデータ トラフィックがリダイレクトされます。同様に、現在ホットラインを受信しているセッションのホットラインを停止することができます。
• BWG による、AAA Access Accept アトリビュートに基づいた新しいセッションのホットラインのサポート
• BWG による、AAA CoA に基づいたアクティブ セッションのホットラインのサポート
• アップリンク トラフィックとダウンリンク トラフィックのホットラインの使用時の、BWG によるパケット リダイレクションのサポート
• BWG による AAA からの加入者単位でのホットラインのサポート
• トラフィックのリダイレクションは、データ パケットだけに適用。DHCP などのシグナリング パケットはリダイレクションの対象外
• IP リダイレクションおよび HTTP リダイレクションのこのリリースでのサポート
（注） ホットライン中のダイナミック QoS およびパケット フィルタリングは、このリリースではサポートされません。
ホットラインのトリガー
次にユーザがホットラインを受信していることを HAAA が示す 2 つの方式を説明します。
HAAA が RADIUS メッセージにホットラインのプロファイル ID を送信します。ホットラインのプロファイル ID は、事前に割り当てられた一連のルールを選択します。これにより、ユーザのパケット データ セッションがリダイレクトおよび（または）ブロックされます。プロファイル ベースのアプローチは、このリリースでサポートされています。
HAAA は RADIUS メッセージに実際のリダイレクション ルール（HTTP または IP）およびフィルタ ルールを送信します。これにより、ユーザのパケット データ セッションがリダイレクトおよび（または）ブロックされます。
上記の 2 つのアプローチの違いは、ネットワーク インテリジェンスが置かれている場所にあります。AAA プロファイル ベースのホットラインは、BWG がホットラインに関するほとんどのネットワーク インテリジェンスを保持することを指示し、AAA サーバは単にトリガーするためにプロファイルを使用します。
また、AAA はルール ベースのアプローチのホットライン中に BWG が実行する詳細アクションを指定する必要があります。このシナリオでは、BWG は AAA が指示することをただ実行するだけです。
（注） ルール ベースのホットラインは、このリリースではサポートされていません。
（注） 上記の 2 つの方式は、混在させることはできません。
プロファイル ベースのホットラインでは、次の条件が適用されます。
ホットラインがイネーブルの場合、アップストリーム パケットではデフォルトでパケットをドロップします。アップストリーム方向のホットライン プロファイルの下にフィルタ ルールが設定されていない場合、すべてのアップストリーム パケットがドロップされます。ホットラインがイネーブルの場合であっても、特定のパケットが BWG を通過することを許可できます。これらのパケットは、ホットライン サーバ自身、HTTP、DNS パケットなどを宛先とするパケットを含みます。URL を指定し、パケットが通過する必要のあるサーバを示すことができます。
アップストリーム パケットのフィルタ ルールは、IP パススルー、HTTP リダイレクトの順で適用されます。
ホットラインがイネーブルの場合、ダウンストリーム パケットではデフォルトでパケットをドロップします。ダウンストリーム方向にフィルタ ルールが設定されていない場合、すべてのパケットがドロップされます。
AAA サーバからの Change of Authorization（CoA）メッセージでサポートされている必須アトリビュートは、User-Name、Calling-Station-Id、および AAA-Session-Id の各アトリビュートです。Calling-Station-Id アトリビュートは、BWG 上の特定のユーザを一意に識別するために使用します。
AAA アトリビュート
次にホットライン機能の AAA Access Accept に関連付けられた新しいアトリビュートを示します。これらのアトリビュートは、新しいセッションでのホットラインをサポートするために使用します。
|
|
|
|
Request |
Challenge |
Accept |
Reject |
[a] Hotline-Profile-ID が含まれている場合、HTTP-Redirection-Rule、IP-Redirection-Rule、および Filter-Rule は含まれません。これらが存在する場合、受信側が自動的にアトリビュートを破棄します。
[b] セッションがホットラインを受信し、このアトリビュートが指定されている場合、NAS はアカウンティング メッセージにこのアトリビュートを含んでいます。
次にホットライン機能の AAA CoA に関連付けられた新しいアトリビュートを示します。これらのアトリビュートは、アクティブなセッションでのホットラインをサポートするのに使用されます。
|
|
|
|
|
|
|
User-Name および AAA-Session-ID に含まれている NAI は、NAS で一意のセッション ID を作成します。 |
|||||
[a] Hotline-Profile-ID が含まれている場合、HTTP-Redirection-Rule、IP-Redirection-Rule、および Filter-Rule は含まれません。これらが存在する場合、受信側はアトリビュートを破棄します。
プロファイル ベースのホットラインの設定
BWG がプロファイル ベースのホットラインを実行するよう設定するには、次のタスクを実行します。
SLA プロファイルと同様に、AAA サーバはホットライン プロファイルを選択するだけです。ホットラインをディセーブルにするには、AAA サーバが「hotlining-exit」（大文字と小文字は区別されません）という特別なプロファイル名を選択します。この特別なプロファイル名を受信すると、BWG は加入者の通常のトラフィックを再開します。混乱を避けるため、この特別なプロファイル名を通常のホットライン プロファイル名に使用しないでください。
BWG で CoA ハンドリング機能をイネーブルにするには、次のタスクを実行します。
|
|
|
|
|---|---|---|
|
|
ユーザのホットライン状態を適切に考慮するには、ユーザのホットライン状態がアカウンティング ストリームに記録されている必要があります。AAA から受信された「Hotlining Indication」アトリビュートがアカウンティング開始/終了の記録の一部として含まれる必要があります。
アクティブ/中間セッション ホットライン
1. セッションの起動中に BWG が AAA Access Request を指示します。
2. AAA が Access Accept で応答します。
3. アクティブ セッションが起動し、AAA が加入者にホットラインを送信しようとします。
4. AAA からホットラインのプロファイル ID が必要とされていることを示す COA 要求が送信されます。
6. BWG が各フローおよびホストの AAA に Accounting Stop を送信します。
7. BWG が各フローおよびホストのホットライン ID を持つ AAA に Accounting Start を送信します。
8. ホットライン セッション タイマーが開始されます。AAA から Session-Timeout の値が送信されていない場合、この値はデフォルトで 3600 秒に設定されます。Session-Timeout アトリビュートで指定された期間が経過し、セッションがホットライン化されているままの場合、セッションのティアダウンが開始します。
9. BWG により、コンフィギュレーションで指定された所定のフィルタ ルールがアップストリームまたはダウンストリーム トラフィックに適用されます。
10. AAA が変更され、加入者の通常のトラフィック フローが再開されます。
11. Hotline Profile ID = hotlining-exit であることを示す COA 要求が AAA から送信されます。
13. BWG は各フローおよびホストについて Hotlining Indication を含む Accounting Stop を AAA に送信します。
新しいセッションのホットライン化
1. 特定の加入者をホットライン化するため AAA がプロビジョニングされます。
2. BWG は AAA Access Request を AAA サーバに送信します。
3. AAA は Access Accept で応答し、ホットライン プロファイルを強制適用します。
4. Accounting Start によりセッションのホットライン化が指示されます。
5. BWG が、コンフィギュレーションで指定された所定のフィルタ ルールによりアップストリームまたはダウンストリーム トラフィックへのセッションを確立します。
6. AAA が、COA によるセッションのホットライン化を終了するよう指示します。
8. BWG がアカウンティングのホットライン化を停止します。
9. BWG が通常のフロー/ホストのアカウンティングを開始します。
（注） ホットライン セッションの通常の Accounting Start を最初から開始しないでください。
AAA パケット オブ ディスコネクト メッセージ（PoD）
この機能により、接続済みのセッションを終了することができます。PoD（パケット オブ ディスコネクト）メッセージは RADIUS Access Request パケットで、セッションが RADIUS Access Accept パケットにより許可された後に AAA サーバがユーザとの接続を切断する場合に使用されます。
PoD メッセージのデータ パラメータは、次の RADIUS アトリビュートです。
RADIUS Disconnect-ACK メッセージの送信時には、追加のパラメータは使用されません。
RADIUS Disconnect NACK メッセージのアトリビュートを次に示します。
|
|
|
|
|
|
PoD を受信するとセッションは終了し、R6 Data Path De-registration Request メッセージによりデータ パスが BS に対してクリアされます。Disconnect-Request パケットは UDP ポート 3799 に送信され、識別属性により NAS（および終了するユーザ セッション）を識別します。NAS は RADIUS サーバにより送信された Disconnect-Request パケットに対して、関連付けられたすべてのセッション コンテキストが破棄されている場合（かつ、ユーザ セッションの接続が解除されている場合）には Disconnect-ACK、セッションの接続解除および関連付けられたすべてのセッション コンテストの破棄を NAS が実行できなかった場合には Disconnect-NAK で応答します。
|
|
|
|
|---|---|---|
|
|
server-key：共有秘密テキスト ストリングを設定します。 string：ネットワーク アクセス サーバとクライアント ワークステーションの間で共有する共有秘密テキスト ストリングです。この共有秘密ストリングは両方のシステムで同じである必要があります。 |
PoD 機能の検証とトラブルシューティングを行うには、次の作業を行います。
|
|
|
|
|---|---|---|
|
|
AAA ベースの固定 IP アドレスのプロビジョニング
この機能を使用すると、MS ホストで使用できる固定 IP アドレスを指定できます。Framed-Route アトリビュートは変更されません。Framed-Route が AAA からダウンロードされると、固定 IP も検証されます。また、固定 IP ホストを許可するには、ユーザ グループで ip static-allowed コマンドを設定する必要があります。
BWG では、複数のホストに同じ IP アドレスが割り当てられないようにする必要があります。AAA プロビジョニング エラーが発生した場合、同じ VRF コンテキストで IP アドレスの重複がないか確認されます。
固定 IP アドレス リストが AAA からダウンロードされ、ip static-allowed コマンドがユーザ グループで設定されている場合、show wimax agw subscriber コマンドを実行すると次のように表示されます。
固定 IP アドレス リストが AAA からダウンロードされ、ip static-allowed コマンドがユーザ グループで設定されている場合、show wimax agw subscriber internal コマンドを実行すると次のように表示されます。
ハンドオフ
WiMax では、ベース間と BWG 間の 2 種類のハンドオフを使用できます。BWG リリース 1.0 以降では、ベース間ステーション ハンドオフしか使用できません。
BS 間ハンドオフには、非制御ハンドオフと制御ハンドオフがあります。制御ハンドオフでは、ターゲット BS はハンドオフが実際に発生する前に R8 インターフェイス経由で稼動 BS からセッションの情報を取得します。非制御ハンドオフは、ターゲット BS が BWG でハンドオフを発生させる前にベース ステーション間で情報を交換できない場合に発生します。非制御ハンドオーバーは初期ネットワーク エントリと同様に扱われますが、このハンドオーバーについては、BWG は可動ベース ステーションで登録されたパスの登録を解除します。リリース 1.0 以降では、登録解除メッセージを稼動 BS に送信するための試行が 1 回行われると、ASN と SBS の間の登録解除ハンドシェイクが完了しているかどうかにかかわらず、ハンドオフが実行されます。
ハンドオフ時の中間アカウンティングの更新
リリース 2.2 以降では、ハンドオフ時に中間アカウンティングの更新を行うように BWG を設定できます。モバイル ステーション（MS）が他のベース ステーションに対してハンドオーバーを行うと、アカウンティングの更新が AAA サーバに送信されます。
中間アカウンティングの更新機能が有効になっていると、BWG によりフローベースのアカウンティングとホストベースのアカウンティングの両方についてアカウンティングの更新が送信されます。
中間更新の一部として送信されるアトリビュートは、ハンドオフ時に送信されるアカウンティングの更新の一部でもあります。また、新しい Cisco VSA 「Handover-Indicator =1」が含まれています。BS ID はターゲット ベース ステーション IP アドレスの BS ID に対応するように更新されます。
中間アカウンティングの更新は、次の機能については行われません。
aaa accounting update handover コマンドを使用すると、中間アカウンティング機能が有効になります。
ハンドオフ時の中間アカウンティングの更新を設定するには、次の作業を行います。
次の表は、中間アカウンティングの更新の AAA-Authentication アトリビュートを示しています。
|
|
|
|
|
|
|
|---|---|---|---|---|---|
UDR の生成時に MS を提供する NAP-ID ベース ステーションを一意に識別するオクテット ストリング。アカウンティングの更新がハンドオフにより発生している場合は、ターゲット BS に置き換えられます。 |
非制御ハンドオフ
非制御ハンドオーバーを示す信号はパス登録要求メッセージを使用して BS から BWG に送信されます。このメッセージには、ソース BS で確立済みの各サービス フローに関する情報が格納されています。また、ダウンリンク フローに使用する DP-IP も格納されています。
（注） セッションは同じ BWG で維持されるため、デバイスや加入者の再認証は必要ありません。
（注） 非制御ハンドオフでは、ターゲット BS はMS ネットワーク エントリを発生させます。このエントリで MS の認証が行われます。
BWG は以前の BS のパスの登録解除を開始します。この登録解除は BWG によりスケジュール設定されます。新しい BS へのハンドオフが正常に完了した直後に発生するとは限りません。
ハンドオフ時にベアラ パス データをバッファに入れる必要はありません。ハンドオーバー時に BWG で受信したダウンリンク データは破棄されます。
BWG がハンドオフのトリガーを受信する前にデバイスはすでにターゲット BS のサービス領域に移動しているため、以前のパスを通過中のトラフィックはすべて失われます。
ターゲット BS と BWG の間のハンドオフ処理が完了する間にデバイスが新しい BS に移動している場合があります。ハンドオーバーは制御されていないため、新しいハンドオフ イベントが処理される前に現在のターゲット BS へのハンドオフが完了します（必要に応じて R6 メッセージの再送信も行われます）。
ハンドオーバー交換は次の 3 種類のメッセージで構成されます（制御ハンドオフの場合のみ）。
• Path Registration Request（ターゲット BS から BWG に送信）：次の項目があります。
– SF INFO（SFID を含む）、Reservation Action（[Create] に設定）、Direction、QoS パラメータ、Data Path Info、GRE Key（ダウンリンク フロー用）
• Path Registration Response（BWG からターゲット BS に送信）：次の項目があります。
– SF INFO（SFID を含む）、Reservation Action（[Success] に設定）、Direction、Data Path Info、GRE Key（アップリンク フロー用）
• Path Registration Acknowledgement（ターゲット BS から BWG に送信）：次の項目があります。
BWG がハンドオーバーを許可しない場合、BWG は応答として「reject cause code TLV」を送信します。
BWG が目的のサービス フローのサブセットに対してのみハンドオーバーを許可した場合、このハンドオーバーは拒否されます。
セカンダリ フローが欠落していてもハンドオフは拒否されませんが、プライマリ フローが欠落している場合は拒否されます。
SBS に送信される登録解除要求と ACK の Registration Type は [Handover] となりますが、SBS からの登録解除応答は [Network exit] となります。これは予期された動作です。このメッセージを受信しても、BWG は「reject cause code TLV」が設定された ACK を送信しません。
制御ハンドオフ
制御ハンドオフが発生するのは、ターゲット BS が BWG でハンドオフをトリガーする前に、現在の BS とターゲット BS が情報を伝達し、サービス フロー、分類子などの詳細情報を交換できる状態になっている場合です。つまり、BWG ハンドオフ トリガーを送信する前に、ターゲット BS にはモバイル デバイスに関連するすべての情報が存在することになります。このトリガーは、モバイル デバイスが 802.16e の手順によりターゲット BS に接続済みの場合に発生します。制御ハンドオフが BWG で発生した場合、BS から Path Registration Request メッセージが送信されます。この場合、事前に認証交換は行われません（認証交換はネットワーク エントリ イベントで発生します）。
次のフロー シーケンスは、制御ハンドオフ時に発生するイベントを示しています。
ステップ 1 ターゲット ベース ステーションは Path Registration Request を BWG に送信します。このメッセージには、稼動ベース ステーションから受信したサービス フロー情報が格納されています。
ステップ 2 BWG は Path Registration Response で応答します。これにより、ターゲット ベース ステーションでのデータ パスの登録が許可されます。
ステップ 3 ターゲット ベース ステーションは Path Registration Acknowledgement で応答します。
ステップ 4 BWG は稼動ベース ステーションに Path Deregistration Request を送信します。
ステップ 5 稼動ベース ステーションは Path Registration Acknowledgement で応答します。
ステップ 6 BWG は Path Deregistration Acknowledgement でこの応答を確認します。
ステップ 7 ターゲット ベース ステーションは BWG に Context Report を送信します。
ステップ 8 BWG は Context Acknowledgement で確認します。
ステップ 9 ターゲット BS は CMAC Key Count Update メッセージを送信し、BWG は CMAC Key Count Ack メッセージで応答します。
設定の確認
BWG のハンドオフ統計情報を表示するには、show wimax agw statistics section handoff コマンドを使用します。
セキュリティ コンテキスト交換
BS でエアーリンクをセキュリティ保護するには、BWG からキー関連情報を取得する必要があります。BS やデバイスの観点から見れば、データ パスの登録が完了し、BS がキー関連情報を受信するまで、ハンドオフを正常に実行することはできません。BS は両方の処理の実行を担当しています。BWG は BS とのコンテキスト交換を、ハンドオーバーとはまったく別のイベントとして処理します。
コンテキスト交換はどの時点でも発生します。BS へのキー関連情報の転送には、AK 転送プロトコルが使用されます。この情報は AK、AKID、AK ライフタイム、AK シーケンス番号、EIK で構成されています。
PMK の有効期間が経過した場合、新しい PMK を作成する必要があります。
セキュリティ コンテキスト交換には 2 つのメッセージが使用されます。
• Context Request（ターゲット BS から BWG に送信）：次の項目があります。
R6 インターフェイスでのキープアライブのサポート
キープアライブ メカニズムは BWG と Base-Station（BS;ベース ステーション）の間の R6 インターフェイス経由で使用します。これにより、各ネットワーク要素（NE）は障害の検出やピアの再起動ができるようになります。NE は障害の検出やピアの再起動を行う場合に所定の処理（対応する MS コンテキストを規定の方法で消去するなど）を行う場合があります。キープアライブ メカニズムでは、ベース ステーションと BWG の間で Keepalive-Req メッセージと Keepalive-Rsp メッセージが定期的に送信されます。
キープアライブ メッセージの送信は、ベース ステーションと BWG の双方で個別にイネーブルまたはディセーブルにできます。
（注） BWG または BS が R6 Keepalive-Req メッセージを受信すると、ベース ステーションに加入者がない場合でも Keepalive-Rsp 応答を送信する必要があります。
各 R6 インスタンスについて、ベース ステーションと BWG には次のパラメータが保存されています。
N：連続して発生しているキープアライブ障害の件数。初期値は 0 です。
Pm：セッションの有効期間。ピアの再起動の検出時にセッションを消去する場合に使用します。
R：最終リセット時刻（LRT）。初期値はノードの再起動時刻です。
キープアライブ機能をイネーブルにするには、ベース ステーション グループ サブモードで次の作業を行います。
キープアライブ機能の動作
1. ベース ステーションまたは BWG が Keepalive-Req を送信し、タイマー Tk を開始します。
2. Keepalive-Rsp の受信時に N の値が 0 になります。
3. Tk の有効期間が経過すると、ノードは次の Keepalive-Req を送信します。最後の Keepalive-Req メッセージが、タイマー Tk の有効期間が経過する前に受信されなかった場合、N の値が増加します。
4. N の値が M と等しい場合、N は 0 にリセットされ、リモート ノードで確立されているすべての R6 セッションが、ネットワーク主導 MS ネットワーク終了と同じ手順で終了されます。
• 最初の加入者（MS）が BS からのネットワーク エントリを実行すると、BWG は Keepalive-Req メッセージを BS に送信します。
• BS からのすべての加入者が登録解除しネットワークを終了すると、BWG は BS への Keepalive-Req メッセージの送信を停止します。
• BWG は上記の手順で定期的に Keepalive-Req を BS に送信します。
• BWG は BS に送信するすべての Keepalive-Req メッセージと Keepalive-Rsp メッセージに LRT TLV を記録し、最終再起動時刻を通知します。
• BWG は BS から Keepalive-Req を受信し、BS に Keepalive-Rsp で応答します。
• BWG から BS に対して送信されるすべての Keepalive-Req について、BWG は上記のように BS から Keepalive-Rsp を受信します。
• BWG は BS からの Keepalive-Req メッセージまたは Keepalive-Rsp メッセージから LRT 値を抽出します。BWG は最初に LRT 値を取得した時点で LRT 値を保存します。
• それ以降に BS から Keepalive-Req と Keepalive-Rsp を受信すると、BWG は受信した LRT 値を保存済みの値と比較します。受信した LRT 値が保存済みの値と異なる場合、BWG は BS が再起動されていると判断してすべての加入者セッションをクリアし、BS の新しい LRT 値を保存します。新しいセッションがクリアされないようにするため、Pm より古いセッションはすべてクリアされます。
LRT 値は SR アクティブと SR スタンバイの間で同期されます。SR スタンバイがアクティブになると、キープアライブ機能は中断されることなく同じ LRT 値で再開されます。
reset-bs オプションによる CLI ベースのキープアライブ
従来は、BS と BWG はセッションで同期されない場合がありました。この問題を解決するには BWG をリロードするしかないものと考えられていました。BWG を再起動すると、キープアライブを送信してすべての BS をリセットできます。しかし、BWG をリロードするとすべての BS や CPE に影響が生じるため、この操作は乱暴な操作であると考えられています。
現在は、BWG と BS が同期状態にない場合、該当する BS をリセットできます。
BWG が特定の BS を再同期できるようにするには、次の作業を行います。
|
|
|
|
|---|---|---|
上記の設定では、10.10.10.10 が BS の IP アドレスです。reset-bs キーワードを使用すると、BWG はその特定の BS のセッションをすべて消去します（セッションが存在する場合）。さらに、BWG はキープアライブ メッセージを（現在のリセット時刻で）その BS に送信して BWG が再起動したことを通知し、これにより BS は確実にすべてのセッションを消去します。この特殊なキープアライブは、定期的なキープアライブがディセーブルの場合でも必ず送信されます。この場合再送信は実行されないため、コマンドは必要があれば複数回実行できます。
BWG に BS への加入者セッションがない場合、BS のパスは存在しません。BS のパスがない状態で CLI がトリガーされると、BWG は KA 要求を BS に送信しません。
show brief コマンドによるスタティック ホストとダイナミック ホストの識別
ハッカーは一般的に固定 IP を使用してネットワークのぜい弱性を探り当てます。このため、BWG にはすべてのホストとその固定 IP アドレスのリストを表示するコマンドが必要です。
この機能は、既存の show wimax agw sub brief host コマンドを強化したものです。出力結果の各行の末尾には「D」または「S」が追加されます。これはそれぞれダイナミック ホストとスタティック ホストを表します。
ホスト キャッシング機能では、ダイナミック ホストは [Idle Time] が「xxx」になっています。現在は、ダイナミック ホストが LRU アルゴリズム用にアイドル時間を記憶する必要があるため、このような形にはなっていません。
セッション冗長性
BWG セッション冗長性アーキテクチャでは、1:1 冗長性モデルのユーザ セッション フェールオーバー機能があり、すべてのアクティブ BWG に対してスタンバイ BWG が存在します。アクティブ BWG は必要に応じて状態同期のための状態情報をスタンバイ BWG に送信します。アクティブ BWG で障害が発生した場合、既存のすべてのセッションにサービスを提供するために必要な状態情報はスタンバイ BWG にあります。その後、スタンバイ BWG がアクティブ BWG となり、ユーザ セッションのサービスを開始します。これによりセッション冗長性が実現されます。元のアクティブ BWG がオンライン状態に戻ると、この BWG は現在のアクティブ BWG に対するスタンバイ BWG となり、現在のアクティブ BWG から既存のすべてのセッションの状態情報を取得します。
BWG は SAMI ブレードにホストされており、カードツーカード冗長性がサポートされています。つまり、SAMI で 1 つのプロセッサ ユニットの障害が発生すると、カード全体が切り替えられます。
（注） Cisco BWG リリース 1.1 では、セッション冗長性は引き続きサポートされています。しかし、各サービス フロー方向の分類子情報と CS の種類の情報の設定が、スタンバイ側とアクティブ側の両方で同一である必要があります。ホスト データ構造に新しく導入されたフィールドは、アクティブ側からスタンバイ側に同期されます。
BWG セッション冗長性とハイ アベイラビリティ インフラストラクチャ
BWG セッション冗長性は、Cisco IOS Hot Standby Routing Protocol（HSRP）、Cisco IOS Check-point Facility（CF）、Redundancy Framework（RF）、Stream Control Transmission Protocol（SCTP）に基づいて、デバイス間の冗長性とハイ アベイラビリティを実現する機能です。図 2-1 に、IOS HA インフラストラクチャにおける BWG SR のシステム概要図を示します。
加入者管理
加入者情報には、加入者コンテキストに関連するセッションとフローがあり、作成やアップデートが行われる他、最終的には削除されます。
• アドレッシング情報（MS MAC、割り当てられた DHCP アドレスなど）
DHCP と AAA
BWG は DHCP リレー モードをサポートしており、DHCP サーバにより割り当てられたクライアントの IP アドレスを追跡しています。これにより、将来の DHCP メッセージがクライアントからサーバにリレーされるようになります。クライアントの IP アドレスと DHCP サーバの IP アドレスは加入者コンテキストに保存され、スタンバイ側と同期されます。スタンバイ側がアクティブになると、引き続き DHCP メッセージをクライアントから所定のサーバにリレーします（プライマリとセカンダリの 2 つのサーバが設定されている場合があります)。
IOS AAA はこの時点では HA に対応していないため、AAA 関連情報の同期はセッション レプリケーションの一部として実行されます。
ダイナミック同期
アクティブ側で障害が発生した場合にアクティブ側の処理をスタンバイ側が引き継げるようにするため、アクティブ側のすべてのセッションとフローに関する情報は明確な同期ポイントでスタンバイ側にダイナミックに同期されます。セッション、フロー、パスに関連する情報の同期には、個別の TLV が使用されます。新しいセッションまたはフロー イベントのダイナミック同期が実行されるのは、スタンバイ側がホット スタンバイ状態になった後と、バルク同期が完了した後です。
• 初期ネットワーク エントリ時にセッションとフローの情報がスタンバイ側に同期されるのは、Initial Service Flow（ISF;初期サービス フロー）が作成された後のみです。
• ISF が起動すると、アクティブ側で作成された新しいフローはそれぞれ個別にスタンバイ側に同期されます。
• サービス フローに何らかのアップデートが行われると、フローはスタンバイ側に同期されます。
• アドレスの割り当てが発生するたびに、フローはスタンバイ側に同期されます。
• アクティブ側のパスに対する変更はすべてスタンバイ側に同期されます。
• ハンドオフ時には、フロー情報はハンドオフの完了後に限りスタンバイ側に同期されます。クローニングされたフローは同期されません。ハンドオフの結果アクティブ側で新規作成されたフローは、FLOW UPDATE メッセージによりスタンバイ側に同期されます。このメッセージにより、ハンドオフの結果変更されたパラメータが伝送されます。
• アクティブ側からの中間アカウンティング要求の送信後のフロー同期。これにより、FLOW UPDATE メッセージがアクティブ側からスタンバイ側に送信され、中間アカウンティングのアップデートの一部として AAA に送信されるアカウンティング カウンタが所定のメッセージにより伝送されます。
セッション冗長性の設定
• Network Time Protocol（NTP;ネットワーク タイム プロトコル）サーバを設定する。
• アクティブ BWG とスタンバイ BWG で AAA を設定する。
BWG でセッション冗長性を設定するには、次の作業を行います。
設定例
---------------------------------------------------------------
---------------------------------------------------------------
（注） タイムゾーンが変更される場合は BWG をリロードします。
認証
加入者は、セッションまたはフローがスタンバイ側で再作成される前に、アクティブ側で EAP により認証されます。関連付けられた MSK、AK コンテキスト、その他の証明書をセッション ステートフル データとあわせてスタンバイ側に転送する必要があります。地理的冗長性が導入されている場合、このデータを保護する必要があります。スタンバイ側がスイッチオーバーの後にアクティブになり、同じ加入者が新しいアクティブ側で再認証される場合、元のアクティブ側での認証と同じ手順で認証が行われます。
アカウンティング
アカウンティングの開始、停止、中間アップデートはアクティブ側からのみ送信されます。スタンバイ側は、アクティブになった場合を除き、アカウンティング レコードを送信することはありません。
スタンバイ側でのセッションまたはフローの再作成の一部として、IOS AAA データベースに各セッションおよびフローのアカウンティング レコードが登録されます。たとえば、「class」アトリビュートとアカウント セッション ID はアクティブ側からスタンバイ側に同期され、関連するアカウンティング レコードに保存されます。これにより、スタンバイ側がアクティブになると、正しい情報が記録されたアカウンティング レコードを送信できるようになります。
アカウンティング カウンタの同期は、AAA 中間アカウンティング アップデート機能の一部です。AAA 中間アカウンティング アップデート機能がイネーブルの場合、アクティブ BWG はアカウンティング レコードを AAA サーバに送信します。さらに、同じイベントを使用して FLOW UPDATE イベント（AAA サーバに送信されたものと同じアカウンティング カウンタが使用されます）が開始されます。逆に、アクティブ側でこの機能がディセーブルの場合、AAA に対するアカウンティング アップデートがないため、アカウンティング アップデート同期メッセージがスタンバイ側に送信されることはありません。BWG SR 機能単独ではアカウンティング カウンタの同期を実行しません。
アカウンティング セッション ID はアカウンティング イベント（開始、停止、中間）で使用される重要なアトリビュートで、AAA サーバでレコードの生成に使用します。これは 4 バイトの未使用の整数で、ASNWG 内で一意に割り当てられます。さらに、ロールオーバーするまで順番に値が増加していきます。新しいアクティブ側でスイッチオーバー時に一意のアカウンティング セッション ID の生成を継続できるようにするため、新しいアカウンティング セッション ID は元のアクティブ側での最後のアカウンティング セッション ID から始まります。
加入者 IP アドレス
現在、加入者 IP アドレスは DHCP サーバによって割り当てられ、ホスト ルートが挿入されています。スタンバイ側が加入者セッションを再作成すると、同じホスト ルートがスタンバイ側にも挿入されます。スタンバイ側はアクティブになるまで DHCP クライアントとサーバの間での DHCP メッセージのリレーを実行しません。
QoS
BWG リリース 1.0 以降では、フローが作成されてそのフローの QoS パラメータが BS に送信された後に、アクティブ BWG がすべての QoS パラメータをスタンバイ側に同期します。これらのパラメータのうち、スタンバイ BWG に同期されたフローの DSCP コードは、スタンバイ BWG がアクティブになった時点でパケットのマーク付けに使用されます。
統計情報とカウンタ
統計情報とカウンタはスタンバイ側には同期されません。かわりに、スタンバイ側はアクティブ側からのステートフル データの処理時にこれらの情報を再構築し、セッションやフローの作成、変更、削除を行います。たとえば、スタンバイ側でセッションやフローの作成と削除を行うと、スタンバイ側でのセッションやフローの数がアップデートされます。スタンバイ側で受信した R6 メッセージの数は、スタンバイ側がアクティブになり R6 メッセージの受信を開始した時点から累積されていきます。
BWG ロード バランシング
ロード バランサを実行する場合、ロード バランサはすべての BWG の負荷情報を使用して、いずれかの BWG を選択し、BS から受信した NetEntry メッセージ（SS/MS に関連するもの）を選択した BWG に転送します。
Dynamic Feedback Protocol（DFP）が設定されている場合、アクティブ BWG は定期的に負荷情報をロード バランサに送信します。スタンバイ BWG は R6 メッセージの処理やユーザ トラフィックの処理を行わないため、スタンバイ BWG はフィードバックを送信せず、正確な負荷情報も保有していません。スタンバイ側がアクティブになると、スタンバイ側が R6 メッセージの処理とユーザ トラフィックの処理を進めるにつれ、正確な負荷情報が構築されていきます。そのため、現在の正確な負荷についてフィードバックを送信できるようにするための調整期間があります。
データ パスと GRE
フローのデータ パスはスタンバイ側で再作成されます。フローのアップストリームとダウンストリームの両方の GRE キーがスタンバイ側に同期されます。スイッチオーバー時に、新しいアクティブ側は、ローカルで割り当てられたすべての新しい GRE キーが、元のアクティブ側で割り当てられた使用中の GRE キーと競合しないようにします。
バージョン制御
上位のバージョンへのアップグレードは、直前のソフトウェア バージョンからであれば可能です。ソフトウェア バージョンのダウングレードはできません。たとえば、BWG の冗長ペアがバージョン A で実行されていて、次のソフトウェア バージョンがバージョン B である場合、バージョン A から B へのアップグレードは可能です（B から A へのバージョン変更はできません）。この場合、下位のバージョンから同期されたステートフル データを上位のバージョンが理解できることが必要になります。
制限事項
これは設定可能であり、イネーブルにする AAA 中間アカウンティング アップデート機能により設定が異なります。AAA 中間アカウンティング機能がディセーブルの場合、BWG SR はデフォルトではアカウンティング データ/ペイロード カウンタの同期は行いません。これにより十分な処理が行われない場合があります。たとえば、2 件の連続した中間アップデートの間にスイッチオーバーが発生した場合、新しい中間アップデートでは新しいアクティブ側でのカウントのみが送信されるため、前回の中間アップデート以降に累積されたカウントは失われます。また、スイッチオーバーの直前に STOP が失われる場合があります。
（注） スタンドアロン システムの場合、現在の AAA/Radius カウンタは正確に動作します。しかし、セッション冗長性がイネーブルの場合、フロー（Radius の場合はセッション）の経過期間を現在のカウンタにもとづいて算出していると、この経過期間の値が正確でない場合があります。そのため、特定のフローが開始されてから経過した秒数を表す「session_elapsed_time」という ASN-GW から別のアトリビュートが送信されます。
SCTP では確実な転送が行われますが、輻輳が発生したり、再試行回数が最大に達したりすると、セッションのレプリケーションに使用するステートフル データが失われる場合があります。この場合、スタンバイ側でのセッションの再作成は実行されません。スイッチオーバーが発生している場合、このセッションは喪失します。
上記と同じ理由で、セッション削除のためのステートフル データが消失した場合、アクティブ側でセッションが削除されてもスタンバイ側では削除されません。
– 同じ加入者の次のセッションが作成される前にスイッチオーバーが発生しない場合、同じ加入者に対するセッションの新規作成の次回の同期時に、この古いセッションが消去されることになります。
– スイッチオーバーが発生する場合、手動操作やアイドル/セッション タイムアウトなどの機能により消去されるまで、古いセッションが停止します。
コール設定が進行中で、最初の同期ポイントに達していない状態でスイッチオーバーが発生すると、コール設定が打ち切られるため、加入者はコールを再試行する必要があります。
スイッチオーバー
スイッチオーバーが発生すると、トラップが生成されて NMS システムに送信され、アクティブ ユニットで障害が発生し、スタンバイ側がアクティブになったことを通知します。次の動作が想定されています。
• ローカルで割り当てられたすべての新しい GRE キーが、元のアクティブ側で割り当てられた使用中の GRE キーと競合しないようにする必要があります。
• ローカルで割り当てられたすべての新しいアカウンティング セッション ID キーが、元のアクティブ側で割り当てられた使用中のアカウンティング セッション ID キーと競合しないようにする必要があります。
• 新しいセッションの DHCP リレーは設定済みの DHCP サーバに転送されます。
• DFP の負荷情報が再構築され、ロード バランサに送信されます。
次のリストは、スイッチオーバーの原因となるイベントを示しています。
• ソフトウェアのクラッシュや CPU の負荷増大などによるルータのリロードやクラッシュ。
• HSRP が設定に基づきインターフェイスを追跡する場合。インターフェイス フラップ <on-off transition> を検出すると、HSRP は現在のアクティブ側を強制的にリロードし、これによりアクティビティのスイッチオーバーが発生します。
• 手動操作で、アクティビティを現在アクティブなルータから冗長ホット スタンバイ側に切り替えた場合。この操作は次のコマンドで行います。
– redundancy switch-activity force
このコマンドは、アクティビティを現在のアクティブ側から現在のホット スタンバイ側に切り替える場合に使用します。このコマンドを実行すると現在のルータがリロードし、現在のホット スタンバイ側がアクティブになります。また、現在アクティブなルータが再起動すると、ホット スタンバイ状態になります。
これは通常のルータ リロード コマンドで、スイッチオーバーが発生します。現在アクティブなルータがリロードし、現在のホット スタンバイ側がアクティブになります。
BWG ロード バランシング
ロード バランシングの目的は、ベース ステーション間の情報伝達を妨げずに BWG のスケーラビリティを確保することです。このスケーラビリティは BWG 間でのロード バランシングによって実現できます。ロード バランシングでは、BS から見るとクラスタが単一の BWG として表されます。これにより、ベース ステーションの接点は 1 か所となります。また、システムに新規に追加されたどの BWG もベース ステーションのプロビジョニングには影響しません。
（注） サーバ ロード バランシングとセッション冗長性は Cisco 7600 SAMI プラットフォームでのみ使用できます。
BWG のロード バランシングは、IOS サーバ ロード バランシング（SLB）機能に基づいています。BS には SLB のバーチャル IP アドレスが BWG ID として設定されています。ロード バランシングの BWG 選択フローを次に示します。dispatch モードと directed モードの両方を使用できます。SLB では DFP により実 BWG の負荷を検出できます。
（注） リリース 1.0 以降では、SLB スティッキ機能と BWG ハンドオーバー コール フローは使用できません。
初期コンテキスト要求が処理されると、SLB で作成されたセッションは再送信のため維持されます。維持する時間は設定可能です。この時間内に特定の MS/SS についてコンテキスト要求の再送信が検出されると、SLB はこの再送信された要求を同じ実 BWG に転送します。これは最初のコンテキスト要求で選択された BWG です。
SLB では DFP により実 BWG の負荷を検出できます。実 BWG にはそれぞれ確立できるセッション数の上限があります。実 BWG の負荷は、現在存在するセッション数と、確立可能なセッション数の上限、メモリの使用状況、帯域体の使用状況に基づき、この BWG 自体により計算されます。この負荷情報は SLB に送信されます。SLB は、ラウンドロビン方式または最小接続方式で初期コンテキスト要求を実 BWG のいずれかに転送します。DFP により計算された負荷が 100% の場合、BWG はそれ以上のセッションを許可しません。このため、この方式では CAC も使用できます。
BWG の選択
• 初期ネットワーク エントリ段階で、BS は SS/MSS に対応する NetEntry MS Pre-Attachment Request をデフォルトとして設定されている BWG に送信します。
• BWG は NetEntry MS Pre-Attachment Response を BS に送信します。この応答には、代替オーセンティケータ ID の IP アドレスが含まれている場合があります。これにより、これ以降の SS/MSS に対応するトランザクションを処理できるようになります。BS は NetEntry MS Pre-Attachment Response を受信すると、NetEntry MS State Change Ack を送信してトランザクションを完了します。
• これ以降の SS/MSS に対応するトランザクションはすべて、BS と NetEntry MS Pre-Attachment Response メッセージで指定された BWG との間で発生します。
動作モード
• dispatched モード：このモードでは、パケットは実サーバに送信され、元のパケットは変更されません。実サーバではバーチャル IP と同じ IP でループバックが設定されています。実サーバは送信元アドレスとしてバーチャル IP アドレスを使用して応答します。
• directed モード：パケットの送信先 IP アドレスが書き換えられ、BWG の IP アドレスが選択されます。BWG でバーチャル IP によるループバックが設定されることはありません。
ロード バランシングの設定
ここでは、サーバ ロード バランシングに関する詳細設定の一覧を紹介します。これらの詳細設定は、特に明記されていない限り directed モード用です。
ロード バランシング設定作業のリスト
ここでは、ロード バランシングの設定に必要な作業の一覧を紹介します。必須作業とオプション作業
Cisco IOS SLB のロード バランシング設定
ここでは、サーバ ファームと実サーバの設定方法について説明します。Cisco IOS SLB サーバ ファームを設定するには、グローバル コンフィギュレーション モードで次のコマンドを実行します。
実 BWG の設定
BWG のロード バランシング設定
BWG でロード バランシングを設定するには、次の各項で所定の作業を行います。
• 「BWG を DHP エージェントとして設定」 （任意、ただし推奨）
SLB のループバック インターフェイスの設定
ロード バランシングをイネーブルにするには、ループバック インターフェイスにファームの 各 BWG の Cisco IOS SLB の仮想サーバと同じ IP アドレスを設定する必要がります。
ループバック インターフェイスを作成するには、グローバル コンフィギュレーション モードで次のコマンドを実行します。
|
|
|
|
|
|
ループバック インターフェイスを作成します。ループバック インターフェイスは、常にアップ状態にある仮想インターフェイスです。 |
|
|
|
BWG を DHP エージェントとして設定
DFP マネージャ（ここでは Cisco IOS SLB）が DFP エージェントへの接続に使用するポート番号を定義するには、グローバル コンフィギュレーション モードで次のコマンドを順番に入力します。
BWG でロード バランシングを設定するには、次の作業を行います。
|
|
|
|
|---|---|---|
BWG でロード バランシングをイネーブルにします。仮想サーバ コンフィギュレーション コマンドが拡張され、ASN をサポートします。 |
||
BWG の設定例
次の設定例は SAMI プラットフォームにしかあてはまりません。
上記のスーパーバイザ カード設定に対応する、実 BWG の設定例です。
設定の確認
BWG でロード バランシングがイネーブルであることを確認するには、次の作業を行います。
|
|
|
|
|---|---|---|
設定例
BWG での SLB の show コマンドの設定例を次に示します。
仮想サーバの設定
Cisco IOS SLB 仮想サーバを設定するには、グローバル コンフィギュレーション モードで次のコマンドを実行します。
DFP サポートの設定
Cisco IOS SLB は DFP マネージャ、他の DFP マネージャ（Distributed Director など）の DFP エージェント、または同時にその両方として設定できます。ネットワーク設定によって、同一のデバイスまたは異なるデバイスで、コマンド入力により Cisco IOS SLB を DFP マネージャとして設定し、さらにコマンド入力により Cisco IOS SLB を DFP エージェントとして設定することができます。
Cisco IOS SLB を DFP マネージャとして設定し、Cisco IOS SLB が接続できる DFP エージェントを指定するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。
|
|
|
|
|
|
||
|
|
SLB スティッキ性のサポート
BWG 用の SLB では、R4 または R6 コントロール プレーン メッセージのロード バランシングができます。リリース 1.0 以降では、Pre-Attachment メッセージの基本的なロード バランシングのみができます。
• BWS 向けのすべての種類の Wimax メッセージ（スティッキ エントリの有無を問わず、R4 参照ポイントと R6 参照ポイントの両方とも対象）。
• 使用可能なスティッキ エントリがない場合、Wimax ポートへのすべての R6/R4 メッセージは現在の DFP（または重み付けアルゴリズム）に基づいて、特定の実 BWG にロード バランシングされます。
• スティッキ MSID がすでに存在する場合は、BWG SLB はすべての Wimax コントロール プレーン メッセージをそれぞれ該当する実 BWG に転送します。
スティッキのアップデート
BWG は SLB にアップデート通知を送信します。認証が完了すると、BWG には MS のユーザ名（NAI）が設定されます。ISF（最初のフロー）が作成された直後に、BWG はスティッキ アップデートを SLB サーバに送信します。この中には NAI 値が含まれています。
スティッキ性の削除
次の 2 通りの状況で、SLB はスティッキ性を削除します。
• 特定の加入者セッションが削除されたことを示す信号を BGW が SLB に送信すると、スティッキ エントリが削除されます。
SLB のステートフル冗長性
信頼性を高めるため、BWG SLB ではプライマリ スーパーバイザとスタンバイ スーパーバイザの間でステートフル スイッチオーバーを行うことができます。
BWG と SLB の間のメッセージ
このメッセージは、BWG が SLB にスティッキの NAI アップデートを通知する場合に使用します。
このメッセージは、セッションの最後の PDP が削除された場合に送信されます。これにより、SLB は該当するスティッキ エントリを削除できます。
SLB サポートの設定
BWG が スティッキ性により SLB を実行できるようにするには、次の作業を行います。
合法的傍受
Lawful Intercept（LI; 合法的傍受）により、シスコは CALEA（Communications Assistance for Law Enforcement Act）などの世界各地の LI 要件を満たします。
BWG の合法的傍受設定
MIB の変数の設定や表示を行うには、まず認証済みホストの認証済みユーザになる必要があります。合法的傍受を実行するには、BWG で次のコマンドを設定します。
|
|
|
|
|
|
|
|
|
|
|
|
3. このグループのメンバであるユーザを作成します。この新しいグループには読み取りおよび書き込み権限があるユーザを作成する必要があります。
|
|
|
|
|
|
4. このユーザが接続元として使用するホストを作成します。このユーザが BWG への接続のために使用するホストを指定する必要があります。
|
|
|
|
|
|
5. テスト用のエンジン ID を設定します。実稼動環境は必要ありません。
|
|
|
|
|
|
認証済みホストから、次の CISCO-TAP2-MIB の変数を設定します。
|
|
|
|
現在の行と関連するすべてのストリーム テーブルの行が自動削除され、傍受機能が停止するまでの時間。将来の日付に設定する必要があります。この値は 16 進数で入力する必要があります（たとえば、07D8 07 0F 0A 3B 0A 00 は 2008 年 07 月 16 日 10 時 59 分 10 秒 00 を表します）。 |
||
この他にも使用できる転送オプションがあります。これらのオプションでは、追加のフィールドの設定が必要になる場合があります。
認証済みホストから、次の CISCO-TAP2-MIB の変数を設定します。
|
|
|
|
ここでは、Status 変数を 5（作成および待機）に設定します。その後、Type 変数を 4（モビリティ傍受ストリーム）に設定します。最後に、個別ストリームをタップに関連付けるまで InterceptEnable 変数を 2（false）に設定します。
認証済みホストから、次の CISCO-MOBILITY-TAP-MIB の変数を設定します。
汎用ストリームの Status 変数を 1 に設定し、行をアクティブにします。最後に、InterceptEnable を true に設定しタップをアクティブにします。
傍受のプロビジョニング
傍受は SNMPv3 によりプロビジョニングされます。プロビジョニングは 3 つの段階で発生します。まず、個別の傍受の設定では、CISCO-TAP2-MIB で説明されている所定の変数の設定により、有効なメディエーション デバイス（MD）を設定する必要があります。MD の設定後には、汎用ストリームの設定が必要です。これについても CISCO-TAP2-MIB で説明しています。最後に、汎用ストリームと関連付ける個別ストリームを選択する必要があります。
BWG の場合、CISCO-MOBILITY-TAP-MIB で定義されたモビリティ ストリームが個別ストリームとなります。現在、BWG ではモビリティ ストリームのモビリティ加入者 ID に基づくタッピングのみを使用できます。このため、モビリティ ストリーム タップを設定する場合は、SubscriberID フィールドを傍受対象のトラフィックに該当する MSID に設定します。その後、SubscriberIDTypeフィールドを「MSID」に設定します。
パケットの傍受
概念上、BWG における合法的傍受の要件はパケットのレプリケーションと類似しています。加入者またはホストが特定されると、この加入者またはホストに向けたパケットはカプセル化が解除され、IP パケットがレプリケーションされます。その後、元のパケットは本来の宛先に送信されます。レプリケーションおよびカプセル化されたパケットはメディエーション デバイスに送信されます。BWG はパケットの種類を考慮せず、いずれかの方向に受信したパケットをレプリケーションし、レプリケーションされたパケットをメディエーション デバイスに送信します。これにより、BWG はデータ パケットだけでなく音声もレプリケーションできるようになります。
WiMAX NWG ではレプリケーションされたパケットをカプセル化する方法は定義されません。CISCO-TAP2-MIB では、MD が PacketCable UDP, Nack 弾性のある RTP、ヘッドオブライン ブロッキングがある TCP、ヘッドオブライン ブロッキングがある SCTP を使用して、レプリケーションされたパケットをカプセル化および転送できるよう設定できます。現在実装されている BWG は UDP（PacketCableTM）をカプセル化スキームとして使用しています。
現在合法的傍受で使用できない SNMP オプション
現在、BWG では CISCO-TAP2-MIB の Debug User オプションを使用できません。具体的には、CISCO-TAP2-MIB の次のオブジェクトは現在使用できません。
BWG の設定
BWG での SNMP 設定
ここでは、BWG で Simple Network Management Protocol（SNMP; 簡易ネットワーク管理プロトコル）を設定する方法について説明します。ここでは次の設定作業について説明します。
ルータの SNMP アクセスの設定
コミュニティ アクセス ストリングを設定して簡易ネットワーク管理プロトコル（SNMP）にアクセスできるようにするには、次の作業を行います。
SNMP サーバ ホストの設定
簡易ネットワーク管理プロトコルによる通知の受信者を指定するには、次の作業を行います。
このコマンドは、デフォルトでディセーブルになっています。通知は送信されません。キーワードを指定せずにこのコマンドを入力すると、デフォルトではホストにすべての種類のトラップが送信されます。このホストに応答要求は送信されません。
version キーワードが指定されていない場合、デフォルトはバージョン 1 です。no snmp-server host コマンドでキーワードが指定されていない場合、ホストへのトラップはディセーブルになりますが、応答要求はディセーブルにはなりません。応答要求をディセーブルにするには、no snmp-server host informs コマンドを使用します。
SNMP-Server Trap-Source の設定
簡易ネットワーク管理プロトコル トラップの送信元となるインターフェイス（およびこれに対応する IP アドレス）を指定するには、次の作業を行います。
SNMP トラップの設定
ルータが簡易ネットワーク管理プロトコル トラップまたは応答要求（SNMP 通知）を送信できるようにするには、次の作業を行います。
設定例
次の例では、「public」というコミュニティ ストリングを使用して、ルータがすべてのトラップを「myhost.cisco.com」という名前のホストに送信できるようにしています。
次の例では、「public」というコミュニティ ストリングを使用して、ルータがフレーム リレーおよび環境モニタ トラップを「myhost.cisco.com」という名前のホストに送信できるようにしています。
次の例では、どのホストにもトラップを送信しません。BGP トラップがすべてのホストに対してイネーブルになっていますが、ホストへの送信がイネーブルになっているのは ISDN トラップのみです（この例ではイネーブルになっていません）。
（注） logging snmp-authfail コマンドを使用すると、すべての SNMP 認証失敗メッセージのログがイネーブルになります。このコマンドの no 形式を使用すると、認証失敗メッセージのログがディセーブルになります。
（注） ルータの SNMP 管理ツールで PPP セッションをモニタしていない場合、no virtual-template snmp コマンドを使用すると、仮想アクセス サブインターフェイスがルータの SNMP 機能で登録されてメモリを使用することがないようにできます。次に例を示します。
router(config)# [no] virtual-template snmp
BWG での SNMP 設定の例
MIB のサポート
BWG では、ユーザとネットワークが SNMP コマンドを使用してリモートで BWG をモニタできるようにするためのオブジェクトを参照できる Management Information Base（MIB;管理情報ベース）を使用できます。BWG では次の独立した 2 つの MIB を使用できます。
1 つは、グローバル システム情報とパラメータ、ベース ステーション情報、加入者、フロー、トラフィックおよびトラップ通知情報が保存されているものです。
もう 1 つは、ベース ステーションと BWG の間で使用される R6 シグナリング プロトコル情報に関する情報が保存されているものです。これには、全体のゲートウェイ R6 情報と、ベース ステーションごとの情報が含まれます。
フェールオーバー時には BWG MIB 変数は同期されません。スタンバイ側からは同期された状態データを使用して各種の MIB 変数を再作成できます。NMS はこのような状況に対処しようと試み、またその結果発生する MIB データの矛盾を解決しようとします。既存の RF/CF MIB も使用できます。
MIB サポートの確認
各種の MIB パラメータを表示するには、次の作業を行います。
|
|
|
|
|---|---|---|
BWG のソフトウェア バージョン、許可されるベース ステーションの数、許可される加入者の数など、各種システム パラメータを表示します。 |
||
設定例
show wimax agw コマンドの出力例を次に示します。
show wimax agw user-group コマンドの出力例を次に示します。
show wimax agw statistics コマンドの出力例を次に示します。
show wimax agw statistics dhcp-relay コマンドの出力例を次に示します。
この出力では、BWG 経由でリレーされる DHCP メッセージの統計情報が表示されます。BWG がいずれかの DHCP を開始した場合、これらのカウンタの値は増加しません。
show wimax agw statistics internal コマンドの出力例を次に示します。
BWG リリース 1.1 での MIB 機能拡張
BWG 管理情報ベース（MIB）はアップデートされ、送信および受信したパケット数とバイト数のイーサネット CS 関連カウンタが追加されています。BWG リリース 1.1 では次の MIB オブジェクトがアップデートされています。
• 新しい EthCS 関連の送受信済みパケット数/バイト数の変数が含まれています。
ASN GW グローバル統計情報
MIB には ARP に関する統計情報（受信した ARP 要求の合計数、送信した ARP 応答の合計数、ドロップされた ARP パケットの合計数）、拒否されたホストに関する統計情報、期限切れのスタティック ホストに関する統計情報の新しいオブジェクトも含まれています。
GRE キー入力
各サービス フローの方向ごとに GRE キーが割り当てられています。GRE キーは、データ パス ベアラの作成に使用する RR-Request を使用して交換されます。BWG に対応する GRE キーは BWG により割り当てられ、サービス フローの作成時に RR-Request を使用して BS に送信されます。同様に、BS に対応する GRE キーの値は BS により割り当てられ、RR-Response メッセージを使用して BWG に送信されます。
BS 間モビリティ中に、新しいキーがベース ステーションにより割り当てられます。BWG は同じ GRE キーを保持します。
VRF のサポート
ユーザ グループには Virtual Route Forwarding（VRF;仮想経路転送）のサポートを設定できます。これにより、内部 VRF エンティティを作成して特定のユーザ グループとの間で送受信されるすべてのトラフィックを接続することができます。
QoS サポート
QoS のサポートは、エアーリンク QoS とネットワーク上のマッピングの両方を意味します。所定のサービス フローの作成のため、ASNGW がベース ステーションに QoS パラメータを送信します。
• 特定のホストには追加の QoS パラメータを設定できます。
• ホスト IP アドレスに対応する新しい R6 ベアラ（サービス フロー）を作成できます。このサービス フローは複数のホストで使用できます。
• 新しい R6 サービス フローへのホストのマッピングが作成され、RR-Request により BS/MS に送信されます。
各サービス フローは Diffserv Code Point（DSCP;DiffServ コード ポイント）に対して一意にマッピングされます。この DSCP 値は外部 IP ヘッダーのマーキングのため、ダウンストリーム パケットでは BWG、アップストリーム パケットでは BS により使用されます。
アップストリームおよびダウンストリーム パケットの内部 IP ヘッダーは、サービス フローのマッピングに従って、BWG により設定されます。ただし、CLI により明示的にディセーブルにされている場合を除きます。
ACL はサポートされており、ユーザ グループごとに設定できます。同じユーザ グループに接続するすべてのユーザに対して適用されます。
すべてのアップリンク パケットについて、対応する MS またはサービス フローに対して割り当てられた IP アドレスが検証されます。ミスマッチが検出されると、そのパケットは破棄されます。
この機能を設定するには、ゲートウェイ ユーザ グループ サブモードで security subscriber address-filtering ingress コマンドを使用します。
コントロールとデータで異なる BS のエンド ポイントのサポート
BS にはコントロールとデータ プレーンで異なるエンド ポイント IP アドレスが存在する場合があります。データ パス エンド ポイント ID TLV（フローの BS のパス登録応答メッセージで送信）の可用性によっては、BWG は GRE パスを作成し、使用可能な TLV から IPv4 を取得できます。
指定した TLV が存在しない場合、コントロール プレーンのエンド ポイントのアドレスがリモート データのエンド ポイントとして使用され、GRE パスが作成されます。
すべてのサービス フローで、ベアラのボリューム カウントが維持されています。これには、入力および出力パケットとオクテット カウントが含まれています。
制約事項
Cisco BWG リリース 1.0 以降では次の制約事項が適用されます。
• CPU 使用率の上昇による問題を回避するため、次の設定が推奨されます。
– 起動時の CPU 使用率を抑えるには、no logging console グローバル コンフィギュレーション コマンドを設定し、コンソール端末へのロギングをディセーブルにします。
– HSRP インターフェイスが同位 hello パケットを処理できる状態になるまでアクティブ状態を宣言しないようにするには、HRSP インターフェイスで standby delay minimum 100 reload 100 interface コンフィギュレーション コマンドを使用して、HSRP グループを初期化する前に遅延時間を設定します。
– PPP PDP 処理（作成と削除）が高頻度である期間が長いなど、その他の理由で CPU 使用率が高くなる問題を最小限に抑えるには、no logging event link-status インターフェイス コンフィギュレーション コマンドを使用して、BWG のすべてのバーチャル テンプレート インターフェイスでのインターフェイス データ リンク ステータスの変更通知をディセーブルにします。
ヒットレス ソフトウェア アップグレード
BWG リリース 2.0 では、新しい SR アトリビュートが導入されています。スタンバイ側がアップグレードした後、スタンバイ側では新しい BWG 2.0 SR アトリビュートを受信しません（アクティブ BWG は引き続き BWG 1.1/1.2 で稼動します）。元の BWG（アクティブ）から同期されないこれらの新しい BWG 2.0 SR アトリビュートについては、スタンバイ BWG に対して適切なデフォルト値を設定する必要があります。
次の条件を前提とした場合、この後に説明する手順を実行するとソフトウェアのアップグレードを正常に実行できます。
アクティブ BWG とスタンバイ BWG は BWG 1.2 (N-1) ソフトウェア イメージで稼動しています。説明を簡単にするために、元のアクティブ BWG をノード A、元のスタンバイ BWG をノード B とします。
• ノード A とノード B で startup-config を起動し、BWG 2.0 に適合させます。CLI は引き続き BWG 2.0 以前の製品に適合しているため、この手順が必要になるのは最初に何らかの BWG 2.0 の機能が必要である場合のみです。この手順が必要な場合は、tftp-copy により既存の startup-config ファイルを外部 TFTP デバイスにコピーし、手動で編集してから tftp-copy により再度 BWG にコピーします。
• スタンバイ側（ノード B）の BWG 1.2 を BWG 2.0 イメージにアップグレードします。スタンバイ側の BWG 2.0 は引き続きスタンバイ BWG として機能します。バルク同期が完了するまで待ちます。既存のすべてのセッションに BWG 2.0 用の該当機能があるわけではないことに注意してください。
• ノード A を BWG 2.0 イメージにアップグレードし、ノード A でスイッチオーバーを実行します。この時点で、ノード B（BWG 2.0 イメージ）がアクティブになります。
制約事項
次の制約事項は、ヒットレス ソフトウェア機能に適用されます。
ユーザ グループごとに 2 台の DHCP サーバをサポート
BWG が DHCP リレーとして機能している場合、DHCP パケットを 2 台の DHCP サーバにリレーできます。DHCP 検出パケットと DHCP 要求パケットは両方の DHCP サーバに送信されます。
フィードバック