포트는 정상인데 네트워크는 마비? NMS로 찾는 루핑 장애의 단서

와치텍

 

스위치 포트는 UP인데 여러 사용자가 동시에 접속 지연과 끊김을 겪는다면, 링크 상태뿐 아니라 트래픽 변화도 확인해야 합니다.

원인 중 하나는 네트워크 루핑입니다. 동일한 L2 네트워크에서 순환 경로가 차단되지 않으면 프레임이 반복 전달되면서 정상적인 통신에 영향을 줄 수 있습니다.

이번 글에서는 L2 이중화 작업 이후 발생한 장애를 예로 들어, NMS로 점검 구간과 원인 후보를 좁히고 장비 점검으로 원인을 확인하는 과정을 살펴봅니다.

이 글의 핵심
  • 포트가 UP 상태여도 브로드캐스트 트래픽이 급증하면 통신 품질이 저하될 수 있습니다.
  • NMS 이벤트와 포트 통계, 트래픽 이력과 작업 기록으로 점검 구간과 원인 후보를 좁힙니다.
  • 최종 원인은 장비 설정에서 확인하고, 조치 후 NMS 통계와 실제 서비스 상태로 복구를 검증합니다.

L2 이중화 작업 이후 시작된 통신 지연

A·B구역 스위치는 각각 상위 스위치인 CORE-SW에 연결돼 있었습니다. 담당자는 기존 업링크 장애 시 우회 경로를 확보하기 위해, 오후 2시에 A·B구역 사이의 이중화 링크를 개통했습니다.

기존 업링크가 유지된 상태에서 같은 VLAN 10을 전달하는 연결이 추가되면서 다음과 같은 경로가 만들어졌습니다.

CORE-SW → A구역 스위치 → B구역 스위치 → CORE-SW

중복 경로는 STP가 정상적으로 동작하면 일부 경로를 차단해 루핑을 방지할 수 있습니다. 그러나 이번 사례에서는 개통 직후 사용자들의 접속 지연과 끊김이 발생했고, 담당자는 NMS에서 이상 징후를 확인했습니다.

① 이벤트와 포트 통계로 점검 구간 좁히기

이벤트 현황에는 CORE-SW와 A·B구역 스위치의 Broadcast pps 임계치 초과 알림이 표시돼 있었습니다. 초당 수신되는 브로드캐스트 패킷 수는 CORE-SW 기준 125,000pps로, 설정된 임계치 100,000pps를 초과했습니다.

 

담당자는 브로드캐스트가 어느 연결 구간에서 유입되는지 확인하기 위해 CORE-SW의 인터페이스 통계를 비교했습니다.

CORE-SW 인터페이스별 수신 Broadcast pps
인터페이스연결 대상수신 Broadcast pps
Gi1/0/1A구역 스위치62,000
Gi1/0/3B구역 스위치61,000

두 포트에서 높은 수신량이 관찰됐습니다. 인터페이스 별칭과 포트 뷰로 연결 대상을 확인한 뒤, A·B구역을 우선 점검 대상으로 선정했습니다.



 

포트는 모두 UP이었지만 트래픽에서는 이상이 나타났습니다. 다만 루핑 트래픽은 여러 포트로 확산될 수 있으므로, 수치만으로 발생 지점을 확정하지 않고 이상이 시작된 시점을 추가로 확인했습니다.

② 트래픽 이력과 작업 기록으로 원인 후보 도출

장비 트래픽 항목을 펼치고 조회 범위를 13:55~14:15로 좁히자, 오후 2시 직후 전체 pps와 Broadcast pps가 함께 급증한 구간이 나타났습니다.


 

이어서 솔루션의 작업 캘린더에서 같은 시간대의 작업을 조회했습니다. ‘A·B구역 L2 경로 이중화’ 작업이 등록돼 있었고, 처리 기록에서도 14:00에 신규 링크를 개통한 사실을 확인했습니다.

 

트래픽이 집중된 구간과 작업 대상이 같았고, 증가 시점도 링크 개통 시각과 일치했습니다. 담당자는 이를 근거로 신규 이중화 연결과 루핑 방지 설정을 우선 점검할 원인 후보로 좁혔습니다.

확인된 단서
  • CORE-SW의 A·B구역 연결 포트에서 높은 브로드캐스트 수신량이 관찰됐습니다.
  • 14:00 직후 전체 pps와 Broadcast pps가 함께 급증했습니다.
  • 같은 시각, 같은 구간에서 L2 이중화 링크가 개통됐습니다.

③ 장비 설정 점검으로 원인 확인

NMS에서 확인한 구간과 작업 내용을 바탕으로 담당자가 관련 스위치의 실제 연결 및 설정을 점검했습니다. 그 결과 관련 스위치에서 VLAN 10의 STP가 비활성화돼, 이중화 링크 개통으로 형성된 순환 경로가 차단되지 않은 것을 확인했습니다.

이는 NMS가 자동으로 판별한 결과가 아니라, NMS 분석을 통해 점검 범위를 좁힌 뒤 장비 설정에서 확인한 원인입니다.

담당자는 14:20에 신규 A·B구역 연결을 우선 차단해 순환 경로를 끊었습니다. 확인한 설정 문제와 조치 시각은 솔루션의 작업 처리 이력에 기록했습니다.

④ 조치 전후 지표로 복구 확인

 

신규 링크를 차단한 뒤 NMS에서 동일한 장비와 인터페이스의 Broadcast pps를 다시 확인했습니다. 14시 이후 높게 유지되던 브로드캐스트는 14:20을 기점으로 평상시 수준으로 감소했습니다. A·B구역 연결 포트의 수신량도 안정됐으며, 사용자 접속 지연과 끊김이 해소됐습니다.

 

링크 개통 직후 증가하고 차단 이후 감소한 흐름은 장비 설정 점검 결과와 함께 원인 판단을 뒷받침했습니다. 긴급 복구 이후에는 VLAN 10의 STP 설정을 보완하고, 중복 경로가 정상적으로 차단되는지 확인하며 이중화 링크를 재개통했습니다. 이후 NMS 통계와 실제 서비스 상태를 함께 확인해 재발 여부를 점검했습니다.

원인 후보를 좁히고 복구 결과까지 검증

이번 사례에서 NMS는 이벤트로 관련 장비를 찾고, 포트 통계로 구간을 좁히며, 트래픽 이력과 작업 기록으로 점검할 변경 사항을 특정하는 데 활용됐습니다.

최종 설정 원인은 장비 점검으로 확인하고, 조치 결과는 다시 NMS 통계로 검증했습니다. 이러한 과정을 통해 여러 장비를 무작정 점검하는 대신, 근거가 있는 구간과 설정부터 확인할 수 있습니다.

복잡한 네트워크 장애, 알림 확인만으로 끝내지 마세요. 트래픽 변화부터 작업 이력, 복구 결과까지 연결하면 원인에 더 빠르게 접근할 수 있습니다.

NMS로 장애 대응의 근거를 확보하고, 더 안정적인 네트워크 운영을 시작해 보세요.

트래픽 변화부터 작업 이력, 복구 결과까지 확인하고 싶다면,
와치올 NMS 기능을 확인해보세요.

문의하기

 

목록
KR · EN