El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe un procedimiento para cambiar la definición del clúster de Cisco Unified Communications Manager (CUCM) de un formato de dirección IP o nombre de host a un formato de nombre de dominio completo (FQDN).
CUCM tiene la opción de elegir si utilizar direcciones IP o servicio de nombres de dominio (DNS) para comunicarse entre nodos y con terminales.
Para los sistemas anteriores a 10.x, la recomendación era no utilizar la dependencia de DNS a menos que se lo requiera un diseño o requisitos específicos.
A partir de CUCM 10.x, debido a la estrecha integración entre CUCM y Cisco Unified Communications Manager IM & Presence Service (IM&P), esa recomendación ha cambiado. Aunque no se puede utilizar DNS en implementaciones básicas de telefonía IP, el uso de nombres de dominio completos en lugar de direcciones IP se convirtió en un requisito para que algunas funciones clave funcionen:
Para configurar una conexión segura, un cliente necesita verificar la identidad del servidor que presenta el certificado.
El cliente realiza la validación en dos pasos:
La identidad del servidor en el certificado deriva del atributo Common Name (CN) o del atributo Subject Alternative Name (SAN) del certificado recibido.
Nota: SAN, si está presente, tiene prioridad sobre CN.
La identidad del servidor en la configuración local se deriva del archivo de configuración del dispositivo descargado a través del protocolo trivial de transferencia de archivos (TFTP) y/o de las interacciones de los servicios de datos del usuario (UDS). Los servicios TFTP y UDS derivan esta configuración de la tabla processnode de la base de datos. Se puede configurar en la página web CM Administration > System > Server.
No confunda la página CM Administration > System > Server , donde se definen los servidores, con OS Administration > Settings > IP Ethernet, donde se configuran los parámetros de red para los servidores. Los parámetros de la página OS Administration afectan a la configuración de red real del servidor; el cambio de nombre de host o dominio lleva a la regeneración de todos los certificados para el nodo. La configuración de la página de administración de CM define, cómo CUCM se anuncia a los terminales a través de archivos de configuración o UDS. El cambio de esta configuración no requiere la regeneración de certificados. Esta configuración debe coincidir con uno de los siguientes parámetros de red del nodo: Dirección IP, nombre de host o FQDN.
Por ejemplo, el terminal se conecta de forma segura a server.mydomain.com. Examina el certificado recibido y verifica si "server.mydomail.com" está presente en este certificado como CN o SAN. Si la comprobación no se realiza correctamente, la conexión falla o un usuario final recibe un mensaje emergente, solicitando aceptar un certificado no confiable, dependiendo de la funcionalidad del cliente. Dado que los CN y SAN en los certificados normalmente tienen formato FQDN, debe cambiar la definición de servidor de la dirección IP al formato FQDN, si desea evitar estas ventanas emergentes o fallas de conexión.
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
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.
Antes de la configuración, se recomienda encarecidamente asegurarse de que se cumplen los requisitos previos.
Paso 1. Verifique la configuración de DNS.
Ejecute estos comandos desde CUCM CLI para asegurarse de que el servicio DNS esté configurado y de que las entradas FQDN para los nombres de nodo se puedan resolver tanto local como externamente.
admin:show network eth0
<omitted for brevity>
DNS
Primary : 10.48.53.194 Secondary : Not Configured
Options : timeout:5 attempts:2
Domain : mydomain.com
Gateway : 10.48.52.1 on Ethernet 0
admin:utils network host cucm105pub.mydomain.com
Local Resolution:
cucm105pub.mydomain.com resolves locally to 10.48.53.190
External Resolution:
cucm105pub.mydomain.com has address 10.48.53.190
admin:
Paso 2. Prueba de diagnóstico de red.
Asegúrese de que la prueba de diagnóstico de red se supere ejecutando este comando CLI.
admin:utils diagnose module validate_network
Log file: platform/log/diag3.log
Starting diagnostic test(s)
===========================
test - validate_network : Passed
Diagnostics Completed
Paso 3. Configuración DHCP para terminales.
Asegúrese de que se agrega la configuración del protocolo de configuración dinámica de host (DHCP) necesaria para que los teléfonos registrados puedan resolver el problema de DNS.
Paso 4. Replicación de la base de datos.
Asegúrese de que la replicación de la base de datos de CUCM funcione. El estado de replicación del clúster debe ser 2 para todos los nodos.
admin:utils dbreplication runtimestate
<output omitted for brevity>
Cluster Detailed View from cucm105pub (2 Servers):
PING DB/RPC/ REPL. Replication REPLICATION SETUP
SERVER-NAME IP ADDRESS (msec) DbMon? QUEUE Group ID (RTMT) & Details
----------- ---------- ------ ------- ----- ----------- ------------------
cucm105pub 10.48.53.190 0.027 Y/Y/Y 0 (g_2) (2) Setup Completed
cucm105sub1 10.48.53.191 0.292 Y/Y/Y 0 (g_3) (2) Setup Completed
Paso 5. Copia de seguridad.
Ejecute la copia de seguridad del sistema de recuperación ante desastres (DRS) de Cisco de la configuración actual.
Cambie la dirección IP (o nombre de host) de la dirección IP al formato FQDN en la página web Administración de Cisco Unified CM.
Paso 1. Navegue hasta System > Server y cambie el campo Host Name/IP Address de la dirección IP a FQDN.
El nombre de host se puede obtener de show status y el dominio se puede obtener de la salida del comando show network eth0.
Paso 2. Repita el paso 1 para todos los servidores CUCM enumerados.
Paso 3. Para actualizar los archivos de configuración, reinicie el servicio Cisco TFTP en todos los nodos CUCM.
Paso 4. Para enviar archivos de configuración actualizados a los dispositivos registrados, reinicie el servicio Cisco Callmanager en todos los nodos CUCM.
Asegúrese de que todos los terminales se hayan registrado correctamente con los nodos CUCM.
Esto se puede lograr con la ayuda de la herramienta de supervisión en tiempo real (RTMT).
En caso de que exista una integración con otros servidores a través de los protocolos SIP, SCCP y MGCP, es posible que se requiera alguna configuración en los servidores de terceros.
Asegúrese de que el cambio se propague correctamente a todos los nodos del clúster de CUCM y que el resultado sea el mismo en todos los nodos.
Ejecute este comando en todos los nodos.
admin:run sql select name,nodeid from processnode
name nodeid
======================== ======
EnterpriseWideData 1
cucm105pub.mydomain.com 2
cucm105sub1.mydomain.com 3
imp105.mydomain.com 7