이 문서에서는 SNMP(Simple Network Management Protocol) 문제 해결 시나리오에 대해 설명합니다.
Cisco에서는 다음 사항에 대해 알고 있는 것이 좋습니다.
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
Cisco Catalyst 3650 Series 스위치
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
1. 오류 메시지: "%SNMP-3-RESPONSE_DELAYED: <OID>(<elapsed-time> msecs)의 GetNext 처리"
이 예에서 ciscoMgmt.810.1.2.1.1은 지연된 GetNext 요청과 연결된 OID입니다. 근본 원인을 파악하기 전에 반복되는 메시지를 CPU 사용률, NMS 폴링 레코드, 릴리스별 결함과 연계합니다.
*May 24 01:30:48.463: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.2.1.1 (24008 msecs)
*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 컨피그레이션을 확인합니다. SNMPv2c의 경우 여러 커뮤니티가 디바이스에 추가된 경우 출력과 비슷하게 표시됩니다.
snmp-server community TAC1 RO
snmp-server community TAC2 RO -->
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 컨피그레이션에 보기를 추가합니다.
SNMPv2c의 경우
snmp-server community TAC1 RO view cutdown RO
snmp-server community TAC2 RO view cutdown RO
문제의 원인이 되는 OID를 제외하는 것이 좋습니다. 그러나 변경 사항을 적용하기 전에 제외할 수 있는 OID의 기능이 무엇인지 검토하십시오.
snmp-server view cutdown iso included
snmp-server view cutdown ciscoMgmt.810 excluded -->>>
SNMPv3의 경우 보기 제외는 snmp-server group 명령과 함께 적용됩니다.
snmp-server view TESTV3 internet included
snmp-server view TESTV3 ciscoMgmt.810 excluded
snmp-server group TestGroupV3 v3 priv write TESTV3
2. "SNMP 플래시 캐시로 인한 높은 CPU 사용률" 오류 메시지.
Device#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 서명 보류: 다중 신호는 프로세스 91로 전송됩니다. Process= "Snmp Flash Cache", 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 플래시 캐시 프로세스는 높은 CPU를 사용할 수 있습니다. show running-config all을 사용하여 구성된 상태를 확인합니다. | snmp mib 플래시 캐시를 포함하고 프로세스 CPU를 확인한 후 snmp mib 플래시 캐시를 적용하지 않습니다.
3. 오류 메시지: "%SNMP-3-INPUT_QFULL_ERR:입력 큐가 꽉 차서 패킷이 삭제되었습니다."
대기열 전체 오류의 가능한 원인은 장치 또는 문제를 일으키는 특정 OID에 대한 과도한 폴링일 수 있습니다. 이를 완화하려면 먼저 디바이스가 많이 폴링되었는지 확인합니다.
이렇게 하려면 다음 명령을 실행합니다.
Device#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 리소스를 사용한다는 것을 알 수 있습니다.
Device#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를 잠글 수 있습니다.
방법 1. show snmp stats oid 명령을 사용합니다.
show snmp stats oid 명령은 폴링된 마지막 OID를 표시합니다. 타임스탬프를 순서대로 표시합니다. 목표는 느리게 응답한 OID를 식별하는 것입니다. 이 명령은 클라이언트가 폴링하는 MIB를 더 자주 찾으려는 경우에도 유용합니다.
Device#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
snmp-server view TESTV3 iso include
snmp-server group TestGroupV3 v3 auth read TESTV3
snmp-server user <username> TestGroupV3 v3 auth sha <auth-secret> priv aes 128 <priv-secret>
참고: 조직 자격 증명 정책을 준수하는 고유한 암호를 사용합니다. 문서화된 Cisco IOS XE 릴리스에 대한 SHA 및 AES 구문 및 지원을 확인합니다.
디바이스의 컨피그레이션 모드를 시작하고 SNMP 컨피그레이션에 보기를 추가하여 변경합니다.
snmp-server community TAC1 RO view cutdown RO
snmp-server community TAC2 RO view cutdown RO
컨피그레이션 모드에서 이러한 행을 추가합니다. 문제의 원인이 되는 OID를 제외하는 것이 좋습니다. 그러나 제외하려는 OID의 기능이 무엇인지 읽어 보십시오.
snmp-server view cutdown iso included
snmp-server view cutdown <oid-subtree> excluded
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
5.0 |
17-Aug-2026
|
재인증 |
4.0 |
02-Apr-2025
|
서식이 업데이트되었습니다. |
3.0 |
28-Mar-2024
|
재인증. |
2.0 |
16-Feb-2023
|
형식이 업데이트되었습니다. 수정된 CCW 알림. 재인증. |
1.0 |
12-Jan-2022
|
최초 릴리스 |