Cet article a deux objectifs. Tout d'abord, il contient des recommandations sur la façon de configurer Cisco Network Registrar (CNR) pour des performances et une stabilité optimales et sur la façon de surveiller votre installation CNR. Deuxièmement, il contient des recommandations sur la façon de réagir en cas de problème. Dans le cas idéal, vous lirez cet article et appliquerez les recommandations de configuration et de surveillance avant tout problème. Ce faisant, vous éviterez les problèmes. Si vous lisez cet article pour la première fois parce que vous avez un problème avec le CN, allez immédiatement à la section Mesures immédiates face à un problème. Pour plus d'explications sur les recommandations, veuillez consulter les Guides d'utilisation et les références des commandes du CN.
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Les recommandations de configuration proposées ici représentent un point de départ. Si votre système est configuré différemment de celui-ci, vérifiez vos paramètres. Votre configuration a peut-être été développée à partir de versions antérieures de CNR. Les versions CNR 5.0 et ultérieures offrent des performances nettement supérieures à celles des versions précédentes, mais des modifications de paramètres doivent être apportées pour obtenir le maximum d'avantages. Ce document porte principalement sur les grands environnements de fournisseurs de services, mais bon nombre des recommandations s'appliquent également à d'autres environnements de CN. Ce document suppose que :
Vous êtes un fournisseur de services qui gère un réseau à large bande comptant au moins 10 000 abonnés.
Vous utilisez CNR 5.0.3 ou version ultérieure.
Vous utilisez le protocole LDAP (Lightweight Directory Access Protocol). CNR fonctionne sans LDAP, mais de nombreux fournisseurs de services utilisent LDAP.
Votre réseau a une saturation d'adresse IP moyenne.
Vous exécutez CNR sur des serveurs UNIX. La plupart des recommandations s'appliquent également à Windows NT, mais la plupart des fournisseurs de services exécutent CNR sur des serveurs UNIX, de sorte que là où UNIX et NT diffèrent, l'exemple UNIX est utilisé.
Vous disposez de connexions en amont vers d'autres systèmes (tels que la facturation, le service client ou le provisionnement) qui s'exécutent sur d'autres serveurs.
Le système DDNS (Dynamic Domain Name System) n'est pas actif sur votre site (la plupart des fournisseurs de services n'utilisent pas le DDNS).
Planifier et documenter l'allocation des adresses IP.
Opérations distinctes à forte intensité de disque : placez votre serveur DHCP principal sur une autre machine que votre serveur LDAP et votre serveur DNS principal.
Documenter la configuration de votre système de terminaison de modem câble (CMTS); vérifiez que les configurations CMTS et CNR correspondent.
Préparer des plans de reprise après sinistre.
Documentez la topologie de votre réseau.
Notez les versions du logiciel Cisco IOS® des CMTS.
Les étapes les plus efficaces pour assurer l'intégrité à long terme de votre réseau sont les suivantes : a) planifiez votre configuration, b) enregistrez ces plans et c) enregistrez les modifications lorsque les modifications sont planifiées et effectuées. Documenter les raisons des choix peut aider lors des sessions de planification futures.
Utilisez le basculement sécurisé. Le basculement simple, où un serveur est principal pour toutes les étendues, et l'autre serveur est la sauvegarde pour toutes les étendues (par opposition au basculement symétrique, où les deux serveurs sont principaux et la sauvegarde en même temps, selon la portée individuelle), est fortement recommandé, car il simplifie considérablement les tâches d'administration.
Activez les déroutements SNMP (Simple Network Management Protocol). Ces exemples sont donnés à titre d'exemple :
nrcmd> trap enable address-conflict nrcmd> trap enable dhcp-failover-config-mismatch nrcmd> trap enable other-server-not-responding nrcmd> trap set free-address-low-threshold=15% nrcmd> trap set free-address-high-threshold=30% nrcmd> trap enable free-address-low
Assurez-vous d'avoir une mémoire vive suffisante (512 Mo ou plus).
Assurez-vous que la partition de données est suffisamment grande (2,5 Go ou plus).
Utilisez des partitions distinctes pour les journaux et les données.
Garantir des connexions à haut débit et à faible latence entre les serveurs ; vérifiez les paramètres de l'interface.
Les déroutements SNMP vous permettent de surveiller le serveur DHCP à partir d'un moniteur réseau. Assurez-vous de configurer les déroutements sur le serveur DHCP, de configurer le moniteur pour les recevoir et les afficher, et assurez-vous évidemment de prêter attention au moniteur.
La configuration d'un système de production nécessite des compromis entre le coût et l'efficacité du système. Nous suggérons ces valeurs en supposant environ 100 000 abonnés sur des systèmes de classe E250 exécutant un basculement. L'utilisation de nombreuses politiques, classes de clients, étendues, tampons de requêtes et de réponses, extensions DHCP et autres complications affecte les besoins en mémoire et les performances.
La partition de journal (/var/nwreg2) doit être augmentée si le nombre et la taille des journaux sont augmentés.
Définissez les tampons de requête et de réponse pour un débit optimal. Notez que ces recommandations ont changé pour CNR 5.0.
nrcmd> DHCP set max-dhcp-requests=500 nrcmd> DHCP set max-dhcp-responses=2000
Durée de location du modem câble = 604800 (7 jours) ou plus.
Durée de location de l'équipement client (CPE) : dans la mesure du possible (voir note pour les compromis).
Augmenter la taille des journaux DHCP et TFTP :
nrcmd> server DHCP serverLogs nlogs=15 logsize=10M nrcmd> server DNS serverLogs nlogs=15 logsize=10M nrcmd> server TFTP serverLogs nlogs=10 logsize=10M
Configurez des paramètres de journal qui fournissent suffisamment de détails pour identifier les problèmes, mais ne génèrent pas de détails excessifs (ce qui rend difficile la distinction des problèmes et met une charge inutile sur le serveur). Il s'agit de paramètres recommandés qui sont généralement applicables. Réglez vos paramètres si nécessaire pour résoudre les problèmes de votre réseau :
Résumé de l'activité
Par défaut
Aucune activité de basculement
Activer les extensions de report-bail
Définir la granularité du temps de la dernière transaction = intervalle de bail 1/2
Désactivez allow-client-lease-override pour les stratégies proposant des baux de production.
Activer le retour arrière vers local ; lorsque LDAP n'est pas disponible, CNR utilise les données locales :
nrcmd> session set visibility=3 nrcmd> dhcp enable fallback-to-local-client-data nrcmd> session set visibility=5
Si vous utilisez CNR 5.5 ou version ultérieure, configurez la fonctionnalité de cache client pour réduire de moitié les requêtes LDAP.
nrcmd> dhcp set client-cache-count=2000 nrcmd> dhcp set client-cache-ttl=5
Pour tirer le meilleur parti de la capacité de débit du CN, il devrait y avoir trois à quatre fois plus de tampons de réponse que de tampons de requête. Le système n'utilise que autant de tampons qu'il en a besoin. À mesure que les délais de bail deviennent plus courts, davantage de tampons de réponse sont nécessaires.
Note : Les délais de location doivent être pris aussi longtemps que possible. Les baux de modem câble proviennent d’un espace d’adressage privé (généralement net-10) et les modems se déplacent rarement vers différents emplacements sur le réseau. Ces baux devraient être effectués une semaine ou plus. Les baux CPE, en revanche, proviennent de l'espace d'adressage public et les CPE (en particulier les ordinateurs portables) se déplacent. Ici, la durée du bail doit être définie pour correspondre aux habitudes de votre population d'utilisateurs. Des baux plus longs réduisent la charge sur le serveur DHCP. Lorsque vous utilisez des baux courts (moins de 8 heures), augmentez les tampons de réponse à 2 500.
Désactivez allow-client-lease-override pour vous assurer que les clients respectent les délais de bail spécifiés dans votre configuration CNR : certains clients tentent de remplacer le paramètre spécifié.
Activez le retour arrière vers local pour maintenir le fonctionnement de votre réseau en cas de défaillance d'un serveur LDAP. Avec ce paramètre, le serveur DHCP continue à répondre aux demandes de bail même si le serveur LDAP ne répond pas. Le serveur n'aura pas accès aux informations spécifiques du client stockées dans le serveur LDAP, de sorte qu'il satisfera chaque demande avec un paramètre par défaut. Vous devez configurer une valeur par défaut raisonnable pour votre réseau.
Enfin, la fonction client-cache conserve en mémoire les données client extraites du LDAP, de sorte que le serveur DHCP ne doit interroger LDAP qu'une seule fois pendant le cycle discovery-offer-request-ack, ce qui accélère les performances du serveur DHCP.
Activez la fonction de transfert incrémentiel :
nrcmd> dns enable ixfr-enable
Activer la notification. Reportez-vous aux références de commandes CLI CNR pour connaître les arguments dont vous avez besoin pour activer la notification.
Placez les serveurs DNS principaux et secondaires sur des segments de réseau distincts.
Configurez les clients pour qu'ils interrogent un serveur DNS secondaire.
Les serveurs DNS secondaires reçoivent leurs données du serveur principal de deux manières : a) « transfert de zone complet » ou b) « notification/ixfr » (transfert incrémentiel). L'utilisation de la fonction de notification/ixfr réduit le nombre d'enregistrements devant être transférés du serveur principal vers le serveur secondaire. Ceci est essentiel lorsque l'espace de noms est relativement dynamique.
Définissez initial-packet-timeout sur 2 :
nrcmd> tftp set initial-packet-timeout = 2
Si vous utilisez CNR 5.5 ou version ultérieure, activez la mise en cache des fichiers TFTP pour améliorer les performances :
nrcmd> tftp set home-directory=/var/nwreg2/data/tftp nrcmd> tftp set file-cache-directory=CacheDir nrcmd> tftp set file-cache-max-memory-size=32000 nrcmd> tftp enable file-cache nrcmd> tftp reload
La mise en cache des fichiers TFTP permet de conserver les fichiers de configuration du modem câble en mémoire, en évitant de les lire sur le disque chaque fois qu’un modem câble demande un fichier de configuration. Un répertoire de cache de fichiers doit être créé sur le disque dur (CacheDir dans l'exemple ci-dessus) et une taille maximale est affectée. Choisissez la taille en tenant compte de la quantité totale de mémoire vive dans votre système et du nombre de fichiers de configuration différents nécessaires.
Le protocole TFTP n’exige pas que le client envoie un paquet d’accusé de réception final (ACK) à la réception d’un fichier. Si aucun ACK n'est reçu, le serveur doit conserver la connexion du client pendant la période d'expiration, ce qui limite sa capacité à traiter de nouvelles demandes. Si votre serveur TFTP a la capacité de ressources, vous pouvez également augmenter la valeur de max-tftp-packets pour prendre en charge un plus grand nombre de connexions client. La valeur par défaut de ce paramètre est 512. La valeur maximale est 1000.
Ces paramètres affichent une configuration dans laquelle CNR écrit des mises à jour de bail dans LDAP. Si possible, concevez votre réseau pour qu'il ne soit pas nécessaire. Il est présenté ici pour fournir des recommandations si vous devez écrire des mises à jour de bail. Optimisez les connexions LDAP en utilisant des objets LDAP READ/WRITE réglables séparément. (Chaque objet obtient son propre groupe de threads).
# Create and Configure a New LDAP Create/Update object ldap LDAP-Write create csrc-ldap ldap LDAP-Write set password=changeme ldap LDAP-Write set port=389 ldap LDAP-Write set preference=1 ldap LDAP-Write setEntry query-dictionary csrcclientclass=client-class-name ldap LDAP-Write set reactivate-interval=60s ldap LDAP-Write set search-filter= (&(macaddress=%s)(|(csrcclassname=Computer)(csrcclassname=Modem))) ldap LDAP-Write set search-path=csrcprogramname=csrc,o=NetscapeRoot ldap LDAP-Write set username= "uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot" ldap LDAP-Write set can-query=disabled ldap LDAP-Write set can-create=enabled ldap LDAP-Write set can-update=enabled ldap LDAP-Write set connections=2 ldap LDAP-Write set limit-requests=enabled ldap LDAP-Write set max-requests=8 ldap LDAP-Write set timeout=30s ### Create and Configure a New LDAP Read object ldap LDAP-Read create csrc-ldap ldap LDAP-Read set password=changeme ldap LDAP-Read set port=389 ldap LDAP-Read set preference=1 ldap LDAP-Read setEntry query-dictionary csrcclientclass=client-class-name ldap LDAP-Read set reactivate-interval=60s ldap LDAP-Read set search-filter= (&(macaddress=%s)(|(csrcclassname=Computer)(csrcclassname=Modem))) ldap LDAP-Read set search-path=csrcprogramname=csrc,o=NetscapeRoot ldap LDAP-Read set username= "uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot" ldap LDAP-Read set can-query=enabled ldap LDAP-Read set can-create=disabled ldap LDAP-Read set can-update=disabled ldap LDAP-Read set connections=3 ldap LDAP-Read set limit-requests=enabled ldap LDAP-Read set max-requests=12 ldap LDAP-Read set timeout=3s
La configuration affichée inclut des mises à jour de bail d'écriture CNR pour LDAP. Vous pouvez effectuer cette opération pour permettre aux applications d'interroger LDAP pour obtenir des informations de bail actuelles, mais vous devez essayer d'éviter de structurer votre application afin que cela soit nécessaire. Si vous devez fournir des informations sur l'état du bail pour une adresse IP, vous pouvez utiliser la commande NRCMD lease pour obtenir l'adresse MAC, l'expiration et d'autres informations sur l'état actuel du bail.
Les annuaires LDAP sont conçus pour être lus rapidement et efficacement, mais l'écriture dans un annuaire LDAP est inefficace. Si vous configurez CNR pour écrire les informations de bail dans LDAP, LDAP devient un goulot d'étranglement pour les performances globales du système. Si vous devez configurer les écritures de bail LDAP, utilisez les paramètres recommandés. Notez que l'accès CNR à LDAP a été optimisé grâce à l'utilisation d'objets LDAP distincts « read » et « update LDAP ». Notez également le délai d'écriture de 30 secondes. Avec un délai d'attente plus court, vous courez le risque d'écritures LDAP lorsque LDAP est soumis à une charge élevée. Ensuite, CNR recommence l'écriture, ce qui ajoute une charge supplémentaire à LDAP.
Le nombre total de connexions à votre serveur LDAP ne doit pas dépasser le nombre maximal de threads disponibles. Si votre serveur LDAP prend en charge plusieurs threads par connexion, le nombre optimal de connexions est le nombre total de threads divisé par le nombre de threads par connexion.
Créer des index pour les champs de recherche.
Configurez la taille du cache pour augmenter le nombre d'entrées mises en cache dans la mémoire, bien que le cache ne doit pas dépasser un tiers de la mémoire disponible.
Configurez le nombre maximal de threads pour augmenter le nombre de connexions simultanées pouvant être prises en charge, bien que cela ne doive pas dépasser la moitié des ressources disponibles.
Configurez des paramètres de journal qui fournissent suffisamment de détails pour identifier les problèmes mais ne génèrent pas de détails excessifs (ce qui rend difficile la distinction des problèmes et met une charge inutile sur le serveur).
Utilisez des partitions distinctes pour les journaux et les données.
Les mises en oeuvre de serveurs LDAP spécifiques varient. Reportez-vous à la documentation de votre serveur pour mettre en oeuvre ces suggestions.
Sauvegarder régulièrement les bases de données du CN. Reportez-vous aux Guides d'utilisation pour obtenir des instructions. Vous devriez sauvegarder les bases de données du CN au moins une fois par jour. Conservez les fichiers de sauvegarde pendant au moins deux semaines.
Sauvegardez régulièrement LDAP.
Sauvegarder et archiver régulièrement les journaux.
Une fois les modifications apportées à CNR, assurez-vous que la configuration des serveurs principal et de sauvegarde dans un scénario de basculement reste cohérente. Utilisez l'outil cnrFailoverConfig -compare dans CNR versions 5.5 et antérieures, ou comparez les configurations à l'aide de WebUI dans CNR 6.0 et ultérieures.
Lorsque des modifications de la topologie du réseau sont planifiées, définissez les délais de renouvellement et de bail DHCP sur de petites valeurs.
Surveillez l'utilisation des adresses IP (utilisez des interruptions SNMP).
Surveillez l'utilisation du système (mémoire, disque, processeur et échange). Le dessus de l'utilitaire est utile à cet effet.
Examiner périodiquement les journaux pour se familiariser avec les cas normaux. Comprendre les journaux normaux vous permet de gérer les problèmes plus rapidement.
Consulter périodiquement les journaux des exceptions : grep pour « error », « warn » ou « connect » (par exemple, sous UNIX, utilisez grep -i warn name_dhcp_1_log).
Le basculement sécurisé DHCP nécessite que les paramètres de configuration d'une étendue soient identiques sur le serveur principal et le serveur de sauvegarde de cette étendue. Lorsque vous modifiez un paramètre, assurez-vous que vous le modifiez sur les deux serveurs. Utilisez périodiquement cnrFailoverConfig -compare ou WebUI dans CNR 6.0 et versions ultérieures pour vérifier s'il n'y a pas de différences.
Les modifications de la topologie du réseau ou de l’allocation d’adresses IP peuvent rendre nécessaire l’obtention d’une adresse différente par les clients. Vous devez prévoir une période de temps pendant laquelle certains clients d'un sous-réseau ont une adresse de l'ancienne plage et certains ont renouvelé et obtenu une adresse de la nouvelle plage. Vous pouvez réduire la durée pendant laquelle les deux ensembles d'adresses sont actifs en réduisant la durée des baux avant que vous ne procédiez à la modification de sorte que tous les clients aient des baux de courte durée. Cela garantit qu'ils doivent renouveler fréquemment leurs baux et donc prendre un bail de la nouvelle gamme peu après que vous ayez fait le changement. Veillez à ne pas définir le délai de bail si court que les baux expirent lorsque vous arrêtez et démarrez le serveur pour effectuer la modification. Après avoir effectué la modification, veillez à restaurer la période de bail d'origine afin de ne pas augmenter la charge sur le serveur.
L'approche la plus efficace pour résoudre les problèmes consiste à les éviter. Suivez les recommandations ci-dessus pour que vos administrateurs soient en phase avec votre fonctionnement et vous évitent les problèmes graves. Lorsque des problèmes apparaissent (tels que l'augmentation du temps d'attente des E/S ou l'augmentation de l'utilisation de la mémoire sans raison connue), suivez les journaux. Examinez les modifications récentes apportées à votre environnement physique ou à votre configuration CNR pour voir si cela peut être la source des problèmes.
Les journaux du CN sont vos amis. Lorsque vous commencez à utiliser CNR, à mettre à niveau CNR ou à modifier la configuration de CNR, utilisez la commande grep décrite pour vérifier les journaux à la recherche de problèmes. Ensuite, refaites le travail dans le journal pour comprendre quand et comment le problème s'est produit et résoudre le problème.
Ne redémarrez pas CMTS à moins que le personnel d'assistance de Cisco ne l'ait demandé (s'applique uniquement aux environnements câblés).
Ne redémarrez pas CNR à moins que le personnel d'assistance de Cisco ne vous y invite.
Ne désactivez pas le basculement sécurisé à moins que le personnel d'assistance Cisco ne vous le demande.
Ne rechargez, redémarrez ou interrompez pas CNR de quelque manière que ce soit avec une resynchronisation de basculement sécurisée en cours.
Ne copiez pas les fichiers journaux dans un répertoire où ils ne seront pas écrasés. Si CNR s'est écrasé, copiez le fichier principal dans un répertoire où il ne sera pas écrasé.
À utiliser :
nrcmd> server dhcp getRelatedServers
pour isoler les erreurs de configuration du basculement sécurisé.
Consultez les journaux pour connaître les exceptions. Vérifiez en particulier la séquence de démarrage (peut-être dans un ancien journal) : grep pour « error », « warn » ou « connect » (par exemple grep -i error name_dhcp_1_log*).
Lorsque vous faites face à un problème, il est essentiel que vous ne causiez plus de dommages tout en isolant et en corrigeant le problème initial. Le redémarrage d'un CMTS ou le redémarrage de CNR crée des pics de charge immédiats pendant une période où le système est déjà fragile. L'objectif est de faire en sorte que votre système fonctionne à nouveau dans les plus brefs délais. Le temps écoulé jusqu'à ce que votre dernière action compte ; le temps de votre première action ne compte pas. En d'autres termes, ne prenez pas de mesures rapides uniquement pour agir rapidement. Réfléchissez avant d'agir.
Démarrez un journal de toutes les étapes effectuées et de toutes les modifications apportées n'importe où dans le système : Serveurs DHCP, DNS ou TFTP, et modifications apportées à n'importe quel CMTS ou modem câble. Décrire le problème et consigner en détail le comportement observable.
Collecter les journaux (/var/nwreg2/logs). Analysez-les et recherchez des erreurs ou des avertissements. Utilisez un éditeur de texte pour analyser plus en détail les erreurs d'intérêt. À partir de l'erreur, recherchez dans le journal toutes les entrées relatives à l'adresse MAC, à l'adresse IP ou au nom de domaine associé à l'erreur.
Vous devrez peut-être activer une journalisation supplémentaire pour diagnostiquer les problèmes DHCP. Le serveur DHCP prend en charge une large gamme de fonctionnalités de journalisation. Reportez-vous aux références de commandes CLI CNR pour obtenir une liste des options de journalisation et une explication de chacune d'elles. Attention, chaque message de journal place la charge sur le serveur. Vous devez faire un compromis entre la quantité d'informations que vous demandez au CN de consigner et les performances du serveur.
Le problème peut provenir du serveur LDAP. CNR crée une file d'attente de requêtes vers le serveur LDAP. Si le serveur LDAP ne peut pas suivre la charge, la file d'attente s'accumule. Recherchez dans le répertoire /var/nwreg2/data/dhcpeventstore. La taille des fichiers du magasin d'événements est fixe. Si la file d'attente est en cours de création, CNR crée davantage de fichiers. S'il y a plusieurs fichiers dans le répertoire, cela indique que la file d'attente est en cours de sauvegarde. La même file d'attente est utilisée pour mettre en file d'attente les requêtes vers le serveur DNS. Par conséquent, si la file d'attente est en cours de sauvegarde et que vous utilisez DDNS, elle peut être remplie avec des requêtes vers le serveur DNS. Pour déterminer si le problème concerne LDAP, activez la journalisation de l'interface LDAP CNR supplémentaire. Activez les indicateurs de journal ldap-create-detail, ldap-query-detail et ldap-update-detail. Le message de journal inclut des horodatages qui vous aident à déterminer si LDAP est le goulot d'étranglement du système.
Si vous soupçonnez que le problème peut être que l'une ou plusieurs des bases de données internes du CN ont perdu leur intégrité, consultez les Guides d'utilisation du CN pour savoir comment exécuter les utilitaires de vérification de validité de la base de données. Si l'un de ces utilitaires indique un problème, continuez à suivre les instructions des guides d'utilisation pour le résoudre.
L'utilitaire nslookup est fourni avec les systèmes UNIX et Windows NT. Il peut être utilisé pour interroger un serveur DNS et est donc utile pour vérifier les données stockées par le serveur. La documentation de votre système d'exploitation fournit des informations détaillées sur ses fonctionnalités.