After USG5330 public network address mapped IP address prompts ARP conflicts, the address can’t be used

Publication Date:  2012-11-27 Views:  341 Downloads:  0
Issue Description
The customer said that after ARP conflicts, they can only ping an IP in address mapping on equipment. At the same time, the mapping server also can’t be accessed from external network.
2011-10-09 16:24:53 USG5330 %%01ARP/4/ARP_DUPLICATE_IPADDR(l): Receive an ARP packet with duplicate ip address 1.1.1.2 from Eth-Trunk1, source MAC is 0021-97c4-6f7f
2011-10-09 16:24:39 USG5330 %%01ARP/4/ARP_DUPLICATE_IPADDR(l): Receive an ARP packet with duplicate ip address 1.1.1.2 from Eth-Trunk1, source MAC is 0021-97c4-6f7f
2011-10-09 16:24:37 USG5330 %%01ARP/4/ARP_DUPLICATE_IPADDR(l): Receive an ARP packet with duplicate ip address 1.1.1.2 from Eth-Trunk1, source MAC is 0021-97c4-6f7f
2011-10-09 16:24:36 USG5330 %%01ARP/4/ARP_DUPLICATE_IPADDR(l): Receive an ARP packet with duplicate ip address 1.1.1.2 from Eth-Trunk1, source MAC is 0021-97c4-6f7f
2011-10-09 16:24:34 USG5330 %%01ARP/4/ARP_DUPLICATE_IPADDR(l): Receive an ARP packet with duplicate ip address 1.1.1.2 from Eth-Trunk1, source MAC is 0021-97c4-6f7f
Alarm Information
None.
Handling Process
The customer said a PC in external network after configured the public IP address, it can be used normally, as long as can access the internal network can ping pass, the eliminate the possibility that the address has been configured in other place.
Check the configuration of the equipment again:
nat address-group 1 2.2.2.1 2.2.2.1
nat server 0 protocol tcp global 2.2.2.2 ftp inside 10.10.10.1 ftp
nat server 1 protocol tcp global 2.2.2.2 www inside 192.168.1.184 www no-reverse
nat server 2 global 1.1.1.4 inside 192.168.1.181
nat server 3 global 1.1.1.3 inside 192.168.1.182
nat server 5 global 1.1.1.1 inside 192.168.1.184 no-reverse
nat server 7 global 1.1.1.2 inside 192.168.1.183 //can’t be used ip:1.1.1.2
nat server 9 global 1.1.1.0 inside 192.168.1.185
nat server 10 global 1.1.1.9 inside 192.168.30.209
nat server 11 global 1.1.1.5 inside 10.10.10.149
nat server 12 global 1.1.1.6 inside 192.168.1.152
nat server 13 global 1.1.1.7 inside 192.168.1.151
nat server 14 global 1.1.1.8 inside 192.168.1.150
nat server 17 protocol tcp global 1.1.1.10 www inside 10.10.10.1 www
#
firewall statistic system enable
#
interface Eth-Trunk1
mac-address 0022-a102-7dd5
ip address 2.2.2.254 255.255.255.128
arp multi-mac-permit
#
interface Eth-Trunk2
mac-address 0022-a102-7dd4
ip address 10.10.10.253 255.255.255.0
#
interface GigabitEthernet0/0/0
ip address 192.168.0.1 255.255.255.0
The equipment hasn’t configured the IP address of 1.1.1.0 network segment. Customers say they configured the network segment in the far end equipment, there is this segment routing here. There is no idea here, because the IP of the other same segment can also be used normally. But the customer says the conflict is really caused by someone accidentally configured this IP. But they have checked it out and modified it.
Then we thought that due to it is not in the same network segment with the far end equipment, whether it is has been configured in other places, it won't send the ARP request of 1.1.1.0 segment to the usg5330. And it hasn’t been configured on the interface of our equipment, so it also won't send ARP request. So we finally thought that in our equipment send a free ARP to the far end equipment. But there is no IP address of 1.1.1.0 network segment in interface, so we finally configure this IP as sub ip in the interface of equipment. After configured, we can ping the far end equipment and can access the mapping.
Root Cause
Doubt that they have configured the address in other position of the public network, which causes address conflict. 
Suggestions
It is suggested that when the public network IP of address mapping and the public network IP of outbound interface are not in the same network segment, we had better configure the IP address in the sub address of the interface, then we can avoid a lot of problems.

END