debug arp
Enables debugging of ARP (Address Resolution Protocol) packets to troubleshoot IP-to-MAC address resolution issues on a Cisco router or switch.
Definition: debug arp is a Cisco IOS privileged exec command. Enables debugging of ARP (Address Resolution Protocol) packets to troubleshoot IP-to-MAC address resolution issues on a Cisco router or switch.
Overview
The `debug arp` command is a powerful diagnostic tool used in Cisco IOS to monitor Address Resolution Protocol (ARP) activity in real time. ARP is a fundamental protocol that maps IP addresses to MAC addresses on a local network segment, enabling Layer 2 communication. When a device needs to send an IP packet to another host on the same subnet, it first checks its ARP cache; if no entry exists, it broadcasts an ARP request.
The target host responds with its MAC address, and the sender caches this mapping. This process is critical for proper network operation, and failures can lead to unreachable hosts, duplicate IP addresses, or performance issues. The `debug arp` command allows network engineers to observe ARP requests, replies, and cache updates as they occur, providing insight into IP-to-MAC resolution problems.
It is particularly useful when troubleshooting connectivity issues that are not explained by higher-layer protocols, such as when a host is reachable via ping but not via other applications, or when intermittent connectivity occurs. Unlike static ARP entries or `show arp` which show the current cache state, `debug arp` reveals the dynamic process, helping to identify missing replies, unexpected MAC addresses, or excessive ARP traffic. This command fits into a broader troubleshooting workflow: after verifying physical connectivity and IP configuration, an engineer might use `debug arp` to see if ARP exchanges are completing.
It is often used alongside `debug ip packet` or `debug interface` for deeper analysis. Important IOS behaviors: `debug arp` generates output to the console or logging buffer; if the console is busy, output may be buffered and displayed later. It requires privileged EXEC mode (enable) and can impact router performance if ARP traffic is high, so it should be used with caution in production.
The command does not modify the running configuration; it is a runtime debug only. To stop debugging, use `undebug arp` or `no debug arp`. Always disable debugging when done to avoid resource exhaustion.
debug arpWhen to Use This Command
- Troubleshooting connectivity issues when a device cannot reach another device on the same subnet.
- Verifying ARP requests and replies during a network attack or misconfiguration.
- Monitoring ARP activity when adding new devices to a VLAN or subnet.
- Diagnosing duplicate IP address conflicts by observing ARP responses.
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| no parameters | debug arp | The command has no optional parameters. It enables debugging for all ARP activity on the device. To limit debugging to specific interfaces or IP addresses, use conditional debugging with access-lists or interface filters, but the base command is unconditional. |
Command Examples
Basic ARP debug output
debug arpIP ARP: creating entry for 192.168.1.1, interface GigabitEthernet0/0
IP ARP: sent req src 192.168.1.10 0050.7966.6800,
dst 192.168.1.1 0000.0000.0000 GigabitEthernet0/0
IP ARP: rcvd rep src 192.168.1.1 0011.2233.4455,
dst 192.168.1.10 0050.7966.6800 GigabitEthernet0/0
IP ARP: creating entry for 192.168.1.1, interface GigabitEthernet0/0, with MAC 0011.2233.4455Line 1: Router creates an ARP entry for IP 192.168.1.1 on interface Gi0/0. Line 2: Router sends an ARP request from its own IP/MAC (192.168.1.10/0050.7966.6800) to broadcast MAC (0000.0000.0000) asking for 192.168.1.1. Line 3: Router receives an ARP reply from 192.168.1.1 with MAC 0011.2233.4455. Line 4: Router adds the resolved MAC to its ARP table.
Debug ARP with specific IP filter
debug arp 192.168.1.1IP ARP: sent req src 192.168.1.10 0050.7966.6800,
dst 192.168.1.1 0000.0000.0000 GigabitEthernet0/0
IP ARP: rcvd rep src 192.168.1.1 0011.2233.4455,
dst 192.168.1.10 0050.7966.6800 GigabitEthernet0/0Only ARP activity for IP 192.168.1.1 is displayed. The output shows a request and reply exchange, confirming that the target host is reachable and responding.
Understanding the Output
The debug arp command outputs lines prefixed with 'IP ARP:' indicating ARP events. Each line describes either a request (req) or reply (rep). For requests, 'src' is the sender's IP and MAC, 'dst' is the target IP with broadcast MAC (0000.0000.0000).
For replies, 'src' is the responder's IP and MAC, 'dst' is the original requester's IP and MAC. The interface is shown at the end. 'creating entry' lines indicate the ARP table is being updated.
A healthy network shows quick request-reply pairs; repeated requests without replies suggest the target is unreachable or does not exist. Duplicate IPs may cause multiple replies from different MACs.
Configuration Scenarios
Troubleshooting ARP Resolution Failure Between Two Routers
Two routers, R1 and R2, are directly connected via GigabitEthernet interfaces. R1 cannot ping R2's interface IP address. Basic IP configuration is correct, but ARP may be failing. This scenario uses debug arp to observe ARP exchanges.
Topology
R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2Steps
- 1.Step 1: On R1, enter privileged EXEC mode: enable
- 2.Step 2: Start ARP debugging: debug arp
- 3.Step 3: From R1, initiate a ping to R2's IP (10.0.12.2): ping 10.0.12.2
- 4.Step 4: Observe the debug output for ARP requests and replies.
- 5.Step 5: If no reply is seen, check R2's ARP cache and interface status.
- 6.Step 6: Stop debugging: undebug arp
! No configuration changes needed; this is a debug-only scenario. R1# debug arp R1# ping 10.0.12.2
Verify: Expected debug output on R1: *Mar 1 00:00:10.123: IP ARP: creating incomplete entry for 10.0.12.2 interface GigabitEthernet0/0 *Mar 1 00:00:10.124: IP ARP: sent req src 10.0.12.1 0011.2233.4455, dst 10.0.12.2 0000.0000.0000 GigabitEthernet0/0 *Mar 1 00:00:10.125: IP ARP: rcvd rep src 10.0.12.2 00aa.bbcc.ddee, dst 10.0.12.1 GigabitEthernet0/0 *Mar 1 00:00:10.126: IP ARP: updating entry 10.0.12.2 00aa.bbcc.ddee via GigabitEthernet0/0
Watch out: If the debug output shows 'rcvd rep' but the ping still fails, the issue may be at Layer 3 (routing) or Layer 2 (switching). Also, ensure that the interface is up/up and not in a VLAN that blocks ARP.
Detecting Duplicate IP Address on a LAN Segment
A workstation on a LAN segment reports intermittent connectivity. The network administrator suspects a duplicate IP address conflict. Using debug arp on the default gateway router can reveal multiple MAC addresses responding for the same IP.
Topology
PC1(192.168.1.10)---Switch---Router(Gi0/0:192.168.1.1)
PC2(192.168.1.10)---Same SwitchSteps
- 1.Step 1: On the router, enable debug arp: debug arp
- 2.Step 2: Clear the ARP cache for the suspect IP: clear arp-cache 192.168.1.10
- 3.Step 3: Initiate traffic from the router to the suspect IP: ping 192.168.1.10
- 4.Step 4: Observe debug output for multiple ARP replies from different MAC addresses.
- 5.Step 5: Identify the offending MAC and locate the device.
- 6.Step 6: Disable debugging: undebug arp
! No configuration changes; debug only. R1# debug arp R1# clear arp-cache 192.168.1.10 R1# ping 192.168.1.10
Verify: Expected debug output showing two different MAC addresses replying for the same IP: *Mar 1 00:01:00.123: IP ARP: rcvd rep src 192.168.1.10 0011.2233.4455, dst 192.168.1.1 GigabitEthernet0/0 *Mar 1 00:01:00.124: IP ARP: rcvd rep src 192.168.1.10 00aa.bbcc.ddee, dst 192.168.1.1 GigabitEthernet0/0 *Mar 1 00:01:00.125: IP ARP: duplicate address 192.168.1.10 on GigabitEthernet0/0, sourced by 00aa.bbcc.ddee
Watch out: The router may not always log a duplicate address warning; you must manually observe multiple replies. Also, some devices may not respond to ARP if they have firewall rules. Use `show arp` to see which MAC is currently cached.
Troubleshooting with This Command
When using `debug arp` for troubleshooting, it is essential to understand what healthy output looks like versus problem indicators. In a normal scenario, when a device sends an ARP request for an IP address, the debug output shows: 'IP ARP: sent req src [sender-IP] [sender-MAC], dst [target-IP] 0000.0000.0000 interface [interface]'. Then, if the target exists and is reachable, a reply appears: 'IP ARP: rcvd rep src [target-IP] [target-MAC], dst [sender-IP] interface [interface]'.
Finally, the cache is updated: 'IP ARP: updating entry [target-IP] [target-MAC] via [interface]'. If the target does not exist, you will see only the request, possibly followed by 'IP ARP: creating incomplete entry for [target-IP]' and then a timeout. Key fields to focus on: the source and destination IP and MAC addresses, the interface, and any error messages like 'duplicate address' or 'failed to set' (which may indicate hardware issues).
Common symptoms that `debug arp` helps diagnose include: (1) No ARP reply received – indicates the target is down, unreachable at Layer 2, or has a firewall blocking ARP. (2) Multiple replies for the same IP – indicates a duplicate IP address conflict. (3) ARP requests being sent but never completing – could be due to a misconfigured subnet mask, VLAN mismatch, or a switch port in errdisable state. (4) High ARP traffic – may indicate a broadcast storm or a device scanning the network. A step-by-step diagnostic flow: First, verify the interface status with `show interfaces` and `show ip interface brief`. Then, clear the ARP cache for the suspect IP with `clear arp-cache [ip]`.
Enable `debug arp` and generate traffic (e.g., ping). Observe the output. If no reply, check the target's ARP cache and interface.
If duplicate replies, locate the offending MAC via switch MAC address tables. Correlate `debug arp` output with `show arp` to see the current cache state, and with `debug ip packet` to see if packets are being dropped after ARP resolution. Also, use `show logging` to review buffered debug messages if console output was missed.
Remember that `debug arp` can flood the console with output on a busy network; use terminal monitors or logging buffers to capture output without overwhelming the console. Always disable debugging after troubleshooting to prevent performance degradation.
CCNA Exam Tips
Remember that 'debug arp' is a privileged EXEC command and can generate heavy output on busy networks; always use filters or 'undebug all' to disable.
The CCNA exam may ask you to interpret debug output to identify ARP spoofing or duplicate IPs.
Know that ARP requests are broadcast (MAC FFFF.FFFF.FFFF) but debug shows 0000.0000.0000 as placeholder.
Be able to distinguish between ARP requests and replies in the output format.
Common Mistakes
Leaving debug enabled after troubleshooting, causing CPU overload; always use 'undebug all' or 'no debug arp'.
Confusing debug arp with 'show arp' — debug is real-time, show is static table.
Using debug arp without an access list on a busy network, flooding the console with irrelevant messages.
debug arp vs clear arp-cache
Both commands are used for ARP-related troubleshooting, but debug arp provides real-time packet analysis while clear arp-cache resets the ARP table. They are often confused because both affect ARP behavior, yet serve opposite purposes: one observes, the one clears.
| Aspect | debug arp | clear arp-cache |
|---|---|---|
| Scope | Individual ARP packets | All ARP entries |
| Configuration mode | Privileged EXEC | Privileged EXEC |
| Persistence | Until disabled or reload | Immediate, not persistent |
| Typical use | Identify incorrect MAC mappings | Remove stale entries |
| Impact on device | High CPU if traffic heavy | Temporary ARP flood |
Use debug arp when you need to observe ARP requests and replies in real time to diagnose resolution failures or duplicate IP address conflicts.
Use clear arp-cache when you suspect stale or incorrect ARP entries are causing connectivity issues and you want the device to dynamically re-learn all mappings.
Platform Notes
In IOS-XE (e.g., Catalyst 9000 switches, ISR 4000 series), the `debug arp` command behaves similarly to classic IOS, but output may include additional fields such as VRF information or interface handle numbers. The syntax is identical. On NX-OS (Cisco Nexus switches), the equivalent command is `debug ip arp` (note the 'ip' keyword).
NX-OS also supports `debug ip arp interface <interface>` for conditional debugging. The output format differs slightly, using timestamps and different wording (e.g., 'ARP: Sending request' vs 'IP ARP: sent req'). On ASA firewalls, ARP debugging is done with `debug arp` (similar to IOS) but only in privileged mode; the ASA uses a different codebase, so output may vary.
For IOS-XR (Cisco ASR 9000, CRS), the command is `debug arp` but requires the 'crypto' or 'ipv4' context; it is available but less commonly used. In older IOS versions (12.x), the output was more verbose and included 'IP ARP: creating entry' messages. In 15.x and 16.x, the output is streamlined but still informative.
One key difference: on some IOS versions, `debug arp` may also display proxy ARP activity, which can be filtered using `debug arp proxy`. Always check the specific platform documentation for exact syntax and output variations.
Related Commands
Practice for the CCNA 200-301
Test your knowledge with practice questions covering all CCNA 200-301 exam domains.
Practice CCNA 200-301 Questions