Bug 167794 - NIC: IP switch, flip flop reported by arpwatch
NIC: IP switch, flip flop reported by arpwatch
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: David Miller
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-08 05:32 EDT by Stefan Marquardt
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 14:54:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stefan Marquardt 2005-09-08 05:32:03 EDT
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 ??
Comment 1 Suzanne Hillman 2005-09-08 14:06:56 EDT
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.
Comment 2 Ernie Petrides 2005-09-08 18:18:42 EDT
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.
Comment 3 Stefan Marquardt 2005-09-09 11:14:01 EDT
(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.
Comment 4 Ernie Petrides 2005-09-09 16:19:01 EDT
Reverting to NEEDINFO_REPORTER until we find out whether this problem
can be reproduced in kernel version 2.4.21-32.0.1.EL.
Comment 5 Stefan Marquardt 2005-09-13 02:54:21 EDT
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
Comment 6 RHEL Product and Program Management 2007-10-19 14:54:43 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.