Meraki

Brash

Huge congratulations to the community as a whole! Over 2,400 posts and 100 solutions are excellent stats. And Congratulations @DanD - enjoy the AP!

Brash

As stated above, your best bet is to contact support as they can provide more information. A couple of additional things you can do are: - Check the event logs in the Meraki dashboard to see if there's any relevant events for the MX around that time - Download a log dump from the local device admin page of the MX. Support can parse it to get more detail as to the reason for the crash.

Brash

Nice tidy setup. I'm always a big fan of rack mounted MX's. That kit must be pretty secure to be comfortable holding the MX on its side 😄

Brash

Keep it up everyone! Seeing lots of good quality posts.

Brash

You beat me to it 😄 That's a really good amount of points and some decent looking training.

Brash

To add to @BlakeRichardson 's comment, if the old dashboard and the new dashboard are running different versions, you will need to factor in upgrade time which could be up to 30 mins.

Brash

Congratulations everyone! Some really great posts this month! Keep it up! 👍

Brash

Nice! I'm really interested to know where all of the MS130-8 switches went. Were they all to provide PoE and connectivity to the AP's or was there another specific use case for requiring so many 8 port switches? Also, big fan of C9500-24Y4C and C9500-48Y4C switches. They're both very capable core switches.

Brash

I'm not usually a fan of comms racks being mounted against the ceiling, but that one looks like a really clean install. Nice job 👍

Brash

As @rhbirkelund mentioned, check which failback behaviour is configured. As a side note, if your network is assigned to a template, you won't see the explicit and dropdown to change and it will be hard set to graceful.

Brash

The only potential issue is it presents a security risk. Any of the clients on that VLAN will be able to send RADIUS requests to the NPS server which can allow for malicious actions.

Brash

Due to issues under investigation, MX75 and MX85 appliances may encounter unexpected device reboots. Didn't this one get a fix in 19.x? I'm surprised it didn't get backported.

Brash · ‎Jun 1 2025

For actual functional issues (rather than subjective feedback), I suggest engaging support so it can be fed back to the product team.

Brash · ‎May 30 2025

(Thankfully) we're not doing any multicast routing, so no PIM and no RP.

Brash · ‎May 29 2025

I'm setting up a network with a bunch of AV equipment. Essentially, all of the AV equipment sits on a stack of MS225 switches which are connected via Port-Channel to a Meraki managed Catalyst 9300 core switch. To try to limit the amount of multicast in the network, I've configured L3 interfaces with IGMP querier on the stack of MS225 switches, with flood unknown multicast disabled. With this configuration, I would expect all multicast streams to be contained within the switch stack as all equipment sending and consuming streams are connected there. However, when I look at port utilisation, I can see that multicast streams are being forwarded upstream to the Catalyst 9300. It's totalling to around 1Gbps of traffic on the port. Looking at all of the other ports on the 9300, their bandwidth usage is minimal (<10Mbps) and from some intermittent captures, I don't see any multicast streams being forwarded out any other ports. Am I correct in expecting the multicast traffic to remain on the access layer switch stack (switched between switches in the stack via the stack ports) rather than all of the streams being sent upstream to the core?

Brash · ‎May 28 2025

I don't believe you can rename tags. You'll have to create and assign new tag(s) and then delete the old ones.

Brash · ‎May 22 2025

Thanks for the advice. I had a colleague go out to site today to patch across MX-2 and it came up good behind MX-1 with no site-to-site issues whatsoever. As it is only temporary, load shouldn't be an issue. Some customers connect their ISP device to a WAN switch, which then allows multiple MX devices to connect through that switch. This setup works especially well if the ISP provides IP addresses via DHCP, or if you have access to multiple public IPs. It’s a clean and efficient way to get multiple MXs online without much hassle. This is the ideal but unfortunately, it's not quite that simple with our ISP. We'll be able to get another service in, but it'll probably be a month or so from now.

Brash · ‎May 22 2025

Good point. No, thankfully it's a split tunnel so no AutoVPN within AutoVPN (a true nightmare indeed)

Brash · ‎May 22 2025

I have an existing MX (MX-1) which is a spoke in a Site-To-Site VPN. I need to bring up another MX (MX-2) in the same location. It is in a different organisation that will connect to a different Site-To-Site VPN. For reasons beyond me, we've had massive issues getting the ISP to run an additional service to the site. Therefore, I'm contemplating connecting MX-2 to the LAN side of MX-1 for them both to run off the single WAN link of MX-1. This will be temporary of course. Although from a networking point of view this should work, I'm wondering whether there will be issues having 2x MX's check in to the VPN registry (for different orgs) from the same public IP. Has anyone had any experience with this?

Brash · ‎May 21 2025

Probably not the issue but worth checking, have you cabled the stack ports correctly? Stack port 1 on switch 1 connecting to stack port 2 on switch 2 (and vice versa)

Brash · ‎May 20 2025

As @alemabrahao advised, staged upgrades is the way to go. This lets you split switches in a network to be upgraded in grouped stages. One thing to note is that switch stacks are treated as a single switch and therefore cannot be staged separately. All switches in the stack may/will reboot at the same time.

Brash · ‎May 19 2025

As stated above, if you're looking to run a reachability test from a device already connected to the Meraki Portal, you can use the Ping Live tool to test ping connectivity. If you're investigating why devices are not connecting to the Meraki dashboard, you would access the device locally via the local admin page to check the status.

Brash · ‎May 18 2025

Exactly as @Mloraditch said, you can't specify explicit sponsors per domain. As has been mentioned, 3rd party integrations can be used to manage this. I believe others have used subdomains with perhaps varying success.

Brash · ‎May 18 2025

A small addition to what has been said above, this is the same behaviour for all Meraki devices (MX, MS, MR, MV etc). As devices get older and go EOL, they will have a fixed final firmware version/train.

Brash · ‎May 15 2025

It's possible that if you apply a group policy to the VLAN with deny rules for RFC 1918 addresses, it may prevent clients from communicating with each-other as they all connect directly to the MX for L2 and L3 communication. You would need to test to validate as I personally don't manage any networks using the MX wireless.

About Brash

Brash

Community Record

Badges