22.03.5 blocks network switch every 10 minutes

Installing and Using OpenWrt Network and Wireless Configuration
1

hi there for some reason openwrt is blocking devices on a second switch. I swapped out to different switch still the same. connect the wire directly to device and it is not blocked. connect to that device via the switch and every is block going through that switch. but nothing is block going through the primary switch

openwrt device ( eth0)-> switch1 ( nothing blocked on that simple 8 port switch) -> switch2 ( devices blocked on this simple 8 port switch every 10 minutes)

2

hmm we need some more information why that is:

  • is your router dsa or swconfig as build in switch?
  • can you provide a full log?
  • which switches are we talking about and is vlan involved?

Often what I notice if I configure two switches with vlan down stream is either I mess up something in the most downstreamed switch and it somehow double tags it, or tags an untagged port, and to make things worse some switches try to pick wan from other ports if one port failed connectivity so sometimes it fixes itself when you boot them in a correct order.

Often in OpenWrt you will see a error about a received packet with the same source mac address.

3

thank you for the reply. i seamed to have corrected the issue. but I do not know what was causing it. up to aday ago everything worked fine for years . I upgrade to 22.03.05 and the issue appeared instantly after doing so . so i assumed it was the newest version. but i pulled the primary switch out and swapped it out. now it being operating fine for the last 40 minutes. but in that time the building AC has turned off. so I have manually turned on the AC to see if maybe it was electric interference from the AC unit causing the problem. or perhaps other daytime electrical usage but i will find that out tomorrow, as it is evening now .. perhaps it is my AP point ( as it is on switch2) - as an AP can do some really strange things to network ( a common problem I ran across with earlier ubiquity radios. is some time a device would go flaky and it would imitate every mac ID on the network )

1 Like
4

Well I'm happy it works :+1:

From reading it could also be the switch trying to resolve wan from AP :thinking:

Well you can figure this out by doing a reboot on order then :yum:

5

well more then just the ap. as there was an asortment of wireed and wireless ap on the secondary switch every on that switch was blocked

6

Although not unheard of, I suspect that it is another piece of equipment that is responsible for the behavior you experienced, and not at all related to OpenWrt.

In my personal experience (direct or discovered while helping others), I have seen a number of things that can cause a 'block' type behavior:

  • classically, a switching loop caused by a wire that physically loops back (i.e. connecting two ports of the same switch). This normally wouldn't be intermittent, though (although it could be -- imagine a switch that has been disconnected from power and then turned back on again).
  • I've seen this happen with some USB-C docking stations with ethernet -- a few of them will send broadcast storms when the host computer goes to sleep or is disconnected. This storm will bring down an entire network.
  • There was a bug with some Peloton bikes where if you had it connected to your network by both ethernet and wifi, it would result in a switching loop. It was bridging the two interfaces rather than treating them independently.
  • Sonos devices use an implementation of STP that can fail to operate properly. In my own network, I had two devices that were ethernet connected for years without an issue. Then, without warning, something changed with their STP algorithm and it intermittently brought down my network due to switching loops.
  • Other network hardware can misbehave in unpredictable ways, especially in situations where there is a hardware fault.

These are just some things that can cause these problems. Diagnosing the true root-cause can be pretty tricky if the network is large or complex... but it is rare that the router itself is the cause of blocking behavior on a switch.

1 Like
7

The only real option to debug this, is segmenting the network, trying to bisect which parts of your network cause this (the router -while not impossible- is rather unlikely to be the culprit here, foremost because it shouldn't really be all that much involved in traffic between clients inside of your lan, that should all be switched in hardware).

2 Likes
8

thank you all for your replies- currently all is fine and nothing being blocked anymore since changing the primary switch. I guess coincidentally it just happened when I upgraded to 22.03.05 from 22.03. though I guess i could test to see if router software some roll in it . revert the hardware back and pop in my older mSATA with the 22.03 software on it and see if it goes away again

9

I don't think this helps but today I also found 2 really bad scenarios with Tp-link SG-1008E and Tp-link SG-1016DE switches.

I found out that sometimes Force Link on a OpenWrt interface in advanced options can get higher priority than port 0 in some scenarios, things could happen in a way that the switch ip reflects on your current dhcp which is not part of vlan 1 at all.

Later I also found out when I was with a proper setup like having all other ports not sharing vlan 1, I got the message like:

Sat Aug 19 19:24:19 2023 kern.warn kernel: [ 2083.088251] br-lan: received packet on lan1 with own address as source address (addr:<snip>, vlan:1)

^ I have had this alot of times and it could block access to web UI for the switch because it thinks it is a loop.

My second switch (most downstreamed one SG-1008E) was the rogue one, when I changed the last port to untagged vlan id 1 and pvid to 1 aswell the error was gone (weirdly), it seems to be finally stopped when I went to Switching->igmp snooping and turned this off on the SG-1008E switch.

heres a screenshot how it is configurated:

image
image696×788 24.7 KB

and the downstream switch (down stream, connected to the 16port switch as above screenshot):

image
image697×571 18.2 KB

it was driving me crazy why it would not work :stuck_out_tongue: , but this maybe demonstrates what could maybe be a issue on your network, when I think after about this I think it was just a situation of having a double igmp stack somewhere and that went rampage on my network, because my SG-1016DE switch has also IGMP on because of iptv.

10

Firmware on these switches is a disaster -- very poorly implemented. These switches should be avoided at all costs.

2 Likes
11

100% agree, I'm planning in the future to replace them because they tend to be unreliable. :+1:

12

very bad experience with the TP-Link ER605 v2 too
VLAN never been able to be configured so as subnets does not communicate with each other!

TP-Link software implementation seems to be very bad lately on their devices

13

This is a router, not a switch. This would not have the described effect on a network.