- Release 15.4SY Supervisor Engine 2T Software Configuration Guide
- Preface
- Product Overview
- Command-Line Interfaces
- Smart Port Macros
- Virtual Switching Systems (VSS)
- Enhanced Fast Software Upgrade (eFSU)
- Fast Software Upgrades
- Stateful Switchover (SSO)
- Non-Stop Forwarding (NSF)
- RPR Supervisor Engine Redundancy
- Interface Configuration
- UniDirectional Link Detection (UDLD)
- Instant Access
- EnergyWise
- Power Management
- Environmental Monitoring
- Online Diagnostics
- Onboard Failure Logging (OBFL)
- Switch Fabric Functionality
- Cisco IP Phone Support
- Power over Ethernet
- Layer 2 LAN Port Configuration
- Flex Links
- EtherChannels
- IEEE 802.1ak MVRP and MRP
- VLAN Trunking Protocol (VTP)
- VLANs
- Private VLANs (PVLANs)
- Private Hosts
- IEEE 802.1Q Tunneling
- Layer 2 Protocol Tunneling
- Spanning Tree Protocols (STP, MST)
- Optional STP Features
- IP Unicast Layer 3 Switching
- Policy Based Routing (PBR)
- Layer 3 Interface Configuration
- Unidirectional Ethernet (UDE) and unidirectional link routing (UDLR)
- Multiprotocol Label Switching (MPLS)
- MPLS VPN Support
- Ethernet over MPLS (EoMPLS)
- L2VPN Advanced VPLS (A-VPLS)
- Ethernet Virtual Connections (EVC)
- Layer 2 over Multipoint GRE (L2omGRE)
- Campus Fabric
- IPv4 Multicast Layer 3 Features
- IPv4 Multicast IGMP Snooping
- IPv4 PIM Snooping
- IPv4 Multicast VLAN Registration (MVR)
- IPv4 IGMP Filtering
- IPv4 Router Guard
- IPv4 Multicast VPN Support
- IPv6 Multicast Layer 3 Features
- IPv6 MLD Snooping
- NetFlow Hardware Support
- Call Home
- System Event Archive (SEA)
- Backplane Platform Monitoring
- Local SPAN, RSPAN, and ERSPAN
- SNMP IfIndex Persistence
- Top-N Reports
- Layer 2 Traceroute Utility
- Mini Protocol Analyzer
- PFC QoS Guidelines and Restrictions
- PFC QoS Overview
- PFC QoS Classification, Marking, and Policing
- PFC QoS Policy Based Queueing
- PFC QoS Global and Interface Options
- AutoQoS
- MPLS QoS
- PFC QoS Statistics Data Export
- Cisco IOS ACL Support
- Cisco TrustSec (CTS)
- AutoSecure
- MAC Address-Based Traffic Blocking
- Port ACLs (PACLs)
- VLAN ACLs (VACLs)
- Policy-Based Forwarding (PBF)
- Denial of Service (DoS) Protection
- Control Plane Policing (CoPP)
- Dynamic Host Configuration Protocol (DHCP) Snooping
- IP Source Guard
- Dynamic ARP Inspection (DAI)
- Traffic Storm Control
- Unknown Unicast Flood Control
- IEEE 802.1X Port-Based Authentication
- Configuring Web-Based Authentication
- Port Security
- Lawful Intercept
Onboard Failure Logging (OBFL)
- Prerequisites for OBFL
- Restrictions for OBFL
- Information About OBFL
- Default Settings for OBFL
- Enabling OBFL
- Configuration Examples for OBFL
Note ● For complete syntax and usage information for the commands used in this chapter, see these publications:
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
- Cisco IOS Release 15.4SY supports only Ethernet interfaces. Cisco IOS Release 15.4SY does not support any WAN features or commands.
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html
Participate in the Technical Documentation Ideas forum
Prerequisites for OBFL
Restrictions for OBFL
- Software Restrictions—If a device (router or switch) intends to use linear flash memory as its OBFL storage media, Cisco IOS software must reserve a minimum of two physical sectors (or physical blocks) for the OBFL feature. Because an erase operation for a linear flash device is done on per-sector (or per-block) basis, one extra physical sector is needed. Otherwise, the minimum amount of space reserved for the OBFL feature on any device must be at least 8 KB.
- Firmware Restrictions—If a line card or port adapter runs an operating system or firmware that is different from the Cisco IOS operating system, the line card or port adapter must provide device driver level support or an interprocess communications (IPC) layer that allows the OBFL file system to communicate to the line card or port adapter. This requirement is enforced to allow OBFL data to be recorded on a storage device attached to the line card or port adapter.
- Hardware Restrictions—To support the OBFL feature, a device must have at least 8 KB of nonvolatile memory space reserved for OBFL data logging.
Information About OBFL
Overview of OBFL
The Onboard Failure Logging (OBFL) feature collects data such as operating temperatures, hardware uptime, interrupts, and other important events and messages from system hardware installed in a Cisco router or switch. The data is stored in nonvolatile memory and helps technical personnel diagnose hardware problems.
Information about Data Collected by OBFL
OBFL Data Overview
The OBFL feature records operating temperatures, hardware uptime, interrupts, and other important events and messages that can assist with diagnosing problems with hardware cards (or modules) installed in a Cisco router or switch. Data is logged to files stored in nonvolatile memory. When the onboard hardware is started up, a first record is made for each area monitored and becomes a base value for subsequent records. The OBFL feature provides a circular updating scheme for collecting continuous records and archiving older (historical) records, ensuring accurate data about the system. Data is recorded in one of two formats: continuous information that displays a snapshot of measurements and samples in a continuous file, and summary information that provides details about the data being collected. The data is displayed using the show logging onboard command. The message “No historical data to display” is seen when historical data is not available.
Temperature
Temperatures surrounding hardware modules can exceed recommended safe operating ranges and cause system problems such as packet drops. Higher than recommended operating temperatures can also accelerate component degradation and affect device reliability. Monitoring temperatures is important for maintaining environmental control and system reliability. Once a temperature sample is logged, the sample becomes the base value for the next record. From that point on, temperatures are recorded either when there are changes from the previous record or if the maximum storage time is exceeded. Temperatures are measured and recorded in degrees Celsius.
- Number of sensors is the total number of temperature sensors that will be recorded. A column for each sensor is displayed with temperatures listed under the number of each sensor, as available.
- Sampling frequency is the time between measurements.
- Maximum time of storage determines the maximum amount of time, in minutes, that can pass when the temperature remains unchanged and the data is not saved to storage media. After this time, a temperature record will be saved even if the temperature has not changed.
- The Sensor column lists the name of the sensor.
- The ID column lists an assigned identifier for the sensor.
- Maximum Temperature 0C shows the highest recorded temperature per sensor.
- Temp indicates a recorded temperature in degrees Celsius in the historical record. Columns following show the total time each sensor has recorded that temperature.
- Sensor ID is an assigned number, so that temperatures for the same sensor can be stored together.
Operational Uptime
The operational uptime tracking begins when the module is powered on, and information is retained for the life of the module.
The operational uptime application tracks the following events:
- Date and time the customer first powered on a component.
- Total uptime and downtime for the component in years, weeks, days, hours, and minutes.
- Total number of component resets.
- Total number of slot (module) changes.
- Current reset timestamp to include the date and time.
- Current slot (module) number of the component.
- Current uptime in years, weeks, days, hours, and minutes.
- Reset reason; see Table 18-1 to translate the numbers displayed.
- Count is the number of resets that have occurred for each reset reason.
|
|
---|---|
Off or on after application-specific integrated circuit (ASIC) interrupt |
|
Interrupts
Interrupts are generated by system components that require attention from the CPU such as ASICs and NMIs. Interrupts are generally related to hardware limit conditions or errors that need to be corrected.
The continuous format records each time a component is interrupted, and this record is stored and used as base information for subsequent records. Each time the list is saved, a timestamp is added. Time differences from the previous interrupt are counted, so that technical personnel can gain a complete record of the component’s operational history when an error occurs.
- Name is a description of the component including its position in the device.
- ID is an assigned field for data storage.
- Offset is the register offset from a component register’s base address.
- Bit is the interrupt bit number recorded from the component’s internal register.
- The timestamp shows the date and time that an interrupt occurred down to the millisecond.
Message Logging
The OBFL feature logs standard system messages. Instead of displaying the message to a terminal, the message is written to and stored in a file, so the message can be accessed and read at a later time. System messages range from level 1 alerts to level 7 debug messages, and these levels can be specified in the hw module logging onboard command.
- A timestamp shows the date and time the message was logged.
- Facility-Sev-Name is a coded naming scheme for a system message, as follows:
– The Facility code consists of two or more uppercase letters that indicate the hardware device (facility) to which the message refers.
– Sev is a single-digit code from 1 to 7 that reflects the severity of the message.
– Name is one or two code names separated by a hyphen that describe the part of the system from where the message is coming.
- The error message follows the Facility-Sev-Name codes. For more information about system messages, see the Cisco IOS System and Error Messages guide.
- Count indicates the number of instances of this message that is allowed in the history file. Once that number of instances has been recorded, the oldest instance will be removed from the history file to make room for new ones.
- The Persistence Flag gives a message priority over others that do not have the flag set.
Default Settings for OBFL
The OBFL feature is enabled by default. Because of the valuable information this feature offers technical personnel, it should not be disabled.
Enabling OBFL
To enable OBFL, perform this task:
Configuration Examples for OBFL
The important OBFL feature is the information that is displayed by the show logging onboard module privileged EXEC command. This section provides the following examples of how to enable and display OBFL records.
- Enabling OBFL Message Logging: Example
- OBFL Message Log: Example
- OBFL Component Uptime Report: Example
- OBFL Report for a Specific Time: Example
Enabling OBFL Message Logging: Example
The following example shows how to configure OBFL message logging at level 3:
OBFL Message Log: Example
The following example shows how to display the system messages that are being logged for module 2:
OBFL Component Uptime Report: Example
The following example shows how to display a summary report for component uptimes for module 2:
OBFL Report for a Specific Time: Example
The following example shows how to display continuous reports for all components during a specific time period:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html
Participate in the Technical Documentation Ideas forum