Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Arp Problem with Cisco 7200

I have a problem with ARP which I've been trying to resolve for a couple of days now and it's doing my head in.

Network topology:

Router (cisco 7200) -> Head Switch (cisco 3750 / VLAN 613 configured for customer) -> Customer's Switch -> Customer's LAN ( on VLAN 613)

The customer is reporting arp issues when trying to reach another machine on the same LAN segment. When he pings this particular host (eg: on his LAN segment, our core router for some odd reason answers to the ARP query (see tcpdump below).

13:53:16.020327 arp who-has tell 203.x.x.58

13:53:16.020485 arp reply is-at 00:04:61:46:c1:42

13:53:16.051428 arp reply is-at 00:0c:86:74:f0:1b

13:53:18.036330 arp who-has tell 203.x.x.58

13:53:18.036468 arp reply is-at 00:04:61:46:c1:42

13:53:18.036753 arp reply is-at 00:0c:86:74:f0:1b

00:04:61:46:c1:42 is the actual machine with IP address

00:0c:86:74:f0:1b is the MAC address of the router's sub interface.

Router#sh int g0/1.613

GigabitEthernet0/1.613 is up, line protocol is up

Hardware is BCM1250 Internal MAC, address is 000c.8674.f01b (bia 000c.8674.f01b)

There's no routes on the router for so we're a bit puzzled why the router thinks it has a route to get to and why it keeps replying back with it's MAC address.

Router#sh ip route

% Subnet not in table

Router#sh ip route | inc 172.16.2


To make this more interesting, I plugged my latop into the customer's lan segment and can not replicate the issue when I ping (I'm only getting one arp reply from the actual machine). The customer has reported that the double arp replies is not happening on all machines as well.

Is there anyway to track down why the router is responding to arp requests it has no route for and how can we go about fixing this?

Router#sh ver

Cisco Internetwork Operating System Software

IOS (tm) 7200 Software (C7200-P-M), Version 12.3(22), RELEASE SOFTWARE (fc2)

Technical Support:

Copyright (c) 1986-2007 by cisco Systems, Inc.

Compiled Wed 24-Jan-07 20:17 by ccai

Image text-base: 0x60008AF4, data-base: 0x61A62000

ROM: System Bootstrap, Version 12.2(8r)B, RELEASE SOFTWARE (fc1)

BOOTLDR: 7200 Software (C7200-KBOOT-M), Version 12.2(15)B, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

Thank you in advance.


Re: Arp Problem with Cisco 7200

I think kindly check the details and take necessary action to upgrade the IOS of Cisco 7206. MCU reboots and when it comes back up, it sends out an ARP request (it has a static IP configured). The 7200 replies to the request with this IP address and its own MAC address. The MCU receives the reply, detects duplicate IP address, and shuts down its port. The same results were observed when using a laptop instead of the MCU and using a different IP addresses.

Hall of Fame Super Silver

Re: Arp Problem with Cisco 7200


Although there are some aspects of your description that are a puzzle to me I believe that I can explain what is going on.

Perhaps you can clarify how the 7200 gets to VLAN 613? It is not clear from your description whether the 7200 has an interface/subinterface in VLAN 613 and considers it as a connected interface or whether the 3750 is doing the routing for VLAN 613 (in which case the router still needs some route to get to VLAN 613). This is what puzzles me about the various show ip routes in your posting. The 7200 must have some route that gets it to VLAN 613 and that is what would be significant.

But I can explain what is happening without knowing the answer to the question that I just asked. Proxy ARP is enabled on the 7200 (it is enabled by default) and the 7200 is generating a proxy arp response to this request (while the destination station is also generating its own answer). Part of the operation of proxy ARP is that the router answers the ARP reuqest and puts its own MAC address into the response. I suspect that part of the issue is that something is misconfigured (why is the source address in the arp request 203.x.x.58?). If I knew more details of your environment I might have a more detailed answer. But the basic explanation is proxy arp.