First, let's bang out some terminology.
DPC: Dense Port Concentrator - This is an older line card architecture, it predates MPC.
MPC: Modular Port Concentrator - This is the newer architecture for line cards, MPC's also have many "sub-architectures" as well (MPC Type 1, Type 2, etc.)
SCB: Switch Control Board - These are fabric cards, they are what connect the FPC's together.
Here's how the DPCs and SCBs fit together:
The boxes in green are the SCB's, they provide 2 fabric planes to each of the line PFE's on the line cards. DPCs/MPCs have either 1, 2, or 4 PFE's - obviously the example is assuming the DPC's have 4. Also note the 2 grey boxes, they act as spare planes should any others fail.
Juniper has a couple Knowledge Base (KB) articles that helps troubleshoot fabric problems that are a bit less obvious, this is just for future reference (I'll post them below).
Looking at the output you provided, it just looks like one of your SCB's rebooted, either by an administrator or just a potential hardware fault. If the same SCB has rebooted 2 or more times (and it wasn't an engineer intentionally rebooting it), you should open a case with JTAC and see what they have to say. You can verify why it rebooted by looking at the logs ("show log messages").
In addition to that, I see that two of the planes are offline (this corresponds to the alarm/offline planes), seeing as you have 3 SCB's, I believe you should see 6 (4 Active/2 Spare). From what I see, it appears that your 3rd SCB has been disabled, or is just down for another reason.
Plane State Uptime
0 Online 266 days, 6 hours, 43 minutes, 49 seconds ##SCB0
1 Online 266 days, 6 hours, 43 minutes, 49 seconds ##SCB0
2 Online 1465 days, 21 hours, 25 minutes, 34 seconds ##SCB1
3 Online 1465 days, 21 hours, 25 minutes, 34 seconds ##SCB1
4 Offline ##SCB2
5 Offline ##SCB2
Your original question relates to planes 4 and 5, which correspond to SCB2. The second KB article will help with this more accurately. I'd strongly advise making sure another engineer isn't working on this, or that the SCB isn't offline intentionally - if it was offlined but another engineer due to errors then turning it back online might cause problems. If you don't see any evidence that it was offlined intentionally, work through the article and see what happens.
- Resolution Guide - MX - Troubleshooting Fabric Planes
- Instructions to Offline/Online MX Fabric Plane and MX SCB
Unfortunately there are no traceoptions for SSH that I'm aware of. If you have access to a *nix machine with your SSH keys loaded, you could try connecting with:
ssh -vvv user@router
and see which keys are offered and which identities are matched.
If you're using PuTTY, then right-click on the window title and select Event Log to get similar output.
Best Answer
FPC Minor or Major errors always points to hardware errors. There are many types of Chips on FPC (MQCHIP, LUCHIP etc) depending on the FPC types. Usually due to some issue on these chips , these errors start to appear.
You could try some preliminary troubleshooting to fix the error by taking the FPC offline and then online using CLI :-
and after few seconds
If this doesn't help , technical team has to go on site to try the following things:-
(1) Make FPC 0 Offline
(2) Take FPC 0 out from the chassis for few seconds (~15) and reinsert it back into chassis.
(3) Make FPC 0 Online again and Observe the chassis alarms (show chassis alarms)
If errors still persists , then it means errors cant be removed. You will have to replace the FPC 0 with new one.