목차

소개

요구 사항

사전 요구 사항

사용되는 구성 요소

표기 규칙

가장 일반적인 오류 트러블슈팅

관련 정보

소개

이 문서에서는 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를 찾으려면  snmpwalk NMS 서버의 디바이스에 연결하고 출력을 확인합니다. 다른 OID보다 느리게 응답하는 OID는 CPU 사용률이 높은 OID일 수 있습니다.

문제 해결 방법:

디바이스에서 SNMP 컨피그레이션을 확인합니다. SNMPv2의 경우 다음과 같아야 합니다.

snmp-server community TAC1 RO

snmp-server community TAC2 RO --> If multiple communities are added to snmp.

- 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 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.

관련 정보

- SNMP

- Cisco 기술 지원 및 다운로드