What would you ask for?
Things on my list are:
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....
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 :
switchport mode access
switchport access vlan 601
switchport port-security maximum 1 vlan access
switchport port-security violation restrict
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
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.
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
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)
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).
- 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.
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.