About cmr

cmr

And there are differences, the ms120-8p models we got a couple of months ago differ from the ones we received a year or so ago as the new ones experienced the PoE mis-location issue, but the old did not...

cmr

@dloeliger are the old and new access switches all the same MS125 models?

cmr

@latintrpt if you mount the MR46E flat to the wall you'd use the B antennas, not the A ones. If you mount the AP on the ceiling or use a bracket so that it sits horizontally, then your use the A ones.

cmr

@u4iia you can break a network switch upgrade into stages now. Once you schedule the upgrade there is an option under Switch / Staged Upgrades where you can edit the schedule and add additional upgrade windows: I have successfully used this on a stack of three MS355X switches to upgrade the master first and then the other two switches 5 minutes later. I was onsite and it did follow the plan with no obvious negative issues. I have also used it on non-stacked switches many times without a problem.

cmr

@latintrpt the MR44 coverage is pretty much a sphere and the omni-directional antenna for the MR46E isn't far off. With the dipole antennas you can have them pointing vertically for wall mounted APs. Just fix them to the wall above head height and you'll be fine.

cmr

@JamesMutie yes, if you have two sites that both use, for example, 192.168.0.0/24, then change one to use a different range like 10.12.3.0/24. If you move to the 10. range you can create almost as many sites as you like as there are 255 /16 networks with easy subdivisions to /24 (where you have large sites) or over 65,000 /24 networks. You don't need to move all, just the ones that overlap.

cmr

As far as I'm aware it applies to upgrades as well, outside of RMA so I'd definitely give it a go and please report back here 👍

cmr

@jko6 if you inject a route to the internet to the MPLS (by using another device) then you can use the WAN port of the MX.

cmr

There is an option to translate remote subnets to different ones in this case, but I'd always go for renumbering despite the initial pain.

cmr

If you go here you can see the supported options: https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview#License_Conversion You are in luck

cmr

There is a standard MX84-85 upgrade, don't worry. Contact support and they will fix it for you.

cmr

@Mloraditch I think it will simply be an additional label you can add for ease of reading. So far I have only applied this firmware to my home switch and as that is an MS220, this feature isn't supported by the release...

cmr

The nearest MS devices to the 9500 are the MS4xx switches but they do not support SFP28

cmr

@Dolik there aren't model for model equivalents, what features of the devices are you looking to use? The nearest Meraki model to the 9130 is the MR56 as it has 8 spatial streams and is Wi-Fi6 enabled, but it doesn't support external antennas, 160MHz channels or splitting the radios.

cmr

Please note that if you are in the closed MX IPv6 beta program, you should not upgrade to this public beta version.

cmr

@Porcap what firmware are you running, what is the power source and has it always been this way?

cmr

@Fabian1 in general the * should mean anything inlcluding . so *.google.com should match it (and a lot more).

cmr

Indeed, but beware of this one: MS210/225/250 series switches cannot initialize SFP modules less than 10Gbps

cmr

Thank you for the explanation @GiacomoS I'm guessing that Cisco hasn't realised that the UK left the EU almost two years ago, but I'll let them know via the feedback button 😉

cmr

@henleyjj Only 1 uplink from each switch in the stack will be active at one time, but you can link both to both as you have suggested. We originally set up all of our sites with only one link to each MX and then started adding a second, but stopped as it did create some spanning-tree issues where we had MS and MX. Therefore on the dual linked sites we commonly left the second link port disabled, so it could be activated in an emergency, but wouldn't stop the switches coming back up after a reboot. This has since been resolved but we have left it as it is with some single linked and some dual linked...! The sites that had Cisco IOS switch stacks with MX were fine. The only issue that you might experience with the single linked option is that if one switch went down, you could end up with the MXs operating in dual master mode and you don't want that.

cmr

Switch firmware versions MS 15.2 changelog Alerts HTTP proxy is no longer supported on MS 15+. Nodes that use HTTP proxy without any other means to connect to dashboard may fail to connect. MS210/225/250 series switches cannot initialize SFP modules less than 10Gbps SecureConnect fails on MS355 series switches MS390 ports are not disabled when configured to do so by dashboard Moving or re-provisioning an MS390 stack in dashboard can cause at least one member to stay offline until rebooted (this only affects control plane traffic). Enabling MS390 ports for UDLD alerting mode will cause those ports to go into an STP blocking state MS390 upgrades to this version will experience a full system reload Branch additions Named VLAN support for MS120/125/210/225/250/350/355/390 series switches Netflow export for Adaptive Policy Multi-auth with voice VLAN bypass support IPv6 management interface support MS390 IPv6 static routing support for MS390 series switches Additional client analytics added for MS390 series switches Meraki authentication support for MS390 series switches Alternate Management Interface (AMI) support for MS390 series switches UDLD support for MS390 series switches Group policy ACL support for MS390 series switches URL redirect support for MS390 series switches UPoE (802.3bt) support for MS390 series switches Critical/failed authentication support for MS390 series switches MAC flap detection support for MS390 series switches Stack power is supported by default for MS390 series switches Netflow support for MS390 series switches Bug fixes Stability enhancements for MS390 series switches in large L2 networks Known issues In rare scenarios, changes made to SVIs may result in connectivity loss for one or more SVIs until reboot (predates MS 12) In rare instances, DAI inspection may fail to snoop DHCP transactions on stacks leading to those clients being in a blocked state Connecting a stacking cable to a stack that is online may result in a stack member going offline (present since MS 12) In rare instances, a stack member may go offline until rebooted (present since MS 12) Networks containing a large number of switches may encounter issues saving changes on the Switch Settings page Stack members are not being marked to update their configuration when changes are made on other members The list of switches to clone from fails to load when cloning a switch in an organization with a large number of switches and networks Broadcast types of traffic can leak into the Guest VLAN if a port that fails authentication has a Voice VLAN configured, and dashboard has a Guest VLAN defined (present since MS 11) AMI IP addresses do not send gratuitous ARP packets which can lead to packet loss if the AMI address has aged out in the network Meraki authentication does not work with guest VLAN MS210/225/250 series switches cannot initialize SFP modules less than 10Gbps When an SFP module is inserted/removed on MS420/425 series switches, BPDUs can be delayed leading to STP transitions in the network (predates MS 12) MS12X In rare instances, MS120 series switches may have empty packet captures until they are rebooted Links being established on an MS120 can result in neighboring ports to flap (present since MS 11) MS120s switch ports with MAB authentication may randomly deauthenticate clients. In order to resume client authentication on that port, a switch reboot is required (present since MS 12) Ports with an odd-numbered MTU value fail to initialize for MS120/125 series switches (predates MS 11) MS35X mGig switches will have an amber light for all physical ports that do not negotiate to the highest supported speed. Dashboard will continue showing a light green status for all ports above 100Mbps. For example, MS355 switch ports will incorrectly show an amber light for 1G, 2.5G, and 5G, but will show a green light for 10G. Enabling Combined Power on MS350/355 switches results in events being logged once per minute (present since MS 11) MS350-24X and MS355 series switches do not negotiate UPoE over LLDP correctly (predates MS 10) SecureConnect fails on MS355 series switches MS390 MS390 ports are limited to the lowest link speed since boot if QoS is enabled MS390s may experience a brief 1-2 minute control plane outage. The data plane will not experience issues during this time. Packet loss is observed when pinging the MS390 management IP MS390 - Port Up/Down Events Shown Across All Members MS390 - StackPower Not Enabled by Default MS390 series switches do not support MAC whitelists MS390 series switches do not support loop detection MS390 series switches do not support warm spare/VRRP Rebooting any MS390 stack member via the UI will result in the entire stack rebooting Enabling MS390 ports for UDLD alerting mode will cause those ports to go into an STP blocking state Moving or re-provisioning an MS390 stack in dashboard can cause at least one member to stay offline until rebooted (this only affects control plane traffic). MS390 ports are not disabled when configured to do so by dashboard IPv6 SVIs added on dashboard do not get configured on MS390 stacks

cmr

Security appliance firmware versions MX 16.14 changelog Important notice While Meraki appliances have traditionally relied on UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications, with MX 16 we are beginning a transition to using TCP port 443 as the primary means for cloud connectivity. In order to ensure proper connectivity to the Meraki cloud after this upgrade, please ensure that traffic using TCP port 443 between 209.206.48.0/20 is allowed through any firewalls that may be deployed upstream of your Meraki appliances. HTTP proxy, which allows default management traffic from MX appliances to be sent through a proxy, is deprecated on MX 16 and higher firmware versions. Legacy products notice When configured for this version, Z1, MX60, MX60W, MX80, and MX90 devices will run MX 14.56. Bug fixes Updated the AnyConnect VPN service Resolved a case that could incorrectly result in brief periods of heightened device utilization. Corrected an issue that could result in communication issues between Z3(C) appliances and client devices connected through a port that was configured to operate at 100Mbps link speed. Fixed a case that could result in group policies not correctly applying to client devices. Corrected an issue that could result in layer 7 firewall rules still taking effect for clients with the whitelisted group policy applied. Resolved an issue that resulted in MX appliances operating in a backup/spare/standby capacity in a high availability pair improperly attempting to establish non-Meraki site-to-site VPN connections. Fixed an MX 15.12 regression that could result in some Macbook clients running some older software versions being unable to reconnect to the client VPN shortly after disconnecting. Corrected an issue that resulted in "Ethernet Port Carrier Change” Event Log messages referencing an incorrect port number on MX95 and MX105 appliances. Resolved a rare case that could cause a device reboot when processing fragmented traffic. Added the ability for MX65(W) appliances to automatically recover when an error causes PoE to stop being provided. Fixed an issue that resulted in the PoE power indicator on the Appliance Status page displaying on the incorrect port for MX75 appliances. Resolved an issue that resulted in Z3(C) appliances that upgraded to MX 16 versions being unable to directly downgrade to MX 14 releases. Corrected a case that could theoretically result in MX250 and MX450 appliances not properly rebooting after a crash had occurred. Upgrade reliability improvements for MX64(W) and MX65(W) appliances. 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 Due to MX 15 regressions, USB cellular connectivity may be less reliable on some modems Due to an MX 15 regression, the management port on MX84 appliances does not provide access to the local status page Client traffic will be dropped by MX65(W), MX67(C,W), and MX68(W,CW) appliances if 1) The client is connected to a LAN port with 802.1X authentication enabled and 2) The VLAN ID of the port is configured to 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, or 240. BGP-learned routes may not be properly reflected in the Route Table page on the Meraki Dashboard, despite BGP and packet routing operating correctly. There is an increased risk of encountering device stability issues on all platforms and across all configurations.

cmr

@Boza please note that the bandwidth limit per SSID is actually per AP per SSID. As an example: You have 30x APs and they all advertise SSID 'public', if you set a limit for that SSID to 1Mbps then you could have as much as 30Mbps of traffic.

cmr

@TEAM-ind we have two MT10 sensors that we have had this issue with. One of them simply has poor reception to all APs so depending on the people in the building etc. it randomly connects every few hours. The other is more like yours where there is an AP well within range but it simply refuses to connect to it most of the time. We did a factory reset on the MT but not the MR as we had a spare MV that was useful in that room so we installed it and now the MT uses that and stays connected all the time. I would try a factory reset on both the MV and the MT (one at a time) as you may get joy there.

cmr

@JDavie in my experience it will either work first time, or it will not, we have some HP switches that just don't work with any DAC, but some Force10 ones seem happy with anything...

cmr

Community Record

Badges