Update 10/31: For those experiencing problems playing this video: The Cisco Support Forum's video player requires both flash and 3rd party cookies. If you are experiencing problems with the video not showing up, please ensure flash is installed and enabled, and that 3rd party cookies are not disabled through your browser settings or a browser extension.
This video provides a demonstration of the steps needed to migrate the hardware and software components of a Cisco ISR4300 Series Router as an aide for users who are doing proactive replacements of their Cisco ISR4300 Series Routers for the FN 64253 Clock Signal Field Notice.
Introduction - 0:00 Checking for what hardware needs to be migrated - 0:34 Backing up Software Components - 2:23 Backing Up ISR Image - 2:25 Backing Up Image to USB - 2:49 Backing Up Image to Remote Server - 4:08 Backing up Serial Number for License Re-Hosting - 5:24 Backing Up Configuration - 5:56 Unracking ISR4300 - 7:07 Hardware Migration - 7:22 Removing Hardware Components from Old Chassis - 7:25 Removing NIMs (Network Interface Modules) and SMs (Service Modules) - 7:27 Removing External Modules - 7:29 - 8:18 Removing Power Supply in a ISR4351 Removing ISR4351 POE Module - 8:34 Re-Installing ISR4351 Front Cover - 9:22 Opening ISR4300 Chassis - 9:54 Opening ISR4321 Chassis - 9:57 Opening ISR4331 Chassis - 10:34 Opening ISR4351 Chassis - 11:11 R emoving Internal Hardware Components - 11:35 Removing DRAM - 11:37 Removing Internal Flash 11:55 Removing Internal SSD - 12:24 Removing PVDM - 12:52 Internal Hardware Component Locations in ISR4331 - 13:21 Removing ISR4331 POE Power Supply - 13:44 Removing ISR4351 Internal POE GigabitEthernet Daughter card - 14:39 Re-Installing Hardware Components into Replacement Chassis - 15:16 Re-Installing Internal Hardware Components - 15:18 Re-Installing DRAM - 15:20 Re-Installing Internal Flash - 15:44 Re-Installing internal SSD - 16:08 Re-Installing PVDM - 16:32 Re-Installing ISR4331 POE Power Supply - 17:00 Re-Installing ISR4351 Internal POE GigabitEthernet Daughter card - 18:45 Re-Installing External Modules - 19:41 Re-Installing NIMs and SMs - 19:43 Re-Installing ISR4351 POE Module - 20:03 Re-Installing ISR4351 Power Supply - 20:57 Restoring Software Components to new ISR - 21:09 Restoring Image - 21:11 Rehosting License - 22:12 Restoring Configuration - 25:04 Conclusion - 26:19 Credits - 26:44
... View more
It looks like the commit to 15,1(4)M throttle wasn't done. If you are in need of getting it fixed for M8, it would be best to open a TAC case so the TAC engineer can follow up with development to make sure the fix gets committed into 15.1(4)M8.
... View more
Yes, I have updated the release notes of CSCto56317 to describe the input queue leak/wedge issue. Your comment about moving to a version where CSCto56317 is already fixed is also good, but unfortunately the 1841 can't run 15.2(1)T or later where CSCto56317 is already present. If Andrea is seeing this on an ISR-G2 instead of a ISR like Chris is, it is an option. CSCto56317 CSCto56317
... View more
Hi Chris and Andrea, Thanks for testing the various versions. I was able to reproduce the issue in order to investigate further. Here's what I have been able to figure out: The input queue leak was introduced by the fix for CSCtn36227 Alignment correction at ipv6_checksum with IPv6 ping sweep it is fixed via CSCto56317 Backward compatibility regarding pak release strategy in ipv6_ping_send CSCto56317 was committed into 15.2(1)T, but was never committed into the 15.1(4)M throttle. I have put in a request to get CSCto56317 fixed in 15.1(4)M throttle. The next potential release that can get the fix is 15.1(4)M7 which is due out in October. Please note that CSCto56317 is currently an internal defect. I will be making it external, but it may take a day or two for that change to propogate. Unfortunately, I don't see an easy workaround to prevent the input leak in the meantime. Given that you decided to move back to 15.1(4)M3, I would assume ip sla is a required feature for you both. Another option would be to modify the frequency of the sla icmps and/or then increase the size of the input hold queue (hold-queue 24000 in) to allow more time before the input queue filled up. Changing the frequency from 1 min to 5 minutes and increasing the hold queue to 24000 should allow the device to go ~83 days before needing a reload to clear the input queue.
... View more