Bug 315691 - ifup should restore VLAN routes
ifup should restore VLAN routes
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: initscripts (Show other bugs)
4.4
All Linux
low Severity low
: ---
: ---
Assigned To: initscripts Maintenance Team
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-02 14:12 EDT by Alan Porter
Modified: 2009-03-18 17:10 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 491006 (view as bug list)
Environment:
Last Closed: 2009-03-18 17:10:01 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)
patch to ifup-routes for VLANs (1.57 KB, patch)
2007-10-02 14:12 EDT, Alan Porter
no flags Details | Diff

  None (edit)
Description Alan Porter 2007-10-02 14:12:03 EDT
----------------------------------------

Description of problem:

If an interface has VLANs on top of it, then any static routes through the VLANs
are lost when the underlying interface is brought down and back up.

For example, this is the way we have our servers configured:

VLAN:   bond0.100
BOND:   bond0
IFACE:  eth01 & eth02

If bond0 is brought down and back up, the routes that go through bond0.100 are
lost (the network routes are not lost, just any other defined static routes
whose gateways are on bond0.100).

I have identified a fairly straightforward fix.

Included is a patch to "ifup-routes" that checks to see if the affected
interface has any VLAN's associated with it.  If so, AND IF THE VLANS ARE
CURRENTLY UP, their static routes are restored.

----------------------------------------

Version-Release number of selected component (if applicable):
initscripts from RHEL 4.4.

----------------------------------------

How reproducible:
Always

----------------------------------------

Steps to Reproduce:
1. Set up a VLAN on top of an eth or a bond.
2. Set up a static route through the VLAN.
3. ifdown the eth or bond
4. ifup the eth or bond

----------------------------------------

Actual results:
The network routes for the VLAN are present, but the static routes (defined in
the routes-eth0.100 files) are not present.

----------------------------------------

Expected results:
Routes should be re-enabled when the interface is brought up.

----------------------------------------

Additional info:

The attached patch to "ifup-routes" fixes the problem.
Comment 1 Alan Porter 2007-10-02 14:12:03 EDT
Created attachment 213751 [details]
patch to ifup-routes for VLANs
Comment 2 Bill Nottingham 2007-10-02 17:19:37 EDT
Where are the routes being removed?
Comment 3 Alan Porter 2007-10-19 08:49:33 EDT
They are removed when you ifdown the underlying interface.

For example:

VLAN:   bond0.100
BOND:  bond0
IFACE:  eth01 & eth02

When bond0 is brought down, the routes that go through bond0.100
are lost.  When bond0 is brought back up, the network routes are
restored, but any other defined static routes whose gateways are
on bond0.100 are lost.

Alan

Comment 4 Bill Nottingham 2009-03-18 17:10:01 EDT
Sorry about the extreme delay. This is true. One way to solve this is to treat VLANs much like aliases are treated, and bounce them on the master interface. However, that's a behavior change, and really isn't appropriate for RHEL 4 at this point. Ergo, closing.

This problem will be resolved in a future major release of Red Hat Enterprise Linux. Red Hat does not currently plan to provide a resolution for this in a Red Hat Enterprise Linux update for currently deployed systems.

With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating changes for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects.

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