CPE VLAN & Trunk Mode in SRS



We are running into an issue where we are trying to deploy A5’s but the current firmware limits a SSID to either have per CPE vlans or trunk all vlans. We need some CPE’s to be trunk mode, some to be a single native vlan, (and ideally a third option, a native vlan + trunk)

This is pretty common on cambium and ubiquity equipment.

Our scenario/use is for BRAS/radius deployments where the native vlan from the customer needs to be a specific tower vlan but we also need to be able to trunk in and handle both tagged and untagged traffic to CPE’s on site.

Is this reasonable to expect from a future firmware? We would greatly perfer the vlan setting to be per CPE, and mimic most switch chips in that the port can be the following;

Untagged traffic only in from the LAN of the CPE, apply “x” vlan tag to it in the radio and send it up to the AP. (traditional vlan tagged access port) block any tagged traffic from passing up to the AP.
Untagged traffic + tagged traffic. Tag untagged traffic in from the LAN of the CPE along with tagged traffic, apply a tag of “x” to any untagged and send up, allow other tagged traffic also up to the AP. (traditional native vlan + tagged)
Tagged only: Discard any untagged traffic, allow only tagged traffic to pass up to the AP. (tagged only port)

Ideally with an option to set in the A5 which tagged vlans to allow/listen to so someones random internal tagged VLAN isn’t leaking in.



One other issue is that there are no current protections for management VLAN, even once a CPE is associated with a tower the management VLAN can still be tagged itno from the lan side. This would allow a customer to connect to our management VLAN if they knew the vlan ID (or sniffed it) and possibly access management systems they should not be.

I would like to know if these feature requests are reasonable and/or possible ETA as it will effect our chances of deploying this equipment.

Both features exist and are common on Ubiquiti and Cambium equipment.



TLDR: I don’t know, but I would not bet on complex VLAN stuff to be doable on Mimosa CPE within the next year.

Calling on @DustinS for insider information, I have no idea, but that has never stopped me before!

Why are you trunking all VLANs to one/several CPE and only one to others? Are you trying to back-feed an AP through a CPE? (if so, I have suggested it a couple times to my boss, if you are doing it I would love to hear about it, both of us think it would be a cute trick, but not very viable…)

Currently, Mimosa CPE don’t do any of the tagging, it is all done on the AP, where the processing power is.

Doing what you want to do, might be in the works, but Mimosa has repeatedly made software/design decisions that do not correspond to what every one else does. If you are looking to make your CPE do complicated things I would not hold my breath for Mimosa. Also Mimosa has a lot of other feature requests piling up and you are the first one on the forums I have seen request this.

That said, it seems like we are due for a big Firmware update. I don’t have any special information, but if Mimosa keeps to their schedule I would guess it would show up pretty soon.

As for your second question, have you hooked up a router/switch with VLAN capabilities and tested this theory out? Seems to me that either the packet would be retagged at the AP with the Customer’s tag, or dropped because your firewall saw management traffic hitting where it should not or it would be double tagged and dropped because your network doesn’t know what to do with it… Unless your Customers have access to the management of your antennas, they can’t tag their own traffic… Although, I guess if the AP saw that the traffic was already tagged then it might just let it pass on by, but that would not be how I would expect it to work. (Maybe Mimosa Support would be a better place to bring this question…)


Re: Why some CPE need VLAN tagging and some a native VLAN:

We have private layer2 service (businesses with multiple sites) so some customers have a VLAN which carries local LAN traffic to other sites, another VLAN for voice traffic internal to the customers network)

We also have our own customers on a seperate vlan which receives 802.1p priority flagging at the backhaul level for VoIP and a seperate internet traffic VLAN.

re: the question of management passthrough in trunk mode, yes, our lead network engineering tested this and was able to reach the management IP/network via setting the management VLAN on a device connected to the CPE with the A5 set in trunk mode. My guess is they don’t distinguish that management VLAN as being management only and disallowed from the LAN side.

Some of these “advanced” features as you say have been included in Ubiquiti and Cambium products for many, many years and are pretty standard on any basic managed switch. Access ports, trunk ports, trunk ports with a native vlan ID, declared members of each port. This isn’t some amazing feature set, this is basic VLAN access control/security here.



Not trying to be argumentative here, just stating what I think to be the case. Mimosa is building a product that delivers fast wireless access, I do not think the features you are wanting will be around soon.

I run Ubiquiti and in some locations we have had to make our router do what the Ubiquiti used to do, we manage everything already for those customers, so not a big deal for us.

As for management VLAN stuff. You probably will want to talk to Mimosa Support, none of us here are the software engineers or anything like that. (AFAIK)

I am not saying the “Advanced Features” are bad or are not useful, just that Mimosa has not built a product that does that and I would not expect those features soon. If you want to do what you are talking about with VLANs you will have to supplement with a “basic managed switch”.


I don’t know of any additional VLAN implemetation coming any time soon. This would be a better question for our Product marketing guys like @David and I don’t even know if he could really elaborate much on unannouced or planned features until closer to launch.