소개
이 문서에서는 SNMP(Simple Network Management Protocol) 및 디바이스에서 SNMP 기능을 테스트하는 방법에 대해 설명합니다.
요구 사항
사전 요구 사항
SNMP 프로토콜 및 NMS(Network Management System) 서버와의 통신에 대해 알고 있는 것이 좋습니다.
사용되는 구성 요소
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
-
SNMP
-
Cisco WS-C3650-12X48UZ
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
표기 규칙
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.
가장 일반적인 오류 트러블슈팅
1. 오류 메시지: "%SNMP-3-RESPONSE_DELAYED: "Any OID"의 GetNext를 처리하는 중입니다."
GetNext of ciscoMgmt.810.1.2.1.1 (24004 msecs)
*May 24 01:30:48.463: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.2.1.1 (24008 msecs)
---> In this scenario ciscoMgmt.810.1.2.1.1 is the OID causes the issue.
*May 24 01:31:12.477: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.2.1.1 (24012 msecs)
*May 24 01:31:36.486: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.2.1.1 (24008 msecs)
*May 24 01:32:00.503: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.3.1.1 (24016 msecs)
*May 24 01:32:24.515: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.3.1.1 (24012 msecs)
*May 24 01:32:48.528: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.3.1.1 (24012 msecs)
*May 24 01:33:12.537: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.3.1.1 (24008 msecs)
문제를 해결하려면 다음을 수행합니다.
디바이스에서 SNMP 컨피그레이션을 확인합니다. SNMPv2의 경우 다음과 같이 표시되어야 합니다.
snmp-server community TAC1 RO
snmp-server community TAC2 RO --> If multiple communities are added to device.
SNMPv3의 경우
snmp-server view TESTV3 iso include
#snmp-server group TestGroupV3 v3 auth read TESTV3
#snmp-server user cisco TestGroupV3 v3 auth md5 ciscorules priv des56 cisco123
디바이스의 컨피그레이션 모드를 시작하고 SNMP 컨피그레이션에 보기를 추가하여 변경합니다.
SNMPv2의 경우
snmp-server community TAC1 RO view cutdown RO
snmp-server community TAC2 RO view cutdown RO
컨피그레이션 모드의 일부 행:
snmp-server view cutdown iso included
snmp-server view cutdown ciscoMgmt.810 excluded -->>>
The Idea is to exclude the OID causes the issue, however,
please read out what is the function of the OID that that is excluded.
SNMPv3의 경우
#snmp-server view TESTV3 internet included
#snmp-server view TESTV3 ciscoMgmt.810 excluded
#snmp-server group TestGroupV3 v3 priv write TESTV3
2. "SNMP 플래시 캐시로 인한 높은 CPU 사용률" 오류 메시지.
#show processes cpu sorted
CPU utilization for five seconds: 99%/0%; one minute: 22%; five minutes: 18%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
447 561399 143012 3925 0.00% 1.58% 1.83% 0 Snmp Flash Cache
SNMP 로그:
%SYS-2-SIGPENDING: 프로세스 91 -Process= "Snmp 플래시 캐시", ipl= 0, pid= 91에 여러 신호가 전송됩니다.
888888888888888888888888888888888888888888888898878889
625424254283314655456532533533772205363424335694492379
100 * *
90 * * * * *** *** * * ** * * *** **
80 ******************************************************
70 ******************************************************
60 ******************************************************
50 ******************************************************
40 ######################################################
30 ######################################################
20 ######################################################
10 ######################################################
0....5....1....1....2....2....3....3....4....4....5....5....6....6....7..
해결 방법:
플래시 MIB 데이터 수집 프로세스는 기본적으로 비활성화되어 있습니다. snmp mib flash cache 명령을 사용하여(다시 로드 후) 활성화하면 경우에 따라 CPU가 높게 나타날 수 있습니다.
대신 컨피그레이션 모드에서 #no snmp mib flash cache 명령을 사용합니다.
또는 다음 EEM 스크립트를 설치합니다.
event manager applet SNMP authorization bypass
event syslog pattern "SYS-5-RESTART"
action 11 cli command "enable"
action 12 cli command "conf t"
action 13 cli command "no snmp mib flash cache"
action 14 cli command "end"
3. 오류 메시지: "%SNMP-3-INPUT_QFULL_ERR:입력 큐가 꽉 차서 패킷이 삭제되었습니다."
대기열 전체 오류의 가능한 원인은 장치 또는 문제를 일으키는 특정 OID에 대한 과도한 폴링일 수 있습니다. 이를 완화하려면 먼저 디바이스가 많이 폴링되었는지 확인합니다.
이렇게 하려면 다음 명령을 실행합니다.
B02#show snmp stats oid
time-stamp #of times requested OID
15:40:19 BKK Dec 27 2019 11180008 ifAlias
15:40:19 BKK Dec 27 2019 44018183 dot1dBasePortEntry.4
15:40:19 BKK Dec 27 2019 44018212 dot1dBasePortEntry.3
15:40:19 BKK Dec 27 2019 45216156 ipNetToPhysicalEntry.4
15:40:19 BKK Dec 27 2019 44018059 dot1dBasePortEntry.5
15:40:19 BKK Dec 27 2019 44578303 dot1dBasePortEntry.1
15:40:19 BKK Dec 27 2019 6011756 dot3StatsEntry.19
15:40:19 BKK Dec 27 2019 11095925 ifSpeed
15:40:19 BKK Dec 27 2019 12879927 dot1dTpFdbEntry.3
15:40:19 BKK Dec 27 2019 84535 vmMembershipSummaryEntry.2
15:40:19 BKK Dec 27 2019 3241107 vmMembershipSummaryEntry.3
15:40:19 BKK Dec 27 2019 45208908 ipNetToMediaEntry.2
15:40:19 BKK Dec 27 2019 45223410 ipNetToPhysicalEntry.6
15:40:19 BKK Dec 27 2019 44018324 dot1dBasePortEntry.2
문제를 해결하려면 다음을 수행합니다.
NMS의 설정을 변경하고 디바이스의 폴링 간격을 줄여야 합니다. 폴링 간격이 줄어들면 대기열 전체 오류를 완화해야 합니다. 그렇지 않은 경우 문제의 원인이 되는 OID를 확인해야 합니다. 문제의 원인이 되는 OID를 찾고 문제를 해결하려면 앞서 언급한 오류 메시지 1을 참조하십시오.
4. 오류 메시지: "SNMP 엔진으로 인해 CPU 사용률이 높음"
문제 파악:
라우터는 클라이언트에 의해 폴링될 때 높은 CPU가 발생하고, 이는 높은 CPU가 발생할 때 #show process cpu <sorted> 명령을 사용하여 확인할 수 있습니다. SNMP 엔진 프로세스가 모든 CPU 리소스를 사용한다는 것을 볼 수 있습니다.
#show processes cpu sorted
CPU utilization for five seconds: 99%/0%; one minute: 22%; five minutes: 18%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
189 1535478456 697105815 2202 88.15% 13.40% 8.74% 0 SNMP ENGINE
문제가 있는 OID로 인해 높은 CPU가 다른 OID보다 느려지며, 클라이언트가 이 OID를 요청할 때 약간의 시간 초과가 발생할 수 있습니다. 대부분의 방법은 더 느린 답을 제공하는 OID를 찾으려고 시도합니다. 이는 CPU가 높아질 가능성이 가장 높기 때문입니다. OID가 식별되면 오류를 완화하기 위해 해당 OID를 잠글 수 있습니다.
참고: 여기에 나열된 방법 중 문제의 원인이 되는 OID를 식별하는 데 도움이 되는 방법이 없으면 TAC에서 케이스를 여십시오.
방법 1. show snmp stats oid 명령을 사용합니다.
show snmp stats oid 명령은 폴링된 마지막 OID를 표시합니다. 타임스탬프를 순서대로 표시합니다. 목표는 느리게 응답한 OID를 식별하는 것입니다. 이 명령은 클라이언트가 폴링하는 MIB를 더 자주 찾으려는 경우에도 유용합니다.
#show snmp stats oid
time-stamp #of times requested OI
14:34:38 CET Oct 25 2020 24 atEntry.2
14:34:29 CET Oct 25 2020 40 atEntry.1
14:34:11 CET Oct 25 2020 11 ifOutErrors
14:34:07 CET Oct 25 2020 10 ifOutDiscards
14:34:06 CET Oct 25 2020 10 ifOutUcastPkts
14:34:06 CET Oct 25 2020 10 ifOutOctets
14:34:05 CET Oct 25 2020 10 ifInUnknownProtos
Entry.1을 계산하는 데 18초가 걸렸다는 것을 알 수 있습니다. 이는 CPU가 이 데이터를 계산하기 위해 통화 중이었음을 나타냅니다.
방법 2. SNMP 클라이언트를 확인합니다.
디바이스에서 높은 CPU 사용량을 담당하는 OID를 찾기 위해 NMS 서버에서 디바이스 snmpwalk 로 연결을 시작하고 출력을 관찰할 수 있습니다. 다른 OID보다 느리게 응답하는 OID는 CPU 사용률이 높은 OID일 수 있습니다.
문제를 해결하려면 다음을 수행합니다.
디바이스에서 SNMP 컨피그레이션을 확인합니다. SNMPv2의 경우 다음과 같아야 합니다.
snmp-server community TAC1 RO
snmp-server community TAC2 RO --> If multiple communities are added to snmp.
snmp-server view TESTV3 iso include
#snmp-server group TestGroupV3 v3 auth read TESTV3
#snmp-server user cisco TestGroupV3 v3 auth md5 ciscorules priv des56 cisco123
디바이스의 컨피그레이션 모드를 시작하고 SNMP 컨피그레이션에 보기를 추가하여 변경합니다.
snmp-server community TAC1 RO view cutdown RO
snmp-server community TAC2 RO view cutdown RO
컨피그레이션 모드에서 다음 행을 추가합니다.
snmp-server view cutdown iso included
snmp-server view cutdown OID _causes_the issue_is _to_excluded excluded
-->>> The Idea is to exclude the OID causes the issue, however,
please read out what is the function of the OID that we are about to exclude.
관련 정보
피드백