For reference, this is what the full-blown output of "swconfig dev switch0 show" from the MT7621 looks like:
http://sprunge.us/YPQwYE On Thu, Dec 26, 2019 at 4:07 PM Russell Senior <[email protected]> wrote: > > > On Thu, Dec 26, 2019 at 3:54 PM Russell Senior <[email protected]> > wrote: > >> Ooh, try this: shell in and run: swconfig dev switch0 show | grep port >> >> Connect your loop and run it again. >> >> Then, seeing which port link state changed, you'll know what switch ports >> are LAN1 and LAN2. Piping to less instead of grep should give you a bunch >> of port stats. >> > > It might not give as verbose of port stats as I suggested. The swconfig > output for my "Atheros AR8316 rev. 1 switch" isn't nearly as verbose as the > one in my mediatek MT7621-based router. But I don't have yours, so I don't > know for sure. > > >> Ping an address in the br-lan network space, and try it again. >> >> On Thu, Dec 26, 2019 at 3:42 PM Tomas Kuchta < >> [email protected]> wrote: >> >>> Qualcomm QCA9563 SOC in GL-AR750S package. >>> >>> >>> >>> On Fri, Dec 27, 2019, 00:12 Mike C. <[email protected]> wrote: >>> >>> > I have a theory about why it didn't work on your device. Its what I >>> > expected would happen and why I didn't suggest what Russell did to just >>> > loop one LAN port to another. I think its due to the architecture. >>> > >>> > What make and model is your switch/router? >>> > >>> > On Thu, Dec 26, 2019, 2:24 PM <[email protected]> wrote: >>> > >>> > > It seems that in my case - looping LAN1 with LAN2 and >>> sending/receiving >>> > > WAN<-->WLAN3 traffic leads to no visible traffic degradation. That >>> > > probably mean >>> > > that I failed to create lan loop. >>> > > >>> > > The lights were "kind of" busy on LAN1 <--> LAN2, but the wlan3 and >>> > > upstream WAN >>> > > are slow enough to observe any effect on that traffic. >>> > > >>> > > I will try to gather together 8+ switches when I get home after the >>> New >>> > > Year. >>> > > With that I may be able to observe some traffic pattern change when >>> > > crossing >>> > > switching depth 7. >>> > > >>> > > > The router/switch looks this way: >>> > > > - WAN (eth0) >>> > > > +- LAN1 (eth1) >>> > > > +- LAN2 (eth2) >>> > > > +- WLAN3 (wlan0) >>> > > > The router is running openWrt. >>> > > > >>> > > >>> > > Tomas >>> > > >>> > > On Wed, 2019-12-25 at 09:15 -0800, Mike C. wrote: >>> > > > > >>> > > > > I happened to have a netgear FS105 nearby. Plugging in a laptop >>> to a >>> > > switch >>> > > > > port, and plugging a patch cable between two other switch ports >>> and >>> > > pinging >>> > > > > a random ip address from the laptop set off the broadcast storm. >>> > > Running >>> > > > > tcpdump from the laptop showed a bunch of "MPCP, Opcode Pause, >>> length >>> > > 46" >>> > > > > packets. Unplugging the loop, the packets stop immediately. >>> > > > > >>> > > > >>> > > > The reason this works and why I suspect it won't work on the OPs >>> router >>> > > is >>> > > > the Netgear isn't a 802.1D (Spanning Tree Compliant) switch. Those >>> > > > multicast packets are flow control packets and would not be >>> forwarded >>> > out >>> > > > all switch ports downstream as per 802.1D they're reserved to be >>> acted >>> > > upon >>> > > > only by the switch. >>> > > > _______________________________________________ >>> > > > PLUG mailing list >>> > > > [email protected] >>> > > > http://lists.pdxlinux.org/mailman/listinfo/plug >>> > > _______________________________________________ >>> > > PLUG mailing list >>> > > [email protected] >>> > > http://lists.pdxlinux.org/mailman/listinfo/plug >>> > > >>> > _______________________________________________ >>> > PLUG mailing list >>> > [email protected] >>> > http://lists.pdxlinux.org/mailman/listinfo/plug >>> > >>> _______________________________________________ >>> PLUG mailing list >>> [email protected] >>> http://lists.pdxlinux.org/mailman/listinfo/plug >>> >> _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
