System Management Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 24.1.x , 24.2.x
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Figure 1. Redundant Set of RP Installed in Slots RP0 and RP1 in an Cisco 8608 8-Slot Centralized Chassis
Figure 2. Redundant Set of RP Installed in Slots RP0 and RP1 in an Cisco 8808 8-Slot Distributed Chassis
1
Modular Port Adaptors (MPAs)
2
Route Processors (RPs)
3
Chassis
Determining the Active RP in a Redundant Pair
During system startup, one RP in each redundant pair becomes the active RP. You can tell which RP is the active RP in the
following ways:
The active RP can be identified by the green Active LED on the faceplate of the card. When the Active LED turns on, it indicates
that the RP is active and when it turns off, it indicates that the RP is in standby.
The slot of the active RP is indicated in the CLI prompt. For example:
RP/0/RP1/CPU0:router#
In this example, the prompt indicates that you are communicating with the active RP in slot RP1.
Enter the showredundancy command in EXEC mode to display a summary of the active and standby RP status. For example:
RP/0/RP0/CPU0:router# show redundancy
This node (0/RP0/CPU0) is in ACTIVE role
Partner node (0/RP1/CPU0) is in STANDBY role
Standby node in 0/RP1/CPU0 is ready
Reload and boot info
----------------------
RP reloaded Fri Apr 9 03:44:28 2004: 16 hours, 51 minutes ago
This node booted Fri Apr 9 06:19:05 2004: 14 hours, 16 minutes ago
Last switch-over Fri Apr 9 06:53:18 2004: 13 hours, 42 minutes ago
Standby node boot Fri Apr 9 06:54:25 2004: 13 hours, 41 minutes ago
Standby node last not ready Fri Apr 9 20:35:23 2004: 0 minutes ago
Standby node last ready Fri Apr 9 20:35:23 2004: 0 minutes ago
There have been 2 switch-overs since reload
Role of the Standby RP
The second RP to boot in a redundant pair automatically becomes the standby RP. While the active RP manages the system and
communicates with the user interface, the standby RP maintains a complete backup of the software and configurations for all
cards in the system. If the active RP fails or goes off line for any reason, the standby RP immediately takes control of the
system.
Summary of Redundancy Commands
RP redundancy is enabled by default in the Cisco IOS XR software, but you can use the commands described in Table 1 to display the redundancy status of the cards or force a manual switchover.
Table 1. RP Redundancy Commands
Command
Description
showredundancy
Displays the redundancy status of the RP. This command also displays the boot and switch-over history for the RP.
redundancyswitchover
Forces a manual switchover to the standby RP. This command works only if the standby RP is installed and in the “ready” state.
show platform
Displays the status for node, including the redundancy status of the RP cards. In EXEC mode, this command displays status
for the nodes assigned to the SDR. In administration EXEC mode, this command displays status for all nodes in the system.
Automatic Switchover
Automatic switchover from the active RP to the standby RP occurs only if the active RP encounters a serious system error,
such as the loss of a mandatory process or a hardware failure. When an automatic switchover occurs, the RPs respond as follows:
If a standby RP is installed and “ready” for switchover, the standby RP becomes the active RP. The original active RP attempts
to reboot.
If the standby RP is not in “ready” state, then both RPs reboot. The first RP to boot successfully assumes the role of active
RP.
RP Redundancy During RP Reload
The reload command causes the active RP to reload the Cisco IOS XR software. When an RP reload occurs, the RPs respond as follows:
If a standby RP is installed and “ready” for switchover, the standby RP becomes the active RP. The original active RP reboots
and becomes the standby RP.
If the standby RP is not in the “ready” state, then both RPs reboot. The first RP to boot successfully assumes the role of
active RP.
Manual Switchover
If a standby RP is installed and ready for switchover, you can force a manual switchover using the redundancyswitchover command or reloading the active RP using the reload command.
Manual Switchover Using the Reload Command
You can force a manual switchover from the active RP to the standby RP by reloading the active RP using the reload command. As active RP reboots, the current standby RP becomes active RP, and rebooting RP switches to standby RP.
Manual Switchover Using the Redundancy Switchover Command
You can force a manual switchover from the active RP to the standby RP using the redundancyswitchover command.
If a standby RP is installed and ready for switchover, the standby RP becomes the active RP. The original active RP becomes
the standby RP. In the following example, partial output for a successful redundancy switchover operation is shown:
RP/0/RP0/CPU0:router# show redundancy
This node (0/RP0/CPU0) is in ACTIVE role
Partner node (0/RP1/CPU0) is in STANDBY role
Standby node in 0/RP1/CPU0 is ready
RP/0/RP0/CPU0:router# redundancy switchover
Updating Commit Database. Please wait...[OK]
Proceed with switchover 0/RP0/CPU0 -> 0/RP1/CPU0? [confirm]
Initiating switch-over.
RP/0/RP0/CPU0:router#
<Your 'TELNET' connection has terminated>
In the preceding example, the Telnet connection is lost when the previously active RP resets. To continue management of the
router, you must connect to the newly activated RP as shown in the following example:
User Access Verification
Username: xxxxx
Password: xxxxx
Last switch-over Sat Apr 15 12:26:47 2009: 1 minute ago
RP/0/RP1/CPU0:router#
If the standby RP is not in “ready” state, the switchover operation is not allowed. In the following example, partial output
for a failed redundancy switchover attempt is shown:
RP/0/RP0/CPU0:router# show redundancy
Redundancy information for node 0/RP1/CPU0:
==========================================
Node 0/RP0/CPU0 is in ACTIVE role
Partner node (0/RP1/CPU0) is in UNKNOWN role
Reload and boot info
----------------------
RP reloaded Wed Mar 29 17:22:08 2009: 2 weeks, 2 days, 19 hours, 14 minutes ago
Active node booted Sat Apr 15 12:27:58 2009: 8 minutes ago
Last switch-over Sat Apr 15 12:35:42 2009: 1 minute ago
There have been 4 switch-overs since reload
RP/0/RP0/CPU0:router# redundancy switchover
Switchover disallowed: Standby node is not ready.
Communicating with a Standby RP
The active RP automatically synchronizes all system software, settings, and configurations with the standby RP.
If you connect to the standby RP through the console port, you can view the status messages for the standby RP. The standby
RP does not display a CLI prompt, so you cannot manage the standby card while it is in standby mode.
If you connect to the standby RP through the management Ethernet port, the prompt that appears is for the active RP, and you
can manage the router the same as if you had connected through the management Ethernet port on the active RP.
NPU Power Optimization
Table 2. Feature History Table
Feature Name
Release Information
Description
NPU Power Optimization
Release 7.3.15
This feature lets you choose a predefined NPU power mode based on your network's individual requirements, and consequently
reducing NPU power consumption.
The hw-module npu-power-profile command is introduced for this feature.
Cisco 8000 series routers are powered by Cisco Silicon One Q200 and Q100 series processors. Cisco Silicon One processors offer
high performance, flexible, and power-efficient routing silicon in the market.
NPU Power Optimization feature helps to reduce NPU power consumption by running a processor in a predefined mode. There are
three NPU power modes—high, medium, and low. Based on your network traffic and power consumption requirements, you can choose
to run the processor in any one of the three NPU power modes.
High: The router will use the maximum amount of power, resulting in the best possible performance.
Medium: The router power consumption and performance levels are both average.
Low: The router operates with optimal energy efficiency while providing a modest level of performance.
Note
We recommend that you work with your Cisco account representatives before implementing this feature in your network.
On a Q200-based Cisco 8200 series chassis, you can configure an NPU power mode on the entire router.
On a Q200-based Cisco 8800 series chassis, you can configure an NPU power mode only on fabric cards and line cards.
The following table lists the supported hardware, and their default NPU power mode:
Table 3. Supported Hardware and Default Modes
Supported Hardware
Default NPU Power Mode
Cisco 8200 32x400 GE 1RU fixed chassis (8201-32FH)
High
88-LC0-36FH without MACSec, based on Q200 Silicon Chip
Medium
88-LC0-36FH-M with MACSec, based on Q200 Silicon Chip
Medium
8808-FC0 Fabric Card, based on Q200 Silicon Chip
Low
8818-FC0 Fabric Card, based on Q200 Silicon Chip
Medium
Caution
We recommend that you use the default NPU power mode on your router.
Limitations
The NPU power optimization is not supported on the Q100-based systems.
The NPU Power Profile mode is not supported on the following Q200-based line cards:
Table 4. Limitation on Hardware and Power Profile Modes
Hardware
Power Profile Mode
88-LC0-36FH-M
High
88-LC0-34H14FH
High
Configuring NPU Power Mode
Configuring NPU power mode on a fixed chassis:
The following example shows how to configure an NPU power mode on a fixed chassis:
RP/0/RP0/CPU0:ios(config)#hw-module npu-power-profile high
RP/0/RP0/CPU0:ios(config)#commit
RP/0/RP0/CPU0:ios(config)#reload
Note
Note: Reload the chassis for the configurations changes to take effect.
Verifying NPU power mode configuration on a fixed chassis:
Use the show controllers npu driver command to verify the NPU power mode configuration:
RP/0/RP0/CPU0:ios#show controllers npu driver location 0/RP0/CPU0
Mon Aug 24 23:29:34.302 UTC
==============================================
NPU Driver Information
==============================================
Driver Version: 1
SDK Version: 1.32.0.1
Functional role: Active, Rack: 8203, Type: lcc, Node: 0
Driver ready : Yes
NPU first started : Mon Aug 24 23:07:41 2020
Fabric Mode:
NPU Power profile: High
Driver Scope: Node
Respawn count : 1
Availablity masks :
card: 0x1, asic: 0x1, exp asic: 0x1
...
Configuring NPU power mode on a modular chassis
The following example shows how to configure an NPU power mode on a fabric card and a line card:
RP/0/RP0/CPU0:ios(config)#hw-module npu-power-profile card-type FC high
RP/0/RP0/CPU0:ios(config)#hw-module npu-power-profile card-type LC low location 0/1/cpu0
RP/0/RP0/CPU0:ios(config)#commit
Note
For the configurations to take effect, you must:
Reload a line card if the configuration is applied on the line card.
Reload a router if the configuration is applied on a fabric card.
Verifying the NPU power mode configuration on a modular chassis
Use the show controllers npu driver location command to verify the NPU power mode configuration:
RP/0/RP0/CPU0:ios#show controllers npu driver location 0/1/CPU0
Functional role: Active, Rack: 8808, Type: lcc, Node: 0/RP0/CPU0
Driver ready : Yes
NPU first started : Mon Apr 12 09:57:27 2021
Fabric Mode: FABRIC/8FC
NPU Power profile: High
Driver Scope: Rack
Respawn count : 1
Availablity masks :
card: 0xba, asic: 0xcfcc, exp asic: 0xcfcc
Weight distribution:
Unicast: 80, Multicast: 20
+----------------------------------------------------------------+
| Process | Connection | Registration | Connection | DLL |
| /Lib | status | status | requests | registration|
+----------------------------------------------------------------+
| FSDB | Active | Active | 1| n/a |
| FGID | Active | Active | 1| n/a |
| AEL | n/a | n/a | n/a| Yes |
| SM | n/a | n/a | n/a| Yes |
+----------------------------------------------------------------+
Asics :
HP - HotPlug event, PON - Power On reset
HR - Hard Reset, WB - Warm Boot
+------------------------------------------------------------------------------+
| Asic inst. | fap|HP|Slice|Asic|Admin|Oper | Asic state | Last |PON|HR | FW |
| (R/S/A) | id | |state|type|state|state| | init |(#)|(#)| Rev |
+------------------------------------------------------------------------------+
| 0/FC1/2 | 202| 1| UP |s123| UP | UP |NRML |PON | 1| 0|0x0000|
| 0/FC1/3 | 203| 1| UP |s123| UP | UP |NRML |PON | 1| 0|0x0000|
| 0/FC3/6 | 206| 1| UP |s123| UP | UP |NRML |PON | 1| 0|0x0000|
| 0/FC3/7 | 207| 1| UP |s123| UP | UP |NRML |PON | 1| 0|0x0000|
| 0/FC4/8 | 208| 1| UP |s123| UP | UP |NRML |PON | 1| 0|0x0000|
| 0/FC4/9 | 209| 1| UP |s123| UP | UP |NRML |PON | 1| 0|0x0000|
| 0/FC5/10 | 210| 1| UP |s123| UP | UP |NRML |PON | 1| 0|0x0000|
| 0/FC5/11 | 211| 1| UP |s123| UP | UP |NRML |PON | 1| 0|0x0000|
| 0/FC7/14 | 214| 1| UP |s123| UP | UP |NRML |PON | 1| 0|0x0000|
| 0/FC7/15 | 215| 1| UP |s123| UP | UP |NRML |PON | 1| 0|0x0000|
+------------------------------------------------------------------------------+
SI Info :
+--------------------------------------------------------------------------------------------+
| Card | Board | SI Board | SI Param | Retimer SI | Retimer SI | Front Panel |
| | HW Version | Version | Version | Board Version | Param Version | PHY |
+--------------------------------------------------------------------------------------------+
| FC1 | 0.22 | 1 | 6 | NA | NA | NA |
| FC3 | 0.21 | 1 | 6 | NA | NA | NA |
| FC4 | 0.21 | 1 | 6 | NA | NA | NA |
| FC5 | 0.21 | 1 | 6 | NA | NA | NA |
| FC7 | 0.21 | 1 | 6 | NA | NA | NA |
+--------------------------------------------------------------------------------------------+
Functional role: Active, Rack: 8808, Type: lcc, Node: 0/1/CPU0
Driver ready : Yes
NPU first started : Mon Apr 12 09:58:10 2021
Fabric Mode: FABRIC/8FC
NPU Power profile: Low
Driver Scope: Node
Respawn count : 1
Availablity masks :
card: 0x1, asic: 0x7, exp asic: 0x7
Weight distribution:
Unicast: 80, Multicast: 20
+----------------------------------------------------------------+
| Process | Connection | Registration | Connection | DLL |
| /Lib | status | status | requests | registration|
+----------------------------------------------------------------+
| FSDB | Active | Active | 1| n/a |
| FGID | Inactive | Inactive | 0| n/a |
| AEL | n/a | n/a | n/a| Yes |
| SM | n/a | n/a | n/a| Yes |
+----------------------------------------------------------------+
Asics :
HP - HotPlug event, PON - Power On reset
HR - Hard Reset, WB - Warm Boot
+------------------------------------------------------------------------------+
| Asic inst. | fap|HP|Slice|Asic|Admin|Oper | Asic state | Last |PON|HR | FW |
| (R/S/A) | id | |state|type|state|state| | init |(#)|(#)| Rev |
+------------------------------------------------------------------------------+
| 0/2/0 | 8| 1| UP |npu | UP | UP |NRML |PON | 1| 0|0x0000|
| 0/2/1 | 9| 1| UP |npu | UP | UP |NRML |PON | 1| 0|0x0000|
| 0/2/2 | 10| 1| UP |npu | UP | UP |NRML |PON | 1| 0|0x0000|
+------------------------------------------------------------------------------+
SI Info :
+--------------------------------------------------------------------------------------------+
| Card | Board | SI Board | SI Param | Retimer SI | Retimer SI | Front Panel |
| | HW Version | Version | Version | Board Version | Param Version | PHY |
+--------------------------------------------------------------------------------------------+
| LC2 | 0.41 | 1 | 9 | NA | NA | DEFAULT |
+--------------------------------------------------------------------------------------------+
Dynamic Power Management
Table 5. Feature History Table
Feature Name
Release Information
Description
Dynamic Power Management
Release 7.3.15
The Dynamic Power Management feature considers certain dynamic factors before allocating power to the fabric and line cards.
This feature has the following benefits:
Reduces number of PSUs required by accurately representing the maximum power consumption
Improves PSU efficiency by providing more accurate power allocation
This feature thus optimizes power allocation and avoids overprovisioning power to a router.
Dynamic Power Management
Release 7.3.2
Previously available for fabric and line cards, this feature that helps avoid excess power allocation by considering dynamic
factors before allocating power to them is now available for optical modules.
To view the power allocation on a per port basis, a new command “show environment power allocated [details]" is introduced.
Dynamic Power Management
Release 7.3.3
The Dynamic Power Management feature is now supported on the following Cisco 8100 and 8200 series routers:
Cisco 8201
Cisco 8202
Cisco 8201-32-FH
Cisco 8101-32-FH
Dynamic Power Management
Release 7.5.2
The Cisco 8202-32FH-M router will now consider dynamic factors, such as optical modules, NPU power profile, and MACsec mode
to enable improved power allocation and utilization.
Prior to Cisco IOS XR Release 7.3.15, when Cisco 8000 series routers were powered on or reloaded, the power management feature
reserved power to fabric cards and allocated maximum power to line cards. The power management feature wouldn’t consider dynamic
factors, such as the type of fabric or line cards in the chassis, or whether a fabric or line card was present in a slot.
The Dynamic Power Management feature considers such dynamic factors before allocating power to the fabric and line cards.
This feature has the following benefits:
Reduces number of PSUs required by accurately representing the maximum power consumption
Improves PSU efficiency by providing more accurate power allocation
This feature thus optimizes power allocation and avoids overprovisioning power to a router.
This feature is supported on the following Cisco 8000 series routers:
Cisco 8804, 8808, 8812, and 8818 routers
Cisco 8201, 8202, 8201-32-FH, and 8202-32FH-M routers
Cisco 8101-32-FH
By default, this feature is enabled on the router.
The Dynamic Power Management feature allocates the total power to a router and its fabric card or line card based on the following
parameters:
Number and type of fabric cards installed on the router
Fabric cards operating modes (5FC or 8FC)
Number and type of line cards installed on the router
Combination of line card and fabric card types installed
NPU power mode configured on a fabric card
Number and type of optics installed (supported in Cisco IOS XR Software Release 7.3.2 and later)
MACSec-enabled ports (supported from Cisco IOS XR SoftwareRelease 7.3.3 and later)
For details, see Dynamic Power Management for MACSec-Enabled Ports section in the Configuring MACSec chapter in the
System Security Configuration Guide for Cisco 8000 Series Routers.
On 8202-32FH-M router, the Dynamic Power Management feature allocates the total power to a router based on the following parameters:
Optical modules installed.
NPU power profile. To identify the mode on which the router is operating, use the hw-module npu-power-profile command.
MACSec mode. By default, MACSec mode is disabled on 8202-32FH-M router.
Note
We recommend you work with your Cisco account representatives to calculate power requirements for the Cisco 8000 series router.
Power Allocation to Empty Card Slot
This feature allocates a minimum required power for all empty LC or FC slots. This minimum power is required to boot the CPU
and FPGAs immediately when a card is inserted. The feature doesn't control booting up the CPU and FPGAs. Also, the minimum
power is required to detect the card type before the feature decides if there’s enough power to power up the data path.
For example, the following show environment power command output displays various LC or FC card statuses, and also shows allocated and used power.
Note
The allocated power capacity shown in the following show command output isn’t standard capacity. The allocated power capacity varies depending on various other factors.
Router# show environment power
Thu Apr 22 12:03:06.754 UTC
================================================================================
CHASSIS LEVEL POWER INFO: 0
================================================================================
Total output power capacity (N + 1) : 9600W + 6300W
Total output power required : 9241W
Total power input : 6146W
Total power output : 5826W
================================================================================
Power Supply -------Input-------- -----Output--- Status
Module Type Volts A/B Amps A/B Volts Amps
================================================================================
0/PT0-PM0 PSU6.3KW-HV 245.5/245.7 5.1/5.0 54.7 43.1 OK
0/PT0-PM1 PSU6.3KW-HV 0.0/245.2 0.0/7.4 54.3 31.7 OK
0/PT0-PM2 PSU6.3KW-HV 0.0/246.9 0.0/7.5 54.1 32.3 OK
Total of Power Modules: 6146W/25.0A 5826W/107.1A
================================================================================
Location Card Type Power Power Status
Allocated Used
Watts Watts
================================================================================
0/RP0/CPU0 8800-RP 95 69 ON
0/RP1/CPU0 - 95 - RESERVED
0/0/CPU0 88-LC0-36FH 796 430 ON
0/1/CPU0 - 102 - RESERVED
0/2/CPU0 88-LC0-36FH 796 430 ON
0/3/CPU0 - 102 - RESERVED
0/4/CPU0 - 102 - RESERVED
0/5/CPU0 - 102 - RESERVED
0/6/CPU0 - 102 - RESERVED
0/7/CPU0 - 102 - RESERVED
0/8/CPU0 - 102 - RESERVED
0/9/CPU0 88-LC0-36FH 102 - OFF
0/10/CPU0 - 102 - RESERVED
0/11/CPU0 - 102 - RESERVED
0/FC0 - 26 - RESERVED
0/FC1 - 26 - RESERVED
0/FC2 - 26 - RESERVED
0/FC3 8812-FC 784 509 ON
0/FC4 8812-FC 784 503 ON
0/FC5 8812-FC 26 - OFF
0/FC6 8812-FC 26 - OFF
0/FC7 8812-FC 26 - OFF
0/FT0 8812-FAN 1072 1000 ON
0/FT1 8812-FAN 1072 1012 ON
0/FT2 8812-FAN 1072 861 ON
0/FT3 8812-FAN 1072 1033 ON
This table describes the card slot statuses:
Table 6. Router Card Slot Status
Status
Description
RESERVED
When a slot is empty
OFF
When a card is inserted in a slot but power isn’t allocated to the card
ON
When a card is allocated power and the card is in operational state
Low-Power Condition
When you insert an LC or FC in a card slot at the time when the router doesn't have enough power available to allocate to
the new card, the dynamic power management feature doesn't provision power to the card. It raises the ev_power_budget_not_ok alarm, and gracefully shuts down the card.
In the following show command output, an FC inserted in the card slot location 0/FC6 is gracefully shut down due to lack of power:
However, after an LC, FC, or chassis reload, the dynamic power management feature can't ensure that the same LCs, FCs, optics,
or interfaces, which were operational earlier (before the reload), would become active again.
Note
During a low-power condition, this feature doesn’t borrow power from a redundant power supply.
Power Allocation to Optics
From Cisco IOS XR Release 7.3.2 onwards, power requirement for optics is also considered before allocating power to them.
To identify the power allocated for a particular interface, use the show environment power allocated [details] location location command.
When the optical modules are inserted, power is automatically allocated for that interface. If power has been allocated to
the interface, then use the “no shut” command to enable the interface.
Router# show environment power allocated location 0/3/CPU0
Thu Oct 7 22:27:35.732 UTC
================================================================================
Location Components Power
Allocated
Watts
================================================================================
0/3/CPU0 Data-path 772
OPTICS138
================================================================================
Total 910
When the power is not allocated to the interface, the following syslog error and alarms are displayed
!<--Syslog Error-->!
#LC/0/3/CPU0:Oct 7 22:46:48.114 UTC: optics_driver[165]: %PKT_INFRA-FM-3-FAULT_MAJOR : ALARM_MAJOR :POWER ALLOCATION FAIL :DECLARE :0/3/CPU0: Optics0/3/0/44
LC/0/3/CPU0:Oct 7 22:46:48.114 UTC: optics_driver[165]: %L2-OPTICS-2-QSFP_POWER_ALLOCATION_FAILURE : Not enough power available to enable Optics 0/3/0/44
!<--Alarm-->!
Router#show alarms brief system active
Thu Oct 7 22:47:19.569 UTC
------------------------------------------------------------------------------------
Active Alarms
------------------------------------------------------------------------------------
Location Severity Group Set Time Description
------------------------------------------------------------------------------------
0/3/CPU0 Major Software 10/07/2021 22:46:48 UTC Optics0/3/0/44 - hw_optics: Lack of available power to enable the optical module
0/3/CPU0 Major Software 10/07/2021 22:47:06 UTC Optics0/3/0/46 - hw_optics: Lack of available power to enable the optical module
If power is not allocated to an interface and you attempt to enable that interface using the “no shut” command, the following syslog error is displayed:
LC/0/2/CPU0:Aug 30 18:01:14.930 UTC: eth_intf_ea[262]: %PLATFORM-VEEA-1-PORT_NOT_ENABLED : Power not allocated to enable the interface HundredGigE0_2_0_6.
Power Allocation to Fixed-Port Routers
The following show environment power command output displays power information for fixed-port routers and components.
Router# show environment power
Wed Feb 16 21:05:10.001 UTC
================================================================================
CHASSIS LEVEL POWER INFO: 0
================================================================================
Total output power capacity (Group 0 + Group 1) : 1400W + 1400W
Total output power required : 1033W
Total power input : 390W
Total power output : 255W
Power Group 0:
================================================================================
Power Supply ------Input---- ------Output--- Status
Module Type Volts Amps Volts Amps
================================================================================
0/PM0 PSU1.4KW-ACPE 244.5 0.8 12.0 11.1 OK
Total of Group 0: 195W/0.8A 133W/11.1A
Power Group 1:
================================================================================
Power Supply ------Input---- ------Output--- Status
Module Type Volts Amps Volts Amps
================================================================================
0/PM1 PSU1.4KW-ACPE 244.2 0.8 12.0 10.2 OK
Total of Group 1: 195W/0.8A 122W/10.2A
================================================================================
Location Card Type Power Power Status
Allocated Used
Watts Watts
================================================================================
0/RP0/CPU0 8201 893 - ON
0/FT0 FAN-1RU-PE 28 - ON
0/FT1 FAN-1RU-PE 28 - ON
0/FT2 FAN-1RU-PE 28 - ON
0/FT3 FAN-1RU-PE 28 - ON
0/FT4 FAN-1RU-PE 28 - ON
To identify the power allocated for a particular interface, use the show environment power allocated [details] location location command.
Router# show environment power allocated location 0/RP0/CPU0
Wed Feb 16 21:05:21.360 UTC
================================================================================
Location Components Power
Allocated
Watts
================================================================================
0/RP0/CPU0 Data-path 858
OPTICS35
================================================================================
Total 893
Router# show environment power allocated details location 0/RP0/CPU0
Wed Feb 16 21:05:36.142 UTC
================================================================================
Location Components Power
Allocated
Watts
================================================================================
0/RP0/CPU0 Data-path 858
0/0/0/19210/0/0/1814
================================================================================
Total 893
Disabling Dynamic Power Management
By default, the dynamic power management is enabled on a router. The following example shows how to disable dynamic power
management:
After disabling the dynamic power management feature, you must manage the router power on your own. So, use this command with
caution.
Note
To reenable dynamic power management, use the no power-mgmt action disable command.
On-demand transfer of Redundant Power Modules to Power Reservation Pool
Table 7. Feature History Table
Feature Name
Release Information
Feature Description
On-demand transfer of Redundant Power Modules to Power Reservation Pool
Release 7.11.1
The Cisco 8800 Series Modular Routers now have a functionality that allows them to transfer their redundant Power Supply Units
(PSUs) to the power reservation pool when there is inadequate power supply. This capability helps prevent the router from
shutting down hardware components due to a lack of power in the reservation pool, which used to occur due to the router prioritizing
redundancy over power availability in the power reservation pool. Consequently, the router now raises an alarm indicating
redundancy loss when it transfers PSUs to the power reservation pool. This feature ensures that the router components reserve
the necessary power, even when redundancy is enabled.
The Cisco 8000 Series Modular Routers offer redundancy while managing Power Supply Units (PSUs), providing continuous operation
if there is PSU failure. By default, the router operates in N+1 redundancy, where N represents the number of PSUs allotted
to the power reservation pool for powering the router components, and 1 indicates the backup PSU. You can use the power-mgmt redundancy-num-pms number command in XR Config mode mode to configure the PSU redundancy from N+1 to N+x, where x is the number of redundant PSUs required. The total number
of functioning PSUs must be at least x more than the number of PSUs required to support the power demanded by all the components
in the system for optimal router functionality. The range of values assigned to x is 0–11, where 0 implies no power redundancy.
The router uses the redundant PSUs only when there is a PSU failure. But, if the power requirement of the router increases
than the available power offered by PSUs, the router prioritizes maintaining PSU redundancy overpowering the components.
Starting from Cisco IOS XR Release 7.11.1, the Cisco 8800 Modular Routers prioritize powering the router components over preserving
redundancy. The router transfers the redundant PSUs to a power reservation pool to power the router components on demand.
The router utilizes the redundant PSUs to increase the power capacity in the power reservation pool rather than maintaining
redundancy. For example, consider a scenario with 18900W (3 6300W PSUs) available power. Initially, the router reserves 12600W
(using 2 PSUs) in the power reservation pool and retains 6300W (one PSU) as a backup to maintain N+1 redundancy. Suppose the
router needs to reserve power for any components to power up and needs more power than is available in the reservation pool.
In that case, the router uses the entire 18900W with all three PSUs to power the components by transferring the redundant
PSU to the power reservation pool. The router then triggers a redundancy loss alarm with such an assignment. However, if any
further actions result in reduced power consumption in the router, the system automatically restores redundancy and clears
the redundancy lost alarm.
On redundancy loss, the router raises a Critical severity Power Module redundancy lost alarm. You can use the show alarms brief command to view the redundancy lost alarm.
Syslog messages for transforming redundant PSU into borrowable resource:
Syslog message created while redundancy loss (transforming redundant PSU to functional PSU):
You can also use the show environment view the redundancy status of the PSUs in the router.
The following section details the commands to verify the redundancy status in the router:
Router with N+1 redundancy:
Router:ios# show environment power
================================================================================
CHASSIS LEVEL POWER INFO: 0
================================================================================
Total output power capacity (N + 1) : 12600W + 6300W
Total output power required : 11545W
Total power input : 3302W
Total power output : 3004W
================================================================================
Power Supply -------Input-------- -----Output--- Status
Module Type Volts A/B Amps A/B Volts Amps
================================================================================
0/PT5-PM0 PSU6.3KW-HV 240.5/241.3 2.2/2.4 55.1 18.3 OK
0/PT5-PM1 PSU6.3KW-HV 240.5/240.8 2.1/2.3 54.8 17.3 OK
0/PT5-PM2 PSU6.3KW-HV 242.2/241.1 2.3/2.4 54.9 19.1 OK
Total of Power Modules: 3302W/13.7A 3004W/54.7A
================================================================================
Location Card Type Power Power Status
Allocated Used
Watts Watts
================================================================================
0/RP0/CPU0 8800-RP 105 78 ON
0/RP1/CPU0 - 105 - RESERVED
0/0/CPU0 8800-LC-36FH 1097 513 ON
0/1/CPU0 - 102 - RESERVED
0/2/CPU0 88-LC0-36FH 102 0 OFF
0/3/CPU0 - 102 - RESERVED
0/4/CPU0 - 102 - RESERVED
0/5/CPU0 - 102 - RESERVED
0/6/CPU0 - 102 - RESERVED
0/7/CPU0 - 102 - RESERVED
0/8/CPU0 - 102 - RESERVED
0/9/CPU0 - 102 - RESERVED
0/10/CPU0 - 102 - RESERVED
0/11/CPU0 - 102 - RESERVED
0/12/CPU0 - 102 - RESERVED
0/13/CPU0 - 102 - RESERVED
0/14/CPU0 - 102 - RESERVED
0/15/CPU0 - 102 - RESERVED
0/16/CPU0 - 102 - RESERVED
0/17/CPU0 - 102 - RESERVED
0/FC0 - 32 - RESERVED
0/FC1 - 32 - RESERVED
0/FC2 8818-FC0 584 475 ON
0/FC3 - 32 - RESERVED
0/FC4 8818-FC0 584 472 ON
0/FC5 - 32 - RESERVED
0/FC6 - 32 - RESERVED
0/FC7 - 32 - RESERVED
0/FT0 8818-FAN 1786 237 ON
0/FT1 8818-FAN 1786 228 ON
0/FT2 8818-FAN 1786 234 ON
0/FT3 8818-FAN 1786 228 ON
Router with redundancy loss:
Router:ios# sh env power
================================================================================
CHASSIS LEVEL POWER INFO: 0
================================================================================
Total output power capacity (N + 1) : 18900W + 0W
Total output power required : 12689W
Total power input : 3302W
Total power output : 3004W
================================================================================
Power Supply -------Input-------- -----Output--- Status
Module Type Volts A/B Amps A/B Volts Amps
================================================================================
0/PT5-PM0 PSU6.3KW-HV 240.5/241.3 2.2/2.4 55.1 18.3 OK
0/PT5-PM1 PSU6.3KW-HV 240.5/240.8 2.1/2.3 54.8 17.3 OK
0/PT5-PM2 PSU6.3KW-HV 242.2/241.1 2.3/2.4 54.9 19.1 OK
Total of Power Modules: 3302W/13.7A 3004W/54.7A
================================================================================
Location Card Type Power Power Status
Allocated Used
Watts Watts
================================================================================
0/RP0/CPU0 8800-RP 105 78 ON
0/RP1/CPU0 - 105 - RESERVED
0/0/CPU0 8800-LC-36FH 1097 513 ON
0/1/CPU0 - 102 - RESERVED
0/2/CPU0 88-LC0-36FH 916 510 ON
0/3/CPU0 - 102 - RESERVED
0/4/CPU0 - 102 - RESERVED
0/5/CPU0 - 102 - RESERVED
0/6/CPU0 - 102 - RESERVED
0/7/CPU0 - 102 - RESERVED
0/8/CPU0 - 102 - RESERVED
0/9/CPU0 - 102 - RESERVED
0/10/CPU0 - 102 - RESERVED
0/11/CPU0 - 102 - RESERVED
0/12/CPU0 - 102 - RESERVED
0/13/CPU0 - 102 - RESERVED
0/14/CPU0 - 102 - RESERVED
0/15/CPU0 - 102 - RESERVED
0/16/CPU0 - 102 - RESERVED
0/17/CPU0 - 102 - RESERVED
0/FC0 - 32 - RESERVED
0/FC1 - 32 - RESERVED
0/FC2 8818-FC0 749 475 ON
0/FC3 - 32 - RESERVED
0/FC4 8818-FC0 749 472 ON
0/FC5 - 32 - RESERVED
0/FC6 - 32 - RESERVED
0/FC7 - 32 - RESERVED
0/FT0 8818-FAN 1786 237 ON
0/FT1 8818-FAN 1786 225 ON
0/FT2 8818-FAN 1786 234 ON
0/FT3 8818-FAN 1786 228 ON
Router:ios# sh alarms brief system active
------------------------------------------------------------------------------------
Active Alarms
------------------------------------------------------------------------------------
Location Severity Group Set Time Description
------------------------------------------------------------------------------------
0/RP0/CPU0 Critical Software 10/27/2023 00:22:08 UTC Redundancy Partner Not Present
0 Major Environ 10/27/2023 00:23:48 UTC Power Module redundancy lost
0/RP0/CPU0 Minor Fabric 10/27/2023 00:22:39 UTC Fabric Plane-0 status
0/RP0/CPU0 Minor Fabric 10/27/2023 00:22:39 UTC Fabric Plane-1 status
0/RP0/CPU0 Minor Fabric 10/27/2023 00:22:39 UTC Fabric Plane-3 status
0/RP0/CPU0 Minor Fabric 10/27/2023 00:22:39 UTC Fabric Plane-5 status
0/RP0/CPU0 Minor Fabric 10/27/2023 00:22:39 UTC Fabric Plane-6 status
0/RP0/CPU0 Minor Fabric 10/27/2023 00:22:39 UTC Fabric Plane-7 status
0/RP0/CPU0 Major Software 10/27/2023 00:22:59 UTC Communications Failure With Cisco Licensing Cloud
0 Major Environ 10/27/2023 00:23:48 UTC Power Module redundancy lost
Power Redundancy Protection
Table 8. Feature History Table
Feature Name
Release Information
Feature Description
Power Redundancy Protection
Release 24.1.1
You can now prevent power module exhaustion or failure due to power redundancy issues in the power feeds with the help of
alarms that warn that the total output power required by the router exceeds the total feed redundancy capacity. You can configure
either single-fault protection or dual fault protection, depending on whether you want to trigger alarms during redundancy
failures in the power supply feed, PSU redundancy, or both.
The Total feed redundancy capacity field is added to the show environment command.
The Cisco 8000 Series Modular Routers have two redundancy mechanisms to ensure the router continues functioning even during
power supply failures:
The PSU redundancy involves having extra power supplies that can take over if one fails, ensuring continuous operation.
The power feed redundancy divides the input power into A and B feeds. When both feeds are functioning normally, they share
the power load equally. However, if one of the feeds fails, the other feed scales up to its maximum capacity or the power
supply unit (PSU) will operate with reduced input to ensure that the power supply to the router is uninterrupted.
These power redundancy options provide a high level of reliability and minimize the risk of network downtime due to power
supply failures.
The routers now have power redundancy protection that triggers alarms for PSU and feed redundancy failures when the total
output power required by the router exceeds its total feed redundancy capacity. You can configure the total feed redundancy
capacity in two modes- single fault protection and dual fault protection.
The single fault protection mode monitors the router against a power supply feed or PSU redundancy failure. Meanwhile, the dual fault protection monitors the router against a power supply feed and PSU redundancy failure simultaneously. You can also customize the PSU single feed capacity in the router. Each PSU has a default
power range for the single feed; you can configure a value within the range to meet your specific infrastructure requirements.
The feed redundancy alarm is triggered when the total output power required exceeds the total feed redundancy capacity. The
router's total feed capacity is determined by the least of two factors: feed redundancy capacity and PSU redundancy capacity.
The PSU redundancy capacity is the number of power supply units minus the redundant ones (N) multiplied by a dual feed capacity.
On the other hand, the feed redundancy capacity is the total number of PSUs multiplied by a single feed capacity. In single-fault
protection, the PSU refers to the router's total number of power supply units (N+1). In dual-fault protection, the PSU refers
to the number of power supply units minus the redundant ones (N).
For example, consider a router that has a total of 9 PSUs with a default N + 1 power redundancy configuration. The PSU feed
capacity with dual feed is 4800 W and the single feed capacity value is set 3200 W, then the total feed redundancy capacity
would be:
Power Redundancy Protection
Total Number of PSUs
PSU redundancy
Number of PSUs minus the redundant ones (N)
Dual Feed Capacity
Single Feed Capacity
Feed Redundancy Capacity
PSU Redundancy Capacity
Total Feed Redundancy Capacity
Single fault protection
9
N+1
8
4800 W
3200 W
28800 W
38400 W
28800 W
Dual fault protection
9
N+1
8
4800 W
3200 W
25600 W
38400 W
25600 W
Guidelines and Restrictions for Power Redundancy Protection
By default, the router doesn’t enable Power Redundancy Protection.
The Power Redundancy Protection feature doesn’t impact the power budgeting in the routers.
For maximum power redundancy protection, use the dual fault protection.
For total feed redundancy capacity calculations, the router considers only the PSUs with A and B inputs. Both A and B inputs
must be within the operating range in healthy conditions. If either feed is unavailable, the router excludes such PSUs from
the calculations.
The router considers all PSUs, including redundant PSUs with two feeds (within the operating range in healthy condition) for
feed redundancy capacity in single fault protection. However, the router excludes the redundant PSUs for feed redundancy capacity
in dual fault protection. If the router has 8 PSUs and N+3 redundancy, single fault protection calculation considers all eight
PSUs, whereas dual fault protection considers just 5 PSUs.
Configure Power Redundancy Protection
To configure the power redundancy protection mode and PSU single feed capacity, you can use the power-mgmt feed-redundancy command.
Single fault protection with PSU single feed capacity set to 2400 Watts
Router# show run power
…
power-mgmt feed-redundancy single-fault-protection capacity 2400
…
Verification:
Router# show env power
================================================================================
CHASSIS LEVEL POWER INFO: 0
================================================================================
Total output power capacity (N + 1) : 28800W + 4800W
Total output power required : 6679W >>>>> 1
Total power input : 2394W
Total power output : 2066W
Total feed redundancy capacity (Single Fault) : 16800W >>>>> 2
//*The router triggers feed redundancy loss alarm when 1 > 2.**//
================================================================================
Power Supply -------Input-------- -----Output--- Status
Module Type Volts A/B Amps A/B Volts Amps
================================================================================
0/PT0-PM0 PSU4.8KW-DC100 62.8/62.7 2.6/2.5 55.2 5.3 OK
0/PT0-PM1 PSU4.8KW-DC100 62.7/62.7 2.7/2.6 55.3 5.3 OK
0/PT0-PM3 PSU4.8KW-DC100 61.0/62.7 2.6/2.5 55.2 4.8 OK
0/PT1-PM0 PSU4.8KW-DC100 67.3/67.3 2.7/2.5 55.3 5.2 OK
0/PT1-PM1 PSU4.8KW-DC100 67.3/67.2 2.8/2.7 55.3 5.7 OK
0/PT1-PM2 PSU4.8KW-DC100 67.3/67.4 2.7/2.7 55.2 5.6 OK
0/PT1-PM3 PSU4.8KW-DC100 67.3/67.3 2.6/2.5 55.3 5.5 OK
Total of Power Modules: 2394W/36.7A 2066W/37.4A
Dual fault protection with PSU single feed capacity set to 2400 Watts
Router# show run power
…
power-mgmt feed-redundancy dual-fault-protection capacity 2400
…
Verification:
Router# show env power
================================================================================
CHASSIS LEVEL POWER INFO: 0
================================================================================
Total output power capacity (N + 1) : 28800W + 4800W
Total output power required : 6679W >>>>> 1
Total power input : 2394W
Total power output : 2066W
Total feed redundancy capacity (Dual Fault) : 14400W >>>>> 2
//*The router triggers feed redundancy loss alarm when 1 > 2.**//
================================================================================
Power Supply -------Input-------- -----Output--- Status
Module Type Volts A/B Amps A/B Volts Amps
================================================================================
0/PT0-PM0 PSU4.8KW-DC100 62.8/62.7 2.6/2.5 55.2 5.3 OK
0/PT0-PM1 PSU4.8KW-DC100 62.7/62.7 2.7/2.6 55.3 5.3 OK
0/PT0-PM3 PSU4.8KW-DC100 61.0/62.7 2.6/2.5 55.2 4.8 OK
0/PT1-PM0 PSU4.8KW-DC100 67.3/67.3 2.7/2.5 55.3 5.2 OK
0/PT1-PM1 PSU4.8KW-DC100 67.3/67.2 2.8/2.7 55.3 5.7 OK
0/PT1-PM2 PSU4.8KW-DC100 67.3/67.4 2.7/2.7 55.2 5.6 OK
0/PT1-PM3 PSU4.8KW-DC100 67.3/67.3 2.6/2.5 55.3 5.5 OK
Total of Power Modules: 2394W/36.7A 2066W/37.4A
Alarms for power redundancy loss
You can use the show alarms brief command to view the power redundancy alarm:
Note
The router triggers the Power Module redundancy feed mode lost alarm only when Total output power required exceeds Total feed redundancy capacity.
Router# show alarms brief system active
----------------------------------------------------------------------------------------------------------------------
Active Alarms
----------------------------------------------------------------------------------------------------------------------
Location Severity Group Set Time Description
----------------------------------------------------------------------------------------------------------------------
0 Major Environ 11/27/2023 12:55:08 UTC Power Module redundancy feed mode lost
System Log messages for power redundancy loss
Syslog message created while power redundancy loss (total output power exceeds total feed redundancy capacity):
We are introducing functionality to set the maximum power limit for a router to improve power management and distribution
in the PSUs. It prevents a router from using more than the configured power and also gives the ability to limit the reservation
pool regardless of how many power supplies are present. In the previous releases, the ability to prevent a router from using
more than a configured amount of power was unavailable.
In the earlier releases, there was no mechanism to limit the power a router consumed. Routers could draw more than the infrastructure
could handle. Over power consumption could result in system brownout.
With the Cisco IOS XR Software Release 7.11.1, you can allocate system power based on max power capacity configuration. This prevents the router from allocating more power
than the infrastructure can handle. It also gives you the ability to limit power to a router according to your infrastructure
requirements. The max power capacity parameter doesn't allow power consumed by the hardware to cross the configured amount.
The criteria to set maximum power limit is that the value must be set between the current allocated power and the available
maximum power at time of configuration.
This feature is not applicable for fixed routers.
A new command power-mgmt configured-power-capacity has been introduced with this feature.
A new alarm PKT_INFRA-FM-3-FAULT_MAJOR : ALARM_MAJOR :Power reservation exceeds configured power is introduced to be raised when the max power capacity is crossed.
Note
This alarm is extremely rare and is raised only when the power reservation exceeds configured power. This can only happen
when hardware is inserted, it is granted power without a request, such as a fan tray.
Upgrading FPD for PSU
Table 10. Feature History Table
Feature Name
Release Information
Feature Description
Optimized PSU FPD Upgrade
Release 7.8.1
We have optimized the upgrade process of Field-Programmable Devices (FPDs) associated with the Power Supply Unit (PSUs) on
the router. During the installation and PSU insertion process on the router, the FPDs associated with the PSUs are automatically
upgraded. Starting this release, the PSU FPDs are grouped in the form of a parent FPD and its related child FPDs, and the
upgrade image is downloaded only once. The upgrade is then triggered on the parent FPD PSU and replicated to the child FPD
PSUs.
In earlier releases, you downloaded the FPD image for each FPD associated with that PSU, and the upgrade process was then
triggered sequentially. This process was time-consuming.
The feature is supported on the following PSUs:
PSU2KW-ACPI
PSU2KW-HVPI
PSU3KW-HVPI
PSU4.8KW-DC100
From Cisco IOS XR Software Release 7.8.1, the PSU FPD upgrade is optimized. PSU FPDs are now grouped in the form of parent
PSU FPD which are related to the child PSU FPDs. The software image is downloaded once for the parent FPD and replicated to
the children FPDs in the same group. Prior to this release, for example, if a PSU with five FPDs that share the same image
across the FPDs needed a software upgrade, there were five upgrades triggered serially. As it is the same image which used
to get downloaded five times, one for each FPD. It was redundant and time consuming.
The parent and child FPDs contain the same group info. If upgrade is required on the parent or the child PSU FPD, the parent
FPD is added to the upgrade queue and the upgrade is triggered through CLI. Once upgrade is completed, the parent and child
FPD software versions are updated.
If you want to upgrade the software version for a FPD PSU which is not a parent, it gets blocked in CLI by the FPD server.
Note
You must disable auto FPD upgrade for PSUs before upgrading the router to Cisco IOS XR Software Release 7.9.1 or later if your router uses any of the following
PSUs:
PSU2KW-ACPI
PSU2KW-ACPE
PSU2KW-HVPI
PSU4.8KW-DC100
To disable auto FPD upgrade, use the following command:
Automatic FPD upgrade for PSUs is now enabled. In earlier releases, automatic upgrades did not apply to FPDs associated with
the PSUs.
During the installation and Power Supply Unit (PSU) insertion process, the Field-Programmable Devices (FPD) associated with
the PSUs are automatically upgraded.
Note
The PSUs are upgraded sequentially, hence the PSU FPD upgrades take longer. You can choose to exclude PSUs from the auto upgrade
flow. This restricts the PSUs from being upgraded either upon insertion, or during system upgrade.
To exclude the PSU FPDs from auto upgrading, use the following CLI:
fpd auto-upgrade exclude pm
RP/0/RSP0/CPU0:router# show running-config fpd auto-upgrade
Wed Mar 30 20:52:55.079 UTC
fpd auto-upgrade enable
fpd auto-upgrade exclude pm
Note
When you upgrade from an earlier unsupported version to a version that supports Automatic FPD upgrade for PSU, the PSU upgrade
might happen on bootup.
Auto upgrade support for SC/MPA
In Cisco 8000 Series Routers, the auto upgrade on bootup path is being supported for new CPU less cards SC and MPA.
The RP and SC cards together form a domain in Active and Standby nodes. The respective domain lead (RP) is responsible to
trigger the auto upgrade of respective SC cards.
Configuring the Compatibility Mode for Various ASIC Types
Table 11. Feature History Table
Feature Name
Release Information
Description
Configure Compatibility Mode for Q100 and Q200-based Line Cards
Release 7.7.1
You can now configure the compatibility behavior of line cards to operate in Q100 mode (default behavior) or in Q200 mode
when you have a mix of Q100-based line cards and Q200-based line cards that are installed in a router.
In earlier releases, in a mixed mode combination, where multiple generations of line cards were installed on a distributed
chassis, the behavior was to make the second-generation line cards interoperate with the first-generation line cards. However,
this led the NPUs to set lower resource limits for the newer generation line cards to ensure backward compatibility. Also,
the router didn't fully utilize the improved scale, higher capacity, and feature-rich capabilities of the newer generation
line cards.
This compatibility feature now enables you to select if you want the line cards to operate in Q100 or Q200 mode.
The hw-module profile npu-compatibility command is introduced for this feature.
In earlier releases, if you install a mix of Q100-based line cards and Q200-based line cards, the Q200-based line cards operate
in a scaled-down (Q100) mode by default.
The compatibility feature, applicable to Cisco 8800 Series modular/distributed chassis, now allows you to choose if you want
line cards to operate in Q100 (default behavior), Q200, or P100 mode. In Q200 mode, the router boots only the Q200-based line
cards and gracefully shuts down the Q100-based line cards.
For example, if a router has a Q100 ASIC family line card and you try to add a line card from the Q200 ASIC family, the Q200
ASIC line card operates in a scaled down mode to be able to work with the older generation-Q100 line cards. With the new implementation,
you can choose if you want the router to work in the Q100 mode or shutdown the Q100-based linecards, and use the Q200 ASIC
line cards in the Q200 mode.
FAQs About the New Implementation
Can the line cards still be used in scaled down mode, like in the previous scenario?
Yes, you can still switch to the previous implementation, if you may, to the scaled down mode.
What all ASICs can participate in the new implementation?
P100, Q200, and Q100
Is there any default ASIC set by the system?
The ASIC default is based on the Fabric Cards (FCs) and route processor cards used in a distributed chassis. However, you
can choose to change the ASIC mode to Q200, Q100, or P100.
Do I need to reboot the router after implementing a new ASIC line card?
Yes, reboot the router for the new ASIC line cards to take effect.
Usage Guidelines and Limitations
The following guidelines and limitations apply when you configure the line cards from different ASIC families:
By default, a mix of Q100, Q200, and P100 line cards results in the Q200 and P100 line cards operating in Q100 (scaled-down) mode. Configuring Q100 mode results in the same (default) behavior.
To be able to use the improved scale, higher capacity, and feature-rich capabilities of the Q200-based line cards, use the
hw-module profile npu-compatibility command and set it to operate in the Q200 mode. Else, the Q200-based line cards scale down to the Q100 mode, which is the
default behavior. The same behavior applies to the P100-based line cards.
Reboot the router for the compatibility mode to take effect. If the system detects a noncompatible line card, it shuts down
that line card. For example, in Q200 mode, the router boots only the Q200-based line cards and gracefully shuts down the Q100-based
line cards.
The hw-module profile npu-compatibility command isn't configurable on the Cisco 8100 and 8200 Series fixed chassis.
For 8800-RP, the default ASIC mode is Q100. For 8800-RP2, the default ASIC mode is Q200.
This table lists the Q100, Q200, and P100-based line cards that support the compatibility mode:
ASIC Family
Line Card
Q100-based line cards
8800-LC-48H
8800-LC-36FH
Q200-based line cards
88-LC0-34H14FH
88-LC0-36FH
88-LC0-36FH-M
P100-based line cards
88-LC1-36EH
Route Processor Card Behavior with ASICs
A newer generation Route Processor (RP) card takes precedence over an older generation RP card when installed from different
ASIC families. The precedence followed by the system is: P100 > Q200 > Q100.
If you have Q200-based line cards and an older generation RP card (8800-RP) installed on your router, the router sets the
ASIC mode for the line cards to Q100. However, you can change the ASIC mode from Q100 to Q200 by using the hw-module profile npu-compatibility command. Setting the ASIC mode to a newer generation ASIC allows you to utilize their improved scale, higher capacity, and
feature-rich capabilities when you replace your RPs with a newer generation RP.
For instance, if your chassis is equipped with an 8800-RP route processor card set to ASIC mode as Q200, upgrading to an 8800-RP2
RP card won't require changing the ASIC mode from Q100 to Q200.
Note
For 8800-RP, the default ASIC mode is Q100. For 8800-RP2, the default ASIC mode is Q200.
Line Card Behavior with ASICs
The following table explains how the various line cards take precendence when installed from different ASIC families. The
precedence followed by the system is: P100 > Q200 > Q100, where the newer generation line cards take precedence over an older generation line card.
ASIC Family of Installed Line Cards
Compatibility Mode Configured?
Compatibility Mode
Router Behavior during Bootup for the Line Cards
Q200 and Q100
N
Default (Q100)
Q200 line cards boot up and operate in Q100 mode, Q100 up.
Y
Q200
Q200 line cards boot up, Q100 line cards shut down.
Y
Q100
All line cards boot up, Q200 line cards operate in Q100 mode.
Q200 and Q200
N
Default (Q100)
Both the Q200 line cards boot up and operate in Q100 mode.
Y
Q200
Both the Q200 line cards boot up
Supported Compatibility Modes on Fabric Cards, RP Cards, and Line Cards
The following table details the fabric cards (FCs), the supported RP card (8800-RP) on the FCs, the default ASIC mode, the
line cards, and if you can configure the hw-module profile npu-compatibility command on those line cards:
Table 12. Compatibility Mode between Fabric Cards and 8800-RP
Fabric Card
Fabric Card ASIC
RP(8800-RP)
Default ASIC
Supported Line Cards
Configure NPU Compatibility?
8808-FC
8812-FC
8818-FC
Q100
Supported
Q100
Q100-based and Q200-based
Yes
You can configure the ASIC mode to Q200 if you have only Q200-based line cards installed on your chassis.
8804-FC0
Q200
Supported
Q100
Q100-based and Q200-based
Yes
You can configure the ASIC mode to Q200 if you have only Q200-based line cards installed on your chassis.
8808-FC1
F100
Not Supported
NA
NA
NA
The following table details the fabric cards (FCs), the supported RP card (8800-RP2) on the FCs, the default ASIC mode, the
line cards, and if you can configure the hw-module profile npu-compatibility command on those line cards:
Table 13. Compatibility Mode between Fabric Cards and 8800-RP2
Fabric Card
Fabric Card ASIC
RP(8800-RP2)
Default ASIC
Supported Line Cards
Configure NPU Compatibility?
8808-FC
8812-FC
8818-FC
Q100
Not Supported
NA
NA
NA
8812-FC0
Q200
Supported
Q200
Q200-based
NA
8808-FC1
F100
Supported
P100
P100-based
Yes
You can configure the ASIC mode to Q200 if you have both Q200-based and P100-based line cards installed on your chassis.
IP Forwarding Feature Support for Different ASICs and RPs
The following tables list the IP forwarding features supported on various ASIC combinations, such as Q100, Q200, P100, when
you have 8800-RP or 8800-RP1 route processor cards installed on your chassis.
This table lists the supported and unsupported features when you have Q100 and Q200 ASICs, and 8800-RP route processor card installed
on your chassis.
This table lists the supported and unsupported features when you have Q200 and P100 ASICs, and 8800-RP1 route processor card installed
on your chassis.
Table 14. IP Forwarding Feature Support on Q100 and Q200 ASICs with 8800-RP Card
To configure a router for handling line cards of different ASIC families, use the hw-module profile npu-compatibility command. To go back to the default mode, use the no form of this command.
The following are the options available in command and their descriptions:
npu-compatibility
Allows you to make a router compatible with an ASIC family.
mode-name
Allows you to set the mode, such as Q100, Q200, or P100.
The following is a configuration example:
Router:ios(config)#hw-module profile npu-compatibility q200
Tue Dec 7 15:06:53.697 UTC
Chassis mode will be activated after a manual reload of chassis/all line cards
Router:ios(config)#commit
Tue Dec 7 15:06:54.646 UTC
LC/0/1/CPU0:Dec 7 15:06:54.796 UTC: npu_drvr292:
%FABRIC-NPU_DRVR-3-HW_MODULE_PROFILE_NPU_COMPATIBILITY_CHASSIS_CFG_CHANGED : Please reload
chassis for the configuration to take effect
end
Router:ios(config)#end
Router:ios#
Running Configuration
RP/0/RP0/CPU0:ios# show ver
Mon Jun 27 19:25:52.947 UTC
Cisco IOS XR Software, Version 7.7.1.27I LNT
Copyright (c) 2013-2022 by Cisco Systems, Inc.
Build Information:
Built By : ingunawa
Built On : Wed Jun 01 23:50:09 UTC 2022
Build Host : iox-ucs-060
Workspace : /auto/iox-ucs-060-san1/prod/7.7.1.27I.SIT_IMAGE/8000/ws
Version : 7.7.1.27I
Label : 7.7.1.27I
cisco 8000 (VXR)
cisco 8808 (VXR) processor with 32GB of memory
ios uptime is 3 minutes
Cisco 8808 8-slot Chassis
RP/0/RP0/CPU0:ios#
RP/0/RP0/CPU0:ios# conf
Mon Jun 27 19:24:40.621 UTC
RP/0/RP0/CPU0:ios(config)# hw-module profile npu-compatibility ?
Q100 Use Q100 for Chassis mode
Q200 Use Q200 for Chassis mode
Verification
RP/0/RP0/CPU0:ios# show hw-module profile npu-compatibility matrix
Mon Jun 27 19:41:47.560 UTC
Node Card Type NPU Type
-------------------------------------------------------
0/0/CPU0 8800-LC-48H Q100
Compatibility Compatibility
NPU Type Mode Q100 Mode Q200
------------------------------------------------
Q100 Compatible Not Compatible
Q200 Compatible Compatible
Default mode: Q100
RP/0/RP0/CPU0:ios# show hw-module profile npu-compatibility
Mon Jun 27 19:41:59.318 UTC
--------------------------------------------------------------
Knob Status Applied Action
--------------------------------------------------------------
npu_compatibility Unconfigured N/A None
RP/0/RP0/CPU0:ios#
Storage Media Sanitization
Table 16. Feature History Table
Feature Name
Release Information
Feature Description
Storage Media Sanitization
Release 7.5.1Release 7.3.4
To comply with NIST SP 800-88 guidelines for Media Sanitization, it is important that your organization ensures that no easily
reconstructible data is stored in the router and associated devices after it has left the control of your organization or
is no longer protected by confidentiality categorization.
With this feature, you can erase and overwrite any sensitive data, configuration, or keys present in the route processor or
line card, ensuring media sanitization and preventing unauthorized data retrieval.
When you identify an RP or line card for RMA, or you require to ship it outside your organization, a service personnel may
not be available on-site to remove the card immediately. However, you can reset your RP or line card to erase customer-sensitive
data and let the RP or line card remain in the slot. The RP or line card shuts down automatically after the factory reset is complete.
Guidelines
We recommend using factory-reset without performing commit replace for securely removing the files in the misc/config folder.
The RP or line card shuts down automatically if the factory reset takes more than 30 minutes, you can perform the factory
reset again. The console displays the following log message during automatic shutdown:
[ TIME ] Timed out starting Power-Off.
[ !! ] Forcibly powering off as result of failure.
If your router has dual RPs, and to perform the factory reset on both the RPs, first reset the standby RP from the active
RP. After the reset is complete, the standby RP automatically shuts down, you can then reset the active RP.
Prerequisites
The RP or line card must be operational to perform factory reset.
Commands
Use the factory-reset command for erasing the following folders of RP or line card:
/misc/disk1
/misc/scratch
/var/log
/misc/config
Run the following command through the console port of the router to erase customer-sensitive data in the RP or line card:
factory-reset location <location-id> - erases customer-sensitive data in the specified location
Note
Factory-reset logs are displayed on the console port of the node where the reset is performed.
The following steps explain how to reset your RP or line card to factory settings:
Erasing the RP or line card folder contents: Run the factory-reset location command to delete the encryption keys and erase the customer-sensitive data from the RP or line card.
The following example shows how to perform the factory-reset command on an RP:
Router#factory-reset location 0/RP1/CPU0
Factory reset requested
Started punching watchdog
Started cleaning up mount point: /misc/scratch
Started syncing folder: /misc/scratch
Finished syncing folder: /misc/scratch
Finished cleaning up mount point: /misc/scratch
factory_reset_stop.sh
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up mount point: /var/log
Started syncing folder: /var/log
Finished syncing folder: /var/log
Finished cleaning up mount point: /var/log
factory_reset_stop.sh
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up mount point: /misc/disk1
Started syncing folder: /misc/disk1
Finished syncing folder: /misc/disk1
Finished cleaning up mount point: /misc/disk1
factory_reset_stop.sh
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up folder: /misc/config
UTC 2022 Started syncing folder: /misc/config
Finished syncing folder: /misc/config
Finished cleaning up folder: /misc/config
factory_reset_stop.sh
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up folder: /var/xr/enc/misc/config
/var/xr/enc/misc/config not present
Finished cleaning up folder: /var/xr/enc/misc/config
factory_reset_stop.sh
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up folder: /mnt/rootfs/misc/config
/mnt/rootfs/misc/config not present
Finished cleaning up folder: /mnt/rootfs/misc/config
factory_reset_stop.sh
+++++++++++++++++++++++++++++++++++++++++++++++
Encrypted logical volume does not exist. Nothing to remove.
/usr/local/etc/fpga-functions: line 797: 10912 Terminated
/usr/local/etc/punch-wd.sh
Stopped punching watchdog
Verifying factory reset: Use the show shelfmgr history events location command to verify the successful completion of the factory-reset in the standby RP or line card.
The following example shows how to verify the factory-reset command:
RP/0/RP0/CPU0:Router#show shelfmgr history events location 0/RP1/CPU0
Tue Mar 15 01:45:56.402 UTC
NODE NAME : 0/RP1/CPU0
CURRENT STATE : CARD_SHUT_POWERED_OFF
TIME STAMP : Mar 15 2022 01:44:47
--------------------------------------------------------------------------------
DATE TIME (UTC) EVENT STATE
--------------------------------------------------------------------------------
Mar 15 2022 01:44:47 ev_powered_off CARD_SHUT_POWERED_OFF
Mar 15 2022 01:44:47 transient_condition CARD_SHUTDOWN
Mar 15 2022 01:44:47 ev_check_card_down_reaso CHECKING_DOWN_REASON
Mar 15 2022 01:44:47 ev_os_halted OS_HALTED
Mar 15 2022 01:44:43 ev_factory_reset_done FACTORY_RESET_DONE
Mar 15 2022 01:33:16 ev_factory_reset_started FACTORY_RESET_IN_PROGRESS
Mar 15 2022 01:33:11 ev_os_halting OS_HALT_IN_PROGRESS
Mar 15 2022 01:33:10 ev_xr_shut START_OS_HALT
Mar 15 2022 01:33:09 ev_ack_ok STATE_NOT_CHANGED
Mar 15 2022 01:33:09 ev_graceful_shut CARD_SHUTDOWN_IN_PROGRESS
Mar 15 2022 00:55:31 ev_xr_ready XR_RUN
Commands
Use the factory-reset command for erasing the following folders of RP or line card:
/misc/disk1
/misc/scratch
/var/log
/misc/config
Run the following command through the console port of the router to erase customer-sensitive data in the RP or line card:
factory-reset { reload | shutdown } location <location-id> - erases customer-sensitive data in the specified location. Use the reload option in the command to reload the RP or line
card after the factory reset and use the shutdown option to shut down the RP or line card after the factory reset.
Note
Factory-reset logs are displayed on the console port of the node where the reset is performed.
The following steps explain how to reset your RP or line card to factory settings:
Erasing the RP or line card folder contents: Run the factory-reset { reload | shutdown } location command to delete the encryption keys and erase the customer-sensitive data from the RP or line card.
The following example shows how to perform the factory-reset shutdown command on an RP:
Router#factory-reset shutdown location 0/RP1/CPU0
Factory reset requested
Started punching watchdog
Started cleaning up mount point: /misc/scratch
Started syncing folder: /misc/scratch
Finished syncing folder: /misc/scratch
Finished cleaning up mount point: /misc/scratch
factory_reset_stop.sh
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up mount point: /var/log
Started syncing folder: /var/log
Finished syncing folder: /var/log
Finished cleaning up mount point: /var/log
factory_reset_stop.sh
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up mount point: /misc/disk1
Started syncing folder: /misc/disk1
Finished syncing folder: /misc/disk1
Finished cleaning up mount point: /misc/disk1
factory_reset_stop.sh
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up folder: /misc/config
UTC 2022 Started syncing folder: /misc/config
Finished syncing folder: /misc/config
Finished cleaning up folder: /misc/config
factory_reset_stop.sh
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up folder: /var/xr/enc/misc/config
/var/xr/enc/misc/config not present
Finished cleaning up folder: /var/xr/enc/misc/config
factory_reset_stop.sh
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up folder: /mnt/rootfs/misc/config
/mnt/rootfs/misc/config not present
Finished cleaning up folder: /mnt/rootfs/misc/config
factory_reset_stop.sh
+++++++++++++++++++++++++++++++++++++++++++++++
Encrypted logical volume does not exist. Nothing to remove.
/usr/local/etc/fpga-functions: line 797: 10912 Terminated
/usr/local/etc/punch-wd.sh
Stopped punching watchdog
The following example shows how to perform the factory-reset reload command on an RP:
Router#factory-reset reload location 0/RP1/CPU0
Factory reset requested
Started punching watchdog
Started cleaning up mount point: /misc/scratch
Started syncing folder: /misc/scratch
Finished syncing folder: /misc/scratch
Finished cleaning up mount point: /misc/scratch
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up mount point: /var/log
Started syncing folder: /var/log
Finished syncing folder: /var/log
Finished cleaning up mount point: /var/log
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up mount point: /misc/disk1
Started syncing folder: /misc/disk1
Finished syncing folder: /misc/disk1
Finished cleaning up mount point: /misc/disk1
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up folder: /misc/config
Started syncing folder: /misc/config
Finished syncing folder: /misc/config
Finished cleaning up folder: /misc/config
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up folder: /var/xr/enc/misc/config
/var/xr/enc/misc/config not present
Finished cleaning up folder: /var/xr/enc/misc/config
+++++++++++++++++++++++++++++++++++++++++++++++
Started cleaning up folder: /mnt/rootfs/misc/config
/mnt/rootfs/misc/config not present
Finished cleaning up folder: /mnt/rootfs/misc/config
+++++++++++++++++++++++++++++++++++++++++++++++
Encrypted logical volume does not exist. Nothing to remove.
/usr/local/etc/fpga-functions: line 790: 4137 Terminated
/usr/local/etc/punch-wd.sh
Stopped punching watchdog
Verifying factory reset: Use the show shelfmgr history events location command to verify the successful completion of the factory-reset in the standby RP or line card.
The following example shows how to verify the factory-reset shutdown command:
RP/0/RP0/CPU0:Router#show shelfmgr history events location 0/RP1/CPU0
Tue Mar 15 01:45:56.402 UTC
NODE NAME : 0/RP1/CPU0
CURRENT STATE : CARD_SHUT_POWERED_OFF
TIME STAMP : Mar 15 2022 01:44:47
--------------------------------------------------------------------------------
DATE TIME (UTC) EVENT STATE
--------------------------------------------------------------------------------
Mar 15 2022 01:44:47 ev_powered_off CARD_SHUT_POWERED_OFF
Mar 15 2022 01:44:47 transient_condition CARD_SHUTDOWN
Mar 15 2022 01:44:47 ev_check_card_down_reaso CHECKING_DOWN_REASON
Mar 15 2022 01:44:47 ev_os_halted OS_HALTED
Mar 15 2022 01:44:43 ev_factory_reset_done FACTORY_RESET_DONE
Mar 15 2022 01:33:16 ev_factory_reset_started FACTORY_RESET_IN_PROGRESS
Mar 15 2022 01:33:11 ev_os_halting OS_HALT_IN_PROGRESS
Mar 15 2022 01:33:10 ev_xr_shut START_OS_HALT
Mar 15 2022 01:33:09 ev_ack_ok STATE_NOT_CHANGED
Mar 15 2022 01:33:09 ev_graceful_shut CARD_SHUTDOWN_IN_PROGRESS
Mar 15 2022 00:55:31 ev_xr_ready XR_RUN
The following example shows how to verify the factory-reset reload command:
RP/0/RP0/CPU0:Router#show shelfmgr history events location 0/RP0/CPU0
Tue Mar 15 01:45:56.402 UTC
NODE NAME : 0/RP0/CPU0
CURRENT STATE : CARD_SHUT_POWERED_OFF
TIME STAMP : Mar 15 2022 01:44:47
--------------------------------------------------------------------------------
DATE TIME (UTC) EVENT STATE
--------------------------------------------------------------------------------
Jun 29 2022 13:48:34 ev_xr_ready XR_RUN
Jun 29 2022 13:48:10 ev_card_info_rcvd CARD_INFO_RCVD
Jun 29 2022 13:47:52 ev_xr_init XR_INITIALIZING
Jun 29 2022 13:47:44 ev_kernel_booting STATE_NOT_CHANGED
Jun 29 2022 13:47:14 ev_kernel_booting KERNEL_BOOTING
Jun 29 2022 13:46:53 ev_unmapped_event STATE_NOT_CHANGED
Jun 29 2022 13:46:53 ev_bios_started BIOS_STARTED
Jun 29 2022 13:46:51 ev_bios_ready BIOS_READY
Jun 29 2022 13:46:10 ev_unmapped_event STATE_NOT_CHANGED
Jun 29 2022 13:46:10 ev_powered_on CARD_POWERED_ON
Jun 29 2022 13:46:05 ev_card_reset_done CARD_RESET
Jun 29 2022 13:46:05 transient_condition CARD_RESETTING
Jun 29 2022 13:46:05 ev_check_card_down_reaso CHECKING_DOWN_REASON
Jun 29 2022 13:46:05 ev_os_halted OS_HALTED
Jun 29 2022 13:45:50 ev_factory_reset_done FACTORY_RESET_DONE
Jun 29 2022 13:34:09 ev_factory_reset_started FACTORY_RESET_IN_PROGRESS
Jun 29 2022 13:33:59 ev_os_halting OS_HALT_IN_PROGRESS
Jun 29 2022 13:33:58 ev_xr_shut START_OS_HALT
Jun 29 2022 13:33:56 ev_graceful_reload CARD_SHUTDOWN_IN_PROGRESS
Jun 29 2022 09:18:43 ev_xr_ready XR_RUN
Jun 29 2022 09:17:37 ev_card_info_rcvd CARD_INFO_RCVD
Jun 29 2022 09:17:32 ev_powered_on CARD_POWERED_ON
Jun 29 2022 09:17:31 init CARD_DISCOVERED
Excluding Sensitive Information in Show Running Configurations Output
Table 17. Feature History Table
Feature Name
Release Information
Feature Description
Excluding Sensitive Information in Show Running Configurations Command Output
Release 7.5.4
You can now exclude sensitive information such as strings, usernames, passwords, comments, or IP addresses within the show running-configuration command output by enabling sanitization on the nonvolatile generation (NVGEN) process.
With this feature, you can achieve better data protection to prevent cybersecurity risks compared to regular router algorithms.
The show running configuration command uses the nonvolatile generation (NVGEN) process in IOS-XR software to collect configuration information from every
system component and construct a running configuration file to create its output. However, this file may contain sensitive
information, including usernames, passwords, and IP addresses, which could pose a security threat when obfuscation algorithms
in the router are weak compared to modern cryptographic standards.
In this feature, you can mask the following types of sensitive information in the show running configurations:
Strings
Usernames
Passwords
Comments
IP Addresses
On enabling the sanitization in show running configurations, the NVGEN process replaces the corresponding information with
<removed> string. For example, if you enable sanitization for IP Addresses, the show running configuration includes the <removed> string in place of all the IP Addresses in the output.
Forward error correction (FEC) is a method for obtaining error control in data transmission in which the transmitter sends
redundant data and the receiver recognizes only the portion of the data that contains no apparent errors. When FEC is used
in data transmissions, the receiver can detect and correct a limited number of errors.
The Cisco IOS XR router will not bring the link to the data plane if the link is noisy at inception (during bring up). If
the link becomes noisy post bring up, fabric link will be re-set and re-tuned. If this event continues for five times with
in an hour then fabric link will be shutdown permanently. Post link up, polling interval for link error is 10 minutes.
Fabric link management feature uses FEC as the criteria to determine if a link is good. The router receives a notification
for every bad FEC on each fabric port. FEC can correct up to 15 bits beyond which the error is considered as uncorrectable
error. This feature allows you to make fabric links run error-free.
Note
In Cisco IOS XR Release 24.2.11, this feature is enabled only for Q200 based line cards and Fabric cards.
FEC bin index
FEC bin index indicates the number of bit errors.
For example, FEC bin index of a good link is {12642341946,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,} and for a bad link it is {221568554,532162,414888,101277,144171,3317,61681,4065,741,1977586,138,62,17,6,1,}.
If the FEC bin index more or equal to ten non-zero bits (bin >= 10 non-zero) before the link is up, then the FEC will show
the link as bad FEC. When the link is up and the FEC bin index more or equal to 13 non-zero bits (bin >= 13 non-zero), the
FEC will show the link as bad FEC.
Link States for a Noisy Fabric Link
When there is a noisy fabric link, any one of the following link states can be possible:
Link does not come up at all.
Link comes up, but fluctuates.
Link comes up, but generates uncorrectable errors.
The network traffic flow is not impacted if the link never comes up and there will be packet drops observed for the other
two states of the link mentioned above.
Monitor FEC Fabric Links
For every FEC report, the router performs the following process to monitor the fabric links:
If the fabric link is faulty before the link is up, the router will retune and checks again for the FEC improvement.
If the link quality does not improve after retuning, the router displays the syslog message after tuning for 100 times and
will not bring the link to the data plane.
Post link up, when the fabric link becomes noisy, the router will collect a snapshot and retune after the first failure.
From second failure to fifth failure, the MAC port will be stopped and re-activated (retune will be done as part of this process).
If the fabric link fails for the sixth time within an hour, the router will permanently shut down the link.
Verify the FEC Links
Verify the FEC link information using show controllers npu link-info command.
router#show controllers npu link-info rx 254 255 fsm instance 0 location 0/2/CPU0 detail
Sat Jan 13 00:39:49.448 UTC
Node ID: 0/2/CPU0
Link ID: 0/2/0/254 255 Oper State: DOWN 0/FC1/2/158
Event State Timestamp
+--------------------------------------------------------------------------------+
LINK_UP_INTR UP Sat Jan 13 00:18:44 2018
BAD_FEC_BELOW_THR PORT_ACTIVATE_DELAYED Sat Jan 13 00:19:16 2018
LINK_MON FAB_PORT_CREATED Sat Jan 13 00:19:17 2018
LINK_MON ACTIVATED Sat Jan 13 00:19:19 2018
LINK_UP_INTR MAC_UP Sat Jan 13 00:19:24 2018
LINK_UP_INTR PEER_DISCOVERY Sat Jan 13 00:19:24 2018
LINK_UP_INTR PEER_DETECTED Sat Jan 13 00:19:24 2018
LINK_UP_INTR TOPOLOGY_CHECK Sat Jan 13 00:19:24 2018
LINK_UP_INTR SYNC_WAIT Sat Jan 13 00:19:24 2018
LINK_UP_INTR KEEPALIVE_START Sat Jan 13 00:19:24 2018
LINK_UP_INTR CHECK_REACH Sat Jan 13 00:19:24 2018
LINK_UP_INTR UP Sat Jan 13 00:19:24 2018
BAD_FEC UP Sat Jan 13 00:20:16 2018
DIS_PERM_SHUT MAC_UP Sat Jan 13 00:20:16 2018
DIS_PERM_SHUT STOPPED Sat Jan 13 00:20:16 2018
+--------------------------------------------------------------------------------+
This table describes the significant fields shown in the above example.
Table 19. show controllers npu link-info Field Descriptions
Field
Description
BAD_FEC_BELOW_THR
There are FEC failures, but the number of failures has not exceeded the predefined threshold (in this case, 5 per hour). The
router retunes and checks for FEC improvement.
BAD_FEC
This part of the log entry indicates that FEC detected failures, and the number of these failures surpassed a predefined threshold.
As a result, the decision was made to permanently shut down the affected interface or port as a protective measure.
DIS_PERM_SHUT
The link or port has been intentionally disabled and is in a shutdown state after FEC fails for the threshold limit (After
fifth failure).
System Log messages
The router displays the following syslog messages after retuning:
If the link is noisy at inception (during bring up), the router displays the following syslog message after tuning for 100
times:
LC/0/2/CPU0:Jan 13 00:56:03.939 UTC: npu_drvr[128]: %FABRIC-NPU_DRVR-3-NPU_CPA_GEN_ERR_INFO : Link 0/254 has tuned 100 times and failed to come up. FEC bin is filled to 11
If the link is noisy post bring up, the router permanently shuts down the link and displays the following syslog message:
LC/0/2/CPU0:Jan 13 00:20:16.251 UTC: npu_drvr[128]: %FABRIC-NPU_DRVR-3-NPU_CPA_GEN_ERR_INFO : FEC check failures on link 0/254. FEC bin is filled to 14
Disable Fabric Link Management for Uncorrectable Errors
Fabric link management for uncorrectable errors is enabled by default. To disable this feature, use the hw-module fabric-fec-monitor disable command in XR Config mode mode.
The following example shows how to disable the fabric FEC monitor:
You can now configure the number of fault recovery attempts by a line card, fabric card or a route processor before it permanently
shuts down, thus preventing a faulty card from entering into a cycle of automatic recovery.
In the previous releases, if a line card, fabric card or a route processor experienced a fault, they used to trigger fault
recovery and reboot themselves to be operational. Fault recovery mechanism was time based as the fault recovery count used
to reset to zero if the card remained operational for more than hour. After the fault recovery count exceeded five, then the
faulty card was shut down. As power related faults triggered were not frequent, and fault recovery count used to reset to
zero, the card never entered the shut down mode. As a result the card always attempted for fault recovery.
With the Cisco IOS XR Software Release 24.2.11, we have introduced the hw-module fault-recovery command with which you can set the number of times a fault recovery can take place before permanently shutting down a faulty
card.
Note
This configuration is not applicable for BMC instance
How to Configure the Fault Recovery Attempts
Configuration Examples
The configuration example shows how to configure the fault recovery attempts on the fabric card FC0.
Use the show reboot history command to get the reason of card shutting down. In the following example, it shows that the card was shut down due to Fault retry attempts exceeded configured count(1).
RP/0/RP0/CPU0:ios#show reboot history location 0/FC0 detail
Mon Dec 4 15:44:55.827 PST
--------------------------------------------------------------------------------
No Attribute Value
--------------------------------------------------------------------------------
1 Time (PST) Dec 04 2023 15:44:22
Cause Code 0x0800000d
Cause String REBOOT_CAUSE_FM
Graceful Reload No
Kdump Requested No
Reason Fault retry attempts exceeded configured count(1)
Use the show platform command to see the current state of the card that was shut down because of Fault recovery handling feature.
RP/0/RP0/CPU0:ios#show platform
Mon Oct 2 21:08:03.383 UTC
Node Type State Config state
--------------------------------------------------------------------------------
0/RP0/CPU0 8800-RP(Active) IOS XR RUN NSHUT
0/RP0/BMC0 8800-RP OPERATIONAL NSHUT
0/RP1/CPU0 8800-RP(Standby) IOS XR RUN NSHUT
0/RP1/BMC0 8800-RP OPERATIONAL NSHUT
0/3/CPU0 8800-LC-48H IOS XR RUN NSHUT
0/FC0 8812-FC SHUT DOWN NSHUT
0/FC3 8812-FC OPERATIONAL NSHUT
0/FT0 SF-D-12-FAN OPERATIONAL NSHUT
0/FT1 SF-D-12-FAN OPERATIONAL NSHUT
0/FT2 SF-D-12-FAN OPERATIONAL NSHUT
0/FT3 SF-D-12-FAN OPERATIONAL NSHUT
0/PT0 FAM7000-ACHV-TRAY OPERATIONAL NSHUT
0/PT1 FAM7000-ACHV-TRAY OPERATIONAL NSHUT
0/PT2 FAM7000-ACHV-TRAY OPERATIONAL NSHUT
Router#