[네트워크] 패킷 손실(Packet Loss), 스위치에서 원인 찾아보기

"팀장님, 접속이 너무 느립니다!"

IT 시스템을 운영하다 보면, '느리다'는 불평만큼 답하기 어려운 문제도 없습니다. 특히 '네트워크'가 원인일 때는 더 막막하죠. 웹사이트가 끊기거나, VoIP 통화가 버벅거리고, 게임이 뚝뚝 끊기는 현상은 대개 '패킷 손실(Packet Loss)' 때문에 발생합니다. 데이터가 목적지까지 도달하는 도중에 사라져 버리는 거죠.

패킷 손실은 눈에 보이지 않지만, 그 흔적은 네트워크 장비에 고스란히 남아있습니다. 오늘은 스위치 로그와 명령어만으로 패킷 손실의 원인을 체계적으로 찾아내보기!

---

패킷 손실, 왜 발생할까?

패킷 손실은 데이터 전송 과정에서 무언가 '방해'를 받았다는 뜻입니다. 주요 원인은 크게 세 가지로 나눌 수 있습니다.

1. 장비 및 물리적 문제: 불량 케이블, 스위치 포트 고장, 전자기기 간섭 등
2. 스위치 과부하: 너무 많은 데이터가 한꺼번에 몰려 스위치의 처리 용량을 초과했을 때
3. 설정 오류: 이중화된 경로에 스패닝 트리(Spanning Tree) 설정이 잘못되었을 때

이 원인들을 진단하기 위해 우리는 가장 먼저 스위치의 상태를 확인해야 합니다.

---

문제 진단 시작: 3단계 분석법

1단계: ping으로 패킷 손실률 확인하기

가장 기본적인 단계입니다. 문제가 발생한 PC나 서버에서 ping 명령어를 이용해 패킷 손실이 실제 발생하고 있는지 확인합니다.

# Windows
ping -n 100 <목적지 IP>
# Linux
ping -c 100 <목적지 IP>

---
# 100번의 패킷을 보냈을 때, lost가 0이면 정상입니다.
> Packets: Sent = 100, Received = 98, Lost = 2 (2% loss)

만약 Lost 패킷이 있다면, 이제부터는 스위치에서 원인을 찾아야 합니다.

2단계: show interfaces로 포트 상태 확인하기

패킷 손실이 발생할 때, 저는 가장 먼저 스위치의 포트 상태를 확인합니다. Cisco 스위치 기준으로 show interfaces 명령어가 매우 유용합니다.

# 문제가 발생한 포트의 상태를 확인합니다.
SW-01# show interfaces gigabitethernet 1/0/1

# 예시 출력
...
  Input queue: 0/75, 0/14496, 0/0 (size/max/drops); Total output drops: 124
  5 minute input rate 10000 bits/sec, 5 packets/sec
  5 minute output rate 20000 bits/sec, 15 packets/sec
     392418 packets input, 613864112 bytes
     10 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     59811 packets output, 9342111 bytes
     5 output errors, 0 collisions

여기서 주목해야 할 4가지 지표가 있습니다.

• input errors 또는 output errors: 패킷 손실의 가장 명확한 증거입니다. 값이 증가하고 있다면 케이블 불량이거나, 이중화 설정(duplex mismatch) 오류일 가능성이 높습니다.
• CRC: Checksum 에러를 나타냅니다. 주로 케이블이 불량이거나 전자기기 간섭이 심할 때 발생합니다.
• drops 또는 discards: 스위치 버퍼가 가득 차 패킷을 버렸다는 뜻입니다. 이는 스위치 포트가 과부하 상태임을 의미합니다.
• collisions: Half-duplex 통신에서 패킷 충돌이 발생했음을 의미합니다. Full-duplex 환경에서 이 값이 증가한다면 설정 오류를 의심해야 합니다.

3단계: show processes cpu로 스위치 과부하 확인하기

포트 상태에 문제가 없다면, 스위치 자체의 문제일 수 있습니다.

# 스위치의 CPU 사용량을 확인합니다.
SW-01# show processes cpu

# 예시 출력
...
CPU utilization for five seconds: 95%/90%; one minute: 85%; five minutes: 75%

만약 CPU 사용량이 80% 이상으로 지속된다면, 스위치가 몰려드는 트래픽을 처리하지 못해 패킷을 버리고 있을 수 있습니다.

문제 원인별 해결 방법

1. input errors가 많다면: 가장 먼저 케이블을 교체해 보세요. 케이블이 낡았거나 손상되었을 가능성이 높습니다.
2. drops가 많다면: 포트가 감당하기 어려운 트래픽이 몰리는 상황입니다. 스위치 업그레이드를 고려하거나, QoS(Quality of Service) 설정을 통해 중요 트래픽에 우선순위를 부여해야 합니다.
3. 높은 CPU 사용량: 이는 곧 스위치의 한계에 도달했다는 뜻입니다. 트래픽을 분산시키거나, 더 높은 사양의 스위치로 교체하는 것이 근본적인 해결책입니다.

패킷 손실은 결코 미스터리가 아닙니다. 눈에 보이지 않을 뿐, 스위치 로그에 모든 증거가 남아있죠. 오늘 알려드린 3단계 진단법을 익히고, 꾸준히 네트워크 상태를 점검하는 습관을 들이세요.