This document is about the most common cause of the CRIT Error LED on the ASR1000 platform. In practice this error is usually encountered when the router is being configured for the first time and the connections have been configured but not brought up yet. An example of the ominous indicator LED is shown to the left.
Frequently it is found that there is a port that is in a hot state but is disconnected or down/down for some reason. In other words, the interface has been configured and had the default shutdown cleared, but for some reason the interface is still down. (Reasons include fiber disconnected, other end admin down, transceiver not inserted yet, etc.)
This scenario can be easily verified by looking for the following symptoms:
Compare the running configuration show run of the device with the interface status while paying special attention to the interfaces not configured with shutdown. Then compare that with the current state of interfaces on the router show interface
*output removed preceding*
ip address 10.10.10.1 255.255.255.0
no ip address
*output removed following*
GigabitEthernet0/0/0 is down, line protocol is down
GigabitEthernet0/0/1 is administratively down, line protocol is down
Then perform a show facility-alarms status which, in this scenario, will show something like:
router#show facility-alarm status System Totals Critical: 1 Major: 0 Minor: 0
Source Severity Description [Index] ------ -------- ------------------- GigabitEthernet0/0/0 CRITICAL Physical Port Link Down  xcvr container 0/0/1 INFO Transceiver Missing  xcvr container 0/0/2 INFO Transceiver Missing 
This critical facility alarm is what is causing the system status. Please note that this behavior is intentional, not a bug. The ASR series is used primarily by ISPs who need to know immediately if an interface is disconnected for any reason. (ie someone in the datacenter accidentally bumping a cable, etc.) For an ISP any disconnect could cause an outage for hundreds or thousands of customers, hence it is critical.
Now that you know what is causing the alarm in this case you basically have two choices. You can place the interface that is causing the status into admin down until you turn up the interface and place it into testing or production. (ie in config-interface perform shutdown) This is preffered. You could also just ignore the error, although I wouldn't suggest it unless you're going to be turning up the interface in the next couple minutes. If you have another critical issue you won't know the difference, via the LED indicators in any case.
Finally, clearing the alarms with clear facility-alarm most likely won't work unless the state of the interface(s) has changed either to admin down or up/up because the alarm will just be thrown again in a couple of seconds. When the interface(s) are in a preferred state this alarm (LED indicator) should clear automatically.
Hi all, I am having issues pinging components outside of the routers that are directly connected to the Multiuser Connection node. I've already set up a DNS service in the HQ network and have assigned a DNS IP address to the DHCP server pools as well as a...
What am I doing wrong/missing here folks? Two switches with a port channel between them. On switch 1, VLAN 66 has an IP of 192.168.66.251, on switch 2, VLAN 66 has an IP of 192.168.66.247. I have the VLAN allowed on the port channel but neither switch can...
Hi all,I am new to Cisco and trying to do some learning by doing, please advice me on how to go:Background:Our Cisco is provided with following setting:+ Connection to Internet on Interface Dialer0 and provided with static ip 220.127.116.11+ Inside Interf...
Hi Everyone,I have 2 queries1. After we configure the IPSec VPN in a Cisco Router, how do we identify and check that the traffic is flowing through the tunnel? Are there any commands and ways to find it out?2. What are some of t...