# ARP / Default Gateway — 본인 설명 노트

2026-09-13. 사용자가 제출한 네 가지 핵심 답변을 바탕으로 Codex가 적용 조건과 진단 한계를 보완했다. 대행 Lab 검증과 사용자 설명 확인을 구분해 기록한다.

## IP와 MAC의 목적지가 왜 다른가?

이번 NAT 없는 라우팅 실험에서 목적지 IP는 최종 수신자인 PC2를 가리키고, 목적지 MAC은 현재 L2 구간에서 프레임을 받을 다음 장비를 가리킨다. 같은 서브넷이면 상대 PC의 MAC, 다른 서브넷이면 선택한 다음 홉인 게이트웨이의 MAC을 사용한다.

## Gateway 오류와 Mask 오류를 ARP로 구별할 수 있는가?

ARP가 찾는 주소로 원인을 좁힐 수 있다. 이번 실험에서 /16으로 잘못 설정한 PC1은 원격 PC2 주소에 직접 ARP했고, 잘못된 GW를 설정한 경우에는 .254를 ARP했다. 다만 원격 IP에 직접 ARP하면 마스크뿐 아니라 경로 설정도 확인해야 한다. 게이트웨이 ARP에 응답이 없으면 잘못된 GW 주소, 게이트웨이 인터페이스 중단, VLAN·링크 문제 등을 확인해야 하며 ARP만으로 원인을 확정할 수는 없다.

## 같은 서브넷은 왜 계속 통신되는가?

이번 구성에서 PC1과 PC3는 서로를 같은 서브넷으로 판단하므로 게이트웨이를 거치지 않고 상대 IP를 ARP해 얻은 MAC으로 직접 통신한다. 따라서 실험한 GW 오류·/16 마스크 오류·라우터 eth0 중단 중에도 PC3 통신은 성공했다. 모든 종류의 마스크 오류에서 같은 서브넷 통신이 보장되는 것은 아니다.

## ARP 캐시가 남아 있으면 어떻게 달라지는가?

유효한 캐시가 있으면 해당 다음 홉의 IP→MAC 정보를 재사용해 새 ARP 요청 없이 프레임을 보낼 수 있다. 그러나 캐시 항목의 존재는 장비나 통신 경로가 살아 있다는 증거가 아니다. 인터페이스 중단 직후에도 기존 MAC으로 전송하다가 응답을 받지 못할 수 있다. 이번 장애 실험은 캐시를 비운 조건이며 캐시가 남은 장애 상황은 별도로 실험하지 않았다.

네 가지 핵심 개념의 설명을 확인했다. 이번 주제의 구성·정상·장애·복구 증거와 설명 확인을 완료로 기록한다. 관리형 스위치 MAC Table CLI와 ARP 캐시가 남은 장애 실험은 이 완료 범위에 포함하지 않는다.