The "PRB_EVENERR or PRB_ODDERR" message is likely caused caused by a transient hardware issue in the unload block of EACHIP or XLCHIP. This is a Troubleshooting Article for a PFE ASIC Syslog Event. To view other documented syslog events related to XMCHIP, XLCHIP, MQCHIP, LUCHIP, EACHIP, and PECHIP, see KB31893 - Master Index of Articles for Troubleshooting PFE ASIC Syslog Events [juniper.net] .
When a "PRB_EVENERR or PRB_ODDERR" event occurs messages similar of the following are reported: EACHIP:
Aug 28 16:07:45.602 router: %PFE-3: fpc8 EA[0:0].unload[1]: PRB_EVENERR 01 Aug 28 16:07:46.601 router: %PFE-3: fpc8 EA[0:0].unload[1]: PRB_ODDERR 03
XLCHIP:
Sep 6 16:31:14.183 router : %PFE-3: fpc10 XL[0:0].unload[0]: PRB_EVENERR 07 Sep 6 16:31:14.200 router : %PFE-3: fpc10 XL[0:0].unload[0]: PRB_ODDERR 02
The following syslog entries upon unload parity errors are reported:
Aug 28 10:42:00.894 router : %PFE-3: fpc10 XMCHIP(1): XMCHIP(1): LI0: Received a parcel from the HSL2 interface with EOPE or Aug 28 16:07:45.598 router : %PFE-3: fpc8 MQSS(0): LI-1: Received a parcel from the HSL2 interface with EOPE
Aug 28 10:42:00.894 router : %PFE-3: fpc10 XMCHIP(1): XMCHIP(1): LI0: Received a parcel from the HSL2 interface with EOPE or
Aug 28 16:07:45.598 router : %PFE-3: fpc8 MQSS(0): LI-1: Received a parcel from the HSL2 interface with EOPE
As a post effect, fabric-self ping blackholing will trigger an alarm upon failure on the fabric side. Host-loopback wedge detection will trigger an alarm if the WAN side is affected. HSL2 with EOPE means the parcel received from the high-speed link was marked with “end of parcel with error” bit. This is not an indication that the high-speed link is not stable, but rather the unload block had marked the parcel with an error-bit. Indications:
PFE wedge will be detected and traffic forwarding is compromised
Alarm will be raised
This error is caused by a transient SRAM parity error. The Unload block is processed once all lookup is finished and the parcel is about to get sent to the Center Chip XMCHIP or EACHIP. In all cases, these parity errors cause a wedge for the corresponding XMCHIP or EACHIP
{DIDYOUKNOWSERVICENOWTOKEN.EN_US} Perform these steps to determine the cause and resolve the problem (if any). Continue through each step until the problem is resolved.
Collect the show command output.
Capture the output to a file (in case you have to open a technical support case). To do this, configure each SSH client/terminal emulator to log your session.
show log messages show log chassisd start shell network pfe <fpc#> show nvram show syslog messages exit
Analyze the show command output.
In the 'show log messages', review the events that occurred at or just before the appearance of the "PRB_EVENERR or PRB_ODDERR" message. Frequently these events help identify the cause.
No RMA required.
The generic pfe-disable event script will detect the wedge condition that happens as a result of this event and invoke the pfe-disable action; see KB31867 - Generic pfe-disable Event Script [juniper.net] . A FPC restart at a later time is needed to bring the PFE back into service.
Perform FPC restart to recover.
Contact your technical support representative if the issue is seen after a FPC restart .
This article is indexed in KB31893 - Primary Index of Articles for Troubleshooting PFE ASIC Syslog Events [juniper.net] ; tag EACHIPTSG XLCHIPTSG
10/8/2024 : dconejomora - adding MX960 in the KB categories, changing visibility to Internal, Partner and Customer