Kazi Zial Hoque.2013-11-22.SAM StudentGuide Ver1.4

Course Introduction
Module 0 - 1
This ALU-IPD-SRC Alcatel-Lucent_Network_and_Service_Troubleshooting_with_the_5620_SAM Guide is for exclusive use of Kazi_Zial_Hoque - WIND_Mobile
Kazi_Zial_Hoque - WIND_Mobile
Network and Service Troubleshooting with

the 5620 SAM
Alcatel-Lucent Career Certification

Course Introduction
Course Modules
Additional Optional Modules
Administration
Network and Service Troubleshooting with the 5620 SAM v1.4
Network and Service Troubleshooting with the 5620 SAM
Module 0 |
All rights reserved 2012-2013 Alcatel-Lucent
Module 0 - 2
Module Overview
ALCATEL-LUCENT
NETWORK ROUTING SPECIALIST II
4 DAYS / 1 COURSE / 1 WRITTEN EXAM
18 DAYS / 4 COURSES / 4 WRITTEN EXAMS /

1 PRACTICAL LAB EXAM
ALCATEL-LUCENT
NETWORK ROUTING SPECIALIST I
ALCATEL-LUCENT
ALCATEL-LUCENT
TRIPLE PLAY ROUTING PROFESSIONAL MOBILE ROUTING PROFESSIONAL
36 DAYS / 8 COURSES / 8 WRITTEN EXAMS /
1 PRACTICAL LAB EXAM
32 DAYS/ 7 COURSES / 7 WRITTEN EXAMS /

2 PRACTICAL LAB EXAMS
ALCATEL-LUCENT
SERVICE ROUTING ARCHITECT
49 DAYS / 11 COURSES / 11 WRITTEN EXAMS / 2 PRACTICAL LAB EXAMS
Module 0 |
This course is NOT part of the Alcatel-Lucent Service Routing Certification (SRC) Program. See www.alcatellucent.com/src for more information on the SRC program.
The Alcatel-Lucent Service Routing Certification (SRC) program gives you the training required to design,
operate, and troubleshoot todays IP/MPLS based multi-service networks, allowing your corporation to get
the most from its investment in IP service routing.
The Alcatel-Lucent SRC program is specifically designed to arm network engineers, as well as operations
and strategic planning staff, with the skills necessary to meet new operational challenges and to align
network changes with their companies business goals.
Adding video to the service mix creates an entirely new set of networking architectural challenges. Our
program is unique in its ability to prepare you for these challenges, both now and in the future.
The NRSI is our introductory certification and the SRA is our highest level certification. As you move from
the introductory certification toward the SRA, you will gain more knowledge associated with the ALU
approach to services such as VPLS and VPRNS, and solutions such as Triple Play.
Module 0 - 3
The Alcatel-Lucent SRC Program Five Certifications
Module 0 |
Module 0 - 4
SRC Courses and Exams
Exam Pre-requisites
(4A0-XXX)
Alcatel-Lucent Scalable IP Networks
4A0-100
NA
Alcatel-Lucent Interior Routing Protocols
4A0-101
NA
Alcatel-Lucent Border Gateway Protocol
4A0-102
NA
Alcatel-Lucent Multiprotocol Label Switching
4A0-103
NA
Alcatel-Lucent Services Architecture
4A0-104
NA
Alcatel-Lucent Virtual Private LAN Services
4A0-105
NA
Alcatel-Lucent Virtual Private Routed Networks
4A0-106
NA
Alcatel-Lucent Quality of Service
4A0-107
NA
Alcatel-Lucent Multicast Protocols
4A0-108
NA
Alcatel-Lucent Triple Play Services
4A0-109
NA
Alcatel-Lucent Advanced Troubleshooting
4A0-110
NA
Alcatel-Lucent IP/MPLS Mobile Backhaul Transport
4A0-M01
NA
Alcatel-Lucent Mobile Gateways for the LTE Evolved

Packet Core
4A0-M02
NA
Alcatel-Lucent Network Routing Specialist II Lab Exam
NRSII4A0
100, 101, 103, 104
Alcatel-Lucent Mobile Routing Professional Lab Exam
MRP4A0
100, 101, 103, 104, 107, M01, M02, NRSII4A0
Alcatel-Lucent Service Routing Architect Lab Exam
ASRA4A0
100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110,
NRSII4A0
Module 0 |
Module 0 - 5
Exam Number
Exam Name
SRC Program Exam Profile
Practice and build your service routing knowledge and configuration skills?
Test new network and service features?
Prepare for your NRS II, MRP and SRA exams?
The Alcatel-Lucent MySRLab service provides:

Remote, private access(7X24) to an Alcatel-Lucent service router lab
Multiple lab topologies for both wireline and wireless service environments
Access to a suite of over 50 lab practice scenarios with optimal solutions
Need access to an SR lab to help you:
Access to traffic simulation and analysis tools
Sign up today at
www.alcatel-lucent.com/src/mysrlab
Module 0 |
MySRLab
Like owning your own Service Router Lab
Alcatel-Lucent Scalable IP Networks

Self-Study Guide
ISBN: 978-0-470-42906-8
Prepares the reader for the NRS I
certification exam
Alcatel-Lucent Network Routing
Specialist II Self-Study Guide
ISBN 978-0-470-94772-2
Prepares reader for the NRS II
certification exams
Both guides include CD with lab
exercises and solutions
MySRLab for hands-on lab exercises
and exam preparation
http://www.alcatel-lucent.com/srpublications
Module 0 |
SRC Self-study Options
Written Exams
Delivered by Prometric
Global provider of testing services

5000+ test sites worldwide
Register at: www.prometric.com/alcatel-lucent
Lab Exams
Administered at Alcatel-Lucent locations
NRS II Certification
Half-day lab exam
MRP Certification
Half-day lab exam
SRA Certification
Full-day lab exam
Register at: www.alcatel-lucent.com/src/examreg
Module 0 |
Module 0 - 8
Exam Delivery
Virtual classroom
Delivery from any Alcatel-Lucent locations globally
APAC
Shanghai, China
Sydney, Australia
Melbourne, Australia
Wellington, New Zealand
Bangalore, India
Chennai, India
Gurgaon, India
Mumbai, India
Europe
Antwerp, Belgium
Newport, UK
Paris, France
Americas
Plano, USA
Ottawa, Canada
Mexico City, Mexico
Sao Paulo, Brazil
On-site delivery at your business location anywhere in the world
Class schedules available at www.alcatel-lucent.com/src

Online registration at www.alcatel-lucent.com/src/coursereg
Module 0 |
Global Reach, Flexible Learning Options
Live, Instructor-led, 100% on-line

Remote access to a Service Router lab for hands-on lab exercises
Interactive and engaging learning environment
Available for public class offerings or private, dedicated customer
deliveries
Viewtheclassscheduleandregisterat
http://www.alcatellucent.com/src/courses
Module 0 |
10
Get the benefits of live SRC training without expensive travel &
living and time-away costs
Virtual Classroom Delivery
Login to the SRC Student Portal to:

Check your exam history

Verify your certification status and reminder
dates (renewal, expiry, etc.)
Download and display logos for your active
certifications
Publish your certification status to third
parties
Check on the status of your fulfillment
items (plaques, diplomas, etc.)
Get program updates
Review FAQs and get support
http://www.alcatel.lucent.com/src/studentportal
Module 0 |
11
SRC Student Portal
Cisco or Juniper certified?

You can receive exemptions from

some of the SRC exams, if you
hold any one of the Cisco or
Juniper certifications identified
Certifications must be valid to
receive exemptions
Submit your request for
exemptions at: http://www.alcatellucent.com/src/exemptions
Module 0 |
12
12
Credit for other IP Certifications
Students are expected to have already acquired at

least some intermediate skills in using the 5620 SAM for
provisioning, network and fault management.
This is not a 5620 SAM introductory course. To find courses

designed for learning the 5620 SAM in general, or for specific
feature training, please contact/consult the Alcatel-Lucent
University list of 5620 SAM courses.
Module 0 |
13
http://www.alcatel-lucent.com/university
http://www.alcatel-lucent.com/src
Module 0 - 13
This course is designed to teach students techniques for

troubleshooting Network and Services issues using the 5620
SAM.
Course Introduction
Demonstrations, practical exercises and hands-on labs are

used to teach students the skills required to apply the
various features available in the 5620 SAM to troubleshoot
and to become familiar with best practices.
Duration: 4-5 days
Module 0 |
14
Module 0 - 14
Course Introduction (cont.)
2 5620 SAM Alarms

3 Navigation Trees
4 Topology Views
5 Service Test Manager
6 Statistics for Troubleshooting
7 Troubleshooting IGP
8 Troubleshooting MPLS
9 Troubleshooting Services
Module 0 |
15
Module 0 - 15
1 Introduction to Troubleshooting with the 5620 SAM
Course Modules
L2 IEEE OAM & Y.1731

Bidirectional Forwarding Detection (BFD)
Troubleshooting BGP
Troubleshooting Redundancy (i.e. MC-LAG, Pseudowire
Redundancy, etc.)
Module 0 |
16
Module 0 - 16
Additional Optional Modules are also available:
Additional Optional Modules
Registration
Facility information
Restrooms
Communications
Materials
Schedule
Introductions
Name and Company
Experience
Questions
Module 0 |
17
Module 0 - 17
Administration
Module 0 |
18
Module 0 - 18
This page has been intentionally left blank.
www.alcatel-lucent.com
Module 1 Introduction

the 5620 SAM
The benefits of using 5620 SAM for troubleshooting

The 5620 SAM features that assist troubleshooting
A standardized troubleshooting methodology
Module 1 |
After successfully completing this module, you should be able to

describe:
All rights reserved 2013 Alcatel-Lucent
Module 1 - 2
Module Objectives
Benefits of 5620 SAM as a Troubleshooting Tool
Introduction
Centralized alarm management

Topology maps to show connectivity and status of links
Ability to view a service end-to-end, rather than a single
service site
Ability to use bulk operations on multiple network elements
at the same time
Statistics management
Module 1 |
Module 1 - 4
View of the entire network
Benefits of 5620 SAM as a Troubleshooting Tool
Overview of 5620 SAM features that assist in
troubleshooting
Introduction
OAM tools managed with the Service Test Manager (STM)

Topology maps
Physical
SDP
Service
Navigation Trees
Equipment
Routing
Service components
Statistics
Policy audits
Module 1 |
Module 1 - 6
Alarms, status values and GUI object coloring
SAM features commonly used for network troubleshooting
Troubleshooting Methodology
Introduction
Network architecture
Routing protocols
Services
Knowledge of available tools

A reasonable/proven, systematic, traceable methodology to
follow
Module 1 |
Module 1 - 8
Knowledge of the system:
What is required for effective troubleshooting?
The biggest challenge may be discovering what the actual

problem is, rather than devising the fix
A standardized approach to troubleshooting is better than a
haphazard one
Most troubleshooting situations can be managed by a generic

methodology
Some cases require stepping outside a fixed approach
Having a methodology already in place is a good starting

point.
Module 1 |
Module 1 - 9
There are too many possible scenarios to have a specific

solution ready for each one
Why use a methodology?
1. Identify the problem/symptoms

Understand the issue
Verify the reported issue
Establish a baseline
Gather information
2. Investigation
Determine the cause
3. Take corrective action (fix)

4. Verification
Module 1 |
10
Troubleshooting is not just diving in and fixing the problem. Complex problems can require a more systematic
approach.
Module 1 - 10
Methodology: Troubleshooting Steps
Requires an understanding of the system and network

Gathering Symptoms vs. Determining the cause
Establish a baseline
Verify reported issue does exist (trust but verify reported
information)
Module 1 |
11
Module 1 - 11
If you lose sight of the real issue or dive into investigation

too soon, you may fail to fix the right problem
Searching for the problem's cause using 5620 SAM tools
Keep an audit trail

where have you looked?
what have you changed during the investigation?
Avoid common pitfalls: unchecked assumptions, red herrings

and being stuck on the common path
Be aware of usual suspects, current networks activities
Searching for the cause
Module 1 |
12
Functional fixation viewing a specific tool as having only the primary use it was designed for (ever used a
screwdriver as a hammer?).
E.g. Ping can be used for more than just testing that an NE is there -> packet size, timings.
The Acknowledgement info and Notes sub-tabs in the Alarm Info window can be used to record part of the
Audit Trail: Where have I looked? Who is looking at the problem? Who was informed? etc.
Module 1 - 12
Requires an understanding of what information is available

(or can be generated)
2. Investigation
Plan the solution that will be applied

Apply the fix and keep an audit trail of actions taken (check
off steps from the plan)
Module 1 |
13
Audit trail many changes applied at once may have to be tracked in order to be rolled back.
Ideally, only one thing at a time should be changed.
Module 1 - 13
The cause has been established by this point
3. Take corrective action (fix)
Revisit the notes from Identify the Problem

Perform other cleanup (e.g. service is restored but some
alarms may still need to be manually cleared)
Monitor the issue if necessary, depending on the type,
complexity and severity of the issue
Module 1 |
14
Module 1 - 14
Confirm that the problem has been resolved and all

symptoms have been accounted for
4. Verification
Phases:
1.
2.
3.
4.
Identify the problem/symptoms

Investigation
Take corrective action
Verification
Key points
Knowledge of system, network and tools

Audit trail
Module 1 |
15
Module 1 - 15
Methodology Summary
5620 SAM features that assist troubleshooting

Standardized troubleshooting methodology
Module 1 |
16
Module 1 - 16
Benefits of using the 5620 SAM for troubleshooting
Module Summary
Module 1 |
17
Module 1 - 17
All Rights Reserved 2013 Alcatel-Lucent
Module 2- 1
Module 2 5620 SAM Alarms
Network and Service Troubleshooting

with the 5620 SAM
After successful completion of this module, you should be able to

describe:
The sources of alarms presented by the 5620 SAM
Alarm information
Alarm coloring
How to optimize alarm viewing using the Dynamic Alarm
window
How to acknowledge and add notes to alarms
Alarm correlation and suppression
Alarm hierarchy/relationships
Module 2 |
Module 2- 2
Module Objectives
Additional text policies

How to monitor service alarms
Best practices for troubleshooting using the 5620 SAM fault
management system
Unexpected alarm behaviors
Module 2 |
Module 2- 3
Alarm history
Module Objectives (cont.)
5620 SAM Alarm Creation
Module 2- 4
5620 SAM Alarms
All alarms that appear in the 5620 SAM Alarm window are
assembled by the SAM.
There are two sources where information contained in an

alarm originates
1. Internal to the 5620 SAM
2. External to the 5620 SAM
Internal Alarms are originated by the 5620 SAM itself.
Deal with conditions or activities within the NMS (Network

Management System)
External alarms originate from NE events (traps)
Module 2 |
From network events to 5620 SAM alarms:

An event happens on the network. For example, a link is cut. A number of traps are generated in
the router. Typically on an SR, there will be at least one link down and an equipment failure trap
on the port.
Traps are generated for other objects on the router associated with the port, such as SAPs or SDPs.
These traps are sent to the active and standby 5620 SAM. The 5620 SAM notes the changes,
generates alarms and, in some cases, resyncs the object. The 5620 SAM alarms are displayed in the
Dynamic Alarm windows and various objects fault tabs. The alarms are also used in the 5620 SAM
to show the alarm status of objects in the Equipment tree or the map, for example.
Module 2- 5
Alarm Sources
Trap lost
Trap flood
NMS network overloaded or down
SNMP trap sequence verification

By default, the 5620 SAM retrieves the last SNMP trap sequence
number sent by all network elements every 4 minutes
This number is compared to the last sequence number received
If they do not match, the 5620 SAM will request only the missing
traps from the required NEs
If the 5620 SAM is missing more than 200 traps, or the missing
traps are no longer available, a full resync is requested
Module 2 |
See SNMP trap sequence verification in the Planning Guide for more info.
Module 2- 6
Trap from NE not received by the 5620 SAM
Conditions where alarms may not get created
<date> UTC WARNING: SNMP #2004 Base 1/1/7

"Interface 1/1/7 is not operational"
Log 98 on NE
5620 SAM alarm
Module 2 |
Example of what appears in the log 98 of the NE and the resulting alarm created by the 5620 SAM.
Note that there is not always a one-to-one correspondence.
When the 5620 SAM receives a trap, it then re-syncs with objects related to the trap and raises additional
alarms according to the status of those objects.
Module 2- 7
Trap Relationship to 5620 SAM Alarms
Alarms Example #1
Module 2- 8
5620 SAM Alarms
1. Indentify the problem/symptoms
Understand the issue

Gather information
Establish baseline
Verify reported issue
2. Investigation
Determine cause
3. Apply Fix - Take corrective action

4. Verification
Module 2 |
Remember to keep an audit trail.

SAM alarms provide acknowledgment and notes can be added to individual alarms to help you track the
actions taken for alarms.
Alarms can come into play during steps 1, 2 and 4; however, they are most important during step 2
(Investigation).
For the purpose of this example we will only focus on the investigation step.
Module 2- 9
Recall the general troubleshooting steps (from Module 1)
2. Acknowledge alarms to signal that an investigation is

underway
3. Determine which alarm to investigate first
4. Examine the details of the alarm
5. If the cause of the issue has not been determined, look at
related objects, alarm statistics and Historical alarms
Module 2 |
10
Module 2- 10
1. Find/discover an alarm (in Dynamic Alarm window, maps,

trees, Properties Forms)
Investigation Phase Using Alarms
1. Finding Alarms
Module 2- 11
5620 SAM Alarms
Alarm appears in the Dynamic Alarm window

Something changes color in the maps and/or trees
Alarm appears in the Faults tab of an objects Properties form
Look for Fault Notification Indicators!
- Or An operator looks for an alarm because of a problem

reported by a customer or OSS system
Module 2 |
12
The color of the alarm indicates the alarms severity. Tip: the color associated with a severity can be seen
in the Dynamic Alarm windows Alarm Statistics tab.
Fault Notification Indicators are present in release 10.0 R1 and above. The sub-tabs under the Faults tab
have notification capabilities as well.
Module 2- 12
An alarm can come to the attention of operators in several

ways:
An Alarm Appears
1. Dynamic Alarm window (Filtering, Sorting)

2. Faults tab on Object Properties Form (Best Practice)
3. Alarm History
If it is not obvious what type of alarm to look for, the

Customer and Service information can be used to track down
an alarm
Alarms can be tracked down by using the Topology Maps or
Navigation trees
Best Practice:
Disable operator ability to purge alarms (5620 SAM User
Security)
Module 2 |
13
If it is known which Customer is having the issue: Manage -> Customers (Search for customer and view the
Services tab).
If it is known which type of service is down: Manage -> Services.
Disable the Update/Execute permissions on fm.AlarmHistoryDatabase.method.purge in order to disable

an operators ability to purge alarms.
(Administration -> Security -> 5620SAM User Security -> Scope of Command).
Hitting the Pause button on the Dynamic Alarm window may be necessary if there is a constant arrival of
new alarms. The Pause button does not prevent new alarms from being created, it simply delays adding
them to the Dynamic Alarm Window until the Pause button is turned off.
Module 2- 13
There are three methods for viewing an alarm
Finding an Alarm
1. Look at the entire history (Tools -> Historical Alarms) and apply a
filter.
2. Go directly to the Properties of a suspected object, click on its
Faults tab and then click the View Alarm History button.
This causes a filter to be auto-generated for that object.
3. From the Alarm Info form, click the View Alarm History button.
This causes a filter to be auto-generated for that object and

specific alarm.
Best Practice:
When possible, the 2nd and 3rd methods should be used
because they automatically build a filter
Module 2 |
14
Module 2- 14
There are three ways to search for historical alarms:
Alarm History
Scenario: Physical Port Admin Down
Module 2 |
15
The GUI lights up in multiple places:

Node icons in Physical and Service Tunnel Topology maps
Equipment and Routing trees
Alarm appears in Dynamic Alarm Window
Fault Notification Indicators
Module 2- 15
Example A port/link issue
Module 2 |
16
Module 2- 16
The Dynamic Alarm window has columns for Name, Probable

Cause, and Severity, as well as other fields.
Dynamic Alarm Window Columns
Module 2 |
17
Double clicking on an alarm in the Dynamic Alarm Window will open the Alarm Info Window for that
alarm.
Module 2- 17
The Description under the Details tab may reveal the issue immediately
The Alarm Info Window
Best Practice:
When viewing the alarm info, be sure to note the following
attributes: Probable Cause, Additional Text, Description and
Remedial Action.
Module 2 |
18
Module 2- 18
The Remedial Action under the Details tab may give instructions on how to fix
the issue
The Alarm Info Window (continued)
Square indicates
object alarm status
Module 2 |
19
The alarm coloring can been seen by looking at the Alarm Statistics tab of the Dynamic Alarm Window
Module 2- 19
Circle indicates
aggregated alarm
status
Alarm Information Legend
Sort field order to individual taste

Drag columns in title field
Save layout using right-click menu
Hide unwanted fields
Module 2 |
20
To make the new Dynamic Alarm window configuration default, in the SAM main menu select;
Application -> Save Workspace
Module 2- 20
Dynamic Alarm Window: Layout alarm table to taste
Quick filter
Type and hit Enter
Advanced filter allows

complex search criteria.
Filters can be saved.
Filter by Equipment Group

Module 2 |
21
Multiple Alarm Windows:

This allows operators to monitor alarms in different network areas at the same time, or make each
window represent a different level in the object containment hierarchy, e.g. port, LSP, Tunnel, SAP, SDP,
Service. This will accelerate troubleshooting.
Module 2- 21
Up to 6 alarm windows
supported
Some Alarm Table Capabilities
The Monitoring Flag panel under the Alarm Table tab indicates the number
of alarms, color-coded by severity, that have been detected since the
window has been open OR flag was reset.
The time the last alarm for that severity was detected is also displayed
Show or hide the Monitoring Flag panel using ApplicationUser

Preferences menu option
select/unselect the Show Alarm Flags checkbox
Reset the flag and values by clicking the flag
Module 2 |
22
Module 2- 22
Alarm Flags
Excellent for multi-monitor setups (Dynamic Alarm window

and main SAM window on separate monitors)
To move a panel outside the main SAM GUI
Select the desired window to move, and from the main

menu click Window Move to External Window
Module 2 |
23
To close all windows outside the main GUI: Window -> Close All External SAM Windows
To close all windows inside the main GUI: Window -> Close All Internal Windows
When opening a child window from an external window, the child window will become an external
window as well
Limitation:
Once a panel is moved outside the main GUI, it cannot be brought back in. It must first be closed and
then re-opened from within the main GUI.
This feature is only available in 5620 SAM 8.0 R5 and above
Module 2- 23
Provides the ability to move SAM windows, such as the

Dynamic Alarm window, outside of the main SAM GUI
Detachable Windows
2. Acknowledging Alarms
Module 2- 24
5620 SAM Alarms
Indicates which operator is investigating the alarm in the

Acknowledged By alarm field
To take advantage of this, it is a best practice to create
separate operator user accounts
Notes can be added to an alarm

Adding notes keeps a revision history, which is a great tool for
keeping an audit trail
Best Practice:
When troubleshooting, be sure to acknowledge all associated
alarms.
Module 2 |
25
Module 2- 25
Signals to other operators that the alarm is being

investigated
Acknowledging an Alarm
3. Determine which alarms to investigate first
Module 2- 26
5620 SAM Alarms
These are organized into a hierarchy to help prioritize the

significance of alarms
Alarms can be filtered by Object Type
Note: After being assigned a managed object, alarms are further
organized by domain. For more information, please view the
5620 SAM 10.0 Troubleshooting Guide
Best Practice:
If multiple alarms are present, the alarm(s) at the lowest MO
should be investigated first.
Module 2 |
27
Usually it is obvious where an alarm fits into the hierarchy.

For example, an alarm on a port would be at a lower level than an alarm on a service that uses that port,
so investigation should focus on the port issue as it is likely causing the service alarm as well.
When alarms are raised, they are assigned a managed object and domain
They fit into a hierarchy of SAM Managed Objects.
The managed object (Object Type) and domain of an alarm can be seen in the Alarm Info window.
An alarms position in the hierarchy can be determined by looking up the managed object and domain in
the SAM Troubleshooting Guides Hierarchy of 5620 SAM-managed objects if required.
Module 2- 27
Alarms are assigned a managed object
Alarm Hierarchy
General network-management or 5620 SAM-related objects

Network
Service
SDP binding
Tunnel
LSP binding
LSP
Session
LDP Interface or Targeted peer
Network Interface
Physical Equipment
SONET/SDH bundle, port or channel
DS1/E1 channel
Module 2 |
28
From the SAM Troubleshooting Guides Hierarchy of 5620 SAM-managed objects.
Module 2- 28
Alarm Hierarchy of Managed Objects
Aggregation
Objects have object and aggregated
alarm status icons
The square is the objects alarm status
The circle is the aggregated alarm status
The objects color on the map is based

on its operational status and the alarm
with the highest severity
Module 2 |
29
The whole Node icon will go red if it is not reachable by SNMP.

Note that this doesnt necessarily mean that the node is down; SAM is just indicating that it
cant communicate with it via SNMP.
Module 2- 29
Alarms, Object Alarm Status and Operational Status
Node
Shelf
Aggregated
alarm status
Slot
Card
Object alarm
Port
Aggregated Alarm status allows the operator to view the

equipment hierarchy when it is closed, and to drill down to find
the object that is causing the alarm.
Module 2 |
30
Alarms visible at higher levels than the object directly involved.

Alarm aggregation allows the GUI to flag alarms on parent objects.
The Faults tab on the Properties window of any of the parent objects will list the
aggregated alarms
Aggregated does not mean that theres an alarm at each level; it means that the higher
levels have an indicator when theres an alarm at a lower level.
This helps operators to drill down to the cause more quickly.
Module 2- 30
Object alarm on any port causes its parent objects Aggregation

Alarm status.
Equipment Hierarchy: Aggregated Alarm Status
Service
Aggregated
alarm status
Site
SAP
The Aggregated Alarm status indicates when alarms exist

within a service components hierarchy. Operators can then
drill down to find the object that is causing the alarm.
Module 2 |
31
Module 2- 31
Service Hierarchy: Aggregated Alarm Status
Best Practice:
When both sets of alarms are present, troubleshoot the
Affecting alarm first
Module 2 |
32
Module 2- 32
Allows the operator to quickly trace to the lowest level of

alarm and see what objects are affected by a given alarm
Alarm Association Affecting/Related Objects
Port
Alarms on
related objects
Affecting
alarms
SAP
Module 2 |
33
Module 2- 33
Port down causes SAP down (port is shown in equipment

hierarchy, and SAP is shown in service hierarchy)
Alarm Association affecting/related objects
Affecting Objects tab objects affecting this alarm
Aggregated alarms on objects below this object

Alarms on Related Objects
Module 2 |
34
From SAM Users Guide:

Alarm tab contains alarm information that includes the object, severity, statistics and
acknowledgement status.
Affected Objects tab contains a list of objects that are affected by the alarm. All alarms list the
affected objects, even when correlation alarm suppression is enabled.
Affecting Objects tab contains a list of objects that directly affect the object in the alarm.
Module 2- 34
Affected Objects tab objects also affected by this alarm
Affecting/Affected/Related objects/Aggregated
Shelf
Aggregated
alarms
i.e. port alarm
Slot
Service
Card
Object alarm X
Site
Affecting Alarms
(i.e Port)
Port
Alarms on
Related Objects
(i.e. SAPs)
Aggregated
alarms
i.e. SAP alarm
SAP
Object alarm
Module 2 |
35
Module 2- 35
Node
Fault Management
Without alarm suppression enabled, all of these alarms

appear in the alarm window, making it difficult to notice
that the parent alarm is the port
Alarm suppression hides the child alarms and shows only the
parent alarm
Module 2 |
36
Module 2- 36
When an object with a lot of dependent objects fails (such as

a port), a large number of alarms are created on the
dependent objects (such as SAPs on that port)
Alarm Correlation and Suppression
Equipment
Node
Shelf
Service
Slot
Service
Card
Site
LSP
Port
SAP
MPLS
Network
Module 2 |
37
Module 2- 37
Network Model Alarm Correlation and Suppression
By default, correlated alarms are not displayed on the Dynamic Alarm

window; they can be viewed by drilling into the correlating alarm
The correlating (parent) alarms severity reflects the highest
severity of either it or its correlated alarms
Module 2 |
38
Images show the object alarm of a Physical port going down and its correlated alarms.
To view all correlated alarms in the Dynamic Alarm window, select the checkbox labeled
Show Correlated Alarms in the Dynamic Alarm Window.
Module 2- 38
Correlation in the 5620 SAM is based on correlation rules that are built
into it for each alarm
How Alarm Correlation works
This is a correlating alarm

because the View Correlating
Alarm button is not active
Module 2 |
39
Module 2- 39
Correlating Alarm (Parent)
This is a correlated alarm

because the View Correlating
Alarm button is active and the

Correlating Alarm ID field
contains the parent alarm
name
Module 2 |
40
Module 2- 40
Correlated Alarm (Child)
Module 2 |
41
Module 2- 41
The number of correlated alarms is visible in: the Dynamic

Alarm window, the Alarm Info window and when alarms appear
in lists
The Alarm Window shows the number of correlated alarms
To view correlated alarms in the

Dynamic Alarm window, select the
Show Correlated Alarms checkbox
Correlation On
Correlation Off
Module 2 |
42
To Enable/Disable the display of correlated alarms by default in the Dynamic Alarm

window:
(Application -> User Preferences -> select Show Correlated Alarms by Default)
Module 2- 42
You can turn Alarm Correlation/Suppression on by default in the

Preferences on a per-operator-position basis.
Turning Alarm Correlation/Suppression on/off
Only receives alarms that are not already correlated under

another alarm
Helps reduce the number of JMS messages going to the OSS
An OSS client can subscribe to all alarms, whether or not

they are correlated
Module 2 |
43
JMS - Java Messaging Service

OSS - Operations Support System
Module 2- 43
A 5620 SAM OSS Interface (SAM-O) client can subscribe to JMS

messages based on the correlation attribute
Alarm Correlation/Suppression and SAM-O
Node
Shelf
Slot
Service
Card
X Port
Correlating Alarm
Site
SAP
X Object alarm
Correlated Alarm
Module 2 |
44
Module 2- 44
A card alarm correlates the port alarms, which correlate the SAP alarms
The correlating alarms appear in the Alarm window (the card alarm)
The correlated alarms (port and SAP) appear in the Correlated Alarm tab.
Double click the Card alarm to see the window
Correlation Hierarchy
4. Examine the details of alarms
Module 2- 45
5620 SAM Alarms
Both the Probable Cause and Description attributes show

that the port is administratively shutdown
Module 2 |
46
Module 2- 46
The port appears to be the cause of the problem
Example: Link cut on network port
Module 2- 47
5620 SAM Alarms
First we make a cut at 1 and observe the alarms. Although the equipment and network
interfaces show alarms, the service is not affected because the service tunnel reroutes through
r2. Then we make a cut at 2. Equipment and network alarms are generated, and the service
goes into an alarm state.
Cut 1
Cut 2
Module 2 |
48
Module 2- 48
A VPLS service runs between r5, r1 and r2 over RSVP tunnels
Example: Network-side Alarms
Physical Topology
Module 2 |
49
Module 2- 49
Before any cable cuts: everything is green, no alarms
Module 2 |
50
(Select Service with ID # 71 -> Tunnel used by mesh-SDP on r5 from r5-r2 properties -> LSPs tab ->
Properties of the Dynamic LSP from r5-r2 -> General tab)
(Select Service with ID # 71 -> Tunnel used by mesh-SDP on r5 from r5-r2 properties -> LSPs tab ->
Properties of the Dynamic LSP from r5-r2 -> LSP Path Bindings Tab -> Properties of LSP Path Binding ->
Actual Path tab)
Module 2- 50
Before cut 1, LSP goes directly from r5 to r2
Service Tunnel Topology
VPLS Service Topology
Module 2 |
51
Module 2- 51
Physical Topology
Cut 1: Equipment and network alarms, but no service alarms
Module 2 |
52
(Select Service with ID # 71 -> Tunnel used by mesh-SDP on r5 from r5-r1 properties ->
LSPs tab -> Properties of the Dynamic LSP from r5-r1 -> General tab)
Module 2- 52
The service re-routes the ingress interface from r2 to r1
Module 2 |
53
Module 2- 53
Cut 2: Equipment, network and service alarms
Module 2 |
54
Module 2- 54
Service topology and hierarchy after cut 2
Module 2 |
55
Module 2- 55
Routing tree after cut 2
Module 2 |
56
(Select Service with ID # 71 -> Tunnel used by mesh-SDP on r5 from r5-r2 properties ->
LSPs tab -> Properties of the Dynamic LSP from r5-r2 -> General tab)
Module 2- 56
The service has no ingress interface because both links are down
Module 2 |
57
Module 2- 57
The physical port shows the impact on other objects in the

Alarms on Related Objects tab
Module 2 |
58
(Routing -> properties of routing network interface r5-r2 on r5 -> Faults tab)
Module 2- 58
The network interface shows Object Alarms,

Affecting Alarms Alarms on Related Objects alarms
Investigating Service Alarms
Module 2- 59
5620 SAM Alarms
The procedure (described in the next slide) does not replace

analyzing alarms in the alarm window. It provides another
way to track the health of services.
Module 2 |
60
Module 2- 60
Alcatel-Lucent 5620 SAMs Service Manager provides a useful

way to monitor all services to track their health.
Investigating Service Alarms Using the Service Manager
Configure the Service Manager to show the Aggregated Alarm Status

in an easy viewing position
If required, narrow the search by using a filter
Wording such as Critical in the Aggregated Alarm column indicates
the highest severity alarm among the service components
Row color applies to the services alarm status
Module 2 |
61
In above image the rows are white because the services are operationally up.
(Manage -> Service -> Services)
Module 2- 61
Service Manager: Investigating alarms
Module 2 |
62
Module 2- 62
Open the Service Configuration form and note the State Cause information
To drill further, expand the service navigation tree.
Service Manager: Investigating Alarms State Cause
Go to the States tab, which provides good error information
Module 2 |
63
Module 2- 63
From the service navigation tree, click the objects with object
alarms (red square)
Service Manager: Investigating Alarms States Tab
Open the alarm
Module 2 |
64
Module 2- 64
The Faults tab of the service shows the mesh binding in a

critical state under the aggregated alarms, as everything is
under the service.
Service Manager: Investigating alarms Faults Tab
Click on View Correlating Alarm to open it

If you see it click it
Module 2 |
65
Module 2- 65
There is a correlating alarm, so we know this alarm is not the

source of the problem
Service Manager: Investigating Alarms View Correlating
There are no more

correlating alarms, so this is
as far as the 5620 SAM will
take you on this path
View the alarm information,

specifically the Probable
Cause, Additional Text and
Description and Remedial
Action attributes
Module 2 |
66
Module 2- 66
Service Manager: Investigating Alarms Probable Cause
Tools
Module 2- 67
5620 SAM Alarms
Alarm Squelching
Additional Text
Changes to these alarm policies have a global effect
Module 2 |
68
Module 2- 68
Specific alarm policies and configurations
Alarm Tools
Administration -> Alarm Settings
Module 2 |
69
All alarms in 5620 SAM list can be seen under: (Administration -> Alarm Settings -> Specific tab)
Module 2- 69
Global Alarm Policies
If facing a flood of a particular

alarm type, select Squelch.
Module 2 |
70
Alarm policies can also be viewed by (Administration -> Alarm Settings -> Specific tab)
An Alarm Info window has a button on the bottom that will open the Specific Policy for the Alarm.
A squelched alarm no longer correlates alarms, nor does it go to the OSS. Other alarms that would have
been correlated by the squelched alarm are still generated.
Troubleshooting value - temporary squelching of an alarm (note that this will squelch that type of alarm
from all NEs).
Module 2- 70
Specific Alarm Policy Window
Displaying associated information within the alarms Info tab

makes identifying the cause of the problem easier
You must create an Additional Text Policy
Module 2 |
71
Module 2- 71
Alarms can be configured to have the Additional Text field

populated with specific values.
Populating Additional Text
1. From the SAM main menu, select Administration -> Alarm

Settings
2. Select the Additional Text tab and click the Create button
Module 2 |
72
(Administration -> Alarm Settings -> Additional text)
Module 2- 72
To create an Additional Text Policy;
3. Select the Domain, Object

Type and whether or not to
Overwrite existing
4. Select the Additional Text
Attributes tab and add the
desired attributes and their
order by clicking the
Create button. Add as
many attributes as needed.
5. Click the OK buttons to
save the policy
Module 2 |
73
Overwrite existing some objects have pre-populated Additional Text values. Selecting this option will
remove this value and replace it with the one defined by this policy.
Once the above policy is created, any new physical port alarms will include the ports MTU value in the
alarms additional text field.
Module 2- 73
Select attributes where problems or misconfigurations

commonly occur. E.g. MTU Value
If there are particular values set the same across a network
and operators are aware of these values, adding them to an
additional text policy can allow an operator to easily pinpoint
the problem
Module 2 |
74
Module 2- 74
Best Practice:
Unexpected Behaviors
Module 2- 75
5620 SAM Alarms
2. Implicitly self-clearing vs. non-self-clearing alarms
Module 2 |
76
Module 2- 76
1. An object may have an alarm coloring for aggregated

objects and yet have no child objects with alarms
Some Counter-Intuitive Cases
This is because the Navigation tree is a filter for different views

When you change the view using the drop-down menu - from
Equipment to Routing, for example the aggregated alarm on
the child object may appear
Also, the alarmed object may not exist in the Navigation tree
(The Power Supply is an example)
Module 2 |
77
Module 2- 77
In the Navigation tree, an aggregated alarm may be present

when no child object in the tree has an alarm.
1. Alarms Appearing to Have No Child
View from
Equipment
Navigation Tree
might not show an
alarm.
Consider examining
the Routing
Navigation Tree
instead
Module 2 |
78
Equipment Navigation Tree shows a critical alarm circle, but its source is not visible in the tree.
There are a few options to pursue:
1. Open the Properties of the object, look at its Faults tab and look for Aggregated Alarms (recall that
circular icon == aggregated)
Or
2. Since the issue does not appear to be equipment-related, switch to the Routing Navigation Tree.
Module 2- 78
Wheres the critical

alarm?
1. Alarms Appearing to Have No Child
Non-self-clearing alarms need to be manually cleared

Each alarm has a field that indicates if the alarm is Implicitly
Cleared or not
Example: NodeRebooted alarm
Module 2 |
79
Module 2- 79
Implicitly self-clearing alarms will clear when an appropriate

trap is received
2. Implicitly Self-clearing vs. Non-self-clearing Alarms
Specified per alarm type

Can be viewed from the Alarm Settings window
Module 2 |
80
This feature is only available in 5620 SAM Release 10.0 R5 and above.
Module 2- 80
Can set to auto-delete an alarm after 4, 7, or 30 days
Auto-Deletion of Non-Self-Clearing Alarms
Open the selection box and choose the desired time
Module 2 |
81
Module 2- 81
Select the desired specific alarm and open its policy form
Setting the Auto-Deletion Rule
Alarm information & coloring

Optimizing alarm viewing using the Dynamic Alarm window
Acknowledging and adding notes to alarms
Alarm correlation and suppression
Alarm hierarchy/relationships
Alarm history
Additional Text
Monitoring service alarms
Unexpected alarm behaviors
Module 2 |
82
Module 2- 82
The sources of alarms presented by SAM
Module Summary
Module 2 |
83
Module 2- 83
Module 2- 84
Module 3 Navigation Trees

the 5620 SAM
Module 3 - 1
After successful completion of this module, you should be able

to:
Determine the status of an object from the Equipment
Navigation tree
Determine if an IOM or MDA is properly configured
Module Objectives
Determine the status of a service from the Service Navigation

Tree
Change the view and the root of a view in the Equipment
Navigation trees
View the status of L3 protocols in the Routing Navigation tree

Open new Equipment trees at different hierarchy levels
Module 3 |
Module 3 - 2
Determine the following information on L3 interfaces:

IP address, Port and Status
Module Objectives (cont.)
Determine if all the interfaces and adjacencies are functional

Derive the status, IP address and neighbor of each interface
Determine if there are alarms on the objects
Identify which instances and areas have been configured
View the type (broadcast or point-to-point) and designated
router status of an interface
Use the contextual menus of the trees
Module 3 |
Module 3 - 3
Overview
Navigation Trees
Module 3 - 4
Navigation Trees
Provide a quick way to view all, or portions of, the networks

equipment, routing instances or services
Allow multiple windows to be opened, with each one capable

of showing a different view of the network. These views
assist in troubleshooting by allowing the operator to compare
objects
Clearly show hierarchy of items
Allow operators to work within the tree, not just view items,
through contextual menus
Are dynamically updated so that the alarm status of an
object is kept current
Module 3 |
Module 3 - 5
Navigation Tree - Find
Press Enter to perform the search

If multiple instances are found, the arrow buttons are
enabled to allow the user to step through each instance
Module 3 |
Enter text in the Find textbox
Module 3 - 6
Navigation Tree Advanced Find
Enter text into one or more text boxes

Next/Previous buttons appear when multiple matches are found
Module 3 |
Click the Binoculars button to open up the Advanced Find window
Module 3 - 7
Depending on the tree and the target object, a right-click

will cause a contextually-based menu to appear.
Several menu items appear in more than one context:
e.g. Resync, Properties
Module 3 |
Navigation Trees - Contextual Menus
Module 3 - 8
Equipment Navigation Tree Contextual Group Menu
Right-click on a Group
Module 3 |
Module 3 - 9
Equipment Navigation Tree Contextual Router Menu
Right-click on a router
Module 3 |
10
Module 3 - 10
Equipment Navigation Tree Contextual Router Menu
On a router -> NE Sessions
Module 3 |
11
Network Element Sessions

Launches a Telnet, SSH or File Browsing session to the router.
Module 3 - 11
Equipment Navigation Tree
Navigation Trees
Module 3 - 12
Allows you to locate a problem faster

Alarm aggregation helps operators to quickly drill down the
Navigation tree to find objects with alarms
Module 3 |
13
Equipment Navigation Tree
Module 3 - 13
Status of slots, cards and ports are easily seen
Module 3 |
14
Equipment Navigation Tree Object Status
Helps to determine if an IOM or MDA is properly configured.
Module 3 - 14
Opens a new window
Module 3 |
15
In the contextual menu via right-click, select Make Root in New Tree
New window gets created, with the root of that windows tree being the originating selected object.
Helps manage large lists by letting the operator examine an individual branch.
Can be used to compare two sub-trees by opening multiple new trees.
Trees can then be used to create more new trees.
Module 3 - 15
Allows operators to
focus on specific
branches of the
network tree
Equipment Navigation Tree - Make Root in New Tree
Does not open a new

window
Equipment Navigation Tree - Make Root
Becomes
Module 3 |
16
Within a Navigation Tree window, the root can be changed. No new window is spawned.
Module 3 - 16
A Navigation Tree window can be reverted back to using the entire

network as the root of its displayed tree by clicking on the Make Root
At Top Level button.
Module 3 |
17
Equipment Navigation Tree - Reverting Back to Full Tree
Module 3 - 17
Routing Navigation Tree
Navigation Trees
Module 3 - 18
Similar to the Equipment tree
The Routing tree allows operators

to quickly navigate through the
networks L3 interfaces and
protocols
Alarm indicators are also present
Module 3 |
19
Module 3 - 19
Routing Navigation Tree Protocol Instances
For IGP/IRP protocols, alarms are shown below the instance
Module 3 |
20
The IGP/IRP Instances dont have alarm indicators. Their alarms do appear below them in the tree.
Where is an alarm? Open each high level protocol branch to spot the issue.
Module 3 - 20
Enabled protocols on routing

instances
Admin Status
Status
Site ID
Partially configured items (in

this case the interface
Bogus and RIP)
Module 3 |
21
In this case, the RIP protocol is enabled, but its status is down. Theres no child of that line in the tree, which
suggests that theres no group/interface assigned to it.
Note: You may see a drop-down key when no child exists. Once the key is clicked, the system will look for a
child, not find one, and then remove the key icon. The row above, with No Association, is an example of this,
indicating that theres no associated port.
Good naming conventions help add extra meaning, for example to75 above indicates that the interface is
connected to another router identified by 75.
Module 3 - 21
Shows:
Service Component Navigation Tree
Navigation Trees
Module 3 - 22
The overview of an entire service presented in one window can help to

quickly determine where a fault exists.
Module 3 |
23
Determine the status of a service from the services Navigation Tree. It is located on the Service Properties
Form.
(Manage -> Service -> Services -> VPLS #)
Displayed on one screen are: statuses, alarm coloring, the service components that are broken or missing, and
key values that commonly need to be compared.
Contextual menus exist for many of the objects presented in this tree to help with configuration and
troubleshooting a service.
Module 3 - 23
Service Navigation Tree
Navigation trees provide a fast way to simultaneously view the

attributes of many network objects within a hierarchy.
Attributes such as:
Status and alarm coloring
Configuration
Network Objects:
Physical equipment
Routing
Module Summary
Service components
Many options are available in contextual menus to help investigate

and modify network objects:
Make Root, Create, Properties, etc.
Module 3 |
24
Module 3 - 24
Multiple windows with different views of the same tree can be

opened
Trees are dynamically updated
Module 3 |
25
Module Summary (cont.)
Module 3 - 25
Module 3 |
26
Module 3 - 26
Module 3 - 27
Module 4 Topology Views

the 5620 SAM
After successful completion of this module, you should be able to:

Use the legend
Interpret the icons in the topology map
Find a specific router on the map
Apply filters and configure flat maps
Use the Highlight MTU mismatch tool
Highlight active sessions
Module Objectives
Explain various contextual menus of icons

Use the LLDP functionality of the 5620 SAM
Understand extended functionality offered by CPAM
Module 4 |
Module 4 - 2
Topology maps have a button that opens a quick reference window

explaining the icons that may appear on the maps
Module 4 |
Map Legends
Module 4 - 3
Use Show Alarmed Links Only to switch from a normal view of all
links to displaying only links that have alarms
Show Alarmed Links Only (Physical or Service Tunnel)
Enabled (Yellow)
Very useful when map is densely populated
Module 4 |
This is a very useful troubleshooting tool!
In a large network with many links, the display of links may be very dense.
By using Show Alarmed Links Only, links that have potential issues can be found easily.
The button turns yellow when activated.
Module 4 - 4
Show Alarmed Links
Module 4 |
Note: only the Alarmed Service tunnel is shown
Module 4 - 5
Module 4 |
Enable Alarm Link Pullout - The icon is yellow, and links with associated alarms are displayed separately on the
topology map. The link groups containing all links are grey.
This feature is very helpful for monitoring when alarms are cleared on a specific link. Picture a scenario where
there is more than one alarmed link in a group and this feature is not enabled. Fixing only one of these would not
turn the link group grey, as there are still links with alarms within the group. This may lead the operator into
thinking that both or all links are still in an alarmed state.
Module 4 - 6
Use this option to separate alarm links from the link group
within the topology window
Enable Alarm Link Pullout
Show Selected Only
Use Ctrl-click to select multiple routers
Very helpful for focusing on a subset of the network
Module 4 |
This functionality appears as an option in the right click context menu

if one or more routers are selected on the map
Module 4 - 7
Topology maps have a Find button (binoculars)

Select Find Vertex or Find Link to display a list
The list has the common quick find, filtering and span abilities
Finding a Router (Vertex) or a Link
From the list, select an item to view and the topology map will switch
to that object regardless of which group the object is in
Useful in troubleshooting to find specific objects
Module 4 |
Module 4 - 8
The searchable area is limited to the maps current group
The Search Field on Topology Maps
Found items are indicated by a black box.

To search the entire network use Find (binoculars) instead
Module 4 |
Module 4 - 9
Module 4 |
10
Navigate, located at the bottom of the Properties window, allows the operator to find the router in the Physical or
Service Topology map quickly.
Module 4 - 10
To find a router in a topology map: from the Properties form,

click More Actions Navigate Physical View OR Service
Tunnel View
Navigate to Object (Topology View)
Allow operators to create and save filtered views of the network

Can display up to 1000 objects
Display the Physical or Service Tunnel topology
Flat Maps
Can create simpler views of a large number of network objects or link

groups
Display icons at a reduced size, with thinner link lines, and no object
information displayed
Module 4 |
11
Module 4 - 11
Flat Maps Viewing Objects Across Groups
Provides a complete
network view without
topology groups
Physical Topology
Flat Map
Module 4 |
12
Module 4 - 12
Opens an overview window that has the current maps view

marked on it
Overview Button
Click and hold

anywhere in the
box to move
Click, hold and

drag one of the
yellow squares in
the corners to
resize
Module 4 |
13
Click and hold anywhere in the box, then drag to move.

Click, hold and drag one of the yellow squares in the corners to resize.
Module 4 - 13
Right-click on Physical Topology map and select

Highlight MTU Mismatch
Shows differences in physical port MTU only
Module 4 |
14
Module 4 - 14
Applies to the current Physical Topology window

The sessions are preserved only until the topology window is
closed
Highlight MTU Mismatch, for example
Module 4 |
15
Highlight Sessions
Module 4 - 15
Right-click on a session to:

Delete the session
Show Only Highlighted helps to view links on dense maps
Module 4 |
16
Highlight Sessions (cont.)
Module 4 - 16
User Preferences - Topology
A common practice is to set/change the 2nd text label of NEs when

performing different activities.
Some Topology icons have two text labels that can be configured to display
various fields.
Application User Preferences
Module 4 |
17
For example, the 2nd text field can be used to display the Location or Management IP address.
Module 4 - 17
Ability to quickly see some chosen values

Header option allows the user to enable or disable the
viewing of the table header information.
Mouse option enables the viewing of the Info Table on object

mouse-over only
This is the preferred method, as turning Info Tables on
permanently can sometimes clutter topology windows.
Module 4 |
18
Excellent tool to quickly view multiple router values at once without having to search through the routers
Properties form.
Also great for viewing the same value over multiple routers without having to launch multiple Properties forms.
Module 4 - 18
You can create an information table configuration for all map

objects, selected map objects, or map highlights
Global Info Tables
Global Info Tables Creation
Click the Global Info Tables button, then select Configure

3
1
Module 4 |
19
Module 4 - 19
Global Info Tables (cont.)
From the Global Info Tables

button, select which table to
enable.
This will apply the selected table
globally
Mouse-over the NE to view the

Info Table
Right-click on the NE to
enable/disable or change the
Info Table for that specific NE
only
Module 4 |
20
Module 4 - 20
Right-click on a router
Also present in the Service
Tunnel Topology
Module 4 |
21
Physical Topology: Contextual Menu
Module 4 - 21
Clicking the layout button can help with cluttered topology

views
Before
Layout
After
Module 4 |
22
Module 4 - 22
Spawn Navigation Tree from Topology Map
Right-click on a group or node and select Make Root in New Tree to

open a new equipment tree
Module 4 |
23
Module 4 - 23
The Physical Topology can have filters applied to it

Filters can be saved
Span can also be enabled on a filter
Module 4 |
24
Physical Topology Filter
Module 4 - 24
Example: a filter to show routers that are in the Maintenance OLC

state
Module 4 |
25
Physical Topology Filter
Module 4 - 25
LLDP is enabled at the system and physical port levels

A red link may mean that the LLDP session is down, not that the
actual link is down (remote peer not working)
Module 4 |
26
Link Layer Discovery Protocol (LLDP) is a neighbor-discovery

protocol that allows a network access device to advertise its identity
and capabilities to other stations attached to the same physical LAN
Link Layer Discovery Protocol is a not a routing protocol, but rather a neighbor-discovery protocol. As such, it is
configured in a different manner than the standard routing protocols. LLDP allows a network access device to
advertise its identity and capabilities to other stations attached to the same physical IEEE 801 LAN. It also permits
information that the devices discover about peer devices to be stored. LLDP is only applicable for devices using
Ethernet connectivity.
5620 SAM uses the information stored in the applicable LLDP tables on the router to automatically discover the
physical topology in the network. You can use this information to examine the L1/L2 topology and perform
appropriate diagnostics and troubleshooting.
There are two ways for links to appear in the topology map: discovered via LLDP, and manually created in the
GUI.
Manual Physical Link creation (Right-click on Physical Topology map -> Equipment -> Create Physical Link)
Module 4 - 26
Physical Links and LLDP
5620 SAM refers to LLDP links as Discovered Physical Links while

manually added links are referred to as Physical Links
Module 4 |
27
The Find button Find Link on the Topology Map offers two pre-defined filters in its search: Discovered Physical
Links and Physical Links
Module 4 - 27
Physical Links discovered via LLDP have LLDP in their Link

Discovered from: field in their Properties window
LLDP and Discovered Physical Links
Displays a list of LLDP remote peers associated with a particular

network element.
Module 4 |
28
LLDP Remote Peers
Module 4 - 28
Once LLDP timers expire

Becomes
Module 4 |
29
On the physical topology map background, the Reference option takes a snapshot of the physical topology at a
specific time. Any deviation from this checkpoint can then be subsequently shown. You can choose from the
following options:
Reference all Discovered Links in NE Group - checkpoints all currently discovered links that exist. Any object
that was previously checkpointed and found to be operationally down is left untouched. Any object that goes
operationally down in the future is not removed, but is simply marked as operationally down.
Clear Reference for All Discovered Links in NE Group - clears all object checkpoints. Any object that is
operationally down (shown as a red link) is removed from the database. Any non-checkpointed object that
becomes operationally down in the future is removed from the system.
Cleanup all Discovered Links in NE Group - keeps the current checkpoint set for objects that are operationally
up, but removes checkpoints from objects that are operationally down. This is the same as the Clear Reference
for All Discovered Links in NE Group option, but only affects operationally down objects.
Module 4 - 29
Right-clicking in the topology window will bring up the Reference

menu options
LLDP Reference Menu
LLDP Reference Single Links
Executed from the Discovered Physical Link properties form
Module 4 |
30
SAM can reference individual links as opposed to all links in a

group
This feature is only available in SAM R9.0 R7 or greater.
The Discovered Physical Link properties form also indicates:

If the link was referenced
When it was discovered and referenced
Which user referenced the link
If LLDP is disabled, when it was disabled
Clearing the reference also clears the User and Reference Time fields
The Discovery Time is unaffected by clearing the reference
Module 4 - 30
LLDP Multi Selection of Reference Links
Allows the reference of multiple selected discovered physical

links as opposed to all the links in a group
Use shift-click to select multiple links groups within a topology

group
Module 4 |
31
This feature is only available in SAM R10.0 R3 or greater.
Module 4 - 31
LLDP Labels
Gives meaningful names to unmanaged routers

Configured by selecting the required LLDP TLVs
Module 4 |
32
5620 SAM is able to display LLDP labels (name/description)

instead of just the MAC address for an unmanaged router that
is running LLDP
For both nodes:

Notifications can be true or false.
Transmit Management Address can be Enabled or Disabled.
Any additional TLVs can be selected.
This feature is only available in 5620 SAM 8.0 R5 and above.
Module 4 - 32
This ALU-IPD-SRC Alcatel-Lucent_Network_and_Service_Troubleshooting_with_the_5620_SAM Guide is for exclusive use of Kazi_Zial_Hoque - WIN
Without Labels
With Labels
- System Name TLV
Module 4 |
33
LLDP Labels
Module 4 - 33
Maps can be filtered to give operators a more targeted view

Help to quickly find an object within the network using search
functionalities
Module Summary: Troubleshooting Benefits of Topology Maps
Topology maps provide specific features to reveal issues in the

network such as MTU Mismatch and Highlight Alarmed links/tunnels
Maps display object status with colors and changing icons
Make Root feature offers easy navigation in the tree
Groups allow organization of the network view as well as the ability
to zoom in and out
LLDP Configuration allows enhanced physical link
monitoring/troubleshooting
Module 4 |
34
Module 4 - 34
Module 5 Service Test Manager (STM)

the 5620 SAM
View and configure STM parameters

View, analyze and compare test results
List steps taken to auto generate and schedule tests
Use event logs and alarms in OAM tests
Module 5 |
Module 5 - 2

to:
Module Objectives
This module describes how STM in 5620 SAM can

be used to troubleshoot common issues.
Module 5 - 3
Service Test Manager
Overview
Module 5 - 4
In order to verify that a service is operational, a set of

packet-based OAM tools is required
Can be performed on a per-service basis
For in-band testing, the OAM packets closely resemble
customer packets
There are diagnostics for LSPs, SDPs, and Services
Module 5 |
For in-band testing, the OAM packets closely resemble customer packets, but are distinguishable from
customer packets so they are kept within the service providers network and not forwarded to the
customer.
Module 5 - 5
Provides the ability to execute various OAM (Operation,

Administration and Maintenance) tests for network
troubleshooting
Overview
From the Properties forms on network objects, for example, LSP

pings from the LSP Properties form
From the Tools -> Service Test Manager (STM) form
From the Service Topology
Best practice:
Create and/or execute tests by viewing the Properties form
of the specific object that is being tested and selecting the
Tests tab. When creating tests for Services, use the Service
Topology Window.
Module 5 |
Module 5 - 6
Can configure and manage OAM tests:
Creation and Management
Test results can also be displayed in an Info Table
Right-click on a
service site to open
the menu
Once the test is

completed, the
results are displayed
in an Info Table
3
Create a new test
OR
Select a previously
created test
1
To enable the OAM
menu options,
select the OAM
checkbox
Module 5 |
This feature is only available in 5620 SAM Release 8.0 R5 and above.
Module 5 - 7
OAM Tests can be fully configured from the Service Topology window
OAM from the Service Topology
The following is a list of

supported OAM test
types and the objects
each test can be
performed against:
Module 5 |
This chart is from the 5620 SAM User Guide.
Module 5 - 8
Service Assurance OAM Test Types and Objects
Module 5 |
Module 5 - 9
Service Assurance OAM Test Types and Objects (cont.)
Module 5 |
10
Module 5 - 10
Service Assurance OAM Test Types and Objects (cont.)
OAM Tests for Troubleshooting
Module 5 - 11
This test verifies:

Local and remote service sites exist
The current state of the local and remote service sites
Local and remote service types are correlated
The same customer is associated with both local and remote
service
Local and remote ingress and egress service labels match
There is a service-to-SDP binding association at both local and
remote service sites
Module 5 |
12
Test Initiated from one Service Edge router.

Used to verify full roundtrip and delay.
Module 5 - 12
Tests a service ID for correct and consistent provisioning

between two service endpoints
Service Site Ping (svc-ping)
Performs in-band MTU path tests on an SDP to determine the

largest path-MTU supported on a service tunnel (SDP),
within one byte
It is important to understand the MTU of the entire path endto-end when provisioning services that must support the
ability to transmit the largest customer packet
Module 5 |
13
MTU Maximum Transmission Unit
Module 5 - 13
MTU Ping (sdp-mtu)
Follows the same path as traffic within the service

For roundtrip tunnel ping, the Return Tunnel ID must be
specified or a unidirectional SDP test is performed
Module 5 |
14
For a unidirectional test:

The egress SDPs encapsulation
Ability to reach the far-end IP address of the SDP within the SDP encapsulation
Path MTU to the far-end IP address over the SDP
Verifies Forwarding class mapping between the near-end SDP encapsulation and the far-end
tunnel termination
Determine whether SLA delay metrics are met
SDP roundtrip testing extends SDP unidirectional tests with the additional ability to test:
The remote SDPs encapsulation
Potential service roundtrip time
Roundtrip path MTU
Roundtrip forwarding class mapping
Module 5 - 14
Performs in-band unidirectional or roundtrip connectivity

tests on SDPs
Tunnel Ping (sdp-ping)
Works with third-party NEs

The packets are sent using the same encapsulation and along
the same path as user packets in the VLL
Provides a check of both the control and data plane
VCCV echo
request
VCCV echo
reply
VLL Service
PE1
PE2 (third-party
switch)
SAP to
CE1
SAP to
CE2
VCCV Trace - Displays the hop-by-hop path used by the VLL

Module 5 |
15
In this example:
The ping test packet or packets are sent with the destination IP address of PE2
The request is encapsulated in a VLL packet and is forwarded to PE2
PE2 replies to the source device IP address
Difference between sdp-ping and vccv-ping?
- sdp-ping only works with 7x50 equipment, but vccv-ping works with third party NEs
- vccv-ping asks to assign a spoke-SDP ONLY
VCCV- ping message format is similar to LSP-ping, but the functionality is closer to an sdp-ping on 7x50.
Dedicated control channel between pseudowire endpoints for VCCV messaging.
Three ways of sending VCCV messages:
1. In-band connectivity testing using Control Word
2. In-band connectivity testing using pseudowire TTL label
Set the TTL in the VC label (inner label) to 1
3. Out-of-band using Router Alert Label
VCCV - Virtual Circuit Connection Verification
Module 5 - 15
Performs in-band VLL connectivity tests
VCCV Ping (vccv-ping) and Trace (vccv-trace)
Can be used together to detect and localize faults in IP

networks
Ping
Can be used from a VRF (Virtual Routing and Forwarding) site of
the subscribers VPRN service to determine the existence of the
far-end egress point
Trace
Displays hop-by-hop path for a destination IP address
Allows target types of Core Routing Site or VPRN Site
Module 5 |
16
Can be sent in-band or out-of-band
VRF -> virtual routing and forwarding - A logical or virtual routing function with associated routing table
that can be instantiated in a device capable of supporting IP VPN services.
Module 5 - 16
Identify the reachability of a remote host across the IP

network
ICMP Ping (icmp-ping) and Trace (icmp-trace)
Tests whether the LSP tunnels are working in both

directions
Provides two functions: MPLS ping and MPLS traceroute
MPLS ping verifies whether the packet reaches the egress LER
LSP
Ping
reply
LSP
Ingress LER
(Originating
SR)
LSP
Ping
request
LSP
LSP
Egress LER
(terminating
device of the LSP)
Module 5 |
17
In this example:
The originating router creates an MPLS echo request packet for the LSP and MPLS path to be
tested
The MPLS echo request packet is sent and awaits an MPLS echo reply packet from the router
that terminates the LSP
The LSP status is displayed when the MPLS echo reply packet is received
Modeled after the ICMP echo request/reply to detect and localize faults in IP networks
Module 5 - 17
Performs in-band LSP connectivity tests
LSP Ping (lsp-ping)
LSP Trace
request
LSP T
LSP
Ingress LER
(Originating
SR)
Displays the hop-by-hop path used by the LSP
LSP T
LSP
LSP
Egress LER
(terminating
device of the LSP)
LSP
Trace
replies
Module 5 |
18
In this example:
The originating router creates an MPLS echo request for the LSP to be tested
Packet contains increasing TTL values
The MPLS echo request packet is sent and waits for a TTL exceeded response or the MPLS
echo reply packet from the router that terminates the LSP
Each device along the hop-by-hop route replies to the MPLS echo request packets with TTL
and MPLS echo reply information
Module 5 - 18
LSP Trace (lsp-trace)
Module 5 |
19
Module 5 - 19
Run an OAM LSP trace test on Dynamic LSP r2-r4-r3-r1-#2
Example - LSP Trace
Populates a service FIB with an OAM-tagged MAC entry

This MAC entry indicates that the router is the egress address of
the service
Sends a message by flooding the domain to learn a MAC

address
This test can:
Force an existing MAC address to become OAM-tagged
Distinguish MAC addresses that are OAM-tagged
Age an OAM-tagged MAC address
Module 5 |
20
Module 5 - 20
Checks the accuracy of the FIB table by testing forwarding

plane correctness
MAC Populate (mac-populate)
Module 5 |
21
FIB entries must be resynced through SAM before they can be viewed. Be sure to click the Resync button
on the right side of the panel before viewing any FIB entries.
Module 5 - 21
Specify if you want to flood this OAM-tagged MAC address to other

devices, so that the same OAM-tagged entry is added to the FIB
tables of other devices
MAC Populate (cont.)
Tests connectivity in a VLL or VPLS by verifying a remote MAC

address at the far-end of a service
Trace
Displays the hop-by-hop route of MAC addresses used to reach
the target MAC address at the far-end of a service
For both tests, one must specify either the far target (farend) MAC address or the broadcast address
Module 5 |
22
MAC-PING
For in-band:
The ping packet goes across each hop, and when it reaches the egress router, it is identified
by the OAM label and the response is sent back along the management plane
For out-of-band:
The ping is forwarded along the flooding domain when no MAC address bindings exist, or is
sent along the bindings if MAC address bindings do exist
A response ping is sent from the far-end device when there is an egress binding for the service
MAC-TRACE
For in-band:
The trace request contains tunnel encapsulation, VC label, OAM, and other information
For known-destination MAC address, the appropriate tunnel encapsulation and VC label is used
Otherwise, the packet is sent to all service tunnels, including all necessary tunnel
encapsulation and egress VC labels for each bound service tunnel
For out-of-band:
The destination IP address is specified by mapping the destination MAC address
If the destination MAC address is known to be a specific site, the far-end IP address of the
service tunnel is used
Otherwise, the packet is sent to all service tunnels in the service.
Module 5 - 22
Ping
MAC Ping (mac-ping) and Trace (mac-trace)
Allows one to do a controlled OAM test without the learning

induced by customer packets
The purge can also tell the control plane to not allow further
learning from customer packets
Module 5 |
23
Module 5 - 23
Deletes an OAM-tagged entry from a FIB, which was

generated using the MAC populate test
MAC Purge (mac-purge)
Can detect an end-station IP address inside a VPLS

Each peer PE within the VPLS context will trigger an ARP request
for the specific IP address
The PE receiving a response to this ARP request will report back
to the requesting device
CPE Ping reply
CPE Ping request

(Destination 5.5.5.187)
CPE Ping
reply
SAP
Module 5 |
24
The MAC ping OAM tool makes it possible to detect whether a particular MAC address has been learned in
a VPLS.
The CPE Ping extends this capability to detecting end-station IP addresses inside a VPLS.
Important to use non-existent source address so customer ARP cache is not polluted with an invalid ARP
entry.
Module 5 - 24
Traces end-to-end switching of specified MAC address of

customer premises equipment
CPE Ping (cpe-ping)
OAM Test Parameter Configuration
Module 5 - 25
ID
Name
Description
Administrative State
NE Persistent if enabled, the OAM test is deployed to a router
after the first run and it remains on the router in memory only
NE Schedulable - specifies whether the associated OAM test, or
the test suite generated from the policy, can be scheduled and
run on managed NEs (default = disabled)
Module 5 |
26
General tab
ID specifies a unique numeric identifier for the created object (by default set to auto-assign ID)
Name specifies the name of an object
Description specifies a description for the created object
Administrative State specifies whether the object can be put in service
NE Schedulable
If enabled, Ignore Probe Results and Lightweight Execution parameters are
configured and the test is deployed to the NE
Ignore Probe Results - specifies that the 5620 SAM ignores all test probe result
records (default = disabled)
Lightweight Execution - specifies that the 5620 SAM only displays results for tests
that fail, generate threshold crossing alarms, or time out (default = disabled). When
enabled, the Ignore Probe Results and Trap Generation parameters options are
enabled
Module 5 - 26
General configures general settings of the test and

5620 SAM managed objects when tests are to be run
Common OAM Test Parameters
Execute Details
Number of Test Probes
Probe Interval (s)
Probe Timeout (s)
Test Probe
Size (octets)
Time To Live
Forwarding Class
Forwarding Profile
Module 5 |
27
Test Parameters tab Execute Details

Number of Test Probes - specifies the number of OAM probes to send
Probe Interval (s) specifies how often, in seconds, to send a probe
Probe Timeout (s) specifies how soon, in seconds, a message request times out and is
aborted
Test Probe
Size (octets) specifies the OAM packet size, in octets, of the probe for a trace
diagnostic
Time To Live specifies the TTL value, in hops, that is added to the test packet to
ensure that the packet does not circulate in a routing loop past the configured time
Forwarding Class specifies the forwarding class for OAM packets (default = be)
Forwarding Profile - specifies whether the test packets are in or out of profile, as
compared to the forwarding class of the test packet
Module 5 - 27
Test Parameters configures details on how the test should

be run and determines test packet settings (different options
are available for different type of tests)
Test Failure Threshold

Probe Failure Threshold
Trap Generation
The options are
Test Completion (default)
Test Failure
Probe Failure
Path Change
Module 5 |
28
Result Configuration tab Test Failure Threshold - specifies the number of test failures that occur before a router sends
a trap about the test failure (default = 1)
Probe Failure Threshold specifies the number of times a probe can fail before the test fails.
The parameter has no effect if the value is higher than the Number of Test Probes parameter
value
Trap Generation - specifies the conditions under which a device sends a trap or raises an
alarm during an OAM test. Multiple options can be selected, but not all options are available
for every type of test. The options are
Test Completion (default)
Test Failure
Probe Failure
Path Change
Module 5 - 28
Result Configuration configures details regarding how

results should be reported
Type
Inbound Jitter (default) - Inbound Loss
Outbound Jitter
- Outbound Loss
Roundtrip Jitter
- Roundtrip Loss
- Inbound Latency
- Outbound Latency
- Roundtrip Latency
Generate Alarm on Rising Threshold

Clear Alarm on Failing Threshold
Update Test Result Status
Include Falling Threshold
NE Threshold tab -
Module 5 |
29
Type specifies which type of threshold crossing event generates an alarm. The options are:
Inbound Jitter (default)
- Inbound Loss
- Inbound Latency
Outbound Jitter
- Outbound Loss
- Outbound Latency
Roundtrip Jitter
- Roundtrip Loss
- Roundtrip Latency
Generate Alarm on Rising Threshold specifies whether to raise a threshold-crossing alarm when a
rising threshold is crossed (default = enabled). The values can be set under the NM Rising
Threshold tab
Clear Alarm on Failing Threshold - specifies whether to clear a threshold-crossing alarm when a
falling threshold is crossed and the threshold condition no longer exists (default = disabled). The
values can be set under the NM Falling Threshold tab
Update Test Result Status specifies whether the Threshold Crossing Event should change the test
result status (default = disabled)
Include Falling Threshold specifies whether to generate a threshold-crossing alarm for an OAM
test if the value falls below a specified level
Module 5 - 29
NM Threshold configures NM threshold-crossing alarms for

OAM tests that are non-NE-schedulable. An alarm is raised
when an NM threshold is crossed, either because the value
rose above or fell below the configured level
Comparing Test Results
Module 5 - 30
Search and Find the results in the STM list window

Select the desired test results and click the Compare button
The comparison form opens with each difference highlighted
Module 5 |
31
Module 5 - 31
Two results of the same test type can be compared
STM Results Comparison
Test Suites and Troubleshooting
Module 5 - 32
These tests are combined based on the Entity

Type parameter
Allows automatic generation of tests based on
a test policy
Can set a suite to be used for service
validation
Can be scheduled to provide continual
performance feedback
Best practice:
Create at least one test suite for each Entity Type for validation
and troubleshooting purposes
Module 5 |
33
(Entity Type: Tools -> Service Test Manager -> Create -> Test Suite -> General tab)
Module 5 - 33
The 5620 SAM STM provides the ability to group various OAM
tests into test suites for network troubleshooting
Test Suites
Execute before the tests in the other groups

Might typically include high-level diagnostics, such as a service
site ping or VPRN ping
Generated tests
Created by the 5620 SAM for use against a specific network
entity
When there is a change in the configuration of a network entity,
such as a service, one must regenerate the generated tests that
apply to that entity
Last-run tests
Executes after the tests in the other groups
Might typically include transport-layer diagnostics, such as an
LSP trace or a tunnel ping
Module 5 |
34
Module 5 - 34
First-run tests
Test Suites
Applies to only one test suite, and a test suite can have
only one associated test policy
Parameters can be configured to display test results only if a
test fails or generates a threshold crossing alarm
(Lightweight Tests)
Allows enabling of OAM test results to be stored in XML files
File can be stored on the server, written to the DB, or both
Must create an Accounting Policy with Type = NE Schedulable
Tests
Module 5 |
35
The Lightweight Execution parameter specifies that the 5620 SAM only displays results for tests that fail,
generate threshold crossing alarms, or time out. The options are:
Disabled (default)
Enabled
This can substantially reduce the amount of test data that the 5620 SAM needs to collect. When enabling,
make sure to select the Lightweight Execution AND Ignore Probe Results checkboxes.
When the parameter is enabled, the Ignore Probe Results (ignoreResults) parameter is enabled and the
Trap Generation (trapGenerationPolicy) parameter options are enabled.
Module 5 - 35
Contains a set of test definitions and pre- and postprocessing rules
Test Policy
Tools -> Statistics -> Accounting Policies
Tools -> Service Test Manager ->

Create -> Test Policy
Module 5 |
36
Module 5 - 36
Saving Results to an XML File
Module 5 |
37
Please see the 5620 SAM 10.0 R5 Planning Guide for more scalability information, such as Guidelines for
maximizing STM text execution.
Module 5 - 37
STM Scalability
Test suite weights are identified in the 5620 SAM GUIs Test
Suites List window
If too many tests are run concurrently and this limit is exceeded,
tests will be skipped
Module 5 |
38
Module 5 - 38
By default, 5620 SAM will only allow test suites with a

combined weight of 80,000 or less to run concurrently
STM Scalability
Auto-OAM feature allows the operator to assign an appropriate

STM test policy to an IP / LSP Path Monitor
The tests defined in the policy are then executed whenever the
path reroutes
Module 5 |
39
This is a great tool for automatic monitoring and test execution!

(Tools -> Service Test Manager -> Create -> Test Suite -> General tab).
Module 5 - 39
In 5650 CPAM:
Test Policy and 5650 CPAM
Ensure it is operationally up
Ensure roundtrip connectivity
Raise an alarm if rising roundtrip latency on the SDPs is greater
then 10 milliseconds
Ensure correct hops are taken by the LSPs
ID 59
Uni-directional Tunnels
ID 60
r5
r6
Module 5 |
40
Module 5 - 40
Validate newly created tunnels to
Validating Tunnels (SDPs) Using Test Suite
Symptoms:
Tunnels (SDP) are
operationally up
LSPs have been assigned
Module 5 |
41
(Manage -> Service Tunnels -> Tunnel).
Module 5 - 41
Validate Tunnel (1. Identify)
No fault indicator
None
Is the State Cause clear?

Yes
Module 5 |
42
(Manage -> Service Tunnels -> Tunnel -> General Tab -> State cause)
Module 5 - 42
Are there any open alarms?
Validate Tunnel (2. Investigation)
Use Tunnel Ping to check the roundtrip connectivity
Module 5 |
43
(Manage -> Service Tunnels -> Tunnel -> Tests -> Tunnel Ping)
To check for round-trip connectivity, the Return Tunnel ID must be set.
Module 5 - 43
Check roundtrip connectivity between routers r5 and r6
Can be checked by testing roundtrip latency from NM Threshold
Module 5 |
44
(Manage -> Service Tunnels -> Tunnel -> Tests -> Tunnel Ping)
Module 5 - 44
Check roundtrip latency is not greater then 2 milliseconds
Module 5 |
45
This policy will apply to all the SasThresholdExceeded alarms for every test where the SAS threshold is
being tested.
(Administration -> Alarm Settings -> Specific)
Module 5 - 45
Escalate the severity of SasThresholdExceeded Alarm from Major

to Critical if it is seen more than 3 times in 24 hours
Validate Tunnel (2. Investigation) (Optional)
Module 5 |
46
(Administration -> Alarm Settings -> Specific)
Module 5 - 46
De-escalate the severity of SasThresholdExceeded Alarm from

Critical back to Major if it is not seen more than 3 times in 24
hours
Validate Tunnel (2. Investigation) (Optional)
Result of Tunnel Ping with roundtrip latency
Roundtrip latency
threshold is crossed
Module 5 |
47
Module 5 - 47
Alarms are raised as a

result of roundtrip
latency crossing the
threshold:
Module 5 |
48
SasThresholdExceeded alarm might have Critical severity because of the escalation policy configured
earlier.
(Dynamic Alarm window)
Module 5 - 48
Can be checked by running LSP trace on the LSP associated with

this tunnel
Module 5 |
49
(Manage -> Service Tunnels -> Tunnel -> LSPs tab -> Dynamic LSP -> Tests -> LSP Trace)
Module 5 - 49
Verify LSP hops
Result of LSP trace
Module 5 |
50
Module 5 - 50
Alarm was raised when roundtrip latency threshold in the

Tunnel Ping test was higher then 2 milliseconds
Module 5 |
51
Module 5 - 51
There is no problem with the newly-created tunnels roundtrip connectivity or LSP hops
Validate Tunnel (3. Fix)
You can create a tunnel

(SDP) test suite to
test/validate all the
existing or newly created
tunnels:
First create a test suite and
select the Validation Test
Suite option
Module 5 |
52
Module 5 - 52
Validate Tunnel (4. Verify)
Assign all the tunnels to be tested in Tested Entities
Module 5 |
53
(Tools -> Service Test Manager -> Test Suite -> Test Policy)
Module 5 - 53
Assign a Test Policy; in this example the Test Policy defines a

Tunnel Ping
Generate tests for all assigned tested entities
Module 5 |
54
Module 5 - 54
Module 5 |
55
Assign the test suite to Tunnel (SDP) for validation
Module 5 - 55
1. Find the cause of the problem, but do not fix it
VPLS Service
r1
r3
Module 5 |
56
Module 5 - 56
A newly created VPLS service with mesh-SDP from r1 to r3

does not become active (operationally up)
Troubleshooting Services Using OAM (LAB 5.1)
2. Using MTU ping, find the maximum MTU size available for the
tunnel
Module 5 |
57
The lab equipment (sims) has these characteristics:

GRE SDP
Default MTU = 1536
MTU ping = 1536
Port MTU - overhead = 1578 42 = 1536
Where overhead = 14 (Ethernet) + 20 (IP header) + 4 (GRE header) + 4 (service label)
MPLS SDP
Default MTU without FRR = 1556
MTU ping = 1556
Port MTU overhead = 1578 22 = 1556
Where overhead = 14 (Ethernet) + 8 (two MPLS labels).
Module 5 - 57
The cause of the problem is that the size of the tunnel from
r1 to r3 has the MTU size too low at 1512
Troubleshooting Services Using OAM (LAB 5.1)
1. Create a scheduled CPE ping test suite for VPLS 31 that periodically
measures the Roundtrip Latency between each VPLS site and an end
device (in this case the CPE is the Traffic Generator). Set a Roundtrip
Latency Rising Threshold equal to 2 milliseconds.
Module 5 |
58
Module 5 - 58
Configure the 5620 SAM to monitor a VPLS service and raise

an alarm when the roundtrip latency between a VPLS site
and the connected CPE device rises above a specified
threshold.
Monitoring Services Using OAM (LAB 5.2)
Summary
Module 5 - 59
A test suite can perform end-to-end testing of a customer

service and the underlying network transport elements
Test suites are especially useful when multiple objects of the
same type require testing
Test suites can be scheduled to run on a regular basis to
provide continual network performance feedback
Module 5 |
60
Module 5 - 60
Provides the ability to group OAM diagnostic tests into test

suites for more comprehensive fault monitoring and
troubleshooting
Benefits of Using STM in 5620 SAM
Module 5 |
61
Module 5 - 61
Module 6 Statistics for Troubleshooting
Module 6 - 1

the 5620 SAM
View Performance and Accounting Statistics

Enable the Collection of Statistics
Configure different statistics policies
Explain the difference between Performance, Accounting and

5620 SAM Server Performance Statistics
Explain the difference between on-demand and scheduled
statistics
Use the Plotter for Real-Time and/or Historical Statistics
Use Statistics to troubleshoot common network issues
Module 6 |
Module 6 - 2
Module Objectives
This module describes how 5620 SAM Statistics
can be used to troubleshoot common network
issues.
Module 6 - 3
Statistics for Troubleshooting
SNMP
Transferring accounting files from NEs for Accounting

Statistics
FTP or SCP
Internal collection for 5620 SAM Server Performance Statistics

Internal on each server
Module 6 |
Module 6 - 4
Polling MIB counters for Performance Statistics
Collection
Storage criteria
File policy - for accounting stats on NEs
Statistics policy - for stats on 5620 SAM
MIB statistics policy used for managing Performance Statistics

NE MIB statistics policy
All objects on the NE that use the MIB entry
e.g. All L2 and L3 SAPs
Specific MIB statistics policy

Specified objects on the NE that use the MIB entry
e.g. only selected L2 or L3 SAPs
Server performance stats policy for 5620 SAM server stats

Module 6 |
Module 6 - 5
Accounting policy: defines record statistics type and

collection interval
Policy Types
Performance
Accounting
Server Performance
NE troubleshooting
Trend analysis &
5620 SAM server
troubleshooting
troubleshooting
Characteristic
Typical use
Source
NE MIBs
NE XML files and

MIBs
Internal 5620 SAM

server data
On-demand
Yes
Yes if MIB-based
Yes
Scheduled
Specific or general File and accounting
Collection policy
collection policy
policy
Real-Time Graph
Yes
Yes if MIB-based
Yes
Collection default
Off
Off
On, 15-min intervals
Module 6 |
Module 6 - 6
Statistics Type
Characteristics of Statistics Types
When viewing statistical records from an objects Properties form, a user can
quickly tell whether it is Performance or Accounting
Accounting (XML file, non

MIB-based) stats do not
have the option to collect
on-demand, so there are
no Collect or Collect All
buttons
Performance (NE MIB)

stats have the option to
collect on-demand
Module 6 |
Collect - do a one-time collection for the type of statistic selected in the drop down for this particular object
Collect All - do a one-time collection for ALL performance statistics on this particular object
Module 6 - 7
Performance vs Accounting Statistics
Traffic flows
Dropped packets
Forwarding Classes
--5620 SAM Server Node Resync issues
5620 SAM Server Memory usage
5620 SAM Server SNMP Traps missing
5620 SAM Server Statistics collection failure
---
Module 6 |
Module 6 - 8
Troubleshooting Using Statistics
Module 6 |
Module 6 - 9
Tools -> Statistics gives access to the configuration forms for all
policies. Statistics policies are also accessed via the Statistics
Record window and the Statistics Browser.
Policy Configuration
Different MIBs
Polling interval can be set to a minimum of 5 minutes
Applies to all objects on a router (Eg. All GigE ports)
Module 6 |
10
(Tools -> Statistics -> MIB policies -> NE MIB Statistics Policy)
Module 6 - 10
Per Product type and release (use filter)
NE MIB Statistics Policy
Different MIBs per Class (see Statistics Guide for more info)
Polling interval minimum: 5 minutes
Specific objects on a router (e.g. Only 1 out of 10 GigE ports)
Module 6 |
11
Statistics Guide has all MIBs linked to the different Classes.

One Class can link to different MIBs, each MIB can be activated separately.
(Tools -> Statistics -> MIB policies -> Specific MIB Statistics Policy)
Module 6 - 11
Per product type and release
Specific MIB Statistics Policy
This will put extra load on the router, so it is better to use a

Specific MIB Statistics Policy
Module 6 |
12
Assigned to an NE either by clicking Assign Sites, shown in the image above, or through the discovery rule in the
5620 SAM Discovery Manager.
(Tools -> Statistics -> MIB policies -> NE MIB Statistics Policy)
Module 6 - 12
Each port will have statistics collected
Example of an NE MIB Statistics Policy (1/2)
Module 6 |
13
Module 6 - 13
Statistics will show up under the Statistics tab of each physical

port.
Example of an NE MIB Statistics Policy (2/2)
Direct link from Statistics Policy to monitored object (in this

case a port)
Module 6 |
14
Statistics will only be collected from the selected port
(Tools -> Statistics -> MIB policies -> Specific MIB Statistics Policy)
Module 6 - 14
Example of a Specific MIB Statistics Policy
Tools -> Statistics Manager

Per Object Type :
View the current collected data

View the actual Statistics Records (Historical)
View and configure the Statistics Policy
Module 6 |
15
Module 6 - 15
Statistics Manager
Can use the link in the Tools menu and paste the monitored object
from the clipboard
2
1
3
Module 6 |
16
(Object Properties form -> Statistics tab)
Module 6 - 16
In the Statistics tab of an object, youll find a link to the Plotter
Accessing the Plotter
Module 6 |
17
Module 6 - 17
Launch the plotter directly from the navigation tree
Accessing the Plotter (continued)
The plotter interval can be selected
If you already have statistics collected for the object, you can
get a Historical Plot
Module 6 |
18
The user can save the plotted data to a file in either tabular (.CSV/HTML file) or graphical format (.JPG/PNG file).
To save the tabular data, right-click on the table header and select Save to File option.
To save the current view of the graph, click on the Save Current View button on the toolbar.
Module 6 - 18
Update the Group and Counter to meet your requirements
Using the Plotter
Easy access of the same plot at a later time
Once a plotter configuration is complete, click the Save

Profile(s) button
Module 6 |
19
Module 6 - 19
Allows users to save a statistics plotter configuration
Statistics Plotter Profiles
Module 6 |
20
Module 6 - 20
After a profile has been saved, it can be loaded from the

Properties form of objects matching the profile type
Launching Statistics Plotter Profiles
Either System or User Defined type
Module 6 |
21
System type profiles are built in and cannot be deleted. They can, however, be disabled. Disabling them will
remove the ability to launch them from an objects properties form. To disable, simply deselect the Display in
Menus checkbox.
Module 6 - 21
Statistics plotter profiles are managed through the Tools

Statistics Statistics Plotter Profiles menu option
Statistics Plotter Profiles Management
View the statistics or access the plotter from the objects

Statistics tab, as this will automatically paste in the
monitored object
Viewing one specific type of statistics on multiple objects:
View the statistics or access the plotter from Tools ->
Statistics -> Statistics Manager.
Module 6 |
22
Viewing one specific type of statistics on one object:
(Tools -> Statistics -> Statistics Browser)
Module 6 - 22
Best Practices for Viewing Statistics and Plotter
Introduced in 5620 SAM 8.0 R5
1. Determines, in bytes, the total amount of data that can be

sent over a Physical Port or channel in a specific amount of
time
2. Determines the total amount of data that was sent during that
same time period
3. Uses the values from steps 1 and 2 to calculate the utilization
as a percentage of the total possible amount of data on the
port or channel
Requires Interface Stats to be enabled on the port
Uses Received/Transmitted Octets Periodic counter

Uses the configured periodic collection interval (minimum of 5
minutes)
Calculates the Utilization Percentage at each collection
interval
Module 6 |
23
Link Utilization Statistics can be configured on the following objects:

DS1/E1 Channel
DS3/E3 Channel
Physical Port
Sts1 SONET Channel
Sts12 SONET Channel
Sts192 SONET Channel
Sts3 SONET Channel
Sts48 SONET Channel
The Link Utilization Statistics depend on TCA, which is covered in the next few slides.
The Link Utilization values appear in an alarm that is generated by the TCA mechanism.
Module 6 - 23
Link Utilization Statistics
Can configure a Rising and/or Falling threshold value
At each interval, if the threshold value is passed, 5620 SAM

will generate a Threshold Crossing alarm
Alarm info contains the values (in this case percentage) that
caused crossing of the threshold
To take advantage of the Link Utilization Statistics

Thresholds, the operator must create a TCA (Threshold
Crossing Alarm) Policy
1. From the 5620 SAM main menu, select Tools TCA
Policies
Module 6 |
24
Module 6 - 24
TCA Policy
Module 6 |
25
(Tools -> TCA Policies)
Module 6 - 25
2. On the TCA Policies form, click the Create button

3. Enter a Displayed Name, select the Monitored Object Type
and set the Admin State
4. Click the Apply button
TCA Policy
a. Expand the Utilization section

b. Under Rules, click the Create button
c. Set the Displayed Name, Alarm Severity, Threshold (%) and
Threshold Direction
d. Click the OK button
Module 6 |
26
5. Create Threshold Crossing Rule(s)
Module 6 - 26
TCA Policy
a.
b.
c.
d.
Click the Monitored Objects tab

Click the Add button
Enter a filter and search for the desired object(s)
Highlight the object(s) in the list and click the OK button
Module 6 |
27
6. Add the desired objects to be monitored
A port can only be assigned to one TCA policy at a time.
Module 6 - 27
TCA Policy
Note: As of SAM Release 9.0 R5, a TCA policy can be created

for all Performance Statistics types.
Module 6 |
28
Module 6 - 28
7. On the TCA Policy form, click OK or Apply to activate Link

Utilization monitoring on the monitored objects
TCA Policy
An operator can view which TCA policies are assigned to a

physical object by selecting the TCA tab in the objects
Properties form
Within this tab, click the Assign button on the right to assign
this physical object to a previously configured TCA Policy
Module 6 |
29
Module 6 - 29
TCA Tab
On any Interface Stats collection interval, an alarm will be

raised if the link utilization crosses the configured threshold
value.
Module 6 |
30
Module 6 - 30
Link Utilization Threshold Crossing Alarm
As of SAM Release 10.0 R5, users are able to plot port utilization
directly in the statistics plotter
Statistics group must be Interface Additional Stats
Module 6 |
31
Module 6 - 31
Plotting Link Utilization
Use Physical Port Interface Stats (Received and Transmitted

Unicast Pkts Periodic) to find which way the traffic flows
through the network
Statistics are already enabled
A port that is carrying traffic will show scheduled 5-minute

periodic unicast pkts (approx. 41,000)
Each group has to find out which ports are involved in the
traffic flow on their assigned router
Group 1 router r1
Group 2 router r2
Group 3 router r3
Group 4 router r4
Module 6 |
32
Module 6 - 32
Traffic is generated from r6 to r5
Statistics - Exercise 1
Storage Location of the Statistics (cf2: in our lab setup)
Accounting Policy :
Link File Policy to Accounting Policy
Select specific Accounting statistics type for troubleshooting
purposes
The Plotter can be used, but only for an Historical Plot.
Module 6 |
33
Module 6 - 33
File Policy :
Accounting Statistics
Below are 2 recommendations:

1. Complete Service Ingress/Egress Packets Octets
XML- based statistic which must be enabled through an Accounting policy
Cannot be monitored on-demand (can only view scheduled collection

interval)
2. SAP Ingress/Egress Queue Accounting Stats
MIB-based statistics
Can be monitored on-demand (real-time data using the statistics plotter)
Module 6 |
34
(Manage -> Service -> Services -> VPLS # -> Layer 2 Access Interface -> Statistics)
Module 6 - 34
There are multiple statistics types that can be used to

view traffic on a customer SAP
Viewing SAP Traffic
No traffic because
Octets are constant
Traffic passing because

Octets are rising
No dropped packets
because value is constant
Historical
plot only
Module 6 |
35
(SAP properties -> Statistic tab)

(SAP properties -> Statistics tab -> Select Object type... -> Plotter).
Module 6 - 35
Configured 5
minute interval
Complete Service Ingress/Egress Packet Octets
Periodic values
enable easier
traffic monitoring
(E.g. No traffic will
show a value of 0)
Real-time
Plotting
Module 6 |
36
Note: This is one of the few accounting stats that is MIB-based and therefore can be collected on-demand.
Module 6 - 36
On-Demand Collection
SAP Ingress/Egress Queue Accounting Stats
Use 5620 SAM Accounting Statistics (Complete Service

Ingress and Egress packets) to find which two SAPs (1 per
site) are carrying the traffic AND which queue is used.
Statistics are already enabled
For this exercise, use the Out of Profile Pkts Forwarded

counter
Module 6 |
37
Traffic is generated from r6 to r5 through VPLS Service ID 31
Module 6 - 37
Statistics - Exercise 2
Alarm Rate
Node Resync
Server Memory
SNMP Trap
Module 6 |
38
(Tools -> Statistics -> Server Performance Statistics)
Module 6 - 38
Each statistic is used to troubleshoot different issues:
Server Performance Statistics
Using 5620 SAM to view Statistics Records

Using 5620 SAM to configure Statistics Collection
Using multiple 5620 SAM Statistics to troubleshoot network
issues
Module 6 |
39
Module 6 - 39
In this module, the following topics were covered:
Module Summary
Module 6 |
40
Module 6 - 40
This page intentionally left blank
Module 6 - 41
Module 7 Troubleshooting IGPs
Module 7 - 1

the 5620 SAM
View and configure IGP parameters

View the IGP configuration using the Routing Navigation tree
List the steps taken to troubleshoot IGP issues
Troubleshoot common IGP issues
Module 7 |2
Module 7 - 2
Module Objectives
This module describes how 5620 SAM can be
used to troubleshoot common IGP issues.
Module 7 - 3
Troubleshooting IGPs
OSPF Properties form

Shutdown/Turn up
View neighbors
View interfaces
OSPF Interface Properties form

Shutdown/Turn up
Authentication
View neighbors
OSPF interface/site search

Manage -> Networking -> Routing Instances
Module 7 |4
Configuration planning is essential to organizing OSPF areas, interfaces and virtual links. OSPF provides defaults
for basic protocol operability. OSPF configuration requires, at a minimum, that a single OSPF backbone area
containing the area border routers is created. For larger networks, several areas can be created into which the
routers are distributed for protocol management. In dealing with smaller networks, all routers can be placed in the
OSPF backbone area.
The parameters that are required for OSPF deployment are:
A Layer 3 interface is a logical IP object that is defined on a physical port, such as an Ethernet port. A Layer 3
interface:
- has an IP address and subnet mask
- is configured with QoS policy settings
- associates its IP address with a physical port or channel
- has its physical port or channel cabled to another device
- has enabled routing protocols
The physical connection of one device to another device is through its port or channel. However, the Layer 3
interface determines its IP connectivity. The Layer 3 interface passes both routing information, using a routing
protocol such as OSPF, and IP traffic.
Router ID Devices that run OSPF must be configured with a unique router ID. The system interface is typically
used as the router ID to preserve connectivity when an interface fails or is removed. A system interface must have
an IP address with a 32-bit subnet mask. The system interface is used as the device identifier by higher-level
protocols such as OSPF and BGP.
The router ID is used by the OSPF and BGP routing protocols in the routing table manager. When a new router ID
is configured, protocols are not automatically restarted with the new router ID. The protocol must be shut down
and restarted to initialize the new router ID.
An Area At least one OSPF area must be created. An interface must be assigned to each OSPF area. The
types of
areas include
a the
backbone
area, stub All
area
and
NSSA.
Network
andOSPF
Service Troubleshooting
with
5620 SAM v1.4
rights
reserved
2013 Alcatel-Lucent
Module 7 - 4
(M
N t
ki
ti
ti
I t f
ti
IP
OSPF Configuration
IS-IS Properties form

Shutdown/Turn up
View neighbors
View interfaces
IS-IS Interface Properties form

Shutdown/Turn up
Authentication
View neighbors
IS-IS interface/site search

Manage -> Networking -> Routing Instances
Module 7 |5
IS-IS is a link-state interior gateway protocol that uses the Shortest Path First algorithm to determine a route.
Routing decisions are made using the link-state information. IS-IS entities include:
- networks: autonomous system routing domains
- intermediate systems: routers such as the 7750 SR and 7710 SR
- end systems: network devices that send and receive Protocol Data Units (PDUs)
End system and intermediate system protocols allow devices and nodes to identify each other. The IS-IS protocol
periodically sends link-state updates through the network, so each device can maintain current network topology
information.
Large networks, or autonomous systems, are supported by the IS-IS using a two-level hierarchy. This divides a
large area into smaller, more manageable areas. The first level (level 1) of routing is performed within an area.
The second level (level 2) of routing is performed between areas.
Level 2 areas are also called backbones, similar to an OSPF backbone area. All traffic traversing different areas
must traverse the backbone. A device can be configured as level 1, level 2, or both level 1 and 2. Level 1 devices
are only aware of their own areas topology, and must forward traffic to a level 1/2 device to forward the data to
another area.
Two devices are in the same level 1 area when they have level 1 adjacency. Level 1 adjacency occurs when the
area IDs are common and there is a level 1 connection between the devices. Level 2 adjacency occurs when it
has at least one level 1 or 2, or one level 2 interface configured. The 5620 The 5620 SAM supports the
configuration of IPv6 addresses for IS-IS adjacencies.
(Manage -> Networking -> Routing Instances -> Router Terminating Interface -> Router Terminating Non-IP
Interface -> ISIS Interface)
Module 7 - 5
IS-IS Configuration
Link/Interface status
MTU mismatch
Mismatched interface type
Mismatched subnet mask or IP address
Interface not configured for OSPF/IS-IS
Neighbor is configured for authentication
OSPF timer parameters
Area ID does not match neighbor
IS-IS interface level capability
Filters (ACL, CPM, etc.)
NOTE: This is also an excellent checklist to follow when troubleshooting IGP
issues
Module 7 |6
Module 7 - 6
Troubleshooting Common IGP Issues
What route is the IGP traffic taking?

What is the cause of this problem?
r2
r4
r1
r3
Module 7 |7
Module 7 - 7
IGP traffic cannot pass from r2 to r4 directly, thus all traffic is

taking a suboptimal route.
Failure Scenario OSPF
Symptoms
IGP traffic is not using the directly connected link

OSPF adjacency between r2 and r4 is down
Reproduce
Using the STM, execute an ICMP trace test to confirm the

issue
View the results and record the probe hops
Module 7 |8
Module 7 - 8
Failure Scenario OSPF (1. Identify)
Reproduce (continued)
Can also run a CLI script from the routers Properties form
Under the Scripts tab, select the desired script and click the
Execute button
Module 7 |9
Note: Only scripts that have router R2 configured as a Target will show up in the list above. Users can also
access the script properties form and the STM list window from this tab.
Module 7 - 9
If the script is successful, a green checkbox will appear in the

Status column and the results will be displayed in the window
below.
Module 7 |10
Module 7 - 10
Can use the script menu Shortcut or Action button to view and
execute scripts much more quickly.
Module 7 |11
If a script is bound to an object, it will be bound to all other objects of the same type, but not to objects of a
different type.
The Manage Scripts option allows adding/removal of scripts from an object type. Use this to add multiple scripts
at once or to remove scripts from the objects scripts menu option.
Module 7 - 11
If the Dynamic Alarm window is quiet, you may be able to

quickly view any alarms from there.
Quick filter allows faster searching
Module 7 |12
To make searching the Dynamic Alarm window easier, filter for Domain containing OSPF.
Module 7 - 12
Failure Scenario OSPF (2. Investigation)
If the Dynamic Alarm window seems busy, navigate to the object(s) in

question using the Navigation tree.
There is an alarm on the interface and neighbor. The interface is a
lower-level object, so start the investigation there
Right-click on the object and select Properties
Click the Faults tab to view any alarms
Module 7 |13
Module 7 - 13
Explore any open alarms/Acknowledge alarms
Warning - InterfaceDbDescriptConfig
2 x Major - NeighborDown
View the alarm information for possible clues to the cause

(based on best practice, start with Probable Cause,
Additional Text, Description and Remedial Action)
Click View Correlating Alarm if it is active to navigate to the

parent alarm. Repeat this step until this button is no longer
active.
Module 7 |14
Module 7 - 14
Navigate to the object in question (OSPF interface)
The Probable Cause on the InterfaceDbDescriptConfig alarm

states there is an mtuMismatch
Click the View Alarmed Object button
Check for affecting, aggregated and related objects alarms
Located under the Faults tab

In the Aggregated Alarms tab there is a NeighborDown alarm
The presence of a NeighborDown alarm shows that the alarms
may be related, and that fixing the mtuMismatch could possibly
bring the neighbor back up
Module 7 |15
Module 7 - 15
Navigate to the network interface
On the General tab, click Properties, located next to the

interface name
From the interface form, navigate to the port
On the Port tab, click the Properties button
Module 7 |16
Note: The ports fault tab Alarms on Related Objects shows two alarms:
Routing Management: OSPF Interface InterfaceDbDescriptConfig
Network - Discovered Physical Link PhysicalLinkPortsMisconfigured
(OSPF Interface -> Interface Properties -> Port)
Module 7 - 16
On the General tab of the port, change MTU to the correct

value (1578)
If you are unsure what it should be, you can check the other
port of the physical link, the configuration of another similar
port or a network design doc/diagram
Record the change in the Audit Trail
Module 7 |17
Module 7 - 17
Failure Scenario OSPF (3. Fix)
Make sure any objects that were operationally down are now UP.
All self-clearing alarms should be implicitly cleared
Issue the same ICMP trace test as in step #1 to verify the fix
Best Practice:
Manually clear non-implicitly cleared alarms, but only once the fix is
verified.
Module 7 |18
Module 7 - 18
Failure Scenario OSPF (4. Verify)
5620 SAM Tool highlights any Physical Port MTU mismatch

throughout the entire network
Right-click in the blue area of the Physical Topology and select

Use if there is an MTU mismatch alarm
Physical links must exist
Module 7 |19
Module 7 - 19
Mode
Encap Types
Default
10/100, GigE, or 10GigE
Access
Null
1514
Access
dot1q
1518
Access
mpls
1518
Access
q-in-q
1522
SONET/SDH or TDM
Access
range
1502-4470
ATM
Access
atm
1508
10/100 or 100FX Ethernet
Network
null
1514
10/100 or 100FX Ethernet
Network
dot1q
1518
1GE or 10GE
Network
null
9212
1GE or 10GE
Network
dot1q
9216
SONET/SDH or TDM
Network
range
9208
Module 7 |20
There are many different MTU defaults depending on the port type, encapsulation and mode applied to the port.
Module 7 - 20
Port Type
MTU Defaults
What route is the IGP traffic taking?

What is the cause of the problem?
r2
r4
r1
r3
Module 7 |21
Module 7 - 21
IGP traffic cannot pass from r2 to r4 directly, thus all traffic is

Failure Scenario IS-IS
Symptoms
IGP traffic is not using the directly connected link

IS-IS adjacency between r2 and r4 is down
Reproduce
Using the STM, execute an ICMP trace test to confirm the

issue
View the results and record the probe hops
Module 7 |22
Module 7 - 22
Failure Scenario IS-IS (1. Identify)
If the Dynamic Alarm window is quiet, you may be able to

quickly view any alarms from there
Module 7 |23
Module 7 - 23
Failure Scenario IS-IS (2. Investigate)
Explore any open alarms
2 x Minor - IsisAdjacencyDown
View the alarm information for possible clues to the cause
Gather information from the alarm fields. More important ones

include the following;
Probable Cause
Additional Text (showing 3 attribute values)
Click the Details tab to view the Description and Remedial

Action
Module 7 |24
Module 7 - 24
The Additional Text alarm feature that was mentioned in

Module 2 can help here:
An Additional Text alarm policy for an IS-IS interface was

previously created
It contains 3 major attributes:
encapType
interfaceType
levelCapability
Because of this tool, we are able to spot a misconfiguration

on interface r2-r4
Module 7 |25
Module 7 - 25
r4-r2
Module 7 |26
The Additional Text field shows that the level capability is misconfigured.
Module 7 - 26
r2-r4
On the General tab of the IS-IS interface r2-r4, change the

Level Capability to Level 2.
Module 7 |27
(Alarm -> View Alarmed Object -> ISIS Interface -> General Tab -> Level Capability)
Module 7 - 27
Failure Scenario IS-IS (3. Fix)
Make sure any objects that were operationally down are now
UP
All self-clearing alarms should be implicitly cleared
Issue the same ICMP Trace test as in step #1
Module 7 |28
Module 7 - 28
Failure Scenario IS-IS (4. Verify)
OSPF traffic cannot pass from r2 to r4 directly, thus all traffic is

taking a suboptimal route
Find the cause, but do not fix it
r2
r4
r1
r3
Module 7 |29
Module 7 - 29
Troubleshooting Common IGP Issues 1 (LAB 7.1)
OSPF traffic cannot pass from r2 to r4 directly, thus all traffic is

Find the cause, but do not fix it
r2
r4
r1
r3
Module 7 |30
Module 7 - 30
Troubleshooting Common IGP Issues 2 (LAB 7.2)
Using 5620 SAM to view and configure IGP parameters

Listing the more common IGP problems
Using multiple 5620 SAM tools to troubleshoot IGP issues
Binding scripts to network objects
Using the MTU mismatch tool
Module 7 |31
Module 7 - 31
Module Summary
Module 7 - 32
Module 8 Troubleshooting MPLS

the 5620 SAM
View and configure MPLS parameters and objects

View MPLS configuration using the Routing Navigation tree
List the steps to troubleshoot MPLS issues
Troubleshoot common MPLS issues
Module 8 |
Module 8 - 2

to:
Module Objectives
This module describes how 5620 SAM can be

used to troubleshoot common MPLS issues.
Troubleshooting MPLS
MPLS, RSVP and LDP Operationally Up on NE and interfaces

LSP - Operationally Up
MPLS path - Operationally Up
LSP-Path Binding - Operationally Up
LSP has a destination address assigned to it
LSP has primary/secondary path assigned to it
Module 8 |
MPLS (Multi-Protocol Label Switching) encompasses a growing set of protocols defined by the IETF. MPLS
combines the performance capabilities of Layer 2 switching with the scalability of Layer 3 routing. It
enables service providers to provide differentiated services utilizing existing infrastructure.
In conventional Layer 3 forwarding, as a packet traverses the network, each router extracts all the
information from the packet header. The router then analyses this information and extracts what is
relevant to forwarding the packet. This information is then compared to the routing table to determine
the packets next hop.
In MPLS, the analysis of the packet header is done just once at the ingress to the network Label Edge
Router (LER). The packet header is then assigned a label based on a manually configured value (static
route) or a dynamically signaled value.
LDP (Label Distribution Protocol) is used to distribute labels in non-traffic-engineered MPLS applications.
Routers can establish LSPs across a network by mapping network-layer routing information directly to the
data link layer switched paths.
RSVP (Resource Reservation Protocol) is a network control protocol that defines procedures for signaling
QoS requirements and reserving the necessary resources for a router. RSVP is not a routing protocol. It
operates with unicast and multicast routing protocols, which determine where packets are forwarded.
RSVP-TE is a set of traffic engineering extensions to RSVP intended for use by label switching routers (as
well as hosts) to establish and maintain LSP-tunnels and to reserve network resources for such LSPtunnels. The RSVP-TE extensions are defined in RFC 3209.
The RSVP-TE specification essentially allows an RSVP session to consist of an arbitrary aggregation of
traffic (based on local policies) between the originating node of an LSP-tunnel and the egress node of the
tunnel. The session is defined as the set of packets that are assigned the same MPLS label value at the
originating node of an LSP-tunnel. The assignment of labels to packets can be based on various criteria,
and may even encompass all packets (or subsets thereof) between the endpoints of the LSP-tunnel.
Module 8 - 4
In troubleshooting any MPLS issue, first verify the following:
Common MPLS configuration
There are basically two types of errors that could happen

when creating an LSP using RSVP:
1. Routing issues: a route to a destination is not available
2. Signaling issues: even with a valid route to a destination, the
LSP tunnel still is not operationally Up
Module 8 |
Module 8 - 5
Two Basic Types of Errors
Shutdown/Turn up
View all interfaces, In Segments, Cross Connects, Out Segments,
Static Label Maps on the router
Specific MPLS parameters such as FRR, LSP resignal
View default values
MPLS Interface Properties form
Shutdown/Turn up
Specific MPLS interface parameters such as Admin Group, SRLG
Groups, Port-id
In Segments, Cross Connects, Out Segments, Static Label Maps on
the interface
Module 8 |
Module 8 - 6
MPLS Properties form
MPLS Configuration Basics
Select Routing in the Navigation tree

Manage MPLS LSPs
Manage MPLS MPLS Objects
Manage MPLS MPLS Paths
Manage Networking Routing Instances
Module 8 |
Module 8 - 7
MPLS Information
Shutdown/Turn up
View all interfaces, interface properties, targeted peers,
targeted peer properties, sessions
Specific LDP parameters such as Import and Export Policies,
Distribution Mode, Retention Mode, Control Mode
View default values
LDP Interface Properties form

Shutdown/Turn up
Specific LDP interface parameters such as Keep-Alive Timeout,
Hello Timeout, Address Type
Statistics, Faults
Module 8 |
Module 8 - 8
LDP Properties form
LDP Configuration Basics
Check that IP reachability to the destination exists

ICMP ping and/or ICMP trace
Traffic engineering enabled on the IGP (optional)

All LSPs do not have to use CSPF / traffic engineering. It is possible to
have an LSP with a strict or loose hop using a regular IGP without TE
extensions.
MPLS enabled on the router

Operationally Up?
MPLS enabled on the network interfaces

Operationally Up?
Are there associated LSP-Path bindings?

Operationally Up?
Error Codes?
Module 8 |
Items listed in this slide are in no particular order.
Module 8 - 9
Verify the following:
Troubleshooting LSPs Checklist
Interface not configured for MPLS

LSP not signaled
Routing issues
Module 8 |
10
This is a list of the more common MPLS problems.
Module 8 - 10
Troubleshooting Common MPLS Issues
No CSPF or FRR
r2
r4
Loose
Strict
r1
r3
Module 8 |
11
Module 8 - 11
A newly-created LSP between r2 and r3 does not become

active (operationally up)
Troubleshooting MPLS Issues - Failure Scenario #1
Symptoms
Verify Issue
Module 8 |
12
(Manage -> MPLS -> Dynamic LPSs)
Module 8 - 12
Troubleshooting MPLS Issues (1. Identify)
Yes; in this case, there is one Object Alarm and one

Aggregated Alarm related to the issue
Module 8 |
13
Module 8 - 13
Troubleshooting MPLS Issues - (2. Investigate)
Explore the Object Alarm (correlating) first
Critical - LspDown
View the Alarm Information for possible clues as to the

cause
If no clues are present, check the status of the LSP Bindings
Module 8 |
14
(Alarm properties)
Module 8 - 14
Troubleshooting MPLS Issues (2. Investigate)
The two most informative windows for troubleshooting

an LSP is the LSP Properties form and the LSP-Path
Bindings window
Best Practice:
When an LSP is operationally down, view the LSP-Path Bindings
Failure Code
Module 8 |
15
(Properties of Dynamic LSP -> LSP-Path Bindings tab)
Module 8 - 15
View the LSP-Path Bindings Status and Failure Code
Best Practice:
Always resync the LSP-path bindings to view the most recent
Failure Code
For a list of common error codes along with possible

causes and suggested actions to resolve the problems,
please check the Lab Guide Appendix A
Module 8 |
16
Module 8 - 16
It may be necessary to resync the LSP-path binding to

update the Failure code because the node does not always
send a trap the moment the code changes (waits for retry
period)
Note:
In this case, the error

message Invalid LSP label
appears
This specific LSP event could be caused by different

factors. First verify that MPLS is enabled on the NEs and
interfaces used by the LSPs
Module 8 |
17
OAM LSP trace test result is being viewed
Module 8 - 17
Perform an OAM LSP trace

test
This can be done in the Routing Navigation tree or the

Manage MPLS MPLS Objects MPLS Interface menus
Notice that Interface r2-r4 is missing
When used with filters, is very useful

in larger networks.
Module 8 |
18
(Manage -> MPLS -> MPLS Objects -> MPLS Interface)
Module 8 - 18
On router r2, enable MPLS on the Interface r2-r4 by

creating the interface in the MPLS menu context
Module 8 |
19
Use the Routing navigation tree to configure the MPLS interface.
Module 8 - 19
Troubleshooting MPLS Issues (3. Fix)
The LSP tries to resignal within 30 seconds by default
The LSP is now operationally up, and the Failure Code is

No Error
The LSP Object Alarm alarm has been implicitly cleared
Module 8 |
20
Module 8 - 20
Troubleshooting MPLS Issues (4. Verify)
CSPF is enabled, FRR is disabled

r2
r4
Loose
Strict
r1
r3
Module 8 |
21
Module 8 - 21
A newly created LSP between r2 and r3 is not taking the

shortest path. What is the current path? What caused it to
reroute? Fix the issue so the LSP will take the shortest path.
Symptoms
Verify Issue
Module 8 |
22
(Properties of Dynamic LSP)

(Properties of Dynamic LSP -> Properties of LSP-Path Binding -> Provisioned Path tab)
(Properties of Dynamic LSP -> Properties of LSP-Path Binding -> Actual Path tab)
Module 8 - 22
Both the LSP and LSP-Path Binding are showing no

alarms
Are there any historical alarms?

LspDown alarm raised 10:48:48 and cleared 10:50:18
(Rerouted)
By default, alarms are logged to historical once they
are cleared.
Module 8 |
23
(Tools -> Historical Alarms)
Default settings of 5620 SAM:

-Delete an alarm when it is cleared
-Log to history when it is deleted
Based on the above information, we know that the Time Logged was the time the LspDown alarm
cleared.
Module 8 - 23
Search both the Alarm History and Dynamic Alarm

window for ALL alarms with a time =< 10:48:48
In the Dynamic Alarm window, there are many critical

alarms around the same time the LSP rerouted
One of these alarms is an interfaceDown alarm on RSVP
Interface r2-r4, which should be the preferred first
hop of the LSP
Module 8 |
24
(Dynamic Alarm window)
Module 8 - 24
What caused the LSP to reroute?
Module 8 |
The description states there may be an

underlyingResourceFailed
25
(InterfaceDown Alarm -> Details)
Module 8 - 25
r2-r4 is Shutdown
Module 8 |
26
Module 8 - 26
Using the Navigation tree, check the MPLS interface
Turn Up MPLS on the

interface
Re-signal the
LSP-Path Binding
if desired
Alternatively,
wait until the resignal timer
expires
Module 8 |
27
Use the Routing navigation tree to turn up the interface.

The Re-signal Do Action is on: (Properties of Dynamic LSP -> Properties of LSP-Path Binding -> General
tab)
By default LSP re-signaling is disabled on the node. To enable this, go to the Routing Instance -> MPLS ->
General Tab and check the LSP Resignal checkbox. Once enabled, the router will re-signal LSPs at the
configured Resignal Timer interval.
Module 8 - 27
Because the first hop is loose, the LSP re-signals and reverts to
the original actual path
Module 8 |
28
The LSP rerouted because the interface went down. The LSP was able to reroute because its first hop is
loose. The rerouting was triggered by the retry time (30 seconds).
Once the interface was repaired, a re-signaling of the LSP allowed it to be optimized and thus revert back
to the original path.
Module 8 - 28
CSPF enabled
r2
r4
Loose
Strict
r1
r3
Module 8 |
29
Module 8 - 29
Another newly created LSP between r2 and r3 does not

become active (operationally up)
Symptoms
Verify Issue
Module 8 |
30
The LSP is administratively up, but operationally down.
Module 8 - 30
Yes; in this case, there is one alarm related to the issue
Module 8 |
31
Module 8 - 31
This code could be caused

by different factors
Best practice is to check the following:

1. IP reachability to the destination exists
2. Traffic engineering in OSPF is enabled
3. Verify all strict/loose hops are valid
4. Check if the requested bandwidth is too big
5. Check if the link color is assigned correctly
Module 8 |
32
Appendix A in the Lab Guide has these steps.
Module 8 - 32
MPLS is already enabled on NEs and Interfaces
Perform OAM ICMP trace test to determine IP reachability:
Based on the provisioned path (two strict hops), we will need

to perform two ICMP trace tests to confirm IP reachability
and that the direct hops are being used
r2-r4
r4-r3
The destination is reachable and both direct

hops are being used
Module 8 |
33
(Properties of Dynamic LSP -> Properties of LSP-Path Binding -> Provisioned Path tab)
(OAM ICMP test results)
Module 8 - 33
Is Traffic Engineering enabled in the OSPF configuration?
For larger networks, use the Manage Networking

Routing Instances window
From the top left hand drop down, select Router Site
Protocol Site OSPF Site
Set filter to Traffic Engineering Support = false
Check to see if any routers of the path are in the list
Notice that Traffic Engineering is disabled on r4
Module 8 |
34
(Manage -> Networking -> Routing Instances, Router Site -> Protocol Site -> OSPF Site).
Module 8 - 34
Enable Traffic Engineering on the NE (router r4)
Can use the form search to find where this is Enabled/Disabled.
Change to True
Module 8 |
35
To open the site properties, just double-click on the row found in the previous slide.
Alternatively, disabling CSPF will also allow the LSP to come up since TE would not be needed if CSPF
were disabled.
Module 8 - 35
The LSP is now operationally up, the Failure Code is No Error
All self-clearing alarms are implicitly cleared
Module 8 |
36
Module 8 - 36
LSP Name is r2-r4-r3-r1

Find the cause, but DO NOT fix it
r2
r4
Loose
Strict
r1
r3
Module 8 |
37
Module 8 - 37
A newly created LSP between r2 and r1 does not become

active (operationally up). CSPF and FRR are enabled
Troubleshooting MPLS Issues 1 (LAB 8.1)
Find the cause and fix the LSP

r2
r4
Loose
Strict
r5
r6
r1
r3
Module 8 |
38
Module 8 - 38
A newly created LSP between r5 and r6 does not become

active (operationally up).
Initially the path was from r2-r4-r3

Fast-Reroute(FRR) is enabled
Explain what happened and the investigation steps taken

r4
r2
Loose
Strict
r3
r1
Module 8 |
39
FRR is enabled on an LSP via Dynamic LSP -> Properties tab.
Module 8 - 39
A failure on r2 caused an LSP between r2 and r3 to reroute
Troubleshooting MPLS Issues with FRR - Failure Scenario #4
Symptoms
The LSP is still UP.
Module 8 |
40
(Properties of Dynamic LSP)
Module 8 - 40
Troubleshooting MPLS Issues with FRR (1. Identify)
LspPathReroutedToByPassTunnel means FRR established path to

destination
Session Down
LspDown
InterfaceDown
Module 8 |
41
Module 8 - 41
This ALU-IPD-SRC Alcatel-Lucent_Network_and_Service_Troubleshooting_with_the_5620_SAM Guide is for exclusive use of Kazi_Zial_Hoque - WI
Troubleshooting MPLS Issues with FRR (2. Investigate)
Status of the LSP binding associated to it
Module 8 |
42
Module 8 - 42
RSVP Session
RSVP sessions show that the node detour is in use (using tunnel ID
2061):
RSVP Session properties (tunnel 2052 has next hop of 10.2.3.3):
Module 8 |
43
(Properties of Dynamic LSP -> RSVP Sessions tab)
(Properties of Dynamic LSP -> RSVP Session properties)
Module 8 - 43
Investigate the InterfaceDown alarm which was seen during

this failure:
Module 8 |
44
Module 8 - 44
Investigate MPLS and RSVP

states on r2 on interface r2r4
MPLS interface r2-r4 is in

shutdown state
Module 8 |
45
Module 8 - 45
Take corrective action
Turn up MPLS interface r2-r4 on r2
Module 8 |
46
Module 8 - 46
Troubleshooting MPLS Issues with FRR (3. Fix)
LSP r2-r4-r3 and its associated binding has no failure code and
is operational with the path from r2-r4-r3
Module 8 |
47
Module 8 - 47
Troubleshooting MPLS Issues with FRR (4. Verify)
LSP trace shows two-hop path
Module 8 |
48
Module 8 - 48
Troubleshooting MPLS Issues with FRR (4. Verify)
Using 5620 SAM to view and configure MPLS parameters

Which MPLS alarms are not self-clearing
Listing the more common MPLS problems
Using multiple 5620 SAM tools to troubleshoot MPLS issues
LSP Optimization Policy
Module 8 |
49
Module 8 - 49
Module Summary
Extra Labs
Appendix 8.1
LSP Name is r4-r3-lab8.3

r2
r4
Strict
r1
r3
Module 8 |
51
Module 8 - 51
A newly created LSP between routers r4 and r3 does not

become active (operationally up). CSPF is enabled.
Find the cause but do not fix the issue

LSP description is r1-r6 LDP (Course)
r2
r4
r6
r1
r3
Module 8 |
52
Module 8 - 52
A newly created LDP-based SDP between routers r1 and r6

does not become active (operationally up).
Module 8 |
53
Module 8 - 53
Module 9 - 1
Module 9 Service Level Troubleshooting

the 5620 SAM
View and configure Service Level parameters

Understand the use of State Causes
Validate a service
Understand the usage of a Policy Audit
Troubleshoot VLL/VPLS issues
Troubleshoot VPRN issues
Use a Mirrored Service
Module 9 |
Module 9 - 2

to:
Module Objectives
Services Overview
Module 9 - 3
Service Level Troubleshooting
Customer
SAP
ServiceID
SDP
Service Tunnel
Service Tunnel
PE-A
SDP
PE-B
ServiceID
Customer
SAP
Subscriber
Service Site
Module 9 |
Service Site: The local instance of a service configured on a specific router.
Service Tunnel: An SDP uses a service tunnel to direct traffic from one 7750 SR router to another. The service
tunnel is provisioned with an encapsulation (GRE, RSVP-TE, LDP) type and services are mapped to the service
tunnel.
Service Access Point (SAP): A SAP is a logical entity that serves as a subscribers point of access to a service.
Each service is configured with at least one SAP. A SAP can only be configured on a port that has been
configured as an access port. The default configuration for a port is network, which means that a port will
need to be configured as access before a SAP can be configured on it. SAPs for IES and VPRN services are
configured on IP interfaces.
Service Distribution Path (SDP): An SDP acts as a logical way of directing traffic from one 7750 SR to another
through a unidirectional service tunnel. An SDP originating on one node terminates at a destination node,
which then directs incoming packets to the correct service egress SAPs on that node. A multi-node service
needs at least one SAP and one SDP on each node. For a service to be bidirectional, an SDP must be
provisioned on each node participating in the service.
Subscriber: This represents the user of the service (external to the router and the 5620 SAM).
Customer ID: This is a value associated with the service that can be used to group together several services to
help manage them.
Service ID: A numeric value used to identify the service.
SDP Binding: This is the association between an SDP and a VC ID (the VC ID is usually the same as the Service
ID).
Module 9 - 4
Service Site
Subscriber
Service Components
Use the Service Navigation Tree or Service Topology
Viewing Services
Grouped by Customer
Use a filter within the Manage Services window
Sites, SAPs and SDP bindings
Topology view
Module 9 |
Module 9 - 5
Service Creation steps
Service Creation and Configuration
State Cause Indicators
Module 9 - 6
When the operational state of an object is down, a check

mark appears beside the appropriate State Cause indicator to
identify the type of fault.
Some indicators are more descriptive than others and may
lead the operator to the cause of the issue
Usually found on the General tab of a Properties form
For SDP bindings, it is on the States tab
Best Practice:
View the State Cause Indicator when troubleshooting an
object
Module 9 |
Module 9 - 7
State Cause Indicators
When troubleshooting a SAP, view the State Cause indicator

In this example, it says to focus on the physical port
Viewing the State Cause indicator can save the operator from
doing unnecessary work and speed up the overall investigation
Module 9 |
(SAP properties -> General tab)
Module 9 - 8
State Cause Example
Service Validation
Module 9 - 9
The operational status of a service depends on the

operational states of its service sites or instances
It is possible for a service to be operationally up when
communication between sites is not operational
For example, a VPLS can be operationally up although traffic
cannot pass between two SAPs because of an ACL
If Service Validation failure occurs, the State Cause will be

flagged with OAM Validation Failed
Module 9 |
10
Module 9 - 10
Used to verify the operational status of a service or servicerelated entity
What is Service Validation?
r5
r6
Module 9 |
11
Module 9 - 11
Create a validation test suite to perform MAC pings between the

SAPs to validate the VPLS service.
Service Validation Example
On the Test Suite Properties form, set the Entity Type and
select the Validation Test Suite check box.
Finish creating the test suite by adding the MAC ping tests
under the First Run Tests tab
Module 9 |
12
(Tools -> STM -> Test Suite)
Module 9 - 12
Enabled through the creation of a Test Suite.
Service Validation Example (Creation)
If there is already a validation test suite created for this

service, an entry will appear in the list below and the Test
Suite Validation check box will be selected.
Module 9 |
13
(Manage -> Service -> Services -> Service ID # 37 properties -> Tests tab)
Module 9 - 13
On the VPLS properties form, click the Tests tab, then click
the Test Suite sub tab.
Service Validation Example (Execution)
If no validation test suite is already created for this service, the

following message will be displayed:
Click the OK button and select the test suite created in the
previous slide.
Once selected, the test suite will run automatically.
Module 9 |
14
Module 9 - 14
On the VPLS service Properties form, click the Validate

button.
Service Validation Example (Execution)
Module 9 |
15
(Service properties -> General tab)
Module 9 - 15
If one of the tests in the test suite fails, the service State
Cause will be set to OAM Validation Failed.
Service Validation Example (Results)
Double click this entry to view the results of each individual

test
Module 9 |
16
(Service properties -> Tests tab)

MAC pings that don't have successful pings are due to an ACL.
The pings could also fail due to the MACs not being present as well.
Module 9 - 16
A new entry under the Tested Entity Result sub tab is

available once the test suite execution is completed
By viewing each Failed Result we can see that the problem is

with traffic going to MAC address 22-66-66-66-66-02
Module 9 |
17
(Service properties -> Tests tab -> Validation Results -> MAC Ping Result properties)
Module 9 - 17
Click the Search button and find the entries for the MAC address (There
may be multiple entries containing the same MAC address)
You may have to click Resync before clicking Search
Module 9 |
18
Navigate back to the VPLS service properties form and click the Forwarding
Control tab, then click the FIB Entries sub tab
(Service properties -> Forwarding Control -> FIB Entries)
The Resync button on the right side of the list is for the FIB entries, while the Resync button at the bottom of
the form is to Resync the VPLS Service.
Module 9 - 18
If the FIB is very large, filter for the MAC address and the
keyword local in the Name field
Highlight the entry and click the Edit Access Interface button
to navigate to the SAP in question
Module 9 |
19
(Service properties -> Forwarding Control -> FIB Entries)

At this point, we have now narrowed down the issue to a particular SAP.
An operator would continue to troubleshoot the SAP for why the pings are failing, but in this case we know the
reason is because of our filter.
The purpose of this example is to show Service Validation and how to view MACs.
Module 9 - 19
The local entry is where the MAC address lives
r5
Create and Run a Service Validation for a VPLS to determine if there

are any issues with the customer SAPs. Are there any failures? If so,
what object is causing the problem?
r6
Module 9 |
20
Module 9 - 20
Service Validation (LAB 9.1)
Policy Audit
Module 9 - 21
Provides a consistent way to manage various types of global

and local policies
Helps users to manage hundreds of policies with ease and

efficiency
Centralized control on policy distribution and updates

Detect policy configuration discrepancies
Note: Avoid using Default policies as they cannot be

edited. Create a new policy and assign it to the NEs
instead.
Module 9 |
22
Module 9 - 22
Advantages of 5620 SAM Policies Management:
Policy Overview
Global Policies
Local Policies
Can be applied to multiple NEs

Exist in 5620 SAM only
Instances of global policies that are distributed to individual

NEs
Exist in 5620 SAM and on the NEs
In a typical workflow, a global policy is created in SAM first

and then distributed to all required NEs within the network
Module 9 |
23
Module 9 - 23
Global vs Local
not ready to be distributed
Released
ready to be distributed to new NEs OR
already assigned to the NEs

View the Local Definitions tab to view Local Policies
Draft
Any changes made on a Released policy will automatically change

the policy to Draft
When in Draft mode, click View Released to check the last

Released policy configuration
Only keeps latest version (No History)
Switching from Draft to Released by clicking the Switch Mode

button will trigger the changes of a policy to be distributed to the
NEs (local policies will be updated)
Module 9 |
24
Module 9 - 24
Global Policy Configuration Mode
Global policy is created
2. Switch configuration mode to Released
1. Create a new policy in 5620 SAM
3. Click the Distribute button to select the NEs in 5620 SAM to

define the policy distribution
4. Distribute the policy to the list of selected NEs
Local policies are created for each NE in the distribution list

List of local policies are displayed under the Local Definitions
tab
Module 9 |
25
Module 9 - 25
Policy Workflow Create and Distribute
Most of the time global and local policies are the same;
however, an operator may want to change a local policy
without changing the global policy
Distribution Mode
Sync with Global
Any changes being made in the corresponding global policy will

automatically be distributed to this local policy/NE
Local Edit Only

NOT affected by global policy changes
Only affected by local policy changes
Module 9 |
26
Module 9 - 26
Local Policies
Can be created in two ways

1. Creating a global policy and distributing it to a router
2. Discovering a router in 5620 SAM with existing policies
With default Sync with Global as distribution mode

Can be changed by editing the following variable in the nmsserver.xml file
<policyConfig isPolicyDiscoveredInLocalEditOnlyMode=false />
Change false to true
If created in Local Edit Only mode, the policy can be
changed to a global policy by clicking Synchronize
Best Practice:
When discovering new NEs, set the mode parameter to local
configuration only to ensure that unique policies are not
modified when a global policy is updated.
Module 9 |
27
The default is false, but for best practice it should be changed to true.
Module 9 - 27
Local Policy Creation
Able to identify local policies that are different from their

global policies
Able to show the differences between global and local

policies
Able to show the differences between local policies
Module 9 |
28
Module 9 - 28
Policy Audit Benefits
For a given list of global policies, find all the corresponding

local policies that have different configurations
For a given local policy, click Local Audit On to show the

differences against the global policy
Follow the first step to identify local policies with
differences. If more details are required, follow the
second step.
Module 9 |
29
Module 9 - 29
Policy Audit Workflow
r5
r6
VLL Service
Module 9 |
30
Module 9 - 30
A customer on site r6 of a VLL is having traffic problems.

Perform a policy audit to see if this issue is due to QoS
policy configuration
Policy Audit Example
Find the customer SAP on R6 and record the Access Ingress

and Egress policies that are assigned
Module 9 |
31
(Service properties -> SAP properties -> QoS tab)
Module 9 - 31
Locate QoS Policy to Audit
Load a filter for the Dynamic Alarm window to show only

Policy Audit Alarms
Alarm Name = TemplateInconsistency
Module 9 |
32
Place an advanced filter on the Dynamic Alarm window to show only the TemplateInconsistency alarm.
Module 9 - 32
Policy Audit Alarm Filter
Using the Access Ingress Policy list window, find the

corresponding policy.
Highlight it and click the Policy Audit button
Module 9 |
33
(Policies -> QoS -> SROS QoS -> Access Ingress -> Access Ingress)
Module 9 - 33
Policy Audit Begin
Include Non Applicable Attributes

Set to Local Edit Only upon finding of differences
Set to Sync with Global upon finding no differences
Module 9 |
34
General Tab includes the following selectable attributes
Include Non Applicable Attributes
Leave this unselected
Set to Local Edit Only upon finding of differences
If differences between the local and global are found, set the local policy to Local Edit Only
Set to Sync with Global upon finding no differences
If local policy is currently set to Local Edit Only, but is no different from the global policy, set it
to Sync with Global
Module 9 - 34
Policy Audit Attributes
If desired, the user can select specific NEs to audit under

the Network Element Selection tab.
If none are selected, all NEs will be audited
Click the Start Audit button to begin
If the audit finds a policy inconsistency, an alarm will be

raised for each instance
Module 9 |
35
Module 9 - 35
Start Audit
Double click the TemplateInconsistency alarm and click the

View Alarmed Object button
A Local Policy Properties form opens.
Click the Local Audit On button to view the inconsistencies.
From here, the user can choose to compare with the global
policy or another local policy.
Module 9 |
36
Clicking on Local Audit On from the local policy of a NE will pop up this dialog.
Module 9 - 36
Investigate Audit Results
Once the local audit is turned on, the compared policy

Properties form, either global or local, will open
Locate the inconsistencies by following the purple arrows

on either Policy form
Module 9 |
37
Module 9 - 37
Some entries in a list may be colored purple or pink
Purple entry contains a value that is different between the

two policies
Pink entry is either new or deleted
Module 9 |
38
Module 9 - 38
Double check all objects that will be affected before

making a change to a policy
There is a separate tab for each type of object the policy can
be assigned to.
Each tab lists the objects where this policy is currently
assigned and will therefore be affected by any changes made.
Module 9 |
39
(Policies -> QoS -> SROS QoS -> Access Ingress -> Access Ingress -> Policy # 5 properties -> Local Definitions tab
-> properties of local policy on r5)
Try doing this easily in CLI!
Module 9 - 39
View Assigned Objects
2. Resync to global
3. Sync with another local definition
Once one of the above actions has been performed,

perform another Policy Audit for verification.
If everything is now in sync, the TemplateInconsistency alarm

will clear.
Module 9 |
40
Edit the local definition - set the distribution mode to Local Edit Only, make the changes and save the local
policy.
Resync to global - set the local policy properties to match the global policy by clicking the Switch Mode button
to change the distribution mode back to Sync with Global.
Sync with another local definition - to set the local policy properties to match that of another local policy,
click the Synchronize button. Choose the desired router from the list and click Synchronize.
Module 9 - 40
1. Edit the local definition
Fixing Inconsistencies Options:
If the main symptom of an issue is Traffic Degradation,

audit the QoS policies first.
If the main symptom of an issue is Total Traffic Loss,

audit the Filter policies (ACL, etc.) first.
Module 9 |
41
Module 9 - 41
Best Practice:
QoS vs Filter (ACL, etc.)
A customer on site r6 of a VLL is having traffic problems.

Perform a policy audit to see if this issue is due to ACL
misconfiguration
r5
r6
VLL Service
Module 9 |
42
Module 9 - 42
Policy Audit (LAB 9.2)
Module 9 - 43
Troubleshooting Common VLL/VPLS Issues
An L2 point-to-point service that connects access interfaces

Is completely transparent to customer or subscriber data and
to control protocols; it looks like a leased link exists
No MAC learning
Uses T-LDP signaling, and MPLS or GRE as the service tunnel
transport
The 5620 SAM supports the following VLL service types:
Apipe, or ATM VLL Service
Epipe, or Ethernet VLL service
Fpipe, or frame relay VLL service
Hpipe, or HDLC to HDLC
Ipipe, or IP interworking VLL service
Cpipe, or circuit emulation VLL service
Module 9 |
44
Module 9 - 44
VLL Overview
PE
VLL Service
Module 9 |
45
Module 9 - 45
PE
VLL Overview
r5
Traffic cannot pass within a VLL service
r6
X
VLL Service
Module 9 |
46
Module 9 - 46
Failure Scenario VLL
Symptoms
VLL Service is operationally down

VLL Sites are down
VLL SDP bindings are down
Module 9 |
47
(Manage Service -> Services -> service id #47 -> General tab)
(Manage Service -> Services -> service id #47 -> General tab -> Topology)
Module 9 - 47
Failure Scenario VLL (1. Identify)
When viewing the critical alarm on the SDP binding, we can

see two correlated alarms for the service site
The cause is most likely a misconfiguration of the SDP binding
and if fixed, the alarm on the site should clear as well
Module 9 |
48
Module 9 - 48
Failure Scenario VLL (2. Investigation)
View the SDP binding alarm
None of the fields in the alarms help to pinpoint the cause
Click the View Alarmed Object button to view the SDP
Check the State Cause under the States tab
The State Cause is set to No Egress VC Label
Module 9 |
49
(Service properties -> SDP properties -> States tab)
Module 9 - 49
Based on the State Cause, check the VCID and Label

configuration
Located on the General tab

VCID = 100 with No Operational Egress Label
Module 9 |
50
(Service properties -> SDP properties -> General tab)
Module 9 - 50
Compare this to the returning SDP binding
VCID = 101 and No Operational Egress Label
The VCIDs of both SDP bindings should be equal; if they

are not, one is configured incorrectly
Module 9 |
51
Module 9 - 51
Because the VCID of an SDP binding cannot be changed once it is

created, we must delete the existing one and create a new
binding with the correct VCID.
Module 9 |
52
Module 9 - 52
Failure Scenario VLL (3. Fix)
Once this is done, the service and all components go

operationally up
Module 9 |
53
Module 9 - 53
Failure Scenario VLL (4. Verify)
You may have been able to find the cause of this issue
much faster simply by studying the service navigation tree,
or by using the Info Tables feature for SDP bindings.
Module 9 |
54
Module 9 - 54
Failure Scenario VLL (Alternate Investigation)
Customer sites in the VPLS appear to be on the same LAN,

even if the sites are geographically dispersed
Devices perform MAC learning
Uses T-LDP signaling, and MPLS or GRE as the service tunnel
transport
Can use HVPLS to eliminate the need for a full mesh of
virtual circuits between devices in a VPLS
Module 9 |
55
Module 9 - 55
VPLS is a class of L2 VPN service that allows multiple

customer sites to be connected in a single bridged domain
VPLS Overview
Blue VPLS
PE
PE
PE
PE
Red VPLS
Module 9 |
56
Module 9 - 56
VPLS Overview
A
r5
r6
Module 9 |
57
Module 9 - 57
End User A within a VPLS is stating that they are no longer

receiving traffic from End User B
Failure Scenario VPLS
All service objects are up and operational
Check statistics on the customers SAP (Complete Service

Egress) to see if packets are being forwarded
Use the following counters: Out of Profile Pkts Forwarded and

Out of Profile Pkts Dropped
View the current values and compare these with historical
stats
Plotter provides a graphical view
Apply filter on the desired queue (this example uses queue 1)
Module 9 |
58
(VPLS 31 -> site r5 -> SAP 1/1/4 -> Statistics -> Select Object Type -> Complete Service Egress Packet Octets,
Filter)
(VPLS 31 -> site r6 -> SAP 1/1/4 -> Statistics -> Select Object Type -> Complete Service Ingress Packet Octets,
Filter)
Module 9 - 58
Failure Scenario VPLS (1. Identify)
INGRESS
(R6 SAP 1/1/4)
EGRESS
(R5 SAP 1/1/4)
Module 9 |
59
Ingress above is: (VPLS 31 -> site r6 -> SAP 1/1/4 -> Statistics -> Select Object Type -> Complete Service
Ingress Packet Octets, Filtered on q #1)
Egress above is: (VPLS 31 -> site r5 -> SAP 1/1/4 -> Statistics -> Select Object Type -> Complete Service
Egress Packet Octets, Filtered on q #1)
These are historical statistics (not available for real time plotting).
Note that the screen captures above are from when the Traffic Generator has stopped (ftp gave up).
Module 9 - 59
Can also use the plotter to view SAP Egress QoS Queue
Accounting statistics
This gives the operator a REAL TIME view of customer traffic

passing on the SAP
Module 9 |
60
(VPLS 31 -> site r5 -> SAP 1/1/4 -> Statistics -> Select Object Type -> SAP Egress QoS Queue Accounting
Statistics, Dropped Out of Prof PcktPeriodic, q 1)
Statistics, Forwarded Out Prof Pckt Periodic, q 1)
Dropped and forwarded packets on SAP 1/1/4 of r5 are both 0.
Module 9 - 60
Customer SAP Accounting stats
Statistics on a customers SAP can also be used for

investigation purposes
The previous slides show that there is currently no traffic
making it to this SAP (on r5)
There are no dropped packets reported by the SAP, therefore
packets are being dropped before they reach this SAP
Module 9 |
61
Module 9 - 61
Failure Scenario VPLS (2. Investigation)
Viewing the VPLS service Components tab shows there are no

objects in an alarmed state; therefore, the problem is most
likely with the transport.
Congestion?
QoS?
Module 9 |
62
Module 9 - 62
Trace the path that traffic is using
From the service Components tab, view the properties of the SDP
binding from r6 to r5.
View the Properties form of the service tunnel used
Under the LSP tab, view the LSP properties
Click the LSP-Path Bindings tab
The Secondary path is currently in an Active state

When and why did this switch from the Primary path?
Is the route for the Primary path operational?
Module 9 |
63
(Service properties -> SDP properties -> Tunnel properties -> LSPs tab -> LSP properties -> LSP-Path Bindings
tab)
Module 9 - 63
To explain why the binding switched to the Secondary path,

view the Dynamic Alarm window and/or Historical Alarms
The Primary LSP-Path Binding shows a major alarm

Time on alarm was 01/04 14:55
The cause of the switch is not indicated in this alarm
Filtering for a point in time just BEFORE 01/04 14:55, search

for alarms using both the Dynamic Alarm and Historical Alarm
windows
NOTE: If getting traffic back up and running is the main

priority, this step can be performed later
Module 9 |
64
The primary LSP-Path binding shows a major alarm (LSP Path Down), but the cause is not indicated. This alarm
is still useful as it points to a time to look for other network events that could have caused the issue.
Module 9 - 64
Within the Historical Alarm window, at 14:55, there are many

OSPF and MPLS alarms
Within these alarms is a EquipmentAdministrativelyDown
alarm for Port 1/1/1 on site r4
Module 9 |
65
(Tools -> Historical Alarms)
Module 9 - 65
This port is configured as the interface facing site r6

If we go back and look at the provisioned path of the primary
LSP-path binding, we see it goes through site r4
Port 1/1/1 on site r4 is currently operationally up, which

should allow the primary path to become Active
Module 9 |
66
(LSP-Path Bindings properties -> Provisioned Path tab)

The port 1/1/1 on r4 that bounced is connected to r6.
The primary LSP path did not switch back automatically because its Retry Limit was exceeded. This can be
seen by looking at the failure code on the LSP-Path binding.
Module 9 - 66
Restart the Primary to make it active
The Primary LSP-path binding should become Active and the

alarm will clear.
Module 9 |
67
Module 9 - 67
Failure Scenario VPLS (3. Fix)
View the SAP Egress QoS Queue Accounting statistics on the

customers SAP to verify that traffic is passing
If the Plotter is still running, it should be plotting traffic flow
Module 9 |
68
Statistics, Dropped Out of Prof Periodic, q 1)
Statistics, Forwarded Out Prof Pckt Periodic, q 1)
Module 9 - 68
Failure Scenario VPLS (4. Verify)
Service ID = 31
Find the cause but DO NOT fix it
A
r5
In a VPLS service, End User A cannot receive traffic from End

User B
r6
Module 9 |
69
Module 9 - 69
Service Level Troubleshooting (LAB 9.3)
When troubleshooting issues with end user SAPs, perform a

policy audit to check for inconsistencies and examine
statistics where appropriate.
Module 9 |
70
Module 9 - 70
Best Practice:
r5
In a multi-site VPLS, site r6 cannot reach site r5. Site r6 can

reach all other sites
r6
Module 9 |
71
Module 9 - 71
Module 9 - 72
Troubleshooting Common VPRN Issues
VPRNs, also called IP VPNs or BGP/MPLS VPNs, are defined in

RFC 2547bis
This standard describes a method of forwarding data and

distributing routing information across an IP/MPLS service provider
core network.
Use MP-BGP to exchange the VPRN routes among the PE

routers that participate in the VPRN
Done in a way that ensures that routes from different VPRNs
remain distinct and separate.
PE routers distribute routes to CE routers in the VPRN
The PE routers use BGP, RIP, or OSPFv2 as the IGP to distribute

internal routes to the CE routers
Module 9 |
73
Module 9 - 73
Troubleshooting VPRNs
CE devices can be routers, a host or a Layer 2 device
Each VPN site must contain one or more Customer Edge (CE)
devices
A PE router is on the Service Provider Edge. Each CE device is

attached, via some sort of attachment circuit, to one or
more Provider Edge (PE) routers
The VRF is the VPN Routing and Forwarding Table
MPLS LSP or GRE tunnels are used to transfer the actual
traffic
Module 9 |
74
Module 9 - 74
PE
PE
PE
Blue VPRN
Red VPRN
PE
Module 9 |
75
IP/MPLS infrastructure can be used to offer multiple services.

From a customer perspective, the VPRN looks like a Layer 3 router.
Module 9 - 75
MP-BGP route
exchange for
all services
YES
Is the VPRN Enabled?
NO
YES
Is an RD configured?
NO
Enable VPRN
Configure a RouteDistinguisher. An RD must be

configured even if the VPRN
service is local.
Module 9 |
76
Module 9 - 76
No routes in the VRF?
Flowchart # 1 For Troubleshooting VPRN Issues
YES
Is the interface within the

VPRN UP?
NO
Enable the interface. Check

the status of the port that the
interface/SAP is bound to.
Module 9 |
77
Module 9 - 77
CE routes missing in the VRF?
YES
Is MP-BGP Session UP?
NO
YES
Are routes in BGP RIB-in?
NO
YES
Is the transport operational?
NO
Enable BGP configuration

This is typically because the VRF
import-target VRF export target
being used by the remote PE
The VPRN must be bound to an
operational SDP for the next-hop of
the VPRN route or Auto-Bind LDP or
GRE must be configured.
YES
Is a policy configured?
NO
Confirm policy settings
Module 9 |
78
MP-BGP:
Multi Protocol BGP (required to support VPRNs).
To enable MP-BGP: Routing Instance -> BGP site -> VPN tab -> VPN IPv4 checked.
BGP RIB-in (Routing Information Base in):

(CLI: show router bgp routes)
Routes received from other BGP peers.
Module 9 - 78
Routes from remote PE are not

getting installed in the VRF?
r3
r1
VPRN Service
Module 9 |
79
Module 9 - 79
A newly created VPRN is operationally up but routes are not

being properly advertised between sites.
Troubleshooting VPRNs Failure Scenario 1

Verify Issue
Both VPRN sites have one interface

All objects are operationally up
Module 9 |
80
(Service 33 -> Topology)
Module 9 - 80
R1 has no
routes in
the VRF
R3 sees no
remote
routes
Module 9 |
81
It is expected that we would see local and remote routes on both routers.
(Service -> Topology -> right click on site -> Show routes)
Module 9 - 81
Show Routes on
the routers
A VPRN ping from r1 to r3

VPRN interface vprn_2_2
(10.1.3.2) fails with Status =
Invalid Source IP
Module 9 |
82
Module 9 - 82
View the alarm in the Dynamic Alarm window or in the

VPRN service itself
There is one alarm related to the VPRN in question
Module 9 |
83
2. Investigation
Module 9 - 83
The alarm indicates

that a Route
Distinguisher is not
configured on r1
Click the View
Alarmed Object
button
Module 9 |
84
Module 9 - 84
Module 9 |
85
(Service properties -> Routing tab -> General tab)
Module 9 - 85
The Route Distinguisher on Routing Instance r1 is not

configured
Correct the Route Distinguisher on r1
SAM can suggest

values configured
within the VPRN
service
Module 9 |
86
3. Take corrective action
(Service properties -> Routing tab -> General tab)
Module 9 - 86
Verify that the routes are now correct on both sites
Module 9 |
87
(Service -> Topology -> right click on site -> Show routes)
Module 9 - 87
4. Verification
Perform OAM test of VPRN

ping, which was executed
in step #1, to verify the
issue no longer exists
Also, note that the alarm
was implicitly cleared
Module 9 |
88
Module 9 - 88
Troubleshooting VPRNs Failure Scenario 1 (Verification cont.)
Service ID = 34
Which subnet(s) on r3 cannot connect to the corporate server?
10.3.3.0/24
10.2.2.0/24
Headquarters
10.4.4.0/24
r1
r3
10.5.5.0/24
Subnets
Module 9 |
89
Module 9 - 89
Users on some (not all) subnets on r3 cannot connect to the

corporate server located at headquarters on r1. For this
exercise, subnets are represented by loopbacks.
Troubleshooting VPRN Issues (LAB 9.5)
When troubleshooting VPRN issues, be sure to view and

confirm the attributes under the Routing tab of a VPRN
Routing Instance (Site)
Module 9 |
90
(Service properties -> VPRN Site -> Routing tab)
Module 9 - 90
Best Practice:
Troubleshooting VPRN Issues (LAB 9.5)
Service ID = 33
r3
r1
10.1.2.0/24
10.1.3.0/24
VPRN Service
Module 9 |
91
Module 9 - 91
Users between sites r1 and r3 cannot communicate to each

other.
Troubleshooting VPRN Issues (Lab 9.6)
Mirror Services
Module 9 - 92
Alcatel-Lucents 7x50 routers support service-based mirroring

Can mirror on an n-to-1 unidirectional service basis and reencapsulate the mirrored data for transport through the core
network to another location, using either IP or MPLS tunneling
as required
Original packets are forwarded, while a copy is sent from the
mirrored port to the mirroring (destination) port
Module 9 |
93
Module 9 - 93
Customer packets can be examined as they traverse the

network
Mirror Services
In many cases, this reduces the need for a separate, costly

overlay sniffer network
Is not an End Customer consumable service
Allows operators to monitor live traffic
Service mirroring allows an operator to see the actual traffic

on a customers service with a sniffer sitting in a central
location
Traffic from a port, SAP or SDP can be mirrored (duplicated)

and sent to a test device either locally or remotely
Module 9 |
94
Module 9 - 94
Mirror Services
Destination Site: a service site where the test equipment is

attached
A mirror service must have a destination site
Source Site: a service site where the traffic that is being

monitored exists
Only created if the port to be monitored is not on the same site

as the test equipment site.
Module 9 |
95
Module 9 - 95
Service Sites
Mirror Services
Mirror
Traffic VPLS
Module 9 |
96
Create a remote mirror of the Traffic VPLS service
(Manage -> Service -> Mirror Services)
Note that for a Mirror Service, the source SAP is not shown in the topology view, and only one SDP is used.
Module 9 - 96
Mirror Services - Example #1
Module 9 |
97
Module 9 - 97
Module 9 - 98

Kazi Zial Hoque.2013-11-22.SAM StudentGuide Ver1.4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Kazi Zial Hoque.2013-11-22.SAM StudentGuide Ver1.4

Uploaded by

Copyright:

Available Formats

Course Introduction

This ALU-IPD-SRC Alcatel-Lucent_Network_and_Service_Troubleshooting_with_the_5620_SAM Guide is for exclusive use of Kazi_Zial_Hoque - WIND_Mobile

Network and Service Troubleshooting with

Alcatel-Lucent Career Certification

Network and Service Troubleshooting with the 5620 SAM v1.4

Network and Service Troubleshooting with the 5620 SAM

All rights reserved 2012-2013 Alcatel-Lucent

This ALU-IPD-SRC Alcatel-Lucent_Network_and_Service_Troubleshooting_with_the_5620_SAM Guide is for exclusive use of Kazi_Zial_Hoque - WIND_Mobile

4 DAYS / 1 COURSE / 1 WRITTEN EXAM

18 DAYS / 4 COURSES / 4 WRITTEN EXAMS /

32 DAYS/ 7 COURSES / 7 WRITTEN EXAMS /

Network and Service Troubleshooting with the 5620 SAM v1.4

All rights reserved 2012-2013 Alcatel-Lucent

Network and Service Troubleshooting with the 5620 SAM

This ALU-IPD-SRC Alcatel-Lucent_Network_and_Service_Troubleshooting_with_the_5620_SAM Guide is for exclusive use of Kazi_Zial_Hoque - WIND_Mobile

The Alcatel-Lucent SRC Program Five Certifications

Network and Service Troubleshooting with the 5620 SAM v1.4

Network and Service Troubleshooting with the 5620 SAM

All rights reserved 2012-2013 Alcatel-Lucent

This ALU-IPD-SRC Alcatel-Lucent_Network_and_Service_Troubleshooting_with_the_5620_SAM Guide is for exclusive use of Kazi_Zial_Hoque - WIND_Mobile

SRC Courses and Exams

Alcatel-Lucent Scalable IP Networks

Alcatel-Lucent Interior Routing Protocols

Alcatel-Lucent Border Gateway Protocol

Alcatel-Lucent Multiprotocol Label Switching

Alcatel-Lucent Services Architecture

Alcatel-Lucent Virtual Private LAN Services

Alcatel-Lucent Virtual Private Routed Networks

Alcatel-Lucent Quality of Service

Alcatel-Lucent Multicast Protocols

Alcatel-Lucent Triple Play Services

Alcatel-Lucent Advanced Troubleshooting

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport

Alcatel-Lucent Mobile Gateways for the LTE Evolved

Alcatel-Lucent Network Routing Specialist II Lab Exam

100, 101, 103, 104

Alcatel-Lucent Mobile Routing Professional Lab Exam

100, 101, 103, 104, 107, M01, M02, NRSII4A0

Alcatel-Lucent Service Routing Architect Lab Exam

Network and Service Troubleshooting with the 5620 SAM v1.4

Network and Service Troubleshooting with the 5620 SAM

All rights reserved 2012-2013 Alcatel-Lucent

This ALU-IPD-SRC Alcatel-Lucent_Network_and_Service_Troubleshooting_with_the_5620_SAM Guide is for exclusive use of Kazi_Zial_Hoque - WIND_Mobile

SRC Program Exam Profile

The Alcatel-Lucent MySRLab service provides:

Need access to an SR lab to help you:

Access to traffic simulation and analysis tools

Network and Service Troubleshooting with the 5620 SAM v1.4

All rights reserved 2012-2013 Alcatel-Lucent

This ALU-IPD-SRC Alcatel-Lucent_Network_and_Service_Troubleshooting_with_the_5620_SAM Guide is for exclusive use of Kazi_Zial_Hoque - WIND_Mobile

Alcatel-Lucent Scalable IP Networks

All rights reserved 2012-2013 Alcatel-Lucent

This ALU-IPD-SRC Alcatel-Lucent_Network_and_Service_Troubleshooting_with_the_5620_SAM Guide is for exclusive use of Kazi_Zial_Hoque - WIND_Mobile

SRC Self-study Options

Global provider of testing services

Network and Service Troubleshooting with the 5620 SAM v1.4

Network and Service Troubleshooting with the 5620 SAM

All rights reserved 2012-2013 Alcatel-Lucent

This ALU-IPD-SRC Alcatel-Lucent_Network_and_Service_Troubleshooting_with_the_5620_SAM Guide is for exclusive use of Kazi_Zial_Hoque - WIND_Mobile

On-site delivery at your business location anywhere in the world

Class schedules available at www.alcatel-lucent.com/src

All rights reserved 2012-2013 Alcatel-Lucent

This ALU-IPD-SRC Alcatel-Lucent_Network_and_Service_Troubleshooting_with_the_5620_SAM Guide is for exclusive use of Kazi_Zial_Hoque - WIND_Mobile