You are troubleshooting ARP connectivity issues for an Ethernet interface on an IOS XR network that runs IS-IS. You verify that the IGP protocol is running, but an ARP entry has not yet been created.

Question

Options

• Adebug ping packets
• Bdebug ARP
• Cping the connected neighbor
• Dverify the RIB table routes

• A
  15% (6)
• B
  8% (3)
• C
  72% (28)
• D
  5% (2)

Explanation

Pinging the connected neighbor is correct because ARP resolution is triggered by traffic destined for that neighbor - sending a ping forces the device to issue an ARP request, which either populates the ARP table (proving Layer 2 reachability) or fails (pinpointing the problem). Since the question confirms IS-IS is up, the issue is specifically at Layer 2, and a ping is the most direct active step to diagnose or resolve the missing entry.

Why the distractors are wrong:

• A (debug ping packets): Not a standard IOS XR command, and passive debugging alone generates no ARP traffic - you need to send something first.
• B (debug arp): debug arp only observes ARP activity already occurring; without generating traffic via a ping first, you'll see nothing useful.
• D (verify RIB routes): ARP operates at Layer 2 and is independent of the RIB for directly connected peers - the RIB is already validated by confirming IS-IS is running.

Memory tip: ARP only fires when there's actual traffic to send - "No ARP entry? Shoot a ping first." Debug tools watch; pings act. On exam questions involving missing ARP entries, always look for the option that generates Layer 2 traffic before reaching for a debug command.

No community discussion yet for this question.