Configuración y administración de CNR recomendadas

Introducción

Este artículo tiene dos objetivos. Primero, contiene recomendaciones sobre cómo configurar Cisco Network Registrar (CNR) para un rendimiento y estabilidad óptimos y cómo monitorear su instalación de CNR. Segundo, contiene recomendaciones acerca de cómo debe reaccionar si ocurre un problema. En una situación ideal, usted leerá este artículo y seguirá las recomendaciones de configuración y control antes de que haya problemas. Al hacer esto, evitará problemas. Si está leyendo este artículo por primera vez porque tiene un problema con CNR, vaya inmediatamente a la sección Acciones inmediatas al enfrentar un problema. Para obtener más información sobre las recomendaciones, consulte las Guías de Usuario CNR y Referencias de Comandos.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

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

Configuración estándar

Las recomendaciones de configuración que se ofrecen aquí representan un punto de partida. Si su sistema no está configurado de esta manera, revise sus configuraciones. Su configuración puede haberse desarrollado a partir de versiones anteriores de CNR. Las versiones 5.0 ó posteriores de CNR proporcionan un desempeño muy mejorado en comparación con las versiones anteriores, pero deben efectuarse los cambios de parámetros para maximizar los beneficios. Este documento hace hincapié en los entornos de grandes proveedores de servicios, pero muchas de las recomendaciones también se aplican a otros entornos de CNR. Este documento supone que:

• Usted es un prestador de servicios a cargo de una red de banda ancha con 10.000 suscriptores o más.

• Está utilizando CNR 5.0.3 o posterior.

• Utiliza el Protocolo ligero de acceso a directorios (LDAP). CNR se ejecuta sin LDAP, pero muchos proveedores de servicios utilizan LDAP.

• La red tiene una saturación de dirección IP media.

• Con servidores UNIX se ejecuta CNR. La mayoría de las recomendaciones se aplican por igual a Windows NT, pero la mayoría de los proveedores de servicios ejecutan CNR en servidores UNIX, por lo que cuando UNIX y NT difieren, se utiliza el ejemplo de UNIX.

• Cuenta con conexiones ascendentes en otros sistemas (como facturación, atención al cliente o abastecimiento) que se ejecutan en otros servidores.

• El sistema dinámico de nombres de dominio (DDNS) no está activo en el sitio (la mayoría de los proveedores de servicios no utilizan DDNS).

Recomendaciones para la configuración e instalación

Planificación y configuración inicial

• Planifique y documente la asignación de direcciones IP.

• Operaciones de disco intensivo independientes: coloque su servidor DHCP primario en una máquina diferente a su servidor LDAP y servidor DNS primario.

• Documentar la configuración del sistema de terminación del cablemódem (CMTS); asegúrese de que las configuraciones de CMTS y CNR coincidan.

• Prepare planes de recuperación ante catástrofes.

• Documente la tipología de red.

• Tenga en cuenta las versiones del software Cisco IOS® de los CMTS.

Los pasos más eficaces para el estado de su red a largo plazo son: a) planifique su configuración, b) registre esos planes y c) registre los cambios cuando se planifiquen y realicen los cambios. La documentación de los motivos de la elección puede ser útil durante las futuras sesiones de planificación.

Configuración del sistema general

• Use una conmutación por error segura. Se recomienda encarecidamente la conmutación por fallas simple, donde un servidor es principal para todos los ámbitos, y el otro servidor es de respaldo para todos los ámbitos (a diferencia de la conmutación por fallas simétrica, donde ambos servidores son principales y de respaldo al mismo tiempo, dependiendo del alcance individual), ya que simplifica en gran medida las tareas de administración.

• Active las trampas del protocolo simple de administración de red (SNMP). Estos ejemplos son ilustrativos:

  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
  

• Asegúrese de tener la RAM adecuada (512 MB o más).

• Asegúrese de que la partición de datos es lo suficientemente grande (2,5 GB o más).

• Use particiones separadas para registros y datos.

• Garantizar conexiones de alta velocidad y baja latencia entre servidores; verifique las configuraciones de las interfaces.

Las trampas de SNMP le permiten controlar el servidor DHCP desde un monitor de red. Asegúrese de configurar las trampas en el servidor DHCP, de configurar el monitor para que las reciba y las muestre, y obviamente asegúrese de prestar atención al monitor.

La configuración de un sistema de producción requiere compensaciones de costes con respecto a la eficacia del sistema. Sugerimos estos valores suponiendo que unos 100 000 suscriptores en sistemas de clase E250 que ejecutan failover. El uso de muchas políticas, clases de cliente, alcances, búferes de solicitud y respuesta, extensiones DHCP y otras complicaciones afecta a las necesidades de memoria y al rendimiento.

La partición de registros (/var/nwreg2) deberá incrementarse si el número y el tamaño de registros aumenta.

Configuración DHCP

• Configure los búfers de pedido y de respuesta para un rendimiento óptimo. Tenga en cuenta que estas recomendaciones han cambiado para CNR 5.0.

  nrcmd> DHCP set max-dhcp-requests=500
  nrcmd> DHCP set max-dhcp-responses=2000
  

• Tiempo de concesión del cablemódem = 604800 (7 días) o más.

• Tiempo de arrendamiento del equipo de las instalaciones del cliente (CPE): en la medida de lo posible (véase la nota para las compensaciones).

• Aumente los tamaños de registro DHCP y 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
  

• Configure los ajustes de registro que proporcionan los detalles suficientes para identificar los problemas, pero no generan detalles excesivos (lo que dificulta la distinción de problemas y pone cargas innecesarias en el servidor). Estas son las configuraciones recomendadas que son generalmente aplicables. Si es necesario, ajuste su configuración para atender los problemas en su red:

  • Actividad-resumen

  • Predeterminado

  • Actividad sin fallas

  • Habilitar defer-lease-extensions

  • Establecer la última granularidad en tiempo de transacción = intervalo de arrendamiento 1/2

  • Inhabilite allow-client-lease-override para las políticas que ofrecen arrendamientos de producción.

  • Habilite la función de retorno a local; cuando LDAP no está disponible, CNR utiliza datos locales:

    nrcmd> session set visibility=3
    nrcmd> dhcp enable fallback-to-local-client-data
    nrcmd> session set visibility=5
    

• Si utiliza CNR 5.5 o posterior, configure la capacidad de caché del cliente para reducir las consultas LDAP a la mitad.

  nrcmd> dhcp set client-cache-count=2000
  nrcmd> dhcp set client-cache-ttl=5
  

Para utilizar de manera más efectiva la capacidad de rendimiento de los CNR, debería haber tres o cuatro veces más búfers de respuesta que búfers de solicitud. El sistema sólo utiliza tantos búfers como sea necesario. A medida que los plazos de arrendamiento se acortan, se requieren más búfers de respuesta.

Nota: Los plazos de concesión deben concederse siempre que sea práctico. Los alquileres de cablemódem provienen de un espacio de dirección privada (por lo general, red-10) y es muy raro que los módems se trasladen a diversos lugares de la red. La valides debería establecerse en una semana o más. Los arrendamientos CPE, por otra parte, provienen del espacio de la dirección pública, y los CPE (en particular, los portátiles) se mueven. Aquí, la duración de la concesión debe establecerse para que coincida con los hábitos de su población de usuarios. Los arrendamientos prolongados reducen la carga en el servidor DHCP. Si utiliza arrendamientos cortos (de menos de 8 horas), aumente los búfers de respuesta a 2500.

Inhabilite allow-client-lease-override para asegurarse de que los clientes adhieran a los tiempos de arrendamiento especificados en su configuración CNR; algunos clientes intentan invalidar la configuración especificada.

Habilite la opción fall-back-to-local (recurrir a local) para mantener su red en funcionamiento en el caso de una falla en un servidor LDAP Con esta configuración, el servidor DHCP continúa satisfaciendo las solicitudes de arrendamiento aunque el servidor LDAP no responde. El servidor no tendrá acceso a la información específica del cliente almacenada en el servidor LDAP, por lo que cubrirá cada solicitud con una configuración predeterminada. Debe configurar un valor predeterminado que sea razonable para su red.

Por último, la función client-cache guarda en memoria los datos del cliente recuperados de LDAP, de modo que el servidor DHCP necesita consultar LDAP sólo una vez durante el ciclo discovery-offer-request-ack, acelerando el rendimiento del servidor DHCP.

Configuración de DNS

1. Habilite la función de transferencia gradual:

   nrcmd> dns enable ixfr-enable
   

2. Habilitar notificación. Refiérase a las Referencias de Comandos CLI de CNR para ver los argumentos que necesita para habilitar la notificación.

3. Coloque los servidores DNS primario y secundario en segmentos de red independientes.

4. Configure los clientes para consultar un servidor DNS secundario.

Los servidores DNS secundarios reciben sus datos del servidor primario de una de las dos maneras siguientes: a) "total zone transfer", o b) "notify/ixfr" (transferencia incremental). El uso de notify/ixfr reduce el número de registros que se deben transferir de los servidores primarios a los secundarios. Esto es crítico cuando el espacio de nombres es relativamente dinámico.

Configuración de TFTP

• Establezca initial-packet-timeout en 2:

  nrcmd> tftp set initial-packet-timeout = 2
  

• Si utiliza CNR 5.5 o posterior, habilite el almacenamiento en caché de archivos TFTP para mejorar el rendimiento:

  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
  

El almacenamiento en caché de archivos TFTP mantiene los archivos de configuración del cablemódem almacenados en la memoria, evitando las lecturas en el disco cada vez que un cablemódem solicita un archivo de configuración. Es necesario crear un directorio de caché de archivos en el disco duro (CacheDir en el ejemplo anterior) y asignar un tamaño máximo. Elija el tamaño teniendo en cuenta la cantidad total de RAM en su sistema y el número de archivos de configuración diferentes necesarios.

El protocolo TFTP no requiere que el cliente envíe un paquete de reconocimiento final (ACK) al recibir un archivo. Si no se recibe ningún ACK, el servidor debe mantener la conexión del cliente durante el período de tiempo de espera, lo que limita su capacidad para atender nuevas solicitudes. Si su servidor TFTP tiene la capacidad de recursos, también puede aumentar el valor de max-tftp-packets para soportar un mayor número de conexiones de cliente. El valor predeterminado para este parámetro es 512. El valor máximo es 1000.

Configuración de CNR LDAP

Estos parámetros muestran una configuración en la que CNR escribe actualizaciones de arrendamiento en el LDAP. Si es posible, diseñe su red para que esto no sea necesario. Se muestra aquí para proporcionar recomendaciones si debe escribir actualizaciones de arrendamiento. Optimice las conexiones LDAP utilizando objetos LDAP READ/WRITE ajustables por separado. (Cada objeto obtiene su propio grupo de subprocesos).

# 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 configuración presentada incluye hacer que CNR escriba actualizaciones de arrendamiento en el LDAP. Quizás quiera hacer esto para permitir que las aplicaciones consulten a LDAP por la información de arrendamiento actual aunque debe tratar de evitar estructurar su aplicación para que esto sea necesario. Si necesita que la información sobre el estado de arrendamiento para una dirección IP esté disponible, puede usar el comando NRCMD lease para obtener la dirección MAC, el vencimiento y más información sobre el estado actual del arrendamiento.

Los directorios LDAP fueron diseñados para ser leídos rápida y eficientemente, pero la escritura en directorios LDAP es ineficiente. Si configura CNR para escribir información de arrendamiento en LDAP, LDAP se convierte en un cuello de botella para el rendimiento general del sistema. Si debe configurar escrituras de arrendamiento LDAP, utilice las configuraciones recomendadas. Tenga en cuenta que el acceso CNR a LDAP se ha optimizado a través del uso de objetos de "leer" y "actualizar LDAP" separados. Asimismo, observe el tiempo de espera de escritura de 30 segundos. Con un tiempo de espera más corto corre el riesgo de que las escrituras de LDAP se suspendan cuando el LDAP está bajo carga pesada. Luego, CNR vuelve a intentar escribir y esto genera una carga adicional en LDAP.

La cantidad total de conexiones a su servidor LDAP no debería exceder la cantidad máxima de secuencias disponibles. Si su servidor LDAP admite varios subprocesos por conexión, el número óptimo de conexiones es el número total de subprocesos dividido por el número de subprocesos por conexión.

Parámetros de ajuste del servidor LDAP

• Cree índices para los campos de búsqueda.

• Configure el tamaño de la memoria caché para aumentar la cantidad de entradas almacenadas en la memoria caché, a pesar de que ésta no debe exceder un tercio de la memoria disponible.

• Configure secuencias máximas para aumentar el número de conexiones simultáneas que se pueden admitir, aunque éste no debería consumir más de la mitad de los recursos disponibles.

• Configure los ajustes de registro que proporcionan suficiente detalle para identificar los problemas pero no generan demasiados detalles (lo que dificulta la distinción de problemas y pone cargas innecesarias en el servidor).

• Use particiones separadas para registros y datos.

Las implementaciones específicas del servidor LDAP varían. Consulte la documentación del servidor para implementar estas sugerencias.

Procedimientos de rutina

• Respalde regularmente las bases de datos CNR. Consulte las Guías de usuario para obtener instrucciones. Debe realizar una copia de seguridad de las bases de datos CNR al menos una vez al día. Conserve los archivos de respaldo al menos por dos semanas.

• Respalde regularmente LDAP.

• Realice copias de seguridad periódicas y archive los registros.

• Después de que se realicen los cambios en CNR, asegúrese de que la configuración de los servidores principales y de respaldo en un escenario de failover se mantenga consistente. Utilice la herramienta cnrFailoverConfig -compare en las versiones 5.5 y anteriores de CNR, o compare las configuraciones usando la WebUI en CNR 6.0 y posteriores.

• Cuando se programan cambios en la topología de la red, establezca los tiempos de renovación y arrendamiento de DHCP en valores reducidos.

• Supervise el uso de la dirección IP (utilice trampas SNMP).

• Supervise el uso del sistema (memoria, disco, CPU e intercambio). La utilidad superior es útil para este fin.

• Periódicamente revise los registros para familiarizarse con los casos normales. La comprensión de los registros normales le permite manejar los problemas con mayor rapidez.

• Revise periódicamente los registros de excepciones: grep para "error", "advertencia" o "conexión" (por ejemplo, en UNIX, use grep -i warn name_dhcp_1_log).

La conmutación por error segura DHCP requiere que los parámetros de configuración para un alcance sean idénticos en el servidor primario y de respaldo para ese alcance. Asegúrese de que, cuando realice un cambio en una configuración, realice el cambio en ambos servidores. Utilice periódicamente cnrFailoverConfig -compare o WebUI en CNR 6.0 y posterior para asegurarse de que no hay diferencias.

Los cambios en la topología de red o en la asignación de direcciones IP pueden hacer necesario que los clientes obtengan una dirección diferente. Debe planificar un periodo de tiempo en el cual algunos clientes en una subred tengan una dirección del rango viejo y algunos hayan renovado y obtenido una dirección del rango nuevo. Puede reducir la cantidad de tiempo durante el cual ambas direcciones son activadas reduciendo la duración de validez antes que realice el cambio para que todos los clientes tengan una duración de validez corta. Esto garantiza que deben renovar sus arrendamientos con frecuencia y, por lo tanto, recoger un arrendamiento del nuevo rango poco después de realizar el cambio. Asegúrese de no establecer el tiempo de concesión tan corto que los arrendamientos se agoten mientras se detiene e inicia el servidor para realizar el cambio. Después de realizar el cambio, asegúrese de restaurar el período de arrendamiento original para que no aumente la carga en el servidor.

El método más efectivo para resolver problemas es evitarlos. El seguimiento de las recomendaciones descritas anteriormente mantiene a los administradores en sintonía con su operación y le permite evitar problemas graves. Cuando aparecen problemas (como aumento del tiempo de espera de E/S o aumento del uso de la memoria por ningún motivo conocido), siga con los registros. Revise los cambios recientes en su entorno físico o en la configuración de CNR para verificar si pueden ser la fuente de los problemas.

Los registros de CNR son tus amigos. Cuando comienza a utilizar CNR, a actualizarlo o a cambiar su configuración, use el comando grep descripto para verificar que los registros no tengan errores. A continuación, retroceda en el registro para comprender cuándo y cómo surgió el problema y solucionar el problema.

Acciones inmediatas cuando se enfrenta un problema

• No reinicie CMTS a menos que el personal de soporte de Cisco se lo solicite (sólo se aplica a entornos de cable).

• No reinicie el CNR, salvo que el personal de asistencia de Cisco se lo solicite.

• No inhabilite el modo a prueba de fallos, salvo que así lo solicite el personal de soporte de Cisco.

• No recargue, reinicie ni interrumpa CNR de ninguna manera con la resincronización de failover segura en curso.

• Copie los archivos de registro en un directorio donde no se los pueda sobrescribir. Si CNR sufrió una caída, copie el archivo central en un directorio en el que no sea sobrescrito.

• Debe utilizar:

  nrcmd> server dhcp getRelatedServers
  

  para aislar el error de configuración de failover seguro.

• Busque en el registro las excepciones. Compruebe en particular la secuencia de inicio (puede estar en un registro antiguo): Grep para “error", “warn” o “connect” (por ejemplo: grep -i error name_dhcp_1_log*).

Cuando se enfrenta a un problema, es fundamental que no se produzcan más daños mientras se aísla y se soluciona el problema inicial. El reinicio de un CMTS o el reinicio de CNR crean picos de carga inmediatos durante un momento en que el sistema ya es frágil. El objetivo es que su sistema vuelva a funcionar en su totalidad en la menor cantidad de tiempo. El tiempo transcurrido hasta su última acción cuenta; el tiempo para la primera acción no cuenta. En otras palabras, no tome medidas rápidas sólo por el bien de una acción rápida. Piense antes de actuar.

Inicie un registro de todos los pasos realizados y de todos los cambios realizados en cualquier lugar del sistema: Servidores DHCP, DNS o TFTP, y cambios realizados en cualquier CMTS o cablemódem. Describa el problema y registre, en detalle, sólo la conducta observable.

Analizar archivos de registro’

Recopile los registros (/var/nwreg2/logs). Analícelos buscando errores o advertencias. Utilice un editor de texto para analizar más a fondo los errores de interés. Comenzando por el error, revise todas las entradas del registro que relacionan al error con la dirección MAC, con la dirección IP o con el nombre del dominio.

Puede ser necesario encender la registración adicional para diagnosticar los problemas del DHCP. El servidor DHCP admite una amplia gama de funciones de registro. Consulte las Referencias de Comandos CLI de CNR para obtener una lista de opciones de registro y una explicación de cada una. Tenga cuidado, ya que cada mensaje del registro coloca carga en el servidor. Debe realizar un intercambio entre la cantidad de información que le solicita a CNR para registrar y el rendimiento del servidor.

Verifique si hay problemas de LDAP

Es posible que el problema pertenezca al servidor de LDAP. CNR crea una cola de solicitudes al servidor LDAP. Si el servidor LDAP no puede seguir el ritmo de la carga, la cola se acumula. Busque en el directorio /var/nwreg2/data/dhcpeventstore. Los archivos del almacén de eventos se fijan en su tamaño, por lo que, si la cola se está acumulando, CNR crea más archivos. Si hay más de un archivo en el directorio, esto indica que la cola está realizando una copia de seguridad. La misma cola se utiliza para poner en cola las solicitudes al servidor DNS, de modo que si la cola realiza una copia de seguridad y está utilizando DDNS, podría estar llenando con solicitudes al servidor DNS. Para determinar si el problema es con LDAP, active el registro de interfaz LDAP CNR adicional. Habilite los indicadores de registro ldap-create-detail, ldap-query-detail y ldap-update-detail. El mensaje de registro incluye sellos de tiempo que le ayudan a determinar si LDAP es el cuello de botella del sistema.

Verificar las bases de datos internas de CNR

Si sospecha que el problema puede ser que una o más de las bases de datos internas de CNR han perdido integridad, consulte las Guías de usuario de CNR para aprender cómo ejecutar las utilidades de verificación de validez de la base de datos. Si una de estas utilidades indica un problema, siga las instrucciones en las Guías de usuario para resolverlo.

Comprobar datos DNS con nslookup

La utilidad nslookup se incluye tanto con sistemas UNIX como con Windows NT. Puede ser utilizado para interrogar un servidor DNS y, en consecuencia, es útil para verificar los datos almacenados por el servidor. La documentación para su sistema operativo proporciona información detallada acerca de sus capacidades.

Información Relacionada

• Recomendación técnica de Cisco Network Registrar CNS
• Soporte Técnico - Cisco Systems