%IP-4-DUPADDR (HSRP and Static NAT)

Unanswered Question

Hello Experts!

We have been recieveing these messages on all of our 6509's and I would like to make it stop!

%IP-4-DUPADDR: Duplicate address on Vlan30, sourced by 0005.317b.b000
%IP-4-DUPADDR: Duplicate address on Vlan30, sourced by 0005.317b.b000
%IP-4-DUPADDR: Duplicate address on Vlan30, sourced by 0005.317b.b000
%IP-4-DUPADDR: Duplicate address on Vlan30, sourced by 0005.317b.b000
%IP-4-DUPADDR: Duplicate address on Vlan30, sourced by 0005.317b.b000

What I have found is that the addresses in this list are included in static NAT statements which are identical on both 6509's (we are running HSRP). Here is an example of what each one has

ip nat inside source static

So, from what I have figured out so far, if static NAT is configured with the same IP on both 6509's you will get this message.

Does anyone know how to resolve this issue (or at least suppress it)?

We are running Cat 6509's on 12.2(18)SXF9 code

SV-Dist-2#sh ver | in .bin
System image file is "sup-bootdisk:s72033-ipservices_wan-vz.122-18.SXF9.bin"



I have this problem too.
1 vote
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 1 (1 ratings)
Peter Paluch Fri, 08/20/2010 - 10:23


If you perform static NAT and the global address is in the IP space of the outside interface, the router will automatically create an ARP entry for that IP address and will answer with its MAC address to ARP requests. This is probably what you are observing.

The problem can be solved by adding the no-alias parameter at the end of the ip nat command, i.e.:

ip nat inside source static no-alias

Please note that under normal circumstances, this would result in the global IP address being unreachable because the router would not respond to ARP queries for the In your case, however, the outside interface seems to be the Vlan30 on which the HSRP is running, so your router will actually respond and it will respond with the virtual MAC address.

Best regards,


David Aicher Fri, 08/20/2010 - 10:51


The config you are attempting is likely unsupported.  Cisco has a feature called stateful nat which would probably work for what you are trying to do but this feature is not supported on the cat6500.

The reason that you see the error message is that both switches create an ip alias for the translated address.  You can verify this with the "show ip alias" command.  This allows the router(or switch) to reply to arp requests so return traffic is routed correctly to the nat device.  

In this case each switch would keep a separate nat table.  This setup will work as long as traffic is routed through the same device in both directions.  If traffic is translated and happens to return on the opposite peer switch then the flow will be broken. 

If you need this type of redundancy Cisco recommends using ASA pair for stateful failover.    Alternately you could redesign and put nat on a single device in the path to avoid the redundant configuration.

I hope this helps.

Dave Aicher

Hey Dave,

The idea behind identical NAT statements was to add some resiliency in the event of a 6509 failure, however our syslog servers show massive amounts of these error messages across the board. I suppose the few NAT's we do have would be the least of our worries at that point in time anyway

I did add the *no-alias* just to see and lost packets

Pinging with 32 bytes of data:

Reply from bytes=32 time=2ms TTL=252 (Before the change to no-alias)

Reply from bytes=32 time=2ms TTL=252 (Before the change to no-alias)

Reply from bytes=32 time=2ms TTL=252 (Before the change to no-alias)
Request timed out. (After the change)
Request timed out. (After the change)
Request timed out. (After the change)
Request timed out. (After the change)
Request timed out. (After the change)
Reply from bytes=32 time=50ms TTL=252 (changed back)

Reply from bytes=32 time=2ms TTL=252 (changed back)

I left it off since it seems to break the NAT (or so it seemed?)

SNAT looks like what we want but I guess that wont happen. I guess we will either live with the errors or take them off one of the switches.

Thanks for your help!

Peter Paluch Fri, 08/20/2010 - 11:24


Please can you describe your network in more detail? What is your "inside" and "outside" network? Why do you actually translate one private IP into another? If possible it would be very good to post a diagram of your network.


Best regards,


Hey Peter,

Back in the day when they were designing the network they had decided to use multiple ranges across our campuses (e.x. 10., 172.16., and 192.168..)

Our corporate office allocates blocks of 10 networks and then it's up to local engineers to break them up as we see fit. The issue we are facing now is that the original designers of our network mixed the 172's and 192's with the 10 networks.

It's my understanding that certain things would never need to talk to the corporate office and for those the 172 and 192's were used. While this may have been true at one point in time things are starting to evolve and change, certain things in these ranges need to talk to our corporate office now.

The issue is that corporate controls the routers that connect back to headquarters, and they will never route for anything other than the 10 networks.

So our *temp* solution was to throw NAT at it, and it's working OK thus far, however the more devices that need the ability of talking to corporate the more NAT's we will need. Not only is this a bad design, but it's a waste of IP's as well.

A long term solution would be  to migrate away from these 172 and 192 networks, however this will take some time, NAT is our *temp* solution. It's just to get things talking to back to our corporate office...

Peter Paluch Fri, 08/20/2010 - 11:20


Note that Steve is using static translations. With only static translations, there should not be any significant problem (please correct me if I am wrong). Of course, if there are also dynamic translations in place, there will be broken flows if the active router gets changed.

Best regards,


David Aicher Wed, 08/25/2010 - 09:28


I agree that in theory a static nat scenario should work, although it will throw the error message and possibly traffic could take an asymetric path.  I am not sure Cisco would support this for nat resilency.  In addition it is not scalable to more than a handful of addresses that need to be translated.  Beyond that adding or changing NAT would start to become a daunting task. Not to mention the scalability with the number of addresses needed.



alfonso.cornejo Fri, 09/17/2010 - 12:33

Hi Steve,

I'm facing the same issue, at the end were you able to find a way on how to get rid of those logs???



This Discussion