Meraki

cmr · ‎Dec 17 2019

When using the MS, you do have it in a separate network to the MXs don't you? If in the same it can cause issues.

cmr · ‎Dec 17 2019

@sebastianfrancowe also tried Purple and while the technology does work, it stopped 90% (yes ninety percent) of our customers using the WiFi so we canned it.

cmr · ‎Dec 17 2019

For about 1 day there was an additional tab called Ports for each MX and it did contain this information (and more), unfortunately it had numerous errors for some MX models so the page was pulled, never to be seen again... 😢

cmr · ‎Dec 13 2019

You can use any LAN port on most devices, out of interest why do you need a local connection, we have never used the local connection on our MSs?

cmr · ‎Dec 11 2019

You also have different spanning-tree bpdu-filtering settings, you have 1/23 and 5/23 the same, not 5/24

cmr · ‎Nov 29 2019

Yes, use the mx64s at remote sites to tunnel and either send over multiple VLANs (enable VLANs on the MXs), or once the tunnel, which if the MXs are in single LAN mode will now be for corporate, is up, change the public SSID to use the mx84 as a concentrator

cmr · ‎Nov 29 2019

@AshMead if you want two separate tunnels from each remote site to the concentrator in the DC then you will need two MXs in each site and have them in two separate networks. The alternatives to this, so that you only need one MX per remote site, are sending multiple VLANs over one tunnel or setting the public SSID at each site to use the central concentrator as the termination point.

cmr · ‎Nov 28 2019

It is a big dumb box once there are no 3000 series Cisco switches connected... The MS doesn't even tell you it is connected in the GUI!

cmr · ‎Nov 28 2019

LOL, you have them pretty much bang on! We had them left over from the old 3560s that the MSs replaced. We do only use them to protect stacks of 2 switches and I've yet to test the PoE when on RPS. With the 3560s they previously powered, the PoE did work (we have 750W/1100W PSUs in them) and did switch back okay, but with older (2960) switches that used the smaller connector, they were all but useless...

cmr · ‎Nov 28 2019

@PhilipDAthI'm pretty sure we are using Cisco RPS2300 redundant power systems on our MS225s and MS210s though it's been a busy week so I might be mistaken!

cmr · ‎Nov 26 2019

Just for peace of mind, we have all the models you have (with the exception of the MR42E) on our networks that are happily running 26.6.

cmr · ‎Nov 20 2019

No, as @General-Zod and @BrechtSchamp said an MX pair is active-passive with up to two wired and one cell uplinks (depending on model).

cmr · ‎Nov 13 2019

Did it come out before Meraki PoE switches existed? The current install guide just mentions an af switch, not particularly a 3rd party one. MR66 (EOS) Installation Guide

cmr · ‎Nov 6 2019

@tomas209cawe had the same with our MX15.17/18 images when 15.20 came out, I believe as it fixes a significant performance bug. Interestingly it didn't propose to upgrade 15.14 devices. We also had similar with switches on MS11.25 as again there was what appears to be a significant bug fix. As @PhilipDAth said the auto beta off feature is just so that a stable image is not suggested to go to beta, or automatically upgraded by Meraki. We are using MX15.14 on the MX250 HA concentrators at our SD-WAN core, MX15.20 at most other sites that have HA pairs of MX100 or MX84, with a couple of the MX84 pairs on MX15.21. Our single internet access only MXs are all on MX15.21 and were on MX15.20 when it came out. We haven't, touch wood, had any issues...

cmr · ‎Nov 4 2019

We get the same on one (busy) site, so much that I made the other ISP the primary. The issue still persists, though perhaps a little less frequently. Having seen this I'll log it with support as both ISPs cannot see an issue and the users don't either. Funniest thing is that they are both MPLS links and the default routes are on the same stack at our main DC and from there they both go through the same internet firewall, even on the same rule, so not sure how one is down when the other is up...!

cmr · ‎Oct 31 2019

@redsectorAll of those APs should be able to run 25.x or 26.x, I'd upgrade as there are a lot of improvements!

cmr · ‎Oct 30 2019

@DarrenOC you have done multiple full stack Meraki installs, you must have come up against this?

cmr · ‎Oct 30 2019

@JoshRans didn't you say you stacked them? You will then just have one IP on the VLAN on the core switch stack and the other on the ASA LAN port. We do this as @Nash described with a 'firewall' VLAN that only exists between the core and the edge.

cmr · ‎Oct 30 2019

@Denathis works fine, I used to have this setup at my home with an MX64 for 3 years and it never went wrong.

cmr · ‎Oct 25 2019

For SD-WAN you can create traffic steering rules to prefer routes that don't have, for example, packet loss over 1%. We created a rule that has excatly that setting and make our VDI traffic obey it as that really doesn't like packet loss. When we have had tail circuit or provider core issues you can see the traffic all being steered to the other loss free link.

cmr · ‎Oct 25 2019

If you have Meraki suggest an upgrade at a certain time and you choose to reschedule it to an earlier time, then the upgrade happens at the new time but the dashboard warning stays there until the upgrade has completed, in your case where I'm guessing you have rescheduled to later I'm not sure what will happen, I'd have thought it will be at the new time but I'd raise a support case just to be sure...

cmr · ‎Oct 22 2019

Love the community, best resource out there. Thank you everyone 😎

cmr · ‎Oct 20 2019

For the MX series in routed mode, you can enable VLANs in the Addressing and VLANs tab. Once you have done this you can assign an access VLAN, or a trunk of multiple VLANs to each LAN port. If you also set up IP addresses for the VLANs then you can route between them. So although you cannot create a router port (in the traditional Cisco sense), you effectively can as you can have 24 VLANs with 24 IP addresses/subnets and apply one to each LAN port of the MX250.

cmr · ‎Oct 10 2019

@AndyM did you have any luck with the process we followed?

cmr · ‎Oct 8 2019

We have done several physical stacks and as @PhilipDAth said, as long as you power them up first on their own before physically stacking them, you will be okay. We have followed the following process: Create the stack in the dashboard by adding the serial numbers Plug in switches on their own with internet access and leave for a few hours Power off switches Install one of the switches in destination and power up, connect devices if needed, to free up space in panel if replacing other switches etc. Install second switch in destination and connect stacking cable(s), then power up Add third etc. if required. As long as you aren't using layer 3 features (we aren't), then it all works fine and there are no connectivity issues for clients, switch reboots etc. We did this with 10.x firmware but haven't added any more yet since moving to 11.x

About cmr

cmr

Community Record

Badges