This article explains the meaning of the " CB fabrics are of mixed types " major alarm that is seen on MX Series devices and provides the troubleshooting steps to clear the same.
CB fabrics are of mixed types
Active Alarm
user@host> show chassis alarms no-forwarding 3 alarms currently active Alarm time Class Description 2020-01-23 17:36:14 UTC Minor CB 2 Fabric Chip 1 Not Online 2020-01-23 17:36:14 UTC Minor CB 2 Fabric Chip 0 Not Online 2020-01-23 17:35:43 UTC Major CB fabrics are of mixed types
The CB fabric - mixed types alarm results in the CB Fabric chip going offline.
Error Logs
Jan 23 17:35:43 alarmd[6724]: %DAEMON-4: Alarm set: CB color=RED, class=CHASSIS, reason=CB fabrics are of mixed types Jan 23 17:35:43 craftd[1630]: %DAEMON-4: Major alarm set, CB fabrics are of mixed types
To troubleshoot and clear the alarm, perform the following steps:
Verify the hardware details of the CB:
user@host> show chassis hardware | match CB CB 0 REV 05 750-062577 XXXXXXXX Enhanced MX SCB CB 1 REV 05 750-062577 XXXXXXXX Enhanced MX SCB CB 2 REV 09 750-062572 XXXXXXXX Enhanced MX SCB 2
CB 2 is of a different hardware type. This could be a possible reason for the alarm. You may choose to replace CB 2 with the same type as seen for CB 0 and CB 1 at this point or choose to proceed with the next steps to check if changing the CB2 type works.
user@host> request chassis fabric plane offline 4 user@host> request chassis fabric plane offline 5 <Wait for few minutes> user@host> request chassis fabric plane online 4 user@host> request chassis fabric plane online 5
user@host> request chassis fabric plane offline 4 user@host> request chassis fabric plane offline 5
<Wait for few minutes> user@host> request chassis fabric plane online 4 user@host> request chassis fabric plane online 5
Refer to KB23067 - Instructions to Offline/Online MX Fabric Plane and MX SCB (called from Resolution Guide - Troubleshoot Fabric Plane) [juniper.net] for more details.
If RE is inserted in the CB that is exhibiting the error, halt the RE.
Note: Make sure that all these steps are performed on the backup RE and not on the primary. In case the alarm is seen for the primary RE, switch mastership before proceeding further by referring to Manually Switch from Primary to Backup Routing Engine .
Halt the RE.
user@host>request system halt other-routing-engine >>>>Issue from Master.
Re-seat/restart the affected CB/RE:
user@host>request chassis cb slot 2 offline
Check for alarms:
user@host> show chassis alarms >>> No alarms will be seen since CB is offline. user@host> request chassis cb slot 2 online
user@host> show chassis alarms
user@host> request chassis cb slot 2 online
user@host> request system power-on other-routing-engine >>> Issued from master
Verify the alarms again.
If the alarm persists, proceed with the next steps.
Restart Chassis Manager to ensure that CB gets detected again:
user@host>restart chassis-control <gracefully|soft>
The above steps should help you clear the alarm. If not, it could be an issue with the slot/ CB.
In a Maintenance Window, swap CB in slot 2 with another spare CB of the correct type (matching the rest of the CBs). Check if the alarm clears. If yes, then the issue lies in the previous CB, which was in the same slot. If the alarm persists, the issue would be with the slot. To re-confirm, you can use another spare to test the same process again.
Contact Support for any help in the above-mentioned process.