[Trouble Shooting/업무] 대외 스위치 장비 교체로 인한 회선 통신 불안정 현상 개선 경험 - traceroute

 

자정이 넘은 시각, 

 

회사에서 스위치 장비를 교체한다해서 밤에 대기를 하고 있었다.

 

WAS 서버를 다 내리고, 서비스를 하나 하나 재기동하는데, 

 

원래 기존에 통신하던 곳들이 통신이 안되는 곳들이 있었다.

 

(되는 곳 안되는 곳을 일일이 찾기 위해 telnet ip port 엄청 쳤었던 기억이...)

 

안되는 곳들에 대해서 다시 방화벽 작업을 한 이후에,

 

대부분 제대로 통신이 원활하게 됐던 것을 확인할 수 있었다..

 

 

하지만,

 

단 하나의 채널이 대량으로 패킷이나 데이터를 송신하면

 

중간에서 통신에 대한 소실이 발생했다.

 

그 채널에 대해서 telnet은 정상적으로 작동하고 있었고,

 

어느 서비스 로그를 확인해도 그 원인을 찾을 수 없었다.

 

문제는 어떤 건 되고, 어떤 건 안되고 일관되지 않은 상황이었고,

 

대외 스위치 교체 이전에는 너무나 잘 되던 것이었다.

 

원인을 찾기 위해 traceroute를 실행해봤다.

✅ traceroute란?

traceroute는 내 컴퓨터에서 목적지(서버, IP 등)까지 도달하는 경로 상의 각 네트워크 장비(Hop)를 추적하여, 각 구간의 응답 속도를 확인하는 명령어이다.

즉, 어디서 지연이 생기는지, 중간에 어디서 문제가 있는지를 분석할 수 있게 도와준다.

 

traceroute [옵션] [목적지 주소 또는 도메인]

 

📄 기본 출력 예시 (Linux 기준)

traceroute to www.google.com (142.250.206.4), 30 hops max
 1  192.168.0.1 (192.168.0.1)  1.123 ms  1.004 ms  0.984 ms
 2  10.1.1.1 (10.1.1.1)        2.133 ms  2.201 ms  2.184 ms
 3  112.174.45.1 (112.174.45.1)  12.324 ms  11.876 ms  11.983 ms
 4  ...
 5  142.250.206.4 (142.250.206.4)  30.183 ms  30.117 ms  30.089 ms

📌 구성 설명

항목	설명
hop 번호	몇 번째 구간인지 (라우터 개수)
IP 주소 (호스트 이름)	해당 라우터의 주소 (DNS 조회 시 이름도 표시)
세 숫자	각 시도에서 걸린 응답 시간 (ms 단위, 보통 3회 시도)

---

🔍 해석 포인트

🔹 정상적인 경우

• 응답 시간이 점점 증가
• 마지막 목적지까지 모두 도달

🔹 문제가 있는 경우

현상원인	예시
특정 hop 이후부터 * * *만 보임	방화벽이 ICMP 차단 or 해당 구간에서 응답 불가
응답 시간 급격히 증가	해당 라우터나 경로에 지연 발생 (병목 가능성)
중간에 Request timed out 발생	라우터 과부하, 정책적 차단 등

 

---

⚙️ 주요 옵션 (Linux 기준)

옵션	설명
-n	DNS 해석 없이 IP만 표시 (속도 ↑)
-m [숫자]	최대 hop 수 지정 (기본 30)
-w [초]	각 응답 대기 시간 지정
-q [숫자]	각 hop당 요청 횟수 (기본 3)

 

traceroute -n -m 20 -q 5 www.naver.com

 

---

🧪 실무 활용 예

상황 traceroute	활용 방법
대외기관 연결 불량	대상 IP로 traceroute → 중간 hop에서 문제 있는지 확인
특정 시간대만 느림	평상시 traceroute와 비교하여 병목 구간 분석
회선 변경 전후 비교	변경 전/후 traceroute 결과 비교로 품질 차이 분석

 

traceroute 를 실행한 결과,

 

특정 구간에서 데이터 송수신이 엄청 오래 걸리는 부분을 확인했다.

 

후에 보안/인프라 팀에서 스위치 장비 회선을 대역폭이 더 큰것으로 교체하고 나니, 통신이 잘 됐던 것이다,

 

결국에는, 스위치 장비와 회선의 성능 호환이 잘 되지 않았던 것이다.

 

서버 간 중간 역할이라 java 개발 외에도 별의 별 서버 작업은 다 해봤던 것 같은데

 

이번 이슈 원인 찾기는 너무 힘들었다..

 

하지만 무엇이 원인이었는지 알고 나니 허탈하고 어이 없었지만

 

그래도 앞으로 이와 유사한 상황이 발생했을 때 어떻게 해결할지를 차분히 생각해볼 여유가 생길 것 같다.

 

 

 

아래부터는 위 상황을 설명하기 위한 보충 해석이다.

---

 

🔧 대외 스위치 장비 교체 시 방화벽 재설정이 필요한 이유

1. 장비의 IP, MAC 주소 변경

• 스위치 장비 자체가 통신에 참여하거나 특정 IP로 NAT 설정되어 있던 경우, 장비 교체 후 IP나 MAC 주소가 달라지면 방화벽에서 이를 **허용 대상 목록(ACL, 정책 등)**에 다시 등록해야 함.

2. 라우팅 경로 변경 가능성

• 장비 교체 시 내부/외부 망으로 가는 라우팅 경로가 변경될 수 있으며, 이로 인해 방화벽이 기존의 포트/방향 외의 트래픽을 차단할 수 있음.

3. 인터페이스/Zone 변경

• 방화벽 정책은 종종 Zone이나 Interface 기준으로 되어 있는데, 새 장비가 다른 인터페이스로 연결되면 기존 방화벽 룰이 적용되지 않을 수 있음.

4. NAT, 포트포워딩, Static Routing 영향

• 기존 장비에서 NAT나 포트포워딩 설정이 적용되었고 방화벽이 이를 기준으로 설정되어 있었다면, 새 장비에 동일하게 설정되지 않으면 방화벽에 트래픽이 도달하지 않거나 차단됨.

5. 연결 확인을 위한 포트 재허용 필요

• 실제로 TCP 443, 22, 1521 등 특정 포트를 다시 열어야 하거나, 장비 교체 후 패킷 캡처나 헬스체크를 위한 임시 방화벽 설정을 추가하는 경우도 많다.

---

✅ 결론

• 회선이 그대로라고 해도, 스위치/라우터/장비 교체는 방화벽 정책에 영향을 줄 수 있다.
• 따라서 네트워크 변경 작업 전후에는 방화벽 정책 점검 및 재설정이 필요하다.
• 특히 대외기관 통신이 필요한 시스템이라면, 교체 전 방화벽 정책을 백업하거나, 통신 IP/포트 범위를 문서화해 두는 것이 좋다.

---

 

📌 회선은 그대로인데 스위치 교체 후 송수신 불안정했던 이유

✅ 1. 속도/듀플렉스 설정 불일치

• 스위치 포트와 회선(라우터/모뎀/통신장비) 간의 링크 속도(예: 100Mbps, 1Gbps) 또는 듀플렉스(Full/Half) 설정이 맞지 않으면 패킷 드롭, 재전송, 연결 지연 등의 문제가 발생할 수 있다.
• 특히 자동 협상(auto negotiation) 실패 시 이런 문제가 흔하게 발생한다.

✅ 2. 물리 계층(L1) 호환성 문제

• 스위치의 포트가 사용하는 **전기적 신호 방식(예: UTP Cat5e/6, 광모듈 SFP 종류)**이 회선 단에서 기대하는 것과 다르면 링크는 올라가더라도 품질이 떨어질 수 있다.
• 예를 들어 SFP 모듈 호환 안됨, 광/전기 신호 mismatch 등.

✅ 3. QoS 또는 트래픽 셰이핑 미적용

• 새 스위치가 기본 QoS 설정 없이 설치되었거나, 이전 장비와 **QoS 정책(우선순위, 대역폭 보장 등)**이 달라졌다면 회선 혼잡 시 품질이 떨어질 수 있다.

✅ 4. 케이블 문제와 인터페이스 상태 불일치

• 장비 교체 시 케이블 손상, 접촉 불량, 포트 불량 등의 단순한 물리 문제도 간과하기 쉽다.

---

💡 고성능 회선으로 바꾼 뒤 해결된 이유는?

• 새로운 회선은 대개 더 높은 품질의 장비 및 관리 체계를 갖추고 있으며,
• 전송 대역폭이 넓어져 병목 구간이 줄고,
• 스위치와의 링크 협상이나 신호 안정성이 더 우수했을 가능성이 크다.

즉, 장비와 회선의 조합에서 발생한 미묘한 호환성 또는 설정 문제가 회선 교체로 자연스럽게 해소된 것이다.

---

✅ 결론

**"회선은 문제가 없고 장비만 바꿨는데 이상하게 불안정해졌다"**는 경우는 실제로 장비와 회선 간의 호환성 또는 포트 설정 불일치로 발생하는 일이 많다.