Dying Gasp Through SNMP, Syslog and Ethernet OAM

Dying Gasp—One of the following unrecoverable condition occurs:

  • System reload

  • Interface shutdown

  • Power failure—supported on specific platforms

This type of condition is vendor specific. An Ethernet Operations, Administration, and Maintenance (OAM) notification about the condition may be sent immediately.

Prerequisites for Dying Gasp Support

You must enable Ethernet OAM before configuring Simple Network Management Protocol (SNMP) for dying gasp feature. For more information, see Enabling Ethernet OAM on an Interface.

Restrictions for Dying Gasp Support

  • The native GigabitEthernet interfaces on the Cisco ISR 4000 platforms do not support generating dying-gasp SNMP traps in the following scenarios:

    • The router goes down after removal of the power supply unit (PSU).

    • The router goes down after removal of the power cable.

  • The dying gasp support feature cannot be configured using CLI. To configure hosts using SNMP, refer to the SNMP host configuration examples below.

  • In the case of system reload or interface shutdown on the Cisco 4000 Series ISRs and Cisco 1100 Series ISRs running Cisco IOS-XE Everest Release 16.6.2, dying gasp packets are sent to peer routers. However, the system state is not captured in the system logs (syslogs) or SNMP traps.

Information About Dying Gasp Through SNMP, Syslog and Ethernet OAM

Dying Gasp

One of the OAM features as defined by IEEE 802.3ah is Remote Failure Indication, which helps in detecting faults in Ethernet connectivity that are caused by slowly deteriorating quality. Ethernet OAM provides a mechanism for an OAM entity to convey these failure conditions to its peer via specific flags in the OAM PDU. One of the failure condition method to communicate is Dying Gasp, which indicates that an unrecoverable condition has occurred; for example, when an interface is shut down. This type of condition is vendor specific. A notification about the condition may be sent immediately and continuously.

How to Configure Dying Gasp Through SNMP, Syslog and Ethernet OAM

Dying Gasp Trap Support for Different SNMP Server Host/Port Configurations


Note
You can configure up to five different SNMP server host/port configurations.

Environmental Settings on the Network Management Server



setenv SR_TRAP_TEST_PORT=UDP port
setenv SR_UTIL_COMMUNITY=public
setenv SR_UTIL_SNMP_VERSION=v2c
setenv SR_MGR_CONF_DIR=Path to the executable snmpinfo.DAT file

The following example shows SNMP trap configuration on the host:



Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#
Router(config)# snmp-server host 10.0.0.149 vrf Mgmt-intf version 2c public udp-port 6264
Router(config)#
Router(config)# ^Z
Router#

After performing a power cycle, the following output is displayed on the router console: 



Router#
System Bootstrap, Version 16.6(2r), RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1994-2017  by cisco Systems, Inc.
Current image running: Boot ROM0
Last reset cause: LocalSoft
C1111-8PLTELA platform with 4194304 Kbytes of main memory
rommon 1 > 

=======================================
Dying Gasp Trap Received for the Power failure event:
-----------------------------------------------------
  Trap on the Host
++++++++++++++

snmp-server host = 10.0.0.149 (nms1-lnx)  and SR_TRAP_TEST_PORT=6264 
/auto/sw/packages/snmpr/15.4.1.9/bin> /auto/sw/packages/snmpr/15.4.1.9/bin/traprcv
Waiting for traps.
Received SNMPv2c Trap:
Community: public
From: 10.29.25.101
snmpTrapOID.0 = ciscoMgmt.305.1.3.5.0.2
ciscoMgmt.305.1.3.6 = Dying Gasp - Shutdown due to power loss

Message Displayed on the Peer Router on Receiving Dying Gasp Notification


001689: *May 30 14:16:47.746 IST: %ETHERNET_OAM-6-RFI: The client on interface Gi0/0/0 has received a remote failure indication from its remote peer(failure reason = remote client power failure action = )

Displaying SNMP Configuration for Receiving Dying Gasp Notification

Use the show running-config command to display the SNMP configuration for receiving dying gasp notification: 


Router# show running-config | i snmp
snmp-server community public RW
snmp-server host 10.0.0.149 vrf Mgmt-intf version 2c public udp-port 6264
Router#

Configuration Examples for Dying Gasp Through SNMP, Syslog and Ethernet OAM

Example: Configuring SNMP Community Strings on a Router

Setting up the community access string to permit access to the SNMP: 



Router> enable
Router# configure terminal
Router(config)# snmp-server community public RW
Router(config)# exit

For more information on command syntax and examples, refer to the Cisco IOS Network Management Command Reference.

Example: Configuring SNMP-Server Host Details on the Router Console

Specifying the recipient of a SNMP notification operation: 



Router> enable
Router# configure terminal
Router(config)# snmp-server host X.X.X.XXX vrf mgmt-intf version 2c public udp-port 9800
Router(config)# exit

For more information on command syntax and examples, refer to the Cisco IOS Network Management Command Reference.

Feature Information for Dying Gasp Support

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Table 1. Feature Information for Dying Gasp Support

Feature Name

Releases

Feature Information

Dying Gasp

Cisco IOS XE Release 16.6.2

Ethernet OAM provides a mechanism for an OAM entity to convey failure conditions to its peer via specific flags in the OAM PDU. One of the failure condition method to communicate is Dying Gasp, which indicates that an unrecoverable condition has occurred; for example, when an interface is shut down. This type of condition is vendor specific. A notification about the condition may be sent immediately and continuously.