Catalyst Center에서 WLC 9800의 No Assurance 데이터 트러블슈팅

소개

이 문서에서는 Catalyst Center에서 Catalyst 9800 Series WLC에 대한 보증 데이터를 표시하지 않는 경우의 트러블슈팅 방법을 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• Catalyst Center maglev CLI 사용
• 기본 Linux 기반
• Catalyst Center 및 Catalyst 9800 플랫폼의 인증서 지식

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

• Catalyst Center 어플라이언스 2세대 및 3세대 버전 2.3.7.7 이상
• Catalyst 9800 Series WLC(Wireless LAN Controller)

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

참고: 이 문서는 2.3.7.9를 기반으로 작성되었지만 이 기능은 3.1.X 릴리스에도 있습니다.

참고: Catalyst 9800 WLC는 Catalyst Center에서 이미 검색하여 사이트에 할당해야 하며, 호환되는 Cisco IOS® XE 버전을 실행해야 합니다. 상호 운용성에 대한 자세한 내용은 Catalyst Center 호환성 매트릭스를 참조하십시오.

배경 정보

사이트 할당 시 Catalyst Center는 SNMP 및 Syslog 구성 위에 있는 9800에 텔레메트리 구성을 푸시합니다.

참고: 이 예는 Catalyst 9800-CL Cloud Wireless LAN Controller에서 가져온 것입니다. 물리적 Catalyst 9800 Series 어플라이언스를 사용하는 경우 몇 가지 세부 사항이 다를 수 있습니다. X.X.X.X는 Catalyst Center 엔터프라이즈 인터페이스의 VIP(Virtual IP) 주소이고 Y.Y.Y.Y는 WLC의 관리 IP 주소입니다.

crypto pki trustpoint sdn-network-infra-iwan
 enrollment pkcs12
 revocation-check crl
 rsakeypair sdn-network-infra-iwan

crypto pki trustpoint DNAC-CA
 enrollment mode ra
 enrollment terminal
 usage ssl-client
 revocation-check crl none
 source interface GigabitEthernet1

crypto pki certificate chain sdn-network-infra-iwan
 certificate 14CFB79EFB61506E
  3082037D 30820265 A0030201 02020814 CFB79EFB 61506E30 0D06092A 864886F7 
  <snip>
        quit

 certificate ca 7C773F9320DC6166
  30820323 3082020B A0030201 0202087C 773F9320 DC616630 0D06092A 864886F7 
  <snip>
        quit

crypto pki certificate chain DNAC-CA
 certificate ca 113070AFD2D12EA443A8858FF1272F2A
  30820396 3082027E A0030201 02021011 3070AFD2 D12EA443 A8858FF1 272F2A30 
  <snip>
        quit

telemetry ietf subscription 1011
 encoding encode-tdl
 filter tdl-uri /services;serviceName=ewlc/wlan_config
 source-address Y.Y.Y.Y
 stream native
 update-policy on-change
 receiver ip address X.X.X.X 25103 protocol tls-native profile sdn-network-infra-iwan

telemetry ietf subscription 1012
<snip - many different "telemetry ietf subscription" sections - which ones depends on 
Cisco IOS® version and Catalyst Center version>

network-assurance enable
network-assurance icap server port 32626
network-assurance url https://X.X.X.X
network-assurance na-certificate PROTOCOL_HTTP X.X.X.X /ca/ pem

Catalyst Center에서 WLC의 No Assurance 데이터 트러블슈팅

WLC360에서 Assurance "Troubleshoot(문제 해결) MRE(Machine Reasoning Engine) 툴 사용

WLC360 페이지로 이동합니다. 상태 옆에 파란색 텍스트 "Troubleshoot(문제 해결)"이 표시됩니다.

그것을 클릭하고 기계 추론 엔진을 실행합니다.

추론 엔진이 완료될 때까지 실행되도록 허용합니다.

"결론" 탭을 확인하여 가능한 문제가 무엇인지 확인합니다. "결론"에 문제가 없는 전체 내용이 표시되면 이 문서의 Inbound Data Verification(인바운드 데이터 확인) 섹션으로 건너뜁니다.

이 "문제 해결" 링크가 표시되지 않으면 GUI의 Tools(툴) > Network Reasoner(네트워크 추론기) 페이지에서 수동으로 실행할 수 있습니다. "Assurance Telemetry Analysis(보증 텔레메트리 분석)" 워크플로를 찾습니다.

결론: 디바이스 연결

평가 데이터 및 검증

먼저 Inventory(인벤토리) 페이지로 이동하여 WLC의 Wireless Management IP 주소를 사용하여 해당 WLC를 관리하는지 확인합니다.

9800 어플라이언스의 경우: 무선 인터페이스 요약 표시

9800-CL의 경우 show ip interfaces brief  | i GigabitEthernet2
참고: 이는 사용자가 https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/technical-reference/c9800-cl-dg.html#Introduction의 구축 설명서를 따랐다고 가정합니다.

이제 Catalyst Center의 인벤토리 페이지로 이동합니다.

이렇게 하면 Catalyst Center와 이 디바이스 간에 연결 문제가 있는지 확인합니다.

문제 해결 및 확인할 항목

IP 연결

주 메뉴에서 시스템 > 설정 페이지로 이동합니다. 그런 다음 왼쪽 배너에서 "Trust & Privacy" 섹션으로 이동하여 "IP Access Control"을 선택합니다. 대체 방법은 전역 검색을 사용하여 "IP Access Control"을 검색하는 것입니다.

여기서 설정을 통해 문제의 장치에 연결할 수 있는지 확인하십시오. 그런 다음 ICMP를 통해 최종 장치에 연결할 수 있는지 확인하십시오. 이 작업을 수행하려면 Catalyst Center의 CLI에 로그인하고 이 출력에 표시된 대로 "ping [IP_Address]" 명령을 실행합니다.

다음으로 살펴볼 항목은 Catalyst Center CLI의 "traceroute" 명령의 출력입니다.

다음으로, "ip -s link show 명령을 사용하여 Catalyst Center에 링크 문제가 없는지 확인합니다. | grep enterprise -A 4"

인터페이스 메트릭이 허용 가능한 것처럼 보일 경우, 다음 단계는 연결의 양쪽에서 패킷 캡처(PCAP)를 수행하는 것입니다. 이 설명서에서는 문제가 되는 디바이스에서 첫 번째 PCAP 세트를 수행할 것을 권장합니다. 이 예에서는 2개의 디바이스가 9800이며 VIP가 있는 Catalyst Center입니다. 가능하지 않은 경우 최대한 디바이스 가까이에서 PCAP를 실행하십시오.

패킷이 네트워크로 전송되지만 유선 인프라를 통해 전송되지 않는 경우, 비동기 라우팅, 방화벽, NAT 및 패킷을 차단하는 ACL 등의 항목에 대해 유선 네트워크를 조사하십시오. 이러한 문제가 해결되면 보증 "문제 해결"을 다시 실행하십시오.

결론: "현재 Catalyst Center에서 관리되지 않는" 디바이스

오늘 2.3.7.10을 기준으로 워크플로 출력에서 TAC에 연락하도록 지시할 수 있습니다. TAC에 연락하거나 TAC 케이스가 올바른 즉각적인 행동 방침인지 결정하기 전에 수행할 수 있는 조치가 있습니다.  먼저 Inventory(인벤토리) 페이지로 이동하여 문제의 디바이스를 찾습니다.  주 메뉴 > 프로비저닝 > 인벤토리.  다음은 잘못 구성된 SSH 비밀번호의 예입니다

이제 확인할 다음 항목은 "연결 가능성" 상태가 "연결 불가"로 표시되지 않는다는 것입니다. "Unreachable" 또는 "Unknown"으로 표시되면 TAC에 참여하기 전에 이 가이드의 "Device Connectivity or Credential Failure" 섹션으로 이동하십시오. "Ping Reachable" 또는 "Reachable"로 표시되면 Catalyst Center에서 사용하는 자격 증명에 대한 트러블슈팅으로 이동할 수 있습니다.  이렇게 하려면 그림과 같이 조사할 디바이스 왼쪽의 상자를 클릭합니다. 상자는 파란색 확인 표시와 함께 파란색으로 바뀝니다.

그런 다음 표시된 대로 "Actions(작업)", "Inventory(인벤토리)", 마지막으로 "Edit Device(디바이스 수정)"를 클릭합니다.

이 작업을 수행하면 이 컨피그레이션을 "검증"할 수 있는 새 창이 표시됩니다. 이 스크린샷의 예를 참조하십시오.  

참고: 이 페이지에서 "사용자 이름"은 일반 텍스트로 표시되지만 "비밀번호"는 표시되지 않습니다. 대신 Catalyst Center는 비밀번호를 "NO!$DATA!$"로 표시합니다.

다음은 올바른 자격 증명 모양에 대한 예입니다.  SNMP 및 잘못된 자격 증명을 참조하십시오. CLI 및 Netconf를 참조하십시오.

참고: 무선 액세스 포인트(AP)는 이러한 방식으로 관리되지 않습니다. 모든 AP 데이터는 WLC를 통해 전달됩니다.

CLI(SSH) 액세스는 모든 디바이스에 필수적입니다.

읽기 전용 액세스 이상의 SNMP는 모든 디바이스에서 필수입니다.

9800(Cisco IOS® XE 기반) WLC에는 Netconf가 필수입니다. Netconf는 Cisco IOS® XE 기반 스위치용 PoE 대시보드와 같은 추가 모니터링을 제공하므로 선택 사항입니다. Netconf는 AireOS 또는 Cisco IOS® 기반 디바이스에서 사용되지 않습니다. 

모든 문제를 수정하고 "Validate(검증)" 옵션을 다시 실행하면 다음을 확인할 수 있습니다.

오류를 해결한 후 왼쪽 하단의 "업데이트" 버튼을 클릭합니다. 이 작업이 완료되면 Catalyst Center는 이 디바이스를 "동기화"를 위해 대기시킵니다. 큐가 비어 있으면 표시된 대로 "동기화"가 즉시 시작됩니다.

이 작업을 완료한 후 다른 항목을 처리해야 하는지 확인하려면 "문제 해결" MORE 출력으로 돌아가십시오. 더 이상 문제가 발생하지 않을 경우 업데이트된 정보를 보려면 15-20분 정도 기다려 주십시오. 해당 시간 이후에 정보가 업데이트되지 않을 경우 TAC에 연락하여 추가 지원을 요청하십시오.

결론: "DNAC-CA(swim) 인증서" 문제

몇 가지 가능성이 있습니다.

• 인증서는 다른 Catalyst Center를 위한 것입니다.
• 장치의 "현재 날짜/시간"이 유효한 범위를 벗어납니다. 
• 인증서가 교체되었으며 디바이스에서 이전 인증서를 사용하고 있습니다.

MRE가 나타내는 항목을 확인하십시오. 그런 다음 9800으로 이동하여 몇 가지 명령을 실행하여 어떤 문제가 문제의 원인인지 확인할 수 있습니다. 먼저 디바이스에서 show clock 명령을 실행한 후 시간과 날짜를 확인합니다.

그런 다음 show crypto pki certificates DNAC-CA를 실행하여 DNAC-CA 인증서의 세부 정보를 가져옵니다.

먼저 "시작 날짜" 및 "종료 날짜"를 디바이스의 현재 날짜 및 시간과 비교합니다. 결론에 인증서가 일치하지 않는다고 표시되면 브라우저에서 인증서 정보를 가져옵니다. 일련 번호가 일치해야 합니다. 일치하는 인증서 일련 번호의 Chrome의 예입니다.

결론: "sdn-network-infra-iwan 인증서의 일련 번호" 문제

먼저 디바이스의 날짜가 올바른지 확인합니다

그런 다음 show crypto pki certificates sdn-network-infra-iwan을 사용하여 sdn-network-infra-iwan 인증서 세부사항을 가져옵니다.

이 경우 유효 날짜가 디바이스에서 기정한 날짜 이내인지 확인하십시오.

다음으로 Catalyst Center로 이동하여 인증서 일련 번호가 일치하는지 확인합니다.

Main Menu(기본 메뉴) > System(시스템) > Settings(설정) 페이지로 이동합니다. 해당 페이지에서 "Device Certificate" 페이지를 찾습니다. 해당 페이지에서 해당 장치로 필터링하여 "인증서 일련 번호"가 일치하는지 확인합니다.

이 값이 일치하지 않으면 디바이스가 여기에 있어야 하며 다른 Catalyst Center 클러스터에서 관리하지 않아야 하는지 확인하십시오. 장애가 최근 발생했거나 인증서가 아직 만료되지 않은 경우, TAC에 문의하여 필요한 경우 추가 근본 원인 분석을 받으십시오. 그렇지 않으면 "인벤토리" 페이지로 이동하여 녹색 확인 표시가 있는 "연결 가능" 및 "관리됨"인지 확인합니다. 이 페이지에 문제가 있는 경우 결론 섹션으로 이동하십시오. 이 가이드의 "현재 Catalyst Center에서 관리되지 않는" 장치를 사용하여 지침을 완료합니다.

모든 것이 녹색으로 완전히 관리되는 경우 강제 원격 분석 업데이트를 수행하십시오. '강제' 원격 분석 업데이트 수행 섹션을 참조하십시오.

인바운드 데이터 확인

System(시스템) > System 360(시스템 360) > Monitor(모니터링)로 이동하여 Grafana로 이동합니다. 그러면 Grafana에 대한 새 화면이 표시됩니다.

그런 다음 왼쪽 열의 돋보기를 클릭하고 Device Processor를 입력하여 Assurance - Device Processor 대시보드로 이동합니다

"Received WLC schema per 5min" 테이블에서 "Memory" 번호를 확인합니다. 이 숫자는 트래픽을 전송하는 Catalyst 9800(Cisco IOS® XE) WLC 수와 일치합니다.

'강제' 텔레메트리 업데이트 수행

Inventory(인벤토리)로 이동하여 표시된 대로 Update Telemetry Settings(텔레메트리 설정 업데이트)를 선택합니다.