About cmr

cmr

Any hot-cold power cable will do for an MS120. As mentioned above the switches with removable power supplies and PoE required the notched connector (C15) at the switch end due to them being in the exhaust flow. The cable is also a slightly rougher material as it can withstand higher temperatures that may be present in those areas. Again, if you ever need those cables they are commonly available from most suppliers.

cmr

We're using it with the enterprise feature set and it works well. Your experience may differ if you use certain devices with advanced features enabled.

cmr · Re: A new stable appliance firmware is now available on Mon, 28 Nov 2022

This is 17.10.2 moving from stable release candidate to stable release. We've been using it with enterprise features reliably, but there are several reports of advanced features leading to a less good experience.

cmr

cmr

If you look at the client page and add the port column, you will see for many MXs that the port shown is indeed N+1. Therefore port 2 is the labelled port 3 as @alemabrahao stated. Try on your network and this will confirm it for you, but it is definitely the case for an MX75.

cmr

@ronnieshih75 I would follow what @GIdenJoe said, we recently found that some 1Gb RJ45 transceivers would not properly plug into Meraki SFP+ ports as the ports were slightly sunk into the fascia. This caused no issues with fibre transceivers as they are smaller. We run MX250s with Cisco GLC-T in the WAN ports without issue, but I do remember that some Meraki GLC-T modules did need a firmware update to be recognised (as per @PhilipDAth's comment. Do you have any non-Meraki GLC-T transceivers or fibre ones? On another note, I'm sure you know that the DAC will only come up at 10Gb (usually) so you mustn't force the port to 1Gb.

cmr

Looks good and hope the holiday season goes well for you guys 👍

cmr

Thanks @Ryan_Miles. I like the idea, but it's painting a bit of a rosy picture 😐

cmr

Is the status page at https://status.meraki.net genuine? It looks like it might be, but the Catalyst monitoring snafu that deleted all the port channel configs isn't on there and as it was a catastrophic issue, it certainly should have been!

cmr

The utilisation of 161 is 0% so that shouldn't be the problem, though I did check a 9166 and the graph is all over the place. Newer models often take a while for this part to be right...

cmr

Here you can see an AP on channel 40 that is slightly suffering, but in realist is working fine, what does the table below show for your one? In terms of diagnostics there is a lot of infrastructure between your client and Google's DNS servers, so I would ping the local gateway for a better test of the AP and local switch / router only. If that shows loss and pinging it from a wired device does not then the wireless is where to investigate.

cmr

@merman01 the Meraki APs automatically adjust power and channels for best performance (unless you override that feature). For connection issues you have the wireless health page and for overall AP placement the location heatmap can help as it shows device locations, see an example below:

cmr

I think it is where it is, because switches can also be DHCP servers and it is in the same relative place there. I do agree however that it is hard to find and I think it should be under Network-wide / Monitor in a DHCP addresses section. There could be a column there to indicate which device leased the address to cover networks with multiple L3 switches assigning addresses alongside an MX.

cmr

We have had STP not block properly with MX + MS though it works fine with Catalyst switches. I haven't re-tried this config with MS15.x stacks yet.

cmr

We run a similar setup and have the MXs at the core site in single arm VPN concentrator mode. The MPLS terminates on the WAN ports of the MXs at the other sites with the core using a L3 switch. There is a separate internet firewall at the core. All works well 😎

cmr

Or on the test laptop set the VLAN to 55 in the network card properties. That would better test that the tagged VLAN 55 is getting across the SG300 to the MX64. Something else to check is the spanning tree type on the switches. Both should be the same (i.e. PVST or MST).

cmr

That looks good to me, you might want to lose the connections to P10 on the MX105 pair, but they might be fine 😎

cmr

It does add more availability and performance to the design, but it does mean that when you apply a firmware change, both have to be done at the same time, so that might be a concern if you are a 24/7 operation.

cmr

Security appliance firmware versions MX 16.16.7 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 and MX80 appliances will run MX 14.56. Bug fixes Corrected an issue that could result in an inconsistent connection to the Cisco Umbrella service when Umbrella Protection was configured. MX appliances will now always connect to Active Directory servers using DCOM version 5.7. This should help resolve errors when communicating with Active Directory servers using more recent versions of software. Corrected an issue that could result in the Dashboard reporting of the Active Directory server status always showing a failed connection. Resolved a rare issue that could result in traffic being misclassified by NBAR. Stability improvements for VMX-L appliances deployed in the Umbrella Cloud. 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.

cmr · Re: A new stable appliance firmware is now available on Wed, 16 Nov 2022

Security appliance firmware versions MX 16.16.7 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 and MX80 appliances will run MX 14.56. Bug fixes Corrected an issue that could result in an inconsistent connection to the Cisco Umbrella service when Umbrella Protection was configured. MX appliances will now always connect to Active Directory servers using DCOM version 5.7. This should help resolve errors when communicating with Active Directory servers using more recent versions of software. Corrected an issue that could result in the Dashboard reporting of the Active Directory server status always showing a failed connection. Resolved a rare issue that could result in traffic being misclassified by NBAR. Stability improvements for VMX-L appliances deployed in the Umbrella Cloud. 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.

cmr

Have you checked if there is a duplex issue. Has the ISP forced full and you are on auto? Can you connect a client directly to test the link?

cmr

The Org I can see it in has MR55/56, the one I cannot has MR32 through to 9166 so it could be older models are going to be added later?

cmr

Or are you using the old cache feature?

cmr

@markus_albisser there shouldn't be any data stored on the MX devices, or are you referring to the configuration that might include hostnames etc. in firewall rules?

cmr

I have access to two organisations and in one the banner is at the top regarding UNI3 and I can select the channels, in the other it is no and I cannot select them. I'd guess this feature is being rolled out in stages.

cmr

Community Record

Badges