Bug 739

Summary: ifup fails to add route for alias devices
Product: [Retired] Red Hat Linux Reporter: xeno
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.2CC: rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-01-20 14:46:09 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:

Description xeno 1999-01-08 01:13:38 UTC
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.

Comment 1 David Lawrence 1999-01-09 01:18:59 UTC
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.

Comment 2 Aleksey Nogin 1999-01-09 04:43:59 UTC
This is a duplicate of #216

Comment 3 Jeff Johnson 1999-01-20 14:46:59 UTC
*** This bug has been marked as a duplicate of 216 ***