From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; DT; Q312461; SV1; .NET CLR 1.1.4322) Description of problem: Customes gets tons of mails from arpwatch a day that MAC adress has changed for IP. This is a pendant to Bug 154302. The other Bug is on a free product. We have the same on RH3.0 (payed!) Version-Release number of selected component (if applicable): kernel-2.4.21-4.ELsmp How reproducible: Always Steps to Reproduce: 1. 2 NICS with different IP's 2. Sent ping to both IP's a few times 3. Arpwatch reported flip-flop at once Actual Results: Our customer gots thousand of mails a day from this Router which examines the network. He is not very happy about this. Another OS like windows on the same hardware doesn't have this results. Expected Results: The IP, which are configured fix for every NIC should stay fixed and not switching between the physcially NIC's. Additional info: We don't know what happens if Layer-3 switches were used. Perhaps the recognize a arp-spoofing ??
As this appears to be something for which you have urgency, you would be best off going through support. In order to file a support issue, please either contact Red Hat's Technical Support line at 888-GO-REDHAT or file a web ticket at http://www.redhat.com/apps/support/. Bugzilla is not an official support channel, has no response guarantees, and may not route your issue to the correct area to assist you. Using the official support channels above will guarantee that your issue is handled appropriately and routed to the individual or group which can best assist you with this issue and will also allow Red Hat to track the issue, ensuring that any applicable bug fix is included in all releases and is not dropped from a future update or major release.
Hello, Stefan. Could you please upgrade to the latest officially supported RHEL3 kernel, which is kernel version 2.4.21-32.0.1.EL (advisory RHSA-2005:472), and let us know whether this problem still occurs? Also, when you get an Issue Tracker number from Red Hat's Technical Support, could you please list it in this bugzilla? Thanks in advance.
(In reply to comment #1) > As this appears to be something for which you have urgency, you would be > best off going through support. In order to file a support issue, please > either contact Red Hat's Technical Support line at 888-GO-REDHAT or file > a web ticket at http://www.redhat.com/apps/support/. Bugzilla is not an > official support channel, has no response guarantees, and may not route > your issue to the correct area to assist you. Using the official support Hello we buy RH3 from our reseller Fujitsu-Siemens. Because of this fact we are unable to oben support request direct and have to play the communication game through them.
Reverting to NEEDINFO_REPORTER until we find out whether this problem can be reproduced in kernel version 2.4.21-32.0.1.EL.
With this parameter this arp requests works as expected: 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 would 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 by particular 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 of conf /{all,interface}/arp_filter is set to TRUE, it will be disabled otherwise
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.