Meraki

Brash · ‎May 3 2023

Adding to @alemabrahao's reply, it's specified in the switch stacking documentation https://documentation.meraki.com/MS/Stacking/Switch_Stacks

Brash · ‎May 2 2023

I believe the only safe way to do this is the unstack the switches, and rebuild the stack without switches 2 and 3. Best to confirm the exact steps with support though.

Brash · ‎May 2 2023

Was this a newly setup mx67? The only time I've hit an issue like this was when the device was rebooted less than 30 minutes after having configured it. Because the configuration wasn't 'safe', it reverted to the previous configuration which was factory default (as it was a brand new device)

Brash · ‎May 1 2023

You would need an internal DNS server that you can point your devices to. You can then have that DNS server resolve the URL to the local IP address.

Brash · ‎Apr 30 2023

I've always been of the opinion that HTTPS inspection sounds great in theory but is still too processor intensive to be truly effective on a security appliance, unless you hugely overspe the appliance.

Brash · ‎Apr 28 2023

If you do not keep firmware up to date, you will begin to see warnings in the dashboard under 'firmware upgrades'. Additionally, depending on how old the version is you're running, Meraki will sometimes auto-schedule an upgrade to force you to a higher version. Dashboard administrators will be notified in advance of this via email.

Brash · ‎Apr 27 2023

The integration piece that Cisco/Meraki offers here is Cisco Umbrella with SIG Essentials or SIG Advantage licensing. Otherwise you'd be looking at putting another vendor's security appliance inline.

Brash · ‎Apr 26 2023

I'm not sure whether this feature is still supported. Another option would be to use a Splash Page and select "Sign-on with" and choose Google Oauth. It would achieve the same end result, but rather than using google credentials as the username and password for association, the user would associate to the wifi first and then be redirected to a splash screen to enter their Google credentials.

Brash · ‎Apr 26 2023

While I share the frustration of some features lacking in the Meraki portfolio, you're far better off voicing these to your Cisco rep or account manager. They can directly share this feedback to the product managers who ultimately make these decisions.

Brash · ‎Apr 26 2023

Assuming you're talking about Meraki devices and their management network, much of it personal preference. I typically use DHCP as I'm not too concerned about the exact address they pick up and I can always check it's leased address on the dashboard. For DNS I typically use a public DNS (Google or CloudFlare). I don't use Meraki NAT for any WiFi offerings, but if I did, I'd consider changing the DNS to a service that offers some additional protections.

Brash · ‎Apr 26 2023

This question is ultimately dependant on your network design and risk tolerance. A few points of note. If your hosts have uplinks to to 2 separate switches, they will reboot alternately and therefore the hosts and VM's should see minimal impact. This assumes your hypervisor pathing is set up correctly. If you have the VM's storage traffic (iSCSI, NFS etc) going over the network. Most hypervisors can handle a small delay in connectivity to the VM storage, but won't handle a larger outage time. It's always a more enjoyable experience to shutdown critical VM's prior and bring them up again later than to have to recover corrupt VM's.

Brash · ‎Apr 25 2023

From my understanding, the MS390 is far more stable than previously but still has its issues. That said, I don't have any MS390's deployed so take that opinion with a grain of salt. As @cmr mentioned, there's been a mountain of MS390 fixes in the last few firmware drops. Given your previous issues, it might be worth engaging support early on to advise of any known issues (other than those documented in the release notes) on the version you're jumping to.

Brash · ‎Apr 25 2023

The dashboard event logs are typically pretty bare bones. You can get a bit more info by logging to a syslog server, but for something like this, you're best off logging a case with support who can usually pull up the details and logging of a crash from the backend.

Brash · ‎Apr 25 2023

Never had an issue raising cases. Assuming you're an administrator it shouldn't be a problem. Try calling support instead. https://documentation.meraki.com/General_Administration/Support/Contacting_Support#Phone

Brash · ‎Apr 25 2023

Prior to MX firmware version 17, Meraki used brightcloud for content filtering categorisation. Version 17 and above, Meraki now hses Cisco Talos Intelligence. You can find information about it here, including how to submit content category/match disputes https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Content_Filtering_Powered_By_Cisco_Talos

Brash · ‎Apr 23 2023

Licensing is DNA Advantage and is activated and we'll in date. I actually dug a bit further on this and it turns out that there's a few different issues occurring. On failover, the tunnel does actually establish within a minute or so, but it takes ~20 minutes for the status to true up in the dashboard. In the meantime, if another failover occurs, the tunnel then fails to come up and will sometimes crash the switch. I've got cases open with both Cisco TAC and Meraki so hoping we'll be able to get it sorted. Just interested to see if anyone else using the feature has seen similar.

Brash · ‎Apr 22 2023

The main reasons vlan 1 is considered a potential security risk is because it is the default vlan on switches. This means that if you have any enabled and unconfigured ports on a switch, someone can plug in with immediate access to vlan 1. Additionally vlan 1 is used to exchange control plane data for some protocols (especially legacy protocols) as it was guaranteed to exist on every switch. Placing user traffic on this vlan introduces additional variables that could impact the control plane traffic.

Brash · ‎Apr 20 2023

Seems odd on the face of it. Do you have anything upstream blocking DNS lookups to 1.1.1.3?

Brash · ‎Apr 20 2023

Assuming the windows and Linux servers are end hosts and not doing any sort of bridging or switching, you would want BPDU guard (to ensure we don't accept body's from the server). I would also set udld to alert only as it's less likely you'll see a loop on this interface from a unidirectional flow issue. If they're designed to act as software switches, you'd want to look at root guard and potentially udld enforcement.

Brash · ‎Apr 19 2023

Running the 'Cisco recommended' (starred release) 17.6.4. Tried an upgrade to 17.6.5 as well.

Brash · ‎Apr 18 2023

I'm setting up a Catalyst 9500 stack with Meraki monitoring and have noticed a strange issue: Whenever I perform a failover (power pull or CLI) to the second switch in the stack, it is never able to connect to the Meraki dashboard. The TLS Tunnel always shows down and the switch shows offline in the dashboard. As soon as I switch back to switch 1, the tunnel is re-established, the Meraki user logs in and the device comes back online in the Meraki dashboard. Has anyone else encountered this behaviour? I'm planning to raise it with support but am working through some other issues first related to unexpected crashes seemingly caused by the Meraki TLS Tunnel.

Brash · ‎Apr 18 2023

Its impossible to say exactly with the level of information provided. If your internal networking scheme and design is remaining unchanged, you can simply move the devices and connect them up as they were before. They should reach the cloud as normal via the internet exit at the new location. If your internal network/IP addressing is changing, you will need to do a lot more work to prepare the configuration changes for the Meraki dashboard and updating the management up of each device from the local status page. If you are completely unsure, it may be worth engaging a partner/consultant to assist.

Brash · ‎Apr 18 2023

Not sure whether creating a new org will be most advantageous or not. But assuming MR licensing works the same as MX licencing, once you add the advanced licensees to your org, it will uplift the org license level including existing licenses. This uplift does however calculate and take away some of your co-term time to take the uplift if existing licenses into account.

Brash · ‎Apr 18 2023

You're right sorry, I misread the image. So yes, they're dual band but can only transmit one at a time. "Meraki outdoor sector and patch antennas have two integrated cables and N connectors. Both of these connectors must be attached to the same radio. This is important for 2x2:2 APs such as MR74 and MR76. A single sector/patch antenna should not be attached to both the top and bottom of the access point, which would have that antenna connected to two different radios. When looking at these 2x2:2 access points, each radio has two ports next to each other on the same side of the AP. For example, if an MR76 has two ANT-25 patch antennas properly connected, even though they are dual band antennas, one ANT-25 will have both pigtail cables connected to the 2.4GHz radio and the other ANT-25 will be connected to the two 5GHz radio ports." https://documentation.meraki.com/MR/Other_Topics/Frequently_Asked_Questions_regarding_Cisco_Meraki_Antennas#What_are_the_Models_of_Indoor_External_Antennas.3F

Brash · ‎Apr 18 2023

Not sure regarding last updated time. Assumedly it's last config update as it's supposed to do a check on the vlan mismatch every 40 minutes. That said i do know that sometimes these alerts can take a number of hours to clear. If config is looking correct and the alert remains after a day or so, open a case with support to check it out.

About Brash

Brash

Community Record

Badges