Dual network cards with the same IP under linux

From: http://q2482696735.blog.163.com/blog/static/250606077201569029441/

Since one machine needs to have two network cards, the IP of the same network segment is set at the beginning, and it is found that the data is always sent from one network card, And there is no data flow on the other network card. I searched online and found a lot of the same problems:
1.
About the strange phenomenon that occurs when dual network cards are set to the same network segment IP and then connected to the switch. At the time, I didn't think much about it, thinking it was because of spanning trees, but later I thought it was not right.
I did a preliminary experiment: the

server is RHEL5 dual network card, eth0 is 234, eth1 is 233, and my local client is 172.
RHEL: ifconfig is as follows:
[root@server1 ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:29:A5:D5:A3
          inet addr:60.232.83.233 Bcast:60.232.83.255 Mask:255.255.255.128
is omitted. . . . . . .

eth1 Link encap:Ethernet HWaddr 00:0C:29:A5:D5:AD
          inet addr:60.232.83.234 Bcast:60.232.83.255 Mask:255.255.255.128Omitted
          . . . . . . . . .
lo Link encap: Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          is omitted. . . . . . . . .
Ping the two addresses on the client XP, are all through.
C:\ >ping 60.232.83.233
Pinging 60.232.83.233 with 32 bytes of data:
Reply from 60.232.83.233: bytes=32 time=9ms TTL=64
Reply from 60.232.83.233: bytes=32 time<1ms TTL=64

C: \ >ping 60.232.83.234
Pinging 60.232.83.234 with 32 bytes of data:
Reply from 60.232.83.234: bytes=32 time<1ms TTL=64
Reply from 60.232.83.234: bytes=32 time<1ms TTL=64
Use arp at this time –a View locally
C:\ >arp -a
Interface: 60.232.83.172 --- 0x20005
Internet Address Physical Address Type
60.232.83.129 00-04-96-1a-ca-60 dynamic
60.232.83.233 00-0c-29-a5-d5-a3 dynamic
60.232.83.234 00-0c-29-a5-d5-a3 dynamic

It is found that the MAC addresses of the two network cards are the same, that is, the mac address of eth0.
Now we [root@server1 ~]# ifconfig eth1 down
to disable eth1, and the results of ping 233 and 234 addresses are all OK.
It can be understood in this way, arp -a sees that the mac addresses of the two network cards obtained by local resolution are the same, the local area network is addressed through layer 2 and cannot involve layer 3 protocols such as ip, so ping whichever has the same mac address should be It works, but why do different IPs with the same mac address appear locally? What I see on Linux is obviously a different MAC address 00:0C:29:A5:D5:A3, 00:0C:29:A5:D5:AD

to continue the test, and now eth0 is prohibited.
[root@server1 ~]# ifconfig eth0 down
[root@server1 ~]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:0C:29:A5:D5:AD
          inet addr:60.232.83.234 Bcast:60.232.83.255 Mask:255.255. 255.128
          inet6 addr: fe80::20c:29ff:fea5:d5ad/64 Scope:Link
          omitted. . . . .
lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          is omitted. . . .

Local first arp -d to clear the cache. Then ping the IP addresses of the two network cards, you can still ping the two addresses.
Arp -a found:
C:\>arp -a
Interface: 60.232.83.172 --- 0x20005
Internet Address Physical Address Type
60.232.83.129 00-04-96-1a-ca-60 dynamic
60.232.83.233 00-0c-29 -a5-d5-ad dynamic
60.232.83.234 00-0c-29-a5-d5-ad dynamic

The Mac address becomes another mac address of eth1.
Then open eth0, and then ping test again. The result is as follows:
C:\>arp -a
Interface: 60.232.83.172 --- 0x20005
Internet Address Physical Address Type
60.232.83.129 00-04-96-1a-ca-60 dynamic
60.232.83.233 00-0c-29-a5-d5-a3 dynamic
60.232.83.234 00-0c-29-a5-d5-ad dynamic

This is the one normal address table.
At this time, eth0 is closed again, and the ping fails, because the mac address of 233 in the cache has been closed at this time.
After Arp -d, the ping can be completed. At this time, eth0 is still in the closed state, but the cache table is clear, so that the ping233 address can be pinged again, and the result is the mac address of 234.
C:\>arp -a
Interface: 60.232.83.172 --- 0x20005
Internet Address Physical Address Type
60.232.83.129 00-04-96-1a-ca-60 dynamic
60.232.83.233 00-0c-29-a5-d5-ad dynamic
60.232.83.234 00-0c-29-a5-d5-ad dynamic
At this time, eth0 is enabled, and now the two IPs in the local cache still correspond to the mac address of 234. Arp -d to clear it, this time ping 234 and then ping 233, the result is both 233 and eth0's mac address.

The experiment was done here, and the brain was a bit confusing. When the Linux server was replaced with Windows Server 2003, this problem did not appear.


C:\Documents and Settings\Administrator>ipconfig /all
Windows IP Configuration
   Host Name . . . . . . . . . . : newxyz-yz5l2clv
   Primary Dns Suffix . . . . . . :
   Node Type . . . . . . . . . . . : Unknown
   IP Routing Enabled. . . . . . . : No
   WINS Proxy Enabled. . . . . . . : No
Ethernet adapter Local Area Connection 3:
   Connection-specific DNS Suffix . :
   Description . . . . . . . . . : VMware Accelerated AMD PCNet Adapter #2
   Physical Address. . . . . . . . : 00-0C-29-68-03-AF
   DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . : 60.232.83.251
   Subnet Mask . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . :
Ethernet adapter Local Area Connection 2:
   Connection-specific DNS Suffix . :
   Description . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter
   Physical Address. . . . . . . . : 00-0C-29-68-03-A5
   DHCP Enabled. . . . . . . . . . : No
   IP Address . . . . . . . . . . . : 60.232.83.250
   Subnet Mask . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . :
ping two network cards locally Afterwards it shows the following:
C:\Documents and Settings\Administrator>arp -a

Interface: 60.232.83.198 --- 0x10005
Internet Address Physical Address Type
60.232.83.129 00-04-96-1a-ca-60 dynamic
60.232.83.250 00-0c-29-68-03-a5 dynamic 60.232.83.251 00-0c
-29-68-03-af dynamic
cannot be pinged.
Therefore, some mechanisms may be adopted for the network card under Linux. For example, first of all, the problem belongs to the automatic routing of the network card of the Linux system with dual network cards on the same network segment.
2. If the system has two independent network cards, and the IPs of the two network cards belong to the same subnet, then the IP of the latter network card will be automatically routed to the previous network card.
This means that data will be automatically routed to the preceding NIC. Without any settings, if the previous network card is disconnected or faulty (unplug the network cable or the network card finger is broken), you must use the command down to adjust the rear network card and then up, then the rear network card can be enabled. At this time, the two IPs are routed to the back network card at the same time, that is to say, the back network card has two IP addresses.
Of course, it is unreasonable to set two network cards to the same network segment.
My skills are really limited. These are all speculations after experiments, so I'm just throwing some light on it. I hope someone can explain it. Thank you. Experiment
another day to bond～～～～

======================
Conclusion:
This phenomenon is normal. We interpret it as the ability to correctly update the routing table when dual network cards are set on the same network segment under the Linux system. Therefore, the above situation occurs.
So the best way is to avoid doing this.


Second, the

problem:
I set two IPs on the same network segment (such as 10.1.0.1 and 10.1.0.2) on the two network cards, and it works normally, but if I unplug the network cable on the first fast network card (eth0) , the network is blocked. According to my assumption, when eth0 is blocked, the system should be able to go from eth1, so the network should still be connected, because I set the IP of the same network segment. Moreover, if I run the command ifdown eth0, the network is connected, that is, I can go from eth1.
Answer:


There is a problem with this configuration. When the network cable of eth0 is unplugged, the system cannot change from eth1 as you imagined, because there is a routing table in the system. When you set the IP, the routing table will be set at the same time. , when you need to access the outside, the system will go to the routing table to query. When the first matching item is queried, the item will be applied, that is, you will go from this path. When you unplug the eth0 network cable, The routing table is not changed at the same time, so the system will still try to go from eth0, and will not automatically change to go from eth1.
However, if you run the command ifdown eth0, the system will delete the eth0 route, and then you can leave from eth1, and the network will be connected.
You can use the command route to view the system routing table:
[root@localhost ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 eth0
10.0.0.0 * 255.0.0.0 U 0 0 0 eth1

As you imagined, if you want two NICs to work like a hot standby, that is, one can go from the other when one fails, then you can use NIC bonding, which provides support for NIC bonding in the core:
#insmod bonding mode=1
#ifconfig eth0 down
#ifconfig eth1 down
#ifconfig bond0 ipaddress
#ifenslave bond0 eth0
#ifenslave bond0 eth1
After this setting, eth0 and eth1 are bound to a new device: bond0, which can work in hot In the two modes of backup (mode=1) and load balancing (mode=0), your imagination can be realized in any working mode, that is, if you unplug any network cable, the network can still work normally, just load balancing The method requires two network cards to work at the same time, and the corresponding network ports on the switch are also required to be bound. For this, you need to check the use of the switch. If you do not know how to use the hot backup method, it is a network card. A network card is used for backup. If there is a problem with the working network card, such as a network segment, it will immediately switch to another network card to ensure smooth network. This method does not require special settings on the switch.

My conclusion:
From the second article, my problem and the first one should be caused by the route table.