Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About bmarms
bmarms
Getting noticed
Member since Jul 30, 2020
Jun 6 2023
Community Record
33
Posts
26
Kudos
2
Solutions
Badges
I’d save yourself the headache and RMA them if you can. If you want cloud managed native Meraki, go with the MS355 series if you need mgig and upoe. I have both ms355 and ms250 in all of our 13 offices and they’ve both been solid platforms.
... View more
I understand Cisco’s reasoning for wanting to manage the Catalyst platform via the meraki dashboard. It seems the MS390 was their first attempt and, IMHO, failed miserably and should have never been offered to customers. hopefully they can get this right.
... View more
i get it but, if we wanted cloud managed catalyst we wouldnt purchase meraki. rather than trying to integrate catlayst and meraki, cisco should be focused on developing additional UI analytics and AI for the merkaki platform as juniper has done with mist. im installing MS355's for now and, when it's time for a lifecycle refresh, i'll be looking at moving to juniper/mist assuming my POC works out. Merkai has yet to announce/release an access point with a 6ghz radio. meraki, like many of cisco's acquisitions, is falling behind their competition.
... View more
I cannot believe they are still selling these devices
... View more
agreed. as soon as i unpacked ours and saw the cisco bag with the catalyst ears etc. as well as the catalyst stack cables i had a bad feeling.
... View more
cisco may have done irreparable damage to the loyal meraki customer base by releasing this model
... View more
the 390's are a frankenstein switch and almost useless. thankfully we had our's RMA'd for 355s. the 355s would reboot every 4-6 weeks on 12.32 code. we upgraded to 14.32, which broke 802.1x on non STP ports, but they havent rebooted now in 6 weeks. had to make sure all of our 802.1x ports had STP enabled. considering a switch to juniper since their acquisition of Mist and their full AI integration at the access layer
... View more
I had a stack of 3 of these I was going to deploy in a new office. thankfully I unpackaged them and attempted provisioning a month or so before ready to deploy and noticed many, many issues with them versus the ease and success I've had with the MS250 models. I reached out to my hardware vendor and cisco rep immediately and threatened the lawsuit based on false advertising as the switches weren't actually capable of what the datasheets said. I was able to get them RMA'd and replaced with MS355's without issue. If Cisco is going to attempt to move Meraki to a frankenstein Meraki/Catalyst monster, I'll consider a move to Juniper.
... View more
Dec 3 2021
6:13 AM
2 Kudos
go to "organization-firmware upgrades" and you should see the upgrade event. there's an icon to rollback that looks like this: click that and you can then schedule your rollback as long as its been 14 days or less since your upgrade
... View more
Dec 1 2021
8:35 AM
3 Kudos
I'd avoid the MS390 altogether. there are numerous posts on this forum as to why. I'd go with an MS355 model versus an MS390
... View more
Meraki was able to identify that STP being disabled on ports was causing the 802.1x issue as the switch was not able to maintain an accurate mac table. I enabled STP on all ports where it was disabled and upgraded switches to 14.32 and am having no issues. Dev is reviewing the access policy not working on STP disabled ports in 14.32 as its no an expected behavior
... View more
Dec 1 2021
8:28 AM
Meraki was able to identify that STP being disabled on ports was causing the 802.1x issue as the switch was not able to maintain an accurate mac table. I enabled STP on all ports where it was disabled and upgraded switches to 14.32 and am having no issues. Dev is reviewing the access policy not working on STP disabled ports in 14.32 as its not an expected behavior
... View more
Dec 1 2021
8:27 AM
the rollback fixed it. Meraki was able to identify that STP being disabled on ports was causing the 802.1x issue as the switch was not able to maintain an accurate mac table. I enabled STP on all ports where it was disabled and upgraded switches to 14.32 and am having no issues. Dev is reviewing the access policy not working on STP disabled ports in 14.32 as its no an expected behavior
... View more
14.32 doesn't fix the 802.1x problem. here's my issue after that upgrade: MS250 14.32 access policy - The Meraki Community
... View more
agreed. I'm having this issue which isn't due to a mac age out and nothing resolves the problem. I either have to remove the access policy or disconnect ethernet and move user's to WiFi MS250 14.32 access policy - The Meraki Community
... View more
here's my issue after an upgrade to 14.32: MS250 14.32 access policy - The Meraki Community
... View more
Nov 5 2021
7:52 AM
Anyone have any issues with access policies on release 14? I upgraded an MS250 stack from 12.28.1 to 14.32 at the request of meraki support. Since the upgrade, we've had a number of user's ethernet nics showing as "unauthenticated" and the switch port not passing any traffic. switch/radius server/and computer Wired-AutoConfig logs all show successful .1x authentication yet the switchport does not pass traffic. the only way I've been able to solve is to remove my nic and re-add it to my machine. once i reboot though, it returns to an unauthenticated state. I've had to remove the access policy from the switch ports altogether or move user's over to WiFi. I'm rolling back to 12.28.1 to see if the issue is resolved.
... View more
Apr 21 2021
7:33 AM
you can do this in API 1.0. latest is 1.7 i believe. that's what i'm using
... View more
Mar 20 2021
5:13 AM
You may want to review this document and understand the different mx modes and their bgp functions. https://documentation.meraki.com/MX/Networks_and_Routing/BGP Your cloud vmx would need to be a one armed concentrator to perform the functions you’re looking for. You’ll need ebgp (different asns) between pfsense and vmx
... View more
FWIW, i would've done things a bit differently to simplify 1. i wouldve used the second octet in my ip address scheme as a site identifier vs. the third. makes route summarization easier. in other words, site A ip subnets would all fall under a 10.1.0.0/16 CIDR and site B under 10.2.0.0/16. you could then use 10.x.1.0/24 for data, 10.x.2.0/24 for voice, etc. x being your site identifier in the second octet. 2. the only trunk ports you need are to anything downstream or upstream that needs to be aware of your vlan tags. in your case, it looks like just downstream switches at both sites? 3. assuming your default route on the meraki switches all has a next hop of your router ip addresses? 10.22.22.2 and 10.22.220.2? from my point in number 1, this would make the route on those routers simpler as they could be summarized simply as route 10.x.0.0/16 to the next hop ip of your meraki switch. in your case, you cannot summarize on the routers and, if you add new networks, now need to get those additional network routes added to them for each site. a simple /16 summary covers you from that perspective. 4. with regards to number 3, i'm unclear as to how the backup link would be used? you'd need a routing protocol setup to have muliple paths. meraki only supports ospf on the MS switches.
... View more
sounds over engineered but i'd need to see your overall topology to confirm
... View more
Mar 16 2021
5:49 AM
shouldve updated this one. there's some bug in their code. the fix was to add another L3 vlan interface, confirm the switches said "up to date" in the dashboard, then i could remove the new interface. something to do with the route table on both switches in the stack weren't synced.
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 1287 | Dec 1 2021 8:35 AM | |
| 9052 | Dec 1 2021 8:28 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 4 | 11241 | |
| 4 | 11670 | |
| 4 | 11673 | |
| 3 | 1287 | |
| 2 | 8948 |
© 2024 Cisco Systems, Inc.
