This document explains log message "fpcX ttrace_single_step(4625): Uninitialized NH at VA 0x477690 jnh_app 0x00090000 PA 0x41477690" and "ppe_error_interrupt" and how to resolve the same.

• We see below logs on FPC post applying changes made in Access-list:

Apr 30 08:34:14 LAB_RE0 fpc2 ttrace_single_step(4625): Uninitialized NH at VA 0x477690 jnh_app 0x00090000 PA 0x41477690. 
Apr 30 08:34:14 LAB_RE0 fpc2 ttrace_single_step(4625): Uninitialized NH at VA 0x060007 jnh_app 0x00010000 PA 0xfc460007. 
Apr 30 08:34:14 LAB_RE0 fpc2 ttrace_single_step(4625): Uninitialized NH at VA 0x477690 jnh_app 0x00090000 PA 0x41477690. 
Apr 30 08:34:14 LAB_RE0 fpc2 ttrace_single_step(4625): Uninitialized NH at VA 0x060007 jnh_app 0x00010000 PA 0xfc460007. 
Apr 30 08:34:14 LAB_RE0 fpc2 cassxr_err_addr(9935): Uninitialized Read Error @ EDMEM[0xfc460007] 
Apr 30 08:34:14 LAB_RE0 fpc2 ppe_error_interrupt(5538): EA[3:0]_PPE 72 Errors sync xtxn error 
Apr 30 08:34:14 LAB_RE0 fpc2 ppe_error_interrupt(5538): EA[3:0]_PPE 73 Errors sync xtxn error 
Apr 30 08:38:14 LAB_RE0 fpc2 cassxr_err_addr(9861): EA[3:0].cass_xr[0] ext_mdata 0x4f != err_mdata 0x24 (cae 0, ext_addr 0x23007) 
Apr 30 08:38:14 LAB_RE0 fpc2 ppe_error_interrupt(5538): EA[3:0]_PPE 51 Errors sync xtxn error 
Apr 30 08:38:14 LAB_RE0 fpc2 ppe_error_interrupt(5538): EA[3:0]_PPE 24 Errors sync xtxn error 
Apr 30 08:38:14 LAB_RE0 fpc2 ppe_error_interrupt(5538): EA[3:0]_PPE 25 Errors sync xtxn error 
Apr 30 08:38:14 LAB_RE0 fpc2 ppe_error_interrupt(5538): EA[3:0]_PPE 26 Errors sync xtxn error 
Apr 30 08:38:14 LAB_RE0 fpc2 ppe_error_interrupt(5538): EA[3:0]_PPE 27 Errors sync xtxn error 
Apr 30 08:38:14 LAB_RE0 fpc2 ppe_error_interrupt(5538): EA[3:0]_PPE 0 Errors sync xtxn error 
Apr 30 08:38:14 LAB_RE0 fpc2 ppe_error_interrupt(5538): EA[3:0]_PPE 1 Errors sync xtxn error 
Apr 30 08:38:14 LAB_RE0 fpc2 ppe_error_interrupt(5538): EA[3:0]_PPE 2 Errors sync xtxn error 
Apr 30 08:38:14 LAB_RE0 fpc2 ppe_error_interrupt(5538): EA[3:0]_PPE 3 Errors sync xtxn error 

• Prolonged Exposure can also cause packet loop condition on the PFE which made the PFE busy leading to fabric self-ping failure condition, thereby disabling the PFE.

Apr 25 07:33:09 LAB_RE0 fpc2 Performing action cmalarm for error /fpc/2/pfe/0/cm/0/CM[0]/0/CM_CMERROR_FABRIC_SELFPING (0x2e0006) in module: CM[0] with scope: pfe category: functional level: major, oc_category: default
Apr 25 07:33:09 LAB_RE0 fpc2 Performing action disable-pfe for error /fpc/2/pfe/0/cm/0/CM[0]/0/CM_CMERROR_FABRIC_SELFPING (0x2e0006) in module: CM[0] with scope: pfe category: functional level: major, oc_category: default
Apr 25 07:33:09 LAB_RE0 fpc2 PFE 0: 'PFE Disable' action performed. Bringing down ifd et-2/0/0 278
Apr 25 07:33:09 LAB_RE0 fpc2 PFE 0: 'PFE Disable' action performed. Bringing down ifd et-2/0/1 279

• On MX platform, when the FLT(fast-lookup-filter) which is used to match traffic and apply an action if this statement is configured with a match that is not supported in the FLT(fast-lookup-filter) hardware, traffic might be lost.
• The FLT(fast-lookup-filter) filters with HYBRID matches need different XTXN hence the response type for FLT Transaction needs to be set properly for Hybrid Filters.

firewall {
    family inet
      filter TEST {
                  fast-lookup-filter;

}

}

TRIGGERS

This issue might be seen if the following conditions are met:

• On all MX platform
• If FLT match statements are not configured properly.

Workaround: Remove fast-lookup-filter knob from the filter.

Solution: Upgrade to a version with Fix PR: https://prsearch.juniper.net/problemreport/PR1573350 

Refer PR: https://prsearch.juniper.net/problemreport/PR1573350 for more information