Dears,
I have installed RHEL 5.8 on HP Proliant DL380 machine.
I have configured two eth ports for signalling purpose as shown below:

[root@tig0eir2 network-scripts]# cat ifcfg-eth1
# Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe
DEVICE=eth1
ONBOOT=yes
BOOTPROTO=none
IPADDR=10.23.28.39
NETMASK=255.255.255.0
GATEWAY=10.23.30.25
USERCTL=no
HWADDR=2C:76:8A:4E:FF:C1
[root@tig0eir2 network-scripts]# cat ifcfg-eth2
# Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe
DEVICE=eth2
ONBOOT=yes
BOOTPROTO=none
IPADDR=10.23.28.40
NETMASK=255.255.255.0
GATEWAY=10.23.30.25
USERCTL=no
HWADDR=2C:76:8A:4E:FF:C2

Issue Description: when an ARP broadcast message comes to my machine as "who has 10.23.28.39?"
i took the wireshark trace on port eth1, in the ARP response my machine is sending 10.23.28.39 is at 2C:76:8A:4E:FF:C1

However, when an ARP broadcast message comes to my machine as "who has 10.23.28.40?"
in the ARP response my machine is sending 10.23.28.40 is at 2C:76:8A:4E:FF:C1

From this it clears that; the RHEL machine is replying with same MAC address for different IP addresses in ARP response.

Please help to resolve this issue. Thanks in advance

It seems that somehow both IP addresses have been assigned to the same interface.

Could you post the output of ifconfig -a?

eth1 Link encap:Ethernet HWaddr 2C:76:8A:4E:FF:C1
inet addr:10.23.28.39 Bcast:10.23.28.255 Mask:255.255.255.0
inet6 addr: fe80::2e76:8aff:fe4e:ffc1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:42141 errors:0 dropped:0 overruns:0 frame:0
TX packets:7286 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2752807 (2.6 MiB) TX bytes:470797 (459.7 KiB)
Interrupt:91

eth2 Link encap:Ethernet HWaddr 2C:76:8A:4E:FF:C2
inet addr:10.23.28.40 Bcast:10.23.28.255 Mask:255.255.255.0
inet6 addr: fe80::2e76:8aff:fe4e:ffc2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:42090 errors:0 dropped:0 overruns:0 frame:0
TX packets:7255 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2746437 (2.6 MiB) TX bytes:468361 (457.3 KiB)
Interrupt:83

OK, so you have two different interfaces with IP addresses in the same IP network. That configuration only makes sense if both interfaces are connected to the same physical network, and under those circumstances the behaviour you're seeing is actually expected.

As this article explains, the reason is as follows: When the Linux IP stack receives an ARP request for an IP address assigned to an interface, the ARP reply will be sent from the interface that received the request, using the MAC address of that interface.

This behaviour is perhaps somewhat counter-intuitive, but it seems to be a valid interpretation of the relevant RFCs.

1 members found this post helpful.

OK, so you have two different interfaces with IP addresses in the same IP network. That configuration only makes sense if both interfaces are connected to the same physical network, and under those circumstances the behaviour you're seeing is actually expected.

As this article explains, the reason is as follows: When the Linux IP stack receives an ARP request for an IP address assigned to an interface, the ARP reply will be sent from the interface that received the request, using the MAC address of that interface.

This behaviour is perhaps somewhat counter-intuitive, but it seems to be a valid interpretation of the relevant RFCs.

1 members found this post helpful.

The MAC address is sent same for both eth1 and eth2.

When there is a different MAC address for each eth port.

My question is: why it is replying with the same MAC address(2C:76:8A:4E:FF:C1) of ETH1 for both the IP's(10.23.28.39 & 10.23.28.40)?

I hope you got my point.

I did get your point, and I did explain. Whenever Linux receives an ARP request on whatever interface for an IP address assigned to any interface, it replies using the MAC address of the interface that received the ARP replay, which may or may not be the interface with the relevant IP address.

You get replies from eth0 because eth0 received the ARP request a few microseconds before the request arrived at eth1. It's all in the linked article.