Bug 661204
| Summary: | loopback interface alias problem | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Maria <maria.francis> |
| Component: | kernel | Assignee: | Red Hat Kernel Manager <kernel-mgr> |
| Status: | CLOSED NOTABUG | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
| Severity: | urgent | Docs Contact: | |
| Priority: | low | ||
| Version: | 6.0 | CC: | jwest, makc |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
https://partner-bugzilla.redhat.com/show_bug.cgi?id=167022
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-02-28 04:11:48 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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
Wrong component: librepository is a java library used by the pentaho reporting engine Hello,
Can you please help me out with this?Please forward it to the appropriate subsystem.
Regards,
Maria
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. 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. 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. 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. 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. 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. |
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