Dépannage de la fonction de limitation AAA

Options de téléchargement

  • PDF     (87.3 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (82.4 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (69.2 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:11 janvier 2016
ID du document:200327

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Introduction

Ce document décrit la fonction de limitation des enregistrements AAA (RADIUS) qui prend en charge la limitation de l'accès (authentification et autorisation) et des enregistrements comptables envoyés au serveur RADIUS.

Cette fonctionnalité permet à l'utilisateur de configurer le débit de régulation approprié pour éviter l'encombrement et l'instabilité du réseau lorsque la bande passante est insuffisante pour prendre en charge une rafale soudaine d'enregistrements générés du routeur Cisco au serveur RADIUS.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used 

Les informations de ce document sont basées sur la plate-forme ASR5k.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Informations générales

Lorsqu'aamgr envoie les messages radius au serveur RADIUS à un débit élevé (par exemple, lorsqu'un grand nombre de sessions s'arrête en même temps, les messages d'arrêt de comptabilité pour toutes les sessions sont générés en même temps), le serveur RADIUS peut ne pas être en mesure de recevoir les messages à un débit aussi élevé. Pour gérer cette condition, nous avons besoin d'un mécanisme de contrôle de débit efficace à aamgr, de sorte qu'aamgr envoie des messages à un taux optimal de sorte que le serveur RADIUS soit capable de recevoir tous les messages et s'assure qu'aucun message n'est abandonné en raison d'une surcharge sur le serveur RADIUS.

  

Mécanisme de travail

Lorsqu'aamgr envoie des messages au débit configuré au serveur RADIUS, il envoie des messages uniformément sur l'ensemble du serveur
chaque seconde au lieu d'envoyer tous les messages en une seule rafale. Selon la configuration, chaque seconde est divisée en plusieurs tranches de temps égales (avec une période spécifique par tranche). La durée minimale d'un emplacement
peut être de 50 millisecondes.

Le taux doit être configuré en tenant compte de ces facteurs

  • Taux d'appels entrants,
  • Nombre d'instances aamgr
  • Taux auquel le serveur RADIUS peut recevoir les messages et
  • Intervalle des intervalles (pour la configuration comptable)
  • Algorithme utilisé pour la sélection du serveur

Si la valeur configurée pour les serveurs d'authentification est trop faible, alors il y aura une bouteille de cou menant à
 encombrement, ce qui peut entraîner la suppression des appels en raison du délai d'attente de configuration de la session. Si une valeur faible est configurée pour les serveurs de comptabilité, beaucoup de purge des messages de comptabilité seront observés, en raison d'un débordement de la file d'attente.

Lorsque la fonction est configurée, le nombre de créneaux horaires d'une seconde et d'une seconde sont calculés et stockés au niveau du rayon. Lorsqu'un message est prêt à être envoyé au serveur RADIUS, il est vérifié si le quota (nombre de messages pour ce créneau horaire) a atteint. Si la limite n'est pas atteinte, le message est envoyé, si c'est le cas, alors le message est mis en file d'attente dans la file d'attente au niveau du serveur pour être envoyé dans les futurs créneaux horaires. Chaque serveur RADIUS contient des détails sur le nombre de messages envoyés dans le créneau horaire en cours et l'heure à laquelle le créneau horaire expire. Lorsque les messages en file d'attente sont sélectionnés dans la file d'attente au niveau du serveur, ils sont placés en tête de la file d'attente au niveau de l'instance, ce qui garantit la préférence pour les messages plus anciens que tout autre nouveau message. Les messages de la file d'attente au niveau de l'instance sont sélectionnés pour la maintenance.

schema.jpg

Files d'attente AAAMGR

Il existe deux types de files d'attente au niveau d'AAAMGR pour les messages :

  1. Files d'attente de niveau d'instance
  2. Files d'attente au niveau du serveur

Lorsqu'un message est généré, il est initialement mis en file d'attente au niveau de l'instance pour la maintenance.

La file d'attente de niveau d'instance est traitée pendant 25 millisecondes toutes les 50 millisecondes. Tout message qui est retiré de la file d'attente au niveau de l'instance sera envoyé au serveur RADIUS. Dans certaines conditions, il se peut que nous ne puissions pas envoyer les messages (aucune bande passante disponible ou aucun ID disponible). Dans de tels cas, les messages qui ont échoué à la tentative seront mis en file d'attente dans les files d'attente au niveau du serveur. Pour chaque 50 millisecondes, vous choisissez autant de messages dont les ID sont disponibles et la bande passante disponible et les placez en tête de file d'attente de niveau instance (ces messages sont plus anciens que tout autre message présent dans la file d'attente de niveau instance).

Lorsqu'il y a un contrôle de débit pour les messages de comptabilité, et s'il y a beaucoup de messages de comptabilité dans la file d'attente au niveau de l'instance, tout nouveau message d'authentification se dirige vers la fin de la file d'attente au niveau de l'instance. Pour être traité, il doit attendre que tous les messages de comptabilité (précédant le nouveau message d'authentification) soient envoyés au serveur RADIUS ou déplacés vers la file d'attente au niveau du serveur. Il s'agit d'un comportement existant et il n'est pas modifié. Il peut donc provoquer un léger retard dans le traitement du nouveau message d'authentification.

Exemple

Sur la base de max-rate avec une valeur de 5, vous pouvez envoyer cinq messages en 1 seconde et avoir 256 messages d'authentification radius en attente (configuration max-en attente par défaut) sans réponse par aamgr vers le serveur d'authentification Radius. Dans le cas où il y a plus de 5 messages, en 1 seconde, les messages sont mis en file d'attente jusqu'à ce que le serveur AAA réponde aux requêtes existantes.

Si vous atteignez 256 messages d'authentification Radius envoyés d'un aamgr vers le serveur, les requêtes restantes seront mises en file d'attente jusqu'à ce que le serveur AAA réponde aux requêtes existantes. Il va de nouveau aller dans la même file d'attente que celle de max-rate. Le message est retiré de la file d'attente uniquement lorsque vous disposez d'un emplacement libre. L'emplacement gratuit arrive lorsque vous recevez une réponse pour le message ou lorsqu'il expire.

Limites

Puisque Cisco ASR5K est un système distribué avec des paires sessmgr/aamgr indépendantes qui traitent les appels, la limitation de débit n'a pu être implémentée que pour les instances aamgr indépendantes. Il est théorique d'étendre le taux d'une seule instance à l'ensemble de la zone Cisco ASR5K en multipliant simplement le nombre total d'instances par le taux maximal
de chaque instance.

Ce nombre n'est que la limite supérieure absolue dans un scénario de jour ensoleillé. Vous ne pouvez pas traiter Cisco ASR5K comme une boîte noire et ne pouvez pas supposer que tous les appels doivent réussir si la valeur calculée affichée dans le système ne dépasse pas la limite supérieure.

Radius max-rate est lié à d'autres paramètres internes et externes liés au système. Veuillez voir l'impact attendu si l'une des conditions n'est pas remplie.

Conditions

Impact si non atteint

Distribution uniforme des appels de demuxmgr à toutes les sessions

Si la distribution des appels n'est pas uniforme, les messages radius peuvent
être mis en file d'attente pour certaines instances. Ainsi, même si la limite de débit maximum théorique n'est pas atteinte, les appels sont abandonnés pour les instances où les messages sont mis en file d'attente.

Distribution uniforme des IMSI (au cas où
de la comptabilité de médiation de round-robin)

Le round-robin de la comptabilité de médiation est basé sur le routage IMSI.
Dans ce cas, en fonction de la distribution IMSI, certains ensembles de serveurs peuvent être préférés par rapport à d'autres en fonction de la logique de routage, la file d'attente peut être constituée pour les serveurs conduisant à la suppression d'appels.

Pas de rafales soudaines d'appels entrants

S'il y a une rafale de nouveaux appels, les messages RADIUS nouvellement générés seront de nouveau mis en file d'attente dans le système. Au moment où les nouvelles demandes de rayon sont traitées. Le délai de configuration de la session peut être expiré et entraîner des abandons d'appel.

Les serveurs Radius doivent répondre dans le temps

Lorsque les demandes RADIUS expirent en raison de problèmes de serveur, il y aura à nouveau une accumulation de file d'attente, car les nouvelles demandes ne seront pas envoyées à moins que la réponse attendue en cours ne soit supprimée du système. La fréquence à laquelle les messages de temporisation seront supprimés du système dépend également des configurations de délai d'attente et de délai d'attente maximum.

Dans de nombreux cas, nous pouvons voir que les demandes d'accès ne sont pas traitées par toutes les tâches aaamgr actives. Cela signifie que nous avons une distribution d'appels inégale dans les tâches de sessmgr et plus loin, toutes les instances aamgr ne sont pas impliquées dans le traitement des appels.

La distribution d'appels n'est pas basée sur le mécanisme strict de round robin qui est que s'il y a 10 appels entrants, ils passeront à 10 sessions dans un algorithme monotone.

La distribution des appels est basée sur ces quatre facteurs principaux

  • nombre_session_active
  • charge_processeur
  • Round_trip_delay (demuxmgr - sessmgr - demuxmgr)
  • exception_add_request (démultiplexage vers sessmgr)

Il s'agit de la mise en oeuvre actuelle. La vitesse maximale n'est qu'une limite supérieure, mais en raison de la nature distribuée de notre architecture, vous ne pouvez pas l'extrapoler directement à la charge du châssis. Le comportement dépend de la charge sur un AAAmgr donné
à un moment donné.

La file d'attente Radius max-rate doit être utilisée pour surveiller l'état du système. S'il y a une accumulation de file d'attente,
cela signifie qu'une de ces quatre conditions (voir le tableau) n'est pas remplie et que vous devez identifier la cause première de la même situation.

**le seuil de file d'attente max-rate peut être mis en oeuvre et surveillé en permanence.

TAC Authored

Contribution d’experts de Cisco

Ce document vous est-il utile?

FeedbackCommentaires

Contacter Cisco