Meraki

Aaron_Wilson · ‎Sep 1 2021

What Blake said. For wireless you really want to avoid any MAC based filtering/access. You can see the MAC for any wireless device, as because of this anyone could spoof and gain immediate access to the network.

Aaron_Wilson · ‎Sep 1 2021

Yea, I'm not digging it. There seems to be to rhyme or reason for the warning. Fox example, if 15.44.3 is stable, and 15.45.0 is RC, there is zero reason for 15.44.3 to be showing a warning.

Aaron_Wilson · ‎Aug 23 2021

That's what I would try first, booting it isolated to see if it's handing out IPs with no up/downlonks.

Aaron_Wilson · ‎Aug 14 2021

Ah, I see now. I guess the confusing part was I updated from an older former stable version which was displaying the warning to the current stable release. After the update it still showed a warning. I would have expected the system to not let me update to a version which too also had the warning.

Aaron_Wilson · ‎Aug 14 2021

This is interesting. I am receiving a warning about some devices which are running the current stable code. Anyone know if there was a recent change in the logic when prompting about this? I would not have expected a RC or beta release to give me a warning.

Aaron_Wilson · ‎Aug 12 2021

I know Meraki is fairly tight lipped on roadmap items. I'm curious if anyone has seen any discussions about nested templates. What I mean by that is a network which is not bound by a template, instead a sub section is. For example, I have the need to have the MX and MS be non-template based, but would desire the wireless to be template drive. I want all of the devices (MX/MS/MR) to be part of a single network. The advantage to this is I can make wireless changes across the board in one fell swoop, while at the same time the wireless is part of the network and status screens. An alternative idea is bulk changes which can be applied across multiple networks for a given value. For example, if I want to update the radius servers for all (or some) networks do this via a few GUI clicks. Anyone who uses Cisco's Control Hub for their collaboration devices knows what I mean. I love templates for the home user setups, but they are not great for the corporate setup. They make total sense for retail, hospitality, etc.

Aaron_Wilson · ‎Aug 11 2021

NHRT would only help solve Windows DNS stuff. I agree, it would be great for Meraki to add DNS intercept/redirect.

Aaron_Wilson · ‎Aug 5 2021

That is how I do it

Aaron_Wilson · ‎Aug 5 2021

Thanks both. It's all making sense now. The mental block I was having was in the Meraki examples of a switch stack, but that was a layer 2 stack, not a layer 3 stack. Ok, so if I run MX 1 to swx1 and swx2, spanning tree on the Cisco switch will shut the swx2 port. And if swx1 fails swx2 will go to forwarding?

Aaron_Wilson · ‎Aug 4 2021

Ok, having a mental block for correct wiring. Here is the lay of the land: -Dual MX67 for VPN back to mothership -Cisco 9300 switch stack running layer 3 for the branch location (/24) -Primary MX connects to SWX 1 -Warm spare MX connects to SWX 2 Over the years I know the Meraki design preference has shifted away from direct link between each Meraki for VRRP, but I'm seeing issues since the MX's do not participate in spanning tree. Here is the diagram I modified from Willette's picture for what I believe to be correct. If I have layer 3 hand-off from MX to switch stack, and the switch stack is running layer 3 for local LANs, is it OK to do direct MX to MX VRRP connection? If so, uplinks between MX and switch stack is ok to be access? One MX going to SWX 1, while warm spare goes to SWX 2? If SWX 1 fails will warm spare MX pass the traffic? Or do I need to trunk VLAN 100 between the two MXs with VLAN 1111 being default?

Aaron_Wilson · ‎Aug 2 2021

Then throw the new alt mgmt interface option to cause even more confusion....but I'm loving the alt mgmt IP option!

Aaron_Wilson · ‎Aug 2 2021

I have seen the mismatch error stick around for a bit even when things are correct. Make sure it's just not a lag in updating the dashboard. Are you doing DHCP or static on the switch for the mgmt vlan IP?

Aaron_Wilson · ‎Apr 13 2021

I echo pretty much what everyone has said. And like recently said, make sure you have the right VLAN set on the Meraki switch config even if DHCP. And welcome to the Meraki world. Just wait until you plug in an AP with no network access, it discovers a near by open SSID, joins it, and access the internet this way! It's pretty freaky.....

Aaron_Wilson · ‎Apr 12 2021

In your example, failover of traffic going via device/path A which then needs to take the other device/path B. It looks like you run active/active so some traffic is not impacted, but there is always something traversing the path/device which goes down. I will say, when we have done forced fail overs it's pretty uneventful. I have seen it where a continuous ping only has one drop. Mileage does vary depending on if its the WAN link, device, LAN link, etc, which is failing. I think the 30 second disclaimer is worst case scenario.

Aaron_Wilson · ‎Apr 12 2021

Just for the sake of discussion, what is your current fail over time with the current hardware and design? Based on experience and non-Meraki systems, I have seen OSPF/BGP re-convergence take 20-30 seconds. Certain devices and deployment methods can certainly be much quicker, I'm just curious what your current setup is.

Aaron_Wilson · ‎Apr 12 2021

The other thing to not forget about is a Meraki is really not a lot different than any other enterprise network equipment. Let's say you have a Cisco 9k or some other large switch, is moving to a Meraki unit changing something which means it's more likely to cause an outage? Unless you are making a fundamental change to the topology or traffic flow, which would likely not even be Meraki specific, you are probably at the same level of risk. Any system can have a failure. We had a fiber cut and a hardware failure occur at the same time taking a site down. The fiber cut would have impacted us regardless of mpls or internet. And a fiber cut occuring at the same time a device failed is VERY unlikely for any brand device, but it happened. Even look at Microsoft or Amazon, they even have challenges at times with their platforms. 🙂

Aaron_Wilson · ‎Apr 7 2021

Also, don't forget about the rule (drop down option) to which blocks wifi traffic from the wired network. This is on the AP config and always gets me when it randomly turns on.

Aaron_Wilson · ‎Mar 25 2021

What Bruce said is true, you have 4 WAN links in a HA pair (only access to 2 at any given time). There is no reason this shouldn't work.

Aaron_Wilson · ‎Mar 22 2021

You need to define "Meraki SD-WAN". If you are asking if a Cisco router can connect to a Meraki MX as a downstream layer 3 device, sure thing. If you are asking if a Cisco router can participate in the Meraki AutoVPN mesh as an active hub, then no. You can use various layer 2/3 switches and routers with Meraki equipment, but the AutoVPN feature is a "Meraki only" thing.

Aaron_Wilson · ‎Mar 6 2021

This has been in the known bugs for a while. Maybe it's this? Known issues After making some configuration changes on MX84 appliances, a brief period of packet loss may occur. This will affect all MX84 appliances on all MX firmware versions.

Aaron_Wilson · ‎Mar 6 2021

2 default routes where? Advertised from hubs over AutoVPN?

Aaron_Wilson · ‎Mar 6 2021

It has its pros and cons. But yea, if cloud is out of the question then you can't use Meraki. On the flip side, if a customer wanted no possible way for locally managed device even if factory reset, Meraki perfectly fits that need.

Aaron_Wilson · ‎Mar 6 2021

You can't. Meraki is a cloud managed solution, period.

Aaron_Wilson · ‎Jan 27 2021

Seems odd to have the two MXs at each ingress point, and not where things converge in an MDF, etc, where all the other distribution/switching gear is.

Aaron_Wilson · ‎Jan 19 2021

A little confused. They already bought a 3 year renewal? Or you meant they were buying 3 year licenses from the start?

About Aaron_Wilson

Aaron_Wilson

Community Record

Badges