# [SOLVED] one MAC address for several IPs

## your_WooDness

Hi out there,

I am having a very strange problem with Intel NICs and their MAC addresses. 

For example a server with 2 Intel NICs: if you enter a "ifconfig" you get two IP addresses and two MAC addresses. Everything as it should be. If I e.g. ping both IP addresses from another host and then check the arp-table, I will get one and the same MAC address for both IP addresses. I hope the folllowing snippit will make it clear...

[edit]

machine A has the IP 10.0.0.10

machine B has the IPs 10.0.0.20 and 10.0.0.21

[/edit]

Locally on B the "ifconfig" output of the machine with two intel NICs shows this

```

rose src # ifconfig 

eth0      Link encap:Ethernet  HWaddr de:ad:be:ef:22:78

          inet addr:10.0.0.20  Bcast:10.0.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:873 errors:0 dropped:0 overruns:0 frame:0

          TX packets:701 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:84366 (82.3 KiB)  TX bytes:161631 (157.8 KiB)

eth1      Link encap:Ethernet  HWaddr de:ad:be:ef:22:79

          inet addr:10.0.0.21  Bcast:10.0.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:1 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:42 (42.0 B)  TX bytes:0 (0.0 B)

```

When I now ping these two addresses on B from A and have a look at my arp-table of A:

```

golem wood # ping 10.0.0.20

PING 10.0.0.20 (10.0.0.20) 56(84) bytes of data.

64 bytes from 10.0.0.20: icmp_seq=1 ttl=64 time=0.443 ms

golem wood # ping 10.0.0.21

PING 10.0.0.21 (10.0.0.21) 56(84) bytes of data.

64 bytes from 10.0.0.21: icmp_seq=1 ttl=64 time=2.00 ms

golem wood # arp

Address                  HWtype  HWaddress           Flags Mask            Iface

localhost                ether   00:13:49:07:69:d7   C                     eth0

10.0.0.20                ether   de:ad:be:ef:22:78   C                     br0

10.0.0.21                ether   de:ad:be:ef:22:78   C                     br0

*** this example is kvm based, but also appears on vmware and bare metal ***

```

...I see that I have the same MAC address for 10.0.0.20 and 10.0.0.21 in the arp-table of A. Well, this can lead to a very strange behaviour in the network, I dont't think I have to go on... =0)

The first time I have encountered this problem I was troubleshooting an IPMI problem for a customer of my company and I thought it would be related to IPMI. But it's not, 'cause I have another server completely without IPMI (2 onboard NICs and a QuadPort Intel NIC) which shows the same problem: one MAC address for several IP addresses.

I then doublechecked this within a vmware based virtual machine and a kvm based virtual machine, which both emulate a e1000 NIC. Both installations showed the same problem. One installation is a SuSE Enterprise 10 SP1 and the other one a gentoo installation. So I think the problem is rather related to the e1000 module than hardware related.

Has anyone seen this already and/or has a workaround for this? 

WooDLast edited by your_WooDness on Mon Jan 26, 2009 6:26 am; edited 2 times in total

----------

## cyrillic

I am not sure having eth0 and eth1 on the same subnet accomplishes anything.  Most likely, all the traffic is going through eth0, and eth1 is just taking up space.

What does "route -n" look like ?

----------

## linuxtuxhellsinki

 *your_WooDness wrote:*   

> 
> 
> ```
> 
> golem wood # arp
> ...

 

Iface = br0   :Exclamation: 

----------

## your_WooDness

Hi,

this is just an example and br0 does not really matter, 'cause I have seen this on br0, eth0 and eht1 (baremetal). This has absolutely nothing to do with a bridge config or bondage config. The NICs, either VM or baremetal, are just configured the normal way.

WooD

----------

## your_WooDness

Hi there,

"route -n" gives the following:

```

golem wood # route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 br0

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo

0.0.0.0         192.168.1.1     0.0.0.0         UG    3      0        0 eth0

```

I had a closer look on this and tried several Intel e1000 modules, but the problem remains. Maybe I haven't found the correct one yet. =0)

Then I tried to add the correct MAC addresses statically in the arp-table of A via:

```

golem wood # cat /etc/ethers

10.0.0.20 de:ad:be:ef:22:78

10.0.0.21 de:ad:be:ef:22:79

golem wood # arp -f /etc/ethers

```

Then I had the correct MAC addresses in my arp-table on A, but the 10.0.0.21 address was unreachable. Setting the arp table back for 10.0.0.21 on the "wrong" MAC address (de:ad:be:ef:22:78 ), the 10.0.0.21 was reachable again.

Hm...strange. When you have a look at the activity LEDs of the two NICs of machine B only one is blinking and shows activity when you ping both IP addresses of machine B. So physically the traffic through the network must be directed through 1 NIC on machine B and somehow it must be redirected on machine B to the correct IP address.

Well, I think this should also affect the performance of the network connections when two or more IP addresses share one physical port, but I haven't made any performance tests yet.

I also disconnected the cable of the NIC with 10.0.0.20 / de:ad:be:ef:22:78, both IP addresses of machine B were not reachable anymore, although the NIC with 10.0.0.21 / de:ad:be:ef:22:79 showed a hardware link. If you disconnect the cable of NIC 10.0.0.21 / de:ad:be:ef:22:79, both IP addresses of machine B are still available.

WooD

----------

## your_WooDness

Hi,

just a little update. I have tried to set two different IP addresses for the NICs:

```

rose src # ifconfig

eth0      Link encap:Ethernet  HWaddr de:ad:be:ef:22:78

          inet addr:10.0.0.20  Bcast:10.0.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:873 errors:0 dropped:0 overruns:0 frame:0

          TX packets:701 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:84366 (82.3 KiB)  TX bytes:161631 (157.8 KiB)

eth1      Link encap:Ethernet  HWaddr de:ad:be:ef:22:79

          inet addr:192.168.1.100  Bcast:192.168.1.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:1 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:42 (42.0 B)  TX bytes:0 (0.0 B)

```

If I then ping both IP addresses and have a look at my arp table everything is OK:

```

bear wood # arp

Address                  HWtype  HWaddress           Flags Mask            Iface

localhost                ether   00:13:49:07:69:d7   C                     eth0

10.0.0.20                ether   de:ad:be:ef:22:78   C                     br0

192.168.1.100            ether   de:ad:be:ef:22:79   C                     br0 

```

If I switch back to my initial IP setup 10.0.0.20 and 10.0.0.21 I will have the same MAC address again in the arp cache. Well, the problem seems only to occur if you have the same subnet on the NICs.

WooD

----------

## your_WooDness

Hi there,

the problem I have reported in this thread is the linux arp flux problem. Haven't seen this before...

WooD

----------

