About cmr

cmr

@Eddie01 they are a high current connector, you need something like these as APC don't seem to do the right cables: Black IEC 60320 C14 to Locking C15 15A A-Lock Power Cords (worldcordsets.com)

cmr

Those power supplies require the C15 connector, not the C13.

cmr

I cannot seem to select any of the UNII-3 channels for an MR56 access point in the UK despite them being legal to use since 2017 before the model was designed, let alone sold: Decision to make Wireless Telegraphy Exemption Regulations 2017 (ofcom.org.uk) Are these channels able to be used elsewhere, or does anyone else in the UK have the ability to use them?

cmr

@JED2021 are you saying that shutting the switchport that the device is connected to did not get it to ask for a new DHCP address? If so, then that device is not behaving as it should and needs to be looked at, as opposed to concentrating on the network infrastructure.

cmr

MG41 and MR76 attached to a horse? 🤔

cmr

LOL, it would need a 3D map with materials and densities etc.! Seriously though you should be able to borrow some devices and try it out.

cmr

@DarNic unless you really need it, always disable client load balancing as some clients really don't behave well with it enabled. I'd also make SSIDs either 2.4GHz or 5GHz as opposed to both if you are having issues as this can help.

cmr

Security appliance firmware versions MX 16.13 changelog Important notice This is a beta version for the MX 16 release. Due to this, we recommend taking additional caution before upgrading production appliances. Where applicable, MX 15 or MX 14 releases will provide a more stable upgrade alternative. 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 Improved performance and reliability of WAN connectivity in some cases for MX75 and MX85 appliances. Corrected a race condition that could result in small amounts of traffic improperly flowing between the WAN and LAN during system bootup on MX64(W) and MX65(W) appliances. Fixed a cosmetic issue that resulted in the Dashboard incorrectly reporting that a device was connected to the USB port on MX95 and MX105 appliances. Resolved an issue that resulted in LLDP and EAP traffic being incorrectly sent out all LAN ports on MX64(W) and MX65(W) appliances. Stability improvements for MX250 and MX450 appliances. Corrected an issue that could result in traffic being sent to an incorrect IP address when MX appliances have a cellular active uplink enabled. Resolved an MX 16 performance regressions for VPN traffic on MX250 and MX450 appliances. Fixed an issue that could result in non-Meraki site-to-site VPN tunnel connectivity issues after a failover and failback to WAN2 occurred. 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. Group policies do not correctly apply to client devices Z3(C) appliances that are upgraded to MX 16 versions cannot directly downgrade to MX 14 releases. They must first downgrade to an MX 15 release. 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

@jbright whilst I agree that technically everything you say is correct, there may be a lower cost option. We have an MR46E with the omni-directional antenna slung under a canopy outside one of our central London venues. @UCcert managed to connect to one of our SSIDs over 100m (328ft) away, and that is in one of the most congested WiFi locations on the planet! Based on that 1AP in the middle might work 🤔 🤞 I'm not saying that it's a certified design guide, but might be worth playing with 4 APs, one for each quarter...

cmr

@Twitch a Layer3 switch is effectively a router without the flexibility to support multiple protocols or acceleration / transcoding cards etc. As it only has to deal with the single protocol of (usually) Ethernet, it's hardware is normally more focussed on that and that alone. Technologies such as cut through (where only the packet header is examined) are often implemented, as opposed to a router's store and forward method, massively reducing latency and processing requirements. Obviously features like stateful firewall rules etc. just don't appear on most L3 switches, but as you (and we) aren't using those then a switch can often give you better throughput for the cost.

cmr

@CSUR each AP supports about 30 users on each radio (2.4GHz and 5GHz) The main difference (apart from the MR76 supporting WiFi6 whereas the MR70 only supports WiFi5) with the two models is that you can use an external antenna to provide the best coverage with the MR76, whereas the MR70 has this fixed coverage pattern:

cmr

@Twitch when we used routers with our VPLS before moving to MXs, we actually used a routed port on a Cisco L3 switch at the DC. Due to using only Ethernet and keeping the speeds similar, this worked better than a router. Do you have a 3750, 3850 or 9300 that you could use?

cmr

@redsector if you add tags to the switch ports then they appear as choices in the menu:

cmr

@RaphaelL the radios in Meraki APs try not to change channel when there are clients connected, could this be impacting you?

cmr

@redsector you can tag ports and then only alert on those tagged ports, i.e. ports connected to APs

cmr

@redsector ours definitely don't do that, here is one for the last 2 hours, last week is all green apart from being off for 4 minutes about six days ago... I note that ours are only connecting at 100Mb/s whereas your one seems to be connecting at 1Gb/s. Do you know what version of Apple TV hardware you have as perhaps we are lucky that the older ones work better!?!

cmr

@redsector we have 7 Apple TVs plugged into an MS120-8P and they seem fine? I see one of these down/up transitions about once a week per device. The Sky boxes also sometimes do it, so do our in-house content delivery PCs. Doesn't cause any real issue, is it just that you don't like transitions in the log?

cmr

Upgraded the switch to 14.32 and the issue is now fixed Thank you Meraki team 😎

cmr

I can confirm on the affected MS120-8P switch that we have, this does fix the PoE dashboard issue.

cmr

@RonaldTan yes there was a firmware issue with recognising newer 1Gb Cu transceivers. You need to find an old one or connect the MX to the internet via a fibre connection to get it to update to then work with the newer Cu transceiver. You need to go to 15.43.1 or later.

cmr

@Lourdes speak to support, they can access backend logs

cmr

I've just pushed the upgrade to the switches where the PoE was on the wrong ports, I'll repost here once applied with the result.

cmr

Switch firmware versions MS 14.32 changelog Alerts MS390 upgrades from MS 14.29 or later will result in minimal impact to client traffic Branch additions Syslog support for MS390 series switches SNMP support for MS390s RADIUS accounting support for MS390s Alternate Management Interface support for MS210/MS225/MS250/MS350/MS355/MS410/MS425/MS450 series switches QoS support for MS390s CoA support for MS390s STP anomaly detection events for non-MS390 series switches Adaptive policy support for MS390 series switches SecureConnect support for MS210/MS225/MS250/MS350/MS355/MS410/MS425/MS450 series switches NAC enhancements for MS120/125/210/225/250/350/355/425/450 series switches Critical/failed auth VLAN support for MS120/125/210/225/250/350/355/425/450 series switches Bug fixes Voice VLAN clients cannot pass traffic on ports that have MAC allowlists enabled (present since MS 14.28) Clients on a RADIUS authenticated port that ages out of the MAC table due to inactivity will fail to be relearned until a port bounce has occurred (present since MS 14.28) MS120s may show PoE usage on the incorrect port If RADIUS authentication begins close enough to boot, the NAS-IP in Access-Request packets will be incorrect Clients connected to a MS390 trunk port on the native VLAN will show "native" for the VLAN information rather than the native VLAN ID Known issues In rare instances, DAI inspection may fail to snoop DHCP transactions on stacks leading to those clients being in a blocked state If a combined network has Umbrella integration, changes cannot be made to the group policy page (present since MS 14.5) Networks containing a large number of switches may encounter issues saving changes on the Switch Settings page 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) Stacking Stack members are not being marked to update their configuration when changes are made on other members In rare instances, a stack member may go offline until rebooted (present since MS 12) In rare instances, non-390 stack members will reboot (present since 12.29+) MS120 MS120 in rare instances will not be able to perform packet captures until rebooted (predates MS 12.28) MS120s on rare occasions will reboot (present since MS 11) Links being established on a MS120 can result in neighboring ports to flap (present since MS 11) MS120s switchports 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) MS35X Enabling Combined Power on MS350/355 switches results in events being logged once per minute (present since MS 11) 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. Example, MS355 switchports will incorrectly show an amber light for 1G, 2.5G, and 5G, but will show a green light for 10G. MS350-24X and MS355 series switches do not negotiate UPoE over LLDP correctly (predates MS 10) MS390 MS390s may experience control plane resets which could impact dashboard connectivity. This does not affect data plane traffic. 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 Stackpower is not enabled on MS390s by default MS390 - Port Up/Down Events Shown Across All Members MS390 series switches do not support SM sentry MS390 series switches do not support Meraki authentication MS390 series switches do not support URL redirection 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 MS390 series switches do not support UDLD Rebooting any MS390 stack member via the UI will result in the entire stack rebooting

cmr

@XChangingIT indeed for that you will need support to do it. However as it isn't a fault it will not be treated as the highest priority, though I'd have thought it should be sorted in a few days.

cmr

TBH I usually get the answer either here, or work it out myself. It is still worth logging as we can't create new firmware, but post your issue here as well.

cmr

Community Record

Badges