ARP

• PC1의 192.168.0.2/24에서 PC2의 192.168.2.2는 다른 네트워크다. 따라서 PC2를 직접 ARP하지 않고 게이트웨이 192.168.0.1을 찾는다.
• 최종 목적지 PC2와 다음 홉 R2의 192.168.1.2는 서로 다른 역할이다.

PC1> show ip
PC1> ip 192.168.0.2/24 192.168.0.1

실습 흐름을 재구성한 명령 예시. 장치·인터페이스 이름은 구성에 맞춰 사용한다.

원본 크기로 보기 ↗

• R1은 PC2 LAN을 R2로 보내고 R2는 PC1 LAN으로 돌아가는 경로를 알아야 한다. 기본 경로가 없을 때 한쪽만 등록하면 요청 또는 응답이 끊긴다.
• 경로표의 프리픽스와 next hop은 스위치 MAC 학습표와 별개다.

R1(config)# ip route 192.168.2.0 255.255.255.0 192.168.1.2
R2(config)# ip route 192.168.0.0 255.255.255.0 192.168.1.1
R1# show ip route
R2# show ip route

실습 흐름을 재구성한 명령 예시. 장치·인터페이스 이름은 구성에 맞춰 사용한다.

• LAN에서 ARP는 게이트웨이의 주소를 준비하고 ICMP는 IP 안에서 전달된다. NAT가 없는 이 구성에서는 ICMP 출발지·목적지 IP가 유지된다.
• Ethernet MAC은 링크마다 바뀔 수 있다. Serial 구간에 Ethernet MAC 교체 설명을 그대로 적용하지 않는다.

PC1> ping 192.168.2.2
Wireshark 표시 필터: arp || icmp

구성도의 확인 명령과 표시 필터

• ip neigh의 REACHABLE은 최근 도달성 확인이 있고 STALE은 그 확인이 오래되었다는 뜻이다. STALE 자체를 삭제·통신 불가로 읽지 않는다.
• 사진의 arp: command not found는 프로그램 오류다. Linux의 sh arp도 IOS show arp 축약으로 동작하지 않는다.

ip neigh
ping -c 3 10.0.0.3
ip neigh

같은 링크에 트래픽을 보내고 캐시를 비교하는 재구성 예시

원본 크기로 보기 ↗

• Ethernet 목적지는 Broadcast지만 ARP Target MAC은 0이다. 브로드캐스트 전달은 Ethernet 목적지가 결정한다.
• Sender IP 10.0.0.5가 Target IP 10.0.0.3을 묻는다. 대상 MAC을 아직 몰라 0으로 채운 것은 정상이다.

원본 크기로 보기 ↗

• 10.0.0.3은 자신의 MAC을 Sender 필드에 넣고 10.0.0.5를 Target으로 지정한다. Ethernet 목적지도 요청자의 MAC이다.
• ip neigh의 MAC과 Reply의 Sender MAC을 비교한다. ARP 성공이 이후 ICMP나 응용 서비스 성공까지 보장하지는 않는다.

ip neigh show 10.0.0.3
Wireshark 표시 필터: arp

실습 흐름을 재구성한 명령 예시. 장치·인터페이스 이름은 구성에 맞춰 사용한다.

원본 크기로 보기 ↗

• 192.168.10.66/24를 AND하면 192.168.10.0이므로 .130도 같은 링크라고 판단한다. 물리적으로 라우터 너머라는 사실을 자동으로 알아내지는 못한다.
• GATEWAY 0.0.0.0은 기본 게이트웨이가 설정되지 않은 상태다. 이 때문에 .130을 직접 ARP하는 상황을 일반적인 기본 게이트웨이 동작과 구분한다.

PC1> show ip
PC1> show arp

실습 흐름을 재구성한 명령 예시. 장치·인터페이스 이름은 구성에 맞춰 사용한다.

원본 크기로 보기 ↗

• 255.255.255.128은 /25다. 192.168.3.1은 네트워크 .0, 호스트 .1~.126, 브로드캐스트 .127의 범위에 속한다.
• ip address의 두 번째 값은 게이트웨이가 아닌 마스크다. no shutdown 뒤 LINK·LINEPROTO up은 원격 경로 성공까지 의미하지 않는다.

interface Ethernet2/0
 ip address 192.168.3.1 255.255.255.128
 no shutdown
end
show ip interface brief

실제 설정에 맞춘 명령 정리

원본 크기로 보기 ↗

• .66↔.130 캡처에서 .66이 .130을 ARP하고 라우터 쪽 MAC이 응답한다. 이는 Proxy ARP 맥락으로 읽어야 한다.
• Echo request의 TTL 64와 reply의 TTL 63은 반대 방향 패킷이다. 두 값만 빼서 한 요청의 홉 수를 확정하지 않는다.

원본 크기로 보기 ↗

• /22의 마스크는 255.255.252.0이고 세 번째 옥텟의 블록 크기는 4다. 10.5.128.1과 .2는 10.5.128.0~10.5.131.255 범위에 함께 들어간다.
• 목적지가 직접 연결된 Ethernet 이웃이므로 R1은 올바른 인터페이스로 ARP를 통해 상대 MAC을 알아낼 수 있어야 한다. 내부 다른 LAN과 NAT 문제를 처음부터 섞지 않는다.

원본 크기로 보기 ↗

• 실행 기록에서는 주소를 입력한 뒤 ping 0/5가 반복되고 show ip interface brief에 administratively down/down이 나온다. IP 설정은 인터페이스 활성화 명령을 대신하지 않는다.
• 해당 인터페이스에 no shutdown을 적용한 뒤 LINK와 LINEPROTO up 로그가 나타났다. 이 변경이 해결한 것은 관리적 비활성 상태다.

show ip interface brief
configure terminal
interface FastEthernet0/0
 no shutdown
end
show ip interface brief
ping 10.5.128.1

실제 실패 기록의 핵심 명령을 사건 순서대로 정리했다.

• 기록에는 up/up 뒤에도 Success rate is 0 percent (0/5)가 나온다. 따라서 링크 활성화만으로 통신을 복구했다고 볼 수 없다.
• 이 시점에는 connected 경로, ARP 응답, 상대 주소·마스크, 가상 연결과 필터를 확인해야 한다. 기본 경로를 추가하기 전에 10.5.128.1에 대한 조회가 직접 연결 경로를 선택하는지 본다.

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가 한 번 더 기록되어 있다. 같은 망의 이웃 접근을 기본 경로 추가로 해결했다고 설명하면 실제 사건 순서와 경로 선택 원리를 모두 놓친다.

관찰 순서
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 사이의 모든 외부 변경이 기록된 것은 아니다.