During a production change, MTU was increased from 1514 to 9192 on part of the path. When traffic was shifted away from and back to the device, a small amount of short-lived packet loss was observed, along with a temporary spike in CPU. Review of the logs and RSI indicates the packet loss was more consistent with reconvergence during the traffic shift than with the switch dropping transit traffic because of CPU exhaustion. The RSI also did not show forwarding-plane drops or output MTU errors at the time of collection. 

• Brief packet loss, typically less than 1%, during traffic move or failback.
• Temporary CPU spike during the same window.
• LACP member links on ae10 changing state and the bundle briefly falling below minimum links.
• OSPF neighbors on ae10.0 going from Full to Down because the interface went down.
• Some links in the path still operating with MTU 1514 while the MTU rollout to 9192 was in progress.   

Recommendations:

• Make the MTU change end-to-end before shifting traffic back through the path.
• Do not combine the MTU rollout and traffic move in the same step when possible.
• Validate the path with jumbo Don't Fragment ping testing before returning the device to service.
• During the change window, avoid extra operational load such as repeated diagnostics if not required.

Logs like PFE_ERROR_FAIL_OPERATION: CPROD: Couldn't write "IPC" message to pipe were seen in logs, but based on the data reviewed they do not appear to be the primary cause of the packet loss.