Data Collection Guideline for the SmartEdge Router
Submitting a Customer Service Request

Contents

1Introduction
1.1Scope
1.2Target Groups

2
Workflow

3
Mandatory Data
3.1Mandatory Logs and Data
3.2Acceptable Compression Formats

4
Collecting Data Based on Problem Type

5
Severity Levels
5.1Emergency
5.2High
5.3Medium
5.4Low
Copyright

© Ericsson AB 2011. All rights reserved. No part of this material may be reproduced in any form without the written permission of the copyright owner.

Trademark List
Ericsson Ericsson is the trademark or registered trademark of Telefonaktiebolaget LM Ericsson. All other trademarks mentioned herein are the property of their respective owners.

1   Introduction

This document describes the troubleshooting data that must be collected and enclosed in a Customer Service Request (CSR) in case a problem is experienced with the SmartEdge® router. This guideline also describes the procedure for collecting the necessary information.

1.1   Scope

This document covers the following issues:

1.2   Target Groups

This document is intended for experienced operation and maintenance personnel troubleshooting the SmartEdge router.

2   Workflow

The workflow for collecting troubleshooting data for the CSR is as follows:

  1. Collect the general mandatory data that is needed for any problem experienced. For more information, see Section 3.
  2. Collect specific data based on the problem type. For more information, see Section 4.
  3. State the severity level of the CSR (mandatory), see Section 5.

3   Mandatory Data

The data described in this section is essential for any CSR, regardless of the problem type.

Use the following checklist when writing the CSR. A more detailed description of each line is presented after the checklist. Some parts are not applicable to certain types of requests, for example documentation faults or consultations, but all parts apply to software and hardware faults. Fill out as many as possible for each case.

Table 1    Checklist when Writing CSRs 

SmartEdge release: 
HW platform: 

RECENT CHANGES
SW changes:
Configuration changes:
HW changes:
O&M procedures:
Environment:

CASE DESCRIPTION
Case description:
Date and time:
Problem frequency:
Problem reproducibility:
Problem effects:
Network diagram to illustrate the problem:

ATTACHMENTS
System logs:
Crashfiles:
Output of the show tech-support command:
Other attachments:

MEASURES
On-site or online support:
Work around:

FACTS

RECENT CHANGES

Specify if any of the following changes has been implemented or occurred recently:

CASE DESCRIPTION

Provide a clear description of the consultation or the problem, to make it easier for Ericsson to locate the problem in the log files:

ATTACHMENTS

Describe the file name and format of all attachments. Always include the mandatory files as described in Section 3.1 and, when necessary, the data described in Section 4.

MEASURES

3.1   Mandatory Logs and Data

The logs and data described in this section must always be included in the CSR.

System Log Files (/var/log/messages)

Collect system logs from both the active and standby XCRP cards to attach to your CSR. The files are named messages.x.gz.; they can be found in the /var/log directory through NetBSD shell mode.

The log file must include the time of the failure. Time stamps before and after the event occurred must also be included in the CSR. It is important to verify exactly in which file the actual failure is, since the active message log file is overwritten after a while. For example, the file can be in /var/log/messages.2.gz instead of current message log.

Verify the logging configuration on the router by collecting the output of the show configuration log command.

Crash Files From Both Active and Standby XCRP cards

Verify if related core dumps were generated at the time of the problem, by entering the following commands:

Transfer the files in binary mode from the router and include an md5 checksum of the original file.

Output of the show tech-support Command

The output of the show tech-support command must be included in the CSR.

Before troubleshooting or performing any recovery steps, run the show tech-support command (in exec mode) without any keywords on both the active and standby XCRP cards.

The basic command is a macro that runs show commands in the following areas:

If you know that your problem is related to one of the following other SmartEdge hardware or processes, you can also collect the output of the command with an appropriate keyword; see Section 4:

AAA


ASE


ATM


BFD


BGP


Database (RDB)


DHCP


DOT1Q


FLOWD


GRE


IGMP


IPV6

IS-IS


L2TP


LDP


Mobile-IP


OSPF


OSPF3


PIM


PPP


PPPoE


QoS


SNMP

3.2   Acceptable Compression Formats

Note:  
Ericsson only accepts the following compressing programs:
  • Compressed tar (*.tar)
  • gzip’d tar (*.tar.gz)
  • win zip (*.zip)

4   Collecting Data Based on Problem Type

For more specific problems, collect the output of the following commands as needed to attach to the CSR, depending on the symptom of the fault.

The show tech-support command includes optional keywords to collect troubleshooting data about many SmartEdge OS modules or the ASE card. To collect data for specific problems, use the command (in exec mode) with an appropriate keyword that runs show commands for the module.

The command has the following syntax:

show tech-support [aaa | ase | atm | bfd | bgp | dhcp | dot1q | flowd | gre | igmp | ipv6 | l2tp | ldp | mobile-ip | ospf | ospf3 | pim | ppp | pppoe | qos | rdb | snmp]

For example, if you know your problem is related to PPP subscribers, enter the show tech-support ppp command.

Use the following commands to obtain additional information when a problem or outage occurs at the customer node. See the appropriate command reference guide for an explanation of the command syntax.

Note:  
Because the output of these commands is intended for use by the support engineers, the format might differ from typical show command output and might not be readable.

 Warning! 
Some show card commands might impact card performance.

5   Severity Levels

It is mandatory to state the severity of the CSR. The correct severity ensures that critical problems are fixed before less critical problems, therefore it is very important to apply the following guidelines.

If the priority is not clear to both the First Line Support (FLS) and the Second Line Support (SLS), they analyze it and decide on the severity. The FLS can increase priority due to commercial reasons at any time.

There are four types of severity, Emergency, High, Medium, and Low, described in the following subsections:

5.1   Emergency

Examples of emergencies are the following:

The following problem types are not considered to be emergencies:

5.2   High

Examples of high severity problems are the following:

5.3   Medium

Medium severity problems have minor customer impact.

Examples of medium severity faults are the following:

5.4   Low

Low severity CSRs must not be related to any fault in the end-customer's network or network elements.

See the SLS for general consultation.

Examples of low severity faults are the following: