Today I saw a problem in Cu: http://linux.chinaunix.net/bbs/thread-1021489-1-1.html
This is a strange phenomenon when the dual network adapter sets the same IP address segment and connects to the switch. At that time, I didn't think much about it. I thought it was a tree generation, but later I thought it was not right.
I made a preliminary experiment:
The server is rhel5 dual Nic, eth0 is 234, eth1 is 233, and my local client is 172.
RHEL: ifconfig:
[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
.......
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
.........
Lo link encap: local loopback
Inet ADDR: 127.0.0.1 mask: 255.0.0.0
.........
Ping both IP addresses on the client XP.
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 = 9 ms TTL = 64
Reply from 60.232.83.233: bytes = 32 time <1 ms 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 <1 ms TTL = 64
Reply from 60.232.83.234: bytes = 32 time <1 ms TTL = 64
At this time, use ARP-a to check locally
C:/> ARP-
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
The MAC address of the two NICS is the same, that is, the MAC address of eth0.
Now we [root @ server1 ~] # Ifconfig eth1 down
To disable eth1. The Ping 233 and 234 addresses are all connected.
It can be understood here that ARP-A sees that the MAC addresses of the two NICs resolved locally are the same, and the LAN is a layer-2 addressing that cannot involve layer-3 protocols such as IP addresses, therefore, if the MAC address is the same, Ping should be successful. But why does different local IP addresses have the same MAC address? In Linux, we can see different MAC addresses: 00: 0C: 29: A5: D5: A3, 00: 0C: 29: A5: D5: ad.
Continue the test. Disable eth0.
[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
.....
Lo link encap: local loopback
Inet ADDR: 127.0.0.1 mask: 255.0.0.0
Inet6 ADDR: 1/128 scope: Host
....
Local ARP-D to clear the cache first. Then ping the IP addresses of the two NICs. You can still ping the two IP addresses.
After ARP-A is found:
C:/> ARP-
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 is another MAC address of eth1.
Enable eth0, and ping it again. The result is as follows:
C:/> ARP-
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 a normal address table.
If you disable eth0 again, the Ping will fail because the 233 MAC address in the cache has been disabled.
After ARP-D, you can ping the table. At this time, eth0 is still disabled, but the cache table is clear, so ping233 can be pinged, the result is a 234 MAC address.
C:/> ARP-
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
Enable eth0. Now, the two IP addresses in the local cache still correspond to the MAC address of 234. ARP-D: Clear it. Ping 234 and then Ping 233 this time. Both are 233 MAC addresses that are both eth0.
The experiment is a bit messy here. If you change this Linux server to Windows Server 2003, this problem will not occur.
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 connection 3:
Connection-specific DNS suffix .:
Description ......: VMWare accelerated amd pcnet adapter #2
Physical address ......: 00-0c-29-68-03-af
DHCP enabled...
IP address ......: 60.232.83.20.
Subnet Mask ......
Default Gateway .........:
Ethernet Adapter local connection 2:
Connection-specific DNS suffix .:
Description ......: VMWare accelerated amd pcnet Adapter
Physical address ......: 00-0c-29-68-03-a5
DHCP enabled...
IP address ......: 60.232.83.250
Subnet Mask ......
Default Gateway .........:
After the two NICs are pinged locally, the following information is displayed:
C:/Documents and Settings/Administrator> ARP-
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.000000-0c-29-68-03-af dynamic
No Nic can be pinged.
Therefore, Nic may adopt some mechanisms in Linux. For example, first, the problem is that the NIC is automatically routed to the Linux system in the same network segment of the dual Nic.
2. If the system has two independent NICs and the IP addresses of these two NICs belong to the same subnet, the IP addresses of the later NICs are automatically routed to the previous Nic.
That is to say, the data will be automatically routed to the previous Nic. If the front network adapter is disconnected or faulty (the network adapter is disconnected or the network adapter is broken) without any settings, you must run the following command to call the back Nic and then raise it, the NIC can be enabled later. At this time, the two IP addresses are routed to the backend Nic, that is, the backend Nic has two IP addresses.
Of course, it is unreasonable to set two NICs to the same network segment.
My technology is really limited. These are the guesses after the experiment. I hope someone can explain them. Thank you.
Try again bond ~~~~
================================
Conclusion:
This is normal. We understand that in Linux, the dual-network card cannot correctly update the route table when setting the same network segment. This may cause the above situation.
So the best way is to avoid this operation.
================================