Meraki

cmr · ‎Aug 5 2020

@GFrazier from a data plane point of view think of stacking being like having three line cards in one chassis. There is absolutely no issue with VLANs between stacks and it works very well. The only areas where a Meraki (non MS390) stack separates out is for management where each switch (stack member) has it's own management interface and IP address and secondly for the power where each stack member is separately powered. In the MS390 these are all common so it really is like a chassis switch with line cards.

cmr · ‎Aug 5 2020

26.8.1 is now stable release and as there is now no release candidate does this mean that 27.x (3?) is about to become a release candidate, the MS12.x software migrated in this way...

cmr · ‎Jul 31 2020

🤣@AnythingHosted You made my Friday with that, I might work for a gambling company but I dont think that we'd give odds on there not being a charge. I could be pleasantly surprised though 🤞

cmr · ‎Jul 31 2020

@Shadius As long as the app can talk to the units via IP on a different subnet then there is no need for the controller to be on the same SSID as the AC units. Obviously when you later create firewall rules between the subnets then you must allow the controller traffic through.

cmr · ‎Jul 30 2020

@ShadiusFirst create the new VLAN interface on the MX and make sure it has a DHCP server assigned to it. To do this go to Security & SD-WAN and pick the Addressing and VLANs menu, then click on the button to change from single VLAN to VLANs, next click on add VLAN and create a second VLAN, give it a name (AC) a subnet and interface IP similar to what is shown below: Next go to the DHCP config menu and make sure both VLANs are set to Run a DHCP server like the second one shown below: On the Wireless / SSIDs configuration page, create a second SSID and set the security (probably WPA2-PSK for an AC unit) and in the Addressing and traffic section make sure you change it to Use VLAN tagging as below It is a good idea to change the existing SSID to also use VLAN tagging but just pick the original VLAN (usually 1 unless you have changed this. SSIDs must be in bridge mode or layer 3 roaming mode (you don't want that) to use VLAN tagging. If you connect the AC units to the new SSID they will now be in a separate VLAN and separate associated subnet and you can create access rules to only allow certain traffic between the VLANs (subnets).

cmr · ‎Jul 30 2020

@eyethis is a good time to log a ticket as support can see the uptime stats and plenty of other low level detail, they can share this with you to try and work out why these 120s are rebooting. There is now 12.22 as a release candidate and 12.24 as a beta though most of the recent fixes look to be MS390 related. I would upgrade at least to the release candidate and if the issue persists log a ticket. One point to check is that I'm guessing you are using a lot of PoE as you have the FPs and this does generate heat, are they in a properly cooled environment?

cmr · ‎Jul 29 2020

The wireless latency still appears on the client page for me, or are you referring to the overall network page as I indeed do not see it there. I haven't looked at that page for a while as it seems incorrect to me. On my home network it shows the below: Clearly 1/7 devices had an issue (the client page correctly reports this) and I have no idea where the 9 devices comes from as there are only 7 in the list...

cmr · ‎Jul 29 2020

@DarrenOC I just made the 26.8.1 (upgrades) happen now and cancelled the upgrade to 27.3 then moved that site to 26.8.1 as well. None of it actually changes any firmware as there are no WiFi6 APs in Amy of those 4 networks so 26.8.1 is actually remaining at 26.8.... 🤔

cmr · ‎Jul 29 2020

Today I received another upgrade notice for three other networks running 26.8, these ones are going to be upgraded to 26.8.1 which makes more sense as they have a mix of pre and post 802.11ac wave 2 devices. Anyone else receiving these upgrade schedules and having the same odd experience as we are?

cmr · ‎Jul 28 2020

Not sure if anyone else has had this happen, but we've just received a notice that one of our networks currently running 26.8 that consists of MR32s and MR42s, is going to be upgraded to 27.3 This seems rather odd as MR32s don't support 27.x and Meraki have been recommending not to have mixed versions within a network. Have I missed an announcement or something?

cmr · ‎Jul 27 2020

@ctscalbers with Python you don't need to know any programming, you simply download and install python (3.8.4 is the current version) and then type commands such as python script.py and this will download the data. I think Meraki have the scripts so you are kind of just running a batch file.

cmr · ‎Jul 20 2020

@CptnCrnch my assumption is that @Prithiviraj is loadbalancing the ISPs on the Active/Passive MX pair. Though I may have got that wrong... Edited to remove incorrect query about dual links which are correct!

cmr · ‎Jul 19 2020

@Prithiviraj we use almost the setup you have and it works well. The differences we have are that the WAN transit switches are dumb layer 2 unmanaged switches and not stacked. Sometimes we have each MX connected like you have to two different stacked L3 core switches and sometimes we have them only singly connected. I have come to the conclusion that dual connections are better only when the MX to L3 core link is a single VLAN. This way the possible STP issues don't seem to cause a problem. However this is open to discussion!

cmr · ‎Jul 19 2020

@PhilipDAth the MS120-8 and 8LP use the 1U RM-CI-T3 as below: The manufacturer website page is at https://www.rackmount.it/products/regulars/cisrack/rm-ci-t3.html The MS120-8FP has 1.3/2U kit, part number RM-CI-T7 and is as below: All of the small MSs and MXs have rackmount kits and they are good, we have used them for a few years now.

cmr · ‎Jul 15 2020

@GijsJ welcome here, you should find all you need here, friendly people who usually know what they are talking about. When I took over our Meraki installs properly I found a great deal of help here, so now try to help others whilst still learning!

cmr · ‎Jul 14 2020

Well 12.22 is out now (obviously 12.20 and 12.21 didn't make the cut) but the bugs remain unless you have a 390 where some more are fixed: Bug fixes Traffic handled by a static route can fail to be routed properly on non-MS390 switch stacks MS390 firmware upgrade progress can reflect as 0% on local status page despite progressing normally Also added is that the MS390 upgrade process will now take a more Meraki time as opposed to an IOS-XE time, although this is from 12.10 onwards... 😎

cmr · ‎Jul 11 2020

If you have two WANs then it is a little more tricky as the main graph only shows overall for both...

cmr · ‎Jul 9 2020

I've long given up with the topology diagram, it always has ghost devices and at one of our sites three separate red diamonds that are all the same Cisco switch stack. We even get it at pure Meraki sites, as you have 🤔

cmr · ‎Jul 9 2020

@MarcAEC I think that is just confirming the unfixed bugs and quite normal. However I agree that some to seem to stay around for an awfully long time!

cmr · ‎Jul 8 2020

Option 1 every time 😎

cmr · ‎Jul 8 2020

@Jwiley78 yes, perfect, and the great thing is that is all there really is to do, it just gets on with it after that 😀

cmr · ‎Jul 8 2020

I believe it is down to power saving. It appears that the current 26.x and 27.x firmwares don't like Intel 802.11ac chipset power saving at all and you get high latency, disconnects, bad password etc. It does seem to affect some other devices but I have personally only seen it on all 802.11ac Intel chipsets. 802.11ax is okay and I don't have anything older.

cmr · ‎Jul 8 2020

@Jwiley78 the virtual !P is the one you will appear to be coming from to the rest of the world. The other two required IPs are one for each box and are used for failover management

cmr · ‎Jul 4 2020

If you want to use in routing mode then MXs cannot be active/active. Why would they want active/active, is the combined internet throughput over 6Gb/s?

cmr · ‎Jul 4 2020

@HarmeshYadav glad to be of help, answers below to your further questions: 1) You are correct, one for primary MX, one for vIP and you do need a third for the second MX. The ISP also needs to use one on the equipment that the line terminates in so effectively the minimum subnet you need is a /29. 2) MX can only be active/active in when deployed purely as a VPN concentrator. Why do you need active/active, with the virtual IP it appears to one firewall to the outside and it always appears as one to the inside. Cheers, Charles

About cmr

cmr

Community Record

Badges