Meraki

rhbirkelund · ‎Oct 31 2024

Congratulations, @cmr . You deserve it. 🙂

rhbirkelund · ‎Oct 21 2024

I have never been able to search the license, either in the results dropdown, or Find Products.

rhbirkelund · ‎Oct 21 2024

Yeah, it's not searchable But if you just press enter, it's added to the estimate.

rhbirkelund · ‎Oct 21 2024

You may need to just “Hail Mary” it, and type in the SKU and press enter. The MR license has never been able to just search for it.

rhbirkelund · ‎Oct 21 2024

Could it be that you are only allowing up to 10 users on the switch port? Perhaps you could remove that, or increase it to a large number?

rhbirkelund · ‎Oct 20 2024

I won't neccesarily say that it's a rule of thumb. Those working a lot with Cisco and been following the roadmap, have more or less gotten use to how it is now, and what's going on. In principle the CW9166 is the same, whether it is in Meraki Persona or Catalyst. -E og -MR simply denotes how the AP was "born" i.e. if it's shipped in Catalyst persona or Meraki persona, respectively. But like I said, they can be converted back and forth, although I believe that Cisco or Meraki might not like you switching between each persona every week... The journey during the last couple of years with Meraki and Catalyst persona is part of Cisco journey towards the one platform. In the future there will not be anything calles Cisco APs or Meraki APs. It'll be the same hardware platform with different personas depending on how they will be managed. As an example, for C9300 switches that are in Meraki Persona, and thus mananged by the Meraki Dashboard, it's been working such that a container is running within IOS-XE, screaming API calls to the underlying IOS, based on 17.12.3. From IOS-XE 17.15 it'll be Native, such that the switch will be talking directly with Meraki, and not via a container. With WiFI 7 we'll be moving even closer to the "one platform to rule them all", so we no longer have to order different APs depending on regulatory domain, persona, etc.

rhbirkelund · ‎Oct 18 2024

Woohoo! Congratulations and welcome, Thomas!

rhbirkelund · ‎Oct 18 2024

CW9166 and Catalyst 9166 are the same thing. CW simply stands for Catalyst Wireless. CW9166 as it self is a general term that people tend to use. CW9166I is an AP with Internal omni-directional Antennas, not unlike 2802i, 3702i, etc. A CW9166I-MR indicates a 9166I AP in Meraki Persona, i.e. one that is fully managed in the Meraki Dashboard, just like an MR33 etc. CW9166D1 is an AP with internal directional antennas. Note that there is a difference between omni-directional and directional antennas. All Meraki APs that start with MR, e.g. MR33, MR36, MR46E, etc are Meraki native Access Points. All APs with CW, e.g. CW9162, CW9164 are dual-mode APs which can be in either Catalyst persona or Meraki persona, and may be converted back and forth. All APs with C, e.g. C9120, C9130, C9136 etc are Catalyst only APs, meaning they can not be managed byt the Meraki Dashboard, and thus requires a Wireless Controller.

rhbirkelund · ‎Oct 17 2024

Neither did I, untill I was preparing a WAN port for a Internet circuit switch to a tagged VLAN, and my MX went Offline. I opened a case with Meraki, who then pointed me towards the behaviour. 🙂 I wasn't impressed either, to say the least.

rhbirkelund · ‎Oct 17 2024

A change on a WAN interface incurs a reset on all WAN interfaces. E.g. if you change the IP address on WAN2 - even if it's not connected - will reset both interfaces. It's expected behaviour - https://documentation.meraki.com/MX/Monitoring_and_Reporting/Appliance_Status/MX_Uplink_Settings#Secondary_WAN

rhbirkelund · ‎Oct 10 2024

What firmware version is it running?

rhbirkelund · ‎Oct 8 2024

Linux does try to recover services and watchdogs by restarting them. So fair point that it's not uncommon. But I have yet to see a Linux machine reboot completely by itself in order to recover from a services stopping.

rhbirkelund · ‎Oct 8 2024

I can see scenarios where this may be a good thing, but I can definitely also see ones where this may potentially wreck havoc.

rhbirkelund · ‎Oct 8 2024

My thought exactly.

rhbirkelund · ‎Oct 8 2024

And sorry for hijacking your usual good work, @cmr 😉

rhbirkelund · ‎Oct 8 2024

Long list of bug fixes, but these two new behaviours mentioned in the end are a doozy. These are really going to mess up customers, who don't expect their MX to randomly reboot because Dashboard Connectivity was lost. When key processes crash, MX appliances will now make a greater effort to restart and recover those processes before initiating a device reboot as a last resort to restore the device to a healthy state. Reinstated a device reboot that will occur after MX appliances lose connectivity to the Meraki Dashboard for 8 hours. These reboots will continue every 8 hours until Dashboard connectivity is restored.

rhbirkelund · ‎Oct 8 2024

Important notice As of MX 19.1, Cisco Meraki will no longer support USB-based Cellular Failover on the MX and Z platforms. What's new Added support for configuring eBGP over non-Meraki site-to-site VPN connections. Added support for failover (and failback) between non-Meraki VPN tunnels MX appliances can now integrate with the Cisco XDR network security product from the Meraki Dashboard Significantly expanded the troubleshooting capabilities available from the device local status page Improved traffic classification with SD-AVC (Software-Defined Application Visibility and Control) Supported products notice VMX-XL appliances are not yet supported in the MX 19.1 beta. VMX-XL appliances that are configured for this version will not upgrade. 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. When configured for this version, MX64(W), MX65(W), MX84, MX100, and vMX100 devices will run MX 18.107.11. Bug fixes Fixed an issue that could result in AutoVPN being disabled when 1) the MX appliance was configured in passthrough mode and 2) DNS caching size parameters were modified in the device configuration. Resolved an issue that resulted in jitter and latency spikes on Z3(C) appliances when there was minimal AutoVPN traffic. Fixed an issue on MX75, MX85, MX95, MX105, MX250, and MX450 appliances that resulted in AutoVPN traffic being sent to the incorrect destination uplink when 1) the MX appliance was configured to operate as a hub, 2) the MX was configured in passthrough mode, 3) the destination AutoVPN spoke had enabled Active-Active AutoVPN, and 4) the AutoVPN traffic was spoke-to-spoke communication being routed through the AutoVPN hub. Resolved an issue that could result in extended periods of incomplete route table updates when a WAN outage occurred if 1) the MX appliance was operating as an AutoVPN hub, 2) the MX appliance was configured in NAT mode, 3) OSPF route advertisement was enabled, and 4) a large number of VPN peers were connected. Fixed an additional issue that could degrade the performance of traffic destined to and sourced by MX appliances when 1) IPv6 was enabled, 2) BGP was enabled, and 3) there were over 1024 AutoVPN peers. Fixed an issue that could result in the Route Table page failing to display correctly. This was caused by BGP routes with very long AS paths. MX appliances will now only report the first 50 AS paths to the Route Table. Corrected an MX 18.2 regression that resulted in MX75, MX85, MX95, MX105, MX250, and MX450 appliances failing to form AutoVPN or teleworker tunnels with other peers via their LAN interfaces. Fixed an issue that could result in EBGP peering instability when 1) the MX appliance is configured to operate in routed mode and 2) many EBGP routes are received. Fixed several rare cases that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances improperly dropping traffic destined to or from a VPN peer. Resolved an issue that could result in users encountering failed connections or connections taking an excessive amount of time to complete when using SAML authentication to authenticate an AnyConnect client VPN session. Corrected a very rare issue that could cause the AnyConnect VPN process to crash. Corrected an issue that could result in group policies failing to apply to AnyConnect VPN clients on MX75, MX85, MX95, MX105, MX250, and MX450 appliances. Resolved an issue that would cause intermittent AnyConnect authentication failures when SAML authentication was in use. Resolved an issue that could result in client VPN not working when 1) the MX appliance had FIPS mode enabled and 2) the device connecting to the client VPN was a Windows PC. Fixed a rare issue that could result in the AnyConnect VPN process becoming unresponsive on MX75 and MX85 appliances. Corrected an issue that could result in MX appliances failing to properly form IKEv1 VPN tunnels. Corrected an issue that resulted in Non-Meraki VPN tunnels persisting on the backup, non-primary uplink after failing back to the primary uplink when the WAN interface used IPv6. Fixed an issue that resulted in the VPN status being reported incorrectly for Non-Meraki VPN peers connected via FQDN. Corrected an issue that resulted in MX75, MX85, MX95, MX105, MX250, and MX450 appliances being unable to successfully establish IPSec VPN connections when NAT-T was required to establish the connection. Corrected an issue that resulted in the primary MX appliance in a warm spare configuration advertising an incorrect VRRP priority when cellular active uplink was enabled. Resolved a rare issue that could result in Z3(C) appliances failing to advertise any SSIDs. Cellular reliability improvements for Z3C, MX67C, MX68CW appliances. Resolved an issue that could result in MX67C and MX68CW appliances failing to correctly establish cellular connectivity after swapping SIM cards. Corrected a rare MX 18.2 regression that could result in MX67C, MX68CW, and Z3C appliances failing to establish a cellular connection using the integrated cellular modem. Resolved an issue MX67C, MX68CW, and Z3C appliances may fail to apply IPv4-only custom APNs. Fixed an extremely rare issue that could result in an unpredictable set of firewall rule sets to fail to allow traffic as configured. This would be consistently reproducible as long as the firewall configuration remained identical. Since the likelihood of encountering this is extremely low, any modification to the firewall rule set, including changes that would produce no functional change to network operations, would remediate the issue. Fixed an issue that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances failing to appropriately block or allow IPv6 traffic that relied on L3 FQDN firewall rules. Corrected a very rare issue that could result in MX68(W,CW) appliances failing to supply full 802.11at power through PoE. Fixed an issue that caused disabled ports to still provide PoE. Corrected a rare issue that could result in MX67(C,W), MX68(W,CW), MX75, and MX85 appliances failing to forward traffic on a subset of physical ports. This was most likely to occur after extended periods of uptime. Corrected an issue that resulted in MX appliances failing to authorize ports when 1) 802.1X port authentication was configured and 2) the configured RADIUS server sent the Tunnel-Private-Group attribute with a string value. Fixed an issue that could result in MX appliances responding to client ARP requests using the WAN MAC address instead of the LAN MAC address. Resolved an issue that caused MX appliances to not reply to IPv6 ICMP requests when they were addressed to one of the MX’s VLAN interfaces. Resolved a rare issue that resulted in MX appliances failing to block websites when the TLS initialization messages were segmented across multiple packets. Fixed an issue that resulted in devices not reporting the category that caused a URL to be blocked by content filtering when in full list mode. Fixed a rare issue that could result in a device reboot when IDS/IPS was enabled. Fixed an issue that could result in a device reboot when very large or very complex firewall rules were configured in the L3 firewall or the site-to-site VPN firewall. Fixed an issue that resulted in MX95 appliances being unable to boot up properly when more than 370 VLANs were configured. Configuring this number of VLANs is not recommended. Resolved an issue that could cause MX appliances upgrading to MX 18.2 from very old, unsupported firmware versions to hang during the upgrade process. Corrected an issue that could result in brand new MX67(C,W) and MX68(W,CW) appliances taking significantly longer than expected to perform a firmware upgrade. Corrected an issue that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances failing to forward NTP responses to LAN clients. Resolved a flow timeout issue that could result in IPv6 inter-VLAN traffic being incorrectly dropped on MX75, MX85, MX95, MX105, MX250, and MX450 appliances. This was most likely to occur in client communication patterns where one side of the inter-VLAN conversation was “silent” for extended periods of time. Fixed an issue that could result in packets being routed incorrectly after 1) a static route was deleted and 2) a VLAN was created using the same subnet as the now-deleted static route. This issue could have been worked-around by rebooting the MX after the configuration change. Resolved a rare issue that could result in traffic being improperly dropped by MX75, MX85, MX95, MX105, MX250, and MX450 appliances. Resolved an MX 18.211 regression that resulted in MX75, MX85, MX95, MX105, MX250, and MX450 appliances failing to properly forward Radius Authentication traffic when configured as a Wireless Concentrator for SSID Tunneling or Layer 3 Roaming. This caused clients to fail to connect to wireless SSIDs. Corrected several packet routing issues that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances continuously operating at 100% device utilization. Resolved an issue that resulted in the ThousandEyes agent being unable to send traffic over IPsec VPN connections. Fixed an issue that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances reporting an erroneous spike in network traffic usage. Resolved an issue where wireless MX and Z appliances could erroneously report an 802.1x authentication even in the event log when clients connected to an open SSID. Corrected an issue that resulted in MX appliances always setting the NAS-IP attribute in RADIUS Access-Request packets to 127.0.0.1. The NAS-IP will now be the IP address of the MX’s lowest numbered VLAN. Known issues There is an increased risk of encountering device stability and performance issues on all platforms and across all configurations. Other When key processes crash, MX appliances will now make a greater effort to restart and recover those processes before initiating a device reboot as a last resort to restore the device to a healthy state. Added support for enabling and disabling PoE via the device local status page. Reinstated a device reboot that will occur after MX appliances lose connectivity to the Meraki Dashboard for 8 hours. These reboots will continue every 8 hours until Dashboard connectivity is restored. The SIM PIN can now be configured via the device local status page without having to first set a custom APN. Added SIM configuration information for AT&T FirstNet and TRUE-H cellular operators for MX67C, MX68CW, Z3C, and Z4C appliances. Z4(C) appliances will no longer perform a device reboot after FIPS mode is enabled or disabled.

rhbirkelund · ‎Oct 5 2024

I would recommend bringing them online individually first, ensure they have been upgraded, and then stack them. Expect the first time boot, coming online in the dashboard and firmware upgrade to take the better part of 20-30 minutes.

rhbirkelund · ‎Oct 5 2024

I'd open a case with Meraki, and have them verify if the optic is supported on C9300X. It's listed on the C9300X datasheet, but the switch is not listed in the compatibility list on Merakis list of trancievers.

rhbirkelund · ‎Oct 5 2024

If you refer to the release notes for CS16 and CS17, there are a number of fixes and caveats (as there are with all firmware versions). Depending on your requirements and need of features it is your decision to use CS16 or CS17. I can't recommend what you should or shouldn't use. It's up to your deployment. With a 9300 in Meraki Persona you do not have access to the CLI - this is disabled. All firmware management is done on the Meraki Dashboard. CS16 software is based on IOS-XE 17.9.6. CS17.1.3 is based on IOS-XE 17.12.3. Again, in a Meraki context, you no longer have the concept of IOS-XE versioning, other than what the CS firmware is built on.

rhbirkelund · ‎Oct 5 2024

In principle, no.

rhbirkelund · ‎Oct 5 2024

If you hold the camera in your phone over the fiber ends, do you see light in the Tx of the fiber? Does it patch with the RX on the other end of the fiber?

rhbirkelund · ‎Oct 5 2024

If using a C9300 in Meraki persona you don't have the concept of IOS-XE versions anymore. Firmware is handled in the the Meraki Dashboard, and uses CS software trains. In Meraki Person, you don't have access to the console anyway, so you wouldn't be able to apply IOS-XE firmwares anyway. At the moment CS16.9 is the Stable version with CS17.1.3 as Stable RC. Overall, these versions have nothing to do with IOS-XE such as 17.9.6 or 17.12.4. Whether going with Stable or Stable RC really depends on your requirements. But both versions are fully supported by Meraki Support. That being said, the CS software internally does have some ties to IOS-XE software. But in general, a C9300 in Meraki persona, is to be regarded as any other Meraki switch - and not a Cisco Catalyst, as we did previously.

rhbirkelund · ‎Oct 5 2024

Most likely it's because the network was created as a combined network, with all product types. If you had created the network at first as e.g. Security Appliance and afterwards added a switch or Wireless, it would have become a Combined Type but with only Security, Switch and/or Wireless product types. To remove the MT and MV types you can select the network on the Organization Overview page. Tick the network, and click "Split". This will split the network into all product types that it contains. Then you can select the product types you are interested in, e.g. Security and Switch, and then click on "Combine". This will combine the selected networks into a Combined Network. The ones you are not interested, you can then simply delete. If I recall, this does not have an impact to production, but it wouldn't hurt being in the side of caution, and do the first network split/combine in a service window to verify production impact (or lack thereof).

rhbirkelund · ‎Oct 2 2024

Fun stuff!

About rhbirkelund

rhbirkelund

Community Record

Badges