네트워크핵심 · 19분 읽기

네트워크 장애 분석: 요청·응답·상태를 따라가기

두 라우터와 DHCP·NAT 실습의 실제 실패 기록에서 출발해 주소 계산, 경로 선택, 이웃 해석, 변환 상태와 서비스 계층을 순서대로 검증합니다.

개념부터 찾아보기

정의·역할·동작 원리를 독립 페이지에서 확인하세요. 본문의 밑줄 용어에도 설명이 있습니다.

Cisco IOS·IOS XE CLI Cisco Packet Tracer 네트워크 장애 분석

이 노트에서 설명할 수 있게 되는 것

원본 실패 출력에서 확정할 수 있는 사실을 구분한다.
로컬 주소 판단부터 왕복 경로·NAT·서비스까지 가설을 좁힌다.
분석 근거와 자신의 담당 범위를 설명할 산출물을 정리한다.

먼저 알면 좋은 개념OSI 계층·TCP/IP와 홉별 캡슐화 라우팅 테이블과 정적 경로의 선택·재귀 해석 패킷 캡처·SPAN·RSPAN: 관측 위치와 실제 해석

01장애 범위를 고정하는 첫 분석 단계

개념은 요청·응답과 계층별 상태를 연결해 실패한 경계를 좁히는 과정이다. 실패· 실패· 거절은 서로 다른 증상이다.
실습 토폴로지원본 캡처의 PC1 192.168.0.2/24와 PC2 192.168.2.2/24는 다른 이다. PC1은 게이트웨이 192.168.0.1의 MAC을 하며 일반 원격 통신에 Proxy 가 필수는 아니다.
HTTPS의 조건IP 직접 접속은 이름 검증·SNI·가상 호스트가 달라질 수 있다. 응용 비교에서는 같은 Host 이름을 유지하는 시험도 필요하다.

시험의 조건 고정출발지 장비·IP·인터페이스, 목적지 이름·IP·포트, 시각과 기대 결과를 적는다.
비교 기준 확보정상 비교 대상과 최근 변경을 기록한다. 같은 조건의 성공·실패를 비교할 수 있게 만든다.
IP 전달과 이름 해석 분리IP 기반 시험과 이름 기반 시험을 나누어 와 전달 경로의 실패를 구분한다.
실패 경계로 조사 이동주소 획득·이웃 해석··전송 연결·응용 응답 중 관찰한 실패에 맞춰 다음 절의 증거를 연결한다. 광범위한 재설정을 첫 조치로 삼지 않는다.

PC1 192.168.0.2와 PC2 192.168.2.2가 R1-R2의 192.168.1.0/24 링크를 통해 연결된 원본 토폴로지 — 9월 8일 실습 구성도. 양쪽 LAN은 Ethernet이며 가운데 붉은 링크는 수업의 Serial 연결이다. 링크 종류별 주소 해석을 구분한다.

원리 심화

02원인을 증명하는 관찰점과 패킷 동일성

검사할 흐름 고정출발지·목적지 IP와 포트, 프로토콜, 시작 시각을 고정하면 서로 다른 시험의 결과를 섞지 않을 수 있다. 이름 기반 접속은 먼저 어떤 주소로 실제 연결했는지 기록한다.
동일 패킷의 단서가 없으면 tuple, 순서 번호·길이, ID와 시간 관계가 대조 단서다. TTL·MAC처럼 정상 전달 과정에서 변하는 필드는 같은 값이어야 한다고 요구하지 않는다.
변환 경계의 대응·터널 앞뒤에서는 주소나 헤더가 달라진다. 변환표·내부 패킷·순서 번호·길이 등의 대응을 이용해 서로 같은 통신이라는 근거를 만든다.
의 범위수신 지점에서 패킷을 실제 본 사실은 그 지점까지 도달했다는 근거다. 그 이후 응용이 읽었는지, 저장했는지, 응답을 만들었는지는 별도의 증거가 필요하다.
의 전제패킷이 없다는 판단에는 올바른 인터페이스·시간·필터·충분한 수집 용량이라는 전제가 필요하다. 이 전제를 검증하지 않으면 망의 손실과 관측 실패를 구분할 수 없다.

03원본 실패 사례: administratively down에서 up/up까지

관리 Down추석 실습 기록에서 R1 FastEthernet0/0에는 10.5.128.2/22가 설정되었지만 상태가 administratively down/down이었다. IP를 입력하는 것과 인터페이스를 활성화하는 것은 별도이다.
- no shutdown 뒤 LINK·LINEPROTO up 메시지가 나타나고 up/up 상태가 되었으나 바로 이어진 ping은 여전히 0/5였다.
up/up 이후 실패이 실습에서는 no shutdown 뒤에도 ping 실패가 관찰되었다. 뒤에 5/5 성공이 나오지만 그 사이의 상대 장비·가상 연결 상태가 모두 기록되지 않아 최종 원인을 하나로 확정할 수 없다.
- up/up은 링크 계층의 필요 조건이며 주소··상대 정책·응답 경로를 보증하지 않는다.
최종 원인 한계같은 기록에 기본 경로를 추가하는 명령이 있지만 10.5.128.1은 10.5.128.2/22와 같은 직접 연결 이다. 정상 connected 경로가 있으면 그 이웃 접근은 기본 경로 추가로 해결되는 문제가 아니다.
- 가까운 변경과 성공이 시간상 이어졌다는 이유만으로 인과관계를 만들지 않는다.

text

원본 출력 일부 (사건 순서대로 발췌)
FastEthernet0/0  10.5.128.2  administratively down  down
... no shutdown 후 ...
FastEthernet0/0  10.5.128.2  up                     up
Success rate is 0 percent (0/5)
... 이후 별도 시험 ...
Success rate is 100 percent (5/5)

원본의 상태 변화와 시험 결과를 발췌했다. 생략 구간의 미기록 원인을 추정하지 않는다.

LEARN THROUGH PRACTICE

up/up 뒤에도 ping이 실패한 기록을 단계별로 진단하기

인터페이스 활성화 전후의 실제 실패 기록을 읽고 링크 상태·직접 연결 경로··최종 성공 원인을 분리한다.

실습 구성과 전제

R1 FastEthernet0/0은 10.5.128.2/22이고 연결 상대는 10.5.128.1/22이다. 같은 /22에 속하므로 정상 connected 경로가 있으면 기본 경로를 사용할 대상이 아니다.
구성도에는 내부 서버망 10.5.132.0/22와 R2 연결망 10.5.136.0/22도 있다. 이번 진단 범위는 R1에서 바로 연결된 10.5.128.1까지로 제한한다.

주소 계획에서 같은 망인지 계산한다
- /22의 마스크는 255.255.252.0이고 세 번째 옥텟의 블록 크기는 4다. 10.5.128.1과 .2는 10.5.128.0~10.5.131.255 범위에 함께 들어간다.
- 목적지가 직접 연결된 이웃이므로 R1은 올바른 인터페이스로 를 통해 상대 MAC을 알아낼 수 있어야 한다. 내부 다른 LAN과 문제를 처음부터 섞지 않는다.
원본 크기로 보기 ↗
- R1의 f0/0에 10.5.128.2/22, 위쪽 연결 상대에 10.5.128.1/22가 표시된다.
- R1 e2/0의 10.5.132.1/22 서버망과 e2/1의 10.5.136.1/22 R2 연결망은 별도로 그려져 있다.
확인 기준
출발지 인터페이스·목적지·마스크를 고정한다. 이름이나 이전·이후 주소를 바꾸어 가며 다른 시험을 같은 결과로 비교하지 않는다.
administratively down을 먼저 해결한다
- 실행 기록에서는 주소를 입력한 뒤 ping 0/5가 반복되고 show ip interface brief에 administratively down/down이 나온다. IP 설정은 인터페이스 활성화 명령을 대신하지 않는다.
- 해당 인터페이스에 no shutdown을 적용한 뒤 LINK와 LINEPROTO up 로그가 나타났다. 이 변경이 해결한 것은 관리적 비활성 상태다.
text
```
show ip interface brief
configure terminal
interface FastEthernet0/0
 no shutdown
end
show ip interface brief
ping 10.5.128.1
```
실제 실패 기록의 핵심 명령을 사건 순서대로 정리했다.
확인 기준
상태가 up/up으로 바뀌었는지 확인한 뒤 동일 출발지·목적지로 시험한다. no shutdown 입력 사실만으로 복구되었다고 적지 않는다.
up/up 뒤의 0/5를 별도 실패로 다룬다
- 기록에는 up/up 뒤에도 Success rate is 0 percent (0/5)가 나온다. 따라서 링크 활성화만으로 통신을 복구했다고 볼 수 없다.
- 이 시점에는 connected 경로, 응답, 상대 주소·마스크, 가상 연결과 필터를 확인해야 한다. 기본 경로를 추가하기 전에 10.5.128.1에 대한 조회가 직접 연결 경로를 선택하는지 본다.
text
```
show ip route 10.5.128.1
show arp
show interfaces FastEthernet0/0
ping 10.5.128.1 source 10.5.128.2
```
실패 시 추가하면 유용한 관찰 명령. 이 출력이 원 기록에 존재하는 것처럼 제시하지 않는다.
확인 기준
다음 조회는 원인을 좁히기 위한 재구성이다. 해당 · 출력이 기록에 없으므로 특정 단계가 실제 원인이었다고 확정하지 않는다.
성공 기록은 보존하고 인과관계는 제한한다
- 뒤에는 5/5 성공과 RTT min/avg/max 16/56/84 ms가 남아 있다. 그러나 그 사이 상대 장비와 연결 상태가 모두 기록되지 않아 최종 해결 원인을 하나로 확정할 수 없다.
- 기본 경로를 넣은 직후에도 0/5가 한 번 더 기록되어 있다. 같은 망의 이웃 접근을 기본 경로 추가로 해결했다고 설명하면 실제 사건 순서와 원리를 모두 놓친다.
text
```
관찰 순서
1. FastEthernet0/0: administratively down / down
2. no shutdown → LINK·LINEPROTO up
3. ping: 0/5
4. 기본 경로 추가 뒤에도 ping: 0/5
5. 이후 별도 시험: 5/5, RTT 16/56/84 ms
```
원 실행 기록의 상태·결과를 요약했다. 3~5 사이의 모든 외부 변경이 기록된 것은 아니다.
확인 기준
보고서에는 최초 상태, 변경, 바로 뒤의 실패, 나중 성공을 각각 기록한다. 최종 성공만 남기거나 미기록 원인을 채워 넣지 않는다.

실습에서 확인한 동작 원리

up/up은 연결의 필요 조건이며 IP 이웃 도달 가능성과 같은 뜻이 아니다.
시간상 앞선 설정과 나중 성공을 연결하려면 같은 시험 조건과 추가 증거가 필요하다.

설정·출력 추가로 확인하기 14장

아래 화면을 펼쳐 위 실습의 설정값, 명령과 확인 기준을 비교해 보세요. 각 묶음은 별도 실습 기록입니다.

실습 화면 묶음 01 1장

TFTP 이미지·설정 전송 · TFTP 실습 — 학습 원본 · TFTP 이미지·설정 전송의 TFTP 실습에 수록된 화면·도식이다.

실습 화면 묶음 02 1장

실습 화면 묶음 03 1장

실습 화면 묶음 04 1장

실습 화면 묶음 05 1장

실습 화면 묶음 06 1장

실습 화면 묶음 07 1장

실습 화면 묶음 08 1장

여러 네트워크를 연결하는 종합 실습 · 네트워크 맵 — 학습 원본 · 여러 네트워크를 연결하는 종합 실습의 네트워크 맵에 수록된 화면·도식이다.

실습 화면 묶음 09 1장

여러 네트워크를 연결하는 종합 실습 · 추석 실습 — 학습 원본 · 여러 네트워크를 연결하는 종합 실습의 추석 실습에 수록된 화면·도식이다.

실습 화면 묶음 10 1장

실습 화면 묶음 11 1장

학습 원본 · 주소·인터페이스와 패킷 흐름 실습의 해당 절에 수록된 화면·도식이다.

실습 화면 묶음 12 1장

실습 화면 묶음 13 1장

실습 화면 묶음 14 1장

동작·명령 참고 문서

RFC 1812 — IPv4 Router Requirements ↗RFC 9293 — ACK·윈도우 상태 해석 ↗

04주소·마스크·DHCP: 전달 전에 로컬 판단부터

호스트 주소R2 설정에서 10.5.136.0 255.255.252.0은 /22의 네트워크 주소여서 Bad mask 오류가 났고 10.5.136.2로 고쳤다. /22는 세 번째 octet가 4 단위로 증가하므로 이 망의 범위는 10.5.136.0~10.5.139.255다.
- 일반 호스트에 네트워크 주소와 broadcast 주소를 배정하지 않는다.
실제 임대 pool에 주소 범위가 보이는 것과 클라이언트가 임대받은 것은 다르다. 원본의 Leased addresses: 0은 당시 임대가 없다는 뜻이다.
- excluded-address, default-router, 와 SVI 활성 상태, Discover·Offer·Request·Ack 흐름 및 relay를 확인한다.
- 주소를 받은 뒤에도 gateway· 옵션이 잘못되면 후속 통신은 실패한다.
대상마스크가 너무 넓으면 실제로 라우터로 보내야 할 목적지를 같은 링크로 판단하여 만 반복할 수 있다. 너무 좁으면 같은 링크의 주소에 불필요하게 게이트웨이를 사용할 수 있다.
- 장비마다 IP만 비교하지 말고 prefix와 해당 목적지에 대한 결정까지 읽는다.

05L2 전달: ARP·VLAN·MAC 학습을 같은 링크에서 확인

·MAC·PC가 게이트웨이 MAC을 모르면 요청을 내고 응답을 기다린다. 이 단계가 실패하면 이후 / 패킷 자체가 나가지 못할 수 있다.
- 요청이 단말에서는 보이지만 게이트웨이에는 없다면 배선··trunk allowed list· 상태· 같은 링크 경로를 확인한다.
양쪽 관측응답이 양끝 캡처에는 보이는데 이웃 항목이 완성되지 않는다면 IP 충돌, 잘못된 대상 필드, ·호스트 보안 정책과 관측 위치를 살핀다. switch MAC 테이블은 출발지 MAC을 학습하고 별로 관리하므로 MAC만 같다고 차이를 무시하지 않는다.
라우터의 링크 처리라우터는 입력 프레임을 처리하고 L3 경로에 맞춰 새로운 출력 링크 프레임을 만든다. 결정의 주된 키가 IP 목적지라는 뜻이며 접속에서는 자신의 MAC과 다음 홉의 MAC을 사용한다.
- Serial point-to-point 링크에는 과정을 그대로 적용하지 않는다.

06L3 전달: 각 라우터의 최장 일치와 반환 경로

최장 일치각 라우터는 자신의 에서 목적지와 가장 길게 일치하는 prefix를 찾아 전달한다. 동일 prefix 후보를 고르는 AD·metric과 이미 선택된 서로 다른 prefix 사이의 longest prefix match는 구분한다.
- show ip route의 C는 Connected, S는 Static을 뜻한다.
홉별 전달예제에서 R1은 192.168.2.0/24를 192.168.1.2로 보내고 R2는 192.168.0.0/24를 192.168.1.1로 보내는 경로가 필요하다. 라우터는 상대 라우터의 전체 설정을 읽고 자동으로 왕복 경로를 완성하지 않는다.
- 다음 홉 자체가 어떻게 도달 가능한지도 확인한다.
응답은 반대 방향의 별도 패킷이다. 출발지 주소 선택, 비대칭 , reverse-path 검사와 상태기반 방화벽 때문에 요청 도착 후 응답만 실패할 수 있다.
- 라우터 자체에서 보낸 ping은 LAN 클라이언트와 출발지·입력 인터페이스· 대상이 달라서 같은 시험이 아니다.

! 원본 두 라우터 구성의 설명용 경로
! R1
ip route 192.168.2.0 255.255.255.0 192.168.1.2
! R2
ip route 192.168.0.0 255.255.255.0 192.168.1.1
! 각 장비에서 실제 선택 경로를 확인
show ip route 192.168.2.2

PC의 기본 게이트웨이·연결 링크·주소가 먼저 정상인 경우의 예제다. 이 명령만으로 전체 통신을 보장하지 않는다.

07NAT·ACL: 변환 조건과 차단 규칙을 분리

동작추석 실습의 R2는 내부 192.168.0.0/24를 로 선택하고 10.5.136.10~20 풀로 동적 했다. 이 10.5 주소는 사설 주소이며 실습에서 outside 쪽 주소 역할을 한 것이지 실제 공인 를 확보했다는 뜻은 아니다.
- 주소 변환과 인터넷 도달성은 별도이다.
주소 풀 고갈동적 without overload는 사용할 pool 주소가 모두 점유되면 새로운 내부 주소의 변환이 실패할 수 있다. PAT는 포트 등을 이용해 공유 범위를 늘리지만 무제한 세션을 보장하지 않는다.
- inside/outside 위치, 대상 , 실제 변환표와 카운터, 외부에서 변환 주소로 돌아오는 경로를 확인한다.
분류·차단 의 주소 선택용 에서 permit은 변환 대상 선정이다. 인터페이스에 적용한 트래픽 필터 의 permit/deny와 효과가 다르다.
- “에 permit했는데 패킷이 안 간다”면 어떤 기능이 그 을 참조하는지부터 확인한다.
- 방화벽의 상태표와 호스트 방화벽도 별도로 점검한다.

예제로 추적

08NAT 앞뒤와 반환 경로를 네 tuple로 연결하기

가상 요청 시작클라이언트 192.0.2.10:51000이 서버 198.51.100.20:443으로 SYN을 보낸다. 내부 캡처 A는 이 tuple과 SYN 순서 번호 1000을 관측한다.
외부 변환 관측외부 캡처 B에서는 출발지가 203.0.113.5:62000으로 바뀌고 목적지·순서 번호는 유지된다. 상태가 두 끝점을 연결하면 A와 B의 요청을 같은 흐름으로 식별할 수 있다.
서버 응답 관측서버가 198.51.100.20:443→203.0.113.5:62000으로 SYN·ACK, ACK=1001을 보낸다. B에 이 응답이 있으면 서버 응답과 외부까지의 가 관측된 것이다.
내부 복원 관측정상 역변환 뒤 A에는 198.51.100.20:443→192.0.2.10:51000의 SYN·ACK가 나타난다. ACK=1001은 해당 SYN이 순서 공간 1을 소비했다는 점과 연결된다.
증거에 따른 범위B에 응답이 있으나 A에 없고 양쪽 수집 조건이 정상이라면 두 지점 사이의 상태·필터·내부 전달이 후보가 된다. 서버 문제라고 다시 추정하기보다 마지막 성공 지점 이후를 좁힌다.

09TCP·DNS·응용 계층: 성공의 범위를 좁혀 말하기

ping의 범위ping 성공은 그 출발지와 목적지 사이에서 Echo 왕복이 되었다는 증거이며 443 서비스·인증·HTTP 응답을 보증하지 않는다. ping 실패도 차단이나 응답 rate limit 때문일 수 있으므로 호스트가 반드시 꺼졌다는 뜻은 아니다.
··응용 SYN에 RST가 오면 관측 경로에서 연결 거절이 발생했음을 알 수 있지만 실제 서버와 중간 장비 중 누가 만들었는지 확인해야 한다. SYN이 반복되고 아무 응답이 보이지 않으면 요청 손실·응답 경로·필터·센서 누락을 나눠 본다.
- 연결 뒤 실패나 HTTP 4xx/5xx는 전달 경로보다 인증서·정책·앱 상태를 더 직접적으로 살펴야 한다.
는 질의 대상 서버, QNAME, QTYPE, 응답 코드와 실제 응답 레코드를 비교한다. NOERROR라도 원하는 주소 레코드가 없을 수 있고 캐시 때문에 변경 전 결과가 보일 수 있다.
- traceroute의 별표는 해당 hop의 응답이 없다는 뜻이며 그 다음 hop 응답이 계속 보이면 전달까지 멈췄다고 단정하지 않는다.

10변경 전후 증거와 직무 산출물로 남기기

변경 전후 비교한 번에 한 가설을 시험하고 바뀐 설정, 시험 출발지·목적지, 관측 시각과 결과를 기록한다. 전체 설정 초기화나 보안 기능 일괄 해제는 문제 지점을 가리고 정상 설정을 잃게 한다.
- 현재 상태를 보존한 뒤 가장 작은 범위의 수정과 되돌릴 방법을 정한다.
직무 산출물취업용 프로젝트 설명에는 “네트워크 구축 가능”이라는 문장만 쓰기보다 주소표·토폴로지·선택 경로·실패 로그·수정 이유·재검증 결과를 연결한다. 팀 전체가 만든 결과와 자신이 맡은 설정·분석 범위를 구분하고 확인되지 않은 원인을 해결 성과로 주장하지 않는다.
운영 인계운영 인계에는 영향 범위, 원인 또는 남은 가설, 임시 조치와 영구 조치, 확인한 시험과 미확인 조건을 남긴다. 본문 원본 사례처럼 최종 성공은 보이지만 정확한 전환 원인이 기록되지 않았다면 그 한계까지 적는 것이 재현 가능한 분석이다.

검증·예외

11접속은 되지만 내용 전송이 멈추는 세 가지 원인

관련 패턴 3-way handshake와 작은 데이터는 성공하지만 큰 세그먼트에서 ACK가 진행하지 않으면 ·터널 오버헤드·DF 조건을 조사한다. 연결 설정 성공은 모든 크기의 패킷 전달 성공을 보장하지 않는다.
수신 버퍼 관련 패턴서버의 ACK가 도착하면서 advertised window가 0으로 유지되면 수신 버퍼·응용 읽기 지연이 단서다. 패킷 손실을 뜻하는 중복 ACK와 다른 상태 변화다.
응용 처리 관련 패턴요청 바이트가 모두 누적 ACK됐는데 응용 응답이 늦으면 서버 처리·상위 의존 서비스·응용 타임아웃을 조사한다. ACK는 요청에 대한 업무 처리 성공 응답이 아니다.
문제 분리연결한 목적지 IP 자체가 기대와 다르면 resolver 응답·캐시·선택된 A/AAAA를 먼저 설명한다. 올바른 서버까지 이미 연결된 후의 데이터 정지는 질의 실패와 다른 단계다.
전후 비교의 기준수정 전후에 같은 흐름·같은 크기·같은 경로 조건을 맞추고 실패했던 상태가 어디서 달라졌는지 기록한다. 설정 변경 뒤 우연히 한 번 성공한 결과보다 특정 카운터·ACK 진행·정책 일치가 검증 근거다.

학습 확인

이해했는지 확인하기

실패한 출발지·목적지·서비스·시간을 구체적으로 기록했는가?
요청과 응답의 주소 변환 및 왕복 경로를 모두 그렸는가?
가설마다 예상 결과와 실제 결과를 비교하며 한 번에 하나씩 확인했는가?