About cmr

cmr

@alemabrahao it's all about getting the result, even in a recent refurbishment, we had to cancel replacing a bundle of 120 unshielded CAT5e cables with new CAT6a as the cost of taking down all the ceilings, opening up the roof and the re-doing it all would have taken the project up to £100k over budget. We ended up using the shortest length possible, re-terminating them all and creating a patch frame out of wooden and angle iron offcuts that would fit into a 80mm deep void. Horrible solution, but often what you need to do in the real world!

cmr

We used IBM type 1 cabling with home made adapters for several years at 100Mb...

cmr

If the cabling behind is CAT5e (only two pairs wired), then you could run 100Mbps... 😉

cmr · Re: A new stable camera firmware is now available on Tue, 19 Sep 2023

This is the firmware being classified as stable.

cmr · Re: A new candidate switch firmware is now available on Tue, 19 Sep 2023

This is the firmware moving from beta to stable release candidate.

cmr

@Aztec_Ninja you could connect them together with two cables, a 10Gb in the SFP+ ports and a 1Gb in the normal RJ-45 ports. The switches will shut the 1Gb link unless the 10Gb one goes down. We have used this option many times when we haven't had two spare SFP+ ports.

cmr

@JacekJ apologies, the title was summarised from 16.4 🙈

cmr

Thanks @athan1234, have you tried looking at the CDP/LLDP information on the ports? If you go to the switchports view and add that column you should be able to see where the switches are connected to each other.

cmr

@alemabrahao I'm guessing the same as you, but what features does an MS450 have that a MS355 does not, or vice-versa? I do wonder if it would be technically possible, but the Meraki product owners don't think it is a feature worth spending development and testing resource on?

cmr

I know we're probably not going to get an answer, but does anyone know a technical reason why switches with the same stacking bandwidth cannot be stacked together, with the notable exception of the MS210 and MS225 ranges? In particular I'm thinking of the MS-355 and MS-450 models that both have 100Gb stacking connections. They must have about the same performance as you can have 384Gbps between the 54 front ports on the 355-48X2 with the 450-12 having 680Gbps between 14 ports. A pair of 450/355 mixed stacks would be a great core.

cmr

@athan1234 do you have a diagram of how they are connected? I would set the core to a lower number and then work out, leaving the edge switches on the default or a higher number. See below where we have done similar, leaving about 5 edge switches in the default group:

cmr

The tool on the switch webpage is merely an indicator. Due to the switches having specialised ASICs that are not good for general purpose compute tasks, the maximum performance you will see on an MS is very low. For example on a site of ours with a 500Mbps+ dedicated fibre connection, a MS355-24X gives 24Mbps and an MS120-8LP give 20Mbps. An MX250 on the same site gives 268Mbps. None are correct and the more general purpose nature of the MXs CPU gives a much higher result.

cmr

@amwjoe we use MX355-24X and 48X (not X2) in our datacentres. They have been very reliable and performant, though we aren't running storage (iSCSI or FCoE) protocols on them. If your servers have 10Gb RJ-45 sockets on them I would go with the MS355s, but if your servers have SFP+ ports on them then the MS425 with DACs might be a better bet. I say this as we have had variable results with 10Gb RJ-45 adapters in SFP+ ports on servers. Sometimes they work like a dream for years, other times they are constantly troublesome, same server models and transceiver models...

cmr · Re: A new beta wireless firmware is now available on Mon, 11 Sep 2023

Wireless firmware versions MR 30.5 changelog Important note While Meraki APs have traditionally relied on UDP port 7351 for cloud communication, and TCP ports 80 and 443 for backup communications, with MR 28+ we are beginning the 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 all “Meraki cloud communication” traffic specified in the "Help" > "Firewall Info" page is allowed through any firewalls or security devices that are deployed upstream of your Meraki APs. These requirements have been updated in November of 2022, so it is important that you review them. (Wi-Fi 6 and Wi-Fi 6E APs) WEP deprecation (https://documentation.meraki.com/MR/Encryption_and_Authentication/WEP_Deprecation_on_MRs) Legacy product notice When configured for this version, MR12, MR16, MR18, MR24, MR26, MR32, MR34, MR62, MR66, and MR72 will run MR 26.8.3 Bug fixes General stability and performance improvements WPA3 OWE AKM suite missing in beacons Incomplete configurations when using VLAN profiles Intermittent connectivity loss for Windows client devices When using WPN, DHCP requests are missing option 55 Known issues Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs) In high capacity wireless networks APs may experience instability when the “Client Balancing” or "Band Steering" feature are enabled

cmr

We use the walled garden feature and have a list of URLs that are allowed pre authentication. We do block all except the walled garden list. It does work for us, but we have domains listed more like *.meraki.com as opposed to what is shown above.

cmr

Also note than you don't need all values, here are a couple we use on dedicated fibre links:

cmr

@DavidV38 is the device in the new network? If not then that is the issue and if you cannot move it please ask support to do so.

cmr

You don't need to create separate networks as the different stacks in the same network can be upgraded at different times. We have sites with three or four stacks and when we do a staged upgrade we create a group for each stack so the upgrades apply to one stack, then another etc. The default is to upgrade one group (stack in our case) each day, but it can be amended to be quicker or slower.

cmr

Updated release notes: Cellular gateway firmware versions MG 3.101 changelog NEW FEATURE HIGHLIGHTS Enabled support for Verizon C-Band (N77) for the MG51/E Introduced automated discovery for AIF Telecom BUG FIXES Corrected Dashboard UI issue where MG51s would display their link speed as 10 Mbps when connected at 2.5 Gbps Corrected behaviour for MG41 in passthrough mode where ICMP reply packets would not be forwarded out its cellular interface

cmr

Updated release notes: Cellular gateway firmware versions MG 3.101 changelog New feature highlights Enabled support for Verizon C-Band (N77) for the MG51/E Introduced automated discovery for AIF Telecom Bug fixes Corrected Dashboard UI issue where MG51s would display their link speed as 10 Mbps when connected at 2.5 Gbps Corrected behaviour for MG41 in passthrough mode where ICMP reply packets would not be forwarded out its cellular interface

cmr

@SwitchedAtBirth personally I'd try the current CS16.3 beta as the release trains were separated to allow Catalyst hardware to get more fixes.

cmr

It looks like you need to go up to at least a 1000F to get 40GbE ports on a Fortigate. Not really a surprise when the 100F only support 1Gbps of throughput, whereas the 1000F supports 13Gbps.

cmr

@CMiranda1 you can't use breakout cables with Meraki switches. The firmware only has one logical port per physical port. It is annoying, but there don't seem to be any plans to add it as a feature.

cmr

It does indeed, ours all run two 5GHz radios and select separate non overlapping channels. We didn't need to set anything as it does default to 2x5GHz radios.

cmr

Security appliance firmware versions MX 18.107.5 changelog Important notice USB modems with MX/Z series devices running firmware MX 18 or newer will be limited to best effort support and will not be receiving any future firmware fixes or improvements. Bug fixes Stability improvements for MX75 appliances. Corrected an issue that could result in AnyConnect client VPN clients from being unable to ping hosts on the MX WAN if the MX was configured in passthrough mode. Fixed an issue that resulted in some AutoVPN subnets becoming unreachable when there were more than 4093 AutoVPN peers configured. Resolved an issue that resulted in performance probes used for measuring AutoVPN path performance being sent too frequently. Corrected an issue that resulted in wireless broadcast traffic being improperly routed on MX64W and MX65W appliances. Fixed an issue that could result in CPU time being spent on wireless processes when no SSIDs were enabled on MX64W and MX65W appliances. Resolved an issue that resulted in MX appliances configured in high availability using their WAN interface IP address for establishing EBGP sessions when a VIP was configured. Fixed an issue that could result in IP addresses not being freed and returned to the lease pool when IPSec client VPN connections were terminated. Corrected an issue that resulted in MX95, MX105, MX250, and MX450 appliances not dropping untagged traffic when configured to do so. Resolved an MX 18.1XX regression that resulted in peripheral devices, such as the USB port, not receiving the correct amount of power on MX65(W) appliances. Legacy products notice When configured for this version, Z1 devices will run MX 14.56. When configured for this version, MX400 and MX600 devices will run MX 16.16.9. 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 an MX 15 regression, the management port on MX84 appliances does not provide access to the local status page MX appliances will now properly validate that DBD packets conform to the appropriate MTU size. If the MX's OSPF peer has an improper MTU configured, it may cause the OSPF adjacency to fail to properly form. The updated behavior properly conforms to RFC. Please ensure these settings are properly configured on any MX's OSPF peers to avoid disruption after upgrading to MX 18.1.X.

cmr

Community Record

Badges