If you could ask for any MS switch feature ...

Kind of a big deal

If you could ask for any MS switch feature ...

What would you ask for?


Things on my list are:

  • Systems Manager support for Meraki managed certificate based 802.1x for Windows like there is on Mac 
  • VRRP between switch stacks 
  • IP SLA based static routes like on the MX (so route gets withdrawn on ping failure) 
  • Larger ACLs (limited to 128 entries at the moment) 
Kind of a big deal

Larger ACL's this is the one reason we didn't go with Meraki for our core routing. 


When you spend hugh amounts on an MS425-32 you expect it to handle more than 128 ACL's....

Getting noticed

Definitly :


PORT SECURITY like CISCO CLI. (Possibilty to allow 1 Mac adress with dynamic mac adress table)

This kind of configuration could prevent installation of unwanted Dumb switch or router by customers 


Example of configuration in CLI I really would like to have in Meraki :


interface FastEthernet0/1

switchport mode access

switchport access vlan 601
switchport port-security maximum 1 vlan access
switchport port-security violation restrict
switchport port-security


Actually no feature purposed by meraki could help us to prevent unwanted network devices


- Stiky mac address : Not an option, to many change, no time to manage that

- 802.1x : not an option, we don't use computer in domain

- Mac address whitelist : not an option (same as the first)


So actually anyone who plug a dumb switch or router in meraki switch with minimum of knowledge with IP adress broke the security

You can get pretty close.



Kind of a big deal

I'm with @damienleick. I've had a maximum MACs feature request in for over a year...

Kind of a big deal

Critical fail-VLAN

Netflow export


VRFs at least for the bigger boxes


P.S.: @damienleick Port-Security doesn‘t give you any more security than not handing out IP addresses via DHCP. 😋 If you want to set the bar high enough, there‘s nothing else but proper 802.1x. That doesn‘t necessarily mean you‘ll have to use a domain.

Kind of a big deal
Kind of a big deal

Better visibility of power supply states when using the models that connect to the Cisco RPS2300.  At the moment the only way of telling that it is working from either the GUI or being in front of the switch is to ... look at the lights on the RPS 🤔


Also the MS1xx switches should support the RPS2300

I understand but we have more than 5000 computer and absolutly no time to use 802.1x. Port security with dynamic mac adress is very usefull and prooved in our CLI network for the last 10 years.

if the customer plug a dumb switch in our port switch and plug two computer in the dumb switch he's going to call us because nothing work correctly thanks to port security. With that we can say to him "NO" dumb switch we don't provide to you is not authorised in the network, it's a security breach.

I know it's not perfect but this little feature do the job 99% of time contrary to Meraki

Not what we want. Sticky mac doesnt release the mac learn if the computer is unplug

Building a reputation

You can prevent a smart switch being installed on a port by using STP Guard.



"If a port with BPDU Guard enabled on it receives a BPDU, the port will transition to a disabled state"


Of course a dumb switch could still be plugged in, but there's less you can do with a dumb switch.


As for 802.1x it could use any source of RADIUS.


I agree I would like to see a richer feature set on here, but turning them into Meraki Catalysts is not appealing to me.  We bought Meraki to get away from the Catalysts, to make our network more junior administrator friendly.  The organization doesn't want to have to hire a network engineer at every subsite.

@Brons2 as i Say 802.1x is not an option for different reason


- computer not in domain,

- computer is not ours

- to many partner devices


99% of time switch are dumb in our case is STP Guard is useless.


I cannot imagine Meraki hasn't eaven think to protect the Network of dumb Network equipment.


I know Meraki is not catalyst but port security with a max 1 Mac adresse on the port an release it when the port is down do the job 99% of Time.


Meraki is able to learn Mac adress with sticky Mac adress security so  I'm pretty sure is not very complicated to add a task to ecrase the learn MAC adress when the port go down (Up/down on switch port are logged)





Building a reputation

I add my vote to this functionality. The supplier of our factory hardware is constantly connecting cheap unmanaged to our switches and hence a Meraki switchport allocated to support one particular device (e.g. a PLC) suddenly had lots of devices on it and we have no knowledge.


What I would like is to either:

a) Specify maximum concurrent MAC's on a switch port


b) Using sticky MAC, for the MAC to be erased when the device is disconnected (hence allowing another client to be connected - i.e. on Hot Desks).



Kind of a big deal

- QoS priority queue
- NBAR also for better matching traffic classes in QoS policy and netflow export
- Full MSTP support
- PACL, RACL, MACACL, dACL, per user ACL (not just VACL's like we have now)
- Static etherchannel support
- Local feature debugging and status of protocols!!! (STP and STP guard states, UDLD,...)
- Trunk ports as STP edge ports
- Better control over SPAN session(s) like ingress traffic and dot1q replication

Just to name a few.

Getting noticed

Right now I'd just settle for a voice VLAN fix. 😕

Building a reputation

@mcvosi What's the problem with the Voice VLAN then? I am using it at a couple of sites with issues.

Getting noticed

This thread talks about it: https://community.meraki.com/t5/Switching/MS250-14-32-access-policy/m-p/133294#M9848


It's also mentioned in recent "known issues" in release notes.


Building a reputation

Luckily I don't have that issue, I have RSTP enabled and BPDU Guard enabled, and am running 14.32 🙂

Getting noticed

Do you have endpoints connecting through Cisco phones?

Building a reputation

I have endpoints yes but the handsets are not CIsco




Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.