James Carlson wrote:
>
> The very same issue occurs with aggregations, doesn't it? You need to
> be able to treat the aggregation as a single sender for the network
> layer clients, which means sending from the "wrong" MAC address on at
> least some of the links.
Link aggregation is IEEE 802.3AD i.e. defined only for IEEE 802.3.
I don't know how aggr currently checks that it is only talking to 802.3,
but I'm assuming there is such a check.
Since bridging is an IEEE 802.1 standard in principle it applies to
802.11 etc.
> I think it gets outside the bounds of this case, but I agree that if
> we have those sorts of drivers, we'll need the same logic to prevent
> misconfiguration in both cases. I'll follow up on the supported
> drivers.
Good (but the logic check might be slightly different due to the above
difference.)
> It may ... after having blindly forwarded for long enough to melt the
> network.
>
> Or you can get into root-guard and BPDU-guard; more about that below.
> The more I think about Cisco-like 'portfast', the less I'm sure we
> want to support it in the first release.
But providing a way to disable stp completely is then even more
dangerous thus I'd propose not to offer that in the first release either.
> If simply allowing an STP per-port disable seems too hazardous, then
> I'd suggest we go with something like BPDU-guard. We can still
> disable STP, but if a BPDU is seen arriving on such a port, then we
> disable the port as apparently broken (changing state to 'disabled')
> and log a message. The administrator must explicitly reenable the
> link by removing it from the bridge and adding it back or otherwise
> making the link signal go down and back up. Seeing a BPDU on such a
> port is good evidence that the topology is just plain wrong, and
> saving the network at the expense of a port sounds like the right
> result to me.
That works for me.
Erik
