s/still eth2/not eth2

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.

# 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.

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)

Created attachment 105384 [details]
use 'dev $GATEWAYDEV' if $GATEWAYDEV is set.

The entire stanza is wrapped in -z "$GATEWAYDEV" - I don't think that
will work.

There's '-o "${GATEWAYDEV}" = "${REALDEVICE}"' as well which is TRUE 
-- the route will be added when REALDEVICE is eth2 (==GATEWAYDEV), so 
it should work.

In that case, should the order of the tests just be reversed?

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..

Added, will be in 7.31.19.EL-1 (and various other releases on various
other branches.)

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}

True, the + sign was missing.  As said, it was untested ;-).  Thanks 
for the good eyes.

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

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