Possible network loop-Help


we would like your help regarding network loops. We are using a lot of Cambium products and we are now possibly having an a network loop caused by a client connected to a 3000l radio. The radio is running on the 4.5.6 firmware.

Is there any way we can guard against such occurences? Is there any setting that will allow us to identify such a loop early on (possibly even find which client antenna broadcasts the looped packets)? Is there a way to nulify or ameliorate the effects of the network loop? We are also using cnmaestro so please let us know if we can do anything from that end.

Thank you very much!

Maybe STP or use SM in router mode?

I assume your client radios are bridged then ? Do you have a router behind the client radios that you hand an IP to ? Are you doing PPPoE ? Need to to know more about how your clients are set up.

Thank you both for your contributions.

Here’s how the network is setup:

  • The p2mp antenna is bridged

  • Client radios are bridged

  • We are using PPPoE and the authentication is done on the client’s router

If there is anything more specific you can suggest based on the info I’ve provided, it’d be great. Thank you so much again for your timely responses!

Firewall rule on the CPE to block all but PPPoE session and discovery. Then there should be nothing the customer can do behind your radio to affect your network.

If you are also managing the “client’s router” you may want to make some rules to specifically allow whatever is needed to access the router.

1 Like

Hi brubble,

we will try it out and let you know. I have one question though regarding the “deny all” from lan interface rule: would that have no implications for the client’s internet access? Does it mean that it will block all local packets from going beyond the cpe radio and thus preventing them from affecting other clients?

Also, what are other causes of a network loop?. Could it be malware or faulty radio somehow mirroring packets (e.g., ePMP 1000 now starting to cause a LOOP)?

Thank you so much for your help!

1 Like

The first two rules allows the PPPoE connection to work and the third rule blocks everything else.

The most common problem with a bridged radio and customers is that the customer plugs the CPE into one of the LAN ports of their router instead of the WAN port. Depending on how your network is set up and what subnets you are using this could cause a lot of different problems. A less common, but potentially worse problem is that without vlans and/or firewall rules the customer can connect to your bridged radio and gain access directly to your network.

Ideally, if your CPE is bridged then you don’t want anything passing through that radio from the customer side that you have not specifically allowed. That’s what having the “deny all” rule at the end of the list of “allowed things” does (in this case the list of “allowed things” is the PPPoE discovery and PPPoE session).

Something else to note. By default PPPoE servers are configured to use port 8863 for discovery and 8864 for sessions. If your pppoe server is configured to use different ports then you will need to change the firewall rules accordingly.

edit: oh and the order of the rules matters. The Deny All has to be the last / bottom rule.

1 Like

It is easier to just not run bridged and put the pppoe in the CPE radio unless you provide a managed wifi router, in which case that router must be the firewall point to block everything except your authentication method and use a VSA to modify the firewall once authentication is accepted.