thanks  @Bruce @GIdenJoe    @Bruce wrote: I’m still in two minds about the MS390. From a futures perspective, yes it will be the best switch. Should you deploy it now? Hmmmmm... if you just want switches doing nothing too special in small stacks (three or less), and you’re happy for the odd hiccup and to run the MS14 ‘beta’ code then I reckon they’re probably deployable. ...and that`s the point, for now the switches will be used for wired-access /w 802.1x and to connect APs maybe via mGig... for this to achive the 355 Series would be fine! But when it comes for future use and one point out of that would be in my opinion Adpative Policy/SGT than I`d have to go with the MS390...   The thing is... when I use the MS425 in the core and they won`t support the Adaptive Policy feature neither in the future as well - the design is`nt as good for future proof! So I`d to use the MS390 (/w all differences e.g. like flexible-stacking compared to the MS425...) or mix Meraki MS-Switches with Cisco Enterprise C9K devices - which I honestly would like to avoid! 😕 ... View more

hi @All do you still think the same way today? how is the experience with the MS390 series as of today? I’m also considering a MS425 flex stack in a new deployment and use the MS390‘s as physical stacks as access switches! One reason for me is that I was told that the 390 would be the best for future use - e.g. of the hardware specifications, Adaptive Policy feature etc. Maybe someone knows if SGT would also be supported on the other switch models like MS425, 350 and 250? ... View more

@Bruce thank you man for that detailed explanation! I appreciate that help on this topic very much! 👍 Just for my better understanding - when RSTP is disabled on a switchport, does this automatically mean that there is some sort of BPDU-Filter active? ... View more

please allow me two more questions on this topic..   1-) @Bruce wrote: For straight 802.1x assignment of a VLAN when a user first connects to the network, CoA isn’t required.  what is the reason from technical perspective - the CoA is disabled per default in the dashboard?   2-) @Bruce wrote:  Enabling CoA configures the switch to listen for CoA messages from the RADIUS server. This allows some more advanced servers, e.g. Cisco ISE (there are other vendors too), to tell the switch to perform the authorisation of the switch port again, so allowing the VLAN to be changed after initial authentication has been performed. This is useful where the RADIUS server has separate threat feeds, or is performing ongoing posture monitoring and can detect, or be informed, of a change in the client state. maybe you know the current possibilities when using ISE in combination with Meraki MS Switches products? I´m not sure what of the features are supported compared when using the Cisco Enterprise devices e.g. device profiling, posturing, TrustSec, etc.   @Bruce wrote: There is also a new feature that you may be interested in too called Group Policy ACL, https://m.youtube.com/watch?v=nekC3_z5SDk. It’s akin to dACLs on the Cisco Catalyst. I can’t find any information on the Meraki site about it, but it was included in the MS14.5 release notes - so you’d need to run the beta code train. thanks for pointing me to that - I´ll have a look and try to understand how this can be used probably in my deployments as well 🙂 ... View more

hi @PhilipDAth,   thanks for your reply on this post! ok... but the local DHCP-Server on the MX is NO option in the project I‘m currently working on! Unfortunatly another reason more (in the meantime they‘re many...) why I’ve to think twice if the MX is really a security component to compete with other vendors on the market! 🤨     ... View more

so it isn‘t necessary to enable CoA for the dynamic vlan assignment to work, correct? if so, why does this option than exist and where/when should or could it be used? ... View more

so it isn‘t necessary to enable CoA for the dynamic vlan assignment to work, correct? if so, why does this option than exist and where/when should or could it be used? ... View more

so the tie-breaker is always the lowest device MAC-Address which determines the Stack-Master and the device-type (e.g. stacking MS225 and MS210) does‘nt matter or influence the election also? ... View more

Hi, looks like the posted link is`nt available anymore?! 😐 Maybe somebody can help and share one that works? thanks in advance and kind regards ... View more

I`ve just looked at the configuration on the bottom switch again and I`ve to say that I made a mistake in the sketch! the port (towards where RSTP is disabled) is an access port untagged in vlan 1 ... View more

someone any ideas on that? ... View more

Hi, @DarrenOC thank you for your reply on this topic! But what I don't understand is that RSTP is disabled on the port and the connected device speaks STP ... so I don't understand why it works without problems / loop at all! ... View more

great, thanks for the fast help to both of you! have a great weekend! ... View more

@GIdenJoe what do you mean when you say they are not aware when their traffic is encapsulated in an VxLAN header? because their traffic will be en-/decapsulated between firewalls which act as the VTEPs... 😅 ... View more

  @Bruce wrote: @whistleblower personally I’d go with plan-1. For a network this size I’d try and keep dynamic routing out of it and if you can achieve your high availability goals using LACP then that’s likely to give you less problems. Dynamic routing has its place - where you expect to add or remove subnets and that would cause a lot of changes to static routes - but I probably wouldn’t use it here.. OK, but there are no technical advantages or disadvantages, at least I don't have any obvious ones in mind...  🤔     You’ll probably want to allow for a management VLAN too, which is the one the Meraki switches internal management interface will use to connect to the Dashboard. It is highly recommended (basically don’t do it) that the management interface VLAN for a switch doesn’t have a SVI on the switch itself. So your management VLAN will likely terminate on a router or firewall facing the internet, and would be a second VLAN between the head office and data centre - another reason to use plan-1 (unless you have internet access from both locations). that`s a really good and of course important point - thanks for the hint! 😅 Hm, but then I´ve to change the switchports from Access-Ports "untagged" to 802.1q Trunking... allowing the so called "transfer-lan" for Routing and as well the Layer2 Vlan for Management as well as the Native-Vlan1 for RSTP and so on... ... View more

I can´t find the Heat-Map with the Time Lapse anymore? Is this function no longer available in the dashboard? ... View more

... OK guys, I think I`ve got it - I looked also over some official documents for Cisco Enterprise and I think I understood the basics about the Hashing topic now 🙂 - thank you very much!   may I ask you if you can give me your assessment of the planned design as well? A MS350 Pair (physical stacked in the HQ) and a MS425 Pair (Flexible Stack, one of each devices in two different DataCenters interconnected with DarkFiber) should use both physical Lines at the same time (= Load-Balancing) for transfering IP-Traffic between the locations! please have a look at the attached plans, what would you say is the better solution from your side of expirience? Please notice, for Plan-02 I´d like to use OSPF as dynamic Routing Protocol!   Plan-01     Plan-02       ... View more

Hi Bruce,   first - thanks for your response, I appreciate it very much!   @Bruce wrote: The Meraki devices don’t have a Layer 3 LAG, in the same way you can’t make a port a Layer 3 interface. The closest you can get is create an SVI (Layer 3 interface) for a specific VLAN on the switch at each end, and the use a LAG which contains only that VLAN.  maybe you or someone can point out, what would be the difference (advantage/disatvantage) between that suggested solution and a "classic" Layer3 LAG? Probably a better design would be to use no LAG and instead dynamic routing /w the same metric over both links?   The Meraki LAG - which uses LACP - makes use of the IP addresses, MAC and port in its hashing algorithm to determine the member to use, and it not configurable. Please see here, https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Link_Aggregation_and_Load_Balancing. what does that mean exactly - so would e.g. a Server with the IP-Address 192.168.1.1, MAC: aaaa.aaaa.aaaa and Src. Port TCP-3389 always use the same link, without consindering the Destination Side?   ... View more