Bug 1374360

I decided to drop the first two commits because these attributes are not supported in current RHEL7 kernel so there is no use in supporting them in iproute. Instead, I added a RHEL only patch removing the respective man page bits so docs are consistent with functionality again.

(In reply to Phil Sutter from comment #2)
> I decided to drop the first two commits because these attributes are not
> supported in current RHEL7 kernel so there is no use in supporting them in
> iproute. Instead, I added a RHEL only patch removing the respective man page
> bits so docs are consistent with functionality again.

Phil these attributes were backported to RHEL7 kernel by bridge rebase:

http://post-office.corp.redhat.com/archives/rhkernel-list/2017-January/msg02237.html
http://post-office.corp.redhat.com/archives/rhkernel-list/2017-January/msg02257.html

(In reply to Ivan Vecera from comment #3)
> (In reply to Phil Sutter from comment #2)
> > I decided to drop the first two commits because these attributes are not
> > supported in current RHEL7 kernel so there is no use in supporting them in
> > iproute. Instead, I added a RHEL only patch removing the respective man page
> > bits so docs are consistent with functionality again.
> 
> Phil these attributes were backported to RHEL7 kernel by bridge rebase:

Oh, thanks for the info! I'll get this fixed then.

Thanks, Phil

Btw. all required commits are part of bug #1417289

Added the two commits previously left out and reverted my man page changes again.

Hi Phil,

I found one issue. Tested on

iproute-3.10.0-79.el7
3.10.0-635.el7

There is written in man-page, that bridge slave priority is unsigned 16bit.

# man ip-link
...
priority PRIO - set port priority (a 16bit unsigned value).
...

But it does not work and kernel rejects higher priority then 63.

# ip link set test_slave type bridge_slave priority 63
# ip -d link show dev test_slave|grep prio
    bridge_slave state disabled priority 63 cost 100 hairpin off guard off root_block off fastleave off learning on flood on port_id 0xfc01 port_no 0x1 designated_port 64513 designated_cost 0 designated_bridge 8000.aa:5d:79:38:dd:f2 designated_root 8000.aa:5d:79:38:dd:f2 hold_timer    0.00 message_age_timer    0.00 forward_delay_timer    0.00 topology_change_ack 0 config_pending 0 proxy_arp off proxy_arp_wifi off mcast_router 1 mcast_fast_leave off mcast_flood on addrgenmode eui64

# ip link set test_slave type bridge_slave priority 64
RTNETLINK answers: Numerical result out of range
# ip -d link show dev test_slave|grep prio
    bridge_slave state disabled priority 63 cost 100 hairpin off guard off root_block off fastleave off learning on flood on port_id 0xfc01 port_no 0x1 designated_port 64513 designated_cost 0 designated_bridge 8000.aa:5d:79:38:dd:f2 designated_root 8000.aa:5d:79:38:dd:f2 hold_timer    0.00 message_age_timer    0.00 forward_delay_timer    0.00 topology_change_ack 0 config_pending 0 proxy_arp off proxy_arp_wifi off mcast_router 1 mcast_fast_leave off mcast_flood on addrgenmode eui64

We have to decide on which side is the issue, kernel or iproute. If iproute, we have to fix man-page.

2,

Another issue. iproute does not set state 4 for bridge_slave. This state means blocking.

# man ip-link
...
state STATE - Set port state.  STATE is a number representing the following states: 0 (disabled), 1 (listening), 2 (learning), 3 (forwarding), 4 (blocking).
...

# ip -d link show dev testSlave
22: testSlave: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master test state UNKNOWN mode DEFAULT qlen 1000
    link/ether be:54:75:98:46:6f brd ff:ff:ff:ff:ff:ff promiscuity 1 
    dummy 
    bridge_slave state disabled priority 32 cost 100 hairpin off guard off root_block off fastleave off learning on flood on port_id 0x8001 port_no 0x1 designated_port 32769 designated_cost 0 designated_bridge 8020.be:54:75:98:46:6f designated_root 8020.be:54:75:98:46:6f hold_timer    0.00 message_age_timer    0.00 forward_delay_timer    0.00 topology_change_ack 0 config_pending 0 proxy_arp off proxy_arp_wifi off mcast_router 1 mcast_fast_leave off mcast_flood on addrgenmode none

# ip link set dev testSlave type bridge_slave state 4

# ip -d link show dev testSlave
22: testSlave: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master test state UNKNOWN mode DEFAULT qlen 1000
    link/ether be:54:75:98:46:6f brd ff:ff:ff:ff:ff:ff promiscuity 1 
    dummy 
    bridge_slave state forwarding priority 32 cost 100 hairpin off guard off root_block off fastleave off learning on flood on port_id 0x8001 port_no 0x1 designated_port 32769 designated_cost 0 designated_bridge 8020.be:54:75:98:46:6f designated_root 8020.be:54:75:98:46:6f hold_timer    0.00 message_age_timer    0.00 forward_delay_timer    7.41 topology_change_ack 0 config_pending 0 proxy_arp off proxy_arp_wifi off mcast_router 1 mcast_fast_leave off mcast_flood on addrgenmode none

It set forwarding instead of blocking.

(In reply to Jaroslav Aster from comment #8)
> Hi Phil,
> 
> I found one issue. Tested on
> 
> iproute-3.10.0-79.el7
> 3.10.0-635.el7
> 
> There is written in man-page, that bridge slave priority is unsigned 16bit.
> 
> # man ip-link
> ...
> priority PRIO - set port priority (a 16bit unsigned value).
> ...
> 
> But it does not work and kernel rejects higher priority then 63.
> 
> # ip link set test_slave type bridge_slave priority 63
> # ip -d link show dev test_slave|grep prio
>     bridge_slave state disabled priority 63 cost 100 hairpin off guard off
> root_block off fastleave off learning on flood on port_id 0xfc01 port_no 0x1
> designated_port 64513 designated_cost 0 designated_bridge
> 8000.aa:5d:79:38:dd:f2 designated_root 8000.aa:5d:79:38:dd:f2 hold_timer   
> 0.00 message_age_timer    0.00 forward_delay_timer    0.00
> topology_change_ack 0 config_pending 0 proxy_arp off proxy_arp_wifi off
> mcast_router 1 mcast_fast_leave off mcast_flood on addrgenmode eui64
> 
> # ip link set test_slave type bridge_slave priority 64
> RTNETLINK answers: Numerical result out of range
> # ip -d link show dev test_slave|grep prio
>     bridge_slave state disabled priority 63 cost 100 hairpin off guard off
> root_block off fastleave off learning on flood on port_id 0xfc01 port_no 0x1
> designated_port 64513 designated_cost 0 designated_bridge
> 8000.aa:5d:79:38:dd:f2 designated_root 8000.aa:5d:79:38:dd:f2 hold_timer   
> 0.00 message_age_timer    0.00 forward_delay_timer    0.00
> topology_change_ack 0 config_pending 0 proxy_arp off proxy_arp_wifi off
> mcast_router 1 mcast_fast_leave off mcast_flood on addrgenmode eui64
> 
> We have to decide on which side is the issue, kernel or iproute. If iproute,
> we have to fix man-page.
> 
> 2,

This is by design. The port ID is unsigned 16bit integer. It consists of port number (10 lower bits) and priority (6 high bits). So priority is value from 0-63.

Hi Ivan,

thanks for the info. So documentation should be changed, because it is confusing.

(In reply to Jaroslav Aster from comment #9)
> Another issue. iproute does not set state 4 for bridge_slave. This state
> means blocking.
> 
> # man ip-link
> ...
> state STATE - Set port state.  STATE is a number representing the following
> states: 0 (disabled), 1 (listening), 2 (learning), 3 (forwarding), 4
> (blocking).
> ...
> 
> # ip -d link show dev testSlave
> 22: testSlave: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master
> test state UNKNOWN mode DEFAULT qlen 1000
>     link/ether be:54:75:98:46:6f brd ff:ff:ff:ff:ff:ff promiscuity 1 
>     dummy 
>     bridge_slave state disabled priority 32 cost 100 hairpin off guard off
> root_block off fastleave off learning on flood on port_id 0x8001 port_no 0x1
> designated_port 32769 designated_cost 0 designated_bridge
> 8020.be:54:75:98:46:6f designated_root 8020.be:54:75:98:46:6f hold_timer   
> 0.00 message_age_timer    0.00 forward_delay_timer    0.00
> topology_change_ack 0 config_pending 0 proxy_arp off proxy_arp_wifi off
> mcast_router 1 mcast_fast_leave off mcast_flood on addrgenmode none
> 
> # ip link set dev testSlave type bridge_slave state 4
> 
> # ip -d link show dev testSlave
> 22: testSlave: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master
> test state UNKNOWN mode DEFAULT qlen 1000
>     link/ether be:54:75:98:46:6f brd ff:ff:ff:ff:ff:ff promiscuity 1 
>     dummy 
>     bridge_slave state forwarding priority 32 cost 100 hairpin off guard off
> root_block off fastleave off learning on flood on port_id 0x8001 port_no 0x1
> designated_port 32769 designated_cost 0 designated_bridge
> 8020.be:54:75:98:46:6f designated_root 8020.be:54:75:98:46:6f hold_timer   
> 0.00 message_age_timer    0.00 forward_delay_timer    7.41
> topology_change_ack 0 config_pending 0 proxy_arp off proxy_arp_wifi off
> mcast_router 1 mcast_fast_leave off mcast_flood on addrgenmode none
> 
> It set forwarding instead of blocking.

No, it does not. The blocking state is used by STP to avoid loops. In the example below there you can find that port state is set to blocking and immediately back to forwarding.

# ip -d link set dev enp3s0np5s0 type bridge_slave state 4
[root@mlxsw-1 ~]# dmesg
[79184.884240] t_br0: port 1(enp3s0np5s0) entered blocking state
[79184.884247] t_br0: port 1(enp3s0np5s0) entered forwarding state

The original state was disabled, so there is transition from blocking to forwarding, right?

What is the trigger to switch from blocking to forwarding state? My test interface is dummy, so there is no traffic.

(In reply to Jaroslav Aster from comment #13)
> The original state was disabled, so there is transition from blocking to
> forwarding, right?
> 
> What is the trigger to switch from blocking to forwarding state? My test
> interface is dummy, so there is no traffic.

When:
1. (bridge_id == designated_bridge && port_id == designated_port)
2. (port == bridge_root_port)

Documentation fix submitted upstream:

http://marc.info/?l=linux-netdev&m=149131855608683&w=2

Documentation fix backported. AFAICT, there are no open questions anymore for this ticket, hence setting it to MODIFIED again. In case I'm wrong, feel free to reset back to ASSIGNED.

Ah, my fault - it was ON_QA before.

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://access.redhat.com/errata/RHBA-2017:2171