Meraki

jdsilva · ‎Jan 23 2025

Congrats All Stars!

jdsilva · ‎Jun 1 2021

https://developer.cisco.com/meraki/api-v1/#!get-network-appliance-warm-spare

jdsilva · ‎May 20 2021

Yeh that's a good point. https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Configuring_Spanning_Tree_on_Meraki_Switches_(MS) So right at the very top of that doc is says both STP and RSTP are supported. Further down in the explanations of the network-wide disable, and port level disable, it says it kills STP completely for the scope each setting is applicable too. I don't see in there any way to force a port into STP mode. I know in Cisco Catalyst RSTP implementations if an RSTP bridge detects an STP BPDU on a port is changes the mode of that port to STP for interoperability purposes (and thus slows down convergence of the entire RSTP domain), so perhaps it's the same with Meraki? Dunno, never had to connect an 802.1D bridge to an MS.

jdsilva · ‎May 20 2021

I was referring to disabling STP at the port level, yes. You can also disable STP on all switches in the network under Switch > Switch settings.

jdsilva · ‎May 6 2021

No, I'm pretty sure mine is correct.

jdsilva · ‎Apr 6 2021

Congrats to all the winners and well done to everyone who participated!

jdsilva · ‎Jan 28 2021

The API is your best bet here.

jdsilva · ‎Jan 27 2021

Two MX in HA need to be layer 2 adjacent, and with as low as latency between them as possible. If you can meet those two conditions then you can place them wherever you like. But honestly, you're better off to just use a dedicated VLAN on your switching infrastructure to bring one of the WAN circuits across the building to where the MX pair is.

jdsilva · ‎Jan 26 2021

I think I can help with that clarification too 🙂 The MX can only have NAT rules that are based on the destination IP address of a given flow. Note that I said 'flow' and not 'packet', because obviously the source IP address field in a _response_ packet is NAT'd, but you can never create a rule that intentionally modifies the source IP for a flow. If you're clever enough there are actually ways to write rules to make this happen for very specific use cases, but I would suggest these configs are bad practice as they are not intuitive and really just taking advantage of side effects of certain configurations. You would be running the risk of no one else understanding your config, and perhaps even Meraki breaking the functionality in future updates as it's not technically supported 🙂

jdsilva · ‎Jan 26 2021

Hey @Jeizzen , While I disagree with you on the definition of what a "real" hairpin NAT is, I can tell you with confidence that what you are asking does indeed work just fine with no special configuration. LAN hosts can reach another LAN host via it's public IP if at least one of a port forward, a 1:1 NAT or 1:Many NAT s configured correctly for the destination. Hope that helps! Jason

jdsilva · ‎Jan 15 2021

Congrats to the new All-Stars! You guys have been great members of the community and it's good to see you added to the list. And for those that are returning it's good to see you back!

jdsilva · ‎Nov 27 2020

1. Why Meraki is discouraging to have P2P for failover/heartbeat VRRP connection? What advantage do we have especially when it's working with passive connection? You cannot specify a dedicated heartbeat link. There is not way to configure this. Simply putting it there does not make it so. You want VRRP to use the links your clients are using. By trying to short cut that you create the scenario where VRRP is working fune, but your clients are isolated and have no connectivity. If both the clients and VRRP use similar paths VRRP more accurately reflects your client's experiences. As well, because the MX's don't handle STP a link between them can cause unexpected STP topologies from your switches' perspectives. 2. If switching infrastructure (as per Meraki) is not available, and passive P2P is not allowed what would be the next solution? As in you have clients directly connected to a pair of HA MX's? Personally, I wouldn't do this. I'd rather have a single cheap dumb switch in the mix than directly connect clients to a pair of HA MX's. 3. How to convince Meraki support personnel to think out the guide book and troubleshoot the issue? In this case you should change your topology. That's ultimately the right answer. Sorry to be the bearer of bad news.

jdsilva · ‎Oct 6 2020

MX65 is not midrange. It's the smallest MX Meraki makes.

jdsilva · ‎Oct 6 2020

@Pipeline You need to adjust your expectations. No where ever has Meraki claimed its lower end MX models can handle 1Gbps, this was your own unreasonable expectation. Further, proper sizing would show that the MX65 is spec'd for 50 clients, and 1Gbps is utter overkill for 50 clients in all but the most exceptional corner cases. What you should be doing is sizing your internet throughput to the actual needs of your users, and then looking to the correct size MX. Your approach of sizing the MX to the throughput you just happen to have is wasteful financially to your organization both in your costs to your ISP and in the costs you pay for hardware.

jdsilva · ‎Oct 5 2020

Because the next smallest Ethernet port is 100Mb, and that's too small.

jdsilva · ‎Oct 5 2020

@Pipeline wrote: It that the highest thought put possible for the MX65W? Yes.

jdsilva · ‎Oct 5 2020

MX65 topped out at 250Mbps, so you're right where you're supposed to be. https://documentation.meraki.com/MX/MX_Overviews_and_Specifications/MX64_and_MX65_Overview_and_Specifications#Context_and_Comparisons

jdsilva · ‎Sep 24 2020

You should be able to retain your CCO account. I've had the same one for almost 20 years now, I just change what company I'm associated to. Also, I hope a CONGRATS! is in order for the new job 🙂

jdsilva · ‎Sep 2 2020

Well done everyone! Great work.

jdsilva · ‎Sep 1 2020

This was a fantastic podcast. @BrechtSchamp and @PhilipDAth are simply the bee's knees!

jdsilva · ‎Sep 1 2020

Episode 16 is clearly the best episode. I know that will be the only one that gets comments on it for this contest 🙂

jdsilva · ‎Aug 31 2020

I'd suggest actually doing the opposite. Set the HQ as the primary DNS server, and the OpenDNS as the secondary. I assume the HQ DNS is configured to use OpenDNS itself for zones it's not authoritative on?

jdsilva · ‎Aug 28 2020

If you get a list of the group policies through the API they will be returned with their ID. I'm not aware of any thing in the web UI that shows these... But if click into the GP I believe it's in the URL as what I label the <GPID> in this exaple: https://<SHARD>.meraki.com/<NET_NAME>/n/<NET_ID>/manage/configure/group_policies#/groups/<GPID>/edit

jdsilva · ‎Aug 28 2020

Good stuff! Just remember that when you start dealing with networks over 1000 clients you're going to have to revisit this and figure out how to fetch the 'next' page to get the remaining clients. The next URL is returned in the headers of your first request, so you have to get that URL, and then make a GET to it. The next URL will be populated as long as there are more clients to be returned. When you've got them all the next URL value will be NULL.

jdsilva · ‎Aug 28 2020

I'm not familiar enough with Postman to really help you with that specifically, but if you only have 150 clients in your network then it's probably easier for you to set the 'perPage' value in your request to the max (1000) and not worry about dealing with multiple pages of clients. Check the documentation for this API call as it defines the requests parameters (including perPage). Set that parameter in your Postman request and you should be good to go. https://developer.cisco.com/meraki/api-v1/#!get-network-clients

About jdsilva

jdsilva

Community Record

Badges