권장 CNR 설정 및 관리

다운로드 옵션

PDF (179.5 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (86.0 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (78.6 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2005년 10월 26일

문서 ID:13390

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 기사는 두 가지 목적이 있다.먼저 최적의 성능과 안정성을 위해 Cisco CNR(Network Registrar)을 구성하는 방법과 CNR 설치를 모니터링하는 방법에 대한 권장 사항이 포함되어 있습니다.둘째, 문제가 발생할 경우 어떻게 대처해야 하는지에 대한 권장 사항이 포함되어 있습니다.이상적인 경우에는 이 문서를 읽고 문제가 발생하기 전에 컨피그레이션 및 모니터링 권장 사항에 대해 조치를 취합니다.그렇게 함으로써 문제를 피할 수 있습니다.CNR에 문제가 있어 이 문서를 처음 읽는 경우 즉시 문제 발생 시 즉시 조치 섹션으로 이동합니다.권장 사항에 대한 자세한 내용은 CNR 사용자 가이드 및 명령 참조를 참조하십시오.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.

표준 구성

여기에서 제공되는 컨피그레이션 권장 사항은 시작점을 나타냅니다.시스템이 이와 다르게 구성된 경우 설정을 검토합니다.컨피그레이션이 이전 버전의 CNR에서 개발되었을 수 있습니다.CNR 5.0 이상 버전은 이전 버전에 비해 훨씬 향상된 성능을 제공하지만, 최대 이점을 얻으려면 매개 변수를 변경해야 합니다.이 문서에서는 대규모 통신 사업자 환경에 중점을 두고 있지만, 많은 권장 사항이 다른 CNR 환경에도 적용됩니다.이 문서에서는 다음을 가정합니다.

가입자가 10,000명 이상인 광대역 네트워크를 실행하는 서비스 제공자입니다.
CNR 5.0.3 이상을 사용하고 있습니다.
LDAP(Lightweight Directory Access Protocol)를 사용하고 있습니다.CNR은 LDAP 없이 실행되지만, 많은 통신 사업자가 LDAP를 사용합니다.
네트워크에 중간 IP 주소가 포화 상태입니다.
UNIX 서버에서 CNR을 실행합니다.대부분의 권장 사항은 Windows NT에 동일하게 적용되지만 대부분의 통신 사업자는 UNIX 서버에서 CNR을 실행하므로 UNIX와 NT가 다른 경우 UNIX 예가 사용됩니다.
다른 서버에서 실행 중인 다른 시스템(예: 청구, 고객 관리 또는 프로비저닝)에 업스트림 연결이 있습니다.
사이트에서 DDNS(Dynamic Domain Name System)가 활성화되어 있지 않습니다(대부분의 통신 사업자는 DDNS를 사용하지 않음).

구성 및 설정에 대한 권장 사항

초기 계획 및 설정

IP 주소 할당을 계획하고 문서화합니다.
별도의 디스크 집약적 작업:기본 DHCP 서버를 LDAP 서버 및 기본 DNS 서버와 다른 시스템에 배치합니다.
CMTS(Cable Modem Termination System) 컨피그레이션을 문서화합니다.CMTS 및 CNR 컨피그레이션이 일치하는지 확인합니다.
재해 복구 계획 준비
네트워크 토폴로지를 문서화합니다.
Cisco IOS® Software 버전의 CMTS에 주목하십시오.

네트워크의 장기 상태를 유지하기 위한 가장 효과적인 단계는 다음과 같습니다.a) 구성을 계획하고, b) 계획을 기록하고, c) 변경 사항을 기록합니다.선택 사유를 문서화하면 향후 계획 세션 중에 도움이 될 수 있습니다.

일반 시스템 구성

안전 장애 조치를 사용합니다.한 서버가 모든 범위의 주 서버이고 다른 서버는 모든 범위에 대해 백업되는 단순 장애 조치(대칭적 장애 조치와 대조적으로, 두 서버가 각각 개별 범위에 따라 주 서버이고 동시에 백업되는 경우)는 관리 작업을 크게 간소화하므로 매우 좋습니다.

SNMP(Simple Network Management Protocol) 트랩을 설정합니다.다음 예제는 다음과 같습니다.

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

적절한 RAM(512MB 이상)이 있는지 확인합니다.
데이터 파티션이 충분히 커야 합니다(2.5GB 이상).
로그 및 데이터에 별도의 파티션을 사용합니다.
서버 간 고속, 저지연 연결 보장인터페이스 설정을 확인합니다.

SNMP 트랩을 사용하면 네트워크 모니터에서 DHCP 서버를 모니터링할 수 있습니다.DHCP 서버에 트랩을 구성하고, 모니터를 수신 및 표시하도록 모니터를 구성하며, 모니터에 주의를 기울여야 합니다.

생산 시스템을 구성하려면 시스템 효율성과 비교하여 비용을 상쇄해야 합니다.장애 조치를 실행하는 E250 클래스 시스템에서 약 100,000명의 가입자를 가정할 때 이 값을 사용하는 것이 좋습니다.많은 정책, 클라이언트 클래스, 범위, 요청 및 응답 버퍼, DHCP 확장 및 기타 복잡한 문제를 사용하면 메모리 요구 사항과 성능에 영향을 줍니다.

로그 수와 크기가 증가하면 로그 파티션(/var/nwreg2)을 늘려야 합니다.

DHCP 구성

최적의 처리량을 위해 요청 및 응답 버퍼를 설정합니다.이러한 권장 사항은 CNR 5.0에 대해 변경되었습니다.
```
nrcmd> DHCP set max-dhcp-requests=500
nrcmd> DHCP set max-dhcp-responses=2000
```
케이블 모뎀 리스 시간 = 604800(7일) 이상
CPE(Customer Premises Equipment) 리스 시간:가능한 한 길게(트레이드오프는 참고 참조).

DHCP 및 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

문제를 식별할 수 있는 충분한 세부 정보를 제공하지만 과도한 세부 정보를 생성하지 않도록 로그 설정을 구성합니다. 따라서 문제를 구분하기가 어렵고 서버에 불필요한 부하가 발생합니다. 일반적으로 적용되는 권장 설정입니다.네트워크의 문제를 처리하기 위해 필요한 경우 설정을 조정합니다.
- 활동 요약
- 기본값
- 장애 조치 없는 활동
- Defer-lease-extensions 사용
- last-transaction-time-granularity 설정 = 1/2 임대 간격
- 프로덕션 임대를 제공하는 정책에 대해 allow-client-lease-override를 비활성화합니다.
- Fall-back-to-local(로컬 폴백) 활성화,LDAP를 사용할 수 없는 경우 CNR은 로컬 데이터를 사용합니다.
```
nrcmd> session set visibility=3
nrcmd> dhcp enable fallback-to-local-client-data
nrcmd> session set visibility=5
```
CNR 5.5 이상을 사용하는 경우 LDAP 쿼리를 절반으로 줄이도록 클라이언트 캐시 기능을 구성합니다.
```
nrcmd> dhcp set client-cache-count=2000
nrcmd> dhcp set client-cache-ttl=5
```

CNR의 처리량 기능을 가장 효과적으로 활용하려면 요청 버퍼보다 3~4배 많은 응답 버퍼가 있어야 합니다.시스템은 필요한 만큼의 버퍼만 사용합니다.리스 시간이 단축됨에 따라 응답 버퍼가 더 많이 필요합니다.

참고: 리스 시간은 실용적으로만 이루어져야 합니다.케이블 모뎀 임대는 개인 주소 공간(대개 10번)에서 가져오며, 모뎀은 거의 네트워크의 다른 위치로 이동하지 않습니다.이 임대 기간은 1주일 이상 되어야 합니다.반면 CPE 임대는 공용 주소 공간에서 제공되며, CPE(특히 랩톱)는 이동합니다.여기에서 임대 기간을 사용자 모집단의 습관과 일치하도록 설정해야 합니다.임대 기간이 길어지면 DHCP 서버의 부하가 줄어듭니다.짧은 임대(8시간 미만)를 사용할 경우 응답 버퍼를 2500으로 늘립니다.

클라이언트가 CNR 컨피그레이션에 지정된 임대 시간을 준수하도록 허용-클라이언트 리스 재정의 사용 안 함 - 일부 클라이언트는 지정된 설정을 재정의하려고 합니다.

LDAP 서버 장애 발생 시 네트워크가 계속 작동하도록 fall-back-to-local을 활성화합니다.이 설정을 사용하면 LDAP 서버가 응답하지 않더라도 DHCP 서버가 리스 요청을 계속 충족합니다.서버는 LDAP 서버에 저장된 특정 클라이언트 정보에 액세스할 수 없으므로 기본 설정으로 각 요청을 충족합니다.네트워크에 적합한 기본값을 구성해야 합니다.

마지막으로, 클라이언트 캐시 기능은 LDAP에서 검색한 클라이언트 데이터를 메모리에 보관하므로 DHCP 서버가 검색 제공 요청 승인 주기 동안 한 번만 LDAP를 쿼리하여 DHCP 서버 성능을 향상시킵니다.

DNS 컨피그레이션

증분 전송 기능을 활성화합니다.
```
nrcmd> dns enable ixfr-enable
```
알림을 활성화합니다.notify를 활성화하는 데 필요한 인수는 CNR CLI 명령 참조를 참조하십시오.
기본 및 보조 DNS 서버를 별도의 네트워크 세그먼트에 배치합니다.
보조 DNS 서버를 쿼리하도록 클라이언트를 구성합니다.

보조 DNS 서버는 다음 두 가지 방법 중 하나를 사용하여 기본 서버에서 데이터를 수신합니다.a) "전체 영역 전송" 또는 b) "notify/ixfr"(증분 전송) notify/ixfr를 사용하면 기본 서버에서 보조 서버로 전송해야 하는 레코드 수가 줄어듭니다.이는 이름 공간이 상대적으로 역동적인 경우 매우 중요합니다.

TFTP 컨피그레이션

initial-packet-timeout을 2로 설정합니다.
```
nrcmd> tftp set initial-packet-timeout = 2
```

CNR 5.5 이상을 사용하는 경우 TFTP 파일 캐싱을 활성화하여 성능을 향상시킵니다.

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

TFTP 파일 캐싱은 케이블 모뎀 컨피그레이션 파일을 메모리에 저장하여 케이블 모뎀이 컨피그레이션 파일을 요청할 때마다 디스크 읽기를 방지합니다.하드 드라이브(위의 예에서 CacheDir)에 파일 캐시 디렉터리를 만들어야 하며 최대 크기가 할당됩니다.시스템에 있는 RAM의 총 양과 필요한 구성 파일의 수를 고려하여 크기를 선택합니다.

TFTP 프로토콜은 클라이언트가 파일을 수신할 때 ACK(Final Acknowledgment) 패킷을 전송할 필요가 없습니다.ACK가 수신되지 않은 경우 서버는 시간 제한 기간 동안 클라이언트 연결을 보유해야 합니다. 이 경우 새 요청을 서비스하기 위한 용량을 제한합니다.TFTP 서버에 리소스 용량이 있는 경우 max-tftp-packets 값을 늘려 더 많은 수의 클라이언트 연결을 지원할 수도 있습니다.이 매개변수의 기본값은 512입니다. 최대값은 1000입니다.

CNR LDAP 컨피그레이션

이러한 설정은 CNR이 LDAP에 임대 업데이트를 쓰는 컨피그레이션을 보여줍니다.가능하면 네트워크를 설계하여 필요하지 않게 하십시오.리스 업데이트를 작성해야 하는 경우 권장 사항을 제공하기 위해 여기에 나와 있습니다.별도로 조정 가능한 읽기/쓰기 LDAP 개체를 사용하여 LDAP 연결을 최적화합니다.각 객체는 자체 스레드 그룹을 가져옵니다.

# 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

표시된 컨피그레이션에는 LDAP에 대한 CNR 쓰기 리스 업데이트가 포함됩니다.애플리케이션에서 현재 리스 정보를 LDAP에 쿼리할 수 있도록 하려면 이 작업을 수행할 수 있지만, 필요한 경우 애플리케이션 구조를 구성하지 않도록 해야 합니다.IP 주소에 대한 임대 상태에 대한 정보를 제공해야 하는 경우 NRCMD lease 명령을 사용하여 MAC 주소, 만료 및 임대의 현재 상태에 대한 기타 정보를 얻을 수 있습니다.

LDAP 디렉토리는 빠르고 효율적으로 읽도록 설계되었지만 LDAP 디렉토리에 쓰는 것은 비효율적입니다.LDAP에 리스 정보를 기록하도록 CNR을 구성하는 경우, LDAP는 전반적인 시스템 성능에 병목 현상이 됩니다.LDAP 임대 쓰기를 구성해야 하는 경우 권장 설정을 사용합니다.LDAP에 대한 CNR 액세스는 별도의 "읽기" 및 "업데이트 LDAP" 개체를 사용하여 최적화되었습니다.30초 쓰기 시간 초과도 참고하십시오.시간 초과가 짧으면 LDAP가 과부하 상태일 때 LDAP 쓰기 시간 초과가 발생할 위험이 있습니다.그런 다음 CNR에서 쓰기를 다시 시도하여 LDAP에 추가 로드를 추가합니다.

LDAP 서버에 대한 총 연결 수는 사용 가능한 최대 스레드 수를 초과할 수 없습니다.LDAP 서버가 연결당 다중 스레드를 지원하는 경우 최적의 연결 수는 연결당 스레드 수로 나눈 총 스레드 수입니다.

LDAP 서버 조정 매개변수

조회 필드에 대한 인덱스를 만듭니다.
캐시가 사용 가능한 메모리의 1/3을 초과해서는 안 되지만 메모리에 캐시된 항목 수를 늘리도록 캐시 크기를 구성합니다.
지원되는 동시 연결 수를 늘리도록 최대 스레드를 구성합니다. 단, 이는 사용 가능한 리소스의 1/2을 초과할 수 없습니다.
문제를 식별할 수 있는 충분한 세부 정보를 제공하지만 과도한 세부 정보를 생성하지 않도록 로그 설정을 구성합니다. 따라서 문제를 구분하기가 어렵고 서버에 불필요한 부하가 발생합니다.
로그 및 데이터에 별도의 파티션을 사용합니다.

특정 LDAP 서버 구현은 다릅니다.이러한 제안을 구현하려면 서버 설명서를 참조하십시오.

일상적인 절차

CNR 데이터베이스를 정기적으로 백업합니다.자세한 내용은 사용자 설명서를 참조하십시오.하루에 한 번 이상 CNR 데이터베이스를 백업해야 합니다.백업 파일을 최소 2주 동안 유지합니다.
LDAP를 정기적으로 백업합니다.
로그를 정기적으로 백업 및 아카이빙합니다.
CNR을 변경한 후 장애 조치 시나리오에서 기본 및 백업 서버의 컨피그레이션이 일관되게 유지되도록 합니다.CNR 버전 5.5 이하의 cnrFailoverConfig -compare 툴을 사용하거나 CNR 6.0 이상에서 WebUI를 사용하여 구성을 비교합니다.
네트워크 토폴로지 변경이 계획되면 DHCP 갱신 및 리스 시간을 작은 값으로 설정합니다.
IP 주소 사용 모니터링(SNMP 트랩 사용)
시스템 사용량(메모리, 디스크, CPU 및 스왑)을 모니터링합니다. 유틸리티 상단은 이 용도로 유용합니다.
로그를 주기적으로 검토하여 일반적인 사례를 숙지합니다.일반 로그를 이해하면 더 신속하게 문제를 처리할 수 있습니다.
주기적으로 예외 로그를 검토합니다."error", "warn" 또는 "connect"에 대한 grep(예: UNIX에서 grep -i warn name_dhcp_1_log 사용)

DHCP 안전 장애 조치(Safe Failover)를 수행하려면 범위에 대한 구성 설정이 해당 범위의 기본 및 백업 서버에서 동일해야 합니다.설정을 변경할 때 두 서버에서 모두 변경해야 합니다.정기적으로 CNR 6.0 이상에서 cnrFailoverConfig -compare 또는 WebUI를 사용하여 차이가 없는지 확인합니다.

네트워크 토폴로지 변경 또는 IP 주소 할당 변경 사항으로 인해 클라이언트가 다른 주소를 가져오는 데 필요할 수 있습니다.서브넷의 일부 클라이언트에 이전 범위의 주소가 있고 일부는 갱신되어 새 범위에서 주소를 얻은 기간 동안 계획해야 합니다.변경하기 전에 임대 기간을 줄여 모든 클라이언트에 단기 임대가 있도록 두 주소 세트가 모두 활성화된 시간을 줄일 수 있습니다.이렇게 하면 리스를 자주 갱신해야 하므로, 변경 후 바로 새 범위에서 리스를 받아야 합니다.서버를 중지하고 시작하여 변경을 수행하는 동안 임대가 초과될 정도로 짧은 임대 시간을 설정하지 마십시오.변경한 후에는 서버의 로드를 증가시키지 않도록 원래 임대 기간을 복원해야 합니다.

가장 효과적인 문제 해결 방법은 문제를 피하는 것입니다.위에서 설명한 권장 사항을 따르면 관리자는 작업을 계속 조정하고 심각한 문제를 방지할 수 있습니다.I/O 대기 시간이 증가하거나 알려진 이유 없이 메모리 사용량이 증가하는 등 문제가 나타나면 로그를 후속 처리합니다.물리적 환경 또는 CNR 컨피그레이션의 최근 변경 사항을 검토하여 문제의 원인이 될 수 있는지 확인합니다.

CNR 로그는 친구입니다.CNR 사용을 시작하거나 CNR을 업그레이드하거나 CNR 컨피그레이션을 변경할 때 설명된 grep 명령을 사용하여 로그에서 모든 문제를 확인합니다.그런 다음 로그를 거꾸로 작업하여 문제가 언제 어떻게 발생했는지 파악하고 문제를 해결합니다.

문제 발생 시 즉각적인 조치

Cisco 지원 직원이 요청하지 않는 한 CMTS를 재부팅하지 마십시오(케이블 환경에만 해당).
Cisco 지원 직원이 요청하지 않는 한 CNR을 다시 시작하지 마십시오.
Cisco 지원 직원이 요청하지 않는 한 안전 장애 조치를 비활성화하지 마십시오.
안전한 장애 조치 재동기화가 진행 중인 경우 어떤 식으로든 CNR을 다시 로드, 재시작 또는 중단하지 마십시오.
덮어쓰지 않을 디렉토리에 로그 파일을 복사합니다.CNR이 손상된 경우 덮어쓰지 않을 디렉토리에 코어 파일을 복사합니다.
사용:
```
nrcmd> server dhcp getRelatedServers
```
안전한 장애 조치 컨피그레이션 오류를 격리합니다.
로그에 예외가 있는지 확인합니다.특히 시작 시퀀스를 확인합니다(이전 로그에 있을 수 있음)."error", "warn" 또는 "connect"에 대한 grep(예: grep -i error name_dhcp_1_log*).

문제가 발생할 경우, 초기 문제를 격리하고 해결하는 동안 더 이상 해를 끼치지 않는 것이 중요합니다.CMTS를 재부팅하거나 CNR을 다시 시작하면 시스템이 이미 취약할 때 즉시 로드가 급증합니다.목표는 시스템이 가장 짧은 시간 내에 다시 정상적으로 작동하도록 하는 것입니다.마지막 작업이 계산될 때까지의 경과 시간첫 번째 작업에 걸리는 시간은 중요하지 않습니다.즉, 빠른 행동을 위해서만 빠른 행동을 하지 마십시오.행동하기 전에 생각해라.

시스템의 모든 단계에 대한 로그 및 모든 변경 사항을 시작합니다.DHCP, DNS 또는 TFTP 서버 및 CMTS 또는 케이블 모뎀에 대한 변경 사항문제를 설명하고 관찰이 가능한 동작만 자세히 기록합니다.

로그 파일 분석

로그(/var/nwreg2/logs)를 수집합니다. 이를 분석하여 오류 또는 경고를 찾습니다.텍스트 편집기를 사용하여 관심 오류를 더 자세히 분석합니다.오류로부터 시작하여, 오류와 관련된 MAC 주소, IP 주소 또는 도메인 이름과 관련된 모든 항목을 로그에서 다시 검색합니다.

DHCP 문제를 진단하려면 추가 로깅을 설정해야 할 수 있습니다.DHCP 서버는 광범위한 로깅 기능을 지원합니다.로깅 옵션 목록 및 각각에 대한 설명은 CNR CLI 명령 참조를 참조하십시오.각 로그 메시지가 서버에 로드되므로 주의하십시오.CNR에 로그인하여 서버 성능을 요구하는 정보의 양을 상쇄해야 합니다.

LDAP 문제 확인

LDAP 서버에 문제가 있을 수 있습니다.CNR은 LDAP 서버에 대한 요청 대기열을 작성합니다.LDAP 서버가 부하를 따라잡을 수 없는 경우 대기열이 구축됩니다./var/nwreg2/data/dhcpeventstore 디렉토리를 찾습니다.이벤트 저장소 파일의 크기가 고정되어 있으므로 큐가 빌드되는 경우 CNR에서 더 많은 파일을 만듭니다.디렉터리에 파일이 두 개 이상 있는 경우 이는 큐가 백업되고 있음을 나타냅니다.동일한 대기열은 DNS 서버에 요청을 대기시키는 데 사용되므로 큐가 백업되고 있고 DDNS를 사용하는 경우 DNS 서버에 대한 요청으로 채워질 수 있습니다.LDAP에 문제가 있는지 확인하려면 추가 CNR LDAP 인터페이스 로깅을 설정합니다.로그 플래그 ldap-create-detail, ldap-query-detail 및 ldap-update-detail을 활성화합니다.로그 메시지에는 LDAP가 시스템 병목 현상인지 확인하는 데 도움이 되는 타임스탬프가 포함됩니다.

CNR의 내부 데이터베이스 확인

하나 이상의 CNR의 내부 데이터베이스가 무결성이 손실되었다고 의심될 경우 CNR 사용 설명서를 참조하여 데이터베이스 유효성 검사 유틸리티를 실행하는 방법을 알아보십시오.이러한 유틸리티 중 하나에 문제가 있는 경우 사용자 가이드의 지침을 따라 해결합니다.

nslookup으로 DNS 데이터 확인

유틸리티 nslookup은 UNIX 시스템과 Windows NT에 모두 포함되어 있습니다.DNS 서버를 조사하는 데 사용할 수 있으므로 서버에서 저장한 데이터를 확인하는 데 유용합니다.운영 체제에 대한 설명서는 해당 기능에 대한 자세한 정보를 제공합니다.