Bug 133575

Summary: GATEWAYDEV directive ignored...
Product: Red Hat Enterprise Linux 3 Reporter: Johnray Fuller <jrfuller>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED ERRATA QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: pekkas, rvokal, tao
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: 2005-05-18 15:35:57 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:
Bug Depends On:    
Bug Blocks: 132991    
Attachments:
Description Flags
use 'dev $GATEWAYDEV' if $GATEWAYDEV is set. none

Description Johnray Fuller 2004-09-24 21:05:27 UTC
On a system with two active NICs (eth0 & eth2), I configured the
second NIC to e the gateway device. However, it seems to begetting
ignored.

# rpm -q initscripts
initscripts-7.31.16.EL-1

# cat /etc/sysconfig/network
HOSTNAME=homocorrectus.mine.nu
NETWORKING=yes
GATEWAY=172.31.0.1
GATEWAYDEV=eth2

# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
PEERDNS=no
NETMASK=255.255.255.0
IPADDR=172.31.0.110

# cat /etc/sysconfig/network-scripts/ifcfg-eth2
DEVICE=eth2
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
PEERDNS=no
NETMASK=255.255.255.0
IPADDR=172.31.0.112

# service network restart

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref   
Use Iface
172.31.0.0      *               255.255.255.0   U     0      0       
0 eth0
172.31.0.0      *               255.255.255.0   U     0      0       
0 eth2
169.254.0.0     *               255.255.0.0     U     0      0       
0 eth2
default         172.31.0.1      0.0.0.0         UG    0      0       
0 eth0

Note the default device is still eth2.

J

Comment 1 Johnray Fuller 2004-09-24 21:07:25 UTC
s/still eth2/not eth2

Comment 2 Pekka Savola 2004-10-17 10:57:53 UTC
You've funkily set up IP prefixes for the interfaces, they overlap; I 
guess that's causing the problems, because the default gateway is 
reachable through the first interface which was brought up (eth0).

Do you have interface aliases or static routes?  Aliases might be 
causing a problem through legacy code in ifup-aliases.

I've looked at the code in CVS and RHL9, and it SHOULD be working even 
though it's funky, unless you have aliases (in which case the failures 
might be explainable).

If that's not the case, I guess the only thing you could do is add 
some debugging log messages e.g. using /usr/bin/logger in ifup around 
GATEWAY to figure out where the gateway gets added and using what 
parameters, and go from there.


Comment 3 Eric Paris 2004-10-18 15:00:38 UTC
# Set a default route.
    if [ -z "${GATEWAYDEV}" -o "${GATEWAYDEV}" = "${REALDEVICE}" ]; then
        # set up default gateway. replace if one already exists
        if [ -n "${GATEWAY}" -a "`ipcalc --network ${GATEWAY}
${NETMASK} 2>/dev/null`" = "NETWORK=${NETWORK}" ]; then
            ip route replace default via ${GATEWAY} ${WINDOW:+window
$WINDOW} ${SRC}
        elif [ "${GATEWAYDEV}" = "${DEVICE}" ]; then
            ip route replace default ${SRC} ${WINDOW:+window $WINDOW}
dev ${REALDEVICE}
        fi
    fi


This is the code in question, notice that the first route statement
does not specify the device.  Since we do have aliases and the dummy
alias is up and it is allowed to pick any interface it wants we can
see this makes sense.  But, it is not right.  There needs to be a
nested if which checks if the gatewaydev is set and then uses the "dev
${REALDEVICE} in the first if block if it is set, and uses the
statement as it stands if not.

Comment 4 Pekka Savola 2004-10-18 15:23:09 UTC
Right.  I was looking at the code real hard, but I didn't notice that 
the first ip route didn't specify the interface.

I guess a patch like attached would fix this? (untested)

Comment 5 Pekka Savola 2004-10-18 15:25:38 UTC
Created attachment 105384 [details]
use 'dev $GATEWAYDEV' if $GATEWAYDEV is set.

Comment 6 Bill Nottingham 2004-10-18 16:10:50 UTC
The entire stanza is wrapped in -z "$GATEWAYDEV" - I don't think that
will work.

Comment 7 Pekka Savola 2004-10-18 16:15:39 UTC
There's '-o "${GATEWAYDEV}" = "${REALDEVICE}"' as well which is TRUE 
-- the route will be added when REALDEVICE is eth2 (==GATEWAYDEV), so 
it should work.

Comment 8 Bill Nottingham 2004-10-18 16:18:06 UTC
In that case, should the order of the tests just be reversed?

Comment 9 Pekka Savola 2004-10-18 16:23:16 UTC
If you refer to the -z $GATEWAYDEV ... line, I guess it won't matter 
except as an optiomization.

If you refer to the following if/elif tests, it wouldn't work (without 
changes) because the elif just adds the route to point at the device 
(weird stuff?!!), doesn't specify the next-hop..

The only reason I can think of why the elif statement is like it is is 
if it was originally thought that GATEWAYDEV would only be used with 
point-to-point interfaces that don't need GATEWAY..

Comment 10 Bill Nottingham 2004-10-18 16:37:07 UTC
Added, will be in 7.31.19.EL-1 (and various other releases on various
other branches.)

Comment 11 Eric Paris 2004-10-18 17:11:57 UTC
Patch doesn't look right to me.  Don't you have to have a + in there?
 Right that patch isn't valid and I thnk will bust the ifup.

should be   ${GATEWAYDEV:+dev $GATEWAYDEV}

Comment 13 Pekka Savola 2004-10-18 17:54:45 UTC
True, the + sign was missing.  As said, it was untested ;-).  Thanks 
for the good eyes.

Comment 16 John Flanagan 2004-12-13 20:31:44 UTC
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-619.html


Comment 17 Tim Powers 2005-05-18 15:35:57 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-123.html