Since we have to operated in bridge mode, Is there any way to prevent a rogue DHCP server from taking over the network?
The easiest way would be to put each client in its own vlan and force tagging all packets from the ethernet port. This way only that customer would have issues.
Now why do you have to run in bridged mode?
We only do ipv4 at this time and the v1000/2000/3000 do not offer a NAT or Routed mode. In our ePMP CPEs we are able to choose bridge or NAT/Routed, and they have layer 2/3 firewall.
Setting up a single VLAN for every client would require a DHCP server per VLAN as well… this would be very impractical.
Not really, the same dhcp server can be used by way of dhcp relaying.
Depending on your tower router though it could be a bit of a challenge to setup though
There is no Tower Routing in a cnWave Mesh network?
Thats a half truth, in a mesh setup there is still a router but it is not for use in the mesh. The router is used as a ipv6 subnet anchor and to provide inter site communications if you have more than one location with DNs installed or more than one uplink out of the network.
Btw the OP is using ipv4 in bridge so no mesh.
Enabling the broadcast filters in the POP network config will block DHCP servers on CNs and downstream DNs.
Thank you for your answer.
So if I set “envParams.CAMBIUM_L2_BRIDGE_DISABLE_BROADCAST” to “True” it will prevent any DHCP or from the CN.
We are currently using PPPoE Server at the gateway but would like to change to DHCP if it can be secured… will PPPoE Discover and Data still work with Broadcast disabled or will this break it?
Is there any other reason not to enable it?
I am not sure about PPPoE. My understanding of the ‘disable broadcast enabled’ is that you will need to configure your DHCP server to add ARP entries and manually add static ARP for any clients that have static IP’s configured. I wish there was more documentation on the feature.
@3-dBnetworks . You are correct.
That flag (at POP) blocks any downstream broadcast packets including client to client. Communication between upstream DHCP server and clients will work fine. PPPoE Server communication should work fine too.
However, communicating with any IPv4 server on the nodes/client (device GUI or ssh) requires ARP request from upstream switch to the nodes. Since this packet gets blocked as well, device GUI/ssh wont open. Config/stats are at E2E controller, I hope there is no real need of device GUI. In case device GUI/ ssh access is required, the work arounds are - Use node’s IPv6 address / enable the flag momentarily to let the ARP pass through / add static ARP entries on the upstream switch.
Thank you @3-dBnetworks Your solution appears to work for me in my Lab setup.
@Kiran_Avva I can confirm PPPoE appears to work fine in the Lab.
Important to note the filter is only enabled on the POP, not the CNs.