RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 661204 - loopback interface alias problem
Summary: loopback interface alias problem
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.0
Hardware: All
OS: Linux
low
urgent
Target Milestone: rc
: ---
Assignee: Red Hat Kernel Manager
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-12-08 06:20 UTC by Maria
Modified: 2018-11-14 15:59 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
https://partner-bugzilla.redhat.com/show_bug.cgi?id=167022
Clone Of:
Environment:
Last Closed: 2011-02-28 04:11:48 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 167022 0 medium CLOSED IP aliasing problems on loopback device 2021-02-22 00:41:40 UTC

Internal Links: 167022

Description Maria 2010-12-08 06:20:25 UTC 
Hello,
    We were able to reproduce the problem on our virtual machines yesterday.The problem is a bug in OS itself.We should check if the fix is available as 
    Linux versions  are not backward compatible.We observed that the IP addresses in a particular series were not 
    accessible whenever an alias to the loopback was configured.However if the netmask to the loopback
    alias is changed to 255.255.255.255 the problem was not observed.This is in accordance with the bug reported below.


   https://partner-bugzilla.redhat.com/show_bug.cgi?id=167022

This is from the above bug statement:

Problem1:
If the alias is configured with

ifconfig lo:1 192.168.1.100 netmask 255.255.255.255 up

The machine will respond to ARPs for 192.168.1.100.  This is
wrong, because this is not an ethernet interface alias.
With a 2.0.x kernel (I've tried 2.0.36)this works perfectly
fine and the machine does not illegally answer ARPs.

Problem 2:(This was why all logins were going to wien07!!)

If I configure the alias with

ipconfig lo:1 192.168.1.100 netmask 255.255.255.0 up

then the illegal ARP replies stop, so the machine will no
longer answer to ARPs received on its ethernet interface for
IP 192.168.1.100.  However, with this statement, the linux
machine thinks that it itself is EVERY HOST on the
192.168.1.0 network.  It's actually rather amusing!!! A
telnet from this linux machine to any 192.168.1.X address
will give you a login prompt for the machine itself (as if
you'd done "telnet 127.0.0.1").  So, no communication is any
longer possible with the 192.168.1.0 network.  Again, with
2.0.36 this works just fine.

This is exactly in accordance with what is happening in our testbed.I don't think Linux versions are backward
compatible unlike Solaris and we should probably ask the person who is responsible for RHEL channel management
to take it up with RedHat.

As of now I will change the design to use 255.255.255.255 netmask for the loopback aliases when they are plumbed.


Regards,
    Maria
Comment 1 Maria 2010-12-08 06:22:01 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
https://partner-bugzilla.redhat.com/show_bug.cgi?id=167022
Comment 3 Caolan McNamara 2010-12-08 09:02:05 UTC 
Wrong component: librepository is a java library used by the pentaho reporting engine
Comment 4 Maria 2010-12-08 09:16:15 UTC 
Hello,
  Can you please help me out with this?Please forward it to the appropriate subsystem.

Regards,
    Maria
Comment 5 RHEL Program Management 2011-01-07 04:20:47 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 6 Max Matveev 2011-01-07 08:10:58 UTC 
arp_ignore/apr_announce tunables provide enough rope for anyone to deal
Problem 1.

Problem 2 is host behaving as designed - if someone telnets to any host in 
127/8 network the packets never go on the wire and just end up
on the open port on the same host. setting an ip address in 192.168.X/24 is
no different then setting the address in 127/8.

Basically, this is not a bug.
Comment 7 RHEL Program Management 2011-01-07 08:28:37 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 8 RHEL Program Management 2011-02-01 05:52:25 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 9 RHEL Program Management 2011-02-01 18:57:01 UTC 
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.
Comment 11 Max Matveev 2011-02-28 04:11:48 UTC 
arp_ignore/apr_announce tunables provide enough rope for anyone to deal
Problem 1.

Problem 2 is host behaving as designed - if someone telnets to any host in 
127/8 network the packets never go on the wire and just end up
on the open port on the same host. setting an ip address in 192.168.X/24 is
no different then setting the address in 127/8.
Note You need to log in before you can comment on or make changes to this bug.