Bug 103872 - defining ipcfg ranges causes bad routes
defining ipcfg ranges causes bad routes
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-05 18:04 EDT by Stephen Samuel
Modified: 2014-03-16 22:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-30 15:55:43 EDT
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 Stephen Samuel 2003-09-05 18:04:02 EDT
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.
Comment 1 Bill Nottingham 2005-09-30 15:55:43 EDT
Closing bugs on older, no longer supported, releases. Apologies for any lack of
response.

Please try to reproduce this on a current release, such as Fedora Core 4. If the
issue persists, please open a new issue.

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