Does your MX licensing level give you access to "Traffic Analytics" ?  If so, click on "Network-wide" -> "Monitor" -> Traffic Analytics and see what has been on your network for the past few hours.  You should be able to sort by the traffic type with most traffic since the network throughput seems to be pretty consistent and will be much higher volume than the normal background noise on the network. ... View more

For starters, get rid of the IPv6 rules.  You don't have IPv6 enabled on the LAN interfaces and unless your clients are actually using IPv6, these rules don't do anything.   Secondly, are you applying any group policies to your users that is not being shown in your screenshots?  It is possible for Group Policy-based firewall rules to overrule default firewall rules.   Lastly, when you say "communication" between the hosts.... are you talking about TCP and UDP, or just ping?  I ask because when you set "any" in MX firewall rules, you would assume that means "TCP, UDP and ICMP", but that is not the case.  "Any" only blocks TCP and UDP, but allows ICMP to pass through.  If you want to block ICMP, you need to create two more rules that specifically block ICMP. ... View more

Basically, yes, that is exactly what I am telling you.  it all depends on if you are trying to optimize for minimum downtime, admin easiness, or the ability to do this remotely.  A lot of my remote sites do not have remote IT staff, so I end up partnering with local office staff (non-IT) to move cables for me.  In my world, safety and minimum downtime is pretty much everything to me.  Building up the new MX in a new network affords you the option of bringing the new MX online and bootstrapping it before you try to throw it in production.  It also minimizes your downtime to the amount of time it takes someone on-site to move the LAN cable from the old MX to the new MX. ... View more

Oh yeah.... I guess I just assumed that nobody in their right mind would leave everything in one combined network.  Please hold while I edit my previous reply! ... View more

PhillipDAth is correct per the official documentation.  HOWEVER, if you are trying to do this with a minimum of downtime, the safest move would be to create a new Appliance network, add the MX105 to it, copy over all of your settings, then when you are ready, physically move the cables from the MX100 to the MX105.  The only setting you cannot replicate ahead of time is if your MX is part of a autoVPN SDWAN, then you will only be able to turn on autoVPN for the MX105 -after- you have replaced the MX100 and disjoined the MX100 network from your autoVPN SDWAN.   EDIT: PhilipDAth pointed out something obvious that I should have mentioned:  If you have your MXs, Switches and WAPs all combined in one Meraki network, the method I mentioned above is Not Ideal(tm).  If you are running separate networks for your appliances, switches and WAPs, my original comment stands as the best option to migrate a new MX with minimal downtime.   HOWEVER, if you are running a combined network, you'll be forced to remove the existing MX100 from the combined network and then add the MX105, which will cause downtime for the period of time where you are missing a configured MX. ... View more

We've run into this same problem with all of our MX100 deployments, as well...  I built a quick & dirty script to dig through event logs in the past 5 minutes looking for DHCP failures, then swap the active/standby units, then reboot the standby.  I have one pair of MX100s at a large-ish site that gets failed over & rebooted several times per day.  *sigh* ... View more

"Fixed an issue that resulted in​​ fragmented packets that were received by an MX appliance and transmitted across AutoVPN getting fragmented after encryption took place."   We are still seeing this issue with 17.10.4 on a MX67W.  Specifically, any SSID advertised on this unit with RADIUS authentication (or wired splash pages with RADIUS authentication) fail due to the MX dropping fragmented RADIUS response packets.  The last version of MX to handle this correctly was 16.16.8, which we had to rollback to when 17.10.4 broke RADIUS once again.   For anyone else with similar problems, our MX67W is advertising a 802.1x authenticated wireless SSID and wired VLAN using RADIUS and the RADIUS servers are across the autoVPN in remote datacenters.  We have had case 08991820 open since 12/3/2022 for this issue. ... View more

To be fair, power settings are not really a SSID-level setting, but rather something that is applied down at the physical WAP device.  You can't very well have a WAP advertising two different SSIDs, each at different power levels on the same WAP.  However, you are correct that TX power is one of several parameters not yet exposed via the API. ... View more

Yes, you can, just not within the Meraki Dashboard webpage.  You'll need to use the Meraki API with something like the Meraki Python library to write your own script to do this.  I'm finishing up my own Python script to do this right now.  Yes, it's annoying that this isn't currently exposed within the Meraki GUI, but it is totally doable.   Start here (https://developer.cisco.com/meraki/api/#/python/getting-started) to learn about accessing the API.  Specifically, follow this link to go through Meraki's API tutorial (https://learninglabs.cisco.com/modules/getting-started-with-meraki/meraki-02-dashboard-api/step/1).  There are other tools out there to access the Meraki API, but the Meraki python library is by FAR the most mature.   The relevant Meraki python module functions are:   getssidl3fwrules(apikey, networkid, ssidnum, suppressprint=False) updatessidl3fwrules(apikey, networkid, ssidnum, fwrules, suppressprint=False) getssids(apikey, networkid, suppressprint=False) getssiddetail(apikey, networkid, ssidnum, suppressprint=False) updatessid(apikey, networkid, ssidnum, name, enabled, authmode, encryptionmode, psk, suppressprint=False) updatessidobject(apikey, networkid, newssid, suppressprint=False)       ... View more