Meraki

jdsilva

Congrats All Stars!

jdsilva · ‎Jun 1 2021

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

jdsilva · ‎May 27 2021

@PhilipDAth wrote: >*premises I always thought premises was the plural of premise. Thanks for updating me on that. I think that's what most people think, but yeh... Two totally different words. Sorry for being the grammar police in your thread. No one likes that guy.. 🙂 And sorry for you not being able to unsee it going forward. Welcome to my hell.

jdsilva · ‎May 27 2021

@cmr wrote: **site 😉 Oh do I wish people would just use that word instead of using that completely wrong word. I also wish I was less OCD on this because I'm basically triggered all day every day with the massive amount of people who don't know (or care) about the difference 😞

jdsilva · ‎May 27 2021

*premises

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 · ‎Feb 3 2021

You'll need to use the API to get this. It's not available via SNMP as far as I know. https://developer.cisco.com/meraki/api-v1/#!get-device

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 · ‎Dec 16 2020

This should be what you're looking for 🙂 https://documentation.meraki.com/MX/Site-to-site_VPN/Troubleshooting_Non-Meraki_Site-to-site_VPN_Peers#Event_Log:_.22failed_to_pre-process_ph2_packet.2Ffailed_to_get_sainfo.22

jdsilva · ‎Dec 14 2020

@IT_Magician wrote: Thanks for sharing, I didn't think there would be a work around. We replaced their Fortigate and the IT team is used to everything being blocked by default and you allow what you want. The concern they have is it opens up for human error to forget to block a new VLAN because everything is allow. As long as you have specific sources in your permit any rules this shouldn't be a concern.

jdsilva · ‎Dec 14 2020

Hey @IT_Magician , Not to be pedantic, but as soon as you manually specify a rule it's no longer implicit, that's an explicit rule. Implicit rules are those rules that you cannot change or modify, they are just there. Your rule 3 is an explicit rule. The "Default rule" on the end is an implicit rule. As for your problem, you are going to have to put deny rules before your permit any that deny intranet traffic accordingly. There isn't really a way around this. The point to take away here though is that your permit any statements have specific sources and don't "permit any any" thereby maintaining a higher level of security.

jdsilva · ‎Dec 14 2020

You can get custom timespans if you pull this data via the API instead of the Dashboard.

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

About jdsilva

jdsilva

Community Record

Badges