SNMP 설정 추가 작업 중 발생한 장애 사례

[한 줄 요약]

SNMP 통신 불가 문제를 해결하기 위해 설정을 추가하던 중, 타 장비 설정을 참고하여 적용한 명령어가 특정 IOS 버전 버그를 유발하여 인터페이스 플랩이 발생했고, 원복 후 정상화된 사례

---

작업 배경

금일 GMS 서버와 네트워크 장비 간 SNMP 통신이 되지 않는 이슈가 발생하였다.

기본 설정을 확인한 결과 ACL 및 Community 설정은 존재했으나, GMS 서버와 통신하기 위한 Host 설정이 누락되어 있는 상태였다.

확인한 주요 SNMP 설정은 아래와 같았다.

ip access-list SNMP_ACL
 10 permit udp x.x.x.x/24 any

 

특정 SNMP 서버 대역의 접근을 허용하기 위한 ACL

snmp-server community Network_R use-acl SNMP_ACL

 

SNMP Community 문자열(Network_R)을 사용하고, SNMP_ACL에 정의된 장비만 접근 가능하도록 제한

snmp-server host 10.x.x.x Network_R

 

SNMP Trap 또는 Polling을 수행할 GMS 서버 지정

확인 결과 GMS 서버 관련 Host 설정이 누락되어 있었으며, 해당 설정만 추가하면 해결 가능한 상황으로 판단하였다.

---

추가 확인 사항

설정 작업 중 다른 운영 장비들의 SNMP 설정을 비교 확인하였다.

다수 장비에서 아래 설정이 추가로 적용되어 있었다.

snmp mib flash cache

 

당시에는 기존 운영 장비에도 동일하게 적용되어 있어 함께 적용하는 것이 좋다고 판단하였다.

---

장애 발생

설정 적용 후 장비에서 순간적인 통신 불안정 현상이 발생하였다.

증상은 다음과 같았다.

• 장비 응답 지연
• 통신 끊김 후 복구
• 인터페이스 플랩 발생

초기에는 SNMP Host 추가 작업과 직접적인 연관성이 없다고 생각했으나, 적용한 설정을 하나씩 검토하던 중 snmp mib flash cache 설정을 의심하게 되었다.

---

원인 분석

추가 확인 결과 해당 장비는 Cisco IOS 15.2(5r)E3 버전을 사용 중이었다.

과거 사례를 확인해보니 해당 버전에서 snmp mib flash cache 설정 적용 시 CPU 사용률이 비정상적으로 증가하는 버그 이력이 존재하였다.

결국 실제 문제는 SNMP Host 설정이 아니라, 함께 적용한 snmp mib flash cache 설정이었다.

---

조치 내용

추가한 설정 중:

snmp mib flash cache

 

를 제거하여 원복 진행

원복 후:

• 인터페이스 플랩 종료
• 통신 정상화
• CPU 이상 현상 미발생

확인

최종적으로는 GMS Host 설정만 유지하고 작업을 마무리하였다.

---

배운 점

이번 작업을 통해 단순히 운영 중인 다른 장비의 설정을 그대로 참고하는 것이 항상 정답은 아니라는 점을 다시 한번 확인할 수 있었다.

특히 네트워크 장비는 동일한 설정이라도:

• IOS 버전
• NX-OS 버전
• 하드웨어 모델

에 따라 동작 방식이 달라질 수 있다.

운영 장비에 동일한 설정이 적용되어 있다고 하더라도:

• 해당 설정의 목적은 무엇인지
• 현재 장비 버전에서 문제가 없는지
• 알려진 버그가 존재하는지

를 먼저 확인한 후 적용해야 한다.

---

정리

이번 작업의 실제 원인은 SNMP 설정 누락이 아니라, 설정 추가 과정에서 함께 적용한 snmp mib flash cache 명령이었다.

결과적으로:

• GMS SNMP 통신 불가 원인은 Host 설정 누락
• 통신 불안정 원인은 IOS 버전과 충돌하는 snmp mib flash cache

였으며,

이번 사례를 통해 설정 복사 시에는 단순히 구성만 볼 것이 아니라 장비 버전과 기능 영향도까지 함께 검토해야 한다는 점을 배울 수 있었다.