When we look at the driver of the Intel 1000 PT Nic today, we have the following information:
Multiple interfaces on same Ethernet broadcast networkecho 1>/proc/sys/NET/IPv4/CONF/All/arp_filter
Google: Someone has tried this. The excerpt is as follows:
Http://blog.sina.com.cn/s/blog_544465b0010000kf.html
Problems with multiple NICs in the same network segment(2005-11-23
23:38:42)
| |
Classification: Network Security |
Keywords: strict interface ARP, multi-link, multipath, multiple network cards on same subnet problem the domain name that provides music download traffic is forced to 1 Gbps, but the system connection is not high, the server uses dell2850, two GBE network ports are loaded on the server, and two Intel GBE network adapters are inserted. Therefore, we plan to expand the network bandwidth of the system through multi-nic load balancing. But I don't want to use the multi-network interface, so I feel that it is not flexible, so I decided to use advanced routing to solve this problem. Check man IP, and then start to do: 1) Configure four addresses for the four network ports. 2) add all four addresses to Server Load balancer on bigip. 3) use IP commands to implement multi-nic Server Load balancer IP Route replace default equalize scope global nexthop via 172.24.x.11 Dev eth0 weight 1 nexthop via 172.24.x.11 Dev eth1 weight 1 nexthop via kernel Dev eth2 weight 1 nextho eth3 weight 1 immediately saw that all traffic was evenly distributed to four network ports, but a new problem occurred, A large amount of IP address conflict information appears in the bigip log: Nov 23 19:18:56 tc04 kernel: ARP info overwritten for 172.24.x.30 by 00: 14: 22: 1b: 94: DC
Nov 23 20:30:24 tc04 kernel: ARP info overwritten for 172.24.x.30 by 00: 04: 23: C0: 5C: 88
Nov 23 20:30:28 tc04 kernel: ARP info overwritten for 172.24.x.30 by 00: 14: 22: 1b: 94: DC
Nov 23 21:03:14 tc04 kernel: ARP info overwritten for 172.24.x.30 by 00: 14: 22: 1b: 94: dd finds that the MAC addresses that cause IP conflicts are the MAC addresses of other network ports on this machine, which is strange. Through tcpdump packet capture and analysis of ARP information, it is found that the IP address used in Linux's response to ARP requests is not strictly limited, which leads to this problem. Soon Google to this article: [Patch] strict interface ARP patch for Linux 2.4.2 and then go to the http://www.linuxvirtualserver.org/find the http://www.linuxvirutalserver.org/docs/arp.html to find no available information, then, the system enters the/proc/sys/NET/IPv4/CONF/all directory and finds out what the clue is: solution 2.6. The three files arp_announce, arp_ignore, arp_filter go to/usr/src/Linux/documentation/networking/ip-sysctl.txt to find the relevant description: arp_filter-Boolean
1-allows you to have multiple network interfaces on the same
Subnet, and have the ARPS for each interface be answered
Based on whether or not the kernel wowould route a packet from
The ARP 'd IP out that interface (therefore you must use source
Based Routing for this to work). In other words it allows control
Of which cards (usually 1) will respond to an ARP request. 0-(default) the kernel can respond to ARP requests with addresses
From other interfaces. This may seem wrong but it usually makes
Sense, because it increases the chance of successful communication.
IP addresses are owned by the complete host on Linux, not
Particle interfaces. Only for more complex setups like load-
Balancing, does this behaviour cause problems. arp_filter for the interface will be enabled if at least one
Conf/{all, interface}/arp_filter is set to true,
It will be disabled otherwisearp_announce-integer
Define different restriction levels for announcing the local
Source IP address from IP packets in ARP requests sent on
Interface:
0-(default) use any local address, configured on any interface
1-try to avoid local addresses that are not in the target's
Subnet for this interface. This mode is useful when target
Hosts reachable via this interface require the Source IP
Address in ARP requests to be part of their logical network
Configured on the processing ing interface. When we generate
Request we will check all our subnets that include
Target IP and will preserve the source address if it is from
Such subnet. If there is no such subnet we select Source
Address according to the rules for level 2.
2-always use the best local address for this target.
In this mode we ignore the source address in the IP packet
And try to select local address that we prefer for talks
The target host. Such local address is selected by looking
For primary IP addresses on all our subnets on the outgoing
Interface that include the target IP address. If no suitable
Local Address is found we select the first local address
We have on the outgoing interface or on all other interfaces,
With the hope we will receive reply for our request and
Even sometimes no matter the source IP address we announce. The max value from CONF/{all, interface}/arp_announce is used. Increasing the restriction level gives more chance
Refreshing answer from the resolved target while decreasing
The level announces more valid sender's information. arp_ignore-integer
Define different modes for sending replies in response
Protected ed ARP requests that resolve local target IP addresses:
0-(default): reply for any local target IP address, configured
On any interface
1-reply only if the target IP address is local address
Configured on the incoming Interface
2-reply only if the target IP address is local address
Configured on the incoming interface and both with
Sender's IP address are part from same subnet on this interface
3-do not reply for local addresses configured with scope host,
Only resolutions for global and link addresses are replied
4-7-Reserved
8-do not reply for all local addresses the max value from CONF/{all, interface}/arp_ignore is used
When ARP request is already ed on the {interface} Hey,: echo 2>/proc/sys/NET/IPv4/CONF/All/arp_announceecho 1>/proc/sys/NET/IPv4/CONF/All/arp_ignore or Echo 1>/proc/ sys/NET/IPv4/CONF/All/arp_filter get it done now! Continue to google some information, found that the first two kernel control seems to be in the 2.6.5 Implementation of the recommendation with the first two, arp_filter should also be able to solve, we feel that the first two are more detailed control implementations of arp_filter. We also found that there is also a section in the Inter Pro/1000 NIC Driver Installation Guide: multiple interfaces on same Ethernet Broadcast Network
------------------------------------------------------ Due to the default ARP behavior on Linux, it is not possible to have
One system on two IP networks in the same Ethernet broadcast domain
(Non-partitioned switch) behave as expected. All Ethernet interfaces
Will respond to IP traffic for any IP address assigned to the system.
This results in unbalanced receive traffic. If you have multiple interfaces in a server, either turn on ARP
Filtering by entering: Echo 1>/proc/sys/NET/IPv4/CONF/All/arp_filter
(This only works if your kernel's version is higher than 2.4.5), or, install the interfaces in separate broadcast domains (either
In different switches or in a switch partitioned to VLANs). Reference: http://linux-ip.net/html/ether-arp.htmlhttp://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.arp_problem.htmlhttp://www.ssi.bg /~ Ja/# arp_announce
