Bug 216 - eth aliases don't work for IPs on different subnets
eth aliases don't work for IPs on different subnets
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
5.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
: 739 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1998-11-28 19:06 EST by Marc MERLIN
Modified: 2014-03-16 22:08 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-03-15 18:20:26 EST
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 Marc MERLIN 1998-11-28 19:06:45 EST
This is not a new bug, I'm just dumping my old bug reports
into your new database.

Whoever designed the IP aliases support made the assumption
that they are only used for web servers. In other words, the
initscript add host routes to those aliases.

After several hours of going through all the network
scripts, I used this fix. It's not necessarly great, but
it works. The patch is small enough to be applied by hand,
so I'm not sending a copy by mail.
It checks if there is already a route to the network the
alias belongs to, and adds one if it isn't the case

--- ifup.redhat Sat Aug 29 18:43:24
1998
+++ ifup        Sat Aug 29 19:18:46
1998
@@ -130,7 +130,9
@@

     ifconfig ${DEVICE} ${MACADDR:+hw ether $MACADDR}
${IPADDR} \\
       netmask ${NETMASK} broadcast
${BROADCAST}
-    if [ "$ISALIAS" = no ] ;
then
+
+    # Setup route to aliases if they're on a different
subnet
+    if [ "$ISALIAS" = no -o z"`route -n | sed "s/ .*//" |
grep ${NETWORK}`" = z
 ] ;
then
        route add -net ${NETWORK} netmask ${NETMASK}
${DEVICE}

else
        route add -host ${IPADDR} ${DEVICE}


Note that this will only work if aliased interfaces go
through ifup
This means that I had to patch ifup-aliases to completely
bypass linuxconf because there was no simple way to fix the
problem.

I think that the way you handle aliases is plain broken:
aliases should be normal devices that go through ifup.
However, at alias creation time, the GUI should give the
option of creating a "web style" alias and put a netmask of
255.255.255.255.
Initscripts could then treat the alias like a normal
interface (just like before you modified
/etc/rc.d/init.d/network to remove aliases with a egrep -v
'(ifcfg-lo|:))

Obviously, most of those problems go away with 2.1.x kernels
since the route to the local subnet is created
automatically. I guess that not fixing this and doing a
rewrite for 2.2 would be reasonable.
Comment 1 Jeff Johnson 1999-01-20 09:46:59 EST
*** Bug 739 has been marked as a duplicate of this bug. ***

If you have an alias device which is on another network than
the 'primary' device, ifcfg incorrectly STILL uses
'route add -host' instead of 'route add -net'.

For example, if eth0 is 10.0.0.1(/24) and eth0:1 is
10.0.1.1(/24), ifup will NOT add a route for the 10.0.1.0
network.


------- Additional Comments From dkl@redhat.com  01/08/99 20:18 -------
I was able to verify this bug as follows

Created a ifcfg-eth0 file with the following
DEVICE=eth0
IPADDR=192.168.1.1
NETWORK=192.168.1.0
NETMASK=255.255.255.0
BROADCAST=192.168.1.255
ONBOOT=yes

the an ifcfg-eth0:0 with the following

DEVICE=eth0:0
IPADDR=192.168.2.1
NETWORK=192.168.2.0
NETMASK=255.255.255.0
BROADCAST=192.168.2.255
ONBOOT=yes

After rebooting the devices were created correctly. But the routing
information showed that the 192.168.2.1 interface was added as a host
instead of 192.168.2.0 being added as a network as it should be

Destination   Gateway   Genmask        Flags Metric Ref   Use   Iface
192.168.2.1   *        255.255.255.255   UH     0    0     0    eth0:0
192.168.1.0   *        255.255.255.0     U      0    0     0    eth0
127.0.0.0     *        255.0.0.0         U      0    0     0    lo

I have assigned this to a developer.

------- Additional Comments From ayn2@cornell.edu  01/08/99 23:43 -------
This is a duplicate of #216
Comment 2 Bill Nottingham 1999-03-15 18:20:59 EST
fixed in initscripts-3.95-1.

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