OSI 7계층 기반 IT인프라 및 네트워크 장애 처리 순서

엔지니어들이 현장에서 가장 자주 마주치는 계층별 대표적인 장애 사례(Case)와 구체적인 해결 방안(Solution)을 정리해 드립니다. OSI 7계층에 대한 대략적인 개념은 지난 포스팅 글을 참조해주세요.
“OSI 7계층이 도대체 뭔가요?” 실무 장비로 완벽 정리 – Tech & Investment

단순히 “안 돼요”라고 말하지 말고, “이 계층의 이 설정이 원인입니다”라고 말하는 전문가가 되어봅시다.

상황: 네트워크 장비 인터페이스(Interface)가 DOWN 상태이거나, UP/DOWN을 반복(Flapping)합니다.

원인: 광케이블(Fiber)이 심하게 꺾였거나, 커넥터 단면에 먼지가 묻은 경우. 혹은 통신사 전송 장비(DWDM/OTN/MSPP)의 광 출력이 약해진 경우입니다.
거의 통신사(ISP)의 관할 구간이기 때문에 통신사에서 처리합니다.
해결 방안:
1. 광 레벨 측정: 장비 명령어(show interfaces transceiver detail 등)로 수신 감도(Rx Power)를 확인합니다. 보통 -20dBm 이하로 떨어지면 불안정 합니다.
2. OTDR측정: 선로를 구간별로 OTDR측정을 하여 선로 단선위치를 확인합니다.
3. ISP 신고: 우리 쪽이 깨끗하다면 KT/SK/LG 등 통신사에 전화해 “전송망(MSPP/PTN) 구간 점검 부탁드립니다”라고 요청합니다.
4. 랜케이블(UTP) 불량 추정하여 랜테스터기를 통해 UTP케이블 장애 여부를 판단합니다.

원인: ISP의 전송 장비(MSPP, OTN 등) 내의 라인 카드(Line Card)가 불량인 경우.
해결 방안: 이건 우리가 못 고칩니다. 통신사 관제실에 연락하여 “구간 루프(Loop) 테스트”를 요청하여 불량 구간을 찾아내고 장비 교체를 요구해야 합니다.

상황: 인터넷이 극도로 느려지거나 끊기며, 스위치의 모든 LED가 미친 듯이 깜빡거립니다. (브로드캐스트 스톰)

원인: 누군가 남는 랜선을 벽면 포트 두 곳에 동시에 꽂았거나(Hub to Hub), 스위치 간 이중화 연결 시 설정이 누락된 경우입니다. 패킷이 뱅글뱅글 돌며 대역폭을 100% 점유합니다.
해결 방안:
1. STP 활성화: 스위치에 Spanning Tree Protocol (STP, RSTP)이 켜져 있는지 확인합니다. 이게 켜져 있으면 루핑 감지 시 자동으로 포트를 차단(Block)합니다.
2. BPDU Guard: 사용자 PC가 연결되는 엣지 포트에는 BPDU Guard 기능을 켭니다. 사용자가 실수로 허브를 연결해 루핑을 유발하면 즉시 해당 포트를 꺼버립니다(Shutdown).

상황: Ping 테스트는 정상인데, 웹페이지 접속이나 특정 프로그램 연결이 안 됩니다.

원인:
- 갈 때: PC → 라우터A → 서버
- 올 때: 서버 → 라우터B → PC
- 경로가 다르면 중간에 있는 방화벽(Firewall)이 문제입니다. 방화벽은 “나는 나가는 패킷(SYN)을 본 적이 없는데, 왜 들어오는 패킷(SYN-ACK)이 있지?”라며 보안상 패킷을 폐기(Drop)합니다.
해결 방안:
1. 라우팅 정리: 갈 때와 올 때의 경로가 같도록 라우팅 테이블(Static Route)을 수정합니다.
2. SNAT (Source NAT): 경로 수정이 어렵다면, 출발지 IP를 방화벽의 IP로 변환(NAT)하여 보냅니다. 그러면 서버는 응답을 무조건 방화벽으로 보내게 되어 경로가 일치해집니다.

상황: 서버 엔지니어는 “서버 켜져 있어요!”라고 하는데, L4 스위치(로드밸런서)에서는 해당 서버를 Down으로 표시합니다.

원인: L4 스위치가 서버가 살았는지 확인하는 방법이 잘못된 경우입니다.
- L4는 80번 포트(HTTP)를 체크하는데, 서버는 8080번 포트(WAS)만 띄워놓은 경우.
- L4는 index.html을 찾는데, 개발자가 파일명을 main.html로 바꾼 경우.
해결 방안:
1. 서버 소켓 확인: 서버에서 netstat -an | grep LISTEN 명령어로 실제 서비스 포트가 열려 있는지 확인합니다.
2. 헬스 체크 정책 수정: 서버의 실제 서비스 환경에 맞춰 L4 장비의 체크 방식을 TCP Port 방식에서 L7 HTTP Request 방식으로 정교하게 변경하거나, 포트 번호를 맞춥니다.

상황: 접속은 되는데 브라우저에 에러 코드나 경고창이 뜹니다.

원인: HTTPS 접속 시 “안전하지 않음” 경고가 뜸. 서버에 설치된 인증서 유효기간이 지났거나, 체인 인증서(Intermediate CA)가 누락된 경우입니다.
해결 방안:
1. 인증서 갱신: 만료일 확인 후 갱신합니다.
2. Chain 파일 적용: 인증서 적용 시 Root CA와 Server Cert 사이에 Chain Cert를 반드시 함께 적용해야 PC뿐 아니라 모바일에서도 정상 인식됩니다.

원인:
- 500: 개발 소스 코드(Java, PHP 등) 내부의 문법 에러나 로직 오류.
- 502 Bad Gateway: 앞단(Nginx/Web)은 정상인데, 뒷단(Tomcat/WAS/DB)이 응답을 안 하거나 죽은 경우.
해결 방안:
1. 로그 분석: 네트워크 문제가 아닙니다. 웹 서버의 Access Log와 Error Log를 개발자에게 전달하여 소스 코드를 수정하게 해야 합니다.

원인: 사용자가 사용하는 DNS 서버(예: 168.126.63.1)가 죽었거나, 도메인 변경 사항이 아직 전파(TTL)되지 않은 경우.
해결 방안:
1. nslookup 테스트: nslookup [도메인] 명령어로 IP가 제대로 변환되는지 확인합니다.
2. DNS 캐시 삭제: PC의 CMD 창에서 ipconfig /flushdns를 입력해 꼬인 정보를 초기화합니다.

현장에서 급할 때 바로 찾아보세요. 기초 이론부터 Cisco, HP, Juniper, L4 장비까지 모두 정리했습니다.

코멘트