Paramètres et gestion CNR recommandés

Introduction

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.

Conditions préalables

Conditions requises

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

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Configuration standard

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).

Recommandations pour la configuration et la configuration

Planification et configuration initiales

• 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.

Configuration générale du système

• 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.

Configuration DHCP

• 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.

Configuration DNS

1. Activez la fonction de transfert incrémentiel :

   nrcmd> dns enable ixfr-enable
   

2. 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.

3. Placez les serveurs DNS principaux et secondaires sur des segments de réseau distincts.

4. 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.

Configuration TFTP

• 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.

Configuration LDAP CNR

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.

Paramètres de réglage du serveur LDAP

• 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.

Procédures courantes

• 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.

Actions immédiates face à un 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.

Analyser les fichiers journaux

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.

Rechercher les problèmes LDAP

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.

Vérifier les bases de données internes de CNR

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.

Vérifier les données DNS avec nslookup

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.

Informations connexes

• Notes techniques de Cisco CNS Network Registrar
• Support technique - Cisco Systems