CPE VLAN & Trunk Mode in SRS


#1

Hello,

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.

Tim


#2

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.

Tim


#3

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…)


#4

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.

Tim


#5

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”.


#6

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.


#7

The requested functionality is standard in most other established vendors. There is a 60GHz manufacturer who is also lacking VLAN features as they are also relatively new to the PtMP space.

I have seen these sorts of requests elsewhere, and I have made such queries to support and in tickets. I am regularly surprised at the lack of seemingly “industry standard” features… but everyone seems to make it work somehow (including me). I look forward to Mimosa continuing to innovate, but also continuing to “complete” their firmware so it is truly competitive with other vendors in functionality, not just “speed”.


#8

The boilerplate response to this is “do that with your demarc router”. This is a hypothetical possibility, for you. In my case, I don’t use a demarc router (since all of the other hardware I use can handle multiple VLAN configurations), and I am not in a position to just start installing them everywhere. Although… when I actually start providing multicast IPTV, I will need to create tunnels since Mimosa does not yet support multicast like the other vendors do.

The current work-around to accomplish your goals would be to use QinQ with VLAN per CPE configured. Then, create 3x QinQ VLANS (one with your native traffic, one with native and VLANs, and one with all VLANs). You then select the QinQ VLAN per customer, and all the traffic inside it is passed to the customer.

The problem comes with using switches. It seems the switches I use don’t let you easily put the same VLAN in multiple QinQ tunnels even though it appears to be a basic L2 function. If you are going straight to routers, you may be able to pull this off without much effort.

I am definitely looking forward to a more industry-standard VLAN implemenation.


#9

Alright guys. I think I get the memo that lots of other manufactures have this functionality in their products. (Bet LTU doesn’t) Thank you for telling me. I apologize if I have presented myself as not reading your messages in their entirety and not seeing anyone mention this fact. Doesn’t change my view of the situation or my answer to the question asked or my opinion of Mimosa’s feature set progression.

In the mean time I would half agree with @Christopher1, “do that with your demarc router”. You will probably need equipment on both sides of the Mimosa link to do the tagging and un-tagging for you. I am not certain that Mimosa’s QinQ VLANs will work for @Timothy2’s situation, but good luck.