I know this is an old thread but I need to make some network name changes to scale with our environment so I need to move switches from one network to another but there is apparently no way to do this without losing my port level config - according to meraki support. Did you get anywhere with the python scripts by any chance? In this immediate case it's only 12 switches but that's still a lot of ports to manually configure. ... View more

Good deal - I haven't tested with linux / mac yet but it's full on awesome with AD - all the information for using an l2tpd client show 3des - I had to call in to get some features enabled for I believe some wireless or maybe a firewall setting so it would not surprise me if the same had to happen for AES.  ... View more

I believe you can call in and request AES - I'm gonna have to do this so I can get a VPN node in my datacenter rack.... ... View more

The MS switches can do ipv4 ACLs also - just keep in mind it's not stateful. CIDR would work for isolating your OUs - just setup dhcp scopes per OU to match whatever your vlans for each OU are and you should be good to go. I've done that where I am now a for a few networks and it's working well. You have to know what traffic needs to get to where so you can configure the static routing but as long as the network isn't sprawling it's not too bad. ... View more

I did a similar rip and replace - I ended up using CIDR on each side of my core links to remove layer 2 vlans  traversing my uplinks - set my root on each side and it's running much better now - I struggle with no pvst - I did set my cisco switches / stacks to mst mode but that did not resolve my issues.  I don't allow all vlans across any trunks, I only allow the vlans that are needed - I am always very careful about having the same settings on each side of the link. I miss not being able to do "no spanning-tree vlan#" ..... ... View more

Ha ha - that was it - no idea when that got changed! Thanks! ... View more

I feel like we're simply missing something obvious but several of us clearly remember using this and none of can get it back...tried several browsers, OS'es , private mode..... ... View more

Interesting.....it shows up for the all clients page - but once I click into any client the detail link goes away - we use this occasionally but will need to have this visibility soon.    The clients I'm checking have been on the network for a very long time. good times..... ... View more

I did configure our cisco switches to be in MST mode and still experienced (and continue experiencing) issues - had to break apart all the cisco to meraki port channels to temporarily resolve network crashes - we had major issues with lacp between netapp and meraki - according to meraki a popular config is with nexus level core and meraki distro / access - we don't have nexus so I can't talk to that point. 3750 and 3850s don't play nice .... ... View more

@BadOscar wrote: If you're using cisco controlled wireless the ap ports just need to be access - if you're not then nevermind! Sorry - I missed the part about meraki aps.....useless reply! ... View more

If you're using cisco controlled wireless the ap ports just need to be access - if you're not then nevermind! ... View more

I configured the meraki switch stacks to never be root for the network and published vlan 1 across all trunked uplinks - the meraki stacks all acknowledge the cisco switches as root for the network now and there has not been a designated >  root  root > designated event since I made the changes at 5am this morning - the event logs from the previous few days indicate a STP event several times per day so that looks promising. I'll reconnect the port channel from my other bldg in the near future to verify that problem has gone away also.  ... View more

It does! I guess what used to work for a decade is irrelevant - it will annoy me to no end that this only happens with meraki - the 3850 stack software doesn't indicate there should be any lacp issues but yet it has major problems, only when connected to meraki - could be a different issue with the same symptoms I suppose.  Keep in mind it works fine to a 3750 port channel spanned across member switches to a single meraki switch -  it's not until I stack the meraki this happens.  At least now I have a stack I can test with - unfortunately one of our 350's is a brick now so I can't test meraki to meraki aggregates - still have the root > designated designated >root events going on all the time, only when meraki aggregates are in use...good times ... View more

Sounds good - I would think that if a lacp issue with the software was causing this it would be a problem with the unstacked switch also?....i wish the 350's had the option of using the 40GB ports as aggregates and not stack only....guess I could put 40GB sfp's in the 350s but i don't see why I should have to!  ... View more

It's possible they left the code where it was for the netapp maybe? Not sure, I may have updated the code on the test stack, don't recall - I didn't setup any access to those switches from the lab network or i would check now!  ... View more

the same issue with the 3850 stacks also.....these switches ran lacp between stacks and netapp for many years.... not saying there aren't issues but they have many years of successful connectivity with no issues.... ... View more

The 3750 stack had 2 port from switch1 and 2 ports from switch2 - the ms350 side I used 1 switch with 4 ports as stand alone and as stacked so the ms350 side didn't change except for being stacked -  the code should be 12.2.55...I can verify next week as I don't have these switches on the prod network right now @PhilipDAth wrote: These port channels were from the individual stack members to the 3750?   ... View more

The 3750 stack had 2 port from switch1 and 2 ports from switch2 - the ms350 side I used 1 switch with 4 ports as stand alone and as stacked so the ms350 side didn't change except for being stacked -  the code should be 12.2.55...I can verify next week as I don't have these switches on the prod network right now ... View more

update -    I was able to test by using the (2) ms350 switches I removed form my core - they were stable with port channels to a cisco 3750 stack right up until I configured them as stacked - as soon as the stack was configured in the cloud the port channels failed and would not come back until they were unstacked in the cloud - then the port channels came right up with no problem. The meraki stacking procedure was followed when creating the ms350 stack - the event log threw the usual root.designated designated > root events during this..... ... View more

You are having similar issues as I am...you're not alone! Out of curiosity if you get time - what happens if you connect two separate meraki switches (not stacked, no other connections other than the management connection for cloud connectivity) to an access port to a vlan that doesn't exist anywhere else? I'm gonna lab up a couple of 350's I have recently removed from my stack in case the over 4 switches in the stack was really an issue (it's not) and see how it behaves - I'm suspecting its whatever flavor of MST meraki switches use to apply stp to vlans. ... View more

@DCooper wrote: So to re-iterate, this is only happening pinging to the switch stack ips? The 66% packet loss is not affecting production traffic traversing the switch stack? Yup - the layer 3 interfaces all rspond fine - its the physical ip address of the switch in the core stack - we do experience network hesitations throughout the day that I traced to lacp issues betweena cisco 3850 stack and the meraki stack - still need to try and figure that one out, resolved it temporarily by splitting the port channel off and using a trunked non port channel uplink.  I've been working with someone from your place, we're kinda slammed over here so I haven't been updating much - I can send the support case..there's a very long thread to it! ... View more

@DCooper wrote: @BadOscarI am not convinced your the only customer with these issues. Let me see how I can help on the backend, can you PM me the case number? Also, most likely what your seeing when losing pings is ARP entries disappearing, when this happens take a look at your ARP tables and see if the entry for the client your trying to ping has disappeared. If it has try to ping the device from another L3 segment and if it is successful see if the ARP entry re-appears.  @DCooper - I did that and the arp entry for my wrkstn is there - I'm not pinging a client, I'm pinging a stacked switch member - all the switches in the access stacks reply as expected - there are 2 switches in the core stack that either don't respond at all or have 66% packet loss....like clockwork. Other switches in the same stack and subnet respond fine - these results are consistent across 3 vlans I've tested from. I've been checking my routes and interfaces to make sure I didn't fat finger something but it looks fine - and really if it was that none of the switches on the subnet would respond. Thanks ... View more

@DCooper wrote: @BadOscar I think this is a relevant topic. Has there been a support case opened where support has reproduced this with you?  There is - last I heard it was getting lab'd up several weeks ago.  We've been moving our critical services back to a cisco stack - this weekend we are moving the rest of our netapp / vmware stuff so that the network doesn't keep crashing.  Once that's done we'll see if things stabilize as before moving to the meraki core we weren't having these issues. I had the access stacks connected to the old cisco core for months without any issues so I don't think its the stack size and removing 2 switches from the meraki core did nothing but move the ping drop issue to a new switch. My question did not get answered so it seems that nobody else is experiencing these problems so it pointless to waste someone's time trying to figure out an issue with going through this thread. ... View more