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 Team,I need some advice: I plan to replace the inter-vlan routing from firewall and implement it to the switch.I'm a Security Engineer and I have some skill to NetworkI have the following infra:- a stack of 3 switch of SG350- a SMB firewall that handle...
Hi,In a multi area like this where if we have a direct link from R5 to R7 and R6, we will have a shorter faster path to those routers, how should we fit it in with ospf protocol definition?I can't come up with any solution other than merging area 1 and 2?...
Hello, If I use Nexus 6ks and 5ks with 2k FEX, and SFP-10G x2 Port-channels, how should I find out how much bandwidth I am gonna lose from my links for hello intervals? and how low I can go for hello intervals for the fastest convergence? thanks...
Hi, Can someone help me understand why my native vlan was set to (inactive). and I get an error on both switch device sayingCDP-W-NATIVE_VLAN_MISMATCH: interface gi6.Native VLAN mismatch detected on interface gi6. If you have a fix please l...