네트워크 생존노트

Packet Forwarding Process

성민 | 네트워크 생존노트 — Thu, 11 Jun 2026 09:11:35 +0900

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에서 빠르게 참조할 수 있는 구조를 만든다.

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 에 대하여

성민 | 네트워크 생존노트 — Wed, 10 Jun 2026 15:48:24 +0900

IPv6에 대하여

IPv6는 단순히 IPv4 주소가 부족해서 나온 긴 주소 체계가 아니다. 주소 형식, 자동 설정 방식, Router Advertisement, DHCPv6, Relay 동작이 서로 연결되어 있다. 특히 네트워크 엔지니어라면 SLAAC, EUI-64, RA Flag, Stateful/Stateless DHCPv6의 차이를 명확히 이해해야 한다.

1. IPv6 주소 형식

IPv6 주소는 128bit 주소 체계다. 일반적으로 16bit씩 8개 블록으로 나누어 16진수로 표기한다.

2001:0db8:0000:0000:0000:0000:0000:0001

IPv6는 연속된 0을 줄여 쓸 수 있다. 위 주소는 다음처럼 표현할 수 있다.

2001:db8::1

일반적인 LAN 구간에서는 보통 /64 prefix를 사용한다. 이때 앞 64bit는 network prefix, 뒤 64bit는 interface identifier 역할을 한다.

IPv6 Address = Prefix 64bit + Interface ID 64bit

Prefix       : 2001:db8:a:a::/64
Interface ID : xxxx:xxxx:xxxx:xxxx
Result       : 2001:db8:a:a:xxxx:xxxx:xxxx:xxxx

2. IPv6 주소 할당 방식

IPv6 주소는 여러 방식으로 설정할 수 있다.

방식	주소 생성 주체	특징
Static	관리자	관리자가 IPv6 주소를 직접 설정한다.
SLAAC	Host	RA로 받은 prefix와 Host가 만든 Interface ID를 조합한다.
Stateful DHCPv6	DHCPv6 Server	DHCPv6 Server가 주소를 할당하고 lease를 관리한다.
Stateless DHCPv6	Host + DHCPv6 Server	주소는 SLAAC으로 만들고 DNS 같은 기타 정보만 DHCPv6로 받는다.

3. SLAAC

SLAAC는 Stateless Address Autoconfiguration의 약자다. Router가 RA, Router Advertisement로 prefix를 알려주면 Host가 스스로 Interface ID를 만들어 IPv6 주소를 완성한다.

Router RA
Prefix : 2001:db8:a:a::/64

Host
Interface ID : Host가 생성

Result
2001:db8:a:a:xxxx:xxxx:xxxx:xxxx

Host는 RS, Router Solicitation을 보내 RA를 요청할 수 있고, Router는 RS를 받지 않아도 주기적으로 RA를 보낼 수 있다.

RS, Router Solicitation
Host -> ff02::2
ICMPv6 Type 133

RA, Router Advertisement
Router -> ff02::1
ICMPv6 Type 134

IPv6 default gateway는 DHCPv6가 주는 것이 아니라 RA를 통해 학습한다. Host는 RA를 보낸 Router의 link-local address를 default gateway로 사용한다.

4. Interface ID 생성 방식

Random 또는 Stable Random Interface ID

Modern Windows PC는 기본적으로 EUI-64를 사용하지 않고 random 또는 stable random 방식으로 Interface ID를 만든다. 이 방식은 MAC 주소 흔적을 IPv6 주소에 남기지 않기 때문에 privacy 측면에서 유리하다.

Prefix       : 2001:db8:a:a::/64
Random IID   : 5850:6d61:01fb:ef3a
IPv6 Address : 2001:db8:a:a:5850:6d61:1fb:ef3a

Random으로 만들면 이론적으로 중복 가능성은 있다. 하지만 64bit Interface ID 공간은 매우 크고, IPv6는 주소를 실제 사용하기 전에 DAD, Duplicate Address Detection을 수행한다.

1. Host가 Interface ID 생성
2. IPv6 주소를 tentative 상태로 둠
3. Neighbor Solicitation으로 중복 여부 확인
4. 응답이 없으면 주소 사용
5. 중복이 확인되면 해당 주소 사용 불가

EUI-64

EUI-64는 MAC 주소를 기반으로 IPv6 Interface ID 64bit를 만드는 방식이다. 예를 들어 MAC 주소가 다음과 같다고 하자.

MAC = 00:50:79:66:68:01

먼저 앞 24bit와 뒤 24bit 사이에 ff:fe를 삽입한다.

00:50:79 + ff:fe + 66:68:01
= 00:50:79:ff:fe:66:68:01

그 다음 첫 번째 octet의 U/L bit를 flip한다.

00 = 00000000
       ^
       U/L bit

flip 후

02 = 00000010

최종 Interface ID는 다음과 같다.

0250:79ff:fe66:6801

prefix가 2001:db8:a:a::/64라면 최종 IPv6 주소는 다음처럼 된다.

2001:db8:a:a:250:79ff:fe66:6801

왜 U/L bit를 flip할까?

MAC 주소의 U/L bit는 Universal/Local bit다.

MAC의 U/L bit
0 = Universally administered
1 = Locally administered

IPv6 Modified EUI-64에서는 이 의미가 반대로 해석된다. 그래서 IEEE MAC 주소의 U/L bit를 IPv6 Interface ID로 옮길 때 값을 뒤집는다.

IEEE MAC U/L bit와
IPv6 Modified EUI-64의 u bit 의미가 반대이기 때문에
U/L bit를 flip한다.

EUI-64는 학습과 시험에서는 매우 중요하지만, 실제 PC OS에서는 privacy 문제 때문에 기본으로 사용하지 않는 경우가 많다. MAC 주소 흔적이 IPv6 주소에 남으면 장비 추적이 쉬워질 수 있다.

5. RA Flag

RA는 Host에게 prefix, default gateway, 주소 자동 설정 방식을 알려주는 ICMPv6 메시지다. RA에서 자주 보는 flag는 다음과 같다.

Flag	위치	의미	Cisco 설정
M flag	RA Header	주소를 DHCPv6로 받아라.	`ipv6 nd managed-config-flag`
O flag	RA Header	DNS 같은 기타 정보를 DHCPv6로 받아라.	`ipv6 nd other-config-flag`
A flag	Prefix Information Option	이 prefix로 SLAAC 주소를 만들어라.	`ipv6 nd prefix ... no-autoconfig`로 끌 수 있음
L flag	Prefix Information Option	이 prefix를 on-link로 판단해라.	`ipv6 nd prefix ... no-onlink`로 끌 수 있음

RA Flag 조합에 따른 Host 동작은 다음처럼 정리할 수 있다.

조합	의미	Host 동작
A=1, M=0, O=0	SLAAC Only	RA prefix로 주소를 만들고 DHCPv6는 사용하지 않는다.
A=1, M=0, O=1	Stateless DHCPv6	주소는 SLAAC, DNS 같은 옵션은 DHCPv6로 받는다.
A=0, M=1, O=1	Stateful DHCPv6 Only	SLAAC 주소는 만들지 않고 DHCPv6로 주소와 옵션을 받는다.
A=1, M=1	SLAAC + Stateful DHCPv6 가능	SLAAC 주소와 DHCPv6 주소를 둘 다 가질 수 있다.

A flag와 M flag는 우선순위 관계가 아니라 독립적인 힌트다. A=1, M=1이면 Host가 SLAAC 주소와 DHCPv6 주소를 둘 다 만들 수 있다. Stateful DHCPv6만 사용하고 싶다면 A flag를 꺼야 한다.

6. Stateful DHCPv6와 Stateless DHCPv6

Stateful DHCPv6

Stateful DHCPv6는 DHCPv6 Server가 IPv6 주소를 직접 할당하고 lease를 관리하는 방식이다.

주소     : DHCPv6 Server가 할당
DNS      : DHCPv6 Server가 제공
Lease    : DHCPv6 Server가 관리
Gateway  : RA로 학습

Stateless DHCPv6

Stateless DHCPv6는 주소는 SLAAC으로 만들고 DNS, Domain Search List 같은 옵션만 DHCPv6로 받는 방식이다.

주소     : SLAAC
DNS      : DHCPv6
Lease    : DHCPv6 Server가 주소 lease 관리 안 함
Gateway  : RA로 학습

7. Cisco 설정 예시

SLAAC Only

RA Router는 prefix를 광고하고, Client는 RA를 받아 SLAAC 주소를 만든다.

R1, RA Router

ipv6 unicast-routing

interface e0/0
 ipv6 address 2001:db8:a:a::1/64
 no shutdown

Cisco Client

interface e0/0
 ipv6 address autoconfig
 no shutdown

Stateless DHCPv6

주소는 SLAAC으로 만들고, DNS 같은 기타 옵션만 DHCPv6로 받는다.

R1, RA Router + DHCPv6 Server

ipv6 unicast-routing

ipv6 dhcp pool DHCPV6-STATELESS
 dns-server 2001:db8:a:a::53
 domain-name example.com

interface e0/0
 ipv6 address 2001:db8:a:a::1/64
 ipv6 nd other-config-flag
 ipv6 dhcp server DHCPV6-STATELESS
 no shutdown

Cisco Client

interface e0/0
 ipv6 address autoconfig
 ipv6 dhcp client request dns-nameserver
 ipv6 dhcp client request domain-name
 no shutdown

Stateful DHCPv6

주소도 DHCPv6 Server가 할당한다. 이 경우 Client가 SLAAC 주소를 만들지 않게 하려면 A flag를 꺼주는 것이 좋다.

R1, RA Router + DHCPv6 Server

ipv6 unicast-routing

ipv6 dhcp pool DHCPV6-STATEFUL
 address prefix 2001:db8:a:a::/64
 dns-server 2001:db8:a:a::53
 domain-name example.com

interface e0/0
 ipv6 address 2001:db8:a:a::1/64
 ipv6 nd managed-config-flag
 ipv6 nd other-config-flag
 ipv6 nd prefix 2001:db8:a:a::/64 no-autoconfig
 ipv6 dhcp server DHCPV6-STATEFUL
 no shutdown

Cisco Client

interface e0/0
 ipv6 enable
 ipv6 address dhcp
 no shutdown

Cisco IOS에서 ipv6 address autoconfig는 SLAAC 주소 생성용이다. Stateful DHCPv6로 주소를 받으려면 Client 쪽에 ipv6 address dhcp를 설정해야 한다.

8. DHCPv6 Message 종류

Stateful DHCPv6의 기본 주소 할당 흐름은 다음과 같다.

Solicit -> Advertise -> Request -> Reply

DHCPv4 DORA와 비교하면 다음처럼 볼 수 있다.

DHCPv4	DHCPv6	의미
Discover	Solicit	Client가 Server를 찾는다.
Offer	Advertise	Server가 자신이 응답 가능함을 알린다.
Request	Request	Client가 특정 Server와 주소를 선택한다.
ACK	Reply	Server가 최종 응답한다.

DHCPv6 주요 Message Type은 다음과 같다.

번호	Message	의미
1	Solicit	Client가 DHCPv6 Server를 찾는다.
2	Advertise	Server가 Client에게 응답 가능함을 알린다.
3	Request	Client가 Server에게 주소/옵션을 요청한다.
4	Confirm	Client가 현재 주소가 해당 링크에서 유효한지 확인한다.
5	Renew	Client가 기존 lease 갱신을 요청한다.
6	Rebind	기존 Server 응답이 없을 때 다른 Server에게 갱신을 요청한다.
7	Reply	Server의 최종 응답이다.
8	Release	Client가 주소를 반환한다.
9	Decline	Client가 주소 중복 등을 이유로 주소 사용을 거부한다.
10	Reconfigure	Server가 Client에게 재설정을 요청한다.
11	Information-Request	주소 없이 옵션 정보만 요청한다. Stateless DHCPv6에서 중요하다.
12	Relay-Forward	Relay가 Client 메시지를 Server에게 전달한다.
13	Relay-Reply	Server가 Relay에게 응답한다.

9. DHCPv4와 DHCPv6의 차이

구분	DHCPv4	DHCPv6
초기 목적지	`255.255.255.255` broadcast	`ff02::1:2` multicast
Client 초기 주소	`0.0.0.0`	link-local address 사용
UDP Port	Client 68, Server 67	Client 546, Server 547
Client 식별	MAC, chaddr, Client Identifier	DUID, IAID
Default Gateway	DHCP Option 3	RA로 학습
Relay 방식	giaddr 사용	Relay-Forward / Relay-Reply 사용

DHCPv6는 Client가 global IPv6 주소를 받기 전에도 link-local 주소를 이미 가지고 있다. 그래서 Solicit 이후 Advertise부터 Client link-local 주소로 unicast가 가능하다.

DHCPv6 Solicit
Src IPv6 : Client link-local
Dst IPv6 : ff02::1:2
UDP      : 546 -> 547

DHCPv6 Advertise
Src IPv6 : Server address
Dst IPv6 : Client link-local
UDP      : 547 -> 546

10. DHCPv6 Relay 동작 방식

Client와 DHCPv6 Server가 같은 링크에 없으면 DHCPv6 Relay가 필요하다. DHCPv4 Relay는 giaddr가 핵심이었지만, DHCPv6 Relay는 Client 메시지를 Relay-Forward 메시지 안에 넣어 Server에게 전달한다.

Client -> Relay
Message : Solicit
Src     : Client link-local
Dst     : ff02::1:2
UDP     : 546 -> 547

Relay -> Server
Message : Relay-Forward
UDP     : 547 -> 547

Server -> Relay
Message : Relay-Reply
UDP     : 547 -> 547

Relay -> Client
Message : Advertise or Reply
Dst     : Client link-local
UDP     : 547 -> 546

DHCPv6 Relay-Forward에는 다음 정보가 중요하다.

필드	의미
link-address	Client가 위치한 링크를 Server가 판단할 수 있게 하는 주소다.
peer-address	Client의 link-local address다.
Relay Message Option	Client가 보낸 원래 DHCPv6 메시지가 들어간다.

Cisco DHCPv6 Relay 예시

R1, Client-facing Relay Router

ipv6 unicast-routing

interface e0/0
 ipv6 address 2001:db8:a:a::1/64
 ipv6 nd managed-config-flag
 ipv6 nd other-config-flag
 ipv6 nd prefix 2001:db8:a:a::/64 no-autoconfig
 ipv6 dhcp relay destination 2001:db8:d:d::2
 no shutdown

interface e0/1
 ipv6 address 2001:db8:d:d::1/64
 no shutdown

R2, DHCPv6 Server

ipv6 unicast-routing

ipv6 dhcp pool DHCPV6-STATEFUL
 address prefix 2001:db8:a:a::/64
 dns-server 2001:db8:d:d::2
 domain-name example.com

interface e0/0
 ipv6 address 2001:db8:d:d::2/64
 ipv6 dhcp server DHCPV6-STATEFUL
 no shutdown

ipv6 route 2001:db8:a:a::/64 2001:db8:d:d::1

11. 네트워크 엔지니어 관점의 핵심

IPv6 주소는 보통 prefix 64bit와 interface ID 64bit로 구성된다.
SLAAC은 RA prefix와 Host가 만든 Interface ID로 주소를 생성한다.
EUI-64는 Interface ID 생성 방식 중 하나일 뿐이며, Windows는 기본적으로 random/stable random 방식을 사용한다.
RA의 M/O flag는 DHCPv6 사용 여부를 알려주고, A flag는 SLAAC 가능 여부를 결정한다.
Stateful DHCPv6에서도 default gateway는 DHCPv6가 아니라 RA로 학습한다.
Cisco Router를 Client로 쓸 때 autoconfig는 SLAAC, ipv6 address dhcp는 Stateful DHCPv6용이다.
DHCPv6는 broadcast를 사용하지 않고 multicast와 unicast를 사용한다.
DHCPv6 Relay는 DHCPv4의 giaddr 방식이 아니라 Relay-Forward / Relay-Reply 구조를 사용한다.

12. 한 줄 정리

IPv6 주소 자동 설정은 RA, SLAAC, DHCPv6가 함께 만든다.

RA는 prefix와 default gateway, DHCPv6 사용 여부를 알려주고,
SLAAC은 그 prefix로 Host가 스스로 주소를 만들게 하며,
DHCPv6는 주소를 중앙에서 관리하거나 DNS 같은 추가 정보를 제공한다.

DHCPv6 Relay는 Client와 Server가 다른 링크에 있을 때
Client 메시지를 Relay-Forward로 감싸 Server에게 전달한다.

참고 RFC

이 글의 기본 개념은 RFC 4291 IPv6 Addressing Architecture, RFC 4862 IPv6 Stateless Address Autoconfiguration, RFC 8415 DHCP for IPv6, RFC 7217 Stable Privacy Addresses를 기준으로 정리했다.

DHCP에 대해서

성민 | 네트워크 생존노트 — Tue, 9 Jun 2026 14:42:37 +0900

DHCP에 대하여

DHCP를 공부할 때 가장 많이 외우는 단어는 DORA다. Discover, Offer, Request, ACK. 하지만 실무에서 중요한 것은 순서를 외우는 것보다 각 메시지가 어떤 L2/L3/UDP/BOOTP/DHCP Option 구조를 갖는지 읽을 수 있는 능력이다.

이번 글은 아래 DHCP Relay 토폴로지를 기준으로 DHCP 동작을 정리한다. Host A, B, C는 서로 다른 VLAN에 있고, R1은 각 VLAN의 Default Gateway이자 DHCP Relay Agent다. R2는 DHCP Server이자 DNS Server 역할을 한다.

DHCP Relay 테스트 토폴로지

1. 테스트 토폴로지

구성은 다음과 같다. Host A, B, C는 같은 스위치에 연결되어 있지만 각각 다른 VLAN에 속한다. R1은 Router-on-a-stick 형태로 subinterface를 사용하며, 각 subinterface에 ip helper-address 10.0.0.2가 설정되어 있다.

구간	인터페이스	역할
Host A	Host A `e0/0` - SW1 `e0/0`	VLAN 10, `192.168.10.0/24`
Host B	Host B `e0/0` - SW1 `e0/1`	VLAN 20, `192.168.20.0/24`
Host C	Host C `e0/0` - SW1 `e0/2`	VLAN 30, `192.168.30.0/24`
SW1 - R1	SW1 `e0/3` - R1 `e0/0`	802.1Q Trunk
R1 subinterface	`e0/0.10`, `e0/0.20`, `e0/0.30`	각 VLAN의 Default Gateway
R1 - R2	R1 `e0/1` - R2 `e0/0`	`10.0.0.0/24` Server 구간

R1 subinterfaces

interface e0/0.10
 encapsulation dot1Q 10
 ip address 192.168.10.1 255.255.255.0
 ip helper-address 10.0.0.2

interface e0/0.20
 encapsulation dot1Q 20
 ip address 192.168.20.1 255.255.255.0
 ip helper-address 10.0.0.2

interface e0/0.30
 encapsulation dot1Q 30
 ip address 192.168.30.1 255.255.255.0
 ip helper-address 10.0.0.2

R1 e0/1 : 10.0.0.1/24
R2 e0/0 : 10.0.0.2/24

ip helper-address는 Client VLAN에서 발생한 DHCP broadcast를 DHCP Server에게 전달하기 위한 설정이다. 이 토폴로지에서는 R1이 DHCP Relay Agent가 되고, R2가 DHCP Server가 된다.

2. DHCP 패킷을 볼 때의 기본 구조

DHCP는 UDP 위에서 동작한다. DHCP 메시지를 분석할 때는 단순히 "Discover냐 Offer냐"만 볼 것이 아니라 다음 구조를 순서대로 보는 것이 좋다.

Ethernet Header
IPv4 Header
UDP Header
BOOTP Fixed Header
DHCP Options

구간	확인할 필드	확인 이유
Ethernet	Src MAC, Dst MAC	현재 L2 구간에서 누가 누구에게 프레임을 보내는지 확인한다.
IPv4	Src IP, Dst IP	Client broadcast인지, Relay가 Server에게 보내는 unicast인지 확인한다.
UDP	Port 67, 68	Client와 Server 사이인지, Relay와 Server 사이인지 확인한다.
BOOTP	`xid`, `chaddr`, `giaddr`, `hops`	Client 식별, Relay 여부, Client subnet 정보를 확인한다.
DHCP Options	Option 53, 50, 51, 54, 61	Message Type, 요청 IP, Lease Time, Server Identifier, Client Identifier를 확인한다.

3. DHCP DORA 흐름

Discover

Client가 DHCP Server를 찾는다. 아직 IP가 없기 때문에 Client VLAN 안에서는 broadcast로 시작한다.

Offer

Server가 Client에게 사용할 수 있는 IP 주소를 제안한다. 제안 IP는 BOOTP의 yiaddr에 들어간다.

Request

Client가 특정 Server의 Offer를 선택하고, 해당 IP를 사용하겠다고 요청한다.

ACK

Server가 최종 승인한다. ACK 이후 Client는 IP, Gateway, DNS 등의 정보를 적용한다.

흔히 DORA는 모두 broadcast라고 말하지만 정확히는 상황에 따라 다르다. Host A가 Client VLAN 안에서 처음 보내는 Discover는 broadcast다. 하지만 R1이 이 Discover를 R2에게 전달할 때는 broadcast가 아니라 unicast DHCP 메시지가 된다.

4. DHCP Discover

Host A가 VLAN 10에서 보내는 Discover

Host A는 아직 IP 주소가 없다. 따라서 Source IP는 0.0.0.0이고, Destination IP는 255.255.255.255다. 이 프레임은 VLAN 10 broadcast로 전송되고, SW1을 거쳐 R1의 e0/0.10 subinterface에 도착한다.

Host A -> VLAN 10 broadcast

Ethernet
Src MAC : Host A MAC
Dst MAC : ff:ff:ff:ff:ff:ff

IPv4
Src IP  : 0.0.0.0
Dst IP  : 255.255.255.255

UDP
Src Port: 68
Dst Port: 67

BOOTP
op      : 1, BOOTREQUEST
hops    : 0
xid     : Client가 생성한 Transaction ID
ciaddr  : 0.0.0.0
yiaddr  : 0.0.0.0
siaddr  : 0.0.0.0
giaddr  : 0.0.0.0
chaddr  : Host A MAC

DHCP Options
53      : DHCP Discover
55      : Parameter Request List
61      : Client Identifier, 있을 수 있음
12      : Host Name, 있을 수 있음

R1이 R2에게 Relay하는 Discover

R1은 VLAN 10에서 DHCP Discover를 받으면, ip helper-address 10.0.0.2 설정에 따라 DHCP Server인 R2에게 메시지를 전달한다. 이때 R1은 DHCP Relay Agent로 동작한다.

R1 DHCP Relay -> R2 DHCP Server

Ethernet
Src MAC : R1 e0/1 쪽 MAC
Dst MAC : R2 e0/0 쪽 MAC

IPv4
Src IP  : 구현 또는 설정에 따라 달라질 수 있음
          예: 192.168.10.1 또는 10.0.0.1
Dst IP  : 10.0.0.2

UDP
Src Port: 67
Dst Port: 67

BOOTP
op      : 1, BOOTREQUEST
hops    : 1
xid     : Host A가 만든 xid 유지
giaddr  : 192.168.10.1
chaddr  : Host A MAC 유지

DHCP Server가 어느 pool에서 IP를 줄지 판단할 때 가장 중요한 값은 giaddr다. 이 예제에서 giaddr = 192.168.10.1이면 Server는 VLAN 10 Client에게 줄 주소를 192.168.10.0/24 pool에서 선택한다.

여기서 중요한 점은 Client의 MAC 주소가 Relay와 Server 사이 Ethernet Header의 Source MAC에 존재하지 않는다는 것이다. Relay와 Server 사이 프레임은 R1이 새로 만든 프레임이다. 실제 Client MAC은 BOOTP의 chaddr와 DHCP Client Identifier에 남아 있다.

5. DHCP Offer

R2는 Discover를 보고 Host A에게 줄 IP를 제안한다. 제안된 IP 주소는 DHCP Option이 아니라 BOOTP Header의 yiaddr 필드에 들어간다.

R2 DHCP Server -> R1 DHCP Relay

UDP
Src Port: 67
Dst Port: 67

BOOTP
op      : 2, BOOTREPLY
xid     : Discover의 xid와 동일
yiaddr  : Host A에게 제안하는 IP
giaddr  : 192.168.10.1
chaddr  : Host A MAC

DHCP Options
53      : DHCP Offer
54      : DHCP Server Identifier = 10.0.0.2
51      : IP Address Lease Time
1       : Subnet Mask
3       : Default Gateway
6       : DNS Server

R2는 giaddr가 0이 아니므로 Offer를 Client에게 직접 보내지 않고 Relay Agent인 R1에게 보낸다. 이후 R1은 VLAN 10 쪽으로 Offer를 다시 전달한다.

R1 DHCP Relay -> Host A

Broadcast로 전달하는 경우:
  Ethernet Dst MAC : ff:ff:ff:ff:ff:ff
  IP Dst           : 255.255.255.255

Unicast로 전달하는 경우:
  Ethernet Dst MAC : chaddr의 Host A MAC
  IP Dst           : yiaddr, 제안된 Client IP

6. DHCP Request

Host A는 R2의 Offer를 선택하면 DHCP Request를 보낸다. 이때 Option 50에는 요청하는 IP가 들어가고, Option 54에는 선택한 DHCP Server Identifier가 들어간다.

Host A -> VLAN 10 broadcast

IPv4
Src IP  : 0.0.0.0
Dst IP  : 255.255.255.255

UDP
Src Port: 68
Dst Port: 67

DHCP Options
53      : DHCP Request
50      : Requested IP Address
54      : DHCP Server Identifier = 10.0.0.2
61      : Client Identifier, 있을 수 있음

Request가 broadcast로 나가는 이유는 여러 DHCP Server가 Offer를 보냈을 때, 선택받은 Server와 선택받지 못한 Server 모두에게 Client의 선택 결과를 알리기 위해서다. 이 토폴로지에서는 R1이 이 Request도 다시 Relay하여 R2에게 전달한다.

7. DHCP ACK

R2는 Host A의 Request를 승인하면 DHCP ACK를 보낸다. ACK에는 최종 할당 IP와 함께 subnet mask, default gateway, DNS, lease time 등이 포함된다.

R2 DHCP Server -> R1 DHCP Relay -> Host A

BOOTP
op      : 2, BOOTREPLY
xid     : Request와 매칭되는 xid
yiaddr  : 최종 할당 IP
giaddr  : 192.168.10.1
chaddr  : Host A MAC

DHCP Options
53      : DHCP ACK
54      : DHCP Server Identifier = 10.0.0.2
51      : IP Address Lease Time
58      : Renewal Time, T1
59      : Rebinding Time, T2
1       : Subnet Mask
3       : Default Gateway
6       : DNS Server

ACK를 받은 Host A는 이제 DHCP lease를 획득한 상태가 된다. 이후에는 할당받은 IP를 사용해서 일반 IP 통신을 할 수 있다.

8. Relay된 DHCP 메시지인지 판단하는 기준

DHCP 패킷이 Relay를 거쳤는지 판단할 때 가장 먼저 볼 필드는 giaddr와 hops다.

필드	Relay되지 않은 Client Discover	Relay된 Discover
`giaddr`	`0.0.0.0`	Client VLAN의 Gateway IP, 예: `192.168.10.1`
`hops`	`0`	`1` 이상
UDP Port	`68 -> 67`	`67 -> 67`
Ethernet Source MAC	Client MAC	Relay 장비 MAC
`chaddr`	Client MAC	Client MAC 유지

Relay와 Server 사이에서 캡처한 DHCP Discover의 Ethernet Source MAC은 Client MAC이 아니다. Client MAC은 BOOTP Header의 chaddr와 DHCP Option 61 Client Identifier를 봐야 한다.

9. 실제 Relay된 Discover 패킷 예시

DHCP Server가 Relay 장비로부터 받은 Discover를 분석하면 다음과 같은 형태가 된다.

Ethernet
Dst MAC : aa:bb:cc:00:f0:00
Src MAC : aa:bb:cc:00:e0:10

IPv4
Src IP  : 192.168.10.1
Dst IP  : 10.0.0.2

UDP
Src Port: 67
Dst Port: 67

BOOTP
op      : 1, BOOTREQUEST
hops    : 1
xid     : 0x8167702f
flags   : 0x0000
ciaddr  : 0.0.0.0
yiaddr  : 0.0.0.0
siaddr  : 0.0.0.0
giaddr  : 192.168.10.1
chaddr  : 00:50:79:66:68:01

DHCP Options
Option 53 : 1, DHCP Discover
Option 12 : Host Name = VPCS
Option 61 : Client Identifier = 01 00 50 79 66 68 01

이 패킷은 giaddr가 0.0.0.0이 아니고, hops가 1이며, UDP Port가 67 -> 67이다. 따라서 Client가 직접 Server에게 보낸 Discover가 아니라 Relay Agent가 DHCP Server에게 전달한 Discover라고 판단할 수 있다.

10. 여러 Client가 동시에 DHCP를 요청하면?

Host A, B, C가 동시에 Discover를 보낼 수 있다. 모두 broadcast로 시작하기 때문에 헷갈릴 것처럼 보이지만, DHCP에는 Client와 transaction을 구분하기 위한 값이 있다.

Host A
xid    : 0xaaaa1111
chaddr : Host A MAC
giaddr : 192.168.10.1

Host B
xid    : 0xbbbb2222
chaddr : Host B MAC
giaddr : 192.168.20.1

Host C
xid    : 0xcccc3333
chaddr : Host C MAC
giaddr : 192.168.30.1

R2는 giaddr를 보고 어떤 VLAN의 pool을 사용할지 결정하고, xid, chaddr, Client Identifier를 보고 각 Client의 요청을 구분한다.

11. DHCP Message Type 전체 정리

DHCP에는 DORA만 있는 것이 아니다. 운영 환경에서는 Decline, NAK, Release, Inform도 자주 만난다.

Option 53 값	Message Type	방향	의미
1	DHCPDISCOVER	Client -> Server	Client가 DHCP Server를 찾는다.
2	DHCPOFFER	Server -> Client	Server가 사용할 수 있는 IP를 제안한다.
3	DHCPREQUEST	Client -> Server	Client가 특정 IP와 Server를 선택하거나 lease 갱신을 요청한다.
4	DHCPDECLINE	Client -> Server	Client가 제안받은 IP가 이미 사용 중이라고 판단했을 때 Server에게 알린다.
5	DHCPACK	Server -> Client	Server가 IP 사용을 최종 승인한다.
6	DHCPNAK	Server -> Client	Server가 Client의 요청을 거절한다.
7	DHCPRELEASE	Client -> Server	Client가 더 이상 해당 IP를 사용하지 않겠다고 반환한다.
8	DHCPINFORM	Client -> Server	Client가 IP는 이미 가지고 있고, DNS 같은 DHCP Option 정보만 요청한다.

Lease는 DHCP Message Type이 아니다

DHCP Lease는 메시지 종류가 아니라 IP를 사용할 수 있는 임대 시간이다. Lease 관련 값은 DHCP Option으로 전달된다.

Option 51 : IP Address Lease Time
Option 58 : Renewal Time, T1
Option 59 : Rebinding Time, T2

12. 네트워크 엔지니어 관점에서 중요한 이유

DHCP 장애는 단순히 "IP를 못 받아요"로 끝나지 않는다. 실제 현장에서는 Client VLAN, Switch trunk, Router subinterface, DHCP Relay, DHCP Server pool, routing, firewall policy가 모두 얽힐 수 있다.

Host가 Discover를 보내는지 확인한다.
R1이 VLAN별 giaddr를 넣어 R2에게 Relay하는지 확인한다.
R2가 giaddr에 맞는 pool에서 Offer를 만드는지 확인한다.
R1이 Offer와 ACK를 다시 Client VLAN으로 전달하는지 확인한다.
Client가 Request를 보내고 ACK를 받는지 확인한다.
NAK, Decline, Release가 보이면 DHCP 상태 관점에서 해석한다.

결국 DHCP 분석의 핵심은 DORA 순서를 외우는 것이 아니라, 패킷 안의 필드가 어떤 장비의 의사결정에 사용되는지 이해하는 것이다. xid는 transaction을 구분하고, chaddr와 Client Identifier는 Client를 식별하며, giaddr는 Server가 어느 subnet pool을 사용할지 결정하게 한다.

13. 한 줄 정리

DHCP Relay 환경에서는 Client의 broadcast Discover가 R1에서 unicast Discover로 바뀌어 R2에게 전달된다.

이때 Ethernet Header는 Relay와 Server 사이의 새 프레임으로 다시 만들어지지만,
xid, chaddr, Client Identifier는 Client 식별을 위해 유지된다.

Server는 giaddr를 보고 어느 VLAN의 pool에서 IP를 줄지 결정한다.

참고 RFC

DHCP 기본 동작은 RFC 2131 Dynamic Host Configuration Protocol과 RFC 1542 BOOTP Relay Agent 동작을 기준으로 정리했다.

과연 두 Host는 통신이 될까?

성민 | 네트워크 생존노트 — Tue, 9 Jun 2026 09:27:29 +0900

과연 두 Host는 통신이 가능할까?

같은 스위치에 연결된 두 Host가 있다. IP 주소도 둘 다 192.168.0.x로 비슷해 보인다. 그런데 두 장비의 subnet mask가 조금 다르다면, 과연 두 Host는 정상적으로 통신할 수 있을까?

Quiz

다음과 같은 네트워크가 있다고 가정해보자. Host A, Host B, Router는 모두 같은 스위치에 연결되어 있다.

Host A  : 192.168.0.10 /26
Host B  : 192.168.0.20 /28
Router  : 192.168.0.21 /26
Gateway : 192.168.0.21

Host A에서 Host B로 ping을 보내면, 과연 통신은 성공할까?

A. 같은 스위치에 있으므로 당연히 통신된다.

B. subnet mask가 다르므로 절대 통신되지 않는다.

정답은 단순히 "된다" 또는 "안 된다"로 끝나지 않는다. 이 글에서는 IPv4 주소를 2진수 비트맵으로 읽는 방법부터 시작해, Host A와 Host B가 서로를 어떻게 다르게 판단하는지, 그리고 그 결과 Router forwarding과 ICMP Redirect가 왜 발생하는지 순서대로 정리한다.

핵심 요약 같은 스위치에 연결된 두 장비라도 서브넷 마스크가 다르면 서로를 같은 네트워크로 판단하지 않을 수 있다. 이 글은 192.168.0.10/26 Host A와 192.168.0.20/28 Host B의 ping 흐름을 기준으로 ARP, ICMP Redirect, 라우팅, 포워딩, TTL 감소가 실제로 어떤 순서로 발생하는지 설명한다.

0. IPv4 주소는 비트맵이다

IPv4 주소는 사람이 읽기 쉽게 192.168.0.10처럼 10진수 네 덩어리로 표시한다. 하지만 실제 장비가 보는 IPv4 주소는 32개의 0과 1로 이루어진 값이다.

192.168.0.10

192      .168      .0        .10
11000000 .10101000 .00000000 .00001010

이 32비트 중 앞쪽 일부는 네트워크 영역이고, 뒤쪽 일부는 호스트 주소 영역이다. 어디까지를 네트워크로 볼지는 서브넷 마스크 또는 prefix length가 결정한다. 예를 들어 /26은 앞의 26비트를 네트워크 영역으로 본다는 뜻이다.

192.168.0.10

11000000

10101000

00000000

00001010

Network 영역, /26 기준 앞 26비트 Host 주소 영역, 나머지 6비트

비전공자 입장에서 핵심은 이 정도로 잡으면 된다. IP 주소는 단순한 숫자 문자열이 아니라 32칸짜리 비트맵이고, 서브넷 마스크는 그 비트맵을 어디에서 자를지 정하는 기준이다. 장비는 이 기준으로 "상대방이 내 로컬 네트워크 안에 있는가?"를 판단한다.

1. 테스트 토폴로지: 서브넷이 조금 다를 때

테스트 환경은 단순하다. Host A, Host B, Router가 모두 같은 스위치에 연결되어 있다. 기본 게이트웨이는 두 호스트 모두 Router인 192.168.0.21로 설정되어 있다.

장비	IP 설정	자신이 인식하는 로컬 네트워크	기본 게이트웨이
Host A	`192.168.0.10/26`	`192.168.0.0 ~ 192.168.0.63`	`192.168.0.21`
Host B	`192.168.0.20/28`	`192.168.0.16 ~ 192.168.0.31`	`192.168.0.21`
Router	`192.168.0.21/26`	`192.168.0.0 ~ 192.168.0.63`	-

이 구성은 정상적인 설계가 아니라 테스트를 위한 의도적인 서브넷 마스크 불일치 구성이다. 실무에서는 같은 L2 세그먼트의 호스트들이 서로 다른 방식으로 네트워크를 판단하게 되어 장애의 원인이 될 수 있다.

1-1. Host A와 Host B의 서브넷 판단이 다르다

먼저 Host A 입장에서 보자. Host A는 192.168.0.10/26이므로 자신의 로컬 네트워크를 192.168.0.0/26으로 판단한다. 이 범위에는 192.168.0.20이 포함된다.

Host A 기준
Local network: 192.168.0.0/26
Range        : 192.168.0.0 ~ 192.168.0.63

Destination  : 192.168.0.20
판단          : 같은 네트워크
동작          : Host B의 MAC으로 직접 전송

반대로 Host B 입장에서 보면 상황이 달라진다. Host B는 192.168.0.20/28이므로 자신의 로컬 네트워크를 192.168.0.16/28로 판단한다. 이 범위는 192.168.0.16 ~ 192.168.0.31이다. 따라서 192.168.0.10은 Host B 기준에서는 다른 네트워크다.

Host B 기준
Local network: 192.168.0.16/28
Range        : 192.168.0.16 ~ 192.168.0.31

Destination  : 192.168.0.10
판단          : 다른 네트워크
동작          : 기본 게이트웨이 192.168.0.21로 전송

핵심은 이것이다. 같은 스위치에 연결되어 있어도 각 호스트의 서브넷 마스크가 다르면 "상대방이 같은 네트워크인가?"에 대한 판단이 서로 달라질 수 있다.

1-2. Host A에서 Host B로 Ping을 보내면

이제 Host A에서 Host B로 ping을 보낸 상황을 순서대로 보자.

Step 1 Host A가 ARP로 Host B의 MAC 주소를 찾는다.

Host A는 192.168.0.20을 같은 네트워크로 판단했기 때문에 Router에게 보내지 않는다. 대신 "192.168.0.20의 MAC 주소가 누구냐?"를 묻는 ARP Request를 같은 L2 세그먼트에 브로드캐스트한다.

ARP Request

Ethernet src : Host A MAC
Ethernet dst : ff:ff:ff:ff:ff:ff
ARP Sender IP: 192.168.0.10
ARP Target IP: 192.168.0.20

의미:
Who has 192.168.0.20?
Tell 192.168.0.10

Host B는 자신의 IP를 묻는 ARP Request를 보고 ARP Reply를 보낸다. 이 응답을 받은 Host A는 ARP Cache에 192.168.0.20 -> Host B MAC을 저장한다.

ARP Reply

Ethernet src : Host B MAC
Ethernet dst : Host A MAC
ARP Sender IP: 192.168.0.20
ARP Sender MAC: Host B MAC

의미:
192.168.0.20 is at Host B MAC

ARP는 IPv4 패킷이 아니라 Ethernet 기반 주소 해석 프로토콜이다. 따라서 ARP Request/Reply에는 IP TTL 필드가 없다. 이미 Host A의 ARP Cache에 Host B의 MAC이 있다면 이 과정은 생략될 수 있다.

Step 2 Host A가 Echo Request를 보낸다.

Host A는 192.168.0.20을 같은 네트워크로 판단한다. ARP로 알아낸 Host B의 MAC 주소를 Ethernet 목적지로 사용해 Echo Request를 직접 보낸다.

Host A -> Host B

IP src  : 192.168.0.10
IP dst  : 192.168.0.20
MAC src : Host A
MAC dst : Host B
TTL     : 64

Step 3 Host B가 Echo Reply를 보낸다.

Host B는 응답의 목적지인 192.168.0.10을 자신의 로컬 네트워크 밖에 있다고 판단한다. 그래서 Echo Reply의 IP 목적지는 192.168.0.10으로 유지하지만, Ethernet 목적지 MAC은 Router의 MAC으로 설정한다.

Host B -> Router

IP src  : 192.168.0.20
IP dst  : 192.168.0.10
MAC src : Host B
MAC dst : Router
TTL     : 64

Step 4 Router가 Echo Reply를 Host A에게 포워딩한다.

Router는 목적지 IP 192.168.0.10을 보고 라우팅 테이블을 조회한다. 192.168.0.10은 Router의 directly connected 네트워크인 192.168.0.0/26 안에 있다. 따라서 Router는 이 패킷을 Host A에게 포워딩한다.

Router -> Host A

IP src  : 192.168.0.20
IP dst  : 192.168.0.10
MAC src : Router
MAC dst : Host A
TTL     : 63

Step 5 Router가 Host B에게 ICMP Redirect를 보낸다.

Router 입장에서는 패킷이 들어온 인터페이스와 나가는 인터페이스가 같다. Host A와 Host B가 같은 L2 세그먼트에 있으므로, Router는 Host B에게 "다음부터는 나에게 보내지 말고 Host A로 직접 보내라"는 의미의 ICMP Redirect를 보낸다.

Router -> Host B

ICMP Type : 5
Code      : 1, Redirect for host
Gateway   : 192.168.0.10

2. ICMP Redirect 메시지의 의미

ICMP Redirect는 "이 패킷을 버린다"는 의미가 아니다. Router는 이미 받은 Echo Reply를 Host A에게 정상적으로 포워딩한다. 동시에 Host B에게 더 좋은 경로를 알려준다.

Router의 판단

192.168.0.10은 내 directly connected 네트워크에 있다.
그런데 Host B와 Host A는 같은 L2 세그먼트에 있다.
Host B가 굳이 나를 거칠 필요가 없다.

따라서:
1. 기존 Echo Reply는 Host A에게 포워딩
2. Host B에게 ICMP Redirect 전송

Redirect 메시지 안에는 더 적절한 gateway 주소가 들어간다. 이 테스트에서는 Router가 Host B에게 192.168.0.10을 gateway로 알려준다. 의미는 다음과 같다.

Host B야,
192.168.0.10으로 갈 때는
나 192.168.0.21에게 보내지 말고
같은 L2 세그먼트에 있는 192.168.0.10으로 직접 보내라.

만약 Host B가 ICMP Redirect를 받아들인다면 이후에는 192.168.0.10으로 가는 임시 host route를 만들고, Host A의 MAC 주소를 사용해 직접 보낼 수 있다.

Redirect 반영 후 예상 흐름

Host B -> Host A

IP src  : 192.168.0.20
IP dst  : 192.168.0.10
MAC src : Host B
MAC dst : Host A
TTL     : 64

그런데 왜 Host B는 Host A의 MAC을 바로 쓰지 못할까?

ICMP Redirect를 받았다고 해서 Host B가 곧바로 Ethernet Destination MAC을 Host A의 MAC으로 바꿀 수 있는 것은 아니다. Redirect 메시지에는 MAC 주소가 들어 있지 않고, 더 좋은 next-hop의 IP 주소만 들어 있다.

ICMP Redirect가 알려주는 것
= 192.168.0.10으로 갈 때 더 좋은 gateway IP는 192.168.0.10이다.

ICMP Redirect가 알려주지 않는 것
= 192.168.0.10의 Ethernet MAC 주소

따라서 Host B가 Redirect를 실제로 사용하려면 다음 과정이 필요하다.

1. ICMP Redirect를 신뢰하고 받아들인다.
2. 192.168.0.10/32에 대한 임시 host route 또는 redirect cache를 만든다.
3. 192.168.0.10을 on-link next-hop으로 보고 ARP를 수행한다.
4. ARP Reply를 통해 Host A의 MAC 주소를 학습한다.
5. 그 다음 패킷부터 Destination MAC을 Host A MAC으로 설정한다.

그런데 이 상황에서 Host B가 192.168.0.10에 대해 ARP를 보내지 않는다면, 가장 먼저 봐야 할 이유는 Host B의 서브넷 판단이다. Host B의 /28 기준에서 192.168.0.10은 로컬 네트워크 밖의 주소다.

Host B 기준

Host B IP      : 192.168.0.20/28
Local network  : 192.168.0.16 ~ 192.168.0.31
Host A IP      : 192.168.0.10
판단            : 로컬 네트워크 밖

호스트는 목적지 IP가 자신의 로컬 네트워크 안에 있을 때만 그 목적지 IP에 대해 직접 ARP를 수행한다. 목적지 IP가 로컬 네트워크 밖이면 목적지의 MAC을 찾는 것이 아니라, 기본 게이트웨이의 MAC 주소를 사용한다.

로컬 목적지일 때
= 목적지 IP에 대해 ARP

원격 목적지일 때
= 기본 게이트웨이 IP에 대해 ARP
= Ethernet Destination MAC은 Gateway MAC

따라서 이 테스트에서 Host B가 192.168.0.10에 대해 ARP를 보내지 않는 것은 자연스러운 동작이다. Host B 입장에서는 192.168.0.10이 자기 네트워크 밖에 있으므로, Echo Reply를 보낼 때 Host A의 MAC이 아니라 기본 게이트웨이인 Router의 MAC을 목적지 MAC으로 사용한다.

정리하면, Host B가 Host A의 MAC을 목적지 MAC으로 지정하지 못하는 직접적인 이유는 192.168.0.10이 Host B의 /28 로컬 네트워크 밖에 있기 때문이다. Redirect를 받는 것과 Host A의 MAC을 아는 것은 같은 일이 아니다.

이 경우 Router를 지나지 않으므로 TTL은 64 그대로 유지된다. 반대로 Redirect가 계속 반복되고 TTL 63짜리 포워딩 패킷이 계속 보인다면, Host B가 Redirect를 실제 라우팅 결정에 반영하지 않는다고 해석할 수 있다.

3. 라우팅과 포워딩을 결정하는 기준

여기서 "라우팅을 할지, 포워딩을 할지"라는 표현은 실무 대화에서 자주 쓰이지만, 정확히는 라우팅과 포워딩은 서로 다른 단계다.

Routing
= 목적지 IP를 보고 어느 방향으로 보낼지 결정하는 과정

Forwarding
= 결정된 방향으로 실제 프레임 또는 패킷을 내보내는 과정

장비 종류에 따라 판단 기준은 다르다. L2 스위치는 MAC 주소를 기준으로 프레임을 전달하고, 라우터와 L3 스위치는 IP 목적지를 기준으로 라우팅 테이블을 조회한 뒤 포워딩한다.

장비	주요 판단 기준	처리 방식	TTL 변화
L2 스위치	Ethernet Destination MAC	MAC Address Table을 보고 같은 VLAN 안에서 프레임을 전달한다. IP 주소나 서브넷 마스크를 기준으로 경로를 고르지 않는다.	TTL 변경 없음
라우터	IP Destination Address	목적지 IP가 자기 자신이면 직접 처리하고, 자기 자신이 아니면 라우팅 테이블을 조회한다. 경로가 있으면 다음 홉에 맞게 새 L2 프레임을 만들어 포워딩한다.	포워딩 시 1 감소
L3 스위치	MAC + IP Destination Address	같은 VLAN 안에서는 L2 스위칭을 하고, VLAN 간 통신이나 Routed Port/SVI로 들어온 트래픽은 L3 라우팅을 수행한다. 실제 전달은 ASIC 기반 하드웨어 포워딩으로 처리되는 경우가 많다.	L3 라우팅 시 1 감소

이번 테스트에서 L2 스위치는 단지 프레임을 전달할 뿐이다. Host B가 Router의 MAC으로 Echo Reply를 보내면 스위치는 그 프레임을 Router 포트로 보낸다. 그 다음 Router가 목적지 IP 192.168.0.10을 보고 라우팅 테이블을 조회한 뒤 Host A 쪽으로 포워딩한다.

정리하면, L2 스위치는 MAC으로 전달하고, 라우터는 IP로 경로를 결정한다. L3 스위치는 두 역할을 모두 할 수 있지만, 어떤 기능이 동작하는지는 VLAN 내부 통신인지 VLAN 간/L3 인터페이스 통신인지에 따라 달라진다.

4. 라우팅할 때 프레임은 다시 만들어지고 TTL은 언제 바뀌는가

Router가 패킷을 포워딩할 때 Source IP와 Destination IP는 일반적으로 바뀌지 않는다. 대신 Ethernet 헤더는 다음 링크에 맞게 새로 작성된다.

Host B -> Router 구간
MAC src : Host B
MAC dst : Router
IP src  : 192.168.0.20
IP dst  : 192.168.0.10
TTL     : 64

Router -> Host A 구간
MAC src : Router
MAC dst : Host A
IP src  : 192.168.0.20
IP dst  : 192.168.0.10
TTL     : 63

라우터의 동작을 논리적인 순서로 표현하면 다음과 같다.

1. Ethernet 프레임 수신
2. Destination MAC이 자신의 MAC인지 확인
3. 기존 Ethernet 헤더 제거
4. IP 헤더의 Destination IP 확인
5. 라우팅 테이블 조회
6. TTL 1 감소
7. IP header checksum 재계산
8. 새로운 Ethernet 헤더 생성
9. 프레임 전송

여기서 TTL은 Layer 2 Ethernet 헤더가 아니라 Layer 3 IPv4 헤더 안에 있는 필드다. 라우터가 IP 패킷을 포워딩할 때 TTL은 1 감소하고, IPv4 header checksum도 다시 계산된다. 논리적으로는 라우팅 테이블 조회로 출력 방향이 결정된 뒤, 새로운 Ethernet 헤더를 붙이기 전에 IP 헤더의 TTL이 수정된다고 보면 된다.

정리

이번 글의 핵심은 IPv4 주소를 비트 단위로 이해하고, 그 비트 해석 차이가 실제 패킷 흐름에 어떤 영향을 주는지 보는 것이다.

IPv4 주소는 32비트 비트맵이며, 서브넷 마스크는 network 영역과 host 영역을 나누는 기준이다.
Host A는 192.168.0.20을 같은 네트워크로 보고 ARP로 Host B의 MAC 주소를 찾은 뒤 Echo Request를 직접 보낸다.
Host B는 192.168.0.10을 다른 네트워크로 보고 Echo Reply를 Router에게 보낸다.
Router는 Echo Reply를 Host A에게 포워딩하면서 Host B에게 ICMP Redirect를 보내 더 좋은 next-hop을 알려준다.
L2 스위치는 MAC 기준으로 프레임을 전달하고, 라우터는 IP 기준으로 라우팅 테이블을 조회한 뒤 포워딩한다. L3 스위치는 상황에 따라 L2 스위칭과 L3 라우팅을 모두 수행할 수 있다.
라우팅 과정에서 기존 Ethernet 헤더는 제거되고 새 Ethernet 헤더가 만들어진다. 이때 IP Source/Destination은 유지되지만 TTL은 1 감소한다.

실무에서 이런 현상은 단순한 ping 테스트에서도 장애 분석 포인트가 된다. 같은 스위치에 연결되어 있다고 해서 두 장비가 반드시 같은 네트워크로 인식하는 것은 아니다. IP 주소, 서브넷 마스크, 기본 게이트웨이, Ethernet MAC, TTL 변화를 함께 봐야 실제 패킷의 이동 경로를 정확히 이해할 수 있다.

Cisco icon images were extracted from the local Cisco Icons.pptx file for this study note.

[Data Center CCIE] - Fibre Channel - 2

성민 | 네트워크 생존노트 — Sun, 29 Mar 2026 17:27:51 +0900

Flow Control

Buffer-to-buffer credits.

FC fabric에서 packet lossless를 달성하기 위한 기술.

per hop basis로, link로 연결된 포트 간에 사용.

transmitter가 port login request를 보내면

receiver는 본인의 frame buffer size와

수용가능한 frame의 개수 정보가 담긴

accept frame을 응답한다.

transmitter는 본인의 table에

BB_credits 값과, BB_credits_CNT값을 저장한다.

transmitter는 frame을 하나 보낼 때 마다

BB_credits_CNT 값을 1씩 줄이고,

receiver가 receiver ready signal을 보내면 1씩 증가 시킨다.

BB_credits_CNT값이 0이 되면,

transmitter는 송신을 중단한다.

End-to-end credits

per hop basis가 아닌,

source - destination 간에 사용.

source port가,

ACK frame을 받는것과 상관없이

보낼 수 있는 최대의 frame 수.

이 credit은 N port login때 결정되고,

ACK frame을 받으면 다시 채워진다.(초기값으로 돌아온다)

Switched Fabric Initialization

위 내용에서, transmitter가 port login request를 보내는데

이 때, transmitter를 initiator라고 한다.

Initialization에 대해 살펴보자.

Principal switch selection.

Fabric내의 다른 switch들에게 domain ID를 분배하는 역할을 한다.

Fabric 마다 오직 한 대의 principal switch가 존재.

Run-time priority 값과 WWN 값을 기준으로

principal switch를 뽑는다.

run-time priority 라고 해서,

처음에는 running time이 제일 적은 switch라고 생각했는데

priority value가 따로 존재.

run time priority값이 낮을수록 우선순위가 높다.

default value는 128이고, 설정 가능 범위는 1~254.

다음으로는

WWN 값이 낮을수록 우선순위가 높다.

priority 값이 동일해서

WWN을 통해 principal switch가 된다면

principal switch의 priority 값은 2로 변경된다.

principal switch를 selection 하는 과정은 꽤나 복잡하다고 한다.

2대의 스위치가 처음 연결 되면, Link initialization phase 를 거친다.

1. Exchange Link Parameter (ELP)

BB credits, timer 정보들의 교환

2. Exchange Switch Capabilities (ESC)

3. Exchange Peer Parameters (EPP)

4. Exchange Fabric Parameters (EFP)

이 때, principal switch가 선택된다.

Domain ID distribution

domain ID는 FCID의 한 부분으로

Fabric 내에서 switch를 구분할 수 있는 ID다.

preferred / static 두 가지 type이 있다.

기본적으로 장비는 preferred mode에, ID가 0으로 되어있다고 한다.
이렇게 설정되어있다고 해서 ID를 0으로 사용하는 것이 아니라

0을 사용하겠다고 principal switch에게 request를 보낸다.

(만약 ID가 설정되어있지 않다면, (아마도 default 설정도 되어있는 것을 빼버린다면)

랜덤 ID 값으로 request를 보낸다)

principal switch는 요청받은 ID가 사용가능한지 불가능한지 판단.

만약 불가능하다면 다른 ID를 할당해서 보낸다.

static mode는 ID를 설정하고,

만약 요청한 이 ID에 대해 승인이 안 나면 다른 ID를 사용하는것이 아니라.

그냥 Fabric과 별개로 본인 혼자가 되어버린다. (고립되어버린다)

FCID allocation

Fabric reconfiguration

...

[Data Center CCIE] - Fibre Channel - 1

성민 | 네트워크 생존노트 — Wed, 25 Mar 2026 08:12:30 +0900

Computer data storage와 server를 연결하는데 주로 사용되는 data 전송 protocol.

발음은 프화이버 췌눨(/ˈfaɪbər ˈtʃænəl/).

Buffert-to-Buffer credit mechanism을 사용해서

loss 없는 전송을 구현한다고 한다.

기본적으로 광케이블에 사용되는데

Copper cable(UTP등)에서도

FCoE(Fibre Channel over Ethernet)이라는 protocol 통해 사용가능.

Topology

- Collapsed-core (single-tier)

Core Switch에, storage device와 server (host)들이 함께 연동되어있는 구조.

Core Switch의 포트를 최대한 활용한다는 장점이 있지만 규모적으로 한계가있다.

그래서 비교적 규모가 작은 곳에서 사용한다.

- Core-edge (two-tier)

Core Switch에는 storage device가,

Edge Switch에는 server(host)가 연동되는 구조.

Fan out과 oversubscription에 대한 내용이 나온다.

Core에 40GB 속도를 지원하는 1개의 포트에 storage가 연동되고,

10GB 속도를 지원하는 8개의 포트에 server(host)가 연동이 된다면

각 server에서 10GB 대역폭의 traffic을 발생시키면

결국 Core로 가는 것은 40GB가 한계이기 때문에

40GB의 traffic에 대해서는 normal하게 핸들링이 안된다.

이것을 oversubscription이라고 하는 듯.

Fan out은,

Core Switch나 Edige Switch에서

여러 장비들을 연동함으로써 퍼뜨려지는 방식을 의미하는 듯하다.

- Edge-core-egde (three-tier)

core-edge 구조에서, storage device가 더 늘어나 core switch의 포트로는

수용이 안 될 대, storage device 쪽에도 edge switch를 배치한 구조.

Port Type

일단 지금으로써는 종류가 너무 많고,

각 포트 타입에 대한 설명을 읽었을 때

크게 와닿지 않아서 나중에 다시 정리해야 할 듯하다.

종류만 열거.

TNP

Auto

BGP route summarization

성민 | 네트워크 생존노트 — Tue, 10 Feb 2026 17:50:23 +0900

2026년 2월 10일 07:30 도착

BGP에서는 summarization을 aggregation이라고 하는듯.

route aggregation을 설정한 라우터에서

해당 aggregation된 route에 대해서는 next-hop을 Null0로 하여

loop를 방지한다고 하는데, 왜 그럴까.

일단 route aggregation을 하면 BGP 테이블에

해당 prefix가 광고가 되고,

본인의 Table에 있으면, RIB에도 해당 route가 설치가 된다.

BGP table에서 next hop이 본인인데,

172.16.1.0처럼 connected된 interface도 없는

그런 aggregation 적용된 경로는 interface도 없고...

일단 첫 번째 이유는 이거 인 것 같다.

조금 더 구조적인 부분을 고려해보자.

이런 구조에서,,

R1도 172.16.0.0 / 16 으로 aggregation을 하고,

R3도 172.16.0.0 / 16 으로 aggregation을 한다면,

만약 R1 R3에서,

본인이 aggregatino한 대역에 대해서 Null0로 설정하지 않는상황에서

R1에서, 172.16.10.5로 ping을 보낸다고 가정을 하면

R1 -> R3 -> R1 -> R3 ...

이렇게 loop가 발생할 것이다...

그래서 Null0 로 설정하는 것 같다.

route aggregation을 하면,

기본적으로 aggregation 된 prefix와, 해당 prefix의 component가 되는 대역들이 전부 advertisement 된다.

aggregation prefix만 광고하려면,

summary-only 옵션을 줘야한다.

특이사항으로, 만약

R1 - R2 - R3 이런 구조에서

R2에서 aggregation을 한다면,

R1에서 받은 component의 AS_PATH attribute를 무시하고,

R2에서 새로 만든 prefix로 인식하게 된다.

그래서 R3에서는 AS_PATH가 R2밖에 없다.

component prefix의 AS_PATH를 유지하는 옵션이

AS_SET이다.

BGP에서 prefix filtering을 하는 4가지 방법.

prefix filtering은 outbound / inbound 2방향에서 할 수 있다.

1. distribute list

이건 ACL을 이용하는건데,

ACL의 source부분은 network portion을 destination 부분은 mask 부분을 나타냄.

2. prefix list

이건,,, prefix list를 어디서 본 것 같긴한데,,

다시 한 번 봐야겠다.

ip prefix-list prefix-list name [seq sequence-number] {permit | deny} high-order-bit-pattern/high-order-bit-count [ge ge-value] [le le-value].

high-order-bit-count < ge-value <= le-value

ip perfix-list RFC1918 seq 10 permit 10.0.0.0/8 le 32 같은 경우에,

10.X.X.X 대역에 prefix가 32보다 작은 것들,,

그런데,, prefix가 le 32이면,, 모든 prefix를 포함하는건가??

ge 16 le 20 이면, prefix가 16 ~ 20인 거라고 생각이 되는데

prefix는 기본적으로 high-order-bit-count ~ le-value 까지 또는 ge ~ le value 까지 인듯하다.

BGP

성민 | 네트워크 생존노트 — Thu, 5 Feb 2026 17:52:24 +0900

이틀전에, 고객의 내부 라우터와 SP의 라우터가 eBGP session을 맺는 경우는 어떻게 해야하는가에 대한 의문,

eBGP는 기본적으로 TTL이 1로 설정되어서 multi hop으로 맺는것이 기본적으로 안 된다는 것을 알게 되었다.

물론, TTL 설정을 바꿔서 multi hop eBGP session을 맺을 수도 있겠지만,

기본적으로 eBGP는 direct 연결된 peer끼리 맺는 것을 추천하는 것 같다.

현재 상황에서,

R2는 10.34.1.4 reachability 못하기 때문에, R2의 BGP 테이블에는 있으나 라우팅 테이블에 등록은 안됨.

근데 갑자기 헷갈리는게,

iBGP가 광고한거는 internal AS에서 다시 광고 안 한다고 했는데,,

"iBGP 가 광고한거"의 기준이 iBGP가 가진 prefix를 advertisement 할 때의 이야기인지,

eBGP로 받은 prefix를 iBGP 내부로 advertisement 할 때의 이야기인지 헷갈린다.

이게 왜 헷갈렸나면,, 교재는 에서는 4대로 예시를 들고있는데

나는 좀 더 사용해서 헷갈렸다.

1,2,3이 65100

4,5,6이 65200

7이 65300

AS를 가지고 있다.

loopback ip는 자기 번호 ex)1.1.1.1 2.2.2.2 이렇게임.

4,5,6이 full mesh iBGP 맺고있는거를 깜빡하고

4번에서 4.4.4.4를 bgp network 명령어로 광고를 했는데.
왜 6번에서도 1.1.1.1이랑 4.4.4.4가 보이지?

iBGP의 peer가 advertisement 한거는 아예 보이지 않아야 하는데...

생각해보니 4번과 6번도 iBGP peer 를 맺고 있었다.

next-hop self

기능...

만약에,,,

eBGP로부터 200개의 prefix 정보를 받고, 그거를 iBGP peer에게 전달해주면

개는 next-hop reachability문제를 해결하기 위해

IGP를 사용하거나

또는

BGP network 명령어로 200개의 prefix정보를 하나씩 다 입력해서

iBGP에게 넘겨줘야 할 것이다.

매우 비효율적이 될 것이다...

그런데 eBGP에게 받은 prefix를 iBGP peer에게 전달해줄 때,

eBGP로 부터 받은 next hop 정보를 그대로 전달하는게 아니라,

next-hop self,, 즉 next hop IP를 본인의 IP로 전달하면

iBGP peer는 reachability 문제를 해결할 수 있을것이다.

iBGP가 광고한 prefix는 다시 광고하지 않는다는 점 때문에,,

이를 해결하려면 iBGP peer끼리는 full mesh 형태를 맺어야 한다.

만약에 iBGP peer가 10대, 100대 이렇게 늘어나면 full mesh로 하기 힘들어진다.

이 때 사용하는것이 바로

route-reflector

그리고

confederation..

confederation설정할 때 조금 헷갈리는게

bgp router <as number> 여기에서는 내부적으로 사용할 번호를,,

그리고 bgp confederation identifier에 eBGP와 맺을 때 사용하는 번호를 입력한다.

나는 공식적인 as number를

bgp router 선언할 때 쓰는게 좀 더 와닿는데...

confederation 의미를 찾아보면,,

약간 느슨한 연합이라는 뜻인데

공식 AS 안에서,

약간의 느슨한 자기들만의 confederation을 맺는거면,

아무튼,, 이것때문에 살짝 헷갈림.

BGP 기초 내용

성민 | 네트워크 생존노트 — Sat, 31 Jan 2026 14:05:17 +0900

BGP peer와 session을 맺을 때,

보통 loopback interface를 이용해서 peer를 맺는데,

이때 사용하는게 보통

R1(config-router)#neighbor <neighborIP> update-source <interface>

인데,, 여기서 순간 의문인것이,

R1에서, <neighborIP> 로 갈 때,

실제 packet의 source가 <interface>로 되어서 가느냐..

그렇다면 내 loopback0 IP에 대한 routing 정보가

상대방에게 있어야 하는건가?

그런데, 서로다른 AS의 라우터가 상대 AS에 속한 라우터의 loopback0에 대한 라우팅 정보를 가지는게

상식적으로 말이 되는건가 ??

아래 예시에서는 R1과 R6의 AS가 65100으로 동일하지만,,

라우팅 정보가 있냐 없느냐에 대한 초점으로만 보자면...

R1은 6.6.6.6을 neighbor table에 등록,

R6은 10.10.123.1을 neighbor에 등록하고, update-source를 loopback 0로 설정.

아래에 log를 보면 알 수 있겠지만,

R1에서 6.6.6.6 라우팅 정보는 없고,

R6에서 10.10.123.1 라우팅 정보는 있다.

일단 결론적으로, R1과 R6는 BGP session을 맺지 못한다.

R1#show ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                10.10.123.1     YES manual up                    up
Ethernet0/1                unassigned      YES unset  up                    up
Ethernet0/2                unassigned      YES unset  up                    up
Ethernet0/3                unassigned      YES unset  up                    up
Loopback0                  1.1.1.1         YES manual up                    up

router bgp 65100
no synchronization
bgp log-neighbor-changes
neighbor 6.6.6.6 remote-as 65100
no auto-summary

R1#show ip route 6.6.6.6
% Network not in table
R1#

R6#show ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                10.10.56.6      YES manual up                    up
Ethernet0/1                10.10.67.6      YES manual up                    up
Ethernet0/2                10.10.68.6      YES manual up                    up
Ethernet0/3                unassigned      YES unset  up                    up
Loopback0                  6.6.6.6         YES manual up                    up

router bgp 65100
no synchronization
bgp log-neighbor-changes
neighbor 10.10.123.1 remote-as 65100
neighbor 10.10.123.1 update-source Loopback0
no auto-summary

R6(config)#do show ip route 10.10.123.1
Routing entry for 10.10.123.0/24
  Known via "ospf 1", distance 110, metric 40, type inter area
  Redistributing via eigrp 1, rip
  Advertised by eigrp 1 metric 1 1 1 1 1
                rip metric 0
  Last update from 10.10.56.5 on Ethernet0/0, 1d18h ago
  Routing Descriptor Blocks:
  * 10.10.56.5, from 5.5.5.5, 1d18h ago, via Ethernet0/0
      Route metric is 40, traffic share count is 1
R6(config)#

그럼 여기서 드는 또다른 궁금증...

고객 입장에서야,

내부 라우팅 프로토콜에서

default-information originate를 써서,

peer를 맺고자 하는 router의 loopback IP 에 대한 경로가 없어도

default route를 통해 packet이 나간다고 치더라도,

SP 입장에서는,,

잠깐만.

가정을 처음부터 다시 하자면,,,

상상을 해보자.

AS 65100에 라우터가 5대가 있고,

각각 1번 ~ 5번 이라고 하고, 5번 라우터가 인터넷과 연결된 라우터인 상태.

1 - 2 - 3 - 4 - 5 ----- ㄱ-ㄴ-ㄷ-ㄹ-ㅁ ----- e - d - c - b - a

(AS65100) (AS65200) (AS65400)

이렇게 ...

굳이 1번 라우터를 이용해서 e라우터랑 external BGP session을 맺고 싶어.

상대방은 다른 AS(65200)를 거쳐야 도달할 수 있는 라우터라고 치자.

AS 65400인 상대방도 5개의 라우터가있고,

각각 a~e 라고 하고, e 라우터가 인터넷과 연결된 라우터인 상태.

그러니까 내 1번 라우터와 상대방의 a 라우터를

BGP session을 맺을거야.

전부 공인 IP를 사용한다고 가정을 하고,,

AS 65100, 65400 에서는 각자 내부적으로 OSPF를 돌리고있고

5번, e 라우터가 각각 default router가 된다..

그러면 1번에서 출발한 BGP packet은 5번으로 간다.

5번에는 static default routing 설정되어 있을거니까 ㄱ라우터로 보낸다.

그러면? AS 65200은 어떻게 AS 65400쪽으로 보내지??..

결국 AS의 단말에 있는 라우터끼리는 connected 상태의 peer를 맺어야 할 필요가 있다는건가?

그러니까 hop count가 1인 peer를 맺을 필요가 있다는거지

일단 이 의문은 잠깐 미뤄두고,,

IGP와 헷갈렸는데.. IGP 같은 경우는

본인의 interface가 가지는 network만 광고할 수 있는데

BGP는 connected 뿐만아니라 IGP나 static route로 배운

RIB에 있는 network 정보를 광고 할 수 있다는 점...

이거를 계속 유의하고!

bgp router 설정에서

network 명령어로 어떤 prefix를 설정하면

제일먼저 RIB를 살펴보고 RIB에 있으면 실질적으로 BGP peer에게 광고를 한다...

internal BGP peer를 multi hop 으로 맺으면,,

bgp로 광고한 prefix가 상대 peer의 RIB에 install은 되지만

실질적으로 중간의 under lay router들은 bgp로 광고한 preifx에 대한 정보를 모르니까

통신이 안된다...

그래서 어떠한 기술이 더 있었던것 같은데...

마침 아래의 내용이 나오네

이때 가능한 기술은,,

BGP를 IGP로 redistribution 하는건데.. 이건 비추천하는 방식이다.

왜냐하면 BGP는 매우 방대한 routing 정보를 가지고 있기 때문에

이거를 IGP로 redistribution 하는 것은,,, 좋지 않다는 이유다.

그러면, 또다른 방법은,,

iBGP를 full mesh 형태로 session을 맺는것.

eBGP 끼리는 AS_Path를 이용해서 loop prevention을 하지만..

iBGP는 AS_Path를 이용하지 못하기 때문에.. iBGP로 받은 라우팅 정보는 전달 불가능.

RFC 4271 prohibits the advertisement of a route received from an iBGP peer to another iBGP peer. RFC 4271 states that all BGP routers in a single AS must be fully meshed to provide a complete loop-free routing table and prevent traffic blackholing

그래서, full mesh를 해야한다고.

이때 R1, R3가 IGP를 하든 static route를 하든, R2에서 10.12.1.0, 10.23.1.0을 BGP network로 광고를하든

R1과 R3가 통신이 되는건 기본으로 깔고간다.

BGP - Path Attributes

성민 | 네트워크 생존노트 — Sat, 31 Jan 2026 11:57:31 +0900

Well known - mandatory

Well known - discretionary

Optional - transitive

Optional - non-transitive

위에 3개는 이해가 가는데, 4번째 Optional - non-transitive는 살짝 이해가 안 간다.

BGP router가 recognize 안 해도 되고, transitive도 안 한다면,

해당 router에서만 사용되는(?) 그런 요소가 있다는 것인데...

아, 자세히 보니까 AS to AS 로 전달이 안 된다는 것은

AS 내부적으로는 사용하는 path attribute다... 이말 이군요

네트워크 생존노트

Packet Forwarding Process

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

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

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

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

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

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

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

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

8. 예시 명령어 정리

show ip route

show ip route longer-prefixes

show ip cef

show ip cef exact-route

show ip arp

show ip nhrp

show adjacency detail

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

10. 마무리

추천 태그

IPv6 에 대하여

IPv6에 대하여

1. IPv6 주소 형식

2. IPv6 주소 할당 방식

3. SLAAC

4. Interface ID 생성 방식

Random 또는 Stable Random Interface ID

EUI-64

왜 U/L bit를 flip할까?

5. RA Flag

6. Stateful DHCPv6와 Stateless DHCPv6

Stateful DHCPv6

Stateless DHCPv6

7. Cisco 설정 예시

SLAAC Only

Stateless DHCPv6

Stateful DHCPv6

8. DHCPv6 Message 종류

9. DHCPv4와 DHCPv6의 차이

10. DHCPv6 Relay 동작 방식

Cisco DHCPv6 Relay 예시

11. 네트워크 엔지니어 관점의 핵심

12. 한 줄 정리

참고 RFC

DHCP에 대해서

DHCP에 대하여

1. 테스트 토폴로지

2. DHCP 패킷을 볼 때의 기본 구조

3. DHCP DORA 흐름

4. DHCP Discover

Host A가 VLAN 10에서 보내는 Discover

R1이 R2에게 Relay하는 Discover

5. DHCP Offer

6. DHCP Request

7. DHCP ACK

8. Relay된 DHCP 메시지인지 판단하는 기준

9. 실제 Relay된 Discover 패킷 예시

10. 여러 Client가 동시에 DHCP를 요청하면?

11. DHCP Message Type 전체 정리

Lease는 DHCP Message Type이 아니다

12. 네트워크 엔지니어 관점에서 중요한 이유

13. 한 줄 정리

참고 RFC

과연 두 Host는 통신이 될까?

과연 두 Host는 통신이 가능할까?

Quiz

0. IPv4 주소는 비트맵이다

1. 테스트 토폴로지: 서브넷이 조금 다를 때

1-1. Host A와 Host B의 서브넷 판단이 다르다

1-2. Host A에서 Host B로 Ping을 보내면

2. ICMP Redirect 메시지의 의미

그런데 왜 Host B는 Host A의 MAC을 바로 쓰지 못할까?

3. 라우팅과 포워딩을 결정하는 기준

4. 라우팅할 때 프레임은 다시 만들어지고 TTL은 언제 바뀌는가

정리

[Data Center CCIE] - Fibre Channel - 2

Flow Control

Switched Fabric Initialization

[Data Center CCIE] - Fibre Channel - 1