RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 713757 - ifup script can't reconize bridge device name "brbond0.XX"
Summary: ifup script can't reconize bridge device name "brbond0.XX"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.1
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-16 13:44 UTC by Teruaki Ishizaki
Modified: 2016-11-25 12:57 UTC (History)
9 users (show)

Fixed In Version: initscripts-9.03.32-1.el6
Doc Type: Bug Fix
Doc Text:
Cause: Previous version of sysconfig.txt led users to put VLAN=yes in global config file. Consequence: Interface with name containing dot (brbond0.XX) are recognized as VLAN interfaces. Fix: Sysconfig.txt was changed - VLAN stanza belongs to interface config file. Result: Mentioned devices are no longer recognized as VLAN interfaces.
Clone Of:
: 860252 (view as bug list)
Environment:
Last Closed: 2013-02-21 10:25:21 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0518 0 normal SHIPPED_LIVE initscripts bug fix and enhancement update 2013-02-20 21:29:01 UTC

Description Teruaki Ishizaki 2011-06-16 13:44:26 UTC
Description of problem:
ifup script can't reconize bridge device name "brbond0.XX" from initscripts-9.03.23-1.el6.

our NW stack is below

eth0 ---
        |--- bond0 --- bond0.XX --- brbond0.XX
eth1 ---

we create a file /etc/sysconfig/network-scripts/ifcfg-brbond0.XX
----------------------------
DEVICE=brbond0.XX
TYPE=Bridge
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
IPADDR=AA.BB.CC.DD
NETMASK=255.255.255.0
DELAY=0
-----------------------------

and /etc/sysconfig/ifcfg-bond0.XX.

Start OS, but brbond0.XX device status is not up.

If we use initscripts-9.03.17-1.el6, brbond0.XX device is successfully up.

Version-Release number of selected component (if applicable):
initscripts-9.03.23-1.el6

Steps to Reproduce:
1.create ifcfg-bond0.XX file for vlan device
2.create ifcfg-brbond0.XX file for bridge device connecting to bond0.XX
3.reboot or /etc/init.d/network start
  
Actual results:
brbond0.XX is not up.

Expected results:
brbond0.XX is up.


Additional info:
If we use initscripts-9.03.17-1.el6, brbond0.XX device is successfully up.

Comment 1 Teruaki Ishizaki 2011-06-16 13:49:33 UTC
typo:

>we create a file /etc/sysconfig/network-scripts/ifcfg-brbond0.XX
>----------------------------
>DEVICE=brbond0.XX
>TYPE=Bridge
>BOOTPROTO=none
>ONBOOT=yes
>USERCTL=no
>IPADDR=AA.BB.CC.DD
>NETMASK=255.255.255.0
>DELAY=0
>-----------------------------
>
>and /etc/sysconfig/ifcfg-bond0.XX.
and /etc/sysconfig/network-scripts/ifcfg-bond0.XX

Comment 3 Bill Nottingham 2011-06-16 19:37:17 UTC
How does it fail? How much of the stack is set up?

Comment 5 Teruaki Ishizaki 2011-06-17 01:53:00 UTC
I think those patches makes those problem.

Our system is using that naming convention "brbond0.XX" for bridge device.
Naming convention's change between RHEL versions have a great influence on existing system.

Naming default policy is exist?(vlan, bonding, bridge, ...etc)

Comment 6 Bill Nottingham 2011-06-17 14:43:09 UTC
(In reply to comment #5)
> I think those patches makes those problem.

I'm sorry, I don't quite understand you hear. Are you saying that removing
these changes fixes the issue for you?

Comment 7 Bill Nottingham 2011-06-17 14:51:45 UTC
That should be 'understand you here'.

Also, when it's not working for you, how far does it get? Which of the component devices are set up correctly?

Comment 8 Teruaki Ishizaki 2011-06-21 10:03:00 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > I think those patches makes those problem.
> 
> I'm sorry, I don't quite understand you hear. Are you saying that removing
> these changes fixes the issue for you?
I think that these changes fix the issue.

Brbond0.XX is misunderstanded for VLAN device with initscripts-9.03.23-1.el6.

I tested changing bridge name to brbond0_XX or brbond0-XX, and bridge interface was up successfully.(using initscripts-9.03.23-1.el6)

Comment 9 Suzanne Logcher 2011-10-06 18:50:21 UTC
Since RHEL 6.2 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.
               
Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 10 Lukáš Nykrýn 2012-06-07 16:53:05 UTC
It seems weird to me that these two patches broke it. First one looks really harmless and the second one is "used" only in case that there is VLAN=yes in configuration file.

Comment 11 Lukáš Nykrýn 2012-06-08 11:53:08 UTC
This is probably caused by setting VLAN=yes in sysconfig/network. Then this variable has the same value in ifup script. Obvious workaround for this would be to explicitly set VLAN=no in ifcfg-brbond0.XX.

Solution to this would be to unset VLAN after sourcing sysconfig/network, but I am not sure if this is completely correct.

--- a/sysconfig/network-scripts/ifup
+++ b/sysconfig/network-scripts/ifup
@@ -23,6 +23,7 @@ cd /etc/sysconfig/network-scripts
 . ./network-functions
 
 [ -f ../network ] && . ../network
+unset VLAN #we want check VLAN in device config
 
 CONFIG=${1}

Comment 12 Bill Nottingham 2012-06-08 15:03:04 UTC
Might be simplest to fix the docs to say that VLAN should be set in the config file, not /etc/sysconfig/network.

Comment 13 Bill Nottingham 2012-06-08 15:04:42 UTC
Fixed in upstream sysconfig.txt, at least.

Comment 14 Lukáš Nykrýn 2012-06-08 21:08:07 UTC
But this variable is also used in init.d/network script, where it starts modprobe 8021q.

Comment 15 Bill Nottingham 2012-06-11 19:06:29 UTC
Right, but since it's also loaded in ifup, so I don't think that stanza of init.d/network is actually needed. Did I miss a usage case here?

Comment 16 Lukáš Nykrýn 2012-06-12 06:48:29 UTC
My mistake, I overlooked the modprobe in ifup.

Comment 19 TakIchikawa 2012-09-06 03:10:01 UTC
I'm troubled, too.
I want VLAN Interface to Bridge (to use KVM vnetXX).

 bond0 --[bridge]--> br0
  |
 [vlan]
  |
 bond0.xx --[bridge]--> br0.xx


/sbin/ifup
-    MATCH='^(eth|hsi|bond)[0-9]+\.[0-9]{1,4}$'
+    MATCH='^.+\.[0-9]{1,4}$'


In old script, br0.xx is normal interface up.
That not VLAN, but success bridge VLAN bond0.xx.

But, in new script, br0.xx to up VLAN (on VLAN, doubled).
 then "ERROR: could not add vlan XX as br0.XX on dev br0" displayed.


I suppose when ifup "TYPE=Bridge" interface except to VLAN mode.

Comment 20 Václav Pavlín 2012-09-06 10:00:51 UTC
I am afraid that I don't understand you completely and not sure how this change could cause this error.

Are you sure you have VLAN=yes set only in ifcfg for VLAN interfaces?

Comment 21 TakIchikawa 2012-09-06 10:57:38 UTC
Oh! 
I've defined 'VLAN=yes' in [/etc/sysconfig/network].
I understand. thanks.
I will define it in every [/etc/sysconfig/network-scripts/ifcfg-*.xxx], really wants to up to VLAN.
(but... it's so many files...)

Comment 22 Václav Pavlín 2012-09-06 12:41:08 UTC
Don't forget to remove 'VLAN=yes' from [/etc/sysconfig/network].

Comment 34 errata-xmlrpc 2013-02-21 10:25:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0518.html


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