Cisco Unified Communications Manager의 NTP 문제 해결

소개

이 문서에서는 Cisco CUCM(Unified Communications Manager) 및 Cisco UC(Unified Communications) 제품의 NTP(Network Time Protocol) 문제를 해결하는 방법에 대해 설명합니다.

배경 정보

CUCM을 사용하려면 NTP를 구성해야 합니다.

• CUCM 노드의 시간이 동기화됩니다.
• 인증서 재생성과 같은 시간에 민감한 컨피그레이션 변경 전에 시간이 정확합니다.
• 데이터베이스 복제는 클러스터의 모든 노드에서 동기화됩니다.

UC 제품의 NTP 폴링 메커니즘

CUCM은 NTP Watchdog를 사용하여 시간을 NTP 서버와 동기화합니다.NTP Watchdog는 구성된 외부 NTP 서버를 주기적으로 폴링하고 시간이 3초 이상 오프셋되면 NTP를 다시 시작합니다.

NTP 데몬은 정기적으로 시간을 수정하지만, 밀리초 단위의 시간 확장입니다.NTP를 다시 시작하면 총 시간 수정을 수행하기 위해 NTP 원샷(one-shot)을 실행하고 NTP 데몬을 다시 시작하여 지속적으로 정기적으로 마이크로시정할 수 있습니다.

NTP Watchdog는 VMware에서 1분에 한 번, 물리적 시스템에서 30분마다 한 번씩 NTP를 폴링합니다.VM(Virtual Machine)의 클럭이 물리적 시스템보다 안정적이지 않으며 VMotion, 스토리지 마이그레이션 등의 VMware 기능이 시간에 부정적인 영향을 주기 때문에 VMware의 폴링 간격이 짧습니다.

VMware에서 실행되는 기본 노드는 물리적 시스템에서 실행되는 외부 NTP 서버와 동기화하여 VM의 시간 차이 또는 지연의 정도를 보상하기 위해 항상 구성해야 합니다.보조 노드는 항상 기본 노드 NTP 서버를 참조하도록 자동으로 구성되므로 클러스터 내의 모든 노드가 시간 내에 닫히는지 확인합니다.

NTP Watchdog는 VMWare VMotions 및 스토리지 마이그레이션으로 인한 총 시간 수정을 위해 NTP 데몬을 재시작하는 속도를 추적합니다.이 속도가 시간당 10회 재시작을 초과하면 NTP Watchdog는 필요한 재시작 속도가 시간당 10회 미만으로 떨어질 때까지 다시 시작을 연기합니다.VMotions 및 스토리지 마이그레이션의 통합 비율은 초과로 간주되므로 시간당 10을 초과할 수 없습니다.

이 NTP Watchdog 구현으로 인해 utils ntp 상태에 표시되는 폴링 간격을 따르지 않습니다.스니퍼 캡처를 통해 60초마다 8개의 NTP 폴링(샘플)이 발견되었습니다.이는 NTP 구현에서 NTP Watchdog를 사용하고 ntpdate가 UC 구현에서 NTP 서버를 폴링하는 방법을 사용하기 때문입니다.

사용된 NTP 버전 식별

참고:CUCM 게시자는 외부 NTP 서버로 구성되며 클러스터에 추가된 가입자는 게시자와 동기화됩니다.

참고:CUCM 버전 9.x 이상에서는 NTPv4 서버를 기본 NTP 서버로 구성해야 합니다.

구성된 NTP 서버에서 사용하는 NTP 버전을 식별하려면 스니퍼 캡처를 실행합니다.

admin:utils network capture port 123

Executing command with options:
size=128         count=1000             interface=eth0
src=dest=                  port=123
ip=

16:03:03.689725 IP cucmlab.cisco.local.34063 > linux.local.ntp: NTPv4,Client, length 48

16:03:03.690174 IP linux.local.ntp > cucmlab.cisco.local.34063: NTPv3,Server, length 48

CUCM은 NTPv4 패킷을 전송하고 응답으로 NTPv3 패킷을 수신합니다.NTPv4는 NTPv3과 역호환되지만, NTP의 CUCM 구현은 다양하므로 NTP는 동기화되지 않습니다.

admin:utils ntp status

ntpd (pid 22458) is running...

remote      refid     st t when poll reach   delay   offset jitter 
=================================================================
172.28.5.9   .INIT.     2 u   45   64 377   0.374 492.965 18.189  


unsynchronised  
time server re-starting  
polling server every 64 s

이 문제를 해결하려면 Linux 기반 외부 NTP 서버 또는 Cisco IOS® 또는 IOS ^XE 기반 NTP 서버를 사용하고 NTPv4가 구성되었는지 확인하는 것이 좋습니다.

다음은 NTP 상태 출력의 NTP 용어에 대한 설명입니다.

• refid 열은 원격 시간의 소스를 나타냅니다.LOCAL(0)은 로컬 하드웨어 클럭입니다..INIT. 은 초기화에 아직 성공하지 않았음을 의미합니다.
  
  
• 첫 번째 열은 원격 NTP 서버의 계층입니다.16은 "이 서버는 시간 공급자로 간주되지 않습니다"라는 잘못된 계층 값입니다. 여러 가지 이유로 인해 계층이 유효하지 않을 수 있습니다. 가장 일반적인 이유는 "시간 공급자가 동기화되지 않음", "구성된 소스가 존재하지 않음" 또는 "ntp 서버가 실행되고 있지 않음"입니다.
  
  
• t 열은 서버 유형(l:로컬;u:유니캐스트;m:멀티캐스트 또는 b:브로드캐스트).
  
  
• when 열은 원격이 쿼리된 시간(초)을 나타냅니다.
  
  
• 폴링 열은 폴링 간격(초)을 나타냅니다.예를 들어, "64"는 64초마다 원격 폴링됨을 의미합니다.NTP에서 사용하는 가장 짧은 간격은 64초이고 가장 긴 간격은 1,024초입니다.NTP 소스가 시간 경과에 따라 더 높게 평가될 수록 간격이 길어집니다.(UC 구현은 여기에 정의된 간격을 따르지 않습니다.)
  
  
• reach 열은 8진수 단위의 연결 가능성 테스트 추세를 나타냅니다. 여기서 각 숫자가 이진으로 변환될 때 특정 폴링이 성공했는지(이진 1) 또는 실패했는지(이진 0)를 나타냅니다. 예를 들어, "1"은 지금까지 하나의 설문조사만 수행되었고 성공했다는 것을 의미합니다."3" (= binary 11)은 마지막 두 개의 설문조사가 성공했음을 의미합니다."7" (= binary 111)은 마지막 세 개의 설문조사가 성공했음을 의미합니다."17"( = binary 1 111)은 마지막 4개의 설문조사가 성공했음을 의미합니다."15" (= binary 1 101)는 마지막 두 개의 설문조사가 성공했고, 그 이전의 설문조사는 성공하지 못했고, 그 이전의 여론조사는 성공했음을 의미합니다.
  
  
• 지연, 오프셋 및 지터 열은 왕복 지연, 분산 및 지터(밀리초)입니다.

CUCM에서 NTP 관련 문제 진단

NTP 관련 문제를 진단하려면 다음 단계를 완료하십시오.

1. CUCM이 포트 123의 NTP 서버와 통신할 수 있는지 확인합니다.
   
   
2. utils ntp 상태의 출력을 가져옵니다.
   
   
   • 최적의 성능을 위해서는 게시자의 계층 수준이 4보다 작아야 합니다.
   • 여러 NTP 서버가 구성된 경우 서버에 적어도 연결할 수 있는지 확인합니다.CUCM에서 참조로 사용하는 NTP 서버에 대한 (*) 기호가 표시되어야 합니다.
   
   
   
3. syslog 경보를 검토하고 그에 따라 조치를 취합니다.syslog 경보의 가능한 원인은 다음과 같습니다.
   
   
   • 외부 NTP 서버에 연결할 수 없습니다.
   • NTP stratum은 허용 가능한 제한보다 높습니다.
   • 게시자가 다운되어 구독자 NTP가 동기화되지 않았습니다.
   • ntpdate -q 관련 알림이 표시되는 경우 Kiss of Death(KoD) 기능이 활성화된 NTP 버전 4.2.6+이 있을 수 있습니다.(설계에 따라 클라이언트에서 보낸 버스트 패킷과 아이버스트 패킷 간의 최소 간격은 2이며, 이 제약 조건을 위반하지 않습니다.이 제약 조건을 위반하는 다른 구현에서 보낸 패킷은 삭제되고 KoD 패킷이 반환됨(활성화된 경우). 해당 버전을 UC 제품의 NTP 서버로 사용할 경우 이 기능을 비활성화하는 것이 좋습니다.
   
   
   
4. NTP 서버가 구성되어 있는지 확인하려면 이 진단 모듈을 사용합니다.
   • utils 진단 모듈 ntp_reachability
   • utils 진단 모듈 ntp_clock_drift
   • utils 진단 모듈 ntp_stratial
   
   
   
5. NTP 클라이언트/서버를 재시작하려면 utils ntp restart를 입력합니다.이 명령은 전체 시간을 즉시 수정해야 하거나 외부 서버가 여전히 연결 가능하고 작동하지만 동기화가 실패할 때마다 유용합니다.외부 NTP 서버의 작동 상태를 확인하려면 utils ntp status 명령을 사용합니다.

CUCM에서 NTP 연계를 통한 일반적인 알려진 문제

Cisco 버그 ID CSCue18813:CLI를 통해 제어되는 NTP 구성 "tos maxdist" 매개변수

해결:ntp.conf 파일에서 tos maxdist 매개 변수를 수동으로 추가하려면 Cisco Technical Assistance Center 사례를 제기해야 합니다.

Cisco 버그 ID CSCuq70611:NTP Stratum 테스트가 단일 NTP 서버에서 제대로 검증되지 않음

고정 버전:10.5(2.10000.005)

Cisco 버그 ID CSCui85967:NTP 참조가 누락되어 CUCM 점프 6.1.5에서 9.1.2으로 업그레이드 실패

해결:Jump 업그레이드 설명서가 업데이트되었으며 NTP 컨피그레이션이 업그레이드 전 작업의 일부로 나열됩니다.

Cisco 버그 ID CSCtw46611: capture.txt의 잘못된 파일 시스템 레이블로 인해 NTP 동기화 실패

고정 버전:8.6(2.24900.017)

Cisco 버그 ID CSCur94973: M1 마이그레이션 중 VMHost 및 VM 인스턴스 간 시간 동기화 문제

해결 방법: 이 해결 방법을 사용하여 VM의 NTP 동기화를 ESXi 호스트와 비활성화합니다.다른 해결 방법은 ESXi 서버 및 CUCM 게시자가 동일한 NTP 서버를 가리키도록 구성하는 것입니다.