MX Firmware changelog improvements

RaphaelL
Kind of a big deal
Kind of a big deal

MX Firmware changelog improvements

hi ,

 

I would like to suggest some improvements to the MX/Z Series firmware changelog. 2 Key things :

 

1- Split the changes by device group / device type. So instead of grouping all the changes for all the devices , put them in groups. Eg : Z Series , MX68 , MX85 , MX95 and so on. This will make bug scrubing way easier.

2- Regroup "general" fixes  ( a.k.a fixes that applies to ALL devices ) into a single category.

 

Yes this will make change logs WAY longer , but way more readable imo as you will be able to ignore sections that do not affect you.

 

Many changes are affecting the same "device group" eg : MX75 to MX450 , maybe grouping in a single category would make the change log shorter.

 

Current 19.1.4 format : 

 

 

Spoiler

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.
  •  

 

 

Suggested format ( I may have omited / lost some changes ! ) :

 

Spoiler

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

                General

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Resolved an issue that would cause intermittent AnyConnect authentication failures when SAML authentication was in use.
  • 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 the primary MX appliance in a warm spare configuration advertising an incorrect VRRP priority when cellular active uplink was enabled.
  • 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 caused disabled ports to still provide PoE.
  • 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.
  • 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.
  • 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 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 an issue that could cause MX appliances upgrading to MX 18.2 from very old, unsupported firmware versions to hang during the upgrade process.

Z-Series

  • Resolved an issue that resulted in jitter and latency spikes on Z3(C) appliances when there was minimal AutoVPN traffic.
  • Resolved a rare issue that could result in Z3(C) appliances failing to advertise any SSIDs.
  • Cellular reliability improvements for Z3C, MX67C, MX68CW appliances.
  • 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.
  • 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.

 

                MX68

  • 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.
  • Corrected a very rare issue that could result in MX68(W,CW) appliances failing to supply full 802.11at power through 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 could result in brand new MX67(C,W) and MX68(W,CW) appliances taking significantly longer than expected to perform a firmware upgrade.

 

                MX75

  • Fixed a rare issue that could result in the AnyConnect VPN process becoming unresponsive on MX75 and MX85 appliances.
  • 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 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.
  • 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.
  • Fixed a rare issue that could result in the AnyConnect VPN process becoming unresponsive on MX75 and MX85 appliances.
  • 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 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 several packet routing issues that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances continuously operating at 100% device utilization.
  • Fixed an issue that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances reporting an erroneous spike in network traffic usage.
  • 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.
  • 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.

 

                MX85

  • Fixed a rare issue that could result in the AnyConnect VPN process becoming unresponsive on MX75 and MX85 appliances.
  • 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 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.
  • 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.
  • Fixed a rare issue that could result in the AnyConnect VPN process becoming unresponsive on MX75 and MX85 appliances.
  • 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 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 several packet routing issues that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances continuously operating at 100% device utilization.
  • Fixed an issue that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances reporting an erroneous spike in network traffic usage.
  • 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.
  • 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.

 

                MX95

  • 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 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.
  • 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.
  • 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 several packet routing issues that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances continuously operating at 100% device utilization.
  • Fixed an issue that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances reporting an erroneous spike in network traffic usage.
  • 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.
  • 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.
  • 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.

 

                MX105

  • 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 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.
  • 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.
  • 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 several packet routing issues that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances continuously operating at 100% device utilization.
  • Fixed an issue that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances reporting an erroneous spike in network traffic usage.
  • 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.
  • 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.

 

                MX250

  • 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 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.
  • 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.
  • 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 several packet routing issues that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances continuously operating at 100% device utilization.
  • Fixed an issue that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances reporting an erroneous spike in network traffic usage.
  • 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.
  • 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.

 

                MX450

  • 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 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.
  • 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.
  • 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 several packet routing issues that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances continuously operating at 100% device utilization.
  • Fixed an issue that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances reporting an erroneous spike in network traffic usage.
  • 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.
  • 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.

 

 

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.

 

Honnest thoughts on this ?

 

Cheers , 

12 Replies 12
Mloraditch
A model citizen

In general I like the idea, but maybe there could be groups. A good number of these fixes apply to everything MX75 and above and it would make it less busy.

RaphaelL
Kind of a big deal
Kind of a big deal

Absolutely !

cmr
Kind of a big deal
Kind of a big deal

Do you mean a bit like I did with the MSs that made it to the real release notes...? 🤔

If my answer solves your problem please click Accept as Solution so others can benefit from it.
RaphaelL
Kind of a big deal
Kind of a big deal

Yes !! Exactly the same way indeed

cmr
Kind of a big deal
Kind of a big deal

I'll have a go with the next release, see what we can do.

If my answer solves your problem please click Accept as Solution so others can benefit from it.
GIdenJoe
Kind of a big deal
Kind of a big deal

I would love if they would reference internal bug tickets with details like observed behavior, software releases affected, fixed releases.

RaphaelL
Kind of a big deal
Kind of a big deal

I remember the time they "leaked" all the bugIds 

mlefebvre
Building a reputation

I prefer the way they do it now, I feel like this giant wall of text is much less readable and I would be afraid of missing things from skipping notes after I've read it for the tenth MX in a row.

RaphaelL
Kind of a big deal
Kind of a big deal

Agreed , that's why I think that grouping those changes per group would be a better idea. All changes affecting MX75,85,105,250,450 wouldn't need to be repeated in their own category

mlefebvre
Building a reputation

But the groups will not be consistent from release to release, so you might have one group in one set of release notes [MX75,85,105,250,450] and then five groups [MX75, MX85] [MX95, MX105] [MX250] [MX450] [MX67C] the next one. I would much, much rather read through the notes currently and just observe what is and isn't for me based on model info in the bullet.

The improvement I would like to see is better adherence to the naming convention of semantic versioning, getting it represented properly in the API (currently many MX versions have the wrong name), and more information about the actual bug and some sort of internal reference ID that we could refer to with Support

RWelch
Head in the Cloud

@RaphaelL I like your suggestions and agree it would make it easier (agree)!

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
KarstenI
Kind of a big deal
Kind of a big deal

I am not 100% confident that it would help as someone could get lost in the amount of text.

 

But here are my 20 cents (inflation) on this:

I assume that this data is coming somehow from a database, and each entry is internally tagged to a software release and a model. In times of HTML5, I would like to have a button list at the top with all models where I can deselect all devices that are not important to me. These buttons could be preselected based on my inventory (either of the org or, which is likely more difficult, the inventory of all orgs the user has access to).

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels