On Fri, Mar 8, 2019 at 9:25 PM Simon Hobson <[email protected]> wrote:
>
> I'm not so sure it's the Shorewall box.
Let's just say that things start acting up when I connect the
Shorewall Bridge to my switch where the other two computers are (hosts
1 and 2).
> I see STP (Spanning Tree) traffic in your dump, so one obvious question is
> how long you waited after plugging in the Shorewall device to the switch.
> With standard Spanning Tree, when you change network topology, it can
> interrupt network traffic for something like 30s or longer (IIRC it can be a
> couple of minutes - depends on how much the tree changes).
It's RSTP so it should take a lot less to stabilize. In any case, I
waited "A LOT" after plugging in the Shorewall device (min. 5 minutes,
up to 10 minutes).
The topology here is quite simple: 2 computers connected to ports 1
and 2 on a Ubiquiti UniFi switch (with mostly default config),
Shorewall device connected to port 3.
There is no physical loop. There is no need for multi-path, at least
not yet. So maybe I could try disabling RSTP on the UniFi switch
(enabled by default).
> You have a Linux bridge which defaults to running STP, and the network switch
> also probably is running STP - connect the two, there's a topology change,
> and it disrupts traffic for a while.
Why do you state that Linux bridges default to running STP?
Most documentation states otherwise, and in any case, here's my brctl output:
# brctl show
bridge name bridge id STP enabled interfaces
dmzbr 8000.6805ca116430 no enp5s0
enp5s0.1
enp5s0.11
lanbr 8000.00e3c05f815d no enp5s0.12
enp8s5
enp8s5.1
enp8s5.12
enp8s5.13
enp8s5.14
enp8s5.15
I have not enabled STP on the Shorewall bridge (default). Should I?
> It's interesting that you see traffic between the two hosts which should not
> be reaching the chorewall box - that suggests that the switch is doing
> something silly.
> Could it be that your Shorewall box is becoming the root bridge when you plug
> it in, and disrupting traffic for "a while" ?
That would require STP on the Shorewall device, right? I mean, a
bridge can become a "root bridge" only if it has STP enabled, right?
Supposedly, it should not be the case here.
> If you have not changed any bridge priorities, then they will all be at the
> default of 32768 and so the device with the lowest MAC address (which appears
> to be your Shorewall box) will win the election.
If it's of any use I'll send the output of "brctl showstp lanbr"
during the network disruption on Monday.
> I note that in the packet dump, the Shorewall box is seeing unicast traffic
> that it should not be seeing :
> > 192.168.215.101 > 192.168.215.102: ICMP echo request
>
> That in itself is a sign that there's something wrong with packet routing at
> L2 - that packet should not have gone out of the port the Shorewall box is
> connected to.
> My guess (note, guess) is that the switch is going through an intermediate
> stage as the tree re-configures.
Well, it's as if it were in an infinite loop reconfiguring the tree
because this goes on for a very long time.
> I don't know your background/skills, but I've found that some even quite
> advanced network engineers don't understand STP - or even think to configure
> it.
I admit I don't have a full understanding of Linux bridges and STP.
Considering the fact that there should be no loops or redundant links
in my network (for now) then maybe I could try disabling RSTP on the
UniFi switch. The Shorewall Linux bridge has STP disabled by default,
but I could run "brctl stp lanbr off" anyway.
However, I'd like to understand why my current setup is failing so
that I can use STP/RSTP on both the switch and the shorewall bridge in
the near future.
I guess my next step is to grab the output of "brctl showstp xxx" on
both my Shorewall box and my UniFi switch (as it's a Linux embedded
OS), and see what happens when the tree reconfigures.
Thanks,
Vieri
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
