The system boot process is governed by StarOS licenses. During the startup process, each card performs a series of Power-On Self Tests (POSTs) to ensure that the hardware is operational. These tests also verify that the card meets all license requirements to operate in this chassis.

Refer to Chassis Universal License Requirements in the ASR 5500 Installation Guide for additional information on the effect licenses and card types have on the boot process.

Status LEDs for all cards can be viewed via the CLI by entering the Exec mode show leds all command.

[local]host_name# show leds all

The following displays a sample of this command's output.

Slot 01: Run/Fail: Green | Active: Off    | Redundant: Green
Slot 02: Run/Fail: Green         | Active: Off    | Redundant: Green
Slot 03: Run/Fail: Green         | Active: Off    | Redundant: Green
Slot 05: Run/Fail: Green         | Active: Green  | Redundant: Green    Master: Green
Slot 06: Run/Fail: Green         | Active: Off    | Redundant: Green    Master:Off
Slot 08: Run/Fail: Green         | Active: Off    | Redundant: Green
Slot 11: Run/Fail: Green         | Active: Green  | Redundant: Green    Status: Green  | Service: Off 
Slot 12: Run/Fail: Green         | Active: Green  | Redundant: Green    Status: Green  | Service: Off 
Slot 13: Run/Fail: Green         | Active: Green  | Redundant: Green
Slot 14: Run/Fail: Green         | Active: Green  | Redundant: Green
Slot 15: Run/Fail: Green         | Active: Green  | Redundant: Green
Slot 16: Run/Fail: Green         | Active: Green  | Redundant: Green
Slot 17: Run/Fail: Green         | Active: Green  | Redundant: Green

The status of the two Power Filter Units (PFUs) can be viewed by entering the Exec mode show power chassis command.

Each PFU has four LEDs along the top edge of its front panel. You must unsnap the top front cover from the chassis to view these LEDs. Each LED is associated with one of the four -48 VDC power feeds connected to the PFU.

Each LED on the PFU should illuminate blue for normal operating conditions.

Figure 1. PFU LEDs

Each MIO/UMIO is equipped with the following LEDs:

Figure 2. MIO Card Status LEDs

The possible states for all MIO/UMIO LEDs are described in the sections that follow.

Each DPC/UDPC or /DPC2/UDPC2 is equipped with status LEDs as listed below:

Figure 3. DPC Status LEDs

The possible states for all of the DPC/UDPC or /DPC2/UDPC2 LEDs are described in the sections that follow.

Each FSC is equipped with the following LEDs as shown in the accompanying figure:

Figure 4. FSC Status LEDs

The possible states for all FSC LEDs are described in the sections that follow.

Each SSC is equipped with the following LEDs as shown in the accompanying figure:

Figure 5. SSC Status LEDs

The possible states for all SSC LEDs are described in the sections that follow.

[local]host_name# test alarm { audible | central-office [ critical | major | minor ] }

When this command is executed, the specified alarm is activated for a period of 10 seconds. After this time, the alarm will return to its previous condition.

When the system boots up, the MIO/UMIO installed in chassis slot 5 will boot into the Active mode and begin booting other system components. The MIO/UMIO installed in chassis slot 6 will automatically be booted into Standby mode dictating that it will serve as a redundant component. The active MIO/UMIO automatically synchronizes currently running tasks or processes with the standby MIO/UMIO.

In the event of a critical failure on the MIO/UMIO in slot 5, system control will be automatically switched to the standby MIO/UMIO in slot 6. This is a relatively seamless transition because the two are synchronized. The formerly active MIO will then enter the standby mode allowing it to be safely replaced or restored.

In the event that an issue arises that is not severe enough for the system to perform an automatic switchover, a manual switchover can be invoked by executing the following commands from the Exec mode prompt.

This busy-out command moves processes from the source DPC/UDPC or DPC2/UDPC2 to the destination DPC/UDPC or DPC2/UDPC2, or disables the DPC/UDPC or DPC2/UDPC2 from accepting any new calls. When busy-out is enabled, the DPC/UDPC or DPC2/UDPC2 stops receiving new calls but continues to process calls until they are completed. The command prompt is returned once the command is initiated. The busy-out procedure is completed in background.

When the system boots up, all DPC/UDPCs or DPC2/UDPC2s enter the "standby" mode. The standby mode indicates that the card is available for use but is not configured for operation. Installed components can be made active through the software configuration process. Cards that are not configured to enter the "active" mode will remain in standby mode for use as redundant components.

In the event of the critical failure of a DPC/UDPC or DPC2/UDPC2, tasks will be automatically be migrated from the active card to a redundant card in standby mode.

In the event that an issue arises that is not severe enough for the system to perform an automatic migration, a manual migration can be initiated. Follow the instructions below to manually initiate a DPC/UDPC or DPC2/UDPC2 migration. These instructions assume you are at the root prompt for the Exec mode.

Cards other than MIO/UMIOs that are in either the Active or Standby modes can be halted. Halting these cards places them into the "offline" mode. In this mode, the card is unusable for session processing as either an active or redundant component.

If a card in the active mode is halted, its tasks, processes, or network connections will be migrated or switched to a redundant component prior to entering the offline mode.

This section describes how to initiate a card halt and restore halted components.

The ping or ping6 command verifies the system's ability to communicate with a remote node in the network by passing data packets between and measuring the response. This command is useful in verifying network routing and if a remote node is able to respond at the IP layer.

The traceroute or traceroute6 command collects information on the route data will take to a specified host. This is a useful troubleshooting command that can be used to identify the source of significant packet delays or packet loss on the network. This command can also be used to identify bottle necks in the routing of data over the network.

The system provides a mechanism for viewing route information to a specific node or for an entire context. This information can be used to verify network connectivity and to ensure the efficiency of the network connection. The command has the following syntax:

show ip route [ route_ip_address ]
show ipv6 route [ route_ipv6_address ] ]

For complete information on the above commands, see the Exec Mode show Commands chapter of the Command Line Interface Reference.

If no keywords are specified, all IP routes within the context's routing table are displayed.

The following displays a sample of this command's output showing a context IPv4 routing table.

"*" indicates the Best or Used route.
  Destination     Nexthop     Protocol    Prec    Cost    Interface
*0.0.0.0/0        10.0.4.1    static      0       0       SPIO1
*10.0.4.0/24      0.0.0.0     kernel      0       0       SPIO1
*10.0.4.0/32      0.0.0.0     kernel      0       0       SPIO1
*10.0.4.3/32      0.0.0.0     kernel      0       0       SPIO1
*10.0.4.255/32    0.0.0.0     kernel      0       0       SPIO1

The system provides a mechanism for viewing Address Resolution Protocol (ARP) table information to a specific node or for an entire context. This information can be used to verify that when the system sends an ARP packet, it receives valid responses from other network nodes.

[local]host_name# show ip arp [ arp_ip_address ]

arp_ip_address specifies a specific network node for which to display ARP information. The address can be entered in IPv4 dotted-decimal or IPv6 colon-separated-hexadecimal notation. If this keyword is not specified, all entries within the context's ARP table are displayed.

The following displays a sample of this command's output showing a context's ARP table.

Flags codes:
C - Completed, M - Permanent, P - Published, ! - Not answered
T - has requested trailers
Address         Link Type    Link Address          Flags    Mask Interface
10.0.4.240      ether        00:05:47:02:20:20     C        MIO1
10.0.4.7        ether        00:05:47:02:03:36     C        MIO1
10.0.4.1        ether        00:01:30:F2:7F:00     C        MIO1

For troubleshooting purposes, the system provides a protocol monitoring utility. This tool displays protocol information for a particular subscriber session or for every session being processed.

Caution

The monitor tool may cause session processing delays and/or data loss. Therefore, it should be used only when troubleshooting.

The protocol monitor displays information for every session that is currently being processed. Depending on the number of protocols monitored, and the number of sessions in progress, a significant amount of data is generated. It is highly recommended that logging be enabled on your terminal client in order to capture all of the information that is generated.

Follow the instructions below83 to invoke and configure the protocol monitoring tool.