ISG RADIUS Change of Authorization インターフェイス ガイド Cisco IOS XE リリース 3S

使用例のシナリオ

---

この章では、さまざまな条件で一般的なシステム動作と RADIUS 対話を監視するために使用可能な使用例のシナリオの例を示します。最初の使用例では、すべての RADIUS メッセージのデバッグが表示されます。他の使用例では、すべてのメッセージ フローがリストされていますが、対象の RADIUS デバッグだけが表示されます。

この章では、次の事項について説明します。

• 「使用例 1：ポータル ログイン」

• 「使用例 1：コール フロー」

• 「使用例 1：詳細」

• 「使用例 2：Transparent Auto-Logon」

• 「使用例 2：コール フロー」

• 「使用例 2：詳細」

• 「使用例 3：サービス認証」

• 「使用例 3：詳細」

使用例 1：ポータル ログイン

この使用例は PWLAN アプリケーションで使用されている典型的なパブリック アクセス コントロールです。このシナリオでは、IP 加入者は IP アドレスを取得し、L3 アクセス ネットワーク上で ISG にルーティングされます。ISG は認証のためにポータルに加入者をリダイレクトし、RADIUS に保存された加入者プロファイルに従ってサービスをアクティブ化します。 に示すアーキテクチャを想定しています。この例では、各番号付き項目は、図 1 の番号に対応しています。

1. ユーザ セッションが新しい IP 送信元アドレスの検出時に作成されます。一部のデフォルト サービスが適用されます。

2. ISG は、ユーザをポータルにリダイレクトします。ユーザは自分のユーザ名とパスワードを入力し、ユーザ クレデンシャルは、ISG に送信されます。

3. ユーザは AAA サーバで認証され、どの機能およびサービスを新しく作成されたセッションに適用するかを指定するユーザ プロファイルが RADIUS から取得されます。

4. ユーザはネットワークにアクセスできます。

5. しばらくすると、ユーザはポータルに戻り、より多くの帯域幅を取得するようにサービスを変更します。新しいポリシング パラメータが CoA によってポータルからプッシュされます。

6. しばらくすると、ユーザはポータルから切断され、セッションが終了します。

図 1 ポータル ログイン ルーティング図

使用例 1：コール フロー

図 2 に、使用例 1 のシーケンス図を示します。各番号付き項目の詳細については、 使用例 1：詳細を参照してください。

図 2 使用例のシーケンス図

使用例 1：詳細

次の各番号付き項目は、図 2 の番号に対応しています。

1. ISG インターフェイスを、新しいセッションとして個々の IP アドレスを識別するように設定します。

新しいセッションの開始時に、デフォルト サービス（この場合、PBHK、L4-redirect、および Open_Garden）を適用するよう ISG を設定します。これらのサービスは、（この使用例で想定されているように）ISG にローカルに定義することも、外部 AAA サーバに定義することもできます。

2. CoA Session Query によるポータル要求セッション情報。これはセッション ID として PBHK ID を使用します。

3. ISG は、CoA ACK で応答します。対象の情報には、クライアントの IP アドレス、またはセッションの状態（この場合は「unautenticated」）が含まれます。

4. PS は、ユーザのユーザ名およびパスワードを含む CoA Account Logon を発行します。ISG は、このイベントのセッションを認証するように設定されています。認証が成功した場合にだけリダイレクト サービスを削除する 2 番目のアクションが実行されることに注意してください。

5. ISG が Accept Request を発行して AAA でセッションを認証します。要求には、クライアントのユーザ名とパスワードが含まれます。

6. クレデンシャルの確認に成功すると、AAA はアクティブ化するサービスがリストされたユーザ プロファイルを含む Access Accept で応答します。認証に成功したため、L4-redirect サービスは適用されません（セッションの制御ポリシーのアクション 20）。

7. ISG はアカウンティング サーバにアカウンティング メッセージを送信して、セッションの開始を通知します。

8. ISG は、CoA ACK で PS に応答してアカウント ログオンの成功を通知し、加入者情報および加入者サービス情報を含めます。

9. セッションに対してアクティブ化するサービスがまだ ISG にキャッシュされていないと仮定して、ISG は AAA に Access Request を送信してサービス定義をダウンロードします。

10. サーバはサービス定義（サービス プロファイル）で応答し、ISG はセッションにサービスを適用します。

11. ISG は、BASIC_INTERNET_SERVICE_UC1 のアカウンティング メッセージを送信してサービス開始を通知します。サービスの accounting-ID が parent-session-id 属性によってセッションに関連付けられます。

12. Portal/PS は自動ログオン サービスが「CoA Session Query for Service Status」を使用して正常にアクティブ化されたかどうかを確認するために ISG に照会します。

13. ISG はセッションのサービス情報を Portal/PS に返します。

14. ユーザがポータルで新しいウィンドウを開くと、Portal/PS がセッション情報を必要とする可能性があり、情報の取得に CoA Account Query を使用します。

15. ISG は、セッションおよびサービス情報で応答します。

16. ユーザがポータルからサービス機能を変更します。PS は CoA 機能プッシュを使用して機能を変更します。この場合、ポリシング レートは 1024K になり、アイドル タイムアウトは 2000 秒に変更されます。

17. ISG は、機能が変更されたことを確認します。

18. ユーザはポータルとの接続を解除します（ログオフします）。Portal/PS は CoA Request: Account Logoff を送信してセッションを終了します。

19. ISG は、CoA ACK で応答します。

20. ISG はセッションがアカウンティング Stop を使用して終了したことを通知します。

21. ISG はサービスがアカウンティング Stop を使用して終了したことを通知します。

使用例 2：Transparent Auto-Logon

Transparent Auto-Logon（TAL）機能は「サービスへの常時アクセス」の提供を可能にします。つまり、セッションはネットワーク ID に基づいて認可され、アクセスのために加入者認証は必要ありません。

この使用例は、多くの IP セッションが BRAS の単一の VLAN 上で集約される典型的なブロードバンド レジデンシャル アクセスです。PPP と同様のサービスを実現するには、サービス プロバイダーは、DHCP Option-82 フィールドに DSLAM によって入力されるロケーション情報に基づいてエンド ユーザを識別します。

図 3 に、この使用例で使用されるアーキテクチャを示します。この例では、次の各番号付き項目は、図 3 の番号に対応しています。

1. ユーザ セッションが新しい DHCP 対話の検出時に作成されます（ISG は DHCP サーバまたはリレー）。ダウンストリーム スイッチまたは DSLAM によって加入者の物理的なロケーションが DHCP Option 82 に入力されることを前提とします。

2. ユーザは自分の MAC アドレス + DHCP Option 82 情報に基づいて AAA サーバで許可されます。AAA サーバはユーザを許可し、セッションに適用される機能およびサービスがリストされたユーザ プロファイルを返します。サービスの 1 つは、vrf-id と DHCP クラスを含むプライマリ サービスで、VRF 経由でルーティング可能な IP アドレスが割り当てられるようにします。

3. ユーザは、MPLS VPN 経由で自分のサービスにアクセスできます。

4. しばらくすると、ユーザはポータルにアクセスし、帯域幅が増加する「turbo-button」タイプのサービスに加入します。さらにしばらくすると、ユーザはポータルにアクセスし、「turbo-button」タイプのサービスを非アクティブ化して通常のサービスに戻ります。

図 3 Transparent Auto-Logon ルーティング図

使用例 2：コール フロー

図 4 に、使用例 2 のシーケンス図を示します。各番号付き項目の詳細については、 使用例 2：詳細を参照してください。

図 4 使用例 2 のシーケンス図

使用例 2：詳細

各番号付き項目は、 の番号に対応しています。

1. DHCP DISCOVERY メッセージは加入者によって開始されます。中間デバイス（DSLAM またはスイッチ）が DHCP Option 82 情報を入力して、加入者の物理的なロケーションを特定することを前提とします。ISG インターフェイスを、DHCP 制御トラフィックに対して新しいセッションを開始するように設定します。

新しいセッションで、デフォルト サービス（この場合 PBHK）を適用し、MAC アドレスおよび DHCP Option 82 情報に基づいてセッションを許可するように ISG を設定します。

2. ISG は Accept Request を発行して、AAA でセッションを許可します。Accept Request には、ユーザ名として MAC アドレスおよび Option 82 情報が含まれており、ポリシーで定義したパスワードが使用されます。この例では、「cisco」が使用されます。

3. アイデンティティの確認に成功すると、AAA はユーザ プロファイルおよびアクティブ化するサービスを含む Access Accept で応答します。この例では、「DEFAULT_BW_512K_UC2」および「VPN1_UC2」が使用されます。

4. 4a-4b . サービスが ISG にキャッシュされていないため、ISG はこれらを AAA から取得する必要があります。

4c-4d . 両方のサービスの定義が取得され、サービスが適用されます。次の例は、AAA サーバに表示されるサービス定義です。

5. ISG はカスタマーによって割り当てられた VRF 内でルーティング可能である DHCP クラスに基づいて IP アドレスを提供します。

6. 6a-6b . アカウンティング要求がユーザ セッションの開始を通知するために送信され、別のアカウンティング要求がサービス開始を通知するために送信されます。

7. 7a-7b . ユーザ要求、提供されたアドレス、およびアドレスは、ISG によって配布されます。

8. 8a-9b . しばらくすると、ユーザがポータルにサイン インすることを前提とします。Portal/PS は 1 つ以上の CoA Request:Account Query を発行して、加入者情報とサービス ステータスを取得します。ISG は加入者情報および加入者サービス情報を含む CoA ACK で Portal/PS に応答します。

9. 9a-9b . これらの手順では、前の手順と同様にサービス クエリーを処理します。

10. ユーザが新しいサービス「BOD1M_SERVICE_UC2」を選択したと仮定して、Portal/PS は新しいサービス名を含む CoA Request:Service Activate メッセージを発行します。

11. 制御ポリシーは、1M サービスがアクティブ化されると、512K サービスを切断するように指定します。512K サービスを切断すると、ISG は 512K サービスのサービス停止を通知するアカウンティング要求を送信します。

12. 12a-12b . 1M サービスの定義が ISG にまだキャッシュされていないという前提があるため、ISG は AAA から 1M サービスの定義を取得する必要があります。AAA におけるサービス定義の例を次に示します。

13. ISG は、1M サービスがインストールされたことを確認します。

14. ISG は、1M サービスが開始されたことを通知するアカウンティング要求を送信します。

使用例 3：サービス認証

この使用例では、ユーザがこのサービスにアクセスする前に、アプリケーション サーバでサービス認証が必要です。サービス プロファイルが ISG によって取得されると、指定されたサーバで追加認証が必要であると（ポリシー ディレクティブ VSA 内で）確認されます。その場合、ユーザ プロファイル内で取得されたユーザ名とパスワードがサービスへのログオンに使用されます。図 5 に、サービス認証のシーケンス図を示します。

この例では、次のようになります。

• PPP ユーザ セッションが PPP 制御トラフィックの検出時に作成されます。

• ユーザは、AAA サーバで許可されます。

• ユーザ プロファイルには、認証を必要とする autologon サービスが含まれています。

• ISG はアクセスを許可する前にサービスを認証します。

使用例 3：詳細なコール フロー

図 5 に、使用例 2 のシーケンス図を示します。各番号付き項目の詳細については、 使用例 3：詳細を参照してください。

図 5 サービス認証のシーケンス図

使用例 3：詳細

各番号付き項目は、図 5 の番号に対応しています。

1. PPP 制御メッセージは加入者によって開始されます。PPP セッションの場合、PPP セッションが自動的に作成されるため、ISG インターフェイスを設定する必要はありません。この使用例では、セッションが認証を必要とすることを前提としています。この認証はコマンドを使用してイネーブルにします。

2. ISG が Accept Request を発行して、ユーザのユーザ名とパスワードが含まれるアクセス プロバイダー AAA でセッションを認証します。

3. アイデンティティの確認に成功すると、AAA はユーザ プロファイルおよびアクティブ化するサービス（この場合、「goldservice」）を含む Access Accept で応答します。ユーザ プロファイルの Service Name VSA には、次のような追加のユーザ名とパスワードが含まれています。

4. サービス「goldservice」が ISG にまだキャッシュされていないと仮定して、ISG は Access Request を AAA に送信してサービス定義をダウンロードします。

5. サーバは、サービス定義で応答します。サービス定義内に、特定のアプリケーション サーバでさらに認証が必要であることを示すポリシー ディレクティブ VSA があります。

6. ISG は、サービス認証のために指定サーバに対する Access-Request を開始します

7. クレデンシャルの確認に成功すると、アプリケーション サーバは Access-Accept で応答し、ユーザは自分のサービスにアクセスできます。