Meraki

Brash

For specific requirements in a specific format like this, I would look into using custom scripts to poll the API to get the data. It can then be correlated and formatted as required.

Brash

The above comments are spot on. A Meraki SE is a must have for something this large. There are probably professional services offerings available too if you need a more detailed design or design, test and implementation assistance.

Brash

As @Mloraditch said, it's likely a GUI bug. Configuration or policies applied in the switch settings won't be pushed to the Z4

Brash

Assumedly it's related to the processing engine of the device. MX's are great for SMB and do a very good job at being simple to setup and run. When you get into use-cases that are more typical of a medium to large enterprise, you may find that the simplicity can sometimes be a hindrance.

Brash

That's correct, Layer 7 Geo blocking rules do not apply to inbound sourced traffic flows. There is no way to achieve this. Re: MX67W - does 1:1 NAT forwarding superceed layer 7 country blocking? - The Meraki Community

Brash

New switch day! Hope the install goes smoothly!

Brash

Congratulations @Mloraditch!

Brash

Congratulations! Thanks for your contributions to the community.

Brash

I'll first state that I don't manage 40+ organizations so my experience may vary. I've personally never found the automatic updates to be all that helpful. I've seen firmware pushed immediately to some orgs while others haven't had it pushed for ages. My preference is to manually manage upgrades. That way I can pilot new versions before pushing it to all organizations.

Brash

Looking around the 3CX forum, it seems that the SBC only requires outbound access to the 3CX server on those ports. Depending on your existing layer 3 firewall files in Meraki, it may simply work (as per the default) or you may need to create a specific rule with the source IP of your SBC, destination to the 3CX servers and allowing ports 5090 TCP & UDP.

Brash

Try a different patch lead, patch port, switch port etc. You could also try manually setting the speed at 100Mbps and see if it stays stable on that speed.

Brash

It's highly likely they would be 802.11 association status codes which are part of the IEEE standard. if you needed to absolutely confirm, you could correlate the reason code from API to what is logged in the AP's connection logs. An excerpt of some of the reason codes can be found here: 802.11 Association Status, 802.11 Deauth Reason codes - Cisco Community A full listing can be found in the IEEE doc here: 802.11-2020 - IEEE Standard for Information Technology--Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks--Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications | IEEE Standard | IEEE Xplore

Brash

@DarrenOC beat me to it. As per the data sheet it's not a supported platform for that license model. But also, the MX80 has been EOL since 2023.

Brash

One thing to be aware of is that Group Policy firewall rules apply in a single direction from the client going into the network. This is typically fine for most use cases (such as a guest network) but something to be aware of nonetheless.

Brash

A great idea!

Brash

That's true, forgot about those.

Brash

Yes, all Meraki MS switches that support L3 interfaces also support running as a DHCP server https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Configuring_DHCP_Services_on_the_MX_and_MS#.22Run_a_DHCP_Server.22_Options

Brash

Are you sure the IP addresses are correct? It sounds like your config is reverting due to invalid DNS servers. Looking up the two IP's you mentioned, they don't have DNS ports open (at least to the internet). They also don't have DNS server looking domain names: 89.20.160.228 · cns1.ef-service.nl 89.20.160.229 · cns2.ef-service.nl On the other hand, this one looks to be a DNS server. Does it work if you try this IP address instead? 89.20.160.230 · dns1.ef-service.nl

Brash

I've found the monitored 9500's can be a little flakey connecting back to the dashboard after upgrade/reboots. You can do some small amounts of troubleshooting yourself: Basic telnet tests documented under "ensure reachability" Cloud Monitoring for Catalyst Onboarding - Cisco Meraki Documentation Check if the tunnel is up show crypto tls-tunnel sessions I've also found sometimes that just 'time' allows it to eventually connect.

Brash

As stated by @Mloraditch , 30 days is the max from the dashboard. I recommend deploying some monitoring software that can record and hold that data for larger amounts of time.

Brash

As said above, there's currently no way to monitor the temperature of the MS210 and MS225 switches from the dashboard. There may be a way that Meraki support can see it from the backend but I'm not entirely sure on that.

Brash

You may not necessarily see problems from the misconfiguration. Based on what you've described and the fact that VLAN 1 isn't trunked, it sounds like your network is essentially split into two separate STP domains, with the border between the Nexus and the Meraki (due to BPDU's not going across the link). A packet capture would definitely confirm this behaviour. Similarly, you could look at STP counters on the nexus. Something along the lines of the below will show sent and received BPDU counters on the interface: show spanning-tree interface <interface number> detail Note: The above command is an IOS-XE command and thus might differ slightly on NXOS

Brash

These are all incredibly creative and very impressive.

Brash

Congratulation @RWelch!! Huge achievement

Brash

Looks great. Nice job @Green_Networker

About Brash

Brash

Community Record

Badges