New CS 17.15.2 IOS-XE beta firmware: adaptive policy, 802.1x, NM simplification etc. Woo! 😎

cmr
Kind of a big deal
Kind of a big deal

New CS 17.15.2 IOS-XE beta firmware: adaptive policy, 802.1x, NM simplification etc. Woo! 😎

CS firmware versions IOS XE 17.15.2 changelog

Important notes

  • Please note that downgrading to CS firmware is restricted after upgrading to any Cloud-native IOS XE release. Factory reset may be required, and support assistance will be necessary. Learn more http://cs.co/9002xhAan.
  • Attempting to convert unsupported models such as C9200CX may result in an unusable switch. Please review the list of supported models in the release notes below before proceeding with the upgrade.

Cloud-native ios xe beta overview

  • The cloud-native IOS XE release introduces a significant architectural shift from the previous container-based design to a cloud-native framework. This simpler architecture unlocks many benefits for your cloud-managed Cisco Catalyst switches, including the C9300-M, C9300L-M, C9300X-M, C9200L and MS390 families. This includes faster boot and initialization performance, especially for stacks, and the start of a new generation of capabilities as we expose more underlying IOS-XE capabilities, including a Cloud CLI Terminal that introduces the ability to perform CLI commands directly from the dashboard!
  • CS16 or CS17 are prerequisites before initiating this upgrade. We do not recommend attempting to upgrade to IOS XE from other firmware versions.

Release highlights

  • Management Interface Architecture Change: removed the need for a dedicated management interface
  • Default Network Module: Simplification and consolidation of all discrete uplink port modules into 8 default ports that get applied dynamically to any inserted Network module.
  • Standardized Cisco logging and interface naming
  • Configuration Templates (note: see known issues)
  • Adaptive Policy
  • Intelligent Capture (note: see known issues)
  • C9200L Hardware Platform Support (see supported models below)
  • Storm Control
  • Radius Multi-Auth (dot1X)
  • Device Uptime
  • 802.1X Control Direction

Before you upgrade or migrate: key considerations

  • Downgrading from cloud-native IOS XE firmware is restricted: Please note that after upgrading to any Cloud-native IOS XE release, downgrading to CS firmware is restricted. Factory reset may be required, and support assistance will be necessary. Learn more at http://cs.co/9006xBRxA
  • After migrating CLI/DNA managed switches to cloud-managed mode, please note that console and SSH access are no longer available. All management access is only available via the cloud dashboard or the local status page through the rear management port.
  • After upgrading from CS to cloud-native IOS XE firmware, port mirroring configurations on module ports will not be retained. Users will need to reconfigure port mirroring on module ports following the upgrade.
  • To onboard a CLI/DNA-managed switch to the dashboard in cloud mode, claim the switch into a network already configured for cloud-native IOS XE. Claiming into a network configured for CS firmware may have unexpected results.
  • The 30-day grace period applies to Catalyst switches onboarded to Meraki Dashboard, allowing customers to trial cloud mode prior to fully committing. Valid DNA licensing can be converted to a Meraki license through a qualified promotion process. Refer http://cs.co/9005aw6VH for more details.

Share your post-upgrade feedback!

Fixed issues

  • Fixed an issue related to downstream clients may experience packet loss for 60-200 seconds in stacks while the standby switch takes over the active stack member role when the active stack member is powered off.
  • Fixed an issue related to Management plane connectivity may be interrupted when there are a large number of LLDP announcements.
  • Fixed an issue related to stacks of 5 or more switches may experience a configuration mismatch when making multiple consecutive port configuration changes to several interfaces in a row

Known issues

  • Installing C9200L firmware on C9200CX switches can cause the device to become unresponsive and will require a RMA.
  • RSTP blocking status is not showing up on the dashboard for network modules, but the status can be checked using the Show CLI/Command Runner as a temporary solution.
  • C9200Ls are not supported on Configuration Templates
  • Unable to use intelligent packet capture on the standby or member devices of a stack for C9300/MS390
  • Meraki authentication is not supported on this version.
  • Port scheduling is not supported on this version.
  • Switches upgraded to IOS XE send DHCP requests with a different identifier than switches running CS firmware. This will result in DHCP reservations not being correctly applied.
  • When upgrading from 17.15.1 to 17.15.2, some devices may lose IP and VLAN settings.
  • LACP is not functioning on the network module ports of NM-2Y modules.

Supported models

  • NOTE: ATTEMPTING TO CONVERT UNSUPPORTED MODELS SUCH AS C9200CX MAY RESULT IN A UNUSABLE SWITCH. PLEASE REVIEW THE LIST OF SUPPORTED MODELS BEFORE PROCEEDING WITH THE UPGRADE.
  • C9200L-24T-4X , C9200L-24P-4X, C9200L-48T-4X , C9200L-48P-4X , C9200L-48PL-4X , C9200L-24PXG-4X , C9200L-48PXG-4X , C9200L-24PXG-2Y , C9200L-48PXG-2Y , C9200L-24T-4G , C9200L-24P-4G , C9200L-48T-4G , C9200L-48P-4G , C9200L-48 PL-4G
  • C9300-24T-M, C9300-24P-M, C9300-24U-M , C9300-24UX-M , C9300-48T-M , C9300-48P-M , C9300-48U-M , C9300-48UXM-M , C9300-48UN-M , C9300-24S-M, C9300-48S-M , C9300X-12Y-M, C9300X-24Y-M, C9300X-48HXN-M, C9300X-24HX-M, C9300X-48HX-M, C9300X-48TX-M, C9300L-24P-4X-M, C9300L-24T-4X-M, C9300L-24UXG-4X-M, C9300L-48P-4X-M, C9300L-48PF-4X-M, C9300L-48T-4X-M, C9300L-48UXG-4X-M, and its corresponding Catalyst switch SKUs for migration
  • MS390-24-HW, MS390-24P-HW, MS390-24U-HW, MS390-24UX-HW, MS390-48-HW, MS390-48P-HW, MS390-48U-HW, MS390-48UX-HW, MS390-48UX2-HW

Transitioning from cs to ios xe 17.15: unsupported features

  • The following CS features are not supported in this release:
  • Sticky MAC
  • Encrypted Traffic Analytics (ETA)
  • Client Tracking does not work on 10G-MGig, 25G, 40G and 100G C9K ports
  • Energy Efficient Ethernet (EEE)
  • Meraki Authentication (Meraki Auth)
  • Port Schedules
  • Alternate Management Interface (AMI)
  • Geo-cloud
  • SNMPv3
  • Certain features will be added to the IOS XE versions in future releases. Refer to the Cloud-native IOS XE documentation for further details: http://cs.co/9001Q4ALF
If my answer solves your problem please click Accept as Solution so others can benefit from it.
21 Replies 21
thomasthomsen
Kind of a big deal

So far the only "problem", and I dont really see it as a problem, because, this is how I would like it to work 🙂 - but the dashboard text tells something different.

 

When you upgrade to a supported 17.15.x release, and you do your "service meraki connect" and "show meraki connect" to get all the into and the switch ready.

When you claim the serial in the dashboard, and add it to a network, the dashboard says this:

 

thomasthomsen_0-1739019195313.png

 

"Proceeding will overwrite all existing configuration". But I have never had this happen.

The switch never starts the actual conversion, I have to force it every time with the command:
"test platform software config mode managed".

 

Personally I think... this is nice, because up until then the switch actually stays in "config mode monitored", so you will actually see the switch be online in the dashboard, but in monitored mode, just the new way, instead of the old way with the onboarding app.

I really hope they keep it this way, so we can avoid using the app, and all the config it applies to the switch.

(Just like the 9800 in monitored mode).

And, of course we would like to be able ourselves to apply the "revert back command" that i guess is :
"test platform software config mode catalyst" 🙂

 

But as mentioned I have not seen any issues, on C9300 or C9200 with this new way of running native NexTunnel.

And I REALLY look forward to all the, ehhh, "normal" IOS-XE features coming here 🙂 - But I would settle for SmartPorts as the MS -> CS feature I feel I need the most.

thomasthomsen
Kind of a big deal

PS: Oh yeah .. be really patient after starting the upgrade ... REALLY REALLY patient.

Go make a cup of coffee, walk the dog, watch some paint dry , or similar activity 🙂

 

PPS: come to think of it, the only issue I have encountered is that for some reason, my C9300 stack uses the configured vlan (10 in this case) for management on IPv4, but insists on using IPv6 in vlan50 (all vlans have IPv6 available .. I have no idea why, and I cant change it 🙂 )

PhilipDAth
Kind of a big deal
Kind of a big deal

I can't get the dashboard to allow me to do this upgrade.

 

PhilipDAth_0-1739131449659.png

 

PhilipDAth_1-1739131465600.png

 

cmr
Kind of a big deal
Kind of a big deal

I'm going to try tomorrow and will post the results...

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

I finally upgraded a C9300L to this version and the experience was very good.

 

Scheduled the upgrade from the dashboard and unlike @PhilipDAth it let me go through.

14 minutes later the upgrade started being staged.

2.5 minutes later network traffic stopped traversing the switch as the MCU upgrade started.

30 seconds later the switch rebooted (soft boot, no fans going loud etc.)

3 minutes 18 seconds later the switch entered Meraki mode according to the console

30 seconds later the switch started passing traffic again.

 

In total 4 minutes and 18 seconds of downtime for an upgrade 😎

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

Interestingly here is the console from before the upgrade:

 

Switch 1 has been registered


Booting in Meraki mode

Switch                         Serial                                                                          Migr
Num PID                      Number            Cloud ID                 Mac Address    Stat
--------------------------------------------------------------------------------
1 C9300L-24UXG-4X FVH0000XXXF Q5XX-XXXX-XXVS c4xx:xxxx:xxxx Regi
Starting Meraki app...


service meraki connect is enabled.


Meraki app is up and connecting to Dashboard ...

 

And after:

 

Switch 1 has been registered


Booting in Meraki mode

Switch                         Serial                                                                             Migration
Num PID                      Number            Cloud ID                 Mac Address       Status         Mode
-----------------------------------------------------------------------------------------------
1 C9300L-24UXG-4X FVH0000XXXF Q5XX-XXXX-XXVS c4xx:xxxx:xxxx Registered C9K-M

Please go to dashboard.meraki.com to manage above device(s).
You can locate the device(s) on the Meraki Dashboard using the Cloud ID(s).

Starting Meraki app...


service meraki connect is enabled.


Meraki app is up and connecting to Dashboard ...
Local status page is available ...

 

The Meraki mode table is somewhat more informative and the local status page is new...

If my answer solves your problem please click Accept as Solution so others can benefit from it.
JeroenVercoulen
Getting noticed

I tried to upgrade to a stack of 2  C9300-48P running CS17.1.4 to this version, but this upgrade failed.

Maybe good to know the uplink is an LACP channel on te modular 8x module

Anybody seen this issue also?

JeroenVercoulen
Getting noticed

Disabled LACP first and did the upgrade after. Now it was successful.

PhilipDAth
Kind of a big deal
Kind of a big deal

Wow.

cmr
Kind of a big deal
Kind of a big deal

I had LACP configured on the C9300L I upgraded from the first beta to this version and that worked.

 

Edit: reread post above!

If my answer solves your problem please click Accept as Solution so others can benefit from it.
JeroenVercoulen
Getting noticed

Still have the same issue. Tried to upgrade 2 C9300-48P and 2 C9300-48T from CS 17.1.4 to this version.

No LACP configured. Getting the messages below. It takes about 2 hours before they come online again.

 

 

facility: DASHBOARD_IMG_MGMT, severity: 5, type: INSTALL, msg: Dashboard Upgrade Final Status - failed

facility: DASHBOARD_IMG_MGMT, severity: 5, type: INSTALL, msg: Dashboard received an Image Upgrade Request

 

JeroenVercoulen
Getting noticed

Found out the the new firmware is probably using other connectivity methods to the Meraki Dashboard. Haven't checked what is different exact but when connecting on the limited guest network with firmware CS 17.1.4 everything was working after the upgrade there was no connectivity to the Meraki Dashboard so the application wouldn't start. I did now send this data a different way to a VPN tunnel via the HUB and everything was working.

JeroenVercoulen
Getting noticed

I'm now running a nice stack of 4 C9300-48 perfectly. Now you can also easily find out what cli commands are used the configure an trunk port in the Meraki Dashboard. This makes it easy to create the correct port settings for devices not in the Meraki Dashboard for configuration.

thomasthomsen
Kind of a big deal

I just did some 17.15.1m1 (the EFT release of native NexTunnel) to this official release with some ehhh mixed results.

 

A 9200L stand alone, no problems, upgraded as expected, nothing to see here 🙂

 

A 9300L stack uh oh .. this was a little "wonky".

The Switch seemed to upgrade just fine, and the equipment connected to the switch (APs, cameras, and clients) came online just fine and the whole thing was down for about perhaps 6 minutes.

BUT ... the switch itself never got back online on the dashboard.

So this was kinda strange to me, because as far as I know the new UAC feature and so on should "just work(tm)".

 

With everything working, except the switch not being online in the dashboard, i created a case, and went to bed.

This morning the switch IS online again, and the uptime graph looks like this.

 

thomasthomsen_0-1742369476128.png

Thats kinda strange right.

 

So of course there is some differences here versus the stand alone C9200L.

This was a C9300L stack, and this stack was setup with a static IP instead of DHCP, but that should of course not matter.

 

Im currently looking at logs to see if I can figure out what happened 🙂

thomasthomsen
Kind of a big deal

So from the log ...

At around 22:30 , this is where i tell it to schedule the upgrade at 23:00, start upgrading and finish the upgrade.

 

I have just collected the complete thing here, and omitted irrelevant things from the log, I have not analyzed it yet

 

Mar 19 02:52:24 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Dashboard Upgrade Final Status - upgraded
Mar 19 02:52:24 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Image Install Commit Completed
<some output omitted>
Mar 19 02:51:29 sw01.lyst [2] INSTALL 5 INSTALL_COMPLETED_INFO Switch 2 R0/0: install_mgr: Completed install commit
Mar 19 02:51:25 sw01.lyst [2] NDBMAN 5 MODEL_RPC_I Switch 2 R0/0: ndbmand: RPC 'http://cisco.com/ns/yang/Cisco-IOS-XE-install-rpc:install-commit' invoked from fd0a:9b09:1f7:1:248e:d42e:f6b6:9ae1:35190 via NETCONF user meraki-user session 28
<some output omitted>
Mar 19 02:51:24 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Starting Image Install Commit
<some output omitted>
Mar 19 02:49:48 sw01.lyst [2] RF 5 RF_TERMINAL_STATE Terminal state reached for (SSO)
Mar 19 02:49:47 sw01.lyst [2] HA_CONFIG_SYNC 6 BULK_CFGSYNC_SUCCEED Bulk Sync succeeded
Mar 19 02:49:44 sw01.lyst [2] PKI 6 AUTHORITATIVE_CLOCK The system clock has been set.
<some output omitted>
Mar 19 02:49:27 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Image Install Activate Completed
<some output omitted>
Mar 19 02:48:37 sw01.lyst [2] REDUNDANCY 5 PEER_MONITOR_EVENT Active detected a standby insertion (raw-event=PEER_REDUNDANCY_STATE_CHANGE(5))
Mar 19 02:48:36 sw01.lyst [2] REDUNDANCY 5 PEER_MONITOR_EVENT Active detected a standby insertion (raw-event=PEER_FOUND(4))
Mar 19 02:48:27 sw01.lyst [2] STACKMGR 6 STANDBY_ELECTED Switch 2 R0/0: stack_mgr: Switch 1 has been elected STANDBY.
Mar 19 02:48:26 sw01.lyst [2] IOSXE_REDUNDANCY 6 PEER Active detected switch 1 as standby.
<some output omitted>
Mar 19 02:48:26 sw01.lyst [2] IOSXE_REDUNDANCY 6 PEER Active detected switch 1 as standby.
<some output omitted>
Mar 19 02:43:15 sw01.lyst [2] INSTALL 5 INSTALL_COMPLETED_INFO Switch 2 R0/0: install_mgr: Completed install activate
<some output omitted>
Mar 19 02:40:08 sw01.lyst [2] INSTALL 5 INSTALL_AUTO_ABORT_TIMER_PROG* Switch 2 R0/0: install_mgr: Install auto abort timer will expire in 7200 seconds
Mar 19 02:39:48 sw01.lyst [2] INSTALL 5 INSTALL_AUTO_ABORT_TIMER_PROG* Switch 1 R0/0: install_mgr: Install auto abort timer will expire in 7200 seconds
Mar 19 02:39:27 sw01.lyst [2] CRIMSON 3 DATABASE_MEMLEAK Database memory leak detected in /tmp/rp/tdldb/0/IOS_PRIV_OPER_DB database, Basic type/No extension/N/A size:32 byte, callsite: C2E89FA4402A8017
Mar 19 02:37:33 sw01.lyst [2] NDBMAN 5 MODEL_RPC_I Switch 2 R0/0: ndbmand: RPC 'http://cisco.com/ns/yang/Cisco-IOS-XE-install-rpc:activate' invoked from fd0a:9b09:1f7:1:ceb:c403:d49b:d786:60746 via NETCONF user meraki-user session 34
Mar 19 02:37:32 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Starting Image Install Activate
<some output omitted>
Mar 19 02:34:27 sw01.lyst [2] CRIMSON 3 DATABASE_MEMLEAK Database memory leak detected in /tmp/rp/tdldb/0/IOS_PRIV_OPER_DB database, Basic type/No extension/N/A size:32 byte, callsite: C2E89FA4402A8017
Mar 19 02:29:27 sw01.lyst [2] CRIMSON 3 DATABASE_MEMLEAK Database memory leak detected in /tmp/rp/tdldb/0/IOS_PRIV_OPER_DB database, Basic type/No extension/N/A size:32 byte, callsite: C2E89FA4402A8017
Mar 19 02:24:27 sw01.lyst [2] CRIMSON 3 DATABASE_MEMLEAK Database memory leak detected in /tmp/rp/tdldb/0/IOS_PRIV_OPER_DB database, Basic type/No extension/N/A size:32 byte, callsite: 811459B41BAF0013
Mar 19 02:19:27 sw01.lyst [2] CRIMSON 3 DATABASE_MEMLEAK Database memory leak detected in /tmp/rp/tdldb/0/IOS_PRIV_OPER_DB database, Basic type/No extension/N/A size:32 byte, callsite: 811459B41BAF0013
Mar 19 02:14:27 sw01.lyst [2] CRIMSON 3 DATABASE_MEMLEAK Database memory leak detected in /tmp/rp/tdldb/0/IOS_PRIV_OPER_DB database, Basic type/No extension/N/A size:32 byte, callsite: 811459B41BAF0013
Mar 19 02:10:37 sw01.lyst [2] CRYPTO_ENGINE 4 CSDL_COMPLIANCE_RSA_WEAK_KEYS RSA keypair CISCO_IDEVID_CMCA_SUDI is in violation of Cisco security compliance guidelines and will be rejected.
Mar 19 02:09:27 sw01.lyst [2] CRIMSON 3 DATABASE_MEMLEAK Database memory leak detected in /tmp/rp/tdldb/0/IOS_PRIV_OPER_DB database, Basic type/No extension/N/A size:32 byte, callsite: 811459B41BAF0013
<some output omitted>
Mar 19 02:04:27 sw01.lyst [2] CRIMSON 3 DATABASE_MEMLEAK Database memory leak detected in /tmp/rp/tdldb/0/IOS_PRIV_OPER_DB database, Basic type/No extension/N/A size:32 byte, callsite: 811459B41BAF0013
Mar 19 01:59:27 sw01.lyst [2] CRIMSON 3 DATABASE_MEMLEAK Database memory leak detected in /tmp/rp/tdldb/0/IOS_PRIV_OPER_DB database, Basic type/No extension/N/A size:32 byte, callsite: 811459B41BAF0013
Mar 19 01:54:27 sw01.lyst [2] CRIMSON 3 DATABASE_MEMLEAK Database memory leak detected in /tmp/rp/tdldb/0/IOS_PRIV_OPER_DB database, Basic type/No extension/N/A size:32 byte, callsite: 811459B41BAF0013
Mar 19 01:49:27 sw01.lyst [2] CRIMSON 3 DATABASE_MEMLEAK Database memory leak detected in /tmp/rp/tdldb/0/IOS_PRIV_OPER_DB database, Basic type/No extension/N/A size:32 byte, callsite: 811459B41BAF0013
Mar 19 01:45:25 sw01.lyst [2] INSTALL 5 INSTALL_COMPLETED_INFO Switch 2 R0/0: install_mgr: Completed install add flash:/switch-iosxe-c9k-V1715_2M1_FC5
Mar 19 01:45:25 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Image Install Add Completed
<some output omitted>
Mar 19 01:44:27 sw01.lyst [2] CRIMSON 3 DATABASE_MEMLEAK Database memory leak detected in /tmp/rp/tdldb/0/IOS_PRIV_OPER_DB database, Basic type/No extension/N/A size:32 byte, callsite: 811459B41BAF0013
Mar 19 01:42:26 sw01.lyst [2] NDBMAN 5 MODEL_RPC_I Switch 2 R0/0: ndbmand: RPC 'http://cisco.com/ns/yang/Cisco-IOS-XE-install-rpc:install' invoked from fd0a:9b09:1f7:1:4217:6160:e475:bc3d:44004 via NETCONF user meraki-user session 31
<some output omitted>
Mar 19 01:42:26 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Starting Image Install Add
Mar 19 01:42:26 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Image Download Completed
<some output omitted>
Mar 19 01:40:46 sw01.lyst [2] FMFP 3 OBJ_DWNLD_TO_DP_STUCK Switch 1 F0/0: fman_fp_image: AOM download to Data Plane is stuck for more than 1800 seconds due to resolve object: obj[293] type[32] 'Void Intf (6)', resulting in it being a pending-issue object
Mar 19 01:40:44 sw01.lyst [2] FMFP 3 OBJ_DWNLD_TO_DP_STUCK Switch 2 F0/0: fman_fp_image: AOM download to Data Plane is stuck for more than 1800 seconds due to resolve object: obj[310] type[32] 'Void Intf (6)', resulting in it being a pending-issue object
Mar 19 01:39:27 sw01.lyst [2] CRIMSON 3 DATABASE_MEMLEAK Database memory leak detected in /tmp/rp/tdldb/0/IOS_PRIV_OPER_DB database, Basic type/No extension/N/A size:32 byte, callsite: C2E89FA4402A8017
<some output omitted>
Mar 19 01:36:33 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Starting Image Download
Mar 19 01:36:31 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Image Install Clean Completed
<some output omitted>
Mar 19 01:35:33 sw01.lyst [2] INSTALL 5 INSTALL_COMPLETED_INFO Switch 2 R0/0: install_mgr: Completed install remove
Mar 19 01:35:33 sw01.lyst [2] NDBMAN 5 MODEL_RPC_I Switch 2 R0/0: ndbmand: RPC 'http://cisco.com/ns/yang/Cisco-IOS-XE-install-rpc:remove' invoked from fd0a:9b09:1f7:1:4854:582e:3de2:e6c4:33638 via NETCONF user meraki-user session 28
Mar 19 01:35:32 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Starting Image Install Clean
<some output omitted>
Mar 19 01:35:31 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Dashboard is initiating Image Upgrade version_name-switch-iosxe-c9k-V1715_2M1_FC5
Mar 19 01:34:08 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Dashboard received an Image Upgrade Request version_name-switch-iosxe-c9k-V1715_2M1_FC5
<some output omitted>
Mar 19 01:34:05 sw01.lyst [2] PKI 6 AUTHORITATIVE_CLOCK The system clock has been set.
<some output omitted>
Mar 18 23:32:35 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Dashboard Upgrade Final Status - unreachable
Mar 18 23:32:35 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Image Install failed - Device is unreachable
Mar 18 23:05:47 sw01.lyst [2] INSTALL 5 INSTALL_COMPLETED_INFO Switch 2 R0/0: install_mgr: Completed install activate
<some output omitted>
Mar 18 23:02:39 sw01.lyst [2] INSTALL 5 INSTALL_AUTO_ABORT_TIMER_PROG* Switch 2 R0/0: install_mgr: Install auto abort timer will expire in 7200 seconds
Mar 18 23:02:17 sw01.lyst [2] INSTALL 5 INSTALL_AUTO_ABORT_TIMER_PROG* Switch 1 R0/0: install_mgr: Install auto abort timer will expire in 7200 seconds
<some output omitted
Mar 18 23:00:02 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Starting Image Install Activate
<some output omitted
Mar 18 22:43:18 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Image Install Add Completed
<some output omitted>
Mar 18 22:37:24 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Starting Image Install Add
Mar 18 22:37:23 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Image Download Completed
<some output omitted>
Mar 18 22:31:31 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Starting Image Download
Mar 18 22:31:28 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Image Install Clean Completed
<some output omitted>
Mar 18 22:30:32 sw01.lyst [2] INSTALL 5 INSTALL_COMPLETED_INFO Switch 2 R0/0: install_mgr: Completed install remove
<some output omitted>
Mar 18 22:30:31 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Starting Image Install Clean
<some output omitted>
Mar 18 22:30:29 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Dashboard is initiating Image Upgrade version_name-switch_combo_4311_4429
Mar 18 22:29:44 sw01.lyst [2] DASHBOARD_IMG_MGMT 5 INSTALL Dashboard received an Image Upgrade Request version_name-switch_combo_4311_4429

 

thomasthomsen
Kind of a big deal

Oh ..-- and also this line on "top".

Mar 19 03:17:17 sw01.lyst [2] FMFP 3 OBJ_DWNLD_TO_DP_STUCK Switch 1 F0/0: fman_fp_image: AOM download to Data Plane is stuck for more than 1800 seconds due to resolve object: obj[304] type[32] 'Void Intf (6)', resulting in it being a pending-issue object

 

For the outage at around 5:15 to 5:18 CET there is no log .. so who knows what happened there 🙂

 

From my very quick look at the logs, it failed the upgrade, and the 7200 second auto abort kicked in.

Then it did a new install, some "DATABASE_MEMLEAK" happened, but it completed, both switches got back and the found out they where in a stack, and it did "commit". - So "success".... I guess 🙂

But what happened at 5:15 where it was offline, I cannot tell you from the logs, because there is no log from thie period of time.

thomasthomsen
Kind of a big deal

I can hardly wait to upgrade the next stack ... a real thrill ride 🙂

thomasthomsen
Kind of a big deal

PS: Since the device uptime is now around 7 hours, the dashboard outage from 5:15 to 5:18 was not due to the switch reloading ... I have no idea what happened there.

Could in theory have been something else.

thomasthomsen
Kind of a big deal

Hmmmm the switch might have had some problems (speculation at this point) with the static IPv4 address it had before the upgrade.

After the upgrade (and I only looked at it now) it had a strange 198.x.x.x IP as "LAN" (not anything we have configured anywhere), and it had a IPv6 (we run dual stack) and it was using the IPv6 address.

Speculation : could this be caused by the new way that static IPs are configured on a Catalyst switch (now under DHCP and routing ?), perhaps ?

I have "re-saved" the config that was on that page, and now the switch has its IPv4 address just fine.

(The IPv6 one did now not work , for some reason now, but Ill play around with it some more 🙂 )

thomasthomsen
Kind of a big deal

PPS: Im also super happy that the switch now apparently have a whole bunch of static IPv6 routes to China.

(there are also some other ones that I can lookup to Meraki ... fx. 2606:7BC0::/32 hot dangit thats a lot of IPs).

 

S 2402:1440:40:100::/64 [1/0], tag 2896997548
via FE80::AA46:9DFF:FEB6:2137, Vlan10
S 2402:1440:40:115::/64 [1/0], tag 2896997548
via FE80::AA46:9DFF:FEB6:2137, Vlan10
S 2402:1440:40:531::/64 [1/0], tag 2896997548
via FE80::AA46:9DFF:FEB6:2137, Vlan10
S 2408:8706:0:1281::/64 [1/0], tag 2896997548
via FE80::AA46:9DFF:FEB6:2137, Vlan10
S 2408:8706:0:1282::/64 [1/0], tag 2896997548
via FE80::AA46:9DFF:FEB6:2137, Vlan10

 

Im GUESSING that these are the IPs used in Merakis Chinese DC ?

But I do not know 🙂

 

thomasthomsen
Kind of a big deal

The switch was apparently not happy with my IPv6 config.

"Router FE80::AA46:9DFF:FEB6:2137 on Vlan10 conflicting ND setting prefix somethinsomething::/64 valid lifetime, difference 2586600 seconds"

I have no idea what this means 🙂

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco ID. If you don't yet have a Cisco ID, you can sign up.
Labels