PTX10001-36mr Junos: 22.2R3-S2.5-EVO reporting the following messages after a link flap.
kernel: %KERN-4: [ttp_encap_xmit:1207] JTD Cache skb failed
After link flap, JTD Cache skb failed messages are seen. mib2d[15824]: %DAEMON-4-SNMP_TRAP_LINK_DOWN: ifIndex 528, ifAdminStatus up(1), ifOperStatus down(2), ifName et-0/2/4 mib2d[15824]: %DAEMON-4-SNMP_TRAP_LINK_DOWN: ifIndex 531, ifAdminStatus up(1), ifOperStatus down(2), ifName et-0/2/5 mib2d[15824]: %DAEMON-4-SNMP_TRAP_LINK_DOWN: ifIndex 604, ifAdminStatus up(1), ifOperStatus down(2), ifName ae12 rpd[17115]: %DAEMON-4-RPD_RSVP_NBRDOWN: RSVP neighbor x.x.x.x down on interface ae12.0 nbr-type Direct, triggered by IGP neighbor down event ifmand[14826]: %USER-3-IFMAND_SPEED_BW_ERROR: UpdateLinkState: bundle ae12: bundle IFD minimum bandwidth or minimum links not met,Bandwidth (Current : Required) 0 : 1 Number of links (Current : Required) 0 : 1 kernel: %KERN-4: [ttp_encap_xmit:1207] JTD Cache skb failed kernel: %KERN-4: [ttp_encap_xmit:1207] JTD Cache skb failed rpd[17115]: %DAEMON-4-RPD_RSVP_BACKUP_DOWN: Backup for protecting LSP Jnrp down, using bypass Bypass->x.x.x.x->x.x.x.x, reason: Deleting protected LSP mib2d[15824]: %DAEMON-4-SNMP_TRAP_LINK_DOWN: ifIndex 528, ifAdminStatus up(1), ifOperStatus down(2), ifName et-0/2/4 mib2d[15824]: %DAEMON-4-SNMP_TRAP_LINK_DOWN: ifIndex 531, ifAdminStatus up(1), ifOperStatus down(2), ifName et-0/2/5 mib2d[15824]: %DAEMON-4-SNMP_TRAP_LINK_DOWN: ifIndex 604, ifAdminStatus up(1), ifOperStatus down(2), ifName ae12 rpd[17115]: %DAEMON-4-RPD_RSVP_NBRDOWN: RSVP neighbor x.x.x.x down on interface ae12.0 nbr-type Direct, triggered by IGP neighbor down event ifmand[14826]: %USER-3-IFMAND_SPEED_BW_ERROR: UpdateLinkState: bundle ae12: bundle IFD minimum bandwidth or minimum links not met,Bandwidth (Current : Required) 0 : 1 Number of links (Current : Required) 0 : 1 kernel: %KERN-4: [ttp_encap_xmit:1207] JTD Cache skb failed
The SWERR in question will arise when an application starts sending data on a newly established TCP connection before JTD has been provisioned with the required TCP flow information by FIBD (FIBDv1)/nsagentd (FIBDv2)+ADs- this is not a bug but a perfectly feasible timing-related situation which will simply result in the outgoing packet being dropped (TCP will subsequently retransmit it). So there is no actual bug here other than the SWERR. From 22.3-EVO onwards, a series of changes were made to phase out logs and move to error/non-error based statistics.