Bug 1305317 - ip link add ifb_X type ifb creates two more unwanted bogus ifb devices
ip link add ifb_X type ifb creates two more unwanted bogus ifb devices
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: iproute (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Phil Sutter
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-06 19:18 EST by an0nym
Modified: 2016-11-24 14:50 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-24 14:50:46 EST
Type: Bug
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 an0nym 2016-02-06 19:18:18 EST
Description of problem:
When you issue ip link add ifb_X type ifb, two more ifb links get created - ifb0 and ifb1. These links can be safely removed thereafter. This only happens when creating first ifb link after reboot. Creating second ifb link (with or without prior removal of ifb0 and ifb1) does not lead to more bogus ifb links. 

Version-Release number of selected component (if applicable):
iproute.x86_64                       4.1.1-3.fc23                       @updates

How reproducible:
once every reboot

Steps to Reproduce:
1. reboot
2. see ip link
3. ip link add ifb_X type ifb
4. see ip link

Actual results:
1. no ifb links

4. 
13: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32
    link/ether 7a:27:f5:e3:5f:ca brd ff:ff:ff:ff:ff:ff
14: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32
    link/ether 56:39:4e:f7:d4:ca brd ff:ff:ff:ff:ff:ff
15: ifb_X: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32
    link/ether 16:99:b7:dc:61:98 brd ff:ff:ff:ff:ff:ff

Expected results:
1. no ifb links

4. 
13: ifb_X: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32
    link/ether 16:99:b7:dc:61:98 brd ff:ff:ff:ff:ff:ff

Additional info:
Comment 1 Fedora End Of Life 2016-11-24 10:25:59 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 2 Phil Sutter 2016-11-24 14:50:46 EST
Hi,

This is expected behaviour and common with some legacy virtual interface drivers such as bond.ko or dummy.ko. In order to prevent ifb.ko from creating these initial interfaces, pass 'numifbs=0' module parameter when loading it.

This device creating upon module loading is a relict from the past when there was no 'ip link add' functionality. Sadly though, any attempts at getting rid of it were torn down reasoning that it might break existing userspace scripts. Of course it's ridiculous that this relatively new driver (from 2006) still implements this obsolete behaviour, yet same argument applies to it as well so it can't be removed anymore.

Cheers, Phil

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