소개
이 문서에서는 Cisco Unified Communications(UC) 제품의 NTP(Network Time Protocol) 문제를 해결하는 방법에 대해 설명합니다.
사전 요구 사항
요구 사항
이 문서에 대한 특정 요건이 없습니다.
사용되는 구성 요소
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
배경 정보
CUCM(Cisco Unified Communications Manager)에서 다음을 보장하려면 NTP를 구성해야 합니다.
- CUCM 노드의 시간이 동기화됩니다.
- 인증서 재생성과 같이 시간에 민감한 컨피그레이션을 변경하기 전에 시간이 정확합니다.
- 데이터베이스 복제는 클러스터의 모든 노드에서 동기화됩니다.
UC 제품의 NTP 폴링 메커니즘
CUCM은 NTP 서버와 동기화된 시간을 유지하기 위해 NTP watchdog를 사용합니다. NTP Watchdog는 구성된 외부 NTP 서버를 정기적으로 폴링하고 시간이 3초 이상 오프셋된 경우 NTP를 재시작합니다.
NTP 데몬은 시간을 밀리초 단위로 정기적으로 수정합니다. NTP를 다시 시작하려면 NTP 원샷을 실행하여 총 시간 수정을 수행하고 NTP 데몬을 다시 시작한 다음 계속적인 일반 미세 수정을 수행해야 합니다.
NTP Watchdog는 VMware에서 1분에 한 번, 물리적 시스템에서 30분에 한 번씩 NTP를 폴링합니다. VMware의 폴링 간격이 더 짧습니다. VM(가상 머신)의 클럭이 물리적 시스템보다 안정적이지 않고 VMotion 및 Storage Migration과 같은 VMware 기능이 시간에 부정적인 영향을 주기 때문입니다.
VMware에서 실행되는 기본 노드는 물리적 시스템에서 실행되는 외부 NTP 서버와 동기화하여 VM의 시간 편류 또는 지연을 더 높게 보정하려면 항상 구성해야 합니다. 보조 노드는 항상 기본 노드 NTP 서버를 참조하도록 자동으로 구성되어 클러스터 내의 모든 노드가 제시간에 닫히도록 합니다.
NTP Watchdog는 VMWare VMotion 및 Storage Migrations로 인한 총 시간 수정 때문에 NTP 데몬을 다시 시작하는 속도를 추적합니다. 이 속도가 시간당 재시작 10을 초과하면 NTP Watchdog는 필요한 재시작 속도가 시간당 10 미만이 될 때까지 재시작을 더 연기합니다. VMotion과 Storage Migration의 통합 비율은 시간당 10을 초과할 수 없습니다. 이 비율은 과도한 것으로 간주되기 때문입니다.
이러한 NTP Watchdog 구현으로 인해 폴링 간격을 따르지 않습니다. 이는 utils ntp 상태에 표시됩니다. 스니퍼 캡처는 60초마다 8개의 NTP 폴링(샘플)을 나타냈습니다. 이는 주로 NTP 구현에서 NTP Watchdog를 사용하고, UC 구현에서는 ntpdate가 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® 또는 Cisco IOS® XE NTP 서버를 사용하고 NTPv4가 구성되어 있는지 확인하는 것이 좋습니다.
다음은 NTP 상태 출력의 NTP 용어에 대한 설명입니다.
- refid 열은 원격의 시간 소스를 나타냅니다. LOCAL(0)은 로컬 하드웨어 시계입니다. .INIT. 초기화가 아직 성공하지 못했음을 의미합니다.
- st 열은 원격 NTP 서버의 계층입니다. 16은 잘못된 계층 값입니다. 즉, 이 서버는 시간 공급자로 간주되지 않습니다. 그 지층은 여러 가지 이유로 무효화될 수 있다. 가장 일반적인 것은 시간 제공자가 동기화되지 않았거나, 구성된 소스가 없거나, ntp 서버가 실행되고 있지 않다는 것입니다.
- t 열은 서버 유형(l: local, u: unicast, m: multicast 또는 b: broadcast)을 나타냅니다.
- when 열은 원격 쿼리를 수행한 시간(초)을 나타냅니다.
- 폴링 열은 폴링 간격(초)을 나타냅니다. 예를 들어, 64는 64초마다 원격지가 폴링됨을 의미합니다. NTP에서 사용하는 최단 간격은 64초이고 가장 긴 간격은 1,024초입니다. NTP 소스의 등급이 시간의 경과에 따라 높을수록 해당 간격이 길어집니다. (UC 구현은 여기에 정의된 간격을 따르지 않습니다.)
- 도달 범위 열은 8진수의 도달 가능성 테스트 추세를 나타냅니다. 각 숫자는 이진수로 변환되었을 때 특정 설문 조사의 성공 여부(이진 1) 또는 실패 여부(이진 0)를 나타냅니다. 예를 들어, 1은 지금까지 단 하나의 여론조사만 실시되었으며 성공적이었다는 것을 의미합니다. 3(= 이진 11)은 마지막 두 개의 폴링이 성공했음을 의미합니다. 7(= 이진 111)은 최근 3개의 폴링이 성공했음을 의미합니다. 17( = 이진 1 1 111)은 마지막 4개의 폴링이 성공했음을 의미합니다. 15(= 바이너리 1 101)는 최근 두 개의 폴링이 성공했음을 의미합니다. 그 이전의 여론조사가 성공적이지 못했고, 그 이전의 여론조사도 성공적이었다.
- delay, offset 및 jitter 열은 왕복 지연, 분산 및 지터(밀리초)입니다.
CUCM에서 NTP 관련 문제 진단
NTP 관련 문제를 진단하려면 다음 단계를 완료하십시오.
- CUCM이 포트 123의 NTP 서버와 통신할 수 있는지 확인합니다.
- utils ntp status의 출력을 가져옵니다.
- 최적의 성능을 위해 게시자의 계층 수준은 4보다 작을 수 있습니다.
- 여러 NTP 서버가 구성된 경우 하나 이상의 서버에 연결할 수 있는지 확인합니다. CUCM에서 참조로 사용하는 NTP 서버에 대해 (*) 기호를 볼 수 있습니다.
- syslog 경보를 검토하고 그에 따라 작업을 수행합니다. syslog 경보의 가능한 원인은 다음과 같습니다.
- 외부 NTP 서버에 연결할 수 없습니다.
- NTP 계층이 허용 한계보다 높습니다.
- 게시자가 다운되어 가입자 NTP가 동기화되지 않습니다.
- ntpdate -q 관련 경고가 표시되면 KoD(Kiss of Death) 기능이 활성화된 NTP 버전 4.2.6+가 있는 것일 수 있습니다. (모든 클라이언트에서 전송되는 버스트 패킷과 버스트 패킷의 최소 간격은 2이며, 이 제한을 위반하지 않습니다. 이 제한을 위반하는 다른 구현이 전송한 패킷은 삭제할 수 있으며 활성화된 경우 KoD 패킷이 반환될 수 있습니다.) 해당 버전을 UC 제품의 NTP 서버로 사용할 때는 이 기능을 비활성화하는 것이 좋습니다.
- NTP 서버가 구성되어 있는지 확인하려면 이 진단 모듈을 사용합니다.
- utils 진단 모듈 ntp_reachability
- utils 진단 모듈 ntp_clock_drift
- utils 진단 모듈 ntp_stratum
- 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 계층 테스트에서 단일 NTP 서버가 올바르게 검증되지 않습니다.
고정 버전: 10.5(2.10000.005)
Cisco 버그 ID CSCui85967: NTP 참조 누락으로 인해 6.1.5에서 9.1.2로의 CUCM 점프 업그레이드가 실패함
해결 방법: Jump 업그레이드 문서가 업데이트되었으며 NTP 컨피그레이션이 업그레이드 전 작업의 일부로 나열됩니다.
Cisco 버그 ID CSCtw46611: capture.txt의 잘못된 파일 시스템 레이블링으로 인해 NTP 동기화가 실패함
고정 버전: 8.6(2.24900.017)
Cisco 버그 ID CSCur94973: M1 마이그레이션 중 시간 동기화 문제가 VMHost 및 VM 인스턴스에서 발생함
해결 방법: 이 해결 방법을 사용하여 ESXi 호스트와의 VM NTP 동기화를 비활성화합니다. 또 다른 해결 방법은 ESXi 서버와 CUCM 게시자가 동일한 NTP 서버를 가리키도록 구성하는 것입니다.
피드백