O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve um procedimento para alterar a definição do cluster do Cisco Unified Communications Manager (CUCM) do formato de endereço IP ou nome de host para um formato de Nome de domínio totalmente qualificado (FQDN).
O CUCM tem uma opção para escolher se deseja usar endereços IP ou o Domain Name Service (DNS) para se comunicar entre nós e com endpoints.
Para os sistemas anteriores à 10.x, a recomendação não era usar a dependência de DNS, a menos que isso fosse exigido por um projeto ou requisitos específicos.
A partir do CUCM 10.x devido à forte integração entre o CUCM e o Cisco Unified Communications Manager IM & Presence Service (IM&P) que a recomendação mudou. Embora a não utilização de DNS em implantações básicas de telefonia IP ainda seja aceitável, o uso de nomes de domínio totalmente qualificados em vez de endereços IP tornou-se um requisito para que alguns recursos importantes funcionem:
Para configurar uma conexão segura, um cliente precisa verificar a identidade do servidor que apresenta o certificado.
O cliente executa a validação em duas etapas:
A identidade do servidor no certificado é derivada do atributo de nome comum (CN) ou do nome alternativo do assunto (SAN) do certificado recebido.
Note: A SAN, se presente, tem precedência sobre a CN.
A identidade do servidor na configuração local é derivada do arquivo de configuração do dispositivo baixado via TFTP (Trivial File Transfer Protocol) e/ou das interações UDS (User Data Services). Os serviços TFTP e UDS derivam essa configuração da tabela processnode do banco de dados. Ele pode ser configurado na página da Web do CM Administration > System > Server.
Não confunda a página CM Administration > System > Server, na qual os servidores estão sendo definidos, com OS Administration > Settings > IP Ethernet, na qual os parâmetros de rede dos servidores estão sendo configurados. Os parâmetros na página Administração do SO afetam a configuração real da rede do servidor; a alteração de nome de host ou domínio leva à regeneração de todos os certificados para o nó. As configurações na página Administração do CM definem como o CUCM se anuncia aos endpoints por meio de arquivos de configuração ou UDS. A alteração dessa configuração não exige a regeneração de certificados. Essa configuração deve corresponder a um dos seguintes parâmetros de rede do nó: Endereço IP, nome do host ou FQDN.
Por exemplo, seu endpoint se conecta com segurança ao server.mydomain.com. Ele examina o certificado recebido e verifica se "server.mydomail.com" está presente neste certificado como CN ou SAN. Se a verificação não for bem-sucedida, a conexão falhará ou um usuário final receberá uma mensagem pop-up solicitando a aceitação de certificado não confiável, dependendo da funcionalidade do cliente. Como CNs e SANs em certificados geralmente têm formato FQDN, é necessário alterar a definição do servidor de endereço IP para formato FQDN, se você quiser evitar essas falhas de pop-ups ou de conexão.
As informações neste documento são baseadas nestas versões de software e 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 da configuração, é altamente recomendável garantir que os pré-requisitos sejam atendidos.
Etapa 1. Verifique a configuração DNS.
Execute esses comandos na CLI do CUCM para garantir que o serviço DNS esteja configurado e que as entradas de FQDN para nomes de nó possam ser resolvidas local e 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:
Etapa 2. Teste de diagnóstico de rede.
Certifique-se de que o teste de diagnóstico de rede seja passado executando 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
Etapa 3. Configuração de DHCP para endpoints.
Verifique se a configuração do Dynamic Host Configuration Protocol (DHCP) necessária foi adicionada para que os telefones registrados possam fazer a resolução de DNS.
Etapa 4. Replicação de banco de dados.
Verifique se a replicação do banco de dados CUCM está funcionando. O estado de replicação do cluster tem de ser 2 para todos os nós.
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
Etapa 5. Backup.
Execute o backup do Cisco Disaster Recovery System (DRS) da configuração atual.
Altere o endereço IP (ou nome do host) do endereço IP para o formato FQDN na página da Web do Cisco Unified CM Administration.
Etapa 1. Navegue até System > Server e altere o campo Host Name/IP Address (Nome do host/Endereço IP) do endereço IP para FQDN.
O nome de host pode ser obtido do show status e o domínio pode ser obtido da saída do comando show network eth0.
Etapa 2. Repita a etapa 1 para todos os servidores CUCM listados.
Etapa 3. Para atualizar os arquivos de configuração, reinicie o serviço Cisco TFTP em todos os nós CUCM.
Etapa 4. Para enviar arquivos de configuração atualizados para os dispositivos registrados, reinicie o serviço Cisco Callmanager em todos os nós do CUCM.
Certifique-se de que todos os endpoints foram registrados com êxito nos nós CUCM.
Isso pode ser feito com a ajuda da Real-Time Monitoring Tool (RTMT).
Caso haja uma integração com outros servidores através dos protocolos SIP, SCCP e MGCP - alguma configuração pode ser necessária nos servidores de terceiros.
Verifique se a alteração foi propagada com êxito para todos os nós no cluster do CUCM e se a saída é a mesma em todos os nós.
Execute esse comando em todos os nós.
admin:run sql select name,nodeid from processnode
name nodeid
======================== ======
EnterpriseWideData 1
cucm105pub.mydomain.com 2
cucm105sub1.mydomain.com 3
imp105.mydomain.com 7