LogoفارسیFA

Hands-On Lab: ARP and Proxy ARP

This hands-on lab demonstrates how a device resolves an IP address to a MAC address using ARP, and shows how Proxy ARP allows a router to answer ARP requests on behalf of a device on a different subnet, sometimes masking a missing default gateway configuration.

ARP ResolutionProxy ARPMAC Address Table

~3 min read · Updated Sep 12, 2026

Lab Objective

Observe normal ARP resolution between a router and a directly connected host, then enable Proxy ARP on a router interface and observe how it allows a misconfigured host with no default gateway to still reach a remote subnet.

Lab Purpose

ARP is the invisible mechanism behind nearly every Layer 3 to Layer 2 translation, and Proxy ARP is a legacy feature that occasionally causes confusing behavior in real networks — a host with no gateway configured can sometimes still reach remote networks, and understanding Proxy ARP is essential to explaining why.

Lab Topology

R1 ---- Gi0/0 (192.168.30.1/24) ---- Switch ---- PC1 (192.168.30.10/24)

R1 ---- Gi0/1 (192.168.40.1/24) ---- R2 ---- LAN 192.168.40.0/24

PC1's default gateway is intentionally left
UNCONFIGURED (0.0.0.0) for this lab

Task 1: Configure Basic Addressing

Configure R1's interfaces as shown, and configure PC1 with IP 192.168.30.10/24 but no default gateway.

Task 2: Observe Normal ARP Behavior

From R1, ping PC1's address, then examine R1's ARP table to confirm the resolved MAC address.

Task 3: Confirm PC1 Cannot Reach the Remote Subnet by Default

Attempt to ping 192.168.40.x from PC1 and confirm it fails due to the missing default gateway.

Task 4: Enable Proxy ARP on R1

Enable Proxy ARP on R1's Gi0/0 interface (note: it is enabled by default on most IOS versions, so this task also covers explicitly verifying and, if needed, re-enabling it).

Task 5: Verify Proxy ARP Resolves the Issue

Attempt the same ping from PC1 to a host on 192.168.40.0/24 and observe that it now succeeds, then explain why using the ARP table.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.30.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 192.168.40.1 255.255.255.0
R1(config-if)# no shutdown

R1# ping 192.168.30.10

!!!!!
Success rate is 100 percent (5/5)

R1# show ip arp

Protocol  Address          Age   Hardware Addr   Type   Interface
Internet  192.168.30.10    0     00aa.bb00.1010  ARPA   GigabitEthernet0/0
Internet  192.168.30.1     -     00aa.bb00.0001  ARPA   GigabitEthernet0/0

PC1> ping 192.168.40.20
(without a gateway configured, and without
Proxy ARP, this would fail entirely -- but
because PC1 has no gateway set, it will
ARP directly for 192.168.40.20 as if it
were on its own local subnet)

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip proxy-arp

R1# show ip interface gigabitethernet0/0 | include Proxy
  Local Proxy ARP is disabled
  Proxy ARP is enabled

PC1> ping 192.168.40.20

Reply from 192.168.40.20: bytes=32 time=2ms

PC1> arp -a

Interface: 192.168.30.10
  Internet Address    Physical Address
  192.168.40.20        00aa.bb00.0001
  -- Notice: PC1 believes it has directly
  -- resolved 192.168.40.20's MAC address,
  -- but the MAC address shown actually
  -- belongs to R1's Gi0/0 interface --
  -- R1 answered the ARP request on behalf
  -- of the remote host, then routed the
  -- traffic normally once it arrived

Key Takeaway

Proxy ARP allows a router to answer ARP requests for addresses it can route to, even though those addresses are not physically on the local segment — this can mask a misconfigured default gateway on a host, which is exactly why unexpectedly working connectivity despite a missing gateway is a classic sign to check for Proxy ARP during troubleshooting.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

Continue

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

Continue

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

Continue

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

Continue

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

Continue

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

Continue
Previous ArticleNext Article