SM Loopback Detection

We occasionally have a problem where failing customer premises equipment acts as a physical loopback on the SM Ethernet interface, causing the SM to forward the frames it receives back onto the network, unaltered. When this happens, it causes significant problems and can be difficult to troubleshoot.

Cisco equipment mitigates loopbacks by sending and listening for keepalive frames. If a keepalive is received on the same port it was sent from, a loopback condition is detected and the port is disabled. This is separate from and complementary to Spanning Tree Protocol.

Together with the suggestion to limit the number of learned MAC addresses per SM, this feature would improve reliability in larger broadcast domains.

We believe unicast traffic would stop at the SM, because the SM bridge table would not allow this.

Regarding broadcast traffic, the feature "Enable Broadcast/Multicast Data Rate" (Configuration > QoS), can limit the amount of broadcast traffic going through the link, limiting the effect of a broadcast storm condition.

Please help.

The Cambium PMP450 SM

What does it support regarding Spanning-tree Feature Wise. Is it enabled for STP be default or not and which mode?What does it do with VLAN information i.e. pass all / get involved. I was reading about the management VLAN seperation from wireless interfaces. Should we be assigning a different VLAN to Management than our default 1 we using across the wireless trunks for switch management?

I know for a fact that a customer can loop the network and trash the entire network through the SMs, when we have protocol filtering blocking IPV4 and IPV6 multicast on the uplink, and with a 32 kbps broadcast/multicast uplink rate set under QOS.  The most recent one was somebody adding a Apple router set to rebroadcast wifi and also connecting it with a cable.

So I'm very skeptical about this being available now.

Sorry to bump this old thread, but with respect, Ted is right.

The SM forwards broadcasts to the attached loopback. The loopback sends the broadcasts back out through the SM, and all bridges, including the SM, learn the source MAC address of the broadcasts from the loopback, causing the bridging topology to flap.

Loopback detection on the SM, via keepalives or whatever measure you choose, is the key way to mitigate this. Limiting bridge table entries will also mitigate this indirectly, and thanks for implementing that.