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 1341343 - Support listing interfaces by type or master
Summary: Support listing interfaces by type or master
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: iproute
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Phil Sutter
QA Contact: Jaroslav Aster
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-31 22:03 UTC by Phil Sutter
Modified: 2016-11-03 23:39 UTC (History)
3 users (show)

Fixed In Version: iproute-3.10.0-67.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 23:39:31 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:2162 0 normal SHIPPED_LIVE iproute bug fix and enhancement update 2016-11-03 13:14:33 UTC

Description Phil Sutter 2016-05-31 22:03:49 UTC 
This is a feature upstream has since the end of 2014 and a real benefit in my point of view. Two simple examples:

List all bridges:

# ip link show type bridge

List slaves of br0:

# ip link show master br0

In theory, this works with 'ip address' as well, though there's a bug upstream which prevents that with the 'type' keyword.

Another nice thing: All this is a pure user-space feature, no kernel support is required (apart from it exporting interface type and assigned master device, which is standard).

Patches to backport:

commit 1b94414854d71a6b6df367644ae9b06a54278daf
Author: Vadim Kochan <vadim4j>
Date:   Sat Nov 29 11:27:41 2014 -0800

    ip link: Allow to filter devices by master dev
    
    Added 'master' option to 'ip link show' command
    to filter devices by master dev.
    
    Signed-off-by: Vadim Kochan <vadim4j>


commit 712249d8fac88bcf3a9fd0b1de2263074075873b
Author: Vadim Kochan <vadim4j>
Date:   Wed Dec 10 10:11:29 2014 +0200

    ip link: Show devices by type
    
    Added new option 'type' to 'ip link show'
    command which allows to filter devices by type:
    
        ip link show type bridge
        ip link show type vlan
    
    Signed-off-by: Vadim Kochan <vadim4j>


And a yet to be submitted fix from me.
Comment 1 Phil Sutter 2016-05-31 22:08:09 UTC 
Here's one more:

commit 417b2180a57b0335981bdaaaaa017a48d1a84b72
Author: Vadim Kochan <vadim4j>
Date:   Fri Dec 26 04:46:20 2014 +0200

    man ip-link: Small example of 'ip link show master'
    
    Signed-off-by: Vadim Kochan <vadim4j>
Comment 4 Jaroslav Aster 2016-06-21 16:13:27 UTC 
Hi Phil,

I found some issues related to type and master.

1, Sets of possible types are different between ip address help, man ip-address, ip link help and man ip-link.

for example:

# diff ip-address-help.txt ip-address-man.txt 
2d1
< bond_slave
4c3
< bridge_slave
---
> can
8a8
> hsr
15a16
> lowpan
23d23
< vrf

Sets should be the same.

2, Is it possible to filter Ethernet type? There is no mention about it.

3, It is possible to specify nonsense type.

# ip link show type blablablablabla && echo ok || echo fail
ok

I know, there is only simple filter in the code which compares type typed by user and device type, but it does not look good.

Switching to assigned state. At least documentation should be fixed.
Comment 5 Phil Sutter 2016-06-21 21:18:53 UTC 
Hi Jaroslav,

(In reply to Jaroslav Aster from comment #4)
> 1, Sets of possible types are different between ip address help, man
> ip-address, ip link help and man ip-link.
> 
> for example:
> 
> # diff ip-address-help.txt ip-address-man.txt 
> 2d1
> < bond_slave
> 4c3
> < bridge_slave
> ---
> > can
> 8a8
> > hsr
> 15a16
> > lowpan
> 23d23
> < vrf
> 
> Sets should be the same.

Yes, you're right. I will make sure this is fixed.

> 2, Is it possible to filter Ethernet type? There is no mention about it.
> 
> 3, It is possible to specify nonsense type.
> 
> # ip link show type blablablablabla && echo ok || echo fail
> ok
> 
> I know, there is only simple filter in the code which compares type typed by
> user and device type, but it does not look good.

The functionality is indeed quite simple. With the above (correct) analysis in mind, I am also not overly happy with having the list of possible interface types hard-coded in help text and man page. Maybe I can get a simple statement à la "whatever 'ip link' displays can be used to select type" as an alternative upstream.

> Switching to assigned state. At least documentation should be fixed.

OK. Thanks for looking into this!

Cheers, Phil
Comment 6 Jaroslav Aster 2016-06-22 12:16:31 UTC 
Hi Phil

(In reply to Phil Sutter from comment #5)

> > 3, It is possible to specify nonsense type.
> > 
> > # ip link show type blablablablabla && echo ok || echo fail
> > ok
> > 
> > I know, there is only simple filter in the code which compares type typed by
> > user and device type, but it does not look good.
> 
> The functionality is indeed quite simple. With the above (correct) analysis
> in mind, I am also not overly happy with having the list of possible
> interface types hard-coded in help text and man page. Maybe I can get a
> simple statement à la "whatever 'ip link' displays can be used to select
> type" as an alternative upstream.

I agree with you, that hard-coded types in help and man page do not make sense when you can type whatever you want. It's better to describe how filter works and where I can find right values for the filter, plus some examples for more common types. Now, it appears that only named names are allowed for the filter and it is not true.
Comment 7 Jaroslav Aster 2016-06-22 12:37:46 UTC 
I found one issue/in-consistence in ip-link man page, where ip link delete is described. ip link delete section in ip-link man page does not contain description of type option. It describes only dev option.

  ip link delete - delete virtual link
       DEVICE specifies the virtual  device to act operate on.  TYPE specifies the type of the device.

       dev DEVICE
              specifies the physical device to act operate on.
Comment 8 Phil Sutter 2016-07-05 13:27:54 UTC 
Hi Jaroslav,

(In reply to Jaroslav Aster from comment #6)
> (In reply to Phil Sutter from comment #5)
> 
> > > 3, It is possible to specify nonsense type.
> > > 
> > > # ip link show type blablablablabla && echo ok || echo fail
> > > ok
> > > 
> > > I know, there is only simple filter in the code which compares type typed by
> > > user and device type, but it does not look good.
> > 
> > The functionality is indeed quite simple. With the above (correct) analysis
> > in mind, I am also not overly happy with having the list of possible
> > interface types hard-coded in help text and man page. Maybe I can get a
> > simple statement à la "whatever 'ip link' displays can be used to select
> > type" as an alternative upstream.
> 
> I agree with you, that hard-coded types in help and man page do not make
> sense when you can type whatever you want. It's better to describe how
> filter works and where I can find right values for the filter, plus some
> examples for more common types. Now, it appears that only named names are
> allowed for the filter and it is not true.

I gave this an additional thought and decided to leave the type list where it
is. The reason is it's sometimes tricky to spot the type name in 'ip -d l'
output - it's not always there and in case of enslaved devices there's a line
following it with the *_slave options. So presenting the user with a list of
valid types is still quite helpful, but I have nevertheless added a paragraph
explaining why there is no validation for the type argument in iproute.

(In reply to Jaroslav Aster from comment #7)
> I found one issue/in-consistence in ip-link man page, where ip link delete
> is described. ip link delete section in ip-link man page does not contain
> description of type option. It describes only dev option.
> 
>   ip link delete - delete virtual link
>        DEVICE specifies the virtual  device to act operate on.  TYPE
> specifies the type of the device.
> 
>        dev DEVICE
>               specifies the physical device to act operate on.

This was fixed by some completely unrelated commit (yay), so I could not just
backport something to get rid of the broken formatting. Instead I applied the
desired changes from that commit by hand.
Comment 9 Jaroslav Aster 2016-08-08 11:40:15 UTC 
VERIFIED: /CoreOS/iproute/Sanity/bz1341343-Support-listing-interfaces-by-type-or-master

iproute-3.10.0-71.el7

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: Test
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [   PASS   ] :: Checking there is 'type' option in ip-link man page. (Expected 0, got 0)
:: [   PASS   ] :: Checking there is 'type' option in ip-address man page. (Expected 0, got 0)
:: [   PASS   ] :: Searching there is 'master' option ip link help. (Expected 0, got 0)
:: [   PASS   ] :: Searching there is 'master' option ip address help. (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip link show type dummy | grep 'testDummy1:'' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip link show type dummy | grep 'testDummy2:'' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip link show type dummy | grep 'testDummy3:'' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip link show type dummy | grep 'testBridge:'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip link show type bridge | grep 'testBridge:'' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip link show type bridge | grep 'testDummy1:'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip link show type bridge | grep 'testDummy2:'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip link show type bridge | grep 'testDummy3:'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip link show master testBridge | grep 'testDummy1:'' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip link show master testBridge | grep 'testDummy2:'' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip link show master testBridge | grep 'testDummy3:'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip link show master testBridge | grep 'testBridge:'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip address show type dummy | grep '172.29.28.31/24'' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip address show type dummy | grep '172.29.28.32/24'' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip address show type dummy | grep '172.29.28.33/24'' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip address show type dummy | grep '172.29.28.30/24'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip address show type bridge | grep '172.29.28.30/24'' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip address show type bridge | grep '172.29.28.31/24'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip address show type bridge | grep '172.29.28.32/24'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip address show type bridge | grep '172.29.28.33/24'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip address show master testBridge | grep '172.29.28.31/24'' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip address show master testBridge | grep '172.29.28.32/24'' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ip address show master testBridge | grep '172.29.28.33/24'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip address show master testBridge | grep '172.29.28.30/24'' (Expected 1, got 1)
:: [   LOG    ] :: Duration: 3s
:: [   LOG    ] :: Assertions: 28 good, 0 bad
:: [   PASS   ] :: RESULT: Test


iproute-3.10.0-54.el7_2.1

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: Test
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [   PASS   ] :: Checking there is 'type' option in ip-link man page. (Expected 0, got 0)
:: [   FAIL   ] :: Checking there is 'type' option in ip-address man page. (Expected 0, got 1)
:: [   PASS   ] :: Searching there is 'master' option ip link help. (Expected 0, got 0)
:: [   FAIL   ] :: Searching there is 'master' option ip address help. (Expected 0, got 1)
:: [   FAIL   ] :: Command 'ip link show type dummy | grep 'testDummy1:'' (Expected 0, got 1)
:: [   FAIL   ] :: Command 'ip link show type dummy | grep 'testDummy2:'' (Expected 0, got 1)
:: [   FAIL   ] :: Command 'ip link show type dummy | grep 'testDummy3:'' (Expected 0, got 1)
:: [   PASS   ] :: Command 'ip link show type dummy | grep 'testBridge:'' (Expected 1, got 1)
:: [   FAIL   ] :: Command 'ip link show type bridge | grep 'testBridge:'' (Expected 0, got 1)
:: [   PASS   ] :: Command 'ip link show type bridge | grep 'testDummy1:'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip link show type bridge | grep 'testDummy2:'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip link show type bridge | grep 'testDummy3:'' (Expected 1, got 1)
:: [   FAIL   ] :: Command 'ip link show master testBridge | grep 'testDummy1:'' (Expected 0, got 1)
:: [   FAIL   ] :: Command 'ip link show master testBridge | grep 'testDummy2:'' (Expected 0, got 1)
:: [   PASS   ] :: Command 'ip link show master testBridge | grep 'testDummy3:'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip link show master testBridge | grep 'testBridge:'' (Expected 1, got 1)
:: [   FAIL   ] :: Command 'ip address show type dummy | grep '172.29.28.31/24'' (Expected 0, got 1)
:: [   FAIL   ] :: Command 'ip address show type dummy | grep '172.29.28.32/24'' (Expected 0, got 1)
:: [   FAIL   ] :: Command 'ip address show type dummy | grep '172.29.28.33/24'' (Expected 0, got 1)
:: [   PASS   ] :: Command 'ip address show type dummy | grep '172.29.28.30/24'' (Expected 1, got 1)
:: [   FAIL   ] :: Command 'ip address show type bridge | grep '172.29.28.30/24'' (Expected 0, got 1)
:: [   PASS   ] :: Command 'ip address show type bridge | grep '172.29.28.31/24'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip address show type bridge | grep '172.29.28.32/24'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip address show type bridge | grep '172.29.28.33/24'' (Expected 1, got 1)
:: [   FAIL   ] :: Command 'ip address show master testBridge | grep '172.29.28.31/24'' (Expected 0, got 1)
:: [   FAIL   ] :: Command 'ip address show master testBridge | grep '172.29.28.32/24'' (Expected 0, got 1)
:: [   PASS   ] :: Command 'ip address show master testBridge | grep '172.29.28.33/24'' (Expected 1, got 1)
:: [   PASS   ] :: Command 'ip address show master testBridge | grep '172.29.28.30/24'' (Expected 1, got 1)
:: [   LOG    ] :: Duration: 3s
:: [   LOG    ] :: Assertions: 14 good, 14 bad
:: [   FAIL   ] :: RESULT: Test
Comment 11 errata-xmlrpc 2016-11-03 23:39:31 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.

https://rhn.redhat.com/errata/RHEA-2016-2162.html
Note You need to log in before you can comment on or make changes to this bug.