내 PC는 목적지로 데이터를 보낼 때 누구의 MAC 주소를 사용할까

같은 네트워크인지 먼저 판단해야 ARP로 물어볼 IP가 정해진다↑

단말 192.0.2.10/24가 같은 Subnet의 192.0.2.80으로 보낼 때는 상대 호스트의 MAC을 찾습니다. 인터넷 서버 203.0.113.80으로 보낼 때는 서버가 아니라 Default Gateway 192.0.2.1의 MAC을 찾습니다.

여기서 “직접 보낸다”는 말은 두 장비 사이에 케이블 하나만 있다는 뜻이 아닙니다. 중간에 한 대 이상의 스위치가 있어도 라우터를 거치지 않는 같은 링크 계층 범위라면, 송신 단말은 최종 상대의 MAC 주소를 넣은 프레임을 보냅니다.

어느 IP를 묻는지는 앞 단계의 로컬·원격 판단이 결정합니다. ARP는 IPv4 주소를 전 세계 MAC으로 바꾸는 서비스가 아니라, 현재 Broadcast 도메인 안에서 Next Hop 인터페이스의 MAC을 찾는 절차입니다.

단말은 먼저 자신의 Route 테이블을 조회해 ARP Target을 정합니다. 192.0.2.10/24에서 192.0.2.80은 Connected Route와 일치하므로 192.0.2.80을 묻습니다. 203.0.113.80은 Default Route와 일치하므로 Route의 Next Hop인 192.0.2.1을 묻습니다. ARP가 Route를 결정하는 것이 아니라 Route 조회 결과가 ARP로 찾을 IP를 결정합니다.

더 구체적인 Static Route가 있거나 인터페이스가 여러 개면 같은 목적지라도 선택되는 Next Hop과 ARP를 보낼 인터페이스가 달라질 수 있습니다. Proxy ARP가 켜진 라우터는 원격 IP에 대한 질문에 자신의 MAC으로 답해 잘못된 On-Link 판단을 가릴 수도 있습니다. 장애 때는 ARP Entry만 보지 말고 그 Entry를 만들게 한 Route와 인터페이스를 함께 확인해야 합니다.

ARP 요청이 전달되는 범위는 현재의 브로드캐스트 도메인입니다. 라우터가 패킷을 다음 이더넷 링크로 내보낼 때는 그 링크에서 필요한 다음 홉의 MAC 주소를 확인하고 새 프레임을 만듭니다. 장애를 조사할 때 IP 목적지와 프레임의 목적지 MAC을 함께 적으면, 원격 서버로 갈 패킷을 게이트웨이 MAC으로 보내는 정상 동작을 구별할 수 있습니다.

이 절의 근거 IETF RFC 1122 §3.3.1 · IETF RFC 826

도해에서 확인할 내용 Ethernet 헤더의 MAC·EtherType 칸과 IP 패킷이 들어 있는 L3 Payload 칸을 비교합니다. L2 스위치가 읽는 Destination MAC이 어느 칸인지 확인합니다.

게이트웨이는 받은 프레임을 벗기고 Route에 맞는 새 프레임을 만든다↑

PC 192.0.2.10/24가 다른 네트워크의 서버 203.0.113.80으로 보낸다고 가정해 보겠습니다. IP 목적지는 처음부터 203.0.113.80이지만, PC가 ARP로 묻는 주소는 게이트웨이 192.0.2.1입니다. 첫 프레임의 Source MAC에는 PC의 주소가, Destination MAC에는 게이트웨이의 주소가 들어갑니다. 중간 스위치는 최종 서버의 MAC 주소를 찾지 않고, 이 Destination MAC을 따라 게이트웨이 쪽으로 전달합니다.

게이트웨이는 Destination MAC이 자신의 수신 인터페이스 주소이므로 프레임을 받아 Decapsulation하고, 안쪽 IP 목적지를 기준으로 Route Lookup을 수행합니다. 여기서 중요한 구분은 라우터가 ARP Cache만 보고 스위칭하는 것이 아니라는 점입니다. 먼저 라우팅 테이블이 출력 인터페이스와 다음 전달 대상을 정합니다. 그 뒤 ARP Cache 또는 Neighbor 정보를 조회하고, 해결된 MAC 주소가 없으면 선택된 출력 링크에서 ARP Request를 보냅니다.

Route Lookup 결과가 203.0.113.0/24의 Connected Route라면, 라우터는 최종 서버 203.0.113.80을 ARP로 묻습니다. 새 프레임의 Source MAC은 라우터의 출력 인터페이스, Destination MAC은 서버의 주소가 됩니다. 그 아래의 스위치가 MAC 테이블에서 MAC 주소와 VLAN에 대응하는 장비 포트를 찾아 실제 출력 장비 포트를 고릅니다. ARP Cache의 IP→MAC 관계와 MAC 테이블의 MAC→장비 포트 관계는 서로 다른 단계입니다.

게이트웨이 기능과 스위칭 기능이 한 L3 스위치 안에 있어도 논리적인 순서는 같습니다. 먼저 Route Lookup이 출력 경로를 정하고 Neighbor 정보를 확인합니다. 출력 쪽 VLAN에서 L2 스위칭이 필요한 경우에는 새 프레임이 MAC 테이블을 따라 출력됩니다. 하드웨어가 이 과정을 한 번에 처리해 보여도 Route·ARP Cache·MAC 테이블이 답하는 질문까지 하나가 되는 것은 아닙니다.

Route가 다른 라우터 198.51.100.2를 Next Hop으로 가리킨다면, 이번 ARP Target은 최종 서버가 아니라 그 Next Hop IP입니다. 새 프레임의 Source MAC은 현재 라우터의 출력 주소이고, Destination MAC은 다음 라우터의 주소입니다. 다음 라우터도 같은 순서를 반복합니다. 따라서 송신 PC는 멀리 있는 서버의 MAC 주소를 알 필요가 없고, 첫 게이트웨이의 주소만 알면 됩니다.

라우터를 지날 때 일반적인 IP 전달에서는 Source IP와 Destination IP가 유지되지만, Source MAC과 Destination MAC은 링크마다 바뀝니다. TTL은 각 라우터에서 줄고 IPv4 헤더의 Checksum도 다시 계산됩니다. NAT나 터널은 IP 값이나 바깥 헤더까지 바꿀 수 있는 별도 경계이므로, 이 절의 기본 흐름과 구분해 봐야 합니다.

이 절의 근거 IETF RFC 1812 §5.2.1.2 · IETF RFC 826

도해에서 확인할 내용 위쪽은 같은 네트워크에서 목적지의 Destination MAC을 쓰는 흐름입니다. 아래쪽은 다른 네트워크로 갈 때 첫 라우터, Next Hop 라우터, Connected Route의 최종 서버 순으로 ARP 대상과 새 프레임의 목적지가 달라지는 모습을 비교합니다.

MAC을 모르면 모두에게 묻고, 응답은 보통 요청한 호스트로 돌아온다↑

단말이 ARP Cache에 항목을 갖고 있지 않으면 목적지 MAC ff:ff:ff:ff:ff:ff로 Request를 보냅니다. 프레임 안에는 묻는 Target IP와 질문자의 Sender IP·MAC이 들어 있습니다.

같은 VLAN의 장비들은 Request를 받지만 Target IP를 사용하는 인터페이스가 자신의 MAC을 담아 응답합니다. 질문자는 IP와 MAC의 대응을 ARP Cache에 일정 시간 보관하고 이후 Data 프레임을 Unicast로 보냅니다.

Request의 Ethernet Destination은 Broadcast이지만 Sender MAC·IP와 Target IP는 구체적인 값을 가집니다. 예를 들어 “192.0.2.80을 가진 장비는 192.0.2.10에게 알려 달라”는 내용입니다. Target MAC 필드는 있지만, 주소를 찾는 요청에서는 그 값에 의미를 두지 않습니다. 응답자는 Reply의 Destination MAC을 질문자 MAC으로 지정해 보통 Unicast로 돌려보내고, 질문자는 그 대응을 Cache에 저장합니다.

ARP Reply가 반드시 Request 직후에만 나타나는 것은 아닙니다. 장비가 자신의 새 IP·MAC 관계를 알리거나 중복 주소를 확인하기 위해 Gratuitous ARP 또는 Probe 형태의 ARP를 보낼 수 있습니다. 고가용성 Gateway가 Active 장비를 바꿀 때도 Virtual IP의 새 MAC 위치를 알리는 데 사용합니다. 캡처에서는 Opcode뿐 아니라 Sender·Target IP와 MAC을 읽어 질문, 응답, 자기 알림 중 어떤 패킷인지 구분해야 합니다.

Reply가 항상 Unicast로 전송되는지, 요청만 받아도 Cache를 갱신하는지는 운영체제와 보안 설정에 따라 달라질 수 있습니다. 핵심은 Request와 Reply의 Opcode, Sender/Target IP·MAC을 보고 질문과 답이 같은 주소 확인 절차인지 확인하는 것입니다.

이 절의 근거 IETF RFC 826

도해에서 확인할 내용 ARP Request의 Broadcast 화살표와 Reply의 Unicast 화살표를 비교합니다. 요청의 목적지 MAC FF:FF:FF:FF:FF:FF와 응답의 단말 MAC, 응답을 받은 호스트가 ARP Cache에 주소 대응을 기록하는 설명을 확인합니다.

스위치가 Destination보다 Source MAC을 먼저 학습하는 데는 이유가 있다↑

스위치는 프레임을 받을 때 Source MAC과 들어온 포트, VLAN을 MAC Address Table에 기록합니다. ARP를 해석해야만 학습하는 것이 아니라 정상적인 Ethernet 프레임의 Source MAC을 관찰해 위치를 배웁니다.

목적지 MAC이 테이블에 있으면 해당 포트로 전달합니다. 조회한 목적지 포트가 프레임이 들어온 포트와 같으면 다른 포트로 전달하지 않고 Filtering합니다. 목적지 MAC을 모르면 들어온 포트를 제외한 같은 VLAN의 전달이 허용된 포트로 Unknown Unicast 플러딩합니다.

PC가 보낸 ARP Request가 포트 5로 들어오면 스위치는 Broadcast Destination을 전달하기 전에 Source MAC을 VLAN 10·포트 5와 연결해 학습합니다. 이후 Gateway의 Reply가 Uplink에서 들어오면 Gateway MAC도 VLAN 10·Uplink와 연결합니다. 이제 두 방향의 Unicast 프레임은 MAC 테이블의 Entry를 사용해 필요한 포트로만 전달할 수 있습니다. ARP 교환이 스위치에 양 끝의 위치를 자연스럽게 가르쳐 주는 셈입니다.

목적지 MAC을 아직 모를 때의 Unknown Unicast 플러딩은 Broadcast와 결과 범위가 비슷해 보여도 원인이 다릅니다. Destination MAC은 Unicast지만 테이블에 위치가 없어서 같은 VLAN에 복제하는 것입니다. 응답 프레임이 돌아오면 Source 학습으로 위치가 채워집니다. 계속 플러딩이 남는다면 비대칭 트래픽, 만료, MAC 학습 제한이나 한 방향 캡처를 의심해야 하며, ARP Cache가 정상이라고 MAC 테이블도 정상이라고 단정할 수 없습니다.

스위치가 Destination을 보고 위치를 “학습”하는 것은 아닙니다. Destination은 현재 전달 결정을 위한 조회 Key이고 Source는 위치를 갱신하는 근거입니다. 그래서 한 방향 프레임만 보이는 초기에는 반대쪽 MAC이 Unknown이라 플러딩될 수 있으며, 응답이 들어온 뒤 양쪽 Source가 학습되면 Unicast 전달로 안정됩니다. 테이블 조회에는 VLAN Context까지 포함해 같은 MAC의 다른 영역을 구분합니다.

이 절의 근거 IEEE 802.1Q

도해에서 확인할 내용 Source MAC 학습과 Destination CAM 조회 뒤의 Hit·Miss 처리를 구분합니다. Port 1에서 학습한 주소 대응, 조회가 맞으면 Port 24로 전달하거나 수신 포트와 같을 때 걸러 내는 처리, 조회가 빗나가면 같은 VLAN으로 플러딩하는 범위를 비교합니다.

호스트와 장비가 이동해도 ARP Cache와 MAC 테이블이 새 위치를 찾는 방법↑

ARP Cache와 Dynamic MAC Entry에는 만료 시간이 있습니다. 너무 오래된 항목을 계속 믿으면 장비 교체와 이동을 반영하지 못하고, 너무 빨리 지우면 Broadcast와 Unknown Unicast가 늘어납니다. 구체적인 시간은 운영체제와 스위치 구현에 따라 다릅니다.

Gateway 이중화에서 Virtual IP의 담당 장비가 바뀌거나 서버 NIC가 교체되면 Gratuitous ARP가 새 MAC 관계를 알릴 수 있습니다. 그래도 중간 장비의 Cache와 보안 정책이 갱신되는지 확인해야 합니다.

호스트의 ARP Cache와 스위치의 MAC 테이블은 서로 다른 장비에서 서로 다른 Timer로 만료됩니다. ARP Entry가 남아 있는데 MAC Entry만 먼저 사라질 수 있습니다. 이때 호스트는 새 ARP 없이 기존 Destination MAC으로 프레임을 보냅니다. 스위치는 처음 몇 프레임을 Unknown Unicast로 플러딩한 뒤 응답 프레임의 출발지 MAC을 보고 다시 학습할 수 있습니다. 두 Timer가 같을 필요도 없고 보통 같다고 가정해서도 안 됩니다.

가상 머신이 다른 하이퍼바이저로 이동하거나 Gateway에 장애 전환이 일어나면 같은 MAC이 새 포트에서 보일 수 있습니다. 정상 이동은 짧은 MAC 이동 로그와 Gratuitous ARP를 만들 수 있지만, 두 위치에서 계속 번갈아 보이면 Loop나 중복 활성 상태일 수 있습니다. 변경 시각, MAC 이동 빈도와 실제 토폴로지를 함께 봐야 정상 이동과 MAC Flapping을 구분할 수 있습니다. 무조건 Cache를 지우는 조치는 증상을 잠시 가릴 뿐 원인을 설명하지 못합니다.

두 테이블의 수명과 갱신 시점이 같지는 않습니다. 스위치가 새 포트를 배웠어도 다른 호스트의 ARP Cache가 예전 MAC을 가리킬 수 있고, ARP는 맞아도 스위치 테이블이 비어 잠시 Flood할 수 있습니다. 이동 장애에서는 IP → MAC과 VLAN + MAC → Port를 같은 시각에 조회하고, MAC Flapping Log나 Gratuitous ARP가 있었는지 연결합니다.

이 절의 근거 IETF RFC 826 · IETF RFC 5227 · IEEE 802.1Q

도해에서 확인할 내용 ARP Probe와 Gratuitous ARP 공지를 구분한 설명을 읽고, VRRP/HSRP 절체 예의 세 상자를 비교합니다. Sender IP와 Target IP가 모두 192.0.2.1인 공지, 호스트의 ARP 주소 대응 처리와 스위치의 새 포트 학습, 주소 충돌 확인을 구분합니다.

인증 없는 ARP를 믿으면 위조와 중복 IP가 어떤 문제를 만들까↑

기본 ARP에는 강한 인증이 없으므로 공격자가 Gateway IP에 자신의 MAC을 연결하는 거짓 Reply를 보낼 수 있습니다. Dynamic ARP Inspection 같은 기능은 신뢰된 DHCP Binding이나 정책과 ARP 내용을 대조해 위조를 줄입니다.

두 장비가 같은 IP를 사용하면 ARP Cache가 번갈아 바뀌어 통신이 간헐적으로 끊길 수 있습니다. 이를 막으려면 기능을 켜는 데서 그치지 말고, 어떤 주소·MAC 대응 정보를 기준으로 검사하는지와 어느 포트를 신뢰하는지 확인해야 합니다.

공격자가 “Gateway IP는 내 MAC이다”라는 ARP Reply를 보내고 클라이언트가 이를 Cache에 저장하면 이후 프레임이 공격자 포트로 향할 수 있습니다. Dynamic ARP Inspection은 DHCP Snooping Binding의 IP·MAC·VLAN·포트와 ARP 내용을 대조해 허용 여부를 판단할 수 있습니다. 그러나 Static IP 장비는 DHCP Binding이 없으므로 별도 ACL이나 신뢰 정책 없이 일괄 검사하면 정상 패킷까지 차단될 수 있습니다.

중복 IP는 악의가 없어도 같은 현상을 만듭니다. 두 호스트가 번갈아 Reply를 보내면 클라이언트마다 서로 다른 MAC을 Cache에 보관하고, 스위치에서는 두 MAC 위치가 정상이어도 IP 통신은 간헐적으로 다른 호스트에 도착합니다. ARP Inspection 폐기 카운터, DHCP Binding, Static 자산 기록과 캡처의 Sender MAC을 함께 확인합니다. 보호 기능은 신뢰할 주소 원장을 전제로 하므로 DHCP·IPAM 운영이 부정확하면 보안 정책도 정확해질 수 없습니다.

DHCP Snooping Binding을 근거로 ARP를 검사하는 Dynamic ARP Inspection, 정적 Binding, Port Security와 네트워크 인증은 위험을 줄일 수 있습니다. 다만 정적 주소나 Relay 환경을 Binding에 반영하지 않으면 정상 패킷도 버릴 수 있습니다. 방어 기능을 켤 때는 신뢰 포트, 검증 필드, Rate Limit와 거부 Log를 설계하고 정상 Gateway 전환을 시험합니다.

이 절의 근거 IETF RFC 5227 · Cisco Dynamic ARP Inspection

도해에서 확인할 내용 DHCP Snooping 바인딩과 고정 주소용 ARP ACL을 검증 근거로 쓰는 Dynamic ARP Inspection 경로를 따라갑니다. 거짓 IP·MAC 대응이 신뢰하지 않는 포트에서 검사·폐기되는 처리를 확인합니다. VLAN별 설정값은 이 도해에 표시하지 않았습니다.

ARP Request부터 Reply와 MAC 학습까지 따라가면 끊긴 지점이 보인다↑

상황: 단말은 Gateway에 Ping을 보내지만 ARP 항목이 계속 Incomplete로 남습니다.

1. 단말 캡처에서 Gateway IP를 묻는 ARP Request가 나가는지 확인합니다.
2. 스위치에서 해당 VLAN이 액세스 포트와 Uplink에 존재하는지 봅니다.
3. Gateway 인터페이스에서 Request가 도착하고 Reply가 나가는지 캡처합니다.
4. Reply가 돌아오지 않으면 VLAN, 포트 Security, DAI와 MAC 테이블 이동 로그를 확인합니다.
5. 수정 뒤 ARP Cache, MAC 테이블과 실제 Unicast 프레임을 다시 대조합니다.

세 지점에서 같은 ARP를 따라가면 실패 범위가 분명해집니다. 클라이언트 액세스 포트에서 Request가 나가는지, Gateway 포트에서 같은 VLAN의 Request가 들어오는지, Gateway Reply가 다시 클라이언트 방향으로 나가는지 확인합니다. 각 지점의 VLAN ID와 Source MAC을 기록하고 스위치 MAC 테이블에서 그 MAC이 어느 포트에 학습되었는지 대조합니다. 한쪽 Uplink 캡처에만 없으면 Allowed VLAN이나 STP 상태로 범위를 좁힐 수 있습니다.

수정 뒤에는 ARP Entry가 Complete가 된 사실뿐 아니라 실제 Data 프레임이 Unicast로 왕복하는지 봅니다. Gateway Ping이 성공하면 같은 VLAN의 다른 호스트와 원격 Prefix도 시험해 Local·Remote ARP Target이 각각 맞는지 확인합니다. Cache 삭제는 재학습을 관찰하기 위한 시험 조건으로 사용하고, 근본 조치처럼 기록하지 않습니다. Request, Reply, MAC 학습과 다음 IP 패킷을 한 Timeline에 놓아야 복구 원인을 설명할 수 있습니다.

Request가 대상 포트에 도달하지 않으면 VLAN 또는 L2 전달 범위를, Reply가 만들어지지 않으면 대상 호스트 설정을, Reply가 중간에서 사라지면 MAC 테이블과 보안 정책을 우선 조사합니다. 이처럼 첫 누락 지점을 찾으면 ARP Cache 삭제 같은 임시 조치가 원인을 가리는 일을 줄일 수 있습니다.

이 절의 근거 IETF RFC 826 · IEEE 802.1Q