From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030901

Description of problem:
ifcfg-eth0-range1 inherits the IPADDR from ifcfg-eth0 and then uses the netmask
from ifcfg-eth0-range1 to define a new ( sometimes wrong ) local subnet.  This
can cause  routing problems.

Problem occurs as far back as RH7.3

Version-Release number of selected component (if applicable):
initscripts-7.14-1

How reproducible:
Always

Steps to Reproduce:
1. define eth0 to be a /29 subnet ( mask 255.255.255.252 )
2. create a 5  element range for eth0:{0~5) in a /26 subnet (mask
255.255.255.192 )(almost any two CIDR sizes will do)
3. service network restart
netstat -rn
    

Actual Results:  eth0 's address will have two different local subnets defined... 
one a /29 and one a /26.  Any other addresses within the /26 subnet that are not
REALLY local to eth0 will not route properly. (i.e. via default route).


It looks like the problem in in the way that the
ifcfg-eth0-range files are handled..
In the scripts, they are using the value of IPADDR and NETMASK
to create a route... Since the range files don't set IPADDR, it is
inherited from ifcfg-eth0   thus you get :

route add -net (IPADDR  from ifcfg-eth0 && NETMASK from ifcfg-eth0-range0 ) gw
$GATEWAY

if the netmasks from the two files match, then you're fine. if they don't then
some near-neighbours (networking-wise) will appear to be unreachable.

Expected Results:  eth0 only has one one 'local' route/netmask.

Additional info:

Problem happens independent of the addresses for the range

workaround:
 Add the following to the end of ifcfg-eth?-range*
IPADDR="$IPADDR_START"

This will cause the scripts to create a spurious route for the first address in
the range (with an apporpriate netmask) as opposed to one for eth0 (with an
incorrect netmask).

I think that the real solution is to not do initialization for range scripts...
but that's a bit more work to write up.