AAA スロットリング機能のトラブルシューティング

概要

このドキュメントでは、RADIUSサーバに送信されるアクセス（認証および許可）およびアカウンティングレコードのスロットリングをサポートするAAA(RADIUS)レコードのスロットリング機能について説明します。

この機能を使用すると、CiscoルータからRADIUSサーバに対して急激に生成されるレコードのバーストに対応できる帯域幅が不十分な場合に、ネットワークの輻輳と不安定さを回避するために適切なスロットリング率を設定できます。

前提条件

要件

このドキュメントに特有の要件はありません。

使用するコンポーネント 

このドキュメントの情報は、ASR5kプラットフォームに基づくものです。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

背景説明

aaamgrがRADIUSメッセージを高速で（たとえば、多数のセッションが同時にダウンすると、すべてのセッションのアカウンティング停止メッセージが同時に生成される）RADIUSサーバがそのような高速でメッセージを受信できない場合があります。この状況に対処するには、aaamgrに効果的なレート制御メカニズムが必要です。これにより、aaamgrはRADIUSサーバがすべてのメッセージを受信できるように最適なレートでメッセージを送信し、RADIUSサーバの過負荷状態によりメッセージが廃棄されないようにします。

作業の仕組み

aaamgrが設定されたレートでメッセージをRADIUSサーバに送信すると、RADIUSサーバ全体でメッセージが均等に送信されます
各メッセージは、1つのバーストですべてのメッセージを送信するのではなく、設定に応じて、各秒は複数の等しいタイムスロットに分割されます（各スロットに特定の期間があります）。 スロットの最小期間
50ミリ秒の可能性があります。

レートは、これらの値を考慮して設定する必要があります

• 着信コールの割合
• aaamgrインスタンスの数
• RADIUSサーバがメッセージを受信できるレート
• 間隔（アカウンティング構成）
• サーバ選択に使用されるアルゴリズム

認証サーバの設定値が小さすぎる場合は、
 輻輳。セッション設定のタイムアウトにより、コールがドロップされる可能性があります。アカウンティングサーバに低い値が設定されている場合、キューのオーバーフローが原因で、アカウンティングメッセージの大量の消去が発生します。

この機能が設定されると、第2のタイムスロット数と第2の時間のタイムスロット数が計算され、半径レベルで保存されます。メッセージをRADIUSサーバに送信する準備ができたら、クォータ（このタイムスロットのメッセージ数）に達したかどうかを確認します。制限に達しない場合はメッセージが送信され、限界に達した場合はメッセージはサーバレベルのキューに入れられ、将来のタイムスロットで送信されます。各RADIUSサーバには、現在のタイムスロットで送信されたメッセージの数と、タイムスロットの有効期限が切れる時刻に関する詳細が保持されます。キューに入れられたメッセージがサーバレベルのキューから選択されると、インスタンスレベルのキューの先頭に置かれ、他の新しいメッセージよりも古いメッセージが優先されます。インスタンスレベルのキューからのメッセージが選択され、サービスが提供されます。

AAAMGRキュー

AAAMGRのメッセージ用キューには、次の2種類があります。

1. インスタンスレベルキュー
2. サーバレベルのキュー

メッセージが生成されると、最初はサービスのためにインスタンスレベルのキューにキューイングされます。

インスタンスレベルのキューは、50ミリ秒ごとに25ミリ秒にわたって処理されます。インスタンスレベルのキューからデキューされたメッセージは、RADIUSサーバに送信されます。一部の状況では、メッセージを送信できない可能性があります（使用可能な帯域幅がない、または使用可能なIDがない）。 このような場合、試行に失敗したメッセージは、サーバレベルのキューにキューイングされます。50ミリ秒ごとに、使用可能なIDと使用可能な帯域幅を持つメッセージの数を選択し、インスタンスレベルキューの先頭に配置します（これらのメッセージは、インスタンスレベルキューに存在する他のメッセージよりも古いメッセージです）。

アカウンティングメッセージのレート制御があり、インスタンスレベルキューにアカウンティングメッセージが多数ある場合、新しい認証メッセージはインスタンスレベルキューの末尾に送られます。処理を行うには、すべてのアカウンティングメッセージ（新しい認証メッセージの前）がRADIUSサーバに送信されるか、サーバレベルのキューに移動されるまで待機する必要があります。これは既存の動作であり、変更されません。そのため、新しい認証メッセージの処理に多少の遅延が発生する可能性があります。

例

値5のmax-rateに基づいて、1秒で5つのメッセージを送信し、RADIUS認証サーバに対してaamgrごとに256のradius認証メッセージ（デフォルトのmax-outstanding設定）未応答を送信できます。5つ以上のメッセージがある場合、1秒間にAAAサーバが既存の要求に応答するまで、メッセージはキューに入れられます。

あるaamgrからサーバに送信された256個のRadius認証メッセージが届くと、AAAサーバが既存の要求に応答するまで、残りの要求がキューに入れられます。再びmax-rateと同じキューに入ります。メッセージは、空きスロットがある場合にのみキューからピックアップされます。フリースロットは、メッセージに対する応答を受信した場合、またはタイムアウトした場合に装着されます。

制限

Cisco ASR5Kは、コールを処理する独立したsessmgr/aamgrペアを備えた分散システムであるため、レート調整は独立したaaamgrインスタンスに対してのみ実装できます。理論上は、インスタンスの総数に最大レートを掛けるだけで、単一インスタンスのレートをCisco ASR5Kボックス全体に拡張できます
各インスタンスに適用されます

この数は、晴れた日のシナリオでは絶対上限です。Cisco ASR5Kをブラックボックスとして扱うことはできません。また、システムで見られる計算値が上限を超えていない場合は、すべてのコールが成功するとはみなされません。

Radius max-rateは、システムに関連する他の内部および外部パラメータと結び付けられます。いずれかの条件が満たされていない場合は、予想される影響を確認してください。

多くの場合、アクティブなaamgrタスクによってアクセス要求が処理されていないことがわかります。つまり、sessmgrタスク内でコールの分散が不均一になり、さらに、すべてのaaamgrインスタンスがコール処理に関与しているわけではありません。

コールの分配は、着信コールが10の場合にモノトニックなアルゴリズムで10のsessgrsに到達するという、厳密なラウンドロビン方式に基づくものではありません。

コール分配は、次の4つの主要な要因に基づいています

• active_session_count
• cpu_load
• Round_trip_delay (demux mgr - sessmgr - demux mgr)
• outstanding_add_request (sessmgrへのdemux)

これが現在の実装です。最大レートは上限ですが、アーキテクチャの分散特性により、シャーシの負荷に直接外挿することはできません。この動作は、特定のAAAmgrのロードによって異なります
特定の時間に実行できます

システムのステータスを監視するには、RADIUSの最大レートキューを使用する必要があります。キューのビルドアップがある場合、
これは、これらの4（表を参照）の条件のいずれかが満たされていないことを意味し、その根本原因を特定する必要があります。

**max-rate queue thresholdは実装でき、常に監視できます。