lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 25 Jun 2016 00:09:17 +0300
From:	Elad Raz <e@...draz.com>
To:	Michal Soltys <soltys@....info>, Ido Schimmel <idosch@...lanox.com>
Cc:	Linux Netdev List <netdev@...r.kernel.org>,
	Jiri Pirko <jiri@...lanox.com>, Florian Westphal <fw@...len.de>
Subject: Re: switch / linux STP interoperation issues.

On Fri, Jun 24, 2016 at 10:14 PM, Michal Soltys <soltys@....info> wrote:
> Hi,
>
> In the last week I've been trying to get STP on the linux side (both its
> builtin STP implementation as well as mstpd userspace daemon). Initially I
> started with more complex setups (vlan aware bridge, bonds, mst) and
> gradually (with identical problems on each step) ended with the most basic
> setup that can be summarized by:
>
> brctl addbr br0
> brctl addif br0 eno1
> brctl addif br0 eno2
> brctl stp br0 on
> ip li set eno1 up
> ip li set eno2 up
> ip li set br0 up
>
> The same config on switch's side (cisco 2960-x in its most basic
> incarnation) - in the other words two cables between linux machine and the
> switch, enabled stp, access ports in vlan1.
>
> The end effect of this setup (and any of the more complex previous ones):
>
> The switch respected BPDUs sent to it (if applicable) - for example it
> complied properly if it's priority was less (numerically higher) than
> linux's - showing linux box as root bridge, marking one port as root, the
> other as alternate/blocking.
>
> The linux box itself was completely deaf to any BPDUs arriving to it (e.g.
> if it's priority was lower) and just keept pushing its own data units all
> the time with little care (quickly leading to loops in some scenarios).
> Whether it was builtin stp implementation, or whether it was mstpd's
> stp/rstp/mstp - the behaviour was the same.
>
> With the bridge itself happily claiming to be the root (despite lower
> priority):
>
> br0
>  bridge id              a000.000af77cddc4
>  designated root        a000.000af77cddc4
>  root port                 0
>
> <cut>
>
> enp8s0f0 (3)
>  port id                8003                    state forwarding
>  designated root        a000.000af77cddc4       path cost    4
>  designated bridge      a000.000af77cddc4
>
> <cut>
> (and analogous output from mstpctl tool)
>
> tcpdump looked like:
>
> 17:33:28.701425 00:0a:f7:7c:dd:c4 > 01:80:c2:00:00:00, 802.3, length 52:
> LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03
> : STP 802.1d, Config, Flags [none], bridge-id a000.00:0a:f7:7c:dd:c4.8003,
> length 35
>         message-age 0.00s, max-age 20.00s, hello-time 2.00s,
> forwarding-delay 15.00s
>         root-id a000.00:0a:f7:7c:dd:c4, root-pathcost 0
> 17:33:29.026185 18:8b:45:6f:38:86 > 01:80:c2:00:00:00, 802.3, length 60:
> LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03
> : STP 802.1d, Config, Flags [none], bridge-id 2001.18:8b:45:6f:38:80.8006,
> length 43
>         message-age 0.00s, max-age 20.00s, hello-time 2.00s,
> forwarding-delay 15.00s
>         root-id 2001.18:8b:45:6f:38:80, root-pathcost 0
>
> The first sent by linux box, the second by the switch (the above from basic
> stp scenario on both sides).
>
>
> The cards in question used:
> Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet
> PCIe (rev 01) handled by:
>
> driver: tg3
> version: 3.137
> firmware-version: FFV7.10.17 bc 5719-v1.37
>
>
> Linux is fresh stock archlinux (so vanilla 4.6.2 kernel and the most (or
> almost) recent userland utils - iproute2, etc.), running on relatively
> recent poweredge dell.
>
> I'm kind of lost at this point - am I missing some basic
> options/sysctls/sysfs ? Is there some known incompatibility here somewhere
> between switch/linux/nic/versions/etc. ? Some by-default enabled BPDU
> filtering maybe ?
>
>
> Any suggestions / hints appreciated.

Please see Ido Schimmel's fix "[net] bridge: Fix incorrect
re-injection of STP packets",
https://patchwork.ozlabs.org/patch/629768/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ