Also MS does not have a limit to the number of clients in a network that can have a group policy ACL assigned, the limits stated in your initial post are based on static assignment done in dashboard that is applicable to MR and MX. If you were to assign group policies by RADIUS on MR and MS there would be no specific limit.  ... View more

Ok I will do my best here. The 390s have a limit of about 5000 active ACE entries on the platform at any given time. The 355s are about 600 ACE entries active at any given time, and the 125s unfortunately do not have the TCAM for group policy ACL assignment. That being said, a single 30 line group policy ACL with 100 clients associated to it, will take up 30 entries in the TCAM due to the way the ACLs are applied to the endpoints. This is the same across the 390 and the other platforms that support GPACL (210/225/250/350/355). These do require a RADIUS server to apply them, so you would need to enable at the minimum MAC Auth Bypass to start applying group policies to clients on switching. Hope this helps!  ... View more

@GregErnest What model MS do you have? Group Policy L3 ACLs are implemented via RADIUS whether it is through a dot1x or mab session. Different platforms have different limits to the number of active ACEs.  ... View more

The bullet was with regards to @cmr s work of sorting the change log by model.  ... View more

Thanks for having me @merakisimon !  ... View more

Connecting an appliance to both DNAC and Dashboard is not supported today. We are investigating a means to provide the functionality but have some firmware limitations we have to investigate further.  ... View more

Hah Thanks @Larry_Woods ! Please feel free to provide feedback via the blog post or here! ... View more

That guide or check our documentation at: https://documentation.meraki.com/MS/Meraki_MS_Beta/StackPower  ... View more

easy to do, the ui could use a little modernizing!  ... View more

If you have RADIUS testing disabled and still see this alert, it could be due to a client connecting and failing authentication, which led to a dot1x authentication failure. These are tracked as a health alert. ... View more

This is a function that was added to MS14 on a few specific switches. It watches traffic for anomalous behavior that would indicate a device is NATing clients. The intention was to try and help people identify rogue access points that are NATing and catching clients that are using VMs that may be performing NAT to the host address. We are working on producing documentation but as of today, I would recommend daily alerts, as if you have misbehaving or oddly behaving clients, it can produce false positives due to the nature of fingerprinting.   ... View more

This feature is for Named VLANs to VLAN ID mappings for RADIUS. We definitely do want to leverage this further down the road for more than just simplifying RADIUS deployments. Please use the feedback button at the bottom (that we for some reason renamed from make a wish) and let us know there if you wouldn't mind.  ... View more

if youre using rapid-pvst just include vlan 1 in the trunk between the Catalyst upstream switch and MS. This will ensure that the stp formatted BPDU makes it to the RSTP process and prune any unused VLANs from the trunk ... View more

Just to add to this release note. The addition of accounting on the MS390 also includes extra attributes for the endpoint including DHCP, LLDP, and CDP information to assist in greater profiling on Cisco ISE and any other supported platforms.  ... View more

Hey, these are good questions. Your L3 switch or switch stack will need to have it's management IP within the uplink subnet with a default gateway that is routable to the internet. This does NOT mean that it cant be in the same L3 segment, but you have to have a control plane MGMT IP & Data-plane IP. Example.    Northbound uplink is 10.0.0.0/29.    Neighbor is 10.0.0.1 switch SVI is 10.0.0.2 and default static is 10.0.0.1 switch management is 10.0.0.6 and default gateway is 10.0.0.1 You can absolutely peer with 10.0.0.1 using OSPF for dynamic routing, but the management interface (10.0.0.6) must be able to statically point to 10.0.0.1 and reach the internet.    ... View more

We are working towards bringing adaptive policy to the MX and should support most of the current platforms out today from a hardware perspective. Official support has yet to be determined but we are hoping for a beta of SGT being carried over AutoVPN on MX sometime Q1 FY21.  ... View more

ISE is not required but does make assigning SGTs to an Access_accept incredibly easy. You can assign tags in a few ways. 1. Statically to a switchport or an SSID, dynamically via RADIUS av-pair, and in the near future, you will be able to create Network Object Groups and map them to SGTs as a fallback tagging mechanism. ... View more

Excellent work Amelie!!!  ... View more

Totally, it is an unfortunate scenario for sure. I honestly wish that from an IOS perspective that STP was MST by default due to greater initial compatibility. At Meraki we have tried to make sure we document where we can, as R-PVST can bring down a network unknowingly.  ... View more

I meant that there is better compatibility between platforms, not that we now allow for design issues. The proper design when an MS is intended to be the root bridge is MST on catalyst to allow for proper interop. The issue you brought up is still an issue as it is an improper spanning-tree design.  ... View more

The overall system level function of the MS390 supports decoding of R-PVST and with the implementation, MST single instance is backwards compatible with R-PVST functionality. This will inevitably reduce the number of configuration issues due to trunk configurations etc that is seen in classic MS to R-PVST deployments.  ... View more

The MS390 will support single instance MST which will integrate much better with R-PVST from a compatibility perspective.  ... View more

Try downgrading to 24-12. I have a customer where this is happening and a downgrade to 24-12 fixed it for the time being.  ... View more

Physics doesn't have an opinion.    I wasn't calling you out on your recommendation to plan for mgig. It will be great for 802.11ax.   I am referencing you saying that today we have an AP that will put 2.5gbps on the wire. It is simply not possible today. Wireless throughput and wired throughput are vastly different as wireless throughput suffers from management frame overhead that can at times hit anywhere from 30% overhead to 60% overhead in contentious environments. The wider the channel the higher the overhead as well. I am not agreeing to disagree as I am stating a fact in how wireless medium throughput operates. Unfortunately 160mhz isn't doable today and is why we have it disabled in dashboard.   Once again I don't disagree with your recommendation to plan for mgig.      ... View more

"  Note that you can already get AP's that can generate 2.5Gb/s of load - so the dual Gigabit circuits is not enough."   This is a pretty misleading statement. Under theoretical and or perfect environments you could possibly exceed a gigabit per second, but you would be putting your APs at least at 80mhz wide channels. This is not sustainable from a channel planning perspective today however and thus in high density and even medium density offices you will more than likely be shooting for lower channel widths such as 20 or 40mhz. I do not know of a single AP on the market that is actually capable putting close to 2.5gbps on the wire. This is due to the amount of overhead associated with wireless transmissions and the fact that there still remain little to no 160mhz wide capable devices that are also leveraging the 3+ spatial streams. ... View more