Why has the minimum bridge table size on the sm gone from 4 to 64 in the 24.0 relase?
Nice catch. Hopefully this is resolved quickly.
Are you using something other then the default of 4096, and if so, why?
Someone plugs the line to the radio into their lan, now there are 30+ devices pulling public IP addresses from me. That can exhaust a DHCP pool quickly. I’ve been running a default bridge table size of 4 for years.
Ahhh ok… that makes sense. We run NAT on 99% of the SM’s, so that’s not a problem… on customers that want a static IP beyond the SM, we run the SM in bridge mode, but assign a VLAN and limit the DHCP scope to only assign them addresses in their assigned block.
We’ll see if this get resolved at all. So far Cambium has told me to kick rocks and that it’s going to stay at 64.
I can understand this use case, but this is getting a desired side effect from the feature where it may be better for us to implement something more specific to this use case than relying on the dynamic bridge table entries.
We can look at rolling it back in some way. The reason it was changed is that in some configs, 4 isn’t even enough for our own internal bridged interfaces. So we’ll look at doing some method where customers can get access to some minimum # of entries while ensuring our own interfaces are able to be bridged.
We are using it for the exact same purpose, and is vital for us. Since implementing maximum bridge table size 4, we do not exhaust our DHCP pool. Another plus of using this feature, is that the customers will start having issues if they plug the cable into lan - they will never get more than 2 units working at the same time (best case scenario). If table size is 64, a wrong connection to the lan could potentially work quite nice for the customers, so they do not register that they have plugged it wrong…
Hello All - Just wanted to send an update to this topic. 24.0.1 Beta-4 will post soon. We have done an update in there that will revert the SM’s bridge size config back to 4 if you had it set to 4 prior to upgrading to 24.0 and have not already manually changed it back.
Another enhancement made after further understanding the usage of this is to allow you to configure it to as low as 1. There will now be some distinction between the Dynamic Entries and Static Entries within the Bridge Table Size Configuration.
Previously, our internal static entries for things like management interfaces would consume bridge table entries from the configured pool. This was the main driver for the increase, as 4 would not be enough depending on our some of our own interfaces being online and still allowing for customer side dynamic learned entries.
Now, customer side devices will continue to be seen as Dynamic Entries and those will go against the User Configured Bridge Table Size while we will allow for extra entries that can only be used by internal interfaces. Those will continue to be called Static Entries.
What this allows for is to let the user configure the Bridge Table Size all the way down to 1 dynamic entry while still allowing for internal static management entries.
Here are some examples:
Configuration option showing 1 as lowest value:
Bridge table showing 1 DYNAMIC entry in use and no more free:
Note the updated stats and note here - it shows that there are no more Dynamic Entries allowed yet we would still have room internally for more Static Entries as needed based on internal configurations.
In this case above, any further attempts by devices below the SM will not work, and you can see here that in this example, there were 13 attempts by some other device to bridge through here but the “BridgeFullErr” count incremented indicating we are out of available entries.
Hopefully this helps. Thank you for your feedback!
4 Likes