Packet-Forwarding Process - PC1에서 Server1까지 패킷이 가는 과정

네트워크 장애를 볼 때 가장 먼저 확인해야 하는 흐름 중 하나가 패킷이 실제로 어느 방향으로 포워딩되는가이다. 이번 글에서는 PC1이 Server1의 HTTP 자원에 접근하는 상황을 기준으로, PC, 라우터, 스위치가 각각 어떤 판단을 하는지 정리한다.

이 글의 핵심은 단순하다. IP Packet은 출발지와 목적지 IP를 유지한 채 이동하지만, Layer 2 Frame은 Hop마다 새로 만들어진다. 그리고 라우터는 그 과정에서 IP Header의 TTL을 감소시키고, Routing Table 또는 CEF 정보를 보고 다음 출구를 결정한다.

기본 토폴로지: PC1과 Server1은 서로 다른 IP 네트워크에 있고, R1과 R2는 Serial PPP 구간으로 연결되어 있다.

1. 이 토폴로지에서 무엇을 봐야 할까?

장비	주소 정보	역할
PC1	`192.168.1.2/24`, MAC `1111.1111.1111`, GW `192.168.1.1`	Server1로 HTTP 트래픽을 보내는 출발지
R1	Fa0/0 `192.168.1.1/24`, MAC `AAAA.AAAA.AAAA` Se1/1 `192.168.2.1/30`	PC1의 Default Gateway
R2	Se1/1 `192.168.2.2/30` Fa0/0 `192.168.3.1/24`, MAC `BBBB.BBBB.BBBB`	Server1 네트워크에 직접 연결된 라우터
Server1	`192.168.3.2/24`, MAC `2222.2222.2222`, GW `192.168.3.1`	HTTP 서비스를 제공하는 목적지

스위치인 SW1, SW2는 같은 VLAN/브로드캐스트 도메인 안에서 Ethernet Frame을 전달한다. 반면 R1, R2는 IP Header를 보고 라우팅 판단을 하며, 이때 기존 L2 Header는 제거되고 새 L2 Header가 만들어진다.

2. Step 1 - PC1은 목적지가 같은 네트워크인지 판단한다

PC1의 주소는 192.168.1.2/24이고 목적지 Server1은 192.168.3.2이다. PC1은 자신의 Subnet Mask /24를 기준으로 목적지가 192.168.1.0/24 안에 있는지 계산한다. 결과적으로 192.168.3.2는 원격 네트워크이므로 PC1은 Server1에게 직접 Ethernet Frame을 보내지 않는다. 대신 Default Gateway인 R1의 MAC 주소로 Frame을 보낸다.

PC1은 Server1의 MAC을 찾는 것이 아니라, Default Gateway인 R1의 MAC을 ARP로 찾는다.

만약 PC1의 ARP Cache에 192.168.1.1에 대한 MAC 주소가 없다면 PC1은 ARP Request를 보낸다. R1은 자신의 Fa0/0 주소가 192.168.1.1이므로 ARP Reply로 AAAA.AAAA.AAAA를 알려준다. 그 다음 PC1이 만드는 Frame은 다음과 같다.

계층	출발지	목적지	의미
Layer 3	`192.168.1.2`	`192.168.3.2`	최종 목적지는 Server1이다. IP 주소는 최종 목적지를 바라본다.
Layer 2	`1111.1111.1111`	`AAAA.AAAA.AAAA`	현재 Hop의 목적지는 R1이다. MAC 주소는 다음 L2 도착지를 바라본다.

3. Step 2 - R1은 Frame을 벗기고 라우팅한다

R1은 Frame의 Destination MAC이 자기 MAC인 것을 보고 Frame을 수신한다. 그 다음 Ethernet Header를 제거하고 IP Header를 확인한다. 여기서 중요한 일이 두 가지 발생한다.

TTL

라우터를 하나 지날 때마다 IP Header의 TTL이 1 감소한다. TTL이 0이 되면 라우터는 Packet을 버리고 출발지에게 ICMP Time Exceeded 메시지를 보낸다.

Route Lookup

R1은 목적지 192.168.3.2에 대해 Routing Table에서 Longest Prefix Match를 수행한다. 예제에서는 192.168.3.0/24가 Serial1/1 방향으로 reachable하다고 판단한다.

R1-R2 구간이 Serial PPP이므로 R1은 next-hop MAC을 ARP로 찾지 않는다. PPP Header로 다시 캡슐화해서 내보낸다.

여기서 많은 사람이 헷갈리는 지점이 있다. R1이 라우팅한다고 해서 IP Packet의 출발지/목적지 IP가 R1/R2로 바뀌는 것이 아니다. IP 출발지와 목적지는 여전히 PC1과 Server1이다. 바뀌는 것은 L2 캡슐화 방식이다. PC1-R1 구간에서는 Ethernet Header였고, R1-R2 구간에서는 PPP Header가 된다.

4. Step 3 - R2는 Server1의 MAC을 알아내고 Frame을 만든다

R2도 R1과 마찬가지로 PPP Header를 제거하고 IP Header의 TTL을 감소시킨다. 그리고 목적지 192.168.3.2에 대한 Route Lookup을 수행한다. 이때 192.168.3.0/24는 R2의 Fa0/0에 직접 연결된 네트워크이다.

R2는 Server1과 같은 Ethernet 네트워크에 있으므로 Server1의 MAC 주소를 ARP로 학습한 뒤 Frame을 만든다.

R2의 ARP Cache에 Server1의 MAC 주소가 없다면, R2는 192.168.3.2에 대해 ARP Request를 보낸다. Server1은 2222.2222.2222를 ARP Reply로 알려준다. R2가 최종적으로 Server1에게 보내는 Frame은 다음과 같다.

계층	출발지	목적지	의미
Layer 3	`192.168.1.2`	`192.168.3.2`	IP Packet은 여전히 PC1에서 Server1로 가는 Packet이다.
Layer 2	`BBBB.BBBB.BBBB`	`2222.2222.2222`	마지막 Ethernet 구간에서는 R2가 출발지 MAC, Server1이 목적지 MAC이 된다.

5. 핵심 정리 - IP Packet은 유지되고, Frame은 Hop마다 바뀐다

구간	L2 Encapsulation	Source MAC / L2 Source	Destination MAC / L2 Destination	L3 Source -> Destination
PC1 -> R1	Ethernet	`1111.1111.1111`	`AAAA.AAAA.AAAA`	`192.168.1.2 -> 192.168.3.2`
R1 -> R2	PPP	MAC 없음	MAC 없음	`192.168.1.2 -> 192.168.3.2`
R2 -> Server1	Ethernet	`BBBB.BBBB.BBBB`	`2222.2222.2222`	`192.168.1.2 -> 192.168.3.2`

정리하면, 라우터는 Packet을 “그대로 중계”하는 것이 아니라 L2 Header를 제거하고, L3 Header를 확인하고, TTL을 감소시키고, 다음 구간에 맞는 새로운 L2 Header를 붙여서 내보낸다. 이것이 라우터의 packet-forwarding process를 이해할 때 가장 중요한 그림이다.

6. R1과 R2가 Serial이 아니라 Ethernet이면 ARP를 사용할까?

결론부터 말하면 IPv4 Ethernet 구간이라면 ARP를 사용한다. Serial PPP 구간에서는 MAC 주소가 없고 상대가 하나뿐인 Point-to-Point 링크이기 때문에 ARP가 필요 없다. 하지만 R1-R2 사이가 Ethernet Routed Link라면 이야기가 달라진다.

R1-R2가 Ethernet이면 R1은 next-hop IP인 R2의 192.168.2.2에 대해 ARP를 수행한다.

예를 들어 R1의 Routing Table에 다음과 같은 결과가 있다고 하자.

192.168.3.0/24 via 192.168.2.2, GigabitEthernet0/1

이 경우 R1은 Server1의 MAC을 찾는 것이 아니다. R1 입장에서 다음 Hop은 192.168.2.2, 즉 R2이다. 따라서 R1은 192.168.2.2에 대해 ARP를 수행하고, R2의 Ethernet MAC 주소를 알아낸 뒤 Frame의 Destination MAC으로 사용한다.

R1-R2 링크 타입	R1이 next-hop MAC을 알아야 하는가?	이유
Serial PPP / HDLC	아니오	Point-to-Point 링크라서 L2 next-hop을 MAC으로 구분하지 않는다.
Ethernet	예	Ethernet Frame을 만들기 위해 Destination MAC이 필요하다. IPv4에서는 ARP로 next-hop IP를 MAC에 매핑한다.
IPv6 Ethernet	예	IPv6는 ARP가 아니라 Neighbor Discovery를 사용해 next-hop의 L2 주소를 찾는다.

Ethernet에서 static route를 설정할 때 단순히 exit interface만 지정하면, 장비와 환경에 따라 최종 목적지 주소에 대해 ARP를 시도하거나 Proxy ARP에 의존하는 비효율적인 상황이 생길 수 있다. Ethernet next-hop이 있는 경로는 보통 next-hop IP를 명확히 지정하는 것이 좋다.

7. Routing Table, ARP, CEF는 서로 어떤 관계인가?

라우터가 매 Packet마다 Routing Table과 ARP Cache를 느리게 하나씩 뒤지는 방식으로 동작하면 비효율적이다. Cisco 장비는 일반적으로 CEF를 사용한다. CEF는 Control Plane의 Routing Table과 Layer 3-to-Layer 2 매핑 정보를 바탕으로 Data Plane에서 빠르게 참조할 수 있는 구조를 만든다.

Router control plane and data plane structures

Routing Table과 ARP/NHRP 같은 매핑 정보가 CEF FIB와 Adjacency Table의 기반이 된다.

구조	위치	역할
IP Routing Table	Control Plane	목적지 Prefix에 대한 최적 경로를 보관한다. Longest Prefix Match의 기준이 된다.
Layer 3-to-Layer 2 Mapping	Control Plane	Ethernet에서는 ARP Cache, DMVPN에서는 NHRP Cache처럼 next-hop L3 주소를 L2 도착 정보에 매핑한다.
CEF FIB	Data Plane	Routing Table에서 파생된 빠른 forwarding 정보다.
CEF Adjacency Table	Data Plane	실제 Frame Header를 만들기 위한 정보를 가진다. Ethernet이면 next-hop MAC이 포함된다.

8. 예시 명령어 정리

show ip route

특정 목적지 IP 또는 Prefix가 Routing Table에서 어떤 경로로 선택되는지 확인한다. 출력에서 봐야 할 것은 Routing Protocol, Administrative Distance, Metric, next-hop IP, outgoing interface이다.

show ip route 192.168.1.11
show ip route 192.168.1.0 255.255.255.0

show ip route longer-prefixes

특정 큰 Prefix 아래에 더 구체적인 경로들이 있는지 확인한다. Longest Prefix Match 문제를 확인할 때 유용하다.

show ip route 172.16.0.0 255.255.0.0 longer-prefixes

show ip cef

Control Plane의 Routing Table이 아니라 Data Plane에서 CEF가 실제로 어떤 next-hop과 interface를 사용하려 하는지 확인한다. Routing Table은 정상인데 트래픽 흐름이 이상하다면 CEF 정보를 같이 봐야 한다.

show ip cef 192.168.1.11
show ip cef 192.168.1.0 255.255.255.0

show ip cef exact-route

특정 Source IP와 Destination IP 조합이 실제로 어떤 interface와 next-hop으로 나가는지 확인한다. ECMP, Policy, CEF hashing 때문에 목적지 하나만 보는 것보다 정확한 판단이 필요할 때 도움이 된다.

show ip cef exact-route 10.2.2.2 192.168.1.11

show ip arp

Ethernet 구간에서 IP 주소가 어떤 MAC 주소로 매핑되어 있는지 확인한다. R1-R2가 Ethernet이라면 R1의 ARP Cache에는 R2 next-hop IP에 대한 MAC 주소가 있어야 정상이다.

show ip arp

show ip nhrp

DMVPN 같은 NBMA 환경에서 Tunnel next-hop과 실제 NBMA 주소 매핑을 확인한다. Ethernet의 ARP Cache와 목적이 비슷하지만, 사용하는 기술과 매핑 대상이 다르다.

show ip nhrp

show adjacency detail

CEF Adjacency Table에 저장된 실제 L2 Header 생성 정보를 확인한다. Ethernet adjacency에서는 Destination MAC, Source MAC, EtherType 같은 정보가 포함될 수 있다.

show adjacency detail

9. 장애 분석 관점에서 보는 순서

PC가 목적지를 Local/Remote 중 무엇으로 판단하는지 확인한다. 잘못된 Subnet Mask나 Default Gateway가 있으면 첫 단계부터 실패한다.

PC의 ARP Cache에서 Default Gateway MAC을 확인한다. PC가 원격지 Server의 MAC을 찾는 것이 아니라 Gateway MAC을 찾는다는 점이 중요하다.

R1의 Routing Table과 CEF FIB에서 목적지 Prefix가 어느 next-hop/interface로 나가는지 확인한다.

Next-hop 구간이 Ethernet이면 ARP/Adjacency를 확인한다. Serial PPP면 ARP가 필요 없다는 점을 구분한다.

마지막 라우터가 목적지 Host의 MAC을 ARP로 학습했는지 확인한다. 직접 연결 네트워크에서 ARP 실패가 나면 Routing Table이 맞아도 통신은 실패한다.

10. 마무리

Packet-Forwarding Process는 라우팅 공부의 가장 기본이지만, 실제 장애 분석에서는 계속 다시 돌아오게 되는 기준점이다. 특히 IP 주소는 end-to-end 관점, MAC 주소는 hop-by-hop 관점이라는 구분을 정확히 잡아두면 ARP, TTL, CEF, Routing Table을 훨씬 자연스럽게 이해할 수 있다.

네트워크 엔지니어로서 이 흐름을 설명할 수 있다는 것은 단순히 이론을 안다는 뜻이 아니다. 장애가 발생했을 때 “PC 문제인지, Gateway 문제인지, Routing Table 문제인지, ARP/Adjacency 문제인지”를 단계적으로 좁혀갈 수 있다는 뜻이다. 이 능력이 실무와 면접에서 꽤 큰 차이를 만든다.

IPv6 에 대하여 (0)	2026.06.10
DHCP에 대해서 (0)	2026.06.09
과연 두 Host는 통신이 될까? (0)	2026.06.09
[Data Center CCIE] - Fibre Channel - 2 (0)	2026.03.29
[Data Center CCIE] - Fibre Channel - 1 (0)	2026.03.25

네트워크 생존노트