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
Best Answer
The Juniper vMX is not all that easy to set up properly. Check the documentation for a proper installation guide.
Architecture
The main thing to remember is that the vMX is actually two VMs that you need to connect with each other: the Routing Engine (virtual control plane - VCP) and the Packet Forwarding Engine (virtual forwarding plane - VFP). The architecture looks like this (from the Juniper site):
The VCP has two interfaces:
The VFP can have more interfaces:
Troubleshooting
If your ge- interfaces aren't working, then the communication between the VCP and the VFP VMs is probably the problem.
When everything's good, the ge- interfaces should show up when you do a show interfaces:
If the interfaces don't show, then you need to troubleshoot the VCP-VFP connection:
wait long enough for the VFP to boot properly (takes longer than the VCP).
try to ping the VFP from the VCP to verify :
ping 128.0.0.16 routing-instance __juniper_private1__
Try the troubleshooting steps from the Juniper site.