5620 SAM (Service Aware Manager) R7 (1) .0 Operator Ed

5620 SAM 5620 SAM (Service Aware Manager) R7.
0 Operator
TOS36010 Issue 1.0
STUDENT GUIDE
All Rights Reserved Alcatel-Lucent 2009
All rights reserved Alcatel-Lucent 2009 Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent
All Rights Reserved Alcatel-Lucent 2009 5620 SAM (Service Aware Manager) R7.0 Operator - Page 1
Terms of Use and Legal Notices

1. Safety Warning Switch to notes view!
Both lethal and dangerous voltages may be present within the products used herein. The user is strongly advised not to wear conductive jewelry while working on the products. Always observe all safety precautions and do not work on the equipment alone. The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.
2. Trade Marks
Alcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent. All other trademarks, service marks and logos (Marks) are the property of their respective holders, including AlcatelLucent. Users are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning the Mark. The absence of a Mark identifier is not a representation that a particular product or service name is not a Mark. Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to change without notice.
3. Copyright
This document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No other use or transmission of all or any part of this document is permitted without Alcatel-Lucents written permission, and must include all copyright and other proprietary notices. No other use or transmission of all or any part of its contents may be used, copied, disclosed or conveyed to any party in any manner whatsoever without prior written permission from Alcatel-Lucent. Use or transmission of all or any part of this document in violation of any applicable legislation is hereby expressly prohibited. User obtains no rights in the information or in any product, process, technology or trademark which it includes or describes, and is expressly prohibited from modifying the information or creating derivative works without the express All Rights Reserved Alcatel-Lucent 2009 2 written consent of Alcatel-Lucent.
5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
All rights reserved Alcatel-Lucent 2009
4. Disclaimer
In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential damages, including lost profits, lost business or lost data, resulting from the use of or reliance upon the information, whether or not AlcatelLucent has been advised of the possibility of such damages. Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes neither an endorsement, nor a recommendation. This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent products. The information contained herein is representational only. In the interest of file size, simplicity, and compatibility and, in some cases, due to contractual limitations, certain compromises have been made and therefore some features are not entirely accurate. Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment and its operation, or contact your nearest Alcatel-Lucent representative for more information. The Alcatel-Lucent products described or used herein are presented for demonstration and training purposes only. AlcatelLucent disclaims any warranties in connection with the products as used and described in the courses or the related documentation, whether express, implied, or statutory. Alcatel-Lucent specifically disclaims all implied warranties, including warranties of merchantability, non-infringement and fitness for a particular purpose, or arising from a course of dealing, usage or trade practice. Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected transmissions, failed internet connections, interruptions, any computer virus or any other technical defect, whether human or technical in nature
5. Governing Law
The products, documentation and information contained herein, as well as these Terms of Use and Legal Notices are governed by the laws of France, excluding its conflict of law rules. If any provision of these Terms of Use and Legal Notices, or the application thereof to any person or circumstances, is held invalid for any reason, unenforceable including, but not limited to, the warranty disclaimers and liability limitations, then such provision shall be deemed superseded by a valid, enforceable provision that matches, as closely as possible, the original provision, and the other provisions of these Terms of Use and Legal Notices shall remain in full force and effect.
Blank Page
Switch to notes view!
3
This page is left blank intentionally
Course Outline
1. This Course AboutProduct Overview
4. Topic/Section is Positioned Here
2. System Overview
Course outline 1. Alcatel-Lucent IP Products Overview Technical support Overview 2. 5620 SAM 5. Topic/Section is Positioned Here Course objectives
1. System Architecture 1. Topic/Section is Positioned Here 3. Graphical User Interface Xxx Xxx 1. Login and GUI Overview Xxx 4. Router Discovery
6. Topic/Section is Positioned Here 7. Topic/Section is Positioned Here
2. Topic/Section is Positioned Here

2. Discovery Management 3. Generic Node Elements 3. Topic/Section is Positioned Here 5. Hardware Configuration 1. Hardware Navigation 6. Routing Protocol Configuration 1. OSPF Configuration 2. IS-IS Configuration 7. MPLS Infrastructure Configuration 1. MPLS using LSPs
4
1. SNMP Configuration
2. MPLS using LDP 3. Traffic Engineering
8. Basic Services 1. Service Tunnel Configuration 2. Epipe Configuration 3. VPLS Configuration 4. IES Configuration 5. VPRN Configuration 9. Create Services from Template 1. Create Epipe from Template 2. Create VPLS from Template
Course Outline
10. Alarm Management About This Course
Course outline Management - Alarms 1. Fault Technical support 11. Performance Monitoring Course objectives
4. Topic/Section is Positioned Here 5. Topic/Section is Positioned Here 6. Topic/Section is Positioned Here
1. Performance Management 1. Redundancy
12. Appendix 1. Topic/Section is Positioned Here

Xxx Xxx Xxx
2. Hardware and Software SpecificationsTopic/Section is Positioned Here 7. 3. Routing Protocol Overview 4. MPLS Overview 5. Basic Services Overview
2. Topic/Section is Positioned Here 3. Topic/Section is Positioned Here
5
Course Outline [cont.]

6
Course Objectives
Welcome to 5620 SAM (Service Aware Manager) R7.0 Operator
Upon completion of this course, you should be able to:
Understand the 5620 SAM architecture, GUI and basic operations, discovery manager and mediation policies, equipment and service management, alarm management and statistics, including the new features introduced on R7.0 Configure basic services and create services from templates
7
Course Objectives [cont.]

8
About this Student Guide

Conventions used in Switch to notes view! this guide
Note
Provides you with additional information about the topic being discussed. Although this information is not required knowledge, you might find it useful or interesting.
Technical Reference
(1) 24.348.98 Points you to the exact section of Alcatel-Lucent Technical Practices where you can find more information on the topic being discussed.
Warning
Alerts you to instances where non-compliance could result in equipment damage or personal injury.
Where you can get further information

If you want further information you can refer to the following: Technical Practices for the specific product Technical support page on the Alcatel website: http://www.alcatel-lucent.com
About this Student Guide [cont.]

10
Self-assessment of Objectives
Contract number : Course title :
At the end of each section you will be asked to fill this questionnaire Please, return this sheet to the trainer at the end of the training to notes view!
Dates from : Location : to :
Client (Company, Center) : Language : Switch
Number of trainees : Surname, First name :
Did you meet the following objectives ? Tick the corresponding box Please, return this sheet to the trainer at the end of the training
Yes (or globally yes) No (or globally no)
Instructional objectives 1 To be able to XXX
Comments
2
11
5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
Self-assessment of Objectives [cont.]

Instructional objectives Yes (or Globally yes) No (or globally no) Comments
12
Other comments
Thank you for your answers to this questionnaire
11
Do not delete this graphic elements in here:
Section 1 Product Overview

TOS36013_01_01 Issue 1.1
Module 1 Alcatel-Lucent IP Products Overview
5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator TOS36010 Issue 1.0
All Rights Reserved Alcatel-Lucent 2009 TOS36013_01_01 Issue 1.1 Section 1 Module 1 Page 1
Blank Page
112
Product Overview Alcatel-Lucent IP Products Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Document History Edition 01 Date 2009-08-14 Author GARCIA LOZANO, Ren Remarks First edition
Module Objectives
Upon completion of this module, you will be able to:
List the 5620 SAM R7.0 supported Alcatel-Lucent devices and their major functions
113
5620 SAM R7.0 Supported Alcatel-Lucent Devices
Supported Alcatel-Lucent Devices 7750 SR 7705 SAR 7250 SAS/SAS-ES/SAS-ESA OS 6850/6855/6400 7210 SAS-E 7710 SR 7450 ESS Telco OMNI 9600/9700/9800 9500 MPR
114
The 5620 SAM supports the above listed Alcatel-Lucent devices.
Note
[Inserted Note] The 5620 SAM supports up to three major releases of the devices. For example, the 5620 SAM can manage a 7750 SR at Release 7.0, Release 6.1 and 6.0, or Release 5.0. Older releases of the devices are not supported.
7750 / 7710 Service Routers
7750 SR-1
7750 SR-7
7710 SR 7750 SR-12

115
Product Overview Alcatel-Lucent IP Products Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
SR-1 Chassis
The SR-1 integrates the I/O, switch fabric/control, power supplies, and fans on one chassis. These components are factory installed and are not field replaceable.
Features
The SR-1 supports the following features: Rack mounted (19 rack); 1.5 Rack Units (RU) high (2.625) Two hot-swappable Media Dependent Adapters (MDAs) are 10Gb/s each Up to three Compact Flash memory are cards used to store operating system files, configuration files, and system logs Power redundancy with AC/DC or dual DC supplies Alarm output port for connection to external alarm devices Front panel LEDs for system status, power, fans, compact flash units, and alarms
7750 / 7710 Service Routers [Cont.]

Switch to notes view! SR-7 Chassis
The SR-7 chassis supports seven slots, five Input/Output Modules (IOMs) and two Switching Fabric/Control Processor Modules (SF/CPMs). The IOM slots are numbered 1 through 5, with 1 being at the top of the chassis. The SF/CPM slots are designated as slots A and B, with B being the bottom slot. Each IOM holds two MDAs, designated MDA 1 and MDA 2. If you are facing the front of the chassis, MDA 1 is installed in the left-hand slot of an IOM and MDA 2 is installed in the right-hand slot of the IOM. The SF/CPM, IOMs, MDAs, and power supply modules can be accessed from the rear of the chassis. The fan and filter trays are accessible from the rear of the chassis. Power Supply Modules (PSMs) are front-loaded in bays 1 and 2.
Features
The SR-7 supports the following features: Two hot-swappable 200 Gb/s SF/CPMs(1) ; load sharing and fully redundant (respectively) when two are installed. Up to ten hot-swappable MDAs; MDAs support Small Form-Factor Pluggable (SFP) optics, twisted pair and coaxial interfaces (MDA dependent) Up to three Compact Flash memory cards are used to store system operating files, configuration files and logs AC (nominal 200V to 240V) or DC (-48V) load sharing power modules; redundancy when two DC PEMs are installed or two AC Power Entry Modules (PEMs) and PSMs are installed Alarm output port for connection to external alarm devices Front panel LEDs for system status, power, fans, compact flash units, and alarms All Rights Reserved Alcatel-Lucent 2009 116 Building IntegratedIP Timing Systems (BITS) port Product Overview Alcatel-Lucent Products Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator Rack mounted (19 rack); 8 RU (14) high
Note
(1)
[Inserted note] 400 G SF/CPMs can be installed as an alternative.
SR-12
The SR-12 chassis supports twelve slots; ten IOMs and two SF/CPMs. The IOM slots are numbered 1 through 5, on the left of the chassis, and 6 through 10, on the right side of the chassis. The SF/CPM slots are designated as slots A and B, and re installed in the center two card slots in the chassis (slot 6 and 7). Each IOM holds two MDAs, designated MDA 1 and MDA 2. If you are facing the front of the chassis, MDA 1 is installed in the top slot of an IOM and MDA 2 is installed in the bottom slot of the IOM. The SF/CPM, IOMs, MDAs, and power supply modules can be accessed from the rear of the chassis. The fan and filter trays are accessible from the front of the chassis. Power supply modules are rear-loaded in bays 1 and 2.
Features
The SR-12 supports the same features as the SR-7 with the exception of the number of MDAs that are supported. The SR-12 fits into a standard 19 inch rack and is 14 RU (24.5) high.
7710 Service Router

The 7710 Service Router uses the same Flexible Fast Path technology and operating system as the 7750 SR. It has a redundant, centralized control and forwarding architecture with 10 Gb/s bandwidth capacity shared across 12 I/O positions. The 7710 SR can accommodate eight Compact Media Adapters (CMAs). The 7710 SR is fully redundant and is five rack units high.
7705 Service Aggregation Router
7705 SAR
117
7705 SAR Chassis

The 7705 SAR chassis contains eight horizontal slots for the CSMs and adapter cards, and one vertical slot for the Fan module. The 7705 SAR Adapter cards are hot-swappable and field-replaceable. Adapter cards install in slots MDA 1 through MDA 6. The CSM slots are designated as slots A and B, with B being the top right slot. The connectors for the DC power feeds are located to the right of the Fan module and are factory-installed.
Features
The 7705 SAR supports the following features: Two hot-swappable Control and Switching Modules (CSMs); load sharing and fully redundant (respectively) when two are installed Up to six hot-swappable MDAs; MDAs support Small Form-Factor Pluggable (SFP) optics, and twisted pair (MDA dependent) One Compact Flash memory cards is used to store system operating files, configuration files and logs Two bipolar power entry connectors allow for independent -48/-60 VDC power feeds, providing power redundancy Alarm output port for connection to external alarm devices Front panel LEDs for system status, power, fans, and alarms Node Synchronization Supply Unit (SSU) Clock External BNC/ MDA port Fits into a standard 2U rack (12 deep, 19 wide)
7450 Edge Service Switch
ESS-1 ESS-6
ESS-7
118
ESS-12
The Alcatel-Lucent 7450 ESS sets a new market standard for enabling the delivery of profitable Ethernet business services in metro, national and international network environments. It also provides high density service-aware Ethernet aggregation for consumer triple-play services over IP/MPLS-based networks. The Alcatel-Lucent 7450 ESS is purpose-built for the service provider market, with an architecture that supports a wide range of interfaces and offers unmatched density and performance. The 7450 ESS allows service providers to offer new, revenue-generating services for both the consumer and business markets.
ESS-1 Chassis
The ESS-1 integrates the I/O, switch fabric/control, power supplies, and fans on one chassis. These components are factory installed and are not field replaceable.
Features
The 7450 ESS-1 supports the following features: Rack mounted (19 rack); 1.5 Rack Units (RU) high (2.625) Two hot-swappable media dependent adapters (MDA); 10 Gbps each Up to three Compact Flash memory cards used to store operating system files configuration files, and system logs AC (nominal 100V to 240V) and/or DC (-48V) load sharing power supplies; power redundancy when both AC and DC power connections are used or two DC connections Cooling provided by six variable-speed fans; air flow is side to side 10/100 Ethernet management port Serial console port for initial system start up, configuration, and monitoring Alarm output port for connection to external alarm devices Front panel LEDs for system status, power, fans, compact flash units, and alarms
7450 Edge Service Switch [Cont.]

Switch to notes ESS-6 Chassis view!
The ESS-6 is targeted at customers requiring a lower-capacity system with full redundancy options who do not require a future upgrade to 40Gb/s IOMs. Target applications for the Alcatel-Lucent 7450 ESS-6 include Ethernet aggregation for broadband (with or without subscriber management as per the TPSDA architecture) and Ethernet business services for smaller PoPs and Cos.
Features
The ESS-6 supports the following features: Rack mounted (19 rack); 8 RU(14) high 2 Switch Fabric /Control Processor Modules called the SFM2-80G (also known as SF/CPM Lite) for full redundancy The SFM2-80G is specifically designed for the ESS-6 and supports a bandwidth capacity of 80 Gbps (20 Gb/s per slot). The SFM2-80G is usable only in the Alcatel-Lucent 7450 ESS-6 chassis Up to 4 Input Output Modules (IOM); supports 20G and/or 10G versions SFM2-80G supports most features of the 200G or 400G SF/CPMs on the ESS-7 and ESS-12 except: No BITs interface No DTE Aux/Modem port Only 1 CPU, does not affect feature set offered on the ESS-6 Supports the same operating system and MDAs as the current Alcatel-Lucent 7450 ESS family
119
ESS-7 Chassis
The ESS-7 chassis supports seven slots, five IOMs and two SF/CPMs. The IOM slots are numbered 1 through 5, with 1 being at the top of the chassis. The SF/CPM slots are designated as slots A and B, with B being the bottom slot. Each IOM holds two MDAs, designated MDA 1 and MDA 2. If you are facing the front of the chassis, MDA 1 is installed in the left-hand slot of an IOM and MDA 2 is installed in the right-hand slot of the IOM. The SF/CPM, IOMs, MDAs, and power supply modules can be accessed from the rear of the chassis. The fan and filter trays are accessible from the rear of the chassis. Power supply modules are front-loaded in bays 1 and 2.
Features
The ESS-7 supports the following features: Rack mounted (19 rack); 8 RU (14) high Two hot-swappable 200 Gb/s SF/CPMs; load sharing and fully redundant when two of one type are installed Five IOM slots; each IOM holds two MDAs Up to ten hot-swappable MDAs; MDAs support Small Form-factor Pluggable (SFP) optics, twisted pair and coaxial interfaces (MDA dependent) Up to three Compact Flash memory cards used to store system operating files, configuration files and log AC (nominal 200V to 240V) or DC (-48V) load sharing power modules; redundancy when two DC PEMs installed or two AC PEMs and PSMs are installed 10/100 Ethernet management port Serial console port for initial system startup, configuration, and monitoring Front panel LEDs for system status, power, fans, compact flash units, and alarms Building Integrated Timing Systems (BITS) port
7450 Edge Service Switch [Cont.]

Switch to notes ESS-12 Chassis view!
The ESS-12 has 12 vertical slots. The chassis weighs approximately 73 lbs (33 kg) and fits into a standard 19 inch rack. The 2 slots in the middle are reserved for two SF/CPM cards. Two SF/CPM cards provides for full switching and control redundancy. The remaining 10 slots are available for IOM cards. Each IOM card can hold two MDAs. All the modules (SF/CPM, IOM, MDA, cooling fans, air filter and power modules) are hot-swappable, fieldreplaceable units.
Features
The ESS-12 supports the following features: Rack mounted (19 rack);14 RU (24.5) high Slots for up to ten 20 Gb/s IOM cards Two hot-swappable SF/CPM card slots; 400 Gb/s SF/CPM cards available; 400 Gb/s cards have capacity to handle future 40 Gbps IOM cards Up to twenty hot-swappable MDAs Hot-swappable cooling fans Switch fabric/control redundancy when two SF/CPMs installed Power redundancy when two DC power sources connected
1 1 10
7250 Service Access Switch / Telco T5C
7250 SAS
7250 SAS-ES
Telco T5C
1 1 11
7250 Service Access Switch (SAS) / Telco T5C

The Alcatel-Lucent 7520 Service Access Switches (SAS) 7250 SAS, 7250 SAS-ES, 7250 SAS-ESA, and Telco devices support Ethernet and service-aware Ethernet aggregation across IP/MPLS networks. Typically, these devices are connected in rings or trees to 7450 ESSs to distribute L2 VPN or BTV services in VLANs.
Features
The Telco T5C is a third-party switch of which Alcatel-Lucent decided to become a reseller providing for a low-cost solution to fulfill the multi-tenant market. With the Alcatel logo, colors and software notation applied to the switch, this product became known as the Telco T-Metro. The 7250 SAS is a feature-rich customer edge device, purpose-built to increase service-provider revenues and deliver a complete portfolio of Carrier Ethernet services to enterprises. The 7250 SAS is Metro Ethernet Forum (MEF) 9 and MEF 14 certified and supports Multiprotocol Label Switching (MPLS), Ethernet, circuit emulation, and operations, administration and maintenance (OAM) tools. It is managed by the Alcatel-Lucent 5620 Service Aware Manager (SAM). The 7250 SAS, 7250 SAS-ES, and 7250 SAS-ESA can backhaul TDM lines through the core network using two 4port CES modules. A 5620 SAM operator configures a CES module to receive E1 or T1 transmission, and then creates an interface on a logical port in the CES module to enable circuit emulation with dot1q encapsulation. In addition to the functionality of the 7250 SAS, the 7250 SAS-ES and 7250 SAS-ESA also support two additional GigE uplink ports that enable the following features: hierarchical QoS RSVP-TE and FRR MPLS LSR functionality VPLS
OmniSwitch 6400 / 6850 / 6855
OS 6850
OS 6855
OS 6400
1 1 12
OmniSwitch 6850
OmniSwitch 6850 (OS 6850) switches are advanced, stackable, fixed configuration, triple-speed (10/100/1000) family of Ethernet switches. They provide wire rate layer-2 forwarding and layer-3 routing with advanced services. With triple-speed capability, built-in combo ports (four 10/100/1000 and four mini-GBIC) and support for optional wire speed, two ports, 10 Gigabit Ethernet modules. In addition to working as individual, stand-alone switches, OS 6850 Series switches can also be linked together to form a single, high-density virtual chassis known as a stack. Up to eight switches can be stacked. OS 6850 Series switches can be mixed and matched in any combination within the stack. A typical application is the Residential/Metro Triple-Play Ethernet Access networks, which demand userdifferentiated, high-speed Internet, voice and video services support.
Features
The OS 6850 supports the following features: Variety of 24- and 48-port Ethernet chassis that support 10/100/1000, MiniGBIC combo and PoE Ethernet ports Chassis that can be used individually or connected in a stack of up to eight chassis Alarm and Ethernet port statistics SNMP v1, v2, and v3
Note
As of Release 6.0 the 5620 SAM introduced support to the following features [Inserted note] on the OS 6850 Release 6.3.1: back up and restore, VLAN configuration, Security (Radius and TACACS+), OAM ping and traceroute, QoS are supported, as well as being able to start the WebView management tool form the 5620 SAM GUI.
OmniSwitch 6400 / 6850 / 6855 [Cont.]

Switch to notes view! OmniSwitch 6400
The OmniSwitch 6400 (OS 6400) series is a line of Advanced L2 with basic routing GigE fixed configuration stackable LAN switches. Small in size but big in performance, it excels at the enterprise edge and in the SMB core with the industrys most advanced triple-play services, PoE, L2/L3 performance and extensive network security. By providing price performance leadership, advanced QoS and layer-3 features, the OS 6400 fits into customers stackable lineup, it's fast enough to run wide open at the edge, and powerful enough to anchor your SMB core. It enables corporations and small businesses to realize the full potential of their networks. Combined with the 5620 SAM management platform; you have a powerful, easy to manage, cost effective metro access triple-play GigE CPE device.
Features
The OS 6400 supports the following features: Variety of 24- and 48-port Ethernet chassis that support 10/100/1000 and MiniGBIC combo ports Chassis that can be used individually or connected in a stack of up to eight chassis Scalable to 4k VLANs and 16k macs with features such as: QOS, VLAN translation, Q-in-Q, OAM, Private VLANs IPMC VLANs and VoIP VLAN's for a secure, guaranteed triple-play level of service for Service Provider customers alarm and Ethernet port statistics
1 1 13
OmniSwitch 6855
OmniSwitch 6855 (OS 6855) Ethernet Hardened LAN Switch models are industrial grade, managed, Gigabit Ethernet switches designed to operate reliably in harsh electrical and severe temperature environments. This superior, rugged hardware design coupled with the widely deployed and field proven Alcatel-Lucent Operating System (AOS), makes it ideal for industrial and mission-critical applications that require wider operating temperatures, more stringent EMC/EMI requirements and optimized features set for high security, reliability, performance and easy management. The target applications for these versatile LAN switches are power utilities, transportation and traffic control systems, industrial factory floor installations, video surveillance systems and outdoor installations, which all require gigabit backbone connectivity.
Features
The OS 6855 supports the following features: Variety of 14- and 24- Copper with PoE chassis or 10- and 24- fiber port chassis Specially designed for harsh environments Ruggedized hardware design Convection cooling fan-less models
Note
[Inserted note] The 5620 SAM Release 6.1 introduced support to the following features on the OS 6400 Release 6.3.3 and OS 6855 Release 6.3.2: Equipment management; stack configuration; Ethernet port configuration; VLAN service; QoS management; NE maintenance; AAA security; port security; static routing VRRP, OSPFv2, IPv4 multicasting (switching and routing); IGP Snooping; traps and alarms notifications; Ethernet interface statistics; OSSI ; OAM ICMP ping and trace; and full Spanning Tree management
OmniSwitch 9600 / 9700 / 9800
OS 9600
OS 9700
1 1 14
OS 9800
OmniSwitch 9000 Product Family

The Alcatel-Lucent OmniSwitch 9000 product family is comprised of 3 chassis models - the OS9600, OS9700, and OS9800. They are a new generation of feature rich, high value switches for use in the enterprise network core, data center, aggregation layer, and wiring closet where power and security are critical. The OS9000 switch family address today's network needs with a larger switching capacity, high availability and performance, higher 10GigE port densities to support next generation network backbone migrations, multi-layer security with 802.1x, and IPv6 to meet corporate and emerging, government requirements.
OMNI 9600
The OmniSwitch 9600 (OS9600) is the smallest chassis of the award winning OmniSwitch 9000 product family. The OS9600 is ideal for the aggregation tier of a 3 tier enterprise network and the wiring closet where support for converged applications and PoE is a requirement. The OS9600 delivers industry leading quality of service (QoS) for multi-media applications and voice-over-IP (VoIP), wire-rate first packet, multi-layer security with 802.1x, and native IPv4 & IPv6.
Features
The OS 9600 is a five-slot chassis supporting one CMM and four network interface modules. It offers a wide range of GigE and 10GigE interfaces and power-over-Ethernet to support IP telephones, WLAN access points and video cameras. The OS9600 supports a maximum of two load sharing power supplies.
OmniSwitch 9600 / 9700 / 9800 [Cont.]

Switch to notes view! OmniSwitch 9700
The OmniSwitch 9700 (OS 9700) is a high-density, 10 slot chassis. Two center slots are dedicated to chassis management modules (CMMs) allowing redundant configurations, and 8 slots for network interfaces. The OS9700 is engineered to be deployed in the core, data center, aggregation layer, or wiring closet, and was recently named as Network Computing's Editor's Choice for its superb manageability and ease of use.
Features
The OS9700 is a high-density ten-slot chassis with two slots for control and eight slots for network interfaces supporting an aggregation of up to 192 GigE ports or 48 10GigE ports. Designed for smart continuous switching operation, the two center slots are dedicated to CMMs allowing redundant configurations. The OS9700 supports a maximum of three power supplies.
OmniSwitch 9800
The Alcatel-Lucent OmniSwitch 9800 model is an 18-slot chassis supporting two chassis management modules (CMMs) and 16 network interface (NI) modules. The OS9800 allows up to 96 10-Gigabit Ethernet ports, making it ideal for a larger enterprise network core and providing enough capability and connectivity to eliminate the need for an aggregation tier. The PoE Gigabit Ethernet module, which is ideal for a converged network because its power-over-Ethernet capability, supports IP phones and other IP devices at true wire-rate speeds.
Features
1 1 15
The5620 SAM 5620 SAM (Service Awareperformance 18-slot switch supporting 16 slots for Gigabit Ethernet and/or 10-Gigabit OS9800 is a high Manager) R7.0 Operator Ethernet network interface modules. An additional two slots are reserved for primary and redundant CMMs. The OmniSwitch 9800 supports a maximum of four power supplies.
Product Overview Alcatel-Lucent IP Products Overview
Note
[Inserted note]
The 5620 SAM R7.0 introduces support to the OS9600, OS9700 and OS9800 Release 6.3.1 R2 or later. OmniSwitches do not support automatic synchronization with the 5620 SAM database when you use the CLI to make configuration changes. To ensure that you are viewing accurate configuration information using the 5620 SAM, perform a database synchronization by clicking on the appropriate Resync button.
7210 Service Access Switch - Ethernet
7210 SAS-E
1 1 16
The Alcatel-Lucent 7210 Service Access Switch Ethernet (SAS-E) is designed as a Carrier Ethernet customer edge device, which is owned and managed by the service provider. Using software based on the SROS and managed by the 5620 SAM, the 7210 SAS-E extends Carrier Ethernet VPN services to the customer edge. The 7210 SAS-E can also be deployed as an aggregation device for smaller sites.
Features
7210 SAS-E: 12 x 100/1000 GigE (SFP) and 12 x 10/100/1000Base-T wire speed, service-aware Ethernet switch in-band management only Epipe and VPLS supported; IES supported only for in-band management Ethernet ports, access and uplink modes Powered by SR OS for feature-rich Carrier Ethernet VPN services with per-service QoS and OAM Ethernet features include IEEE 802.1Q and QinQ (stacked VLAN IDs) static routes for in-band management static and dynamic LAGs backup and restore software upgrade statistics collection Alarm management. Provides 6 dry contacts to monitor 4 alarm inputs and 2 alarm outputs through a DB15 interface on the front panel Hot-swappable, redundant, load sharing AC or DC power and fan modules
9500 Microwave Packet Radio
9500 MPR
1 1 17
The Alcatel-Lucent 9500 MPR is a microwave digital radio that supports PDH and Ethernet to migrate from TDM to IP. The 9500 MPR provides a generic, modular IP platform for multiple network applications, such as 2G, 3G, HSDPA, and WiMAX to accommodate broadband services. The 9500 MPR supports: 4 and 8-slot MSS shelves removable core-enhanced, radio modem, 32 x DS1/E1, and cooling fan cards ODUs
MSS-4 and MSS-8 shelves

Slots 1 and 2 are reserved for core-enhanced cards. Each shelf must have a core-enhanced card installed in slot 1 and may have an optional spare card installed in slot 2 to protect the main card. The MSS-4 shelf supports cards in slots 3 and 4. The card slots can be used for unprotected radio modem or 32 x DS1/ E1 cards or a card in slot 3 can be protected by an identical card in slot 4. The MSS-8 shelf supports six additional card slots. The slots support any combination of unprotected radio modem or 32 x DS1/E1 cards, or a combination of protected and unprotected cards. Protected cards must be installed in slots 3, 5, or 7 and are protected by optional identical cards in slots 4, 6, and 8 respectively.
9500 Microwave Packet Radio [Cont.]

Switch Features to notes view!
The multi-service aggregation layer feature aggregates and carries over a common packet layer: TDM 2G, 3G and IP/Ethernet This allows sharing a common packet transmission infrastructures, regardless of the nature of carried traffic. Mapping over Ethernet different access technologies is achieved by standardized protocols like circuit-emulation and pseudo-wire Thanks to the Service Awareness feature, different end users services data flows are treat according to their QoS requirements while with TDM products there is no possibility to differentiate services with different QoS requirements The 9500 MPR is a packet node meaning that it is on a single packet matrix with high switching capacity thanks to the common aggregation layer over ETH (>10 Gbs) The Service-Driven Packet Adaptive Modulation allows it to fully exploit the air bandwidth by changing modulation scheme according to the propagation condition, associating with the different services quality the available transport capacity
1 1 18
Questions
?
1 1 19
1. How many MDAs can an SR-12 accommodate? a. 10 b. 12 c. 20 d. 24 2. Which 7750 SR versions support redundant switch fabrics? a. SR-1 and SR-12 b. All versions c. SR-7 and SR-12 3. Which 7450 ESS versions support redundant switch fabrics? a. ESS-1 b. ESS-6, 7 and 12 c. All versions 4. How many CMAs can a 7710 SR accommodate? a. 4 b. 8 c. 10 d. 12 5. The maximum bandwidth of the 7710 SR is: a. 7 Gb/s b. 10 GB/s c. 20 Gb/s
Answers
1. How many MDAs can an SR-12 accommodate?
a. 10 b. 12 c. 20 d. 24
2. Which 7750 SR versions support redundant switch fabrics?

a. SR-1 and SR-12 b. All versions c. SR-7 and SR-12
3. Which 7450 ESS versions support redundant switch fabrics?

a. ESS-1 b. ESS-6, 7 and 12 c. All versions
4. How many CMAs can a 7710 SR accommodate?

a. 4 b. 8 1 20 1 c. 10 d. 12
5. The maximum bandwidth of the 7710 SR is:

a. 7 Gb/s b. 10 GB/s c. 20 Gb/s
End of Module Alcatel-Lucent IP Products Overview
1 1 21
Last Blank Page

1 1 22
12
Section 1 Product Overview

Module 2 5620 SAM Overview
TOS36013_01_02 Issue 1.1
Blank Page
122
Product Overview 5620 SAM Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Upon completion of this module, you will be familiar with:
The function of the Alcatel-Lucent 5620 SAM The main features of the Alcatel-Lucent 5620 SAM

Identify the components of SAM modularity Describe the function of each module
123
5620 SAM Overview

Supports IP/MPLS based network convergence by providing subscriber services over a common infrastructure Extensive use of open standards, such as:
SOAP (Simple Object Access Protocol) XML (Extensible Markup Language) Java
Enables network management at the service and customer levels Extensive fault management and troubleshooting tools
124
5620 SAM Platform Types
GUI Client
Server
IP IP
GUI Client Delegate Database
Auxiliary Statistics Collector
125
Five types of platforms can be present in a 5620 SAM Release 7.0 deployment: 5620 SAM Server 5620 SAM Database 5620 SAM Graphic User Interface (GUI) Client Workstation(s) 5620 SAM GUI Client Delegate Workstation(s) 5620 SAM Auxiliary Statistics Collector
The 5620 SAM Auxiliary Statistics Collector workstation can be installed on an independent workstation to reduce the burden of statistics handling from the 5620 SAM Server. Up to two 5620 SAM Auxiliary workstations can be installed to ensure that there is redundancy, but only one Auxiliary will be actively collecting statistics at any given time. The 5620 SAM GUI Client Delegate Workstation(s) option enables customers to launch multiple 5620 SAM GUI Clients from a single Solaris workstation.
5620 SAM Server
Java-based network management processing engine Includes:

application server web server protocol stack database adaptor
Supported on Solaris and Microsoft Windows platforms Server
126
The 5620 SAM Server is a network management processing engine, which is written in Java and runs on the Sun Solaris or Microsoft Windows platforms. The server includes several third-party components, such as an application server, web server, protocol stack set, and database adaptor. The 5620 SAM Server functionality can be distributed across multiple physical platforms in a standalone or redundant 5620 SAM configuration. The 5620 SAM Server in a cluster is the network-management engine that processes GUI and OSS client requests and monitors the network elements. The 5620 SAM Server Release 7.0 is supported on Solaris 10 01/06 (and higher). The Solaris support of the 5620 SAM Release 7.0 is applicable to SPARC and AMD platforms provided by Sun Microsystems only. The 5620 SAM Server Release 7.0 is supported on the following 32-bit versions of Microsoft Windows: Windows 2000 Windows 2003 Windows XP Professional Edition 64-bit versions of the Windows operating systems are not supported at this time. The 5620 SAM Server and 5620 SAM Database platforms are supported on the Microsoft Windows operating systems, but are only advisable for a lab deployment. The network being managed must not exceed either of the following dimensions: 50 MDAs and 3 clients (GUI or OSS) 30 MDAs and 5 clients (GUI or OSS) The Solaris operating system should be used in situations where network growth is expected.
5620 SAM Database
Customized Oracle database Provides persistent storage of network data Supported on Solaris and Microsoft Windows platforms
Database
127
The 5620 SAM Database is a customized Oracle relational database that provides persistent storage for the network data. The 5620 SAM Database Release 7.0 is supported on Solaris 10 01/06 (and higher). The Solaris support of the 5620 SAM Release 7.0 is applicable to SPARC and AMD platforms provided by Sun Microsystems only. 5620 SAM Release 7.0 supports a distributed deployment, whereby the 5620 SAM Server and the 5620 SAM Database software components are installed on two different Solaris workstations. In such case, the database must runs on the same platform as the 5620 SAM server software. The 5620 SAM Database Release 7.0 is supported on the following 32-bit versions of Microsoft Windows: Windows 2000 Windows 2003 Windows XP Professional Edition 64-bit versions of the Windows operating systems are not supported at this time.
5620 SAM GUI Client
Operational Support Systems (OSS) applications or Java-based 5620 SAM GUIs May be installed on workstations running different operating systems from the 5620 SAM Server and 5620 SAM Database Supported on Solaris and Microsoft Windows platforms GUI Client
128
The 5620 SAM GUI Client Workstation(s) are Operational Support Systems (OSS) applications or Java-based 5620 SAM GUIs. The 5620 SAM GUI Client software may be installed on workstations running different operating systems from the 5620 SAM Server and 5620 SAM Database. For example, the 5620 SAM Server, 5620 SAM Auxiliary and 5620 SAM Database software can be installed on Sun AMD or SPARC based Solaris workstations while the 5620 SAM Clients are installed on a Windows platform. The 5620 SAM Client can be installed on Solaris or Windows. The 5620 SAM GUI Client Release 7.0 is supported on Solaris 10 01/06 (and higher). The Solaris support of the 5620 SAM Release 7.0 is applicable to SPARC and AMD platforms provided by Sun Microsystems only. The 5620 SAM GUI Client Release 7.0 is supported on the following 32-bit versions of Microsoft Windows: Windows 2000 Windows 2003 Windows XP Professional Edition Windows Vista Business/Enterprise and Ultimate 64-bit versions of the Windows operating systems are not supported at this time.
Note
[Inserted Note] As previously alerted, as of Release 7.0 5620 SAM Client support for Red Hat Linux support has been removed.
5620 SAM GUI Client Delegate

SAM Server db Client Delegate IP IP
Managed Network
Client
129
Central server for access to GUI client Simplified client software upgrade Separate GUI client install for each user
As of Release 4.0, the 5620 SAM introduced support for a Client Delegate platform. This option enables customers to launch multiple 5620 SAM GUI Clients from a single Solaris workstation. These GUI clients can be displayed using the X11 protocol to other Solaris desktops or native X displays. Displaying GUI clients to computers running X-emulation software is not currently supported. The Client Delegate platform provides an option to consolidate multiple installations of the 5620 SAM GUI Client on a single Solaris workstation. Individual 5620 SAM Clients can be installed on the Client Delegate Platform. In Release 7.0, 5620 SAM Client also supports the ability for multiple users to share a single installation; however, each user must run the client with a unique UNIX Id. Please note that on computers running Windows, only one instance of a 5620 SAM GUI Client can be running at any given time.
5620 SAM Auxiliary

SAM Server
SAM Auxiliary
db
extends network-management processing supported in UNIX environment only
Managed Network
currently used for statistics collection and Service Test Manager (STM) 5620 SAM Server Cluster - Main and Auxiliary Server together
1 2 10
Product Overview 5620 SAM Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
5620 SAM Release 5.0 introduced the concept of the 5620 SAM Auxiliary Statistics Collector also known as the 5620 SAM Auxiliary. The 5620 SAM Auxiliary collects and processes performance and accounting statistics. This option enables customers to reduce the load of statistics collection from the 5620 SAM Server while allowing for increased statistics collection capabilities. A 5620 SAM Auxiliary workstation should be used when statistics collection is expected to exceed the capacity of the 5620 SAM Server.
Technical Reference
See 5620 SAM R7.0Technical Guide Section 6. Hardware Platform [Inserted Planning Reference] Requirements for scalability details of the 5620 SAM Server and dimensioning of the 5620 SAM Auxiliary workstation. The 5620 SAM Server directs the operation of the 5620 SAM Auxiliary and distributes the processing load to them as required. This distributed functionality is invisible to 5620 SAM GUI and OSS clients because they interact only with the 5620 SAM Server. The 5620 SAM Server sends new or updated operating information, for example, the 5620 SAM license capacity, redundancy status, and database credentials, to each auxiliary server as the information becomes available. The 5620 SAM Server and the 5620 SAM Auxiliary workstation must maintain consistent and accurate time. It is encouraged to use an NTP service to achieve this. An alarm will be raised if the times are not within 30 seconds. Variations in time can cause the system to stop collecting statistics prematurely. In networks where 5620 SAM Auxiliary workstations are not configured, the 5620 SAM Server handles the statistics collection. In networks where the 5620 SAM Auxiliary is configured, the 5620 SAM Server will never collect statistics regardless of the availability of the 5620 SAM Auxiliary workstations. At least one 5620 SAM Auxiliary workstations must be available for statistics collection to occur.
5620 SAM Auxiliary [Cont.]

The 5620 SAM Auxiliary is only supported with a distributed 5620 SAM Server and 5620 SAM Database. The Switch to notes view! 5620 SAM Server and database platforms must be running Solaris on either a Sun SPARC or Sun AMD platform. 5620 SAM Auxiliary Server: In a 5620 SAM system that is deployed using distributed server architecture, a 5620 SAM server instance on a dedicated station that accepts processing requests from, and is directed by, a 5620 SAM main server. A main server and one or more auxiliary servers that are in communication are collectively called a 5620 SAM server cluster. 5620 SAM Main Server: A server instance in the 5620 SAM distributed server architecture that directs one or more 5620 SAM auxiliary servers and interacts with 5620 SAM clients. The term is meaningful only in the context of a distributed 5620 SAM server deployment; the term 5620 SAM server applies to a single server instance in a non-distributed 5620 SAM deployment. A main server and one or more auxiliary servers that are in communication are collectively called a 5620 SAM server cluster.
1 2 11
Redundancy
Active
Standby
IP
7450
7450 7750
Automatic transfer of network data to Standby Protects against:

software failure hardware failure connectivity problems
7450 7450 7750 7750
1 2 12
High Availability (Redundancy)

Fault tolerance is important in carrier networks to provide the reliability expected by customers and to maintain system availability even under failure conditions. This is achieved on the 5620 SAM using software and hardware redundancy. The 5620 SAM duplicates both server and database hardware and software and monitors active and backup components to ensure automatic recovery from failure. The 5620 SAM protects the server from any point of failure in the server or database software or the server and database hardware platform, and from connectivity problems that isolate a server from the network. Duplication of the network connection to the 5620 SAM server can also be achieved using the in-band and out-of-band management connections to protect against problems in the link between the server and the managed network.
Architecture Overview
The 5620 SAM supports IP/MPLS-based network convergence by providing subscriber services such as VLL, Switch to notes view! VPLS, VPRN, IES, and VLAN over a common network infrastructure. The 5620 SAM allows network operators to manage their networks at the service, customer, and subscriber levels. The 5620 SAM software architecture is built on industry standards including open standards such as SOAP and XML, the Java and J2EE framework, multi-tier layering, and web service interfaces. This use of standard interfaces allows the 5620 SAM to integrate with other network management systems such as the 5620 NM and the 5750 SSC, to add management of IP/MPLS and metro Ethernet services to multiservice networks.
Benefits
Open standards, and the multi-tier and web service models provide many benefits. Open standards are widely used. Their inclusion in 5620 SAM promotes interoperability with other systems. The large industry knowledge base of developers also means that more resources are available to create new services The multi-tier model packages functionality in separate, well-defined elements that can be coded quickly, easily maintained, and combined with different vendor product components. The scope of system changes are contained within components, which provides flexibility for future growth. To improve performance and scalability, different components can be spread over multiple processors or duplicated for multiprocessor execution. Web services are created when applications export their XML interfaces over the web, which allow remote components, including web portals, to Reserved Alcatel-Lucent 2009 access the services. The XML access to 5620 SAM All Rights 1 2 13 functionality allows third-party vendors to create customized windows into 5620 SAM services. Product Overview 5620 SAM Overview
Network Management Capabilities

The 5620 SAM network manager provides flexible network access, thereby allowing users to interact with the network on a service or subscriber basis, or at the level of individual devices. The ability of the 5620 SAM to link subscribers, customers, services, equipment, and faults allows efficient management of complex networks by simplifying daily operations. The 5620 SAM provides this flexible capability by creating a data model of the network with relationships between subscribers, services, and equipment. The server collects data and traps from managed devices, and can correlate the data to allow billing, performance monitoring, troubleshooting, and inventory and alarm reporting at the service or subscriber level. The server also deploys user commands to the network, and performs autonomous functions such as node discovery and backups.
Redundancy and 5620 SAM Auxiliary Workstations

5620 SAM Clients
Geographic Location A
5620 SAM Database Active Oracle DataGuard
Geographic Location B
5620 SAM Database Standby
5620 SAM Server Active
5620 SAM Server Standby
5620 SAM Auxiliary Preferred for the Active Server Reserved for the Standby Server
5620 SAM Auxiliary Preferred for the Standby Server Reserved for the Active Server
Managed Network
1 2 14
In customer networks where the statistics collection requirements exceed the scalability capabilities of a 5620. SAM Server, a 5620 SAM Auxiliary Statistics Collector can be used. As with other high availability components, 5620 SAM Auxiliary can be configured to be redundant. Each 5620 SAM Server can be configured to have one preferred and one reserved 5620 SAM Auxiliary. In the figure above, there are 2 workstations that are configured as 5620 SAM Auxiliary workstations. The role of the 5620 SAM Auxiliary is dependant and configured on the 5620 SAM Server that is active. In both geographic locations, the 5620 SAM Server would consider the 5620 SAM Auxiliary in its geographic location to be the preferred. The 5620 SAM Auxiliary in the opposite geographic location would be considered to be reserved. In this scenario, if the 5620 SAM Auxiliary for the active 5620 SAM Server were to no longer be available, the active 5620 SAM Server would use the reserved 5620 SAM Auxiliary in the opposite geographic location to collect statistics.
SAM Modularity
SAM-E
Element Management
SAM-P
Provisioning Management
SAM-A
Assurance Management
SAM-O
OSS Management
1 2 15
SAM-E (Element Management)
CLI access to managed devices
Equipment Management & Navigation
Alarm Policy management
Real-time equipment statistics
1 2 16
The SAM-E module is the basic component of the 5620 SAM and is required for all other modules to function.
Functions
The SAM-E module provides: CLI access to managed devices device mediation, equipment management and navigation alarm policy management real-time equipment statistics security backup and restore, and inventory and reporting
SAM-P (Provisioning Management)
Protocol Management
Network Tunnel and Path Management
Service Provisioning
Customer Management
1 2 17
The SAM-P module is an optional component of the 5620 SAM and provides functions that deal with service provisioning.
Functions
The SAM-P module provides: network protocol configuration and management network tunnel and path management subscriber management policy management, and templates
SAM-A (Assurance Management)

Fault Correlation using alarms
Topology Views
P i ng
OAM troubleshooting tools Statistics and Accounting Policies & Data
1 2 18
The SAM-A module is an optional module of the 5620 SAM and provides service assurance functions.
Functions
The SAM-A module provides: topology views fault correlation using alarms OAM tools statistics policies and data, and accounting policies and data
SAM-O (Operating Support System OSS Interface)
OSS Applications
XML interface
Server
SOAP encoding
HTTP
HTTPS
1 2 19
The SAM-O module is an optional module of the 5620 SAM and provides Open Socket service interface using XML. The SAM-O application key permits network operations staff access to all four components of the SAM. An OSS application uses the Alcatel 5620 SAM Open Interfaces XML interface to configure or access network management information contained in the 5620 SAM database. The XML interface can then receive information from or manipulate the managed object model. All transactions with the 5620 SAM database are processed by the 5620 SAM server.
Function
The 5620 SAM-O XML interface allows OSS users to: access all 5620 SAM FCAPS function for read only, or read and write methods ensure backward compatibility access functions using HTTP or HTTPS and simple SOAP encoding, and transport requests and receive responses securely
5620 SAM Release 7.0 Scalability Limits

Attribute of Managed Network Maximum number of managed MDAs Maximum number of managed services Maximum number of SAPs Maximum number of simultaneous 5620 SAM GUI Maximum number of simultaneous active 5620 SAM-O applications Maximum number of outstanding alarms Maximum number of GNEs Maximum number of 7705s Distributed Configuration 16,000 1,000,000 5,000,000 100 10 50,000 15,000 7,000
1 2 20
5620 SAM Release 7.0 uses the number of MDAs as the fundamental unit of network dimensioning. To determine the current or eventual size of a network, the number of deployed or expected MDAs, as opposed to the capacity of each router, must be calculated. The table above provides the scalability limits for 5620 SAM Release 7.0. To achieve these scale limits, a distributed Solaris configuration is required, and may also require a 5620 SAM Auxiliary Statistics Collector and a storage array for the 5620 SAM database workstation. Consult Alcatel-Lucent personnel to ensure you have the correct hardware platform and configuration for your network size. For networks which contain, or are expected to contain, 7250 SAS or Telco T5C CLE equipment, the number of managed MDAs can be obtained by adding 2 MDAs for each 7250 SAS or Telco T5C elements in the network to the current or expected number of MDAs on 7750 SR routers and 7450 ESS switches. For OmniSwitch 6850, each shelf in the stackable chassis is equivalent to 1 MDA for scaling guidelines.
Technical Reference
See Alcatel-Lucent 5620 SAM Planning Guide, Release 7.0, Section 6 - Hardware Platform Requirements for information on identifying the correct hardware platform for a particular network configuration. Contact your Alcatel-Lucent representative for more information on hardware planning requirements and scalability limits.
SAM Integration and Control
7750 7705 7450 7250 OS 6850
7710 7250
7250
7450 7750 7750 7450

1 2 21
The 5620 SAM simplifies network provisioning by allowing you to discover devices and reconcile them to the 5620 SAM database for management. Network element discovery is executed via SNMP. During the discovery process, the 5620 SAM scans the network for devices according to user-defined IP addresses or IP address ranges. When the IP address used to discover the device is the system IP address, also known as the system ID, management is considered in-band. When the IP address used to discover the device is the IP address of the device management port, management is considered out-of-band. When a device is discovered, the 5620 SAM sets the device in a managed state and reconciles device elements into the 5620 SAM database. To discover devices, you use the Discovery Manager to create one or more discovery rules, choose a discovery rule, and scan the network as specified by the rule. Discovery rules contain rule elements. Rule elements specify which devices or subnets are to be included in or excluded from the discovery process. A discovery rule can contain more than one rule element. For example, you can configure one rule element to discover a subnet, and configure another rule element to exclude specific IP addresses from the subnet.
Equipment Management
Navigation Tree
Properties Window
Node
Group
1 2 22
Physical equipment is: discovered and the 5620 SAM database is initially populated resynchronized with the 5620 SAM database and the content of the database is matched with the content of the physical device database, and configured when clients send requests to add new equipment or change existing equipment The server makes the appropriate changes to the data model and deploys the updates on the relevant nodes. For example, when a card is added to a node, the server data model is updated, and the card configuration commands are sent to the node. Network configuration is supported for Multi-protocol Label Switching (MPLS), Label Switched Paths (LSPs), and service tunnels, as well as routing protocols such as Routing Information Protocol (RIP), Border Gateway Protocol (BGP), and Intermediate System to Intermediate System (IS-IS). These configurations are requested by clients and deployed to the network. New nodes can be discovered by a user request or automatically through server polls. When a new node is discovered, it is added to the data model and set to a managed state.
Generic Network Element (GNE)

Sun Microsystems
Non-SAM SNMP managed devices Management limited to monitoring node and port status Telnet, FTP, SSH, CLI and scripting possible
7670 RSP
7x50 Network
1 2 23
7670 RSP
7670 RSP 7x50 Network
As of Release 4.0, the 5620 SAM made possible for network designers to expand the integration of network elements into the remotely managed network through the introduction of Generic Network Elements. Generic Network Elements, also referred to as Generic NE or GNE, are any SNMP- manageable device other than the 7710 or 7x50 series of routers and switches (e.g., Sun Workstation, Alcatel-Lucent 7670 RSP, Alcatel-Lucent 7470 MSP, Cisco router, Juniper router). The 5620 SAM provides limited management of GNEs which includes: the ability to plot the GNE, create physical links to the device, monitor the device status (up or down), perform direct cut-through for telnet/ SSH, and to send CLI scripts to the Generic NE. There are three (3) main steps to discover then manage a Generic NE: create a Generic NE Profile for each device to be managed create a Mediation Security Policy for the specific nodes to be managed, and create a Discovery Rule that will be used to discover the node(s)
Script Management
CLI script management to view or change node configuration Any managed device (SAM managed or GNE)
Active
7705 7450
7450 7750 7710 7450 7450 7750 7750
1 2 24
As of Release 4.0, the 5620 SAM introduced the ability for network operations staff to configure selected network devices and view configuration information through CLI command scripts. Script management can be used to: create, configure, and test script instances to manage Alcatel and generic NEs view and compare versions of CLI command scripts preview scripts start and stop the execution of scripts associated with managed NEs, and view, compare, and store the results of executions of individual and multiple script instances Access to the script manager is controlled by user account privileges. Users with admin privileges can create, modify, delete, and execute scripts. Users with script execution privileges can view and run scripts, view and save results, configure script targets, and view historical results.
Fault Management
Dynamic Alarm List
7450
Fault Window
7450 7750
7450 7450 7750 7750
1 2 25
Fault management occurs in response to traps triggered in the managed network. SNMP traps are sent to the 5620 SAM server, which converts them to status updates and alarms against the appropriate equipment and services. Traps include hardware faults on equipment. Traps may be sent for many reasons; for example, managed device configuration or operational state changes, or security breach attempts. These traps are passed to clients immediately if they have registered for a JMS event channel, or later when a client polls the server. The fault management system provides: conversion of SNMP traps of device events to many X.733-ISO Standard alarm fields (Critical, Major, Minor, Warning, Intermediate, Cleared) impact analysis and correlation of alarms to equipment and serviceaffecting faults updated operational status of equipment, services, and interfaces in near-real-time from the network device resources alarm policy control by network administrators so the administrators can determine how to handle individual incoming alarms and how alarm logs are created and stored point-and-click alarm management from both the dynamic alarm list and from equipment and services configured on the 5620 SAM GUI operator notes and acknowledgement to track the work undertaken to fix the problem that caused the alarm, and correlated data in a historical alarm database to provide trend analysis and records
Configuration Management
MPLS Configuration
OSPF IS-IS RIP Static Routes BGP
7450
7450 7750
7450 7450 7750 7750
Service Configuration
1 2 26
The network management capabilities of the 5620 SAM allow network operations staff to provision the Internal Gateway Protocols (IGP), including: static routes, RIP, Open Shortest path First v2 (OSPFv2) , OSPFv3 and IS-IS, as well as the BGP (Border Gateway Protocol) used for L3 VPN (VPRN) services. The MPLS network can then be tracked for performance monitoring, billing, inventory, reporting, and alarms. Network Operations staff can track the managed network data from SNMP traps, billing and traffic analysis data, and SNMP MIB performance data. The data is rolled-up and correlated using the data model and business logic on the server.
MPLS Management
The MPLS management capabilities of the 5620 SAM allow network operations staff to provision the MPLS network including: static and dynamic Label Switched Paths (LSPs) to support services for subscribers. The MPLS network can then be tracked for performance monitoring, billing, inventory, reporting, and alarms.
Service Management
The service management capabilities of the 5620 SAM allow network operations staff to provision VLL, VPLS, IES, VPRN, or VLAN services for subscribers. These service networks can then be tracked for performance monitoring, billing, inventory, reporting, and alarms. Network Operations staff can track the managed network data from SNMP traps, billing and traffic analysis data, and SNMP MIB performance data. The data is rolled-up and correlated using the data model and business logic on the server.
Service Templates
Reduces number of steps required to create a service Defines common characteristics and parameters that must be changed Uses secondary templates to define configuration details
7450
Service Configuration
7450 7750
7450 7450 7750 7750
1 2 27
Overview
The 5620 SAM supports the configuration of VLL, VPLS, IES, VLAN, mirror, and VPRN services using XML API script-based templates. The templates allow users to define common characteristics for a service or templatable service object, and the parameter values that can be configured. Only users who are assigned the mirror service management scope of command role can create, modify, delete, or view mirror services and mirror service templates. Only users that are assigned the template management scope of command role can create, modify, or delete XML API templates. Users can create XML API configuration templates for services and child objects of services, and include sites, access interfaces, SDP bindings, group interfaces, and other service-related objects. The 5620 SAM generates an XML API script with Velocity properties which must be modified to generate a UI for the configuration form that is tailored to the users requirements and to NE-specific properties and attributes. Service templates in the 5620 SAM, as of Release 6.0, are based on XML API configuration scripts. XML API service configuration templates simplify service object creation by reducing the number of steps required to create a service or service component. Users can use an existing valid service as a starting point for the creation of an XML API service configuration template or create a template without using a managed service object as a basis.
Service Templates [Cont.]

Manage Service Templates Service Templates Form
1 2 28
Users can create, modify, or delete XML API service configuration templates using the form accessed by selecting Manage Service Templates. The form allows one to view all templates for services, sites, and templatable children network objects. Users can also use the form to convert standard service templates that were created in earlier releases to XML API service templates. A service template can use secondary, or child, templates to further define the configuration details for the created service. Templates for sites can be bound to the service template. Network objects, such as SDP bindings and interfaces, are considered child templates which can be bound to the site template. Unlike in previous releases, only site templates can be bound to service templates. When a user creates an XML API configuration template for a service, one can choose to create templates for child objects of the service and to bind the child templates to the service template. Users can bind a child template to multiple parent templates. For example, a site template can be bound to several service templates. Users must convert standard service templates that were created using Release 5.0 and earlier of the 5620 SAM to XML API service templates. All the child templates that are bound to the service templates are automatically converted when the service template is converted to an XML API configuration template. The association of the service template with service objects that may have been created using the template in Release 5.0 and earlier of the 5620 SAM is maintained after the service template has been converted. Since the 5620 SAM, Release 5.0 and earlier, does not support an association between site templates, SDP binding templates, or access interface templates with network objects that were created from the templates, no association is maintained after the conversion. Alcatel-Lucent recommends that users convert old service templates to XML API configuration template only one time. If a template is converted that has already been converted, a new template is generated. However, the association of templated objects such as serviceswith the original template is removed and associated with the newly converted template.
Velocity GUI Builder

GUI Builder Selection Button
1 2 29
The Velocity GUI Builder allows users to easily create the XML content for the velocity properties. It allows the user to specify all property types and configure them through a GUI. The builder is opened through the script editor, and can be used to create or edit the velocity properties, or test the generated UI. Under the versions tab of a script, select Add to create the script. A button is available in the script editor to launch the GUI builder. As part of the Service Templates capabilities of the 5620 SAM Release 6.0, the GUI Builder allows GUI based locking, default setting and bounds setting extends service template philosophy to general templates. It provides support for output format scripts greatly improving the potential look and feel of customer scripts.
Policy Management
Access ingress Network Policy ACL IP filter Access buffer
Access egress Scheduler Service Mgt. Policies MAC IP filter Network buffer
Alarm Mediation
File
Accounting Network Mgt. Policies Poller
Routing Policy
Routing Mgt. Policies
1 2 30
The 5620 SAM provides the capability for extensive policy management grouped into three main categories: Service Management Policies, Routing management Policies and Network Management Policies. This feature provides the network operator or administrator the ability to create up to 131,000 management policies from the 5620 SAM to be applied to the network elements, as required. Policies created in the 5620 SAM are referred to as Global policies. Once a Global Policy is assigned to an object on a network element, the configuration of that policy will be deployed to the device and is referred to as a Local policy.
Synchronize
Should an operator make changes to a local policy via CLI, the modifications will not result in a change to the Global Policy. Instead, a warning will be raised on the modified Local policy at which time the network operator or administrator may initiate a policy synchronization. The Synchronize button will trigger a synchronization of the global policy with the selected local policy. Modification of a Global Policy configuration via the 5620 SAM shall result in an updates in upgrades to the configuration of all corresponding Local policies and thus an update to the configuration of those policies on the associated network elements.
Policy Audit
The Policy Audit is used to compare every Local policy with the corresponding Global policy. Alarms will be raised on the Local policy to indicate a mismatch.
Accounting and Performance

Queue Queue 7450
7450 7750
$
7450
Billing information
7450 Queue Queue 7750
7750
1 2 31
The 5620 SAM provides the capability to monitor services and resources using performance monitoring statistics, alarms, and diagnostic and troubleshooting tools. Performance monitoring and accounting statistics collection are performed on the 5620 SAM using serviceand equipment-related statistics counters from the managed devices. There are two types of statistics collected: accounting statistics for SAPs (Service Access Points), SDPs (Service Distribution Paths) and network ports which can be used for billing and traffic-analysis purposes, and network object performance statistics, for control plane, data forwarding plane, and device utilization statistics Performance statistics are collected regularly by server polls of the managed devices. Changes to network performance statistics, which are in MIB format on the managed devices, are uploaded to the server using SNMP.
Accounting
Accounting statistics for billing records and traffic analysis are generated and stored on the managed devices. They are collected and transferred to the 5620 SAM server using FTP or Secure Copy Protocol (SCP).
Diagnostics
7750
Customer
7450 7450
Sniffer
7450 7750 Legend Service Traffic Mirror Traffic 7750
Customer
Extensive OAM tools to troubleshoot infrastructure and service related problems Service mirroring for network and traffic analysis
1 2 32
The 5620 SAM provides network operations staff with an extensive suite of diagnostic tools for fault analysis and localization. These tools include Medium Access Control (MAC) ping, Virtual Circuit Connection Verification (VCCV) ping for Virtual Leased Line (VLL) services, Domain Name System (DNS) ping for name resolution, LSP ping and traceroute, and Virtual Private Routed Network (VPRN) ping. Connectivity tests can be made on SDPs and SDP bindings, and service connectivity tests can ensure service functionality at configuration time. Pinging of management IP addresses can determine when managed devices become unreachable from the server. Service mirroring enables the network diagnostics staff to redirect data from any service within the network to a centralized monitoring point for network and data analysis without impacting customer data flow. This service can be configured to filter data based upon L2 to L7(1) information.
Note
(1)
An Application Assurance (AA) MDA is required to filter at L7.
Service Test Manager

7750
Tests to be performed lsp-ping lsp-trace 2 1 tunnel_ping mtu_ping
Object under test LSP 1 LSP 2 LSP 3 Tunnel 1 Tunnel 2 Tunnel 3
7750
3
7750 7750
Group of OAM Tests Execute consecutively or concurrently Can be scheduled for multiple OAM test against multiple objects Can be configured with threshold-crossing alarms
1 2 33
The 5620 SAM Service Test Manager (STM) system provides the ability to group various OAM tests into test suites for network troubleshooting and for verifying compliance with SLAs. You can schedule the execution of a test suite to provide continual performance feedback, or run a test suite on demand to investigate service issues. The 5620 SAM archives test-result data for monitoring and trend analysis. The grouping of tests into a test suite allows a 5620 SAM operator to use one schedule for the periodic execution of multiple OAM diagnostics against multiple network objects; for example, services, devices, or network transport components. An operator can choose to include existing tests, use the 5620 SAM to generate the tests that comprise a test suite, or both. Groups of tests in a suite can be configured to execute sequentially or concurrently. Threshold-crossing parameters can be configured to generate alarms when rising or falling threshold values are reached due to the reach, latency, or jitter issues discovered by the OAM tests.
Access Management
Client Account Type admin unknown operator Access Yes No Yes
User 1
User 1 User 2 User 3
User 2
x
7450
7450
User 3
7750
b
7450 7450 7750 7750
1 2 34
The 5620 SAM provides for data protection through various means, one of which is access management. Network operations staff is provided access to the 5620 SAM database through the GUI. However, users must be successfully authenticated. Authentication is performed at login which the system can be configured to perform locally or through TACACS+ or RADIUS servers available within the network. Users are then assigned permissions based upon the profile which determines the functions which may or may not be executed. A default user named admin with the password 5620Sam! is provided with the initial installation.
Site Access Management

The 5620 SAM can also be used to manage access to each of the network devices individually or through templates whose configuration can be propagated to one or more of the network elements. This enables system administrators to configure the console, telnet and snmp user access and their permissions through the 5620 SAM GUI.
SAM Database Security

Network Model
7450
7450 7750
Data Warehouse
7450 7450 7750 7750
db
Scheduled or Manual Database Backup Copied to offsite storage for safekeeping
1 2 35
Database Management
To ensure against data loss, backups of managed device files, including the 5620 SAM database and individual routers, can be scheduled or performed manually through the intervention of network operations staff. Backups are performed when the server copies files from the managed devices to a remote location(1) using FTP or secure copy protocol (SCP).
Note
(1)
[Inserted Note (1)] Remote location: is any mounted partition or file system to which the 5620 SAM has access (i.e U:\\ drive)
NE Database Security
SAM Server Network Model
7450
7450 7750
Data Warehouse
7450 7450 7750 7750
Scheduled or manual configuration and bof Backup FTP (or SCP) to SAM Server Copied off-site for secure storage NE restore from SAM GUI
1 2 36
Network Element (NE) Database Management

A major concern for network providers is disaster recovery: what happens when nodes or network configurations are destroyed? Network element configuration backup procedures form a large portion of a carriers ability to restore services with minimal disruption to service in the case of a disaster. The 5620 SAM permits the network operator or administrator the ability to create a regular schedule to backup node element configuration files, and/ or bof files, as well as initiating a manual backup of these files, as required. When initiated, the config and/ or bof files are copied to the 5620 SAM server through FTP or SCP. The files can then be transferred to an off-site data storage facility for a higher degree of risk management for disaster recovery. The 5620 SAM will also permit the network operator or administrator the ability to restore a node as long as IP connectivity exists between the 5620 SAM server and network element and the configuration and/ or bof file are visible to the operator or administrator.
NE Software Upgrade
Time set for download Current time
12:00: 03
00 03 02 12:00: 01
TiMOS Release 5.0. Release 6.0
SAM Server
Scheduled or manual initialization Individual or multiple NEs at a time In-Service Software Upgrade possible
1 2 37
When a new device software version is available, the 5620 SAM can be used to perform an on-demand NE software upgrade or schedule one using a software upgrade policy. Multiple software upgrade policies can be created and configured which can then be assigned to multiple NEs. A software upgrade policy cannot be deleted once it has been assigned to an NE. During a software upgrade, the 5620 SAM performs checks to ensure that the new software is compatible with the device type and that the required files are present. The 5620 SAM does not initiate a device software upgrade unless the necessary conditions are in place. A software upgrade can be rolled back to the previous version in the event of an upgrade failure. An in-service software upgrade performed on a device allows a managed device to provide uninterrupted service during the upgrade process. A device software upgrade requires a CPM restart, which causes temporary device down time. When a device has dual CPMs, however, one CPM can remain active while the other restarts with the upgraded software. These alternate CPM restarts mean that the device remains in service during the upgrade. If an upgrade on a CPM fails, the CPM reports a failed state and raises an alarm. In-service software upgrades for devices are restricted to maintenance software releases. The 5620 SAM can be configured to activate the new software image immediately after transferring it to an NE, or transfer the files only and manually activate the software image later, as might be required for a scheduled upgrade of multiple NEs performed during off-hours when fewer staff are available to monitor the upgrades.
Network Management Software Integration
5620 NM 5620 SAM

Alcatel-Lucent ATM & TDM Network
1354 BM
Alcatel-Lucent SDH / SONET Network
Alcatel-Lucent IP Network
1 2 38
The 5620 SAM can be configured to inter-work with the following network management software applications: 5620 Network Manager (NM) Alcatel-Lucent ATM and TDM network management software which provides end- to-end service and network management including fault management and monitoring through a GUI 1354 Broadband Manager (BM) Alcatel-Lucent SDH/SONET equipment management software which provides end-to-end service and network management including fault management and monitoring through a GUI
Network Management Inter-working Software Functions

Network Management Software 5620 Network Manager Inter-working Functions Navigate to the 5620 NM GUI using X-terminal software on the 5620 SAM client GUI Forward alarms from the 5620 SAM to the 5620 NM Display 5620 SAM alarms on the 5620 NM Monitor end-to-end services using supported network manager integration Navigate from the 1354 BM to the 5620 SAM client GUI Forward alarms from the 5620 SAM to the 1354 BM Display 5620 SAM alarms on the 1354 BM Monitor the 5620 SAM server status from 1354 BM Monitor end-to-end services using supported network manager integration
1354 Broadband Manager
5650 Control Plane Assurance Manager (CPAM)
IP/MPLS control plane management solution enabling operators to perform

Network planning Network operation Network troubleshooting Network restoration Proactive assurance
1 2 39
The 5650 CPAM Release 1.0 (coincident with 5620 SAM Release 5.0), the 5650 CPAM Release 2.0 (coincident with 5620 SAM Release 6.0), and the 5650 CPAM Release 3.0 (coincident with 5620 SAM Release 7.0), provide real-time control IGP topology capture, inspection, visualization, and troubleshooting. The 5650 CPAM is integrated with the 5620 SAM, which allows the 5650 CPAM to cohesively tie routing layer information to infrastructure, such as network routes, service tunnels, LSPs, edge-to-edge service layer connectivity, and rich OAM test management. The holistic approach to control plane management offered by the 5650 CPAM and the 5620 SAM supports the following operational activities: Network Planning - Planning activities are optimized with real-time topology and strong linkages between services and infrastructure layers in the 5620 SAM GUI and 5620 SAM-O OSS interfaces. Network Operations - Real-time topology and multi-layer highlighting allows you to rapidly assess the state of services, tunnels, and routing on the IGP and IP/MPLS maps. Network Troubleshooting- Historical OAM trace, SPF and RSVP path, and checkpoints allow you to rapidly detect and resolve service level issues whose root cause is in the IP or MPLS layers. Network Restoration - Checkpoints and real-time views of IP/MPLS and service and tunnel infrastructure allow you to restore and plan networks. Proactive Assurance - 5650 CPAM alarms, network route and tunnel inspection lists, validation functions, checkpoints, and multi-layer views allow you to detect routing faults. The 5650 CPAM consists of: 7701 CPAA (Control Plane Assurance Appliance) Route Analyzer rack-mounted and provides and analysis and distributed computing platform. 5650 CPAM Route Controller a java application running on a Solaris platform that is able to retrieve data from the Route Analyzers.
Questions
?
1 2 40
1. Which of the following statements is true?

a. The 5620 SAM supports IP/MPLS-based network convergence by providing subscriber services such as
VLL,VPLS, VPRN, IES and VLAN over a common network infrastructure.

b. The 5620 SAM software architecture is built on industry standards such as SOAP and XML which promote
interoperability with other systems.

c. The 5620 SAM provides flexible network access, thereby allowing users to interact with the network on a
service or subscriber basis, or at the individual device level.

d. The 5620 SAM uses proprietary software architecture intended for configuration management of Alcatel-
Lucent IP products exclusively. 2. Which of the following is considered a Generic NE?

a. SunBlade 1500 b. Alcatel-Lucent 7670 Router Switching Platform c. Alcatel-Lucent 7470 Multi-Service Platform d. Alcatel-Lucent 7750 Service Router
3. The 5620SAM protects the server from any point of failure in the server or database software or the server and database hardware platform, and from connectivity problems that isolate the server from the network.
a. True b. False
Questions [Cont.]
4. What is the maximum number of simultaneous GUI Clients supported in this release?
a. 10 b. 60 c. 100 d. 1,000
5. Which of the following is true?

a. The fault management system provides impact analysis and correlation of alarms to equipment and
service-affecting faults.
b. The network management capabilities of the 5620 SAM allow network operations staff to provision the
Internal Gateway Protocols (IGP), including; static routes, RIP, OSPFv2 , OSPFv3 and IS-IS, as well as the BGP (Border Gateway Protocol) used for L3 VPN (VPRN) services.
c. Performance monitoring and accounting statistics collection are performed on the 5620 SAM using
service- and equipment-related statistics counters from the managed devices.

d. The 5620 SAM provides network operations staff with a limited suite of diagnostic tools for fault analysis
and localization requiring extensive use of third-party software and equipment. 6. The SAM-E is the base component of the 5620 SAM software.
a. True b. False 1 2 41
7. Network protocol configuration and management is provided by which of the 5620 SAM software components?
a. SAM-E b. SAM-P c. SAM-A d. SAM-O
8. The SAM-A component of the 5620 SAM software provides which of the following functions?
a. Topology views b. OAM troubleshooting tools c. Statistics and accounting policies and data d. All of the above
9. The SAM-O component of the 5620 SAM software provides open systems interface to the 5620 SAM managed network?
a. True b. False
Answers
1. Which of the following statements is true?
a. The 5620 SAM supports IP/MPLS-based network convergence by providing subscriber services such as
VLL,VPLS, VPRN, IES and VLAN over a common network infrastructure.

b. The 5620 SAM software architecture is built on industry standards such as SOAP and XML which
promote interoperability with other systems.

c. The 5620 SAM provides flexible network access, thereby allowing users to interact with the network
on a service or subscriber basis, or at the individual device level.

d. The 5620 SAM uses proprietary software architecture intended for configuration management of Alcatel-
Lucent IP products exclusively. 2. Which of the following is considered a Generic NE?

a. SunBlade 1500 b. Alcatel-Lucent 7670 Router Switching Platform c. Alcatel-Lucent 7470 Multi-Service Platform d. Alcatel-Lucent 7750 Service Router
3. The 5620SAM protects the server from any point of failure in the server or database software or the server and database hardware platform, and from connectivity problems that isolate the server from the network.
a. True b. False Product Overview 5620 SAM Overview
1 2 42
All Rights Reserved Alcatel-Lucent 2009 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
4. What is the maximum number of simultaneous GUI Clients supported in this release?
a. 10 b. 60 c. 100 d. 1,000
5. Which of the following is true?

a. The fault management system provides impact analysis and correlation of alarms to equipment and
service-affecting faults.
b. The network management capabilities of the 5620 SAM allow network operations staff to provision
the Internal Gateway Protocols (IGP), including; static routes, RIP, OSPFv2 , OSPFv3 and IS-IS, as well as the BGP (Border Gateway Protocol) used for L3 VPN (VPRN) services.
c. Performance monitoring and accounting statistics collection are performed on the 5620 SAM using
service- and equipment-related statistics counters from the managed devices.

d. The 5620 SAM provides network operations staff with a limited suite of diagnostic tools for fault analysis
and localization requiring extensive use of third-party software and equipment. 6. The SAM-E is the base component of the 5620 SAM software.
a. True b. False
Answers [Cont.]
7. Network protocol configuration and management is provided by which of the 5620 SAM software Switch to notes view! components?
a. SAM-E b. SAM-P c. SAM-A d. SAM-O
8. The SAM-A component of the 5620 SAM software provides which of the following functions?
a. Topology views b. OAM troubleshooting tools c. Statistics and accounting policies and data d. All of the above
9. The SAM-O component of the 5620 SAM software provides open systems interface to the 5620 SAM managed network?
a. True b. False
1 2 43
Blank Page
1 2 44
End of Module 5620 SAM Overview
1 2 45
Last Blank Page

1 2 46
21
Section 2 System Overview

Module 1 System Architecture
TOS36013_02_01 Issue 1.1
Document History
212
System Overview System Architecture 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
List the components of the 5620 SAM management system Explain the interfaces between each of the SAM components Describe the security measures of the 5620 SAM
213
5620 SAM Main Components

The threeSwitch to notes view!SAM are: main components of 5620 5620 SAM Server 5620 SAM Database, and 5620 SAM Client The 5620 SAM Server is a network management processing engine, which is written in Java and runs on the Sun Solaris or Microsoft Windows platforms. The server include several third-party components, such as an application server, web server, protocol stack set, and database adaptor. The 5620 SAM Database is a customized Oracle relational database that provides persistent storage for the network data. The database usually runs on the same platform as the 5620 SAM server software. The 5620 SAM Clients are OSS applications or Java-based 5620 SAM GUIs. The 5620 SAM GUIs run on Sun Solaris or Microsoft Windows. The OSS applications can run on any platform, because they exchange platform-neutral XML/SOAP messages with the 5620 SAM server. Note
As previously alerted as All Rights Reserved Alcatel-LucentClient support for Red Hat Linux support has of R7.0 5620 SAM 2009 System Overview System Architecture been removed. 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
214
5620 SAM Configurations - Distributed or Collocated
OSS Client IP IP
GUI Client
OSS Client IP IP
GUI Client
Server IP IP
Managed Network
Server db
Managed Network
db
Distributed
215
System Overview System Architecture 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
Collocated
The 5620 SAM Server and Database are designed to operate using Sun Solaris or Windows operating systems, the details of which are discussed later in this section. When installing these components, network designers have the option of using a distributed or collocated configuration. In a distributed configuration, the 5620 SAM server and database are installed on separate workstations. This configuration is supported in a Sun Solaris OS and Windows OS environments. In a collocated configuration, the 5620 SAM server and database are installed on the same workstation and is supported in a Windows OS environment only.
Multi-tier Model
OSS Client GUI Client
Client
Web Server Application Server
JMS
EJB
Data Model
Presentation Business Integration
Server Business Logic Mediators
Database Adaptor
Managed Network
Resource db
Oracle database
216
Overview
The 5620 SAM has three main components, which can be viewed from a multi-tier perspective. The data model component plays an important role in providing service-level functions. These components are built using Alcatel-Lucent and non-Alcatel-Lucent software. All licensed components of the 5620 SAM are listed in the 5620 SAM server directory /nms/distribution/licenses.
Multi-tier Model
The 5620 SAM is structured into a five-layer multi-tier model, as shown on the opposite page, with associated components at each layer. Each layer performs the following functions: Client Layer - comprises the OSS clients and 5620 SAM GUI clients. The 5620 SAM GUI client installation package contains a Java virtual machine and Java GUI components that send EJB (Enterprise Java Bean) remote method invocations to the 5620 SAM server. The OSS clients send XML/SOAP messages to the 5620 SAM server. The distributed 5620 SAM architecture also supports web portal interfaces. Presentation Layer - buffers the application logic from the client layer. This layer contains several components. The web server receives SOAP/XML messages from OSS (Operational Support System) clients and passes them to the business layer. The third-party application server handles EJB method invocations received from the 5620 SAM GUI clients on the network and returns the responses generated by the business-layer logic. The application server also forwards JMS asynchronous
Multi-tier Model [Cont.]

Business Layer -to notes view! application logic and data model that drive 5620 SAM functions. The Switch contains the Java business logic processes input from client requests, managed network traps, and internal server events, and performs the appropriate actions on the managed network, clients, and internal data model. The server data model maintains information about network objects and their relationships. To support the business layer, an application server provides J2EE (Java 2 Platform Enterprise Edition) services. Integration Layer - buffers resource-layer entities from the business layer. This layer contains the mediators, which communicate with equipment in the managed network, and the database adapter. The mediator components translate messages from the business layer into the SNMP, FTP, Secure Copy Protocol (SCP), and CLI messages that are sent to the managed network. Messages that are received from the network are processed by the mediator components and passed to the business layer. The integration layer also contains the database adapter that decouples the Oracle database from the business logic. The database adapter code translates business logic requests into JDBC (Java Database Connectivity commands, and translates JDBC responses into the Java business model Resource Layer - describes external or legacy systems, which include the network of managed devices and the Oracle database. Managed devices are the resources that can be configured, controlled, and monitored by the 5620 SAM. The Oracle database contains the persistent storage for the data model, with data such as device configurations and statistics, as well as information about customer connections and services.
Server Data Model

217
The Data Model represents the physical and logical elements of the network, such as equipment, subscribers, customers, services, accounting data, and network performance statistics. The model also contains the relationships between these entities, thereby allowing users to perform network operations at the service level or subscriber level. This ability to associate entities in the network provides enhanced service capabilities and is crucial for managing complex multi-service networks. The data model representation of the current state of the managed network is stored in the Oracle database. Changes to the model that are triggered from the network and include event and data notifications such as network device fault traps or state changes. These updates are applied to the model, stored in the database, and reported to the client interfaces. Changes to the model that are triggered from clients include configuration or provisioning changes. These changes are applied to the model, stored in the database, and deployed to the network when appropriate.
Database Writes
database write sent to primary database from active server directed to redo log becoming persistent record full redo log, sent to database tablespace and archive log
db 1 Engine
redo log 1 Gig? 3 db tablespace
Server
The archive log files are removed when a database backup is performed.
218
archive log
When an event is to be written to the SAM database, the Server Business Logic directs the message to the database engine. The database engine sends the message to the redo log file, making it a persistent entry of the SAM database. Once 1 GByte of information has been written to the redo log, the contents of that file are written to the database tablespace. At the same time, the log file is written to the archive log file and a new redo log file is automatically opened; only one redo log file exists at any time. Archive log files are stored until a database backup is performed at which time they are removed. When the SAM database initializes, the database tablespace is read as well as the redo log file. Therefore, if the SAM database is power cycled, there is no loss of data.
Importance of Persistence
Persistence specifies whether the system will preserve system indexes when a save command is executed. During a subsequent boot, the index file is read along with the configuration file. Indexes uniquely identify objects in the router (ie Interfaces, LSPs) and are used by SNMP tools (ie MIB Browsers, the SAM database) to identify these objects. When configuration changes on a device are saved, a corresponding index file (.ndx extension) is created. During a reboot of the network element, the configuration file is compared to the index file to ensure that indexes remain the same, thus establishing a persistent index. This reduces the number of resynchronizations between the 5620 SAM and the affected network element.
Interfaces
Alarms/ Events
OSS Application Provisioning, inventory set/get requests

JMS JMS XML/ SOAP/ HTTP(S) XML/ SOAP/ HTTP(S) SNMP sets/ gets SNMP sets/ gets CLI or SSH1/2 CLI or SSH1/2 FTP/ SCP FTP/ SCP JDBC/ TCP JDBC/ TCP SNMP traps SNMP traps
EJB EJB JMS JMS
GUI Client
Managed Network
db
219
The 5620 SAM interfaces use industry-standard protocols to communicate between the server and managed network devices, the server and clients, and the server and database as shown in the figure on the opposite page.
Server and Managed Devices

The 5620 SAM server sends messages to the managed network in the form of SNMP sets and gets, CLI commands (over telnet or SSH), JDBC JMS (Java Messaging Script) messages, and FTP or SCP commands. SNMP is used by the server to monitor and manage network performance and find network problems by polling MIB performance data stored on the managed devices. The server also deploys configuration changes to the managed devices using SNMP. The managed devices use asynchronous SNMP messages, called traps, to notify the 5620 SAM server about device events. CLI is a command line interface that is accessible using Telnet or SSHv1 or v2. The commands are used to control node configurations and perform troubleshooting functions on network devices. Clients with the appropriate privileges can access the CLI by sending messages to the 5620 SAM server, which serves as an intermediary between the network devices and clients. FTP and SCP are application layer protocols for securely transferring files between machines. These protocols are used when the 5620 SAM backs up managed device configuration data, collects accounting statistics from the devices, and downloads software from the servers to devices. JMS is a subscription service for clients that want to receive event and alarm messages about the state of the managed network.
Server and Clients

Client interfaces give access to the 5620 SAM server and managed network. Clients generate messages to Switch to notes view! the 5620 SAM server to view and change data objects in the data model and to perform network operations. The OSS clients use the XML/SOAP protocol over HTTP or HTTPS. The client GUIs use Java session bean invocations. OSS client software developers create XML messages to send requests to the 5620 SAM server. The JMS interface is also available using XML messaging, which is the recommended way to implement JMS on the OSS client. Schema files provide the XML interface definitions for relevant data objects. The schema files package related domain objects together and describe the attributes and methods of the objects. See the Alcatel 5620 SAM-O OSS Interface Developer Guide for more information about the contents of the schema files and the messages that are sent between the OSS clients and the 5620 SAM server. The 5620 SAM Java GUI clients send requests to the server EJB session beans using RMI. The 5620 SAM Java GUI and 5620 SAM-O OSS clients use JMS channels to receive realtime network event and alarm information from the server. Clients must register a subscription or durable subscription using object messaging to set up this link. The events received include: managed network alarm notifications System Overview System Architecture
2 1 10
configuration changes in the network notifications of activity switches from the primary to the standby 5620 SAM server errors in 5620 SAM database connectivity
Server and Database

The 5620 SAM server communicates with the 5620 SAM database using a JDBC session over TCP. JDBC is a Java API for inter-working with SQL relational databases.
5620 SAM and External Systems

The 5620 SAM can be integrated into multi-service network management systems using its open XML interface.
Security
In a distributed system such as the 5620 SAM, security is required not only at the session management Switch to notes view! level, but also at the network transport layer, because messages sent over a network can be intercepted and forged. To begin a user session, a client must provide user identification and a password to access the 5620 SAM menus and functions. These and subsequent messages are also protected at the network transport level. The diagram on the opposite page shows the 5620 SAM components and the security at the session and network transport levels.
Session Management
Effective session management requires authentication, authorization, and accounting functionality. Authentication is the verification of a user identification and password. Authorization is the assignment of different levels of access permissions to users. Accounting is the recording of user actions. These three functions can be accomplished on the 5620 SAM by using the local security capability on the 5620 SAM server, or with a third-party authentication server. A combination of local and third-party mechanisms can also be used to provide backup authorization. Local authentication on the 5620 SAM server is provided with a local database of users and a local security scheme to verify logon attempts and assign permission levels for command execution. Third-party authentication servers supported are RADIUS or TACACS+. These products run on their own platforms, with their own user lists and administration process. User accounts are created on the 5620 SAM and consist of a user name and password, plus an associated user group. User groups are used to assign and control authorization levels for each user, and to control the extent of access to such areas All Rights Reserved Alcatel-Lucent 2009 2 1 11 as subscribers, services, or faults. The system administrator can also limit the type of user access per System Overview System Architecture 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator managed device; for example, allowing FTP access but denying console, telnet, or SNMP access.
Client Sessions
All client session types have username and password protection. The 5620 SAM client GUI EJB sessions are protected by the username and password for the session. Each OSS client XML/SOAP message is individually authenticated using cached information from an authorization server. JMS messages are protected by the user name and password for the JMS connection.
Database Sessions
The database is accessible through a connection from the server, which is protected by a user ID and password. When a database update is completed, an entry in the client activity log saves the client name and the request performed to track user actions on the database workstation. Secure communication between the 5620 SAM server and the underlying Oracle database is provided by network authentication. During installation of the 5620 SAM server, the administrator can enable authentication.
Managed Device Sessions

The 5620 SAM server performs CLI, FTP, or SCP commands on managed devices. Clients can also perform these commands by issuing requests to the server. The authentication, authorization, and accounting function required for security is achieved using the local security databases on managed devices, or with a third-party authentication service such as RADIUS or TACACS+. SNMPv3 message authentication and authorization is handled by USM (User State Migration) and VACM (View-based Access Cluster Manager) mechanisms to define users and user authorization permissions. Older SNMP versions are authenticated with community string identifiers. Every SNMP message is individually authenticated.
Network Transport Security

Legend
OSS Application
JMS/ SSL JMS/ SSL HTTP(S)/ HTTP/ HTTP(S)/ HTTP/ User ID/password User ID/password
Firewall
User ID/password User ID/password EJB/SSL EJB/SSL User ID/password User ID/password JMS/SSL JMS/SSL
SNMP v3 USM/ VACM SNMP v3 USM/ VACM SNMPv1, v2 community string SNMPv1, v2 community string CLI or SSH2 CLI or SSH2 User ID/password User ID/password FTP/ SCP FTP/ SCP User ID/ password User ID/ password
Managed Network
GUI Client
User ID/password User ID/password
Database Database session session authentication authentication
SSL SSL
db db SAM server if redundant

2 1 12
Radius or TACACS+
User authorization User authorization and authentication and authentication requests requests
Transport protocol security is supported by the network protocols that carry messages between programs running on different platforms.
Server and Clients

Network communication between the 5620 SAM server and clients is carried out using XML/SOAP, EJB, or JMS messages. The OSS clients have two options for message security. When HTTPS is used to transport XML/SOAP messages, messages are protected by an SSL (Secure Sockets Layer) connection. The less-secure HTTP can also be used. The Java GUI clients use the EJB interface, which is protected by an SSL connection. Both OSS and GUI clients use JMS, which is protected by SSL. In a redundant configuration, the secondary 5620 SAM server acts as a client of the primary server, which is protected by SSL.
Server and Managed Devices

Messages from devices are in SNMP, CLI (over Telnet or SSHv1 or v2), or FTP or SCP format. When SNMPv3 is used, then Secure Hash algorithm (SHA) or Message Digest 5 (MD5) authentication values are placed in messages and checked against a key shared by server and device to prevent tampering. Security is provided by SSH in CLI commands.
Firewall Support
The 5620 SAM supports firewalls on all the server interfaces, that is, between the server and clients, and between the server and managed network. See the 5620 SAM Planning Guide for firewall and reserved port information. All Rights Reserved Alcatel-Lucent 2009
TOS36013_02_01 Issue 1.1 Section 2 Module 1 Page 12
Questions
?
2 1 13
1. Physical and logical representation of the elements of the network, such as equipment, subscribers, customers, services, accounting data, and network performance statistics is a function of what tier? a. Client Layer b. Business Layer c. Integration Layer d. Resource Layer 2. The 5620 SAM Java GUI and 5620 SAM-O OSS clients use JMS channels to receive real-time network event and alarm information from the server. a. True b. False 3. Security is provided only at the session management level. a. True b. False
Answers
1. Physical and logical notes view! of the elements of the network, such as equipment, Switch to representation subscribers, customers, services, accounting data, and network performance statistics is a function of what tier? a. Client Layer b. Business Layer c Integration Layer d. Resource Layer 2. The 5620 SAM Java GUI and 5620 SAM-O OSS clients use JMS channels to receive real-time network event and alarm information from the server. a. True b. False 3. Security is provided only at the session management level. a. True b. False
2 1 14
End of Module System Architecture
2 1 15
Last Blank Page

2 1 16
31
Section 3 Graphical User Interface

Module 1 Login and GUI Overview
TOS36013_03_01 Issue 1.1
Document History
312
Graphical User Interface Login and GUI Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Describe how to launch the Graphical User Interface (GUI) List the components of the GUI Describe window management
313
Graphical User Interface (GUI)

5620 SAM Graphical User Interface runs on Client machines Used to provide FCAPS:
Fault management Configuration Management Administration Performance Monitoring Security
314
The GUI and the network management components use a Java-based technology that provides distributed, secure, and scalable applications. This architecture allows for scaling and fair load balancing, which improves performance. GUIs run on clients, and do not have direct access to the database or the network elements The GUI is used to provide Fault, Configuration, Administration, Performance, and Security functionality. 5620 SAM operators can: display equipment and alarm status configure and manage network management applications simplify the administration and execution of equipment, service, and subscriber using wizard-like configuration forms instead of the Command Line Interface (CLI) configure, manage, and monitor Service Level Agreements (SLAs) and equipment using performance counters, and create and manage security policies for access to the routers and for operations using the 5620 SAM
Launching the 5620 SAM GUI

Click the icon 5620 SAM Client App
Enter Login name and Password Default Login Login Name: admin Password: 5620Sam!
Click on the Login button

315
Graphical User Interface Login and GUI Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
To start the 5620 SAM GUI from a Microsoft Windows machine: 1. Double-click on the shortcut icon that was created on your desktop when the software was installed. The 5620 SAM login window appears. 2. Enter the appropriate Login Name and Password, and click on the Login button. The 5620 SAM GUI opens. To start the 5620 SAM GUI from a UNIX machine: 1. As root in the bash shell, navigate to the appropriate bin directory in the 5620 SAM client installation directory, for example the c:/<sam directory>/client/nms/bin directory. 2. Start the 5620 SAM client by typing nmsclient.bash. The 5620 SAM login window appears. 3. Enter your Login Name and Password, and click on the Login button. The 5620 SAM GUI opens.
GUI Components
Menu bar Tool bar
Navigation tree Working pane Dinamic alarm list Task bar Status bar
316
There are seven (7) basic components to the 5620 SAM GUI. They are the: Menu Bar used to execute 5650 CPAM tasks Tool Bar provides shortcuts for Menu functions Navigation Tree Window displays all 5650 CPAM managed equipment, services, and protocols including OSPF and IS-IS Working Window Pane displays drawings and configuration forms Dynamic Alarms List displays incoming events and alarms Task Bar used to track all currently opened windows of the client session. Status Bar displays user account, date, redundancy, alarm-related object, propagation, and connection status information. Using the Menus, the Toolbar, or Shortcuts:
1. Open the 5620 SAM GUI. 2. Choose a menu:
From the drop down submenu options under each top-level menu. An applicable shortcut icon for that menu function is shown next to the options text. From the menu equivalent in the Toolbar. Scrolling over the icons will display their function. By typing the appropriate ALT+Key shortcut. For example, ALT+P opens the policies menu. The underlined letter indicates the shortcut action.
GUI Menus
317
Menu Item Application Submenus Create Submenus
Function Display maps and views of the network Turn audible alarms on or off Shut down the 5620 SAM GUI Create services with the option of using service templates which automate the specification of provisioning of complex managed object Create groups of nodes and display physical links Manage services, LSPs, service tunnels, customers Manage maps and views of the network, including a subscriber view of services used by the customer Configure and manage routers Configure and manage policies related to alarm handling, quality of service, routing protocols, schedules, Access Control Lists (ACLs), services and statistics Numerous functions, including launching a Telnet or SSH2 session with selected network equipment, with the option to configure routers via SSH or Telnet Configure and manage discovery of network objects. Configure and manage users and access Manage how forms are displayed in the working pane Show the splash screen
Manage - Submenus
Policies - Submenus Tools - Submenus Administration Submenus Window - Submenus Help - Submenus
Note
Icons appearing next to submenu items indicate that a shortcut exists on the Tool Bar for that function.
Manipulating Windows
Close a Close a window window Maximize a Maximize a window window Moving a Moving a window window Minimize a Minimize a window window
Altering a window Altering a window size size

318
Minimizing, Maximizing and Closing a Window

By clicking on the icons in the upper right corner of a window, it can be minimized, maximized or closed.
Window Size Alteration

By placing the cursor at any border of a window until the symbol shown above appears, its size can be altered vertically or horizontally by dragging the cursor up, down, right or left.
Moving a Window
In order to move a window, place the mouse cursor in the area indicated in the above diagram Moving a window, and while holding the left mouse button down, the window can be dragged to the appropriate location on the screen.
Tool Bar
Navigation Navigation Tree Tree
Equipment Equipment Manager Manager
Task Task Manager Manager
Manage Manage Services Services Manage Manage Equipment Equipment
Alarm Alarm Window Window
Physical Physical Topology Topology
Create Create Service from Service from a Template a Template
Customize the Tool Bar Customize the Tool Bar
319
The toolbar provides shortcuts to Menu functions and can be customized on a per-session, per-user basis.
Customizing the Tool Bar

Place the cursor in the Tool Bar area of the window. Right-click the mouse and select or de-select the boxes next to the functions that are to be added or removed from the Tool Bar. Save the settings. Application Note
If the settings are not saved prior to terminating the sessions, the GUI defaults will [Inserted Note] be applied at the next log in.
Save Workspace.
Navigation Trees
3 1 10
The network operator is provided the ability to determine the configuration and status of various aspects of the managed network through the use of Navigation Trees. From the drop down menu, the managed network is represented through four Navigation Trees: Equipment - enables the network operator to configure and display the hardware configuration and status of the managed nodes. Other functions; such as CCAG (Cross Connect aggregate Groups), APS (Automatic Protection Services) and LAGs (Link Aggregate Groups) are configured and monitored through this tree. OSPF displays the configuration and status of the OSPF (v2 and v3, if enabled) in the network. IS-IS same as OSPF. Routing enables the network operator to configure and display the configuration and status of the network routing protocols, including; MPLS, LDP, BGP, etc. Ring Group displays the ring group structure for the OS 6850 and 7250 SAS nodes in the user network
Dynamic Alarm List

Alarm Counter Alarm Counter
Alarm Statistics Alarm Statistics
Alarm details Alarm details
3 1 11
The Dynamic Alarm List provides the network operator information relating to outstanding alarms in the network which is displayed under the Alarm Table and Alarm Statistics tabs. Alarm Table provides the network operator or administrator with a count and list of the total number of outstanding alarms in the network. Alarm Statistics provides the network operator or administrator with the number of acknowledged and unacknowledged outstanding alarms displayed by alarm severity. Alarms are reported in accordance with the ITU-T X.733 method of reporting which includes alarm classification and its associated color coding which will be discussed in a later module.
Dynamic Alarm List [Cont.]
Total of objects listed Total of objects listed Information Categories Information Categories selectable selectable
Per Session; Per Per Session; Per User User
3 1 12
The network operator or administrator is not only able to customize the categories which will be presented in the list but may also rearrange the order in which alarms will appear by placing the mouse in the title of any of the information categories and right-clicking on the mouse. In the menu window that appears, the network operator or administrator will find an alarm count at the very top (in blue font) which represents the total number of outstanding alarms. It is also possible to modify the alarm information to be displayed simply by deselecting the item in the list. The arrowhead at the bottom provides for scrolling through the full range of information categories. The order in which the information appears in the alarm list can also be modified simply by selecting the category (left-click on its title) and then moving it to the right or left, as desired. To ensure that these changes remain permanent, it is important to Save Table Preferences, as shown above. The changes will be saved on a per user; per workstation basis. If changes are not saved prior to terminating the session, the 5620 SAM GUI will revert to its default settings.
Contextual Menus
Select an object Right click to display contextual menu
3 1 13
Right-clicking on an applicable object provides a network administrator with Contextual Menus which permits them to select appropriate options available to that object. Once selected, the appropriate window or configuration form appears.
Window Tiling
Vertical Vertical
Horizontal Horizontal
3 1 14
All 5620 SAM windows are displayed in a working pane on the GUI, to the right of the navigation tree. Each newly opened window appears in the foreground. The previously opened window is placed in the background. The working pane can contain dozens of configuration forms, drawings, maps, and displays. With window management, the network administrator can: organize windows according to operator preference keep windows open until they are needed perform side by side comparisons of data on different forms, and navigate quickly to other open windows using a numbered list, which is ordered according to the time that the window was opened Window Tiling allows users to organize the GUI session to promote efficient workflow and quick access to the necessary information. As shown above, windows can be set for: Vertical tiling Horizontal tiling Square tiling, or Cascade Tiling
Window Tiling [Cont.]
Square Square
Cascade Cascade
3 1 15
Window Submenu
Submenu Item Function
Reset to Preferred Size Cascade & Reset to Preferred Size Close All Minimize All Tile Vertical Tile Horizontal Tile Square Tile Cascade
Reset the window in the foreground to the default size. Reset the window in the foreground to the default size and cascade. Close all open windows. Reduce all windows to a small rectangle with truncated title bar.
Windows Management Workflow

1. Open the appropriate windows. See the appropriate section and module for the tasks to be performed. 2. Manage the open windows in the working pane to maximize operator effectiveness and efficiency.
Bring the window on which you want to work to the foreground. Organize the location and appearance of open windows.
3. Close unnecessary windows to clear the window pane.
Network Topology Maps

Physical Topology view Physical Topology view
LSP Topology view LSP Topology view
Alternate Topology Alternate Topology view selection view selection
Service Tunnel Topology view Service Tunnel Topology view
3 1 16
The following network topology maps are available on the 5620 SAM: Physical topology LSP topology Service Tunnel topology The maps visually display network information, and provide contextual menus and submenus to launch windows which display additional information. To view these topology maps, choose Application -> Physical Topology or Service Tunnel Topology or LSP Topology. An alternate method of viewing Network topologies is to place the mouse cursor on the area indicated in the diagram Alternate Topology view selection above and selecting the particular topology view of interest.
Topology Map Tool Bar
Save to Save to File File Bookmarks Bookmarks
Auto-Layout Auto-Layout Tool Tool Select Select Tool Tool
Zoom in Zoom in Tool Tool Sizing Sizing Tool Tool
Reload Reload Topology view Topology view from database from database
Go Go Back Back Find Find
Configure Configure into Tables into Tables
Display Filterable Display Filterable Flat map Flat map Hand Hand Tool Tool
Zoom Zoom out Tool out Tool
Overview Overview Window Window
3 1 17
Save Map View and Save Full Map

Click on the Save to File icon Select action from the drop down menu
Select a location and name for the saved image
Select the format type for the saved image

3 1 18
As of SAM 6.0, all topology maps have been updated to include a Snapshot button allowing a snapshot of the entire map, or viewed portion of the map. The snapshot button functions as a pop-up menu allowing selection of one of the following: Save Map View produces a snapshot of the viewed portion of the map Save Full Map produces a snapshot of entire map area The user can select the location for the snapshot image and the file type. The file type presents system available formats which includes: JPEG, JPG, BMP (Windows), and PNG (UNIX).
Topology Map Functionality
The hide functionality related to a zoom level is The hide functionality related to a zoom level is overridden when the vertex (or node) is selected overridden when the vertex (or node) is selected
3 1 19
All topology maps now provide the following pan and zooming functionality: Mouse wheel zooming - rolling the mouse wheel changes the zoom level in increments of 5% to minimum or maximum zoom level. When in pan mode dragging the mouse results in map panning, when in select mode the dragging the mouse results in the multi- select rectangle. Objects can now be selected in both pan and select mode. In pan mode the cursor will change to the selection cursor if over a vertex (node). Zoom + - modes are still present and function as they did and are provided in case user doesnt have mouse wheel capability As of SAM 6.0, to reduce map clutter at lower zoom levels all topology maps have been enhanced to provide the following functionality: Two icons have been provided for each vertex, a normal and a reduced size one. The link widths are drawn thinner when the zoom level is below the zoom threshold. The labels on the map are hidden if the zoom level drops below the hide threshold. The hide functionality is overridden when the vertex is selected and the label will be displayed.
Flat Map Topology View

Accessing the Flat Map Topology View
Select Application Flat Maps choose one of the three available flat map options.
For example choose Physical Topology. A Topology filter Physical Topology Flat window will open
3 1 20
The 5620 SAM R7.0 Flat Map Topology view (previously introduced on R6.0 as flat snapshot maps) is used to view a large number of network objects and link groups. Double-click on a network element in the flat map to display the objects properties. For example, when you double-click on a network element, a property form opens. You can view or configure the parameters. The flat map provides similar navigation and functionality to other 5620 SAM topology maps such as: Object icons in the flat map are displayed at a reduced size, link lines are thinner, and object details are not displayed all mouse based navigation is supported zoom in and out node and link status color
Flat Map Topology View [Cont.]

Input a filter by selecting the Object Filter field. Select an option from the filter dropdown list and click on the + icon.
A filter window will open
Select Attribute, Function and Value as required. Click on Add to create the filter. Click on the Apply button
3 1 21
To open a flat map:

1. Once the user selects a Flat Map type to display, an empty window will open. 2. The user must then input a filter by selecting the Object filter which will open the filter drop down
list.
3. Click on the root object in the tree to add specific filter entries and Click on the + icon 4. Select Attribute, Function and Value as required. Once the filter is complete click on the ADD+
icon to build the filter.

5. Select the Apply button when the filter is complete. The flat map window will open.
Flat Map Topology View [Cont.]
3 1 22
The 5620 SAM will display the flat map requested. The flat map provides a complete view of the network since grouping is removed. Since the flat topology map supports up to 1000 objects, you can narrow the range of objects that are displayed by creating, and saving multiple filters, and filter definition trees.
Service Topology Map View
Managed Access Managed Access Interface Interface Managed Router Managed Router
Link Group Link Group

3 1 23
A service topology map view is available on the 5620 SAM from the Manage A service topology map displays the state of a given service. Icons in the service path topology map represent routers. Link groups between routers represent service tunnels. When a link group is red, at least one link in the link group is down.
Services window.
For link groups between managed routers, right click on the link group icon to list and edit service tunnels in the link group. For link groups between managed and unmanaged routers, right click on the link group icon to launch contextual menus and submenus which allow you to launch additional information windows for the service tunnel, including the Properties window. The service map that appears displays all routers for the service. Right click on the router to launch contextual menus and submenus for the service. In this context, the symbol and color in the top left corner of the managed router icon represent the most severe alarm on the router. The symbol and color in the bottom right corner represent the status of the communications between the router and the 5620 SAM. Link groups between routers represent service circuits. Link groups between router icons and ports represent the binding of an access port or interface to a service. Right click on the link group icon to launch contextual menus and submenus. Right clicking anywhere on the service map launches contextual menus and submenus for all the sites for the service.
Blank Page
3 1 24
Questions
?
3 1 25
1. Name the seven main components of the SAM GUI. 2. Name the four possible formats of window tiling. 3. Name the three available network topology maps.
Answers
1. Name Switch to notes view! of the SAM GUI. the seven main components Menu Bar Tool Bar Navigation Tree Window Working Window Pane Dynamic Alarms List Task Bar Status Bar 2. Name the four possible formats of window tiling. Vertical tiling Horizontal tiling Square tiling Cascade Tiling 3. Name the three available network topology maps. Physical Topology LSPGraphical User Interface Login and GUI Overview Operator Topology 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Service Tunnel Topology
3 1 26
End of Module Login and GUI Overview
3 1 27
Last Blank Page

3 1 28
41
Section 4 Router Discovery

Module 1 SNMP Configuration
TOS36013_04_01 Issue 1.1
Document History
412
Router Discovery SNMP Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Describe what is SNMP and what versions of SNMP are supported on the 7X50 node Configure community string and SNMP packet size on the 7X50 node
413
SNMP Overview
SNMP Manager
Advantages:
Simple Popular Expandable SNMP is an application SNMP is an application layer protocol layer protocol
PDUs variables (Titles and Values)
Exchange
PDUs variables (Titles and Values)
Remote Management of TCP/IP Networks
414
Simple Network Management Protocol (SNMP) Overview

SNMP Standards
SNMP is a communications protocol that has gained widespread acceptance since 1993 as a method of managing TCP/IP networks, including individual network devices and devices in aggregate. SNMP was developed by the IETF (Internet Engineering Task Force) and is applicable to any TCP/IP network, as well as to other types of networks. SNMP is an application-layer protocol designed to give a user the capability of remotely managing a computer network by polling and setting terminal values and monitoring network events. It exchanges network information through messages (technically known as protocol data units or PDUs). From a high-level perspective, the message (PDU) can be looked at as an object that contains variables that have both titles and values. Advantages of SNMP Simplicity. Its easy to implement on a large network Popularity All Over the World. Almost all major vendors of internetwork hardware design their products to support SNMP Expandability. Because of its simple design, it is easy for the protocol to be updated.
SNMP Standard Specifications
SNMP Manager Defines How/When:
Data exchanged ??
Data formatted ??
Data transmitted ??
Data
referenced
??
SNMP Managed Node

415
Router Discovery SNMP Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
SNMP can be viewed in many different ways as: a Standard Message Format a Standard Set of Managed Objects a Standard Way of Adding Object a Standard Message Format SNMP is a standard communications protocol that defines a UDP message format. This part of the standard is highly involved, and is of little consequence to users (but of great interest to SNMP programmers.)
A Standard Set of Managed Objects

SNMP is a standard set of values (referred to as SNMP "objects") which can be queried from a device. Specifically, the standard includes values for monitoring TCP, IP, UDP and device interfaces. Each manageable object is identified with an official name, and also with a numeric identifier expressed in dot-notation.
A Standard Way of Adding Objects

One reason that SNMP has become popular and the industry standard is that a method was originally defined so that the standard set of managed objects could be augmented by network device vendors with new objects specific for a particular network.
SNMP Components SNMP Agent
Responds to SNMP manager requests SNMP Manager
Sends Traps
(SNMP Managed Nodes) (SNMP Managed Nodes)
Software process
Software process
Software process
SNMP Agent SNMP Agent
416
SNMP Components
The SNMP components are: Agent Manager Community MIB
SNMP Agent
The SNMP agent is a software process that runs on a managed node. The agent stores a variety of management data and responds to SNMP manager requests for specific data. The agent can also asynchronously signal an event (a trap) to the SNMP manager. Each node managed by the 5620 SAM has an SNMP agent.
SNMP Components SNMP Manager

5620 SAM
Software Process that runs on the Network Management System
HP OpenView NNM
7750 SR
SNMP Agent(s)
417
SNMP Manager
The SNMP manager is a software process that runs on the NMS. The NMS runs the network management applications that present management information to users. The 5620 SAM has an SNMP manager that communicates with the SNMP agent of a managed node. Using SNMP commands, the SNMP manager can: query and/or send requests to SNMP agents set variables in agents get responses from agents acknowledge asynchronous events (traps) from agents
SNMP Components SNMP Community

SNMP Community SNMP Community
NNM
SNMP Manager SNMP Manager Community String Community String Community String Community String Community String Community String
(SNMP agent) (SNMP agent) (SNMP agent) (SNMP agent) Community Name? Community Name?
418
(SNMP agent) (SNMP agent)
SNMP Community
An SNMP community is a relationship between an SNMP agent and a set of SNMP managers. The SNMP architecture allows access to a managed node by multiple managers. When an SNMP agent is paired with one or more SNMP managers through community strings, they form an SNMP community. Each community is given a unique community name. The SNMP manager must use that name in all get and set operations. Because the agent defines community names, different agents may define the same name. This does not mean that communities with the same name share any similarities. The SNMP manager must keep track of the community name or names associated with each SNMP agent it wants to access.
SNMP Components MIB
Server Program Client Program Virtual Connection Virtual Connection 7750 SR (SNMP Agent) (SNMP Agent)
SNMP Manager Status Information Status Information
SNMP MIB
SNMP MIB
SNMP MIB
MIB Modules
419
MIB - Definition
SNMP defines a client/server relationship. The client program, the SNMP Manager, makes virtual connections to a server program, the SNMP Agent, which executes on a remote network device and serves information to the manager regarding the status of the device. The database, controlled by the SNMP agent, is referred to as the SNMP Management Information Base (MIB), and is a standard set of statistical and control values. SNMP allows managers and agents to communicate so that they can access the objects stored in the MIB. SNMP additionally allows the extension of these standard values with values specific to a particular agent through the use of private MIBs. The term MIB can be used generically to refer to the entire database of the managed device, or it can be used to refer to a specific set of data defined by a particular MIB module. In the latter case, the database is composed of the data structures and data defined by one or more MIB modules.
How SNMP Works

5620 SAM
7750 SR

Software process
Get requests Get next requests Set requests Get - responses from agent Traps - Acknowledge asynchronous events- from agent
4 1 10
There are five types of messages exchanged between the SNMP manager and SNMP agent: The get-request operation is sent by the SNMP manager. It fetches the value of one or more variables/objects to determine performance and the state of the device. The get-next-request operation is sent by the SNMP manager. Returns the next name and value of thenext object supported by a network device given a valid SNMP name. Used to determine all names and values that a device supports. The set-request operation set is sent by the SNMP manager. Sets a named object to a specific value. Used to configure and control the device by SNMP. The get-response operation is the message returned by the SNMP agent in response to the previous three operations. The trap operation is sent by the device and notifies the SNMP manager when something happens on the SNMP agent (Cold-start/Link-down/Link-up). Enables devices to reach out to a manager to notify them of problems with the device. Since four of the five messages are simple request-reply operations, SNMP is designed to run over UDP. The SNMP agent sends traps to UDP port 162.
SNMP Security Models and Levels

Security Model
V1 V2c V3 V3 V3
Security Level
No Authentication No Privacy No Authentication No Privacy No Authentication No Privacy Authentication No Privacy Authentication Privacy
Authentication
Community String Community String User Name MD5 or SHA MD5 or SHA
PDU Encryption
None None None None DES
4 1 11
The 5620 SAM supports all three versions of SNMP, as shown above. Depending upon the security model implemented in the network, configuring SNMP security can be as simple as defining a community string (v1 and v2) or more complex, using usernames and passwords, with/ or without encryption (v3). Which security model to implement will depend upon the equipments ability to support the various versions of SNMP and the level of risk management set by corporate policy.
Firewalls and FTP

The 5620 SAM uses FTP to transfer data from managed devices. You can use FTP without any impact to the Switch to notes view! 5620 SAM. As well, ports between 5620 SAM applications and managed devices, such as between the 5620 SAM server and the managed devices, such as a 7750 SR, must be open across firewalls to allow for proper operation of the software.
Secure File Transfers

As of Release 4.0 of the 7450 ESS and 7750 SR, SSH2 is the default secure file transfers protocol. When SSH2 is enabled and the secure file transfer type is configured in the SSH2 mediation policy for the 7X50 nodes, SCP, not FTP, is used to transfer data from the managed devices.
Enabling FTP, SSH2 and Telnet

Run the following CLI command to enable FTP, SSH2, and if desired, Telnet on the managed device. FTP is used for accounting statistics and device backup and restore functionality. SSH2 is used for secure CLI communication and secure file transfers for statistics, and for device backup and restore functionality on the 7X50 nodes. configure system security ftp-server configure system security telnet-server
4 1 12
Questions
?
4 1 13
1. What version of SNMP is supported on the 5620 SAM?

a. 1 b. 2 c. 2c d. 3,4
2. What community string is used by the 5620 SAM and 7X50 routers?
a. Private b. Public
Answers
1. What version of SNMP is supported on the 5620 SAM?
a. 1 b. 2 c. 2c d. 3,4
2. What community string is used by the 5620 SAM and 7X50 routers?
a. Private b. Public
4 1 14
End of Module SNMP Configuration
4 1 15
Last Blank Page

4 1 16
42

Module 2 Discovery Management
TOS36013_04_02 Issue 1.1
Document History
422
Router Discovery Discovery Management 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Discover 7x50 nodes on the SAM using the Discovery Manager Perform the manual reconciling of 7x50 nodes Configure polling for in-band and out-of-band management
423
Introduction to the 5620 SAM Discovery Manager

Reconciles router elements into the 5620 SAM database SAM DB
Di sc o ve ry
Ma
Network Mgmt IP Persistence on Router ID SNMP security SNMP no shutdown
SN
na
MP
ge r
re
sp on se
managed network
424
The 5620 SAM simplifies network provisioning by allowing you to discover devices and reconcile them to the 5620 SAM database for management. Network element discovery is executed via SNMP. During the discovery process, the 5620 SAM scans the network for devices according to user-defined IP addresses or IP address ranges. When the IP address used to discover the device is the IP address of the device management port, management is considered outof-band. Once a device has been discovered through its out-of-band management IP address, management of that device can be changed to be in-band, at which time the device is managed through its system IP address, also known as the System ID. To discover devices, use the Discovery Manager to create one or more discovery rules, choose a discovery rule, and scan the network as specified by the rule. When a device is discovered, the 5620 SAM sets the device in a managed state and reconciles device elements into the 5620 SAM database. Discovery rules contain rule elements. Rule elements specify which devices or subnets are to be included or excluded from the discovery process. A discovery rule can contain more than one rule element. For example, one rule element can be configured to discover a subnet, and configure another rule element to exclude specific IP addresses from the subnet.
Discovery Workflow
Configure Configure Router Router
Network Mgmt IP Persistence on Router ID Community string SNMP no shutdown Base SNMP Mediation Policy Mediation Security Create Discovery Rule Verify Rule status Enable or disable discovery rules Remove discovery rules Rescan the network according to a discovery rule Manage or un-manage routers Reconcile router elements into the 5620 SAM database
Configure Configure Mediation Policies Mediation Policies
Discover Routers Discover Routers
Manage Manage Router Discovery Router Discovery
425
The following workflow outlines the high-level steps necessary to discover the network. 1.Configure Mediation Policies 2.Discover Routers Create discovery rules Discover devices by scanning the network according to discovery rules Set discovered device in a managed state Reconcile device elements into the 5620 SAM database Check discovery, management, and reconciliation status of the devices 3. Manage Router Discovery. Edit discovery rules Add or edit rule elements Enable or disable discovery rules Remove discovery rules Rescan the network according to a discovery rule Manage or unmanage devices Reconcile device elements into the 5620 SAM database
Note
Using CLI, ensure the router is configured to be discovered by the 5620 SAM, including the maximum transmission unit size of the SNMP packets at 9216, as previously discussed.
Basic Router Configuration

1. 2. Launch a CLI or SSH session to the router Configure Network Management IP a. # bof <Enter> b. # show bof
Tip If address is not defined, type the following: a. bof# address <IP address/ subnet mask> <Enter> 3. 4. 5. Set persistence on a. bof# persist on <Enter> Define a location to save the configuration file a. bof# primary-config <file location:/file path/filename.cfg> Save the bof a. bof# save
426
The first step to enable the 5620 SAM to discover and manage network elements is to provide for the basic configuration of the devices. Use the following steps to provide the basic configuration 7750/ 7450 and 7710:
1. Initiate a CLI or SSH session with the appropriate network element 2. Configure the Management IP interface
Follow the procedure shown above to define the Ethernet management IP which is used for remote access to the network element. This address is defined in the bof (boot options file) and is shown above. Configure the interface, as required.
3. Set persistence on
Persistence is required for management of network devices through the 5620 SAM and is enabled by default. Set the parameter, as required.
4. Define the location to save the configuration file
Changes to the configuration of the router (interfaces, SNMP, etc) must be saved to ensure that the parameters are not lost should the element be rebooted. The file location can be either on an ftp server or any of the compact flashes on the device. There is no specific naming convention for the filename however, it must end with a .cfg extension. This file will become the default save location each time an admin save is performed.
5. Save the bof
To ensure that changes are not lost should the network element reboot, perform a bof save as indicated above.
Basic Router Configuration [Cont.]

6. Define the Router ID a. # configure router interface system address <IP address/32> <Enter> Configure SNMP Security a. # configure system security snmp <Enter> b. # community <community string> rwa version both <Enter> Enable a. # b. # c. # SNMP configure system snmp <Enter> packet-size 9216 <Enter> no shutdown <Enter>
7.
8.
9.
Confirm changes a. # show bof <Enter> b. # show router interface <Enter> c. # configure system security snmp <Enter> # info d. # configure system snmp <Enter> # info
Attention: Remember to save the router configuration

427
Router Discovery Discovery Management 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
6. Define the Router ID
Though any interface can be configured as the Router ID, traditionally the system interface, also know as the loopback address in other vendors equipment, is configured to assume this role.
7. Configure SNMP Security
Deployments are initiated from the SAM to the managed devices through SNMP. By default, SNMP is not configured on the managed devices. Therefore, network operators or administrators will be required to define the SNMP parameters. The example above assumes SNMP v1/v2 will be configured on the devices in the network. SNMPv3 requires more extensive configuration. Refer to the managed devices technical practices for details.
8. Enable SNMP
By default, SNMP is disabled. Enable the protocol and ensure that the appropriate PDU size is set (5620 SAM requires a PDU size of 9216 bytes).
9. Confirm changes 10. Save the configuration changes
# admin save <Enter>
Configuring Mediation Policies
Mediation Policies control polling rates and intervals to the 7X50 nodes Polling Synchronization Time reference time for all polling intervals Discovery Rule Scan Interval how often the SAM rescans using each Discovery Rule
428
Mediation policies define the interval and ratio used by 5620 SAM to poll network elements for SNMP MIB configuration changes. The mediation manager and mediation forms can be used to view the network element information contained in the SNMP MIB. To configure the Mediation Policy: Choose Administration Mediation from the 5620 SAM main menu. Click on the General tab button. Configure the parameters, as required. Polling Synchronization Time is the reference time for all polling intervals, which are typically defined in a given policy. Discovery Rule Scan Interval specifies how often 5620 SAM database rescans the network according to discovery rules that are enabled.
MIB Entry Policies
429
Configure additional parameters as required. MIB Entry Policies - edit MIB Entry policies. Network operators may filter on specific a MIBs or may view the entire list available to the 5620 SAM. Network Operators may accept the default action or are able to modify the manner in which the 5620 SAM deals with individual MIBs. To do so, double-click on the MIB entry and modify the parameters, as required. Once completed, save the changes by clicking on the OK or Apply button. Changes will override the Polling Synchronization Time defined under the General tab.
Mediation Security
4 2 10
Mediation Security - add or edit SNMP mediation security policies. To create a new policy: Select the Mediation Security tab of the Mediation window and click on the Add button. A new window appears on the screen. Specify the Displayed Name, as required. Set the security model parameter to the version of SNMP used for security from the dropdown menu, as shown above. Depending on whether SNMP V2 or V3 is used, the community string (or specify the security level, passwords, and authentication type) will have to be configured. Click on the Apply button to save the changes.
Mediation Security [Cont.]
4 2 11
To create a mediation policy that uses SSH2 for CLI sessions and secure file transfers in backups, restores, and software upgrades, and in statistics collection: Select the appropriate Communication Protocol from the dropdown menu under the CLI section of the Mediation Security configuration window, as show above. Set the User Name and User Password as required. Ensure that the user and password are already configured on the network devices to which this mediation security policy will be associated. Select the appropriate File Transfer Type from the dropdown menu in the File Transfer section of the configuration window, as shown above. Set the User Name and User Password, as required. Ensure that the user and password are already configured on the network devices to which this mediation security policy will be associated. Click on the OK or Apply button at the bottom of the window to accept the changes. However, the changes will not be sent to the database until the network operator or administrator clicks on either the OK or Apply button of the containing window.
Creating Discovery Rules
4 2 12
Create a Discovery rule to discover the managed node(s). Select Administration Discovery Manager Click on the Discovery Rules tab button and click on the Add button to create a new discovery rule. Configure the parameters in the Specify General Attributes window. Specify a description for the discovery rule that is up to 80 characters. This is an optional parameter. Specify the administrative state. When the administrative state is set to Up, the network is scanned according to the discovery rule when the discovery rule is saved. The network is also scanned according to the discovery rule as specified by the Discovery Rule Scan Interval parameter in the Mediation window (as already discussed). If the administrative state is set to Down, the network is not scanned as specified by these conditions. Click the Next button. The Add Rule Elements window appears.
Creating Discovery Rules [Cont.]
4 2 13
In the Add Rule Elements panel, click the: Add button to add a new rule element. Specify the management IP address and subnet mask of the router(s) to be discovered. You can discover a subnet by specifying a general IP address and setting a portion of the network mask bits to the appropriate value. Specify whether the IP address or range is to be included or excluded for the discovery rule. For example, one rule element may specify that a subnet be included and therefore discovered, while another rule element may specify that specific IP addresses in the subnet be excluded and therefore not discovered. Next button to assign the Mediation Security policy which was configured previously. The 5620 SAM provides a default mediation security policy that may also be used. Finish button to save the rule using the default settings for the remaining parameters. The network will be scanned according to the discovery rule when the Apply button in the selected in the Discovery Manager window, also referred to as the Containing Window.

Configure the Access Mediation Policies to be used
these define certain parameters which control communication to the routers press Select and specify which policy to use
Optionally, press Mediation to configure policies which control polling rates and intervals Press Finish to complete creation of the Discovery Rule
4 2 14
Click the Next button In the Mediation Security panel, click on the Select button if you want to specify mediation security policies specific to the discovery rule. If you do not specify a policy, the default policy is applied. Click the Next button. If you clicked the Select button, the mediation security window appears. The network operator may: Select an existing mediation security policy and click the OK button. Select an existing mediation security policy and click on the View button. When the View button is selected, a Mediation Policy window appears. Set the security model parameter to the version of SNMP used for security. Depending on whether you use SNMP V2 or V3, you have to configure the community string, or specify the security level, passwords, and authentication type. Click on the OK button. Click on the Finish button to save the discovery rule. The 5620 SAM automatically polls the network, via SNMP, searching for routers in the range of addresses specified in the rule.
Verifying Discovery and Reconciliation

Double Click on the Discovered NEs group Double Click on the Discovered NEs group
Drag and drop into the Physical Topology Map
Node 95 is no longer in Discovered NEs Group Node 95 is no longer in Discovered NEs Group
4 2 15
The 5620 SAM pulls the configuration from the node and reconciles it to its Oracle database. All newly discovered nodes will be listed in the Discovered NEs group. To view the node icon, double-click on the Discovered NEs group, select the node from the list an drag-and-drop the listing into the appropriate group. The node icon will appear in that group. When first discovered, the 5620 SAM will show the node as yellow, indicating that a database transfer from the node to the 5620 SAM Oracle database is underway. Once completed, the icon will turn grey-green and a check mark will appear in the upper right corner of the nodes icon. Rescan the Discovery Rule if necessary by: Select Administration Highlight the rule. Then click Rescan. Discovery Manager
Verifying Discovery and Reconciliation [Cont.]

Newly discovered routers are automatically Managed by the SAM and will appear in the Discovered NEs group on the Topology Map Managed State Status
4 2 16
Verify that the router is discovered and is managed by the 5620 SAM by clicking the Managed State tab in the Discovery Manager window. The management state of the router is displayed in the Site State column. The default state is managed. It may become necessary to unmanage a router; for example, during equipment maintenance. When unmanaged, the 5620 SAM removes the device from active involvement in the network. The router will disappear from the Navigation Tree and the Physical Topology however, it remains in the database. This will result in re-convergence of the protocols configured in the network and alarms will be ignored. To unmanage a router: Navigate to the Managed Sites tab of the Discovery Manager window Select the router from the list Click on the Unmanaged button. The Site State will change to unmanaged requested and then to unmanaged. To return a router to active management: Navigate to the Managed Sites tab of the Discovery Manager window Select the router from the list Click on the Managed button. The Site State will change to managed requested and then to managed. The 5620 SAM will automatically query the routers management IP address and list it in the Discovered NE group.
Verifying Discovery and Reconciliation [Cont.]

The SAM can be told to rescan using a Rule by selecting it and pressing Rescan
Under the Resync Status tab, all routers which have been discovered are listed and their resync status displayed Individual routers can be resynchronized (the MIB is read into the SAM db)
4 2 17
Verify that the router configuration has been reconciled into the 5620 SAM database by clicking the Resync Status tab button. The status is displayed in the Resync Status column. Done indicates the database has been successfully reconciled. Failed indicates the database has not been successfully reconciled. Routers that have been successfully reconciled appear in 5620 SAM equipment windows.
Manual Reconciliation
Individual routers can be resynchronized (the entire MIB is read into the SAM db)
4 2 18
To initiate a manual reconciliation of a router, select the router from the router list and click the Resync button. If the reconciliation fails: View faults that are associated with a router by double clicking on the router in the Discovery Manager window, and clicking on the Faults tab button in the window that appears. Check the SNMP security parameters on a router using the CLI. Check the 5620 SAM mediation policy settings by choosing Administration from the 5620 SAM main menu. Mediation
Reconciling Router Elements in the SAM Database
4 2 19
Choose Administration Select a router.
Discovery Manager from the 5620 SAM main menu.
Click on the Resync Status tab button. Click on the Resync button. Configure the parameters in windows that appear and click on the Finish button. It is possible to resynchronize specific MIBs, or all of the MIBs for the entire router. A message indicates when the reconciliation is successful.
Editing a Discovery Rule
Administration
Discovery Manager
4 2 20
Choose Administration Select a discovery rule.
Click on the Discovery Rules or Managed State tab button. Click on the Properties button. The discovery rules editing window appears. Configure the parameters as required. To delete a node (or an entire group) from the Discovery Manager, select a node (or group), then select Delete. To delete a rule element, select Properties, then the Rule Elements tab button and click on the Delete button. Click on the OK button at the bottom of the window to close the discovery rules editing window.
Enabling / Disabling a Discovery Rule

Administration Discovery Manager
4 2 21
When a discovery rule is enabled, the network is scanned according to the parameters saved in the database. The network is also scanned according to the discovery rule as specified by the Discovery Rule Scan Interval parameter in the Mediation window. If the discovery rule is disabled, the network is not scanned. To enable or disable a Discovery Rule: Choose Administration Discovery Manager from the main menu. The Discovery Manager window appears. Click on the Discovery Rules tab button. Select a discovery rule. Enable or disable the discovery rule. Click on the Shut Down button to disable the discovery rule. Click on the Turn Up button to enable the discovery rule.
In-Band and Out-of-Band Management - Overview

Management Port Management Network
5620 SAM
192.168.186.100 80.80.80.1
Out-of-band connection
Virtual Interface
192.168.186.165 (sysIP=1.1.1.2) Router 2 10.10.10.1
192.168.186.164 (sysIP=1.1.1.3) Router 3 10.10.10.2 80.80.80.2
In-band connection
4 2 22
There are two ways for the 5620 SAM to send management traffic to the managed network: Out-of-band using an Ethernet connection to the management interface of a device In-band using connectivity between devices When both types of management are configured, network elements can be managed using alternate routes if a link fails. Out-of-band management, called primary on the GUI, uses a management connection to the management port of the router. The management traffic is sent out-of-band. The packets with the management data arrive at the router using the management port. The destination address is the management IP address of the router. In-band management, called secondary on the GUI, uses a connection provided by a customer service, such as a VLL. The management traffic is sent in-band along with the customer payload traffic. The packets with the management data arrive at the router using one of the virtual interfaces. The destination address is the system IP address of the router. In-band management is typically used when the geography of dispersed sites makes it economically impractical to have out-of-band links. As well, an in-band connection can be configured as a safety measure, in case the primary out-of-band connection fails.
In-band and Out-of-Band Management Configuration

Select the network device From the equipment hierarchical tree Properties Polling
4 2 23
Each node can be individually configured for in-band/out-of-band management. The router must be discovered using an out-of-band connection. Therefore, a router may require that out-of-band access set up temporarily for discovery purposes. Specify whether scheduled polling is enabled or disabled using the Scheduled Polling parameter. Scheduled polling is configured using the mediation policies configuration form. Set the Active Management IP parameter. The parameter specifies the currently used management method. Primary, the default, refers to Out-of-Band management. Secondary refers to In-Band management. The management method can be modified by changing the Active Management IP parameter. Check the Auto Revert to Primary check box to ensure that primary (out-of-band) management is used after a failed switch to secondary (in-band) management. Specify whether to use Primary Only, Secondary Only, or Primary and Secondary as the management method using the Management IP Selection parameter. When Primary and Secondary has been selected, either parameter can be used to control and regulate the management switch-over process.
In-Band Management
To manage routers in-band, the 5620 SAM Server requires a second Ethernet interface which connects to a network port on one of the 7X50 nodes in the network. In-band management is done to routers system (loopback) address. A second SNMP trap destination log must be configured in CLI so that the router sends event notifications to the 5620 SAMs in-band interface. # configure log log-id <XX> from main security # configure log log-id <XX> to snmp 1024 # configure log snmp-trap-group <XX> trap-destination <y.y.y.y> snmpv2c notifycommunity privatetrapXX
Blank Page
4 2 24
Questions
?
4 2 25
1. 7750 SR routers can be discovered by the 5620 SAM via a. In-band communication only b. Out-of-band communication only c. In-band or Out-of-band communication d. CPSS 2. All the statement about in-band management are incorrect except: a. In-band uses an Ethernet connection to the management interface of a device,. b. Before a 7750 SR can be managed by the 5620 SAM, it must be discovered via in-band management. c. In-band management is the default. d. Out-of-band management is the default.
Answers
1. 7750 SR routers can be discovered by the 5620 SAM via a. In-band communication only
b. Out-of-band communication only c. In-band or Out-of-band communication d. CPSS 2. All the statement about in-band management are incorrect except: a. In-band uses an Ethernet connection to the management interface of a device,. b. Before a 7750 SR can be managed by the 5620 SAM, it must be discovered via in-band management. c. In-band management is the default. d. Out-of-band management is the default.
4 2 26
End of Module Discovery Management
4 2 27
Last Blank Page

4 2 28
43

Module 3 Generic Node Elements
TOS36013_04_03 Issue 1.1
Document History
432
Router Discovery Generic Node Elements 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Describe Generic Node Elements (GNEs) Explain the purpose of GNEs Identify how GNEs are managed
433
Generic Node Element (GNE)

Sun Microsystems
Non-SAM SNMP managed devices Management limited primarily to monitoring Telnet, ftp, SSH, CLI and scripting possible
7670 RSP
7x50 Network
434
7670 RSP
7670 RSP 7x50 Network
As of Release 4.0, the 5620 SAM introduced the capability for basic management of Generic Network Elements. Generic Node Elements, also referred to as Generic NE or GNE, are any SNMP- managed device that is not directly managed by the 5620 SAM (e.g., Sun Workstation, Alcatel 7670 RSP, Alcatel 7470 MSP, Cisco router, Juniper router). Generic NE management includes the ability to: Plot GNEs on the Physical Topology Map Monitor the NE status (on- or off-line) Perform direct cut-through telnet/ SSH to the Generic NE Send CLI scripts to the Generic NE
Generic NE Discovery Workflow
Create Generic NE Create Generic NE Profile Profile
Define System Object ID (System OID) Specify CLI Login Profile
Configure Configure Mediation Policies Mediation Policies
Base SNMP Mediation Policy Mediation Security
Discover GNE Discover GNE
Scan the network Set routers in a managed state Reconcile router elements into the SAM DB Verify Rule status
435
The following workflow outlines the high-level steps necessary to discover the network: 1. Create Generic NE Profile. This profile is used to define the System Object Identifier and CLI login profiles required to manage the device. 2. Configure Mediation Policies. Poller Policies define the SNMP characteristics to be used by the 5620 SAM to communicate with the device to be managed. Of primary concern are: Base SNMP Poller Policy Discover devices by scanning the network according to discovery rules Mediation Security 3. Discover Generic Network Elements. Through Discovery Management, the network operator will: Edit discovery rules Add or edit rule elements Enable or disable discovery rules Remove discovery rules Rescan the network according to a discovery rule Manage or unmanage devices Reconcile device elements into the 5620 SAM database
Note
Using CLI, ensure the router is configured to be discovered by the 5620 SAM, including the maximum transmission unit size of the SNMP packets supported by the generic NE (refer to the equipments technical documents).
Generic NE Profile
Click on the Add button
Select Administration Generic NE Profiles.

Generic NE Profiles window will open
Specify Generic NE Type, Sys Object ID and Description.

Sys Object ID unique SNMP System Object Identifier of object to be managed.
436
To enable the 5620 SAM to be able to discover generic NEs, it is necessary to first create a Generic NE Profile. This profile defines the manner in which the 5620 SAM will communicate with the generic NE and will require a separate profile for each type of node to be managed. To create a Generic NE Profile, select Administration Generic NE Profiles, as indicated above. From the General tab of the Generic NE Profile (Create) window, specify the Generic NE Type - a name to identify the device type for this profile (mandatory) Sys Object ID - the unique SNMP System Object ID (System OID) of the device type to be managed (mandatory). The System OID may be used to define a family of products or a specific device. Example: a. .1.3.6.1.4.1.637.69.2.1.1.63 identifies the Alcatel 7670 RSP b. .1.3.6.1.4.1.42 identifies the family of Unix workstations by Sun Description - optional information about the profile or node type to assist the network operator in identifying the particular profile at a later date.
Generic NE Profile [Cont.]
CLI Profile specifies function of telnet or CLI cut-through to the device Refer to device configuration manual for details
437
The CLI Profile tab enables the network operator to specify the manner in which telnet or the CLI cutthrough will function with the managed device. Generic NEs are different one to the other. Therefore, it will be necessary to refer to the appropriate NE technical documents to properly configure the parameters presented in this window. Some of the common functions are: Maximum Number Of Sessions Telnet Port Read and Write user Login and Password prompts.
Generic NE Profile [Cont.]

CLI Second Level Login secondary CLI command required to enter the configuration prompt Example: Telco T5C Not required for most devices. Refer to device technical documents.
438
CLI Second Level Login are not commonly used. However, some devices, such as the Telco T5C, use a second level of security during the login procedure. From this window, network operators may enable and configure the appropriate parameters to support second level login. It is imperative to select the OK or Apply button to save any changes to the 5620 SAM Oracle database.
Configuring Mediation Policies
Mediation Policies control polling rates and intervals to the 7X50 nodes Base Polling Interval - how often the SAM polls the routers for changes to the MIB tables Discovery Rule Scan Interval - how often the SAM rescans using each Discovery Rule
439
Mediation policies define the interval and ratio used by 5620 SAM to poll network elements for SNMP MIB configuration changes. The mediation manager and mediation forms can be used to view the network element information contained in the SNMP MIB. To configure the Mediation Policy: Choose Administration Mediation from the 5620 SAM main menu. Click on the General tab button. Configure the parameters, as required. Polling Synchronization Time is the reference time for all polling intervals, which are typically defined in a given policy. Discovery Rule Scan Interval specifies how often 5620 SAM database rescans the networ according to discovery rules that are enabled.
Generic NE Mediation Security
Security Model SNMP v1, v2c or v3, as required
Community string as configured on the device to be managed Communication Protocol Telnet or SSH2 Username / Password as configured on the device to be managed
4 3 10
Mediation Security defines the SNMP characteristics that the 5620 SAM will use to communicate with the managed device. Under the Mediation Security tab of the Poller Policy configuration window, the following parameters must be specified: Policy ID must be a unique number within the 5620 SAM database. Users may manually assign a value or allow the 5620 SAM to Auto-Assign ID. Displayed Name used to assist in locating the policy at a later date (optional) Security Model allows users to select the appropriate SNMP model as it is configured on the device to be managed from a drop-down menu Community String required where SNMP v1 or V2c is used and must match the value configured on the device to be managed Communication Protocol permits the user to select Telnet or SSH2 as the communication protocol to the managed device. Username / Password automates the login process through pre-configuring the login username and password.
Creating Discovery Rules
4 3 11
Create a Discovery rule to discover the managed node(s). Select Administration Discovery Manager Click on the Discovery Rules tab button and click on the Add button to create a new discovery rule. Configure the parameters in the Specify General Attributes window. Specify a description for the discovery rule that is up to 80 characters. This is an optional parameter. Specify the administrative state. When the administrative state is set to Up, the network is scanned according to the discovery rule when the discovery rule is saved. The network is also scanned according to the discovery rule as specified by the Discovery Rule Scan Interval parameter in the Mediation window (as already discussed). If the administrative state is set to Down, the network is not scanned as specified by these conditions. Click the Next button. The Add Rule Elements window appears.
4 3 12
In the Add Rule Elements panel, click the: Add button to add a new rule element. Specify the management IP address and subnet mask of the router(s) to be discovered. You can discover a subnet by specifying a general IP address and setting a portion of the network mask bits to the appropriate value. Specify whether the IP address or range is to be included or excluded for the discovery rule. For example, one rule element may specify that a subnet be included and therefore discovered, while another rule element may specify that specific IP addresses in the subnet be excluded and therefore not discovered. Next button to assign the Mediation Security policy which was configured previously. The 5620 SAM provides a default mediation security policy that may also be used. Finish button to save the rule using the default settings for the remaining parameters. The network will be scanned according to the discovery rule when the Apply button in the selected in the Discovery Manager window, also referred to as the Containing Window.

Configure the Access Mediation Policies to be used
these define certain parameters which control communication to the routers press Select and specify which policy to use
Optionally, press Mediation to configure policies which control polling rates and intervals Press Finish to complete creation of the Discovery Rule
4 3 13
Click the Next button In the Mediation Security panel, click on the Select button if you want to specify mediation security policies specific to the discovery rule. If you do not specify a policy, the default policy is applied. Click the Next button. If you clicked the Select button, the mediation security window appears. The network operator may: Select an existing mediation security policy and click the OK button. Select an existing mediation security policy and click on the View button. When the View button is selected, a Mediation Policy window appears. Set the security model parameter to the version of SNMP used for security. Depending on whether you use SNMP V2 or V3, you have to configure the community string, or specify the security level passwords, and authentication type. Click on the OK button. Click on the Finish button to save the discovery rule. The 5620 SAM automatically polls the network, via SNMP, searching for routers in the range of addresses specified in the rule.
Verifying Discovery
Double Click on the Double Click on the Discovered NEs group Discovered NEs group
Drag and drop into the Drag and drop into the Physical Topology Map Physical Topology Map
Kanata
4 3 14
Once a Generic NE Profile and Discovery Rule have been created, the 5620 SAM scans the network in search of the devices in the same manner as fully managed devices. The 5620 SAM scans the Discovery Rule, with the associated Mediation Security Policy. It assumes that the device is a fully managed node and looks for 7x50 / 7710 first, then sequencing through each of the Generic NE Profiles until one of the profiles works to manage the device. The 5620 SAM pulls the configuration from the node and reconciles it to its Oracle database. All newly discovered nodes will be listed in the Discovered NEs group. To view the node icon, double-click on the Discovered NEs group icon, select the node from the list and drag-and-drop the listing into the appropriate group. The GNE node icon will appear in that group, as well as, in the Navigation Tree Equipment view, under that same group, as a GNE. This icon will only appear in the Equipment view since it is not a fully managed node. When first discovered, the 5620 SAM will show the node as yellow, indicating that a database transfer from the node to the 5620 SAM Oracle database is underway. Once completed, the icon will turn grey-green and a check mark will appear in the upper right corner of the nodes icon.
Generic NE Properties
General Node information as read from
Device MIBs
Polling as defined in
Mediation Policy. Enable or Disable, as required
4 3 15
Double click on a GNE icon, or right-click from either the contextual menu or from the Network view of the Navigation Tree, allows the user to view the equipments Properties. The information presented is obtained from the NEs MIB and is presented in the General tab. The Polling tab enables the user to view the current mediation policy, as defined in the Discovery Rule. The polling can be disabled from the drop-down menu next to Scheduled Polling, if required.
Verifying Reconciliation
5620 SAM can be told to rescan using a Rule by selecting it and pressing Rescan
Under the Resync Status tab, all routers which have been discovered are listed and their resync status displayed
4 3 16
Router Discovery Generic Node Elements 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
Verify that the router configuration has been reconciled into the 5620 SAM database by clicking the Resync Status tab button. The status is displayed in the Resync Status column: Done indicates the database has been successfully reconciled. Failed indicates the database has not been successfully reconciled. Routers that have been successfully reconciled appear in 5620 SAM equipment windows.
Manual Reconciliation
Individual routers can be resynchronized (the MIB is read into the SAM db)
4 3 17
To initiate a manual reconciliation of a router, select the router from the router list and click the Resync button. If the reconciliation fails: View faults that are associated with a router by double clicking on the router in the Discovery Manager window, and clicking on the Faults tab button in the window that appears. Check the SNMP security parameters on a router using the CLI. Check the 5620 SAM mediation policy settings by choosing Administration SAM main menu. Mediation from the 5620
Reconciling Router Elements in the SAM Database
4 3 18
Choose Administration Select a router.
Click on the Resync Status tab button. Click on the Resync button. Configure the parameters in windows that appear and click on the Finish button. It is possible to resynchronize specific MIBs, or all of the MIBs for the entire router. A message indicates when the reconciliation is successful.
Editing a Discovery Rule

4 3 19
Choose Administration Select a discovery rule.
Click on the Discovery Rules or Managed State tab button. Click on the Properties button. The discovery rules editing window appears. Configure the parameters as required. To delete a node (or an entire group) from the Discovery Manager, select a node (or group), then select Delete. To delete a rule element, select Properties, then the Rule Elements tab button and click on the Delete button. Click on the OK button at the bottom of the window to close the discovery rules editing window.
Enabling/Disabling a Discovery Rule

4 3 20
When a discovery rule is enabled, the network is scanned according to the parameters saved in the database. The network is also scanned according to the discovery rule as specified by the Discovery Rule Scan Interval parameter in the Mediation window. If the discovery rule is disabled, the network is not scanned. To enable or disable a Discovery Rule: Choose Administration Discovery Manager from the main menu. The Discovery Manager window appears. Click on the Discovery Rules tab button. Select a discovery rule. Enable or disable the discovery rule. Click on the Shut Down button to disable the discovery rule. Click on the Turn Up button to enable the discovery rule.
Questions
?
4 3 21
1. Generic NE management provides the ability to: a. Monitor the NE status (on- or off-line) b. Perform direct cut-through telnet/ SSH to the Generic NE c. Send CLI scripts to the Generic NE d. All of the above 2. Which of the following statements is true? a. Generic NEs are managed exactly as is they are fully-managed nodes. b. Generic NE functions allow the 5620 SAM to manage any node in the network. c. Generic NE functions provide for limited manageability of SNMP managed devices. d. None of the above 3. The 5620 SAM Discovery Manager scans the network looking for fully managed nodes first, then looks at GNE profiles to determine if any exist. a. True b. False 4. Managing discovery rules for GNE devices is completely different to those for fully managed nodes. a. True b. False
Answers
1. Generic NE management provides the ability to: a. Monitor the NE status (on- or off-line) b. Perform direct cut-through telnet/ SSH to the Generic NE c. Send CLI scripts to the Generic NE d. All of the above 2. Which of the following statements is true? a. Generic NEs are managed exactly as is they are fully-managed nodes. b. Generic NE functions allow the 5620 SAM to manage any node in the network. c. Generic NE functions provide for limited manageability of SNMP managed devices. d. None of the above 3. The 5620 SAM Discovery Manager scans the network looking for fully managed nodes first, then looks at GNE profiles to determine if any exist. a. True b. False 4. Managing discovery rules for GNE devices is completely different to those for fully managed nodes. a. 3 22 4 True b. False
End of Module Generic Node Elements
4 3 23
Last Blank Page

4 3 24
51
Section 5 Hardware Configuration

Module 1 Hardware Navigation
TOS36013_05_01 Issue 1.1
Document History
512
Hardware Configuration Hardware Navigation 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Describe the function of Equipment Management Summarize a basic router configuration using the Navigation Tree Determine equipment configuration and status using the Navigation Tree Configure LLDP to automatically discover the physical topology in the network
513
Navigation Tree Overview

The Navigation Tree displays information about the status of managed devices, including the alarm status Switch to notes view! of an object and the aggregated alarm status of an object, based on the alarms raised against child objects of the parent objects. As well, the state of the object, for example the operational state or the administrative state, is displayed following the icon, object type, and description of the object. The view selector in the 5620 SAM navigation tree is a drop-down menu that lists the view options that you can choose. The available views are: Equipment OSPF IS-IS Routing Ring Group The Equipment view of the navigation tree contains the physical objects that the 5620 SAM manages and that can be created in a hierarchical order for the managed device. There can be more than one managed device object in the navigation tree. In the navigation tree, you can use the contextual menu choices to create, configure, and manage specific parameters for the child objects of the discovered device. To access objects in the navigation tree from the 5620 SAM: Click on an object in either the equipment view or the ring group view of the navigation tree and use the + and - icons to navigate the hierarchy of network equipment or ring group objects. Right-click on each object to open the contextual menu and choose a function. The functions available from the contextual menu are specific to All Rights Reserved Alcatel-Lucent 2009 each object in the hierarchy. 51 4
Configure Card Slot
Equipped Card Type card in place Assigned Card Type card configuration
515
Hardware Configuration Hardware Navigation 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
OK
Apply
Managed devices are often configured using scripts prior to their being discovered for management by the 5620 SAM. Use the following method to configure device hardware from the Equipment tab of the Navigation Tree: Navigate to the Card slot under the appropriate managed device. The 5620 SAM Card Slot refers to the Input/ Output Module (IOM) in CLI. Right-click and select Configure Card from the contextual menu. A new window appears that provides the network administrator or operator with available information about the Card. The Equipped Card Type identifies the type of IOM that is detected in the card slot. To configure the card as installed: Select the matching card type from the Assigned Card Type drop-down menu Select OK or Apply It is also possible to assign a Card Type to a slot even without one being physically present. This permits the device to be provisioned while waiting for equipment to be available. To pre-provision a card Slot, assign the appropriate card type to the slot and select OK or Apply.
Configure Daughter Card
@@SECTION @@MODULE 6
@@SECTIONTITLE @@MODULETITLE @@PRODUCT @@COURSENAME
All Rights Reserved Alcatel-Lucent @@YEAR
A Card Slot, or IOM, supports two (2) Daughter Card Slots, also referred to as the Media Dependent Adapter (MDA) in CLI. The MDA represents the physical interface to the devices in the managed network. To configure a Daughter Card Slot: Navigate to the Daughter Card Slot under the appropriate managed device. Right-click and select Configure Daughter Card from the contextual menu. A new window appears that provides the network administrator or operator with available information about the Card. The Equipped Card Type identifies the type of IOM that is detected in the card slot. To configure the card as installed: Select the matching card type from the Assigned Card Type drop-down menu. Select OK or Apply. The ports associated to the Daughter Card will appear under the appropriate slot with their defaults settings. It is also possible to assign a Card Type to a slot even without one being physically present. To preprovision a Daughter Card Slot, assign the appropriate card type to the slot and select OK or Apply.
Viewing Ports
To view ports, right-click on a particular port and select Properties. The associated port information will appear in a port window.
Configure Chassis Mode
Configure Chassis Mode to reflect the IOM installed and the Feature Set/Scaling figures required for the installation
Create Physical Links
Select an empty point on the background of Physical Topology Map and Click Right Choose Equipment and Create Physical Link Fill in Name and Description Select Endpoint A and Endpoint B using Select button. A Select Endpoint window will open, select an endpoint and click OK to close this Select Endpoint window. The end point information will display on the Endpoint field of the Create Physical Link window. Select OK on the Create Physical Link form A Green-Grey line will join Nodes to represent the physical link
Link Layer Discovery Protocol (LLDP) Overview

Neighbor-discovery protocol Configured in a different manner than the standard routing protocols LLDP allows a device to:
advertise its identity and capabilities to other stations attached to the same physical LAN send and receive LLDP periodical messages on all physical interfaces enabled for LLDP transmission locally store information discovered about peer devices for a configurable amount of time
LLDP is only applicable for devices using Ethernet connectivity
5 1 10
Link Layer Discovery Protocol is a not a routing protocol, but instead, 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. When LLDP is enabled on a device, it will send and receive LLDP messages on all physical interfaces enabled for LLDP transmission. These messages are sent periodically to ensure that information is accurate. These messages are stored on the local device for a configurable amount of time, and once this time has expired, the information is discarded.
LLDP 5620 SAM Capabilities

Discovered physical topology
LLDP table
LLDP enabled device 5620 SAM 5620 SAM uses the information stored LLDP tables on the node to automatically discover the physical topology in the network
5 1 11
LLDP is available in 5620 SAM Release 7.0 R1 and later, and is only applicable for devices using Ethernet connectivity. It is supported by the 7450 ESS, 7710 SR, and 7750 SR, all at Release 7.0 and later. and also the OmniSwitch at Release 6.3.1 and later. The 5620 SAM uses the information stored in the applicable LLDP tables on the node to automatically discover the physical topology in the network. Operators can use this information to examine the L1/L2 topology and perform appropriate diagnostics and troubleshooting. In LLDP, a single LLDP Protocol Data Unit is transmitted in a single Ethernet frame. The basic LLDP PDU consists of a header, followed by a variable number of information elements known as TLVs that each include fields for Type, Length, and Value. Type identifies what kind of information is being sent. Length indicates the length of the information string. Value is the actual information sent. Each LLDP PDU includes three mandatory TLVs followed by optional TLVs.
Technical Reference
[Inserted User Guide - Section See 5620 SAM R7.0Technical Reference] 34.1 Router Configuration Overview LLDP for more details on mandatory TLVs and optional TLVs.
LLDP Multiple Transmission Scopes
Bridging Customer bridge
Bridging Bridging Customer bridge TPMR
NE
NE
NE
NE TPMR
Nearest C-VLAN bridge Nearest non-TPMR bridge Nearest bridge

5 1 12
LLDP also supports multiple transmission scopes. The diagram above is a figure from the 802.1AB document that visually captures the concept of multiple transmission scopes. The destination MAC address in the LLDP PDU determines how a frame is propagated through the network, thereby determining the LLDP message scope. Table bellow identifies a set of destination MAC address and describes the different transmission scopes associated with each address. Name Nearest Bridge Nearest non-TPMR bridge Value [Inserted Table] 01-80-C2-00-00-0E 01-80-C2-00-00-03 Purpose Propagation constrained to a single physical link Propagation constrained by all bridges other than TPMR; intended for use within provider bridged networks Propagation constrained by customer bridges
Nearest Customer Bridge
01-80-C2-00-00-00
Configure LLDP on the Router
5 1 13
To enable LLDP on a router:

1. From the 5620 SAM GUI, choose Routing from the navigation tree view selector. 2. Navigate to the router icon. The path is Routing Router. 3. Right-click on the router icon and choose Properties. The Network Element (Edit) form opens. 4. Enable LLDP by performing the following steps.
i. ii.
Click on the Globals tab button. Configure the parameters: Administrative Status Transmission Interval (Seconds) Transmission Multiplier Re-Init Delay (Seconds) Notification Interval (Seconds) Transmission Delay (Seconds) Maximum Consecutive Transmissions Fast Transmission Interval (Seconds) PDUs in Fast Transmission
5. The Administrative Status, Maximum Consecutive Transmissions, Fast Transmission Interval (Seconds),
and PDUs in Fast Transmission parameters do not apply to the OmniSwitch. The Transmission Delay (Seconds) parameter only applies to the OmniSwitch.
6. Click on the OK button. A dialog box appears. 7. Confirm the action. The Network Element (Edit) form closes.
Configure LLDP on the Port
5 1 14
To configure LLDP on the port: Choose Equipment from the view selector in the navigation tree. The navigation tree displays the Equipment view. Right-click on a port object in the Equipment view and choose Properties from the contextual menu. The Physical Port (Edit) form opens with the General tab displayed. Configure the parameters: Administrative Status Notifications Transmit Management Address LLDP TLVs Click on the Remote Peers sub-tab under the LLDP tab to search for and display LLDP remote peers associated with the port. These remote peers are used to determine the physical topology of the network.
Technical Reference
See 5620 SAM R7.0 User Guide - Section 31.5 Navigation tree equipment management procedures - LLDP Procedure 31-29 for more details on configuring LLDP on Ethernet ports.
Physical Topology
5 1 15
Once the 5620 SAM has discovered all Physical Links using LLDP they will be displayed in green on the Physical Topology map.
Reference
The Reference option displays a fly-out menu. You can choose from the Set All, Clear All, or the Cleanup All options. The Reference option essentially takes a snapshot of the physically topology at a given time. Any deviation from this checkpoint can then be subsequently shown. The Set All option checkpoints all currently discovered links that exist. Any object that was previously checkpointed and is now operationally down is left untouched. Any object that goes operationally down in the future is not removed, but is simply marked as operationally down. The Clear All option 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. The Cleanup All option keep the current checkpoint set for objects that are operationally up, but removes checkpoints from objects that are operationally down objects. This is basically the same as the Clear All option, but only affects operationally down objects.
Blank Page
5 1 16
Questions
?
5 1 17
1. Router hardware can be configured using:

a. CLI b. The Navigation Tree c. All of the above
2. Card Slots cannot be pre-provisioned.

a. True b. False
3. Card Slot in the 5620 SAM refers to which of the following in CLI?
a. IOM b. MDA c. SF/CPM d. None of the above 4. Daughter Card in the 5620 SAM refers to which of the following in CLI? a. IOM b. MDA c. SF/CPM d. None of the above
Answers
1. Router hardware can be configured using:
a. CLI
b. The Navigation Tree c. All of the above
2. Card Slots cannot be pre-provisioned.

a. True b. False
3. Card Slot in the 5620 SAM refers to which of the following in CLI?
a. IOM b. MDA c. SF/CPM d. None of the above 4. Daughter Card in the 5620 SAM refers to which of the following in CLI? a. IOM b. MDA
5 1 18 c. SF/CPM
d. None of the above
End of Module Hardware Navigation
5 1 19
Last Blank Page

5 1 20
61
Section 6 Routing Protocol Configuration

Module 1 OSPF Configuration
TOS36013_06_01 Issue 1.1
Document History
612
Routing Protocol Configuration OSPF Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Configure network interfaces Describe the process to configure OSPF areas Enable OSPF on managed devices and add them to the appropriate OSPF area Describe the process to verify OSPF neighbors
613
Open Shortest Path First (OSPF)

Configuration planning is essential to organize OSPF areas, interfaces, and virtual links. OSPF provides Switch to notes view! defaults for basic protocol operability. OSPF configuration requires, as a minimum, that a single OSPF backbone area that contains the area border routers is created. For larger networks, several areas ca 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 1router ID is used by the OSPF and BGP routing protocols2009 the routing table manager. When a new in All Rights Reserved Alcatel-Lucent 6 4 Routing Protocol Configuration OSPF Configuration router ID is configured, protocols are not automatically restarted with the new router ID. The protocol 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator 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 OSPF areas include a backbone area, stub area, and NSSA.
OSPF Workflow
Create Network Create Network Interface Interface Numbered (IPv4 / IPv6) Unnumbered
Configure OSPF Configure OSPF Area(s) Area(s)
Area Identifier Area Type
Enable OSPF Enable OSPF on device(s) on device(s)
OSPF Version 2 OSPF Version 3
Add device(s) Add device(s) to OSPF to OSPF Add Network Add Network Interface to Interface to OSPF OSPF
615
Routers into appropriate area
system interface (passive) All other interfaces to be running OSPF Verify neighbors
The following workflow outlines the high-level steps necessary to configure the OSPF protocol in the managed network.
1. Create Network Interface. Network ports are used in the service provider transport or infrastructure
2. 3.
4. 5.
network, such as an IP/MPLS-enabled backbone network. Network ports can be assigned IP addresses (numbered) and act as Layer 3 interfaces. Create OSPF Area(s). At least one OSPF area must be created. An interface must be assigned to each OSPF area. The types of OSPF areas include a backbone area, stub area, and NSSA. Enable OSPF on device(s). With the appropriate hardware and TiMOS, it is possible to support OSPFv2 (IPv4) and/or OSPFv3 (IPv6). Refer to the appropriate technical documents for details on IPv6 supported hardware. Add device(s) to OSPF. Adding routers (OSPF instances) into the appropriate OSPF area establishes the router ID as the device identifier for the protocol. Add Network Interfaces to OSPF. Adding network interfaces into OSPF will initiate the exchange of link state information which will, in turn, establish the OSPF routing table. The system interface must also participate in OSPF and must be set to passive.
The exchange of routing information can be determined by verifying OSPF link status and viewing OSPF neighbours.
Create Network Interface
616
Network interfaces are used in the service provider transport or infrastructure network, such as an IP/MPLSenabled backbone. Network ports can be assigned IP addresses (numbered) and as Layer 3 interfaces. When network ports act as Layer 3 interfaces, they can pass IP traffic to other devices and communicate using routing protocols, such as ISIS or OSPF. To create a Network Interface: Select the Equipment view in the Navigation Tree Navigate to the appropriate port and right-click From the contextual menu, select Properties Under the General tab, ensure that the Mode parameter is set to Network Ensure the port MTU is set to a value large enough to support the underlying protocols, particularly MPLS Select the Network Interfaces tab Click on the Add button

Name mandatory (highlighted) Description - optional
Numbered assign an IP address Unnumbered no IP assigned
617
The Create Network Interface wizard opens. This is a multiple step process and is repeated for each network interface to be created. Complete each step of the wizard and select Next to move to the next step. Selecting Finish at any point in the wizard will apply the default settings of the remaining steps to the interface and close the wizard.
Selected General Properties

Name highlighted, meaning mandatory. All interfaces must have a name. Description (optional) Used to help find the interface at a later time. IPv6 allowed checking the box will allow the network administrator or operator to configure IPv6 parameters, as required. Additional steps will appear in the wizard. MAC Address manually configure an interface MAC, if required. Leave at default for most applications. Class Numbered if an IP address is to be assigned; Unnumbered if no IP address Port MTU is set to a value large enough to support the underlying protocols, particularly MPLS Click on the Next button
Assign IP Address
IP Address and Subnet (Numbered) as per network configuration Network ID primary address (ID # 1) or up to 15 secondary addresses Click OK to return to the main configuration wizard window. Click Next
618
Select Port
If the network administrator or operator has already selected the port at the beginning of this process, the selected port identifier is already populated in the window. However, should it be required to change the port: Click on the Select button. A list of all Network ports available on that device will appear Select the appropriate port from the list and click on the OK button. The list will clear and the selected port designator will appear in the Port block. If any Encapsulation type other than Null is configured on the port, Outer and Inner Encapsulation Values (to be discussed later in the course) may need to be defined. Select Next or Finish, as desired.
No policies or profiles exist by default Configured and assigned by admin / operator
Next Assign policies and profiles in succession Finish Accept default settings and finish configuration
619
Policies and Filters

Policies and filters permit the network administrator or operator to manage the characteristics of the traffic along the Network Interface and configure various optional parameters. There are no policies nor filters configured within the 5620 SAM default. Each must be implicitly created by the network administrator or operator. Once created, they are available and may be applied at any time. Select the Next button to step through each of the filters and policies to be applied. In each window, the appropriate parameters can be applied by clicking the Select button. Clicking the Finish button in the main configuration window at any time will apply the default values for each parameter within the successive steps. For example, clicking Finish at the point indicated above, will apply the default value for Step 4 through Step 11 and the network Interface configuration will be completed. It is always possible to apply policies and filters at any time in the future without affecting service on the interface. To do so: Search for the Network Interface and either double-click from the list. Select the appropriate tab Click on the Select tab within the appropriate window and select from the list Click OK
Manage Network Interface
6 1 10
Once created, it is possible to view, manage and modify Network Interface configuration using the 5620 SAM. To do so: Open the Properties window by navigating to the Equipment tab of the Navigation Tree Navigate to the appropriate port and right-click. From the contextual menu, select Properties. The Physical Port General Tab window will appear. Select the Network Interface tab, select the network interface, then Properties and the Network Interface window opens. Each tab provides the network administrator or operator with the information that pertains to the present configuration of the interface. Optional parameters, usually represented with white text boxes, and various drop-down menus are available and represent the variables that may be modified without affecting services on the interface. Toggle through each of the tabs to determine the present configuration and modify, as required. For those tabs that list multiple instances (i.e. Network Interfaces), double-click on an entry will open the associated Properties window.
Configure OSPF Area
Area ID - mandatory Area Type Backbone must exist
Confirmation
6 1 11
Configuration planning is essential to organize OSPF areas, interfaces, and virtual links. OSPF provides defaults for basic protocol operability. OSPF configuration requires, as a minimum, that a single OSPF backbone area that contains the area border routers is created. To configure an OSPF Area: Select the OSPF view in the Navigation Tree Select the Network group icon Right-click and select Create Area from the contextual menu. In the Area (Create) window: Specify the OSPF version from the drop-down menu (2 or 3) Define the area ID, usually using a four digit, quasi-IP format. Area 0 (Backbone) must exist. Specify the area Type from the drop-down menu. Backbone Area 0 must exist. Specify the Description, which defines the area type. Select OK or Apply for the changes to take effect. Confirm that the area has been created by expanding the entries below the Network icon the in OSPF view in the Navigation Tree. The newly created area should be present.
Enable OSPF
6 1 12
It is for the service provider to decide which protocols will be used in their managed network. Therefore, all protocols supported by managed devices are disabled by default. To enable protocols on managed devices: Select the Routing view in the Navigation Tree Navigate to the Routing Instance of a managed device Right-click and select Properties from the contextual menu Select the Protocols tab from within the new window Check the appropriate protocol boxes (OSPFv2 or OSPFv3) Click OK or Apply. The protocol will show in the list. Repeat this process for all routers that are to participate in OSPF router within the managed network.
Add OSPF Instance (Router) to OSPF
6 1 13
Though OSPF has been enabled on the device, it is still necessary for the network administrator or operator to define in which area it will participate in order to build its route table. To assign an OSPF area to a device: Switch to the OSPF window in the Navigation Tree. Navigate to the appropriate area and right-click. Select Add OSPF Instance from the contextual menu. In the Instance area in the new window, click on the Select button next to the Instance ID parameter. From the list, highlight the appropriate router and click on the OK button. Repeat this process for all the managed devices to participate in OSPF routing. To confirm that the router has been added to the appropriate OSPF area, expand the area under the OSPF view of the Navigation Tree. The devices should appear in the list.
Add Network Interfaces
6 1 14
Now that the managed devices have been assigned to their respective OSPF areas, it is possible for routers to exchange protocol information to negotiate their operational status and build the route table. To add network interfaces to OSPF: Navigate to the managed device within the OSPF view of the Navigation Tree Right-click on the appropriate Instance and click on the Select button under the select Create Interface section of the OSPF Interface window. Click on Select. Using the Search filter, click on Search as required, list the device(s) that are configured to support OSFP In the Select Interface window, select Search. Select an interface and click the OK button Repeat this process for all interfaces that are to support OSPF.
Manage Network Interfaces
6 1 15
It may be necessary to modify the OSPF characteristics for an interface (i.e. the system interface must be Passive to participate in OSPF). To do so: Select the network interface from the appropriate router listing under the OSPF window of the Navigation Tree Right-click and select Protocol Properties from the contextual menu In the properties window, select the Protocols tab, as shown above Adjust the characteristics and click OK or Apply, as required
Characteristics
Interface Type Broadcast or Point-to-Point. Passive the interface participates in the route table but not in LSAs.
Verify OSPF Status
Interface Status
OSPF Neighbor
6 1 16
Routing Protocol Configuration OSPF Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
OSPF Status
Once OSPF has been configured correctly, the protocol will set about establishing communications with its neighbors and exchange that information amongst network devices. This will build the OSPF route table and each device will learn the route to each of the others. Verifying OSPF status and neighbors within a managed network can be accomplished through either the OSPF view or the Routing view of the navigation Tree (shown above). In either case, expanding the listing under the appropriate area and router will provide the network administrator or operator with the current status of these interfaces. In the example above, (Routing view of the Navigation Tree), the Network Interfaces are listed under the Routing Instance. From this, it is possible to determine that the interface is operation (Status: OK) and its assigned IP address. Expanding the OSPFv2 listing indicates the OSPF area to which the device and its network interfaces are assigned. The information provided above indicates: the protocol properties of each interface operational status function (DR or BDR) the IP address and status of its directly connected OSPF neighbor
Verify OSPF
6 1 17
Once OSPF has been configured in the network, the foundation for the MPLS network has been prepared. Verifying the OSPF route table will allow the network operator or administrator to ensure that all routers and interfaces are participating in the exchange of information. To verify the OSPF route table: Initiate a Telnet or SSH session to a network device From the prompt, type show router route-table and press Enter Verify that the appropriate interfaces are listed in the table. Additionally, it is possible to verify that the interfaces are reachable through the use of the ping (ICMP) utility. To verify that interfaces are participating in the route table: Initiate a Telnet or SSH session to a network device From the prompt, type ping <interface IP address> and press Enter Verify that the interface responds to the ICMP message.
Multiple Routing Instances

Support for multiple instances of the same area in OSPFv2 More than one autonomous network per router One physical router; many virtual routers
Network A Network B
Network C
6 1 18
Routing Protocol Configuration OSPF Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
AS of SAM 5.0, it is possible to configure multiple instances of OSPFv2 within the base router. This permits the service provider to support multiple autonomous networks one the same router using the same area IDs. In essence, a single physical router functions as multiple virtual routers. An example of this implementation is shown above. In this diagram, the service provider has three (3) separate customers with independent networks. Each network requires its own Backbone Area (Area 0) which can be broken out into other Areas, as required. Instead of having one Area 0 for all networks, which would require a mechanism to restrict routing information being exchanged between the various networks, or assigning a separate router to each network. With support for multiple routing instances, the service provider is now able to configure each network as if they were supported on separate routers even though there is only one physical router.
End of Module OSPF Configuration
6 1 19
Last Blank Page

6 1 20
62
Section 6 Routing Protocol Configuration

Module 2 IS-IS Configuration
TOS36013_06_02 Issue 1.1
Document History
622
Routing Protocol Configuration IS-IS Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Configure network interfaces Describe the process to configure IS-IS NET Address Enable IS-IS on managed devices Describe the process to verify IS-IS adjacencies
623
IS-IS
IS-IS is a link-state interior gateway protocol that uses the shortest path first algorithm to determine a Switch to notes view! route. Routing decisions are made using the link-state information. IS-IS entities include: networks, which are autonomous system routing domains intermediate systems, which are routers, such as the 7750 SR and 7710 SR end systems, which are network devices that send and receive Protocol Data Units (PDUs) End systems and intermediate system protocols allow devices and nodes to identify each other. The IS-IS protocol sends link state updates periodically 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 more manageable, smaller 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 SAM supports the configuration of IPv6 addresses for IS-IS adjacencies. After the IS-IS is configured, routing occurs as follows: Hello PDUs are sent to IS-IS-enabled interfacesReserved Alcatel-Lucentneighbors and establish adjacencies. to discover 2009 All Rights 62 4 Routing Protocol Configuration IS-IS Configuration IS-IS SAM 5620 SAM (Service Aware Manager) R7.0 Operator formed. 5620 neighbor relationships are Link-state PDUs are created based on local interfaces and prefixes that are learned from adjacent devices. The devices flood LSPs to adjacent neighbors, and build a link-state database. A shortest path tree is calculated by the IS-IS and the routing table is built.
IS-IS Workflow
Create Network Create Network Interface Interface Numbered (IPv4 / IPv6) Unnumbered
Enable IS-IS Enable IS-IS on device(s) on device(s)
Enable IS-IS on a routing instance
Create IS-IS Create IS-IS NET Address NET Address
Area Identifier Area Type
Add Network Add Network Interface to Interface to IS-IS IS-IS

625
system interface (passive) All other interfaces to be running IS-IS Verify adjacencies
The following workflow outlines the high-level steps necessary to configure the IS-IS protocol in the managed network. 1. Create Network Interface Network ports are used in the service provider transport or infrastructure network, such as an IP/MPLS-enabled backbone network. Network ports can be assigned IP addresses (numbered) and act as Layer 3 interfaces. 2. Enable IS-IS on device(s) Refer to the appropriate technical documents for details on IPv6 supported hardware. 3. Create IS-IS NET Address Unique identifier for each autonomous IS-IS system. 4. Add Network Interfaces to ISIS Adding network interfaces into IS-IS will initiate the exchange of link state information which will, in turn, establish the IS-IS routing table. The system interface must also participate in IS-IS and is automatically assigned when the protocol is enabled. The exchange of routing information can be determined by verifying IS-IS link status and viewing IS-IS neighbours.
626
Network interfaces are used in the service provider transport or infrastructure network, such as an IP/MPLSenabled backbone. Network ports can be assigned IP addresses (numbered) and as Layer 3 interfaces. When network ports act as Layer 3 interfaces, they can pass IP traffic to other devices and communicate using routing protocols, such as ISIS or OSPF. To create a Network Interface: Select the Equipment view in the Navigation Tree Navigate to the appropriate port and right-click From the contextual menu, select Properties Under the General tab, ensure that the Mode parameter is set to Network Ensure the port MTU is set to a value large enough to support the underlying protocols, particularly MPLS Select the Network Interfaces tab Click on the Add button

Name mandatory (highlighted) Description - optional
Numbered assign an IP address Unnumbered no IP assigned
627
The Create Network Interface wizard opens. This is a multiple step process and is repeated for each network interface to be created. Complete each step of the wizard and select Next to move to the next step. Selecting Finish at any point in the wizard will apply the default settings of the remaining steps to the interface and close the wizard.
General Properties
Name highlighted, meaning mandatory. All interfaces must have a name. Description (optional) Used to help find the interface at a later time. IPv6 allowed checking the box will allow the network administrator or operator to configure IPv6 parameters, as required. Additional steps will appear in the wizard. MAC Address manually configure an interface MAC, if required. Leave at default for most applications. Class Numbered if an IP address is to be assigned; Unnumbered if no IP address Port MTU is set to a value large enough to support the underlying protocols, particularly MPLS click on the Next button
Assign IP Address
IP Address and Subnet (Numbered) as per network configuration Network ID primary address (ID # 1) or up to 15 secondary addresses Click OK to return to the main configuration wizard window. Click Next
Create Network Interface [Cont.]
628
Select Port
If the network administrator or operator has already selected the port at the beginning of this process, the selected port identifier is already populated in the window. However, should it be required to change the port: Click on the Select button. A list of all Network ports available on that device will appear Select the appropriate port from the list and click on the OK button. The list will clear and the selected port designator will appear in the Port block. If any Encapsulation type other than Null is configured on the port, Outer and Inner Encapsulation Values (to be discussed later in the course) may need to be defined. Select Next or Finish, as desired.
Create Network Interface [Cont.]
No policies or profiles exist by default Configured and assigned by admin / operator
Next Assign policies and profiles in succession Finish Accept default settings and finish configuration
629
Policies and Filters

Policies and filters permit the network administrator or operator to manage the characteristics of the traffic along the Network Interface and configure various optional parameters. There are no policies nor filters configured within the 5620 SAM default. Each must be implicitly created by the network administrator or operator. Once created, they are available and may be applied at any time. Select the Next button to step through each of the filters and policies to be applied. In each window, the appropriate parameters can be applied by clicking the Select button. Clicking the Finish button in the main configuration window at any time will apply the default values for each parameter within the successive steps. For example, clicking Finish at the point indicated above, will apply the default value for Step 4 through Step 11 and the network Interface configuration will be completed. It is always possible to apply policies and filters at any time in the future without affecting service on the interface. To do so: Search for the Network Interface and either double-click from the list. Select the appropriate tab Click on the Select tab within the appropriate window and select from the list Click OK
Manage Network Interface
6 2 10
Once created, it is possible to view, manage and modify Network Interface configuration using the 5620 SAM. To do so: Open the Properties window by navigating to the Equipment tab of the Navigation Tree Navigate to the appropriate port and right-click. From the contextual menu, select Properties. The Physical Port General Tab window will appear. Select the Network Interface tab, select the network interface, then Properties and the Network Interface window opens. Each tab provides the network administrator or operator with the information that pertains to the present configuration of the interface. Optional parameters, usually represented with white text boxes, and various drop-down menus are available and represent the variables that may be modified without affecting services on the interface. Toggle through each of the tabs to determine the present configuration and modify, as required. For those tabs that list multiple instances (i.e. Network Interfaces), double-click on an entry will open the associated Properties window.
Enable IS-IS
6 2 11
It is for the service provider to decide which protocols will be used in their managed network. Therefore, all protocols supported by managed devices are disabled by default. To enable protocols on managed devices: Select the Routing view in the Navigation Tree Navigate to the Routing Instance of a managed device Right-click and select Properties from the contextual menu Select the Protocols tab from within the new window Check the appropriate protocol box (IS-IS) Click OK or Apply. The protocol will show in the list. Repeat this process for all routers that are to participate in IS-IS routing instance.
Create NET Address
6 2 12
Though IS-IS has been enabled on the device, it is still necessary for the network administrator or operator to define in which area it will participate in order to build its route table. To assign an IS-IS NET Address (IS-IS Area) to a device: Navigate to the appropriate device in the Routing tab of the Navigation Tree Select the IS-IS protocol under the Routing Instance of the appropriate device Right-click and select Add NET Address from the contextual menu Enter the NET Address in the Area ID parameter block and click the OK or Apply button Repeat this process for all the managed devices to participate in IS-IS routing. To confirm that the router has been added to the appropriate IS-IS area, expand the area under the IS-IS view of the Navigation Tree. The devices should appear in the list.
Add Network Interfaces
OK
Apply
6 2 13
Now that the managed devices have been assigned to their respective IS-IS Level, it is possible for routers to exchange protocol information to negotiate their operational status and build the route table. To add network interfaces to ISIS: Navigate to the appropriate device in the Routing tab of the Navigation Tree Select the IS-IS protocol under the Routing Instance of the appropriate device Right-click and select Create Interface from the contextual menu Under the General tab, click on the Select button next to the Interface Name Enter a Description (optional) Configure the Capability parameters from the drop-down menus, as required Type Broadcast or Point-to-Point Level Compatibility Level 1/ Level 2 / Level 1 and 2 Click the OK or Apply button Click the Search button. A list of available interfaces based upon the Search filter criteria will appear. Double-click on an interface or select it from the list and click OK Repeat this process for all interfaces that are to support IS-IS.
Verify IS-IS Status
Interface Status
IS-IS Neighbor
IS-IS Status
6 2 14
Once IS-IS has been configured correctly, the protocol will set about establishing communications with its neighbors and exchange that information amongst network devices. This will build the IS-IS route table and each device will learn the route to each of the others. Verifying IS-IS status and neighbors within a managed network can be accomplished through either the IS-IS view or the Routing view of the Navigation Tree (shown above). In either case, expanding the listing under the appropriate area and router will provide the network administrator or operator with the current status of these interfaces. In the example above, (Routing view of the Navigation Tree), the Network Interfaces are listed under the Routing Instance. From this, it is possible to determine that the interface is operation (Status: OK) and its assigned IP address. Expanding the IS-IS listing indicates the IS-IS area to which the device and its network interfaces are assigned. The information provided above indicates: the protocol properties of each interface operational status the IP address and status of its directly connected IS-IS neighbor. Level 1 and Level 2 neighbors will appear independently of each other.
Verify IS-IS
6 2 15
Once IS-IS has been configured in the network, the foundation for the MPLS network has been prepared. Verifying the IS-IS route table will allow the network operator or administrator to ensure that all routers and interfaces are participating in the exchange of information. To verify the IS-IS route table: Initiate a Telnet or SSH session to a network device From the prompt, type show router route-table and press Enter Verify that the appropriate interfaces are listed in the table. [Inserted Note] OSPF routes have a higher preference that IS-IS routes. Therefore, IS-IS routes will not be displayed on the routing table should OSPF routes have been previously configured. Additionally, it is possible to verify that the interfaces are reachable through the use of the ping (icmp) utility. To verify that interfaces are participating in the route table: Initiate a Telnet or SSH session to a network device From the prompt, type ping <interface IP address> and press Enter Verify that the interface responds to the icmp message.
Note
Blank Page
6 2 16
End of Module IS-IS Configuration
6 2 17
Last Blank Page

6 2 18
71
Section 7 MPLS Infrastructure Configuration

Module 1 MPLS using LSPs
TOS36013_07_01 Issue 1.1
Document History
712
MPLS Infrastructure Configuration MPLS using LSPs 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Configuring MPLS using LSPs
713
MPLS using LSP Configuration Workflow

Create MPLS Create MPLS interfaces interfaces
Enable MPLS & RSVP protocols Add interfaces to MPLS
Create MPLS Create MPLS Paths Paths
Create MPLS Paths: Name the Paths Designate Start Node and End Node Select Strict or Loose Hop Type
Signaled Signaled LSPs LSPs
Create RSVP-TE signaled LSPs: Name the LSPs Designate the Source and and Destination Site IDs
Manage LSPs Manage LSPs

714
View LSPs (Topology View) LSP Ping LSP Trace

As already discussed, the purpose of using MPLS in a network is to eliminate the decision making process required of a Layer 3 network where a routing decision is required at each hop. The two mechanisms supported in a 7x50 network are implementing RSVP-signaled LSPs or using LDP. The workflow illustrated above defines the process required to implement RSVP-signaled LSPs in the carriers network. As illustrated, the process will require that the network operator or administrator ensure that: the MPLS protocol is enable (RSVP will be enabled at the same time as a default action) MPLS Paths are created RSVP-signaled LSPs are created and associated to an MPLS Path Once created, the network operator or administrator will be able to view: The LSP Topology through the GUI Perform LSP OAM tests to ensure connectivity.
Note
[Inserted Note] The Source IP Address for a given node, should be its Source System ID.
Enable MPLS
1. Select Properties
2. Ensure MPLS and RSVP are Enabled
715
Regardless of whether the network carrier intends to implement a RSVP-signaled LSP infrastructure, or build their network using the LDP protocol, the MPLS protocol must be enabled on all devices that are to participate in the MPLS infrastructure. To enable the MPLS protocol on 5620 SAM managed devices: Select the Routing view in the Navigation Tree Navigate to, and select, the Routing Instance of the appropriate network element Right-click and select Properties from the contextual menu In the new window, select the Protocols tab Then click on the box next to MPLS Enabled. Click OK or Apply, then note that the RSVP Enabled box will also be checked. Select OK or Apply to save the configuration changes. Note that the MPLS and RSVP protocols are now listed under the Routing Instance in the Navigation Tree.
MPLS Interface Creation

1. Select Create Interface
2. Click Select
716
Any interface that is to support MPLS LSPs, either RSVP or LDP, must be included in the MPLS instance of the network device(s). To create MPLS interfaces: Select the MPLS instance under the appropriate network devices Routing Instance Right-click and select Create Interface from the contextual menu In the new window (MPLS Interface (Create)), click on the Select button in the Interface section
MPLS Interface Creation

1. Select an Interface
2. If required, enter a description. Then click OK
717
A search window will appear. Set the Search filter options, as required, and click on the Search button. Select the appropriate interface from the list and click on the OK button on the left side of the window The 5620 SAM will return the network operator or administrator to the Create window. Complete the configuration by entering a Description, if required, and click on the OK or Apply button. Repeat this process for each of the interfaces to be included in the MPLS routing instance.
MPLS Path Creation

1. Select Manage MPLSMPLS Paths 2. Select Create
718
A RSVP-signaled LSP must be associated to a MPLS Path to be able to establish its routing to the destination device through the network. To create a MPLS Path: From the main menu, select Manage MPLS MPLS Paths In the new window, click on the Create Button.
MPLS Path Creation [Cont.]

Name the LSP Path
719
The configuration wizard appears which will guide the network operator or administration through a series of configuration steps to ensure the proper configuration of the MPLS Path. Specify the interface Name and Description, as required. Specifying these parameters will assist the network operator or administrator to identify the MPLS Path using the Search filter in the future. The structure of these parameters is defined as part of the carriers corporate policy. Click on the Next button to continue the MPLS Path configuration.
MPLS Path Creation Source Site

1.Click Select 2. Choose the Source Site 3. Click OK
Starting Network Element is now populated. 4. Click Next to continue
7 1 10
Specify the Source Site for the MPLS path by clicking on the Select button. Select the appropriate network element from the list and click on the OK button. The Starting Network Element is now populated. Click the Next button to move to the next step.
MPLS Path Creation Provisioned Path

1. Click Insert Hop 2. Select Hop Type 3. Click Select
4. Choose the Next Hop Element from the list
5. Click OK, then Finish then Close, then Close
`
7 1 11
MPLS Infrastructure Configuration MPLS using LSPs 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
The Define Provisioned Path window appears. In this window, the network operator or administrator will define the MPLS Path, as well as specify whether the path will be loose, uses the IGP route table to find the destination network element, or strict, which will override the IGP route table and force the path through a specific network element. A strict path must be specified hop by hop. In either configuration, the final hop must be the destination site. To configure the MPLS Path: Click on the Insert Hop button In the new window, specify the site for the next hop either Manually or click on the Select button and choose the appropriate site from the list available. Click on the OK button. Set the Hop Type to loose or strict from the drop-down menu, as required. Click on the OK button. Set the Initial State from the drop-down menu, as required, select Finish. The MPLS Path has been configured. Repeat the process for the remaining MPLS Paths to be created. Remember that a MPLS Path is unidirectional.
LSP Creation
1.Select Manage MPLS Dynamic LSPs 2.Click Create
3.Name the LSP
7 1 12
RSVP-signaled LSPs are associated with MPLS Paths to be able to establish the end-to-end communication required to exchange labels. To create LSPs: From the main menu, select Manage MPLS Dynamic LSPs In the new window, click on the Create Button. Specify the interface Name and Description, as required. Specifying these parameters will assist the network operator or administrator to identify the MPLS Path using the Search filter in the future. The structure of these parameters is defined as part of the carriers corporate policy. Click on the Next button to continue the MPLS Path configuration.
LSP Creation Source and Destination

1. Click Select 2. Choose the Source Element
3. Select the Destination IP Address
7 1 13
The configuration wizard now prompts the network operator or administrator to define the source and destination sites. To do so: Click on the Select button in the Source section of the window A list of available network elements will appear. Select the appropriate device and click on the OK button. The site information will be populated into the configuration window. Complete the same process for the Destination site by clicking on the Select button in the appropriate section pf the window, selecting the appropriate network element from the list and clicking the OK button. The Destination site information will be populated in the configuration window. Click on the Next button to advance the configuration wizard to the next step.
LSP Creation Path Type

1.Select Add 2.Select Primary, then Select Next
3. Select the created path
7 1 14
Click on the Add button to associate an MPLS Path to the LSP. The 5620 SAM opens a sub-wizard. Define the Path Type (primary or secondary) from the drop-down menu and click on the Next button. Choose the appropriate MPLS Path from the list and click on the Next button. The network operator or administrator is also able to view the Properties for the selected MPLS Path or create a new one, if required. Set Traffic Options, as required, or click on Finish to accept the default values and complete the subwizard configuration.
LSP Creation Complete and Verify Configuration

1.Select OK 2.Select Finish
4.View LSP 3.Select the check box then select Close
7 1 15
Click the OK button in the Warning window. The MPLS path will appear in the list, indicating that MPLS Path has been associated with the LSP. However, the changes will not be deployed to the router and stored in the 5620 SAM database until the Finish button in the containing Window has been clicked. Complete the LSP configuration by advancing through each step by clicking on the Next button and assigning the appropriate parameters Click on the Finish button at any point in the configuration wizard assigns the default values for each of the remaining steps. Repeat the process for each LSP to be created. To view the LSP configuration (Properties), either select View the newly created Dynamic LSP or, select Manage MPLS Dynamic LSPs from the main menu.
LSP Topology View

Select LSP Topology
7 1 16
The 5620 SAM GUI enables the network operator or administrator to view the LSP Topology in the carriers network. To view the topology, select LSP Topology from the drop-down menu in the Map View window. The map will display the LSP connectivity between network elements. An arrowhead indicates that the direction of the LSP (Remember: LSPs are unidirectional). A plus sign (+) indicates that at least one set of bidirectional LSPs exists between the two network elements. Selecting the arrowhead or + sign and right-click on the mouse will permit the network operator to list the LSPs from the contextual menu. Once listed, select the appropriate LSP and perform the management functions provided by the action buttons on the right side of the window, as required.
OAM - LSP Ping
7 1 17
The LSP ping OAM tool, which is called lsp-ping in CLI, performs in-band LSP connectivity tests. The following information can be determined from the test: detect data plane failures in LSPs and with LSP connectivity test whether the LSP tunnels are working in both directions In an LSP ping, the originating router creates an MPLS echo request probe for the LSP and MPLS path to be tested. The MPLS echo request probe is sent and awaits an MPLS echo reply packet from the router that terminates the LSP. The status of the LSP is displayed when the MPLS echo reply probe is received. To configure and execute an LSP Ping OAM: Select Manage MPLS Dynamic LSP from the Main menu Use the configurable filters choices and properties options on the form and click on the Search button. The list displays the available LSPs that meet the selected filter criteria. . Select the appropriate LSP from the list and click on the Properties button Open the Tests window and select the LSP Ping tab Clicking in the Create button opens a new window thus permitting the network operator or administrator to configure an LSP Ping test.
LSP Ping - Create
Name and Description (optional) Node and MPLS Site
LSP information
7 1 18
For an network operator or administrator to be able to effect a test, they will first be required to configure and save various parameters. Once saved, the test can be executed against the network object and the results saved in the 5620 SAM database. Under the General tab of the Create LSP Ping test configuration window, the network operator or administrator can configure the following: Name used to identify the particular test amongst the various tests that may be created. This parameter is optional for the 5620 SAM and is set based upon corporate policy. Description - used to identify the particular test amongst the various tests that may be created. This parameter is optional for the 5620 SAM and is set based upon corporate policy. Target Type defines the endpoint network device for the LSP under test. This parameter is automatically based upon the LSP selected. MPLS Site defines the MPLS Path endpoint and is automatically populated based upon the LSP selected. The network operator or administrator can view the MPLS Path configuration by clicking in the Properties button. LSP defines the ID number and Name of the LSP under test and is automatically populated based upon the LSP selected. The network operator or administrator can view the MPLS Path configuration by clicking in the Properties button. Click the Apply button to save these and keep the window open.
LSP Ping Test Parameters
Execution Details
Number of Probes Packet Interval Packet Timeout
Test Probe packet

configuration information Size Time To Live Forwarding Class Forwarding Profile
7 1 19
The Test Parameters window enables the network operator or administrator to configure the test probes. These parameters are grouped into two categories: the execution details, which defines how the test probes will behave during the test; and, how the test probes are configured. Set the parameters, as required, and click on the Apply button to save the changes and keep the LSP Ping test configuration window open.
Execution Details
Number of Probes specifies the number of packets to be sent along the LSP under test. Packet Interval (seconds) parameter specifies the minimum amount of time, in seconds, that must expire before the next message request is sent. The range is 1 to 10. The default is 1. Probe Timeout (seconds) parameter specifies the time, in seconds, before a message request times out and is aborted. The message request depends on receiving a message reply from the target corresponding to the outstanding request.
Test Probe
Probe Size (octets) parameter specifies the size, in octets, of the message in an OAM diagnostic. The range is 40 to 9198. Time To Live parameter specifies the TTL value, in hops, added to the test packet to ensure that the probe does not circulate in a routing loop past the configured time. Forwarding Class parameter specifies the forwarding class for a tunnel ping, MAC ping, or LSP ping or trace. Forwarding Profile parameter specifies whether the test probes are in or out of profile, as compared to the forwarding class of the test packet.
LSP Ping Results Configuration

How results are stored in the database
Number of Entries Test Failures Probe Failures Trap Generation
7 1 20
The Results Configuration window enables the network operator or administrator to define how the test results will be formatted. Configure the parameters, as required, and click the OK or Apply button to save the configuration changes.
Parameters
History Size (rows) parameter specifies the number of OAM history rows that can be stored on the managed device probe results table. The range is 0 to 99,000,000. The default is 50. When the parameter setting has been exceeded, the device removes the oldest entry in the table to allow a new history row. Test Failure parameter specifies whether the managed device on which the OAM test failed should raise an SNMP trap to indicate a test failure. The test failure trap is raised once the value set for the Test Failure Threshold parameter is reached. Test Failure Threshold parameter specifies the number of times a probe can fail before an indication of failure is provided. This parameter has no effect if the value is higher than the value for the Probes to be Issued parameter. The range is 0 to 15. The default is 1. Trap Generation specifies the condition(s) that will generate a trap within the 5620 SAM. Test Completion is set by default however, the network operator or administrator may also select Test Failure, which will generate a trap should the test fail, and Probe Failure, in which case, a trap will be generated for each probe that fails during the test.
LSP Ping Execute
7 1 21
Once a test has been configured and saved, it will appear in the list of available tests in under the Tests tab of the Dynamic LSP window and is available to be used to test, as shown above. To conduct an LSP Ping test: Open the LSP Ping tab from the Tests window (Manage MPLS Dynamic LSPs Tests) The available tests for the selected LSP will appear in the list. Select the appropriate test and click on the Execute button. The 5629 SAM will perform the test based upon the saved configuration parameters.
View Test Results

To view the test results: Select the appropriate LSP test and click on the Properties button and select the Results tab Set the Search filter parameters, as required, and select the appropriate test from the list. Use the configurable filters choices and properties options on the Service Test Manager form and click on the Search button. The list of test results that meet the filter criteria are displayed. Click on the Properties button
LSP Ping Results
7 1 22
The filtered list of test results will be listed in the LSP Ping Results window. Select the appropriate Results listing and click on the Properties button which opens a new multi-tab window. Review the information under each of the tabs to determine the results of the LSP Ping test. General tab provides a summary of the test results, including: the time it was effected; who initiated the test; the status of the test; and other such information. Details tab provides more specific information about the LSP performance measured in Round Trip Time and Inbound and Outbound One Way Travel Time.
LSP Ping Results [Cont.]
7 1 23
Response Probes tab provides the network operator or administrator to information about the performance of each probe sent during the test. Top view each probes details: Use the scroll bar at the bottom to move the listing from left to right, or Select an entry in the list and click on the Properties button. The packet information will appear in a new window.
OAM LSP Trace
7 1 24
The LSP trace OAM tool, which is called lsp-trace in CLI, displays the hop-by-hop route used by the LSP. The following information can be determined from the test: hop-by-hop path for an LSP destination path of the packets In an LSP trace, the originating router creates an MPLS echo request packet for the LSP to be tested. The packet contains increasing TTL values. The MPLS echo request packet is sent and awaits a TTL exceeded response or the MPLS echo reply packet from the router that terminates the LSP. The devices along the hop-by-hop route reply to the MPLS echo request packets with TTL and MPLS echo reply information. To configure and execute an LSP Trace OAM: Select Manage MPLS Dynamic LSPs from the Main menu. Use the configurable filters choices and properties options on the form and click on the Search button. The list displays the available LSPs that meet the selected filter criteria. Select the appropriate LSP from the list and click on the Properties button Open the Tests window and select the LSP Trace tab Clicking in the Create button opens a new window thus permitting the network operator or administrator to configure an LSP Trace test.
LSP Trace - Create
Name and Description (optional) Node and MPLS Site
LSP information
7 1 25
For an network operator or administrator to be able to effect a test, they will first be required to configure and save various parameters. Once saved, the test can be executed against the network object and the results saved in the 5620 SAM database. Under the General tab of the Create LSP Trace test configuration window, the network operator or administrator can configure the following: Name used to identify the particular test amongst the various tests that may be created. This parameter is optional for the 5620 SAM and is set based upon corporate policy. Description - used to identify the particular test amongst the various tests that may be created. This parameter is optional for the 5620 SAM and is set based upon corporate policy. Target Type defines the endpoint network device for the LSP under test. This parameter is automatically based upon the LSP selected. MPLS Site defines the MPLS Path endpoint and is automatically populated based upon the LSP selected. The network operator or administrator can view the MPLS Path configuration by clicking in the Properties button. LSP defines the ID number and Name of the LSP under test and is automatically populated based upon the LSP selected. The network operator or administrator can view the MPLS Path configuration by clicking in the Properties button. Click the Apply button to save these and keep the window open.
LSP Trace Test Parameters
Execution Details
Number of Probes Packet Interval Packet Timeout
Test Probe packet

configuration information Size Time To Live Forwarding Class Forwarding Profile
7 1 26
The Test Parameters window enables the network operator or administrator to configure the test probes. These parameters are grouped into two categories: the execution details, which defines how the test probes will behave during the test; and, how the test probes are configured. Set the parameters, as required, and click on the Apply button to save the changes and keep the LSP Ping test configuration window open.
Execution Details
Number of Probes specifies the number of probes to be sent along the LSP under test. Packet Interval (seconds) parameter specifies the minimum amount of time, in seconds, that must expire before the next message request is sent. The range is 1 to 10. The default is 1. Probe Timeout (seconds) parameter specifies the time, in seconds, before a message request times out and is aborted. The message request depends on receiving a message reply from the target corresponding to the outstanding request.
Test Probe
Probe Size (octets) parameter specifies the size, in octets, of the message in an OAM diagnostic. The range is 40 to 9198. Time To Live parameters specifies the TTL value, in hops, added to the test packet to ensure that the probe does not circulate in a routing loop past the configured time. Forwarding Class parameter specifies the forwarding class for a tunnel ping, MAC ping, or LSP ping or trace. Forwarding Profile parameter specifies whether the test probes are in or out of profile, as compared to the forwarding class of the test probe.
LSP Trace Results Configuration

Number of Entries Maximum Failures Trap Generation
7 1 27
Parameters
Probe History Size (rows) parameter specifies the number of OAM history rows that can be stored on the managed device probe results table. The range is 0 to 99 000 000. The default is 50. When the parameter setting has been exceeded, the device removes the oldest entry in the table to allow a new history row. Maximum Failures parameter specifies how many packet arrival failures are allowed before the OAM test is considered failed. The range is 0 to 255. The default is 5. A value of 0 or 255 specifies no maximum number of failures; the test continues to run, no matter the number of time outs. Trap Generation specifies the condition(s) that will generate a trap within the 5620 SAM. Test Completion is set by default however, the network operator or administrator may also select Test Failure, which will generate a trap should the test fail and Path Change The Path Change parameter specifies whether the managed device on which the OAM test was issued should raise an SNMP trap to indicate that the path changed during the test. When this happens, the list of hops associated with this test result are suspect, and may contain hops from before and after the path change. The trap is raised once the Path Change Threshold is reached. The options are: enabled disabled (default)
LSP Trace Execute
7 1 28
Once a test has been configured and saved, it will appear in the list of available tests in under the Tests tab of the Dynamic LSP window and is available to be used to test, as shown above. To conduct an LSP Trace test: Open the LSP Trace tab from the Tests window (Manage MPLS Dynamic LSPs Tests) The available tests for the selected LSP will appear in the list. Select the appropriate test and click on the Execute button. The 5620 SAM will perform the test based upon the saved configuration parameters.
View Test Results

To view the test results: Select the appropriate LSP test and click on the Properties button and select the Results tab Set the Search filter parameters, as required, and select the appropriate test from the list. The Search filter permits the network operator or administrator to define search criteria (single or multiple) to reduce the number of objects to be listed. Click on Search. Click on the Properties button
LSP Trace Results
7 1 29
Viewing Results
The filtered list of test results will be listed in the LSP Ping Results window. Select the appropriate Results listing and click on the Properties button which opens a new multi-tab window. Review the information under each of the tabs to determine the results of the LSP Ping test. General tab provides a summary of the test results, including: the time it was effected; who initiated the test; the status of the test; and other such information. Hops and Probes tab provides more specific information about each hop along the LSP and each specific hop in a tabular form. Clicking on the key tab next to each of the entries provides the detailed information for that entry. Review as required.
Blank Page
7 1 30
End of Module MPLS using LSPs
7 1 31
Last Blank Page

7 1 32
72

Module 2 MPLS using LDP
TOS36013_07_02 Issue 1.1
Document History
722
MPLS Infrastructure Configuration MPLS using LDP 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Configuring MPLS using LDP (Label Distribution Protocol)
723
MPLS using LDP Configuration Workflow
LDP LDP Interfaces Interfaces
Create LDP Interfaces

Enable LDP Create LDP interfaces
Targeted Peers Targeted Peers (if required) (if required)
Create Targeted Peers

Enable LDP Create Targeted Peers
Manage LDP Manage LDP interfaces interfaces
Verify interface status View interface properties Enable or disable interface, as required Remove interface
724
The chart above provides the workflow for configuring and managing LDP in the network. 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. After LDP distributes the labels to the LSR, the LSR assigns the label to a FEC, and then informs all other LSRs in the path about the label and how the label will switch data accordingly. Targeted Peers non-directly connected LDP peers
Enable LDP Protocol
725
To create an LDP interface, the network operator or administrator must enable the LDP protocol on the appropriate router(s). To enable LDP: From the Routing view in the Navigation tree, select the Routing Instance of the appropriate router Right-click and select Properties from the contextual menu; In the Routing Instance window, select the Protocols tabs and check the box next to LDP Enabled; Click OK or Apply to save the changes, then select Yes. Note that LDP now appears in the list of protocols and under the Routing Instance of the appropriate router.
LDP Interface Creation
OK
Apply
726
Once LDP has been enabled, it is possible to create an LDP interface. To do so: Navigate to the appropriate Routing Instance and select LDP; Right-click and select Create Interface from the contextual menu; Click the Select button in the Interface block of the new window; Set the Search filters, as required and click on the Search button. Available interfaces will appear in the list. Select the appropriate interface and click on the OK button; Select the OK or Apply button in the Containing window. Repeat this process for each interface to be added to the LDP instance.
Verify LDP Interfaces
727
To verify that the interface has been added to LDP instance: Navigate to the LDP instance under the appropriate Routing Instance Click on the key at the left of the LDP instance to expand the interface listing. The interface status will also be indicated.
Targeted Peers
728
Create Targeted Peers

Should it become necessary to establish an LDP session between routers that are not directly connected, the network operator or administrator will be required to create Targeted Peers. To do so with the 5620 SAM: Ensure the LDP is enabled on the source and destination routers, as already discussed. Navigate to the appropriate Routing Instance and select LDP; Right-click and select Create Targeted Peers from the contextual menu; Enter the Router ID (typically the system interface address) in the Peer Address block. Since the block is highlighted, this is a mandatory parameter. Add a Description, if desired. Doing so will enable the network operator or administrator to use the Search function to find the interface more easily. Select the OK or Apply button in the Containing window. Repeat this process for each Targeted Peer. To verify that the Targeted Peer has been successfully created: Navigate to the LDP instance under the appropriate Routing Instance Click on the key at the left of the LDP instance, then the Targeted Peers instance to expand the interface listing. The interface status will also be indicated.
End of Module MPLS using LDP
729
Last Blank Page

7 2 10
73

Module 3 Traffic Engineering
TOS36013_07_03 Issue 1.1
Document History
732
MPLS Infrastructure Configuration Traffic Engineering 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Describe the process to enable the IGP to support traffic engineering Configure secondary LSP protection Configure dynamic LSP protection
733
Traffic Engineering Workflow

Enable TE Enable TE on IGP on IGP
Select the IGP Instance Enable Traffic Engineering
Configure TE Configure TE on LSPs on LSPs
Enable Traffic Engineering and Protection Enable Make Before Break Enable CSPF
Create Create Secondary Paths Secondary Paths
Create Standby LSP, if required Create Secondary LSP, if required
Manage Manage LSPs LSPs

734
View status Display Properties
Enable TE on IGP
735
Enable TE on IGP
To be able to implement traffic engineering in a network, it is first necessary to modify the behavior of the IGP within the network so as to support this function. Use the following steps to do so: From the Navigation Tree Routing view,navigate to the IGP Routing Instance. Right-click and select Properties from the contextual menu. Open the Behavior tab in the Properties window. In the dropdown menu next Traffic Engineering Support, select true and click OK or Apply. The Traffic Engineering function for the IGP is now enabled and can be used by the LSPs.
List LSPs
736
List LSP
Now that Traffic Engineering has been enabled on the IGP (OSPF in this example), it is possible to configure RSVP-signaled LSP for Fast Reroute; a dynamic path protection mechanism discussed earlier in the course. It is possible to edit the configuration of an existing LSP without service interruption or create Traffic Engineered paths from the beginning.
Edit an Existing LSP

To edit the configuration of an existing LSP without service disruption: Select Manage MPLS Dynamic LSPs from the main menu. Click on the Search button to list the existing LSPs. Defining a specific Source Site and /or Destination Site will refine the Search criteria and provide a modified listing should the network operator or administrator so desire. Select the appropriate LSP from the list and click on the Properties button.
LSP Properties
737
LSP Properties
From the Dynamic LSPs window, select the Properties tab, then change the following parameters, as required: Traffic Engineering and Protection- from the dropdown menu, select true and set the Hop Limit, as required. Once this parameter has been changed, the window will refresh to display an additional set of parameters to be configured. Fast Reroute from the dropdown menu, select either One To One or Many To One, the mechanisms which have been discussed earlier in the course. Set the Hop Limit, as required. Make before Break The RRO function keeps track of RSVP-signaled LSPs through the network from PE To PE. Since there is a record of this path, it is possible to restore a failed LSP back to its original path. This option ensures that the original path is signaled and operationally up before restoring a failed LSP. CSPF from the dropdown menu, select true to enable the Constraint-based shortest Path First algorithm previously discussed in this course. Click OK or Apply to effect the changes in the network configuration.
Creating a New T-E LSP

To create a new traffic-engineered LSP, the network operator or administrator uses the procedure as discussed earlier in the course. When prompted, ensure the parameters discussed above are set to true and save the configuration.
Secondary LSPs
List the Primary LSP
738
Secondary LSP
The alternate method of providing LSP protection is through the use of Secondary LSPs, as discussed earlier in the course. To create a Secondary LSP, first ensure that a primary LSP is configured and established. Once this has been completed, create the Secondary LSP as follows: List the LSPs, as shown above. Select the LSP to which this protection mechanism will be configured. Click on the Properties button.
Secondary LSP - Create
739
LSP Properties
From the Dynamic LSPs window, navigate to the LSP Path Bindings tab. All existing LSP paths associated with the selected entry will be displayed in the list. Note that the Type column indicates that the LSP is set to primary. This is the LSP that will be protected by secondary paths. To configure a secondary LSP: Select the primary path and click on the Add button. The LSP-Path Binding Wizard window will open. On the LSP-Path Binding Wizard - Step 1. Choose the Path window, choose Type as secondary and click Next.
Secondary LSP - Create [Cont.]
7 3 10
Secondary LSP
All available LSPs between the source and destination site will be listed in the Choose MPLS Path window. Select the appropriate MPLS path and click next. Note that the network operator or administrator may Create MPLS Path or view the Properties of the existing MPLS path from this window, if required. Click on the Next button. Set Traffic Options permits the network operator or administrator to assign any bandwidth reservation requirements for the LSP. Select Next to configure the Administrative Status or Finish to accept the default status (UP). The secondary LSP will set up its signaled path and is now ready to pass traffic in the case of the primary failure. Each primary LSP may support up to eight secondary LSPs. It is important to remember that this mechanism of path protection is revertive to the primary LSP but not between secondary LSPs.
Verify Secondary LSPs
7 3 11
Verifying and managing secondary LSPs is the same process as it is for primary LSPs. From the main menu, select Manage List and select the appropriate LSP Click on the Properties button In the Dynamic LSP window, select the LSP-Path Bindings tab. All LSPs associated to the selected entry will be listed. Note that there will be one entry Type configured as primary and the others will be set for secondary. Manage the LSPs as already discussed during this course. MPLS Dynamic LSPs
Blank Page
7 3 12
End of Module Traffic Engineering
7 3 13
Last Blank Page

7 3 14
81
Section 8 Basic Services

TOS36013_08_01 Issue 1.1
Module 1 Service Tunnel Configuration
Document History
812
Basic Services Service Tunnel Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Describe the process to configure service tunnels
813
Service Tunnel Configuration Workflow
Service Tunnel Service Tunnel Initiation Initiation
Select Manage Service Tunnels Select Create Name the Service Tunnel
Service Tunnel Service Tunnel Endpoint Endpoint Designation Designation
Select Source and Destination Site IDs Ensure the underlying transport is MPLS Ensure TLDP signaling is enabled
LSP Binding LSP Binding
Bind an LSP to the Service Tunnel View the Service Tunnel Topology
814
As already discussed, Service Tunnels are the mechanism over which the network provider will pass customer traffic from PE to PE over their MPLS infrastructure. Once a service has been associated to a service tunnel, a Service Distribution Path (SDP) is created and is thus the CLI equivalent. As illustrated above, the process to create service tunnels will require that the network operator or administrator: Define the start and endpoint nodes of the service tunnel Define the label switching mechanism (LDP, RSVP or GRE) Ensure t-LDP is enabled Bind an LSP to the service tunnel Once created, the network operator or administrator will be able to view: The Service Tunnel Topology through the GUI Perform Service Tunnel OAM test to ensure connectivity.
Service Tunnel - Create

1.Select Manage Service Tunnels 2.Select Create
815
The number of service tunnels to be created will depend upon the network design and implementation philosophy of each network provider. To create a Service Tunnel: From the Main Menu, select Manage Service Tunnels In the new window, click on the Create button. The network operator or administrator may deselect the Any Source and Any Destination box to manually assign the source and destination nodes for the service tunnel. In this case, these parameters will be automatically populated in the configuration wizard.
Service Tunnel Create [Cont.]
816
The configuration wizard appears which will guide the network operator or administrator through a series of configuration steps to ensure the proper configuration of the service tunnel. Specify the service tunnel Name and Description, as required. Populating these parameters will assist the network operator or administrator to identify the service tunnel using the Search filter in the future. The structure of the parameters is defined as part of the carriers corporate policy. Click on the Next button to continue the service tunnel configuration.
Service Tunnel Endpoint Designation
1. Click Select
2. Choose the tunnel source
817
Specify the Source Site ID for the service tunnel by clicking on the Select button, and the Next or Finish button at the bottom of the page will not be activated until correctly populated. If a specific source site was selected in the previous step, its ID will be automatically populated in this window. Select the appropriate node from the list and click OK Click on the Next button to continue the configuration process
Service Tunnel Endpoint Designation [Cont.]
1.Click Select
2.Choose the tunnel destination
818
Specify the Destination Site ID for the service tunnel by clicking on the Select button. Note that the configuration box is highlighted yellow meaning that this is a mandatory parameter and the Next or Finish button at the bottom of the page will not be activated until correctly populated. If a specific source site was selected in the previous step, its ID will be automatically populated in this window. Select the appropriate node from the list and click OK. Click on the Next button to continue the configuration process.
Service Tunnel - Transport
819
Specifying the transport mechanism for the service tunnel: Underlying Transport the network operator or administrator may select either MPLS or GRE from the dropdown menu, depending upon the availability of paths supporting either of these protocols. Ldp Enabled specifies whether LDP-signaled LSPs will be used to signal the tunnel from source to destination. Selecting false from the dropdown menu indicates that RSVP-signaled LSPs will be used; whereas, true indicates that LDP-signaled LSPs will be used instead. Note that LDP Enabled appears only if the user selects the MPLS transport mechanism. Signaling specifies whether the TLDP protocol will be used to establish end-to-end tunnel dynamically or it will be configured manually (none). Select the parameters as required and click on the Next button to continue the service tunnel configuration. signaling
Service Tunnel - LSP Binding
8 1 10
The configuration wizard now prompts the network operator or administrator to Associate LSPs, if the LDP Enabled parameter of the previous step was set to false. That being the case, to associate an LSP to a service tunnel: Click on the Add button and select the appropriate LSP listed in the Bind LSP to Service Tunnel (SDP) Stage window. Click the Finish button. Note that the selected LSP is now listed in the Associate LSPs window. Click on the Next button to continue the service tunnel configuration or, click on Finish to accept the default settings for the remaining configuration parameters.
Service Tunnel Topology View
8 1 11
The 5620 SAM GUI enables the network operator or administrator to view the Service Tunnel Topology in the carriers network. To view the topology, select Service Tunnel Topology from the drop-down menu in the Map View window. The map will display the Service Tunnel connectivity between network elements. An arrowhead indicates that the direction of the Service Tunnel (Note: Tunnels are unidirectional). A plus sign (+) indicates that at least one set of bidirectional Service Tunnel exists between the two network elements. Selecting the arrowhead or + sign and right-click on the mouse will permit the network operator to list the Service Tunnels from the contextual menu. Once listed, select the appropriate service Tunnel and perform the management functions provided by the action buttons on the right side of the window, as required.
OAM - Tunnel Ping
8 1 12
The Tunnel ping OAM tool, which is called sdp-ping in the CLI, performs in-band unidirectional or bidirectional connectivity tests on service tunnels (also called an SDP). The OAM packets are sent in-band in the tunnel encapsulation, so they follow the same path as the service traffic. The response can be received out-of-band in the control plane or in-band using the data plane for a bidirectional test. For a unidirectional test, tunnel ping OAM tests: egress service tunnel ID encapsulation whether the packet can reach the far-end IP address destination of the service tunnel ID within its encapsulation whether a packet of the specified size goes to the far-end IP address of the service tunnel ID within its encapsulation forwarding class mapping to ensure that the test packet is treated the same as the customer traffic determine whether SLA delay metrics are met To configure and execute a service tunnel Ping OAM: Select Manage Service Tunnels from the Main menu Click on the Search button to list the available service tunnels in the network. Deselecting the Any Source box and selecting a specific element permits the network operator or administrator to filter the list of available service tunnels. Select the appropriate Service Tunnel from the list and click on the Properties button Open the Tests window and select the Tunnel Ping tab Clicking in the Create button opens a new window thus permitting the network operator or administrator to configure an LSP Ping test.
Tunnel Ping - Create
Name and Description (optional)
Originating Tunnel
Return Tunnel
8 1 13
For an network operator or administrator to be able to effect a test, they will first be required to configure and save various parameters. Once saved, the test can be executed against the network object and the results saved in the 5620 SAM database. Under the General tab of the Create Tunnel Ping test configuration window, the network operator or administrator can configure the following: Name used to identify the particular test amongst the various tests that may be created. This parameter is optional for the 5620 SAM and is set based upon corporate policy. Description - used to identify the particular test amongst the various tests that may be created. This parameter is optional for the 5620 SAM and is set based upon corporate policy. Originating Tunnel defines the service tunnel under test. This parameter is automatically populated based upon the tunnel selected. Return Tunnel For a bidirectional test, tunnel OAM uses a local egress service tunnel ID and an expected remote service tunnel ID, so the user can specify where the returned messages should be sent from based on the far-end tunnel ID.
Tunnel Ping Test Parameters
Execution Details Number of Probes Packet Interval Packet Timeout
Test probe Probe configuration information Size Forwarding Class Forwarding Profile
8 1 14
The Test Parameters window enables the network operator or administrator to configure the test packets. These parameters are grouped into two categories: the execution details, which defines how the test packets will behave during the test; and, how the test packets are configured. Set the parameters, as required, and click on the Apply button to save the changes and keep the Tunnel Ping test configuration window open.
Execution Details
Number of Probes specifies the number of probes to be sent along the LSP under test. Probe Interval (seconds) parameter specifies the minimum amount of time, in seconds, that must expire before the next message request is sent. The range is 1 to 10. The default is 1. Probe Timeout (seconds) parameter specifies the time, in seconds, before a message request times out and is aborted. The message request depends on receiving a message reply from the target corresponding to the outstanding request.
Test Probe
Probe Size (octets) parameter specifies the size, in octets, of the message in an OAM diagnostic. The range is 72 to 9198. Forwarding Class parameter specifies the forwarding class for a tunnel ping, MAC ping, or LSP ping or trace. Forwarding Profile parameter specifies whether the test packets are in or out of profile, as compared to the forwarding class of the test packet.
Tunnel Ping Results Configuration

Number of entries
Test failures Probe failures
Trap Generation
OK
Apply
8 1 15
Parameters
Probe History Size (rows) parameter specifies the number of OAM history rows that can be store on the managed device probe results table. The range is 0 to 99 000 000. The default is 50. When the parameter setting has been exceeded, the device removes the oldest entry in the table to allow a new history row. Test Failure Threshold parameter specifies whether the managed device on which the OAM test failed should raise an SNMP trap to indicate a test failure. The test failure trap is raised once the value set for the Test Failure Threshold parameter is reached. Probe Failure Threshold parameter specifies the number of times a probe can fail before an indication of failure is provided. This parameter has no effect if the value is higher than the value for the Probes to be Issued parameter. The range is 0 to 15. The default is 1. Trap Generation specifies the conditions that will generate a trap within the 5620 SAM. Test Completion is set by default however, the network operator or administrator may also select Test Failure, which will generate a trap should the test fail, and Probe Failure, in which case, a trap will be generated for each probe that fails during the test.
Tunnel Ping Execute
8 1 16
Once a test has been configured and saved, it will appear in the list of available tests in under the Tests tab of the Tunnel Ping window and is available to be used to test, as shown above. To conduct a Tunnel Ping test: Open the Tunnel Ping tab from the Tests window (Manage Service Tunnels Tests) The available tests for the selected service tunnel will appear in the list. Select the appropriate test and click on the Execute button. The 5620 SAM will perform the test based upon the saved configuration parameters.
View Test Results

To view the test results: Select the appropriate service tunnel test and click on the Properties button and select the Results tab Set the Search filter parameters, as required, and select the appropriate test from the list. The Search filter permits the network operator or administrator to define search criteria (single or multiple) to reduce the number of objects to be listed, or click on Search, then select the test. Click on the Properties button
Tunnel Ping Results
8 1 17
The filtered list of test results will be listed in the Tunnel Ping Results window. Select the appropriate Results listing and click on the Properties button which opens a new multi-tab window. Review the information under each of the tabs to determine the results of the Tunnel Ping test. General tab provides a summary of the test results, including: the time it was effected; who initiated the test; the status of the test; and other such information. Details tab provides more specific information about the service tunnel performance measured in Round Trip Time and Inbound and Outbound One Way Travel Time
Tunnel Ping Results
8 1 18
Response Probes tab provides the network operator or administrator to information about the performance of each packet sent during the test. Top view each probes details: Use the scroll bar at the bottom to move the listing from left to right, or Select an entry in the list and click on the Properties button. The packet information will appear in a new window.
OAM - MTU Ping
8 1 19
The MTU ping OAM diagnostic tool, which is called sdp-mtu in the CLI, provides a tool for service providers to determine the exact frame (MTU) size that is supported on a service tunnel (also called an SDP), to within one byte. Use the MTU ping OAM to: determine the maximum frame size supported between the service ingress and the service termination point solve troubleshooting issues that are related to equipment used across the network core that may not be able to handle large frame sizes In a large network, network devices can support a variety of packet sizes, up to a limit, that are transmitted across its interfaces. This size limit is referred to as the MTU of network interfaces. It is essential to consider the MTU of the entire service tunnel end-to-end when you provision services, especially for VLL services in which the service must support the ability to transmit the largest customer packet. To configure and execute an LSP Ping OAM: Select Manage Service Tunnels from the Main menu Click on the Search button to list the available service tunnels in the network. Deselecting the Any Source box and selecting a specific element permits the network operator or administrator to filter the list of available tunnels. Select the appropriate tunnel from the list and click on the Properties button Open the Tests window and select the MTU Ping tab Clicking in the Create button opens a new window thus permitting the network operator or administrator to configure a MTU Ping test.
MTU Ping - Create
Name and Description (optional)
Test Object
8 1 20
For an network operator or administrator to be able to effect a test, they will first be required to configure and save various parameters. Once saved, the test can be executed against the network object and the results saved in the 5620 SAM database. Under the General tab of the MTU Ping test configuration window, the network operator or administrator can configure the following: Name used to identify the particular test amongst the various tests that may be created. This parameter is optional for the 5620 SAM and is set based upon corporate policy. Description - used to identify the particular test amongst the various tests that may be created. This parameter is optional for the 5620 SAM and is set based upon corporate policy. Test Object defines the originating node and Tunnel for the MTU Ping test. This parameter is automatically populated based upon the service tunnel selected. Clicking the Properties button will permit the network operator or administrator to view the present configuration of the selected tunnel. Click the Apply button to save these and keep the window open.
MTU Ping Test Parameters
Execution Details Probe Interval Probe Timeout
72
Test Probe packet configuration information Size MTU Start Size MTU First Size MTUI Stop Size
8 1 21
The Test Parameters window enables the network operator or administrator to configure the test probes. These parameters are grouped into two categories: the execution details, which defines how the test packets will behave during the test; and, how the test packets are configured. Set the parameters, as required, and click on the Apply button to save the changes and keep the MTU Ping test configuration window open.
Execution Details
Number of Probes specifies the number of probes to be sent along the LSP under test. Probe Interval (seconds) parameter specifies the minimum amount of time, in seconds, that must expire before the next message request is sent. Probe Timeout (seconds) parameter specifies the time, in seconds, before a message request times out and is aborted. The message request depends on receiving a message reply from the target corresponding to the outstanding request.
Test Probe
Probe Size (octets) parameter specifies the size, in octets, of the message in an OAM diagnostic. The range is 72 to 9198. MTU Start Size, MTU End Size and MTU Step Size parameter specifies the size of the frame, in bytes, that starts an MTU OAM diagnostic test. The frame size at the beginning of the test is the value provided by the MTU Start Size (octets) parameter. During the test, the frame grows incrementally by the number of bytes specified by the MTU Step Size (octets) parameter. When the size specified by the MTU End Size (octets) parameter is reached, the test is complete.
MTU Ping Results Configuration

Number of entries Test failures Probe failures
Trap Generation
OK
Apply
8 1 22
Parameters
Probe History Size (rows) parameter specifies the number of OAM history rows that can be stored on the managed device probe results table. The range is 0 to 99 000 000. The default is 50. When the parameter setting has been exceeded, the device removes the oldest entry in the table to allow a new history row. Test Failure Threshold parameter specifies whether the managed device on which the OAM test failed should raise an SNMP trap to indicate a test failure. The test failure trap is raised once the value set for the Test Failure Threshold parameter is reached. Probe Failure Threshold parameter specifies the number of times a probe can fail before an indication of failure is provided. This parameter has no effect if the value is higher than the value for the Probes to be Issued parameter. The range is 0 to 15. The default is 1. Trap Generation specifies the conditions that will generate a trap within the 5620 SAM. Test Completion is set by default however, the network operator or administrator may also select Test Failure, which will generate a trap should the test fail, and Probe Failure, in which case, a trap will be generated for each packet that fails during the test.
MTU Ping Execute
8 1 23
Once a test has been configured and saved, it will appear in the list of available tests in under the Tests tab of the Service Tunnel window and is available to be used to test, as shown above. To conduct a MTU Ping test: Open the MTU Ping tab from the Tests window (Manage Service Tunnels Tests) The available tests for the selected service tunnel will appear in the list. Select the appropriate test and click on the Execute button. The 5620 SAM will perform the test based upon the saved configuration parameters.
View Test Results

To view the test results: Select the appropriate service tunnel test and click on the Properties button and select the Results tab. Set the Search filter parameters, as required, and select the appropriate test from the list. The Search filter permits the network operator or administrator to define search criteria (single or multiple) to reduce the number of objects to be listed, or click on Search, then select the test. Click on the Properties button.
MTU Ping Results
8 1 24
The filtered list of test results will be listed in the MTU Ping Results window. Select the appropriate Results listing and click on the Properties button which opens a new multi-tab window. Review the information under each of the tabs to determine the results of the MTU Ping test. General tab provides a summary of the test results, including: the time it was effected; who initiated the test; the status of the test; and other such information. Response Probes tab provides more specific information about each of the ping probes. Selecting an entry in the list and clicking on the Properties button will present the network operator or administrator with the detailed information for the selected packet. Review and manage, as required.
End of Module Service Tunnel Configuration
8 1 25
Last Blank Page

8 1 26
82

Module 2 Epipe Configuration
TOS36013_08_02 Issue 1.1
Document History
822
Basic Services Epipe Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Describe the characteristics of an Epipe service List the steps in configuring an Epipe service
823
Virtual Leased Line (VLL) Service

PE B
PE A
PE C
IP / MPLS Network
VLL
PE D
A VLL service provides a point to point connection between two nodes.

Appears as if a leased link exists between the two locations. The Service provider can apply billing, ingress/egress shaping and policing No MAC learning required
824
Basic Services Epipe Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
The 7x50 router supports a Layer 2 point-to-point service commonly known as a Virtual Leased Line (VLL). The VLL service encapsulates customer data and transports it across a service providers IP or MPLS network in a GRE or MPLS tunnel. Customer access to the service providers network is through a Service Access Point (SAP). An VLL connects two access points (SAP) on the same node or two SAPs on different nodes through two uni-directional tunnels. Each node requires a SDP (Service Distribution Path) to provide access to the service tunnel. A basic VLL service must have the following: A locally unique SDP identification number System IP address of the originating and far-end nodes SDP encapsulation type GRE or MPLS QoS and filter ingress and egress policies can be applied to VLL services. Any point-to-point service where at least one endpoint is an Ethernet port is referred to an Epipe service (Ethernet pipe).
Epipe Configuration Workflow

Configure a Configure a Customer Customer
Configure a Customer
Create Service Create Service (Epipe) (Epipe)
Create Epipe Service Define the Sites
Create SAPs Create SAPs
Configure L2 Interfaces Configure Access ports Specify MTU Assign Encapsulation value Select a Service Tunnel Assign VC Label
SDP Bindings SDP Bindings
Manage Service Manage Service

825
Service Topology View Properties

The workflow illustrated above describes the steps for a network administrator or operator to configure a Virtual Private LAN Service. Customer - must be assigned to the service. Though the service can have only one Customer, that customer may be assigned to more than one service. Create Service - specify the service type (VLL) and add the appropriate service sites. Create Service Access Points as discussed, a SAP is a Layer 2 interface configured on a physical port. Configure the port Mode for Access, define the Encapsulation Type, specify the Encapsulation ID (as required) and specify the service MTU size. Create SDP Bindings Create the Spoke SDP or Mesh SDP Bindings by associating the service to service tunnels. The VC Label may be assigned manually, by the network administrator or operator, or automatically, by the 5620 SAM. Manage Service through the Properties window and/ or by using the Service Topology View.
1.Select Manage Customers
2.Select Create
3.Define the Customer Attributes
826
Services must be associated with a customer. Though a service may only have one customer, that customer may have more than one associated to them. To create a Customer using the 5620 SAM, the network administrator or operator will use the following sequence: From the Main Menu, select Manage Customers In the new window, click on the Create button Complete the customers details as provided in the configuration window Click on the OK button. To verify that the customer was created, or edit any detail: Select Manage Customers from the Main Menu Click on the Search button Double-click on the appropriate entry or, select the appropriate customer and click on the Edit button. Review or modify the details, as required.
Configure Access Port
827
As discussed, a service requires a port facing the customer edge to be configured for Access and an Encapsulation type specified. To configure a port: Navigate to the Equipment view in the Navigation Tree Expand the tree and select the appropriate port or ports. It is possible to configure multiple ports at the same time by through the Shift Click or Ctrl Click method. Right-click and select Properties from the contextual menu From the Mode drop-down menu, select Access From the Encapsulation Type drop-down menu, select the appropriate encapsulation type Set the port MTU. Remember that the port MTU must be set to a value set to support the largest service MTU to be supported on that port. Select OK to complete the configuration.
Create Epipe Service

1. Select Create Service VLL Epipe 2.Choose Select
3.Select the Customer
4.Name the Epipe Service
828
To create a service, select the service type and assign the managed devices upon which the service will terminate, referred to as the Service Sites. To create a VLL Epipe: Select Create Service VLL Epipe from the Main Menu Click the Select button in the Customer block Select a customer from the list that appears and click the OK button Complete the remaining parameters, as required. Though optional, providing a service name and relevant description will enable the network administrator or operator to find the service more quickly using the Search filter. Click Apply Automatic SDP Binding Creation This option enables the network administrator or operator to leave the creation of SDP bindings to the 5620 SAM instead of having to manually assign service tunnels (discussed later in this module).
Create Epipe Service Service Sites
1.Select VLL Epipe 2.Right Click Create Sites
3.Create Sites
829
Having clicked the Apply button, the configuration window remains open and the changes are saved in the 5620 SAM database. However, service components (Service Sites, Access Interfaces and SDP Bindings) have yet to be configured for the service to be commissioned. To configure service sites: Navigate to the Components window of the service configuration form Select VLL Epipe and right-click Select Create Site and select the sites to participate in the VLL service from the list. This may be done individually or by selecting multiple entries at once. Click the OK button Confirm the sites have been added in the Components window It is important to remember that, even though they appear in the configuration window, the changes will not be sent to the managed devices and saved to the 5620 SAM database until the OK or Apply button at the bottom of the window (referred to as the Containing Window) is clicked.
Create Service Access Points (SAPs)

1.Select Access Interfaces 2.Right Click on Create L2 Access Interface 3.Select the Port tab
4.Select the Access Port
8 2 10
Service Access Points are virtual interfaces to provide customer access to the service providers network. An SAP consists of: a physical port configured to support Access points; an encapsulation type; and, an encapsulation ID value unique to the port. To create a SAP: Navigate to the Component window for the service Navigate to the Access Interface of the appropriate Site Right-click and select Create L2 Access Interface Click the Port tab and then click the Select button Click the Search button. All Access ports on the managed device will appear in the list. Select the appropriate port and click the OK button
Create SAPs
Assign an Outer Encapsulation Value
8 2 11
The SAP also requires an encapsulation ID value that is unique to the port upon which it is being created. To assign an encapsulation ID: Select the Port tab Assign the Outer Encapsulation Value and Inner Encapsulation Value*, as required Click the OK or Apply button Confirm that the SAP has been configured. To do so: Expand the Access Interface list under the Components window Confirm the SAP is listed and verify its status. Repeat this process for the remaining Access Interfaces to participate in the VLL.
Note
Selecting the Auto-Assign ID will automatically assign an Outer Encapsulation [Inserted Note] value.
Add SDP Bindings

1.Right Click Spoke SDP Bindings 2.Click on Create Spoke SDP Bindings
3. Select a termination site
4. Select a Service Tunnel
8 2 12
Service Distribution Paths are required when Service Access Points are located on separate network devices (distributed service). An SDP is created when a service is associated (bound) to a Service Tunnel. The network administrator or operator has the option of either manually or automatically creating SDP bindings. To manually create the SDP Bindings: Expand the Site listing under the Components window for the service Navigate to Spoke SDP Bindings Right-click and select Create Spoke SDP Bindings, as required based upon network requirements Click the Select button in the Termination Site section of the new window Select the terminating Site ID from the list and click OK. Select a Service Tunnel and click OK.
Note
As of Release 5.0, pseudo-wire switching and redundancy are supported. Hence in [Inserted Note] an Epipe, and other VLL services nodes can be terminating or endpoints. Because of these features, the SAM allows for more than two nodes (sites) to be members of a VLL service.
Add SDP Bindings
8 2 13
Select the OK button in the Warning window. Service components are listed under the Components tab of the service. However,5620 SAM deployment has yet to occur. Select OK or Apply to save the service configuration to the 5620 SAM database, which in turn generates SNMP messages to the affected devices.
Manage Epipe Service

Manage Services Search
Select the Service

8 2 14
Basic Services Epipe Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
Graphical view of service
Once created, the network administrator or operator is able to view and/ or manage the Epipe service from the 5620 SAM GUI. To manage or view the Epipe service configuration: Select Manage Services from the Main Menu Set the Search filter parameters, as required Click on the Search button Select the service from the list. The configuration window appears on the screen. Service configuration information is provided under the appropriate tabs listed at the top of the window. Parameters in drop-down menus or in the white blocks may be changed. Changes to an existing service will prompt a warning to which the network administrator or operator will be required to acknowledge before changes will be affected. Viewing a graphical representation of the service is possible by clicking on the Topology View button of either window. An example is provided on the next page.
Manage the Epipe Service
Service Type Service ID: Site ID

8 2 15
SDP Bindings
Service Access Point Port ID:Outer Encap: Inner Encap
The Topology View, provides the network administrator or operator with a wealth of information about the service through a graphical representation. All components, and their status, will be represented in the window. The network administrator or operator will be able to determine: Site IDs Service Type; Service Name; Service Access Points, including the Encapsulation IDs; Service Distribution Path Bindings Status and fault conditions of each of the above. As is the case throughout the 5620 SAM, it is possible to view any components Properties by selecting the component (left click), then right-click and select the appropriate function from the contextual menu. Color coding is used to indicate Fault conditions based upon the ITU-T X.733 standard (discussed later in the course). In the picture above, green indicates that the service components are reporting a normal operational status. The check mark indicates that the managed device is in active communication with the 5620 SAM.
Blank Page
8 2 16
End of Module Epipe Configuration
8 2 17
Last Blank Page

8 2 18
83

Module 3 VPLS Configuration
TOS36013_08_04 Issue 1.1
Document History
832
Basic Services VPLS Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Describe the characteristics of a VPLS service List the steps in configuring a VPLS service
833
How is a VPLS provided over MPLS?
Bridging capable PE routers

connected with a full mesh of MPLS LSP tunnels
Per-Service VC labels
negotiated using draft-Martini
Unknown/broadcast
traffic replicated in a service domain
PE B
VPLS VPLS Service Service
MAC learning
over tunnel & access ports separate FIB per VPLS
PE A PE C
IP / MPLS Network
LSP FullMesh
PE D
834
For each VPN at each site, a Customer Edge (CE) device connects to the Provider Edge (PE) router via a point-to-point access connection. Ethernet serves as the framing technology between the CE device and the PE router in the providers network. Frames can include IEEE 802.1Q Ethernet VLAN tags, which allow customers to segment their networks and assign quality of service priorities to LAN traffic. VPLS also supports QinQ encapsulation, where a second VLAN tag is added as a service delimiter. From the customers perspective, the entire VPN looks like a single Ethernet LAN, with the PE acting as a bridge that switches frames on the basis of their Layer-2 destination MAC addresses. On the providers side, however, PEs are interconnected with Generic Routing Encapsulation (GRE) and/or Multiprotocol Label Switching (MPLS) tunnels. If PEs are connected using GRE tunnels traffic is encapsulated and routed through the core network using standard IP frame formats and addressing. If PEs are connected using MPLS tunnels traffic is encapsulated in an MPLS frame and transmitted using MPLS labels. MPLS routes can be signaled using RSVP-TE or LDP.
VPLS: Customer View

All locations appear to be on the same Ethernet LAN Entire provider network appears to be a Layer 2 switch CE-PE interface
Simple Ethernet interface Removes L2 protocol conversion between LAN and WAN No additional training required on WAN technologies such as FR
VLAN A
L2 switch
CE
VPLS Service
CE
CE
835
VPLS: Customer Operation
Customers maintain complete control over routing Adding new sites simplified: no re-configuration at existing sites
CE A
CE B VPLS #1 10.10.1. x VPLS #2 20.20.2. x CE A
CE B
CE A
CE B
836
Customers maintain complete control over their routing (unlike with VPRN). This clear demarcation of functionality between service provider and customer makes troubleshooting easier Adding a new site requires no configuration of the service providers equipment or the customer equipment at existing sites
VPLS: Service Provider View
Clear demarcation of functionality between service provider and customer networks Service provider does not have to deal with customer routing issues Separate Ingress/Egress Traffic Parameters Detailed billing and accounting
Ethernet
Access Network
PE IP / MPLS Network 7750
CE
IP / MPLS Network
837
VPLS - VC Label
VC-label Signaling between PEs per VPLS service instance
Each PE initiates a targeted LDP session to the farend System IP address Tells far-end what VC label to use when sending packets for each service
pe2-1
PE-2 M-3
PE-1
pe1-2 pe3-2
PE1->PE2: For Svc-id 101 UseVC-label pe2-1 PE2->PE1: For Svc-id 101 Use VC-label pe1-2 PE1->PE3: For Svc-id 101 Use VC-label pe3-1 PE3->PE1: For Svc-id 101 Use VC-label pe1-3 PE3->PE2: For Svc-id 101 Use VC-label pe2-3 PE2->PE3: For Svc-id 101 Use VC-label pe3-2
838
Basic Services VPLS Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
M-1
pe3-1
VPLS
pe2-3
PE-3
pe1-3
M-4
Customer packets are transported either inside an IP packet (GRE) or inside an MPLS packet. The packet carries an inner (VC) label that identifies the service the packet belongs to. This label is sometimes referred to as the Martini label. When a packet arrives at the destination, the outer IP address or MPLS label is stripped off. At this point the inner label is examined to determine which service the packet belongs to. After determining which service the packet belongs to, the customers Ethernet packet is examined and its MAC address is looked up in a table on the PE to determine which SAP the packet should go to. VC labels can be assigned manually or automatically using targeted LDP (TLDP). The TLDP protocol is used to dynamically negotiate VC labels between PEs. This method is not error prone and scales much better then manually assigning labels.
Spoke and Mesh SDPs
PE-A
SDP
Mesh
Flooded traffic received on spoke SDP is:

replicated on all other ports (spoke and mesh SDPs and SAPs) not replicated on the port it was received on
Spoke SDP
Service G SAP
SDP
SDP
Spoke
SDP
PE-A
SDP
Mesh
Mesh SDP
Service G SAP
SDP
SDP
Flooded traffic received on mesh SDP on the Service is:

replicated on spoke SDPs and SAPs not transmitted on any mesh SDPs
Spoke
SDP
Spoke
839
An SDP is a logical method of advertising and connecting to an encapsulation tunnel and must be bound to a service before the service can be used. The method of binding an SDP to a service, spoke or mesh, determines how flooded traffic is transmitted.
Spoke SDP
A spoke SDP treats flooded traffic like a traditional bridged port. Flooded traffic received on a spoke SDP is replicated on all other ports (other spoke and mesh SDPs or SAPs) but not the port on which it was received.
Mesh SDP
Mesh SDPs bound to the same service are treated like a single bridge port. Flooded traffic received on a mesh SDP on the service is replicated to other ports (spoke SDPs and SAPs) but are not transmitted to other mesh SDPs.
Configuration Workflow - VPLS

Create a Create a Customer Customer
Create a Customer
Create Create Service Service
Specify Service Type Specify Service Sites Configure L2 Interfaces Configure Access ports Specify MTU Assign Encapsulation value Select a Service Tunnel Assign VC Label
Create SDP Create SDP Bindings Bindings

8 3 10
View Service Topology Properties Properties

The workflow illustrated above describes the steps for a network administrator or operator to configure a Virtual Private LAN Service. Customer - must be assigned to the service. Though the service can have only one Customer, that customer may be assigned to more than one service. Create Service - specify the service type (VPLS) and add the appropriate service sites. Create Service Access Points as discussed, a SAP is a Layer 2 interface configured on a physical port. Configure the port Mode for Access, define the Encapsulation Type, specify the Encapsulation ID (as required) and specify the service MTU size. Create SDP Bindings Create the Spoke SDP or Mesh SDP Bindings by associating the service to service tunnels. The VC Label may be assigned manually, by the network administrator or operator, or automatically, by the 5620 SAM. Manage Service through the Properties window and/ or by using the Service Topology View.
Create a Customer
1.Select Manage Customers 2.Select Create
8 3 11
A service it must be associated with a customer. The customer may be associated with multiple services yet there can only be one customer per service. To create a customer: Select Manage Customers from the Main menu Click on the Create button Under the General tab of the Customer Create window, complete the appropriate customer information then click OK. Verify that the customer has been created by selecting Manage Customers from the Main menu and click the Search button. A list of customers, based upon the configured filter, will appear. Verify the customer appears in the list.
8 3 12
Create a VPLS
1. Select Create Service VPLS 2. Choose Select
3.Select the Customer Service Name Description (optional) Automatic SDP Binding Creation (optional)
8 3 13
Basic Services VPLS Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
To create a service, select the service type and assign the managed devices upon which the service will terminate, referred to as the Service Sites. To create a VPLS: Select Create Service VPLS from the Main Menu Click the Select button in the Customer block Select a customer from the list that appears and click the OK button Complete the remaining parameters, as required. Though optional, providing a service name and relevant description will enable the network administrator or operator to find the service using the Search filter. Click Apply Automatic SDP Binding Creation This option enables the network administrator or operator to leave the creation of SDP bindings to the 5620 SAM instead of having to manually assign service tunnels (discussed later in this module).
Create a VPLS Service Sites

1. Components VPLS Create Site
2. Select Sites
3. Confirm Sites
8 3 14
Having clicked the Apply button, the configuration window remains open and the changes are saved in the 5620 SAM database. However, service components (Service Sites, Access Interfaces and SDP Bindings) have yet to be configured for the service to be commissioned. To configure service sites: Navigate to the Components window of the service configuration form Select VPLS and right-click Select Create Site and select the sites to participate in the VPLS service from the list. This may be done individually or by selecting multiple entries at once. Click the OK button Confirm the sites have been added in the Components window It is important to remember that, even though they appear in the configuration window, the changes will not be sent to the managed devices and saved to the 5620 SAM database until the OK or Apply button at the bottom of the window (referred to as the Containing Window) is clicked.
Create SAPs
1. Right-click Create L2 access Interface 2. Port tab click on Select
3. Search
OK
8 3 15
Service Access Points are virtual interfaces to provide customer access to the service providers network. An SAP consists of: a physical port configured to support Access points; an encapsulation type; and, an encapsulation ID value unique to the port. To create a SAP: Navigate to the Component window for the service Navigate to the Access Interface of the appropriate Site Right-click and select Create L2 Access Interface Click the Port tab and then click the Select button Click the Search button. All Access ports on the managed device will appear in the list. Select the appropriate port and click the OK button
Create SAPs
1. Assign Encapsulation Value (as required)
2. Confirm Access Interface
8 3 16
The SAP also requires an encapsulation ID value that is unique to the port upon which it is being created. To assign an encapsulation ID: Select the Port tab Assign the Outer Encapsulation Value and Inner Encapsulation Value, as required Click the OK or Apply button Confirm that the SAP has been configured. To so so: Expand the Access Interface list under the Components window Confirm the SAP is listed and verify its status. Repeat this process for the remaining Access Interfaces to participate in the VPLS.
Create SDP Bindings

1. Create Mesh SDP Binding
2. Select Termination Site (mandatory)
1. Create Spoke SDP Binding
8 3 17
Service Distribution Paths are required when Service Access Points are located on separate network devices (distributed service). An SDP is created when a service is associated (bound) to a Service Tunnel. The network administrator or operator has the option of either manually or automatically creating SDP bindings. To manually create the SDP Bindings: Expand the Site listing under the Components window for the service Navigate to either Mesh SDP Bindings or Spoke SDP Bindings Right-click and select Create Mesh SDP Bindings or Spoke SDP Bindings, as required based upon network requirements. Click the Select button in the Termination Site section of the new window Select the terminating Site ID from the list and click OK.
Create SDP Bindings

1. Manual Tunnel Assignment
2. Select tunnel
OK
1. Automatic Tunnel Select
3. Confirm SDP Configuration
8 3 18
With the Terminating Site identified, the network administrator or operator can assign a Service Tunnel. To manually assign a Service Tunnel: Click the Select button in the Tunnel section of the configuration window Select the appropriate Service Tunnel from the list Click the OK button SDP Binding configuration is verified by expanding the appropriate Site listing under the Components window. Repeat this process until the remaining SDP Bindings required to support the VPLS have been configured. Click the OK or Apply at the bottom of the containing window to save the configuration to the 5620 SAM and send the configuration changes to the managed nodes. Automatic SDP Binding Creation is possible if the network administrator or operator has checked this option under the General tab of the configuration window (already discussed). When selected, it is possible to specify the Tunnel Transport protocol from the drop-down menu in the configuration form, as shown above.
Manage VPLS Service
8 3 19
Once created, the network administrator or operator is able to view and/ or manage the VPLS service from the 5620 SAM GUI. To manage or view the VPLS service configuration: Select Manage Services from the Main Menu Set the Search filter parameters, as required Click on the Search button Select the service from the list. The configuration window appears on the screen. Service configuration information is provided under the appropriate tabs listed at the top of the window. Parameters in drop-down menus or in the white blocks may be changed. Changes to an existing service will prompt a warning to which the network administrator or operator will be required to acknowledge before changes will be affected. Viewing a graphical representation of the service is possible by clicking on the Topology View button of either window. An example is provided on the next page.
View Service Topology
Service Type Service ID: Site ID Service Access Point SDP Bindings Port ID:Outer Encap: Inner Encap
8 3 20
The Service Topology View displays the service components configuration and status information at a glance. Information available includes: Service Type indicated within the Site icon (VPLS, in this case). The Service ID and Site ID are posted below the icon. Service Access Point the square with two arrows contained within the icon. The Port ID and Outer and Inner Encapsulation ID are posted below the icon. SDP Bindings arrows indicate direction of the bindings between service sites. Select any component in the Topology View. Right-clicking provides a contextual menu for the selected item.
End of Module VPLS Configuration
8 3 21
Last Blank Page

8 3 22
84

Module 4 IES Configuration
TOS36013_08_06 Issue 1.1
Document History
842
Basic Services IES Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Describe the characteristics of an Internet Enhanced Service (IES) List the steps in configuring an IES service
843
Internet Enhanced Service (IES)

Internet
Company C
Service Provider Network

PE A
PE C
PE B Company A Company B
Internet Enhanced Service provides direct internet access for the customer with the added function of providing for traffic engineering, QoS, accounting, etc.
844
Basic Services IES Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
IES Service
An Internet Enhanced Service (IES) is a routed connectivity service where the subscriber communicates with an IP (Layer 3) router interface to send and receive Internet traffic. The 7750 SR buffers service traffic and shapes it to conform to SLA parameters. Buffer allocation is programmable per-service to accommodate different maximum burst sizes (MBS). Each service can use multiple queues to enable shaping, policing and marking of different flows. The 7750 SR can also shape and police on service egress so customers can purchase sub-rate services (e.g. Internet services) with asymmetric SLAs.
Characteristics
Service Access Point (SAP) acts as the access point to the subscribers network SAP supports multiple encapsulation types, such as: Ethernet null, dot1q, q-in-q, SONET/SDHIPCP, BCP-null, BCP-dot1q and ATM. Supports VRRP, Cflowd, secondary IP addresses, and ICMP options on customer IP interfaces Interface supports RIP, OSPF, IS-IS, and BGP. QoS and filter policies Does not require a Service Distribution Path (SDP); traffic is routed rather than being encapsulated in a tunnel
IES Configuration Workflow
Configure a Configure a Customer Customer
Create Service Create Service (IES) (IES)
Create IES Service Define the Site(s) Configure Access Ports Select the Layer3 Access Interface Site(s) Add the Routing Protocol to the IGP
Service Topology View Properties
845
1.Select Manage Customers 2.Select Create
846
Services must be associated with a customer. Though a service may only have one customer, that customer may have more than one associated to them. To create a Customer using the 5620 SAM, the network administrator or operator will use the following sequence: From the Main Menu, select Manage Customers In the new window, click on the Create button Complete the customers details as provided in the configuration window Click on the OK button. To verify that the customer was created, or edit any detail: Select Manage Customers from the Main Menu Click on the Search button Double-click on the appropriate entry or, select the appropriate customer and click on the Edit button. Review or modify the details, as required. Click OK or Apply to save the changes or Cancel to disregard any modifications and close the window.
847
Create IES Service

1. Select Create Service IES 2.Choose Select
4.Name the IES Service
848
To create a service, select the service type and assign the managed devices upon which the service will terminate, referred to as the Service Sites. To create an IES: Select Create Service IES from the Main Menu Click the Select button in the Customer block Select a customer from the list that appears and click the OK button Complete the remaining parameters, as required. Though optional, providing a service name and relevant description will enable the network administrator or operator to find the service more quickly using the Search filter. Click Apply
Create Service Site(s)

1.Click on Sites tab 2.Select Add
3. Add site
849
Having clicked the Apply button, the configuration window remains open and the changes are saved in the 5620 SAM database. However, service components (Service Sites, Access Interfaces and SDP Bindings) have yet to be configured for the service to be commissioned. To configure service sites: Navigate to the Components window of the service configuration form Select IES and right-click Select Create Site and select the sites to participate in the VPLS service from the list. This may be done individually or by selecting multiple entries at once. Click the OK button on the bottom of the Components window (i.e., the containing window in this case) Confirm the sites have been added in the Components window It is important to remember that, even though they appear in the configuration window, the changes will not be sent to the managed devices and saved to the 5620 SAM database until the OK or Apply button at the bottom of the window (referred to as the Containing Window) is clicked.
Create L3 Interface
8 4 10
Service Access Points are virtual interfaces to provide customer access to the service providers network. An SAP consists of: a physical port configured to support Access points; an encapsulation type; and, an encapsulation ID value unique to the port. To create a SAP: Navigate to the Component window for the service. Navigate to the Access Interface of the appropriate Site. Right-click and select Create L3 Access Interface. Assign an interface name (mandatory) and complete the remaining parameters, as required. Click the Port tab and then click the Select button. Click the Search button. All Access ports on the managed device will appear in the list. Select the appropriate port and click the OK button.
Create L3 Access Interface (SAP) [Cont.]
Encapsulation Value, as required
8 4 11
The SAP also requires an encapsulation ID value that is unique to the port upon which it is being created. To assign an encapsulation ID: Select the Port tab. Assign the Outer Encapsulation Value and Inner Encapsulation Value, as required. The use of encapsulation values will be determined by the encapsulation type configured on the port being used. This was set during the process to create an Access port, discussed earlier in the course. Select the Address tab.
Create L3 Access Interface (SAP) [Cont.]
8 4 12
An IES is a Layer 3 service and will therefore require an IP Address on the SAP. To assign an IP address to the SAP: Open the Address tab in the service configuration window Click on the Add button Enter the appropriate IP address according to scheme provided. The Address ID determines whether the IP address is either the primary (ID # 1) or a secondary address (ID# 2 16). Configure the parameters under the remaining windows, as required. These are optional settings and may be added at any time in the future without service interruption. These parameters include: QoS: assign access ingress and egress policies Schedulers: assign ingress and egress schedulers for HQoS ACL: assign ingress and egress filter policies Accounting: define an accounting policy ICMP: define type and rate that ICMP messages will be processed on this interface ARP: define static entries in the ARP table. Turn on Proxy ARP and define proxy ARP policies DHCP: configure DHCP relay, Option 82 and the DHCP lease state table. Anti-Spoofing: turn on auto creation of anti-spoofing filters and configure static hosts Click on OK or Apply to complete the configuration Opening the Components tab will provide a tabular view of the service configuration. Expand the Access Interface entry to confirm that the SAP has been created and verify that its status indicates that the interface is Up.
Add SAP to Internal Gateway Protocol (IGP)
OK
8 4 13
Though the IES has been created, traffic will not be forwarded through the interface until it participates in the Internal Gateway Protocols routing table. To do so, the interface must be assigned to an Internal Gateway Protocol (IGP) including an appropriate area or autonomous system, as required by the protocol. To configure the IES interface to participate in the IGP route table: Open the Components tab of the IES Navigate to the IES Access Interface and select the appropriate SAP. Right-click and select Properties from the contextual menu In the window that appears (L3 Access Interface), select the Protocols tab Select the Add button. The Create Interface window appears. From the drop-down menu, select the appropriate protocol to which the interface will be added and click OK. Repeat this process for each of the IGP in which this interface is to participate. The protocol(s) will appear in the list. Select OK to complete the configuration and deploy the changes to the 5620 SAM database and network element(s). The IES will now be able to pass traffic through the SAP. In the new window (L3 Access Interface), click on the Select button in the Routing Instance portion of the configuration window List the available routing instances by clicking on the Search button. Using Search filters can refine the list. Select the appropriate routing instance from the list and click OK
Protocol Properties
8 4 14
As part of the service providers policy in providing the IES, it may be necessary to modify the default actions of the IGP on this interface. For example, the IES interface may be used to provide routing to another carriers network, in which case, it may be desirable to prevent the exchange of routing tables by configuring the interface for Passive mode. To modify the IGP properties for an IES interface: Navigate to and select the IES SAP in the Components tab of the service. Select the Properties from the contextual menu. Select the Protocols tab, select the protocol instance and then select the Properties button, which will open the OSPF Interface window. Click on the Protocol Properties tab. Configure the parameters, as require and then click on OK at the bottom of the list to save the changes.
Manage IES
8 4 15
Once created, the network administrator or operator is able to view and/ or manage the IES from the 5620 SAM GUI. To manage or view the IES service configuration: Select Manage Services from the Main Menu Set the Search filter parameters, as required Click on the Search button Select the service from the list, and double click on the service. The configuration window appears on the screen. Service configuration information is provided under the appropriate tabs listed at the top of the window. Parameters in drop-down menus or in the white blocks may be changed. Changes to an existing service will prompt a warning to which the network administrator or operator will be required to acknowledge before changes will be affected. Viewing a graphical representation of the service is possible by clicking on the Topology View button of either window. An example is provided on the next page.
View Service Topology
Service Type Service ID: Site ID

8 4 16
Basic Services IES Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
Service Access Point Port ID:Outer Encap: Inner Encap
The Service Topology View displays the service components configuration and status information at a glance. Information available includes: Service Type indicated within the Site icon (VPLS, in this case). The Service ID and Site ID are posted below the icon. Service Access Point the square with two arrows contained within the icon. The Port ID and Outer and Inner Encapsulation ID are posted below the icon. Select any component in the Topology View. Right-clicking provides a contextual menu for the selected item. Color coding is used to indicate Fault conditions based upon the ITU-T X.733 standard (discussed later in the course). In the picture above, green indicates that the service components are reporting a normal operational status. The check mark indicates that the managed device is in active communication with the 5620 SAM.
End of Module IES Configuration
8 4 17
Last Blank Page

8 4 18
85

Module 5 VPRN Configuration
TOS36013_08_07 Issue 1.1
Document History
852
Basic Services VPRN Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Describe the operation and benefits of a VPRN service List VPRN features, functions, components and topologies Describe VPRN configuration on the Service Router using the SAM
853
Virtual Private Routed Network

VPRN is a class of VPN that allows the connection of multiple sites in a routed domain over a provider managed IP/MPLS network
MP-IBGP Route Exchange For all Services
CE B
RI-1 RI-2
PE B
RI-1 RI-2
PE A
PE C
CE C
CE A
IP / MPLS Network
RI-1 RI-2 VPRN Service Red
PE D
RI-1
VPRN Service Green
CE D
RI-2
As of R4.0, inter-AS VPRNs are supported.
In Feb. 2006, Internet Draft RFC2547bis was moved to standard status, as RFC 4364.
854
Basic Services VPRN Configuration 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
A Virtual Private Routed Network (VPRN) service allows service providers to use their IP backbone to provide a Layer 3 VPN service to their customers. VPRNs are also known as BGP/MPLS VPNs because BGP is used to distribute VPN routing information across the provider's backbone and MPLS is used to forward VPN traffic from one VPN site to another. From the customers perspective it looks as if all sites are connected to a routed domain Service provider can reuse the IP/MPLS infrastructure to offer multiple services Each VPRN appears like an additional routing instance, routes for a service between the various PEs are exchanged using MP-BGP Customer data is encapsulated using MPLS or GRE encapsulation Each CE router becomes a peer of the PE router that it is directly connected to, not a peer to the other CE routers. A CE router provides the PE router with route information for the private customer network. Each associated PE router maintains a separate IP forwarding table for each VPRN. Additionally, the PE routers exchange the routing information configured or learned from all customer sites via MP-BGP peering. Each route exchanged via the MP-BGP protocol includes a Route Distinguisher (RD), which identifies the VPRN association making the router unique and a Route Target. MPLS handles the forwarding between the PE routers. This means that the routers in the core of the network need not know about the routes connecting the private networks. A VPRN service uses a two-level label stack the ingress PE router pushes both an inner VC label and an outer tunnel label onto a packet. After reaching the egress PE router via one or more MPLS Label Switched Paths (LSPs), the PE router pops the MPLS headers and delivers a normal IP packet to the customer.
VPRN Features
Consistent QoS model used across all VPN services Highly scalable implementation Per VPN controls to limit route table growth Consistent service and feature support over IP or MPLS backbone PE-CE routing support Comprehensive set of OA&M tools Statistics, billing and accounting data
855
Highly scalable: VPN routing and forwarding (VRF) tables Total routes BGP Peerings IP Interfaces PE-CE routing supports: Static Routes BGP RIP OSPF Statistics, billing and accounting data: Per IP-VPN (VPRN) Current routes Current routes per protocol source (Static, Local, BGP (PE-CE or Network), OSPF Maximum number of routes (high watermark) Per IP-VPN Interface: Packets (In/Out) Bytes (In/Out) Errors In/Out
VPRN Architecture and Components

Tunneling Mechanisms: RSVP-TE LDP GRE
PE CE CE
PE
CE CE
Customer 1 VPN
CE
Customer 2 VPN
PE CE
PE CE
Core Network CE CE to PE Routing: BGP RIP Static OSPF

856
CE
VPN Instance #1 VPN Instance #2

VRF for Customer 1 VPRN VRF for Customer 2 VPRN
In a Virtual Private Routed Network (VPRN) the service provider network distributes its customers routing information using MP-BGP and forwards their data packets using MPLS or GRE tunnels. The routers in the service providers network perform one of two possible roles: Provider (P) routers in the core. These routers simply support the switching of LSPs. They do not have any knowledge of the existence of the VPRNs. Provider Edge (PE) routers at the edge of the service providers network. These devices provide the MPLS signaling and forwarding and partitioned IP routing and forwarding capabilities to partition customer data flows received from or destined to the various customer sites. The routers in the customers network which connect to the PEs are known as CE (Customer Edge) devices and are simple IP routers that forward and receive IP packets and distribute routing information using standard IP routing protocols or configured static routes and are VPRN unaware. The architecture of the VPRN service is shown on the above diagram. The components of a VPRN VPN are:
1. MP-BGP sessions between PEs to distribute customer routes across the service providers backbone.
2. Virtual Routing and Forwarding (VRF) tables on PEs specifying the import and export rules for customer routes advertised between PEs. 3. Configured or learned VPRN routes from the customer sites. 4. MPLS or GRE tunnels between PEs for transporting customers traffic across the service providers backbone.
VPRN Functions
Switch to notes view! Learning Routes from Local CEs
A PE learns the routes from a CE through static routes or a dynamic routing protocol such as BGP. Locally reachable IPv4 addresses as well as remote routes learned from other PEs are stored in the appropriate VRF.
Distributing Routes
The PEs establish MP-BGP sessions with each other to distribute the routes they have learned from locally connected CEs. The PEs maintain one or more VRF for each VPRN it is involved with, depending on the VPN topology (mesh or hub and spoke, intranet or extranet).
Ensuring Unique Customer Routes

Because different customers may use the same IP addresses within their respective networks, a method is need to ensure that they remain unique when they are distributed across the service provider network. This is achieved by pre-pending the 4-byte IPv4 address with an 8-byte Route Distinguisher to form a new address called the VPN-IPv4 address. A distinct RD value can be associated with individual routes or with all routes learned from a particular CE.
Populating Routes Into VRFs

When a PE receives routes from another PE via their MP-BGP session it adds the learned routes into the appropriate VRFs based on the route targets configured in each VRF, and contained in the route advertisement. An export route target is included in the route advertisement. If it matches the import route 7 target configured in a VRF, those routes Reservedpopulated into the VRF. All Rights are Alcatel-Lucent 2009 85
Forwarding Data Among Customer Sites

The PEs forward customer traffic across the service providers network via GRE or LSP tunnels (outer label). LSPs can be established using LDP or RSVP-TE signaling. When the destination PE receives a data packet it determines the appropriate VRF to use to forward the packet onward to the correct CE based on the inner label associated to a given VRF. The inner label is allocated by the local PE and advertised to the peer PE as part of a VPN-IPv4 route update.
Transport Tunnels
Each PE involved in a given VPRN service must be configured with a tunnel to every other PE participating Switch to notes view! in the same VPRN service to transport a customers VPN traffic from one site to another. The tunnel is created either through the configuration of a SDP or using the auto-bind option when creating a VPRN service instance. For VPRN services, SDP tunnels can be created using MPLS with RSVP-TE or GRE encapsulation. The auto-bind method for creating tunnels can be used with LDP or GRE. If SDP tunnels are used, they must be created prior to the creation of the VPRN services. The configuration of a SDP includes specifying the far-end PE and the type of encapsulation used, GRE or MPLS with RSVPTE. When RSVP-TE signaling is used, the outer LSP tunnels must be explicitly configured in addition to the creation of the SDPs. When the outer tunnels are created using auto-bind with LDP there is no need to explicitly configure the LSP tunnels. It is only necessary to enable LDP signaling on the appropriate interfaces and once the MP-BGP sessions have been established, the LSP is automatically established. Similarly, outer tunnels created using auto-bind with GRE do not require any preliminary configuration the VPRN service only needs to be auto-bound to GRE. When the auto-bind option is used traffic from all VPRN services (configured with the auto-bind option) traverse the same LSPs. In this case it is not possible to have alternate tunneling mechanisms (like GRE) or the ability to configure sets of LSP's with bandwidth reservations for specific customers as is available with explicit SDPs for the service. If LSPs with reserved bandwidth are needed then SDPs with RSVP-TE signaling should be used for the outer tunnels. If distinct tunnels per VPRN service are desired, then SDPs with GRE or RSVP-TE signaling should be used so that VPRN instances can be explicitly bound to specific SDPs.
858
Transport Tunnels and Service Binding
Outer Label
Each PE in the VPRN connected by a tunnel Tunnels created by: Creating an SDP (RSVP-TE or GRE) Auto-bind (LDP or GRE)
Tunnel binding depends on the tunnel signaling protocol:

LDP signaled LSP tunnels GRE tunnels RSVP-TE signaled tunnels
859
Each PE involved in a given VPRN service must be configured with a tunnel to every other PE participating in the same VPRN service to transport a customers VPN traffic from one site to another. The tunnel is created either through the configuration of a SDP or using the auto-bind option when creating a VPRN service instance. For VPRN services, SDP tunnels can be created using MPLS with RSVP-TE or GRE encapsulation. The auto-bind method for creating tunnels can be used with LDP or GRE. If SDP tunnels are used, they must be created prior to the creation of the VPRN services. The configuration of a SDP includes specifying the far-end PE and the type of encapsulation used, GRE or MPLS with RSVPTE. When RSVP-TE signaling is used, the outer LSP tunnels must be explicitly configured in addition to the creation of the SDPs. When the outer tunnels are created using auto-bind with LDP there is no need to explicitly configure the LSP tunnels. It is only necessary to enable LDP signaling on the appropriate interfaces and once the MP-BGP sessions have been established, the LSP is automatically established. Similarly, outer tunnels created using auto-bind with GRE do not require any preliminary configuration the VPRN service only needs to be auto-bound to GRE. When the auto-bind option is used traffic from all VPRN services (configured with the auto-bind option) traverse the same LSPs. In this case it is not possible to have alternate tunneling mechanisms (like GRE) or the ability to configure sets of LSP's with bandwidth reservations for specific customers as is available with explicit SDPs for the service. If LSPs with reserved bandwidth are needed then SDPs with RSVP-TE signaling should be used for the outer tunnels. If distinct tunnels per VPRN service are desired, then SDPs with GRE or RSVP-TE signaling should be used so that VPRN instances can be explicitly bound to specific SDPs.
PE to CE Route Distribution
Switch to Static Routesnotes view!
All routes to be advertised by the CE to other CEs belonging to the VPRN are configured as static routes in the VPRN service instance.
eBGP Routing
eBGP is configured between the PE and each attached CE belonging to the same VPRN in the VPRN service instance. The explicit configuration of the autonomous system number and router-id is optional. If omitted, these values simply inherit the routers global AS number and router-id. The local address is also an optional parameter. When it is not specified, it inherits the system IP address when communicating with IBGP peers and the interface address for directly connected eBGP peers. If no import route policy is specified, then all BGP routes advertised by the CE are accepted by the PE. An export policy is needed for the PE to advertise the routes learned from other PE sites in the VPRN instance via MP-BGP to the CE router via eBGP.
RIP Routing
When RIP is used as the PE-CE routing protocol, a RIP instance must be enabled on the PE router in the router context. Subsequently RIP can be configured on the PE-CE interface during the configuration of the VPRN service. RIP is configured between the PE and each attached CE belonging to the same VPN in All Rights Reserved Alcatel-Lucent 2009 8 VPRN service instance. 10 the 5Services VPRN Configuration Basic By default RIP does not export routes it has learned to its neighbors. Therefore it is necessary to configure an export policy to enable MP-BGP routes learned from remote CEs belonging to the VPN, to be redistributed into RIP and to the local CE.
OSPF Routing
As of R4.0 of the 7X50 routers, OSPF can be used at the PE-CE routing protocol. This provides a way for a network to continue using a single protocol as it is migrated to an IP-VPN backbone. OSPF LSA information is not transmitted natively across the IP-VPN. The OSPF routes are imported into MP-BGP as AS externals. As a result, other OSPF-attached VPRN sites on remote PEs will receive these via type 5 LSA. This process is not automatic and requires the configuration of (existing) Route Policies. Stub areas, OSPF-TE and sham links are not currently supported.
Configuration Workflow - VPRN

Configure BGP Configure BGP
Configure an BGP mesh among participating sites
Create a Create a Customer Customer
Create a Customer
Create Service Create Service
Specify Service Type Specify Service Sites
Add a Layer 3 Access Interface to each site Configure Access ports Specify MTU Assign Encapsulation value Service Topology View Properties

8 5 11
VPRN Configuration Workflow

The workflow illustrated above describes the steps for a network administrator or operator to configure a Virtual Private LAN Service. BGP Network Configuration Configure BGP for VPRN connectivity Customer - must be assigned to the service. Though the service can have only one Customer, that customer may be assigned to more than one service. Create Service - specify the service type (VPRN) and add the appropriate service sites. Create Service Access Points Add a Layer 3 Access Interface to each site. Configure the port Mode for Access, define the Encapsulation Type, specify the Encapsulation ID (as required) and specify the service MTU size. Bind Service Tunnels to create the SDPs. It is possible to use Auto-Bind, when using LDP, or manually assign Spoke SDPs, if RSVP is to be used for tunnel transport. Manage Service through the Properties window and/ or by using the Service Topology View.
BGP Configuration - Configure BGP AS

1. Select the Routing Instance-1 2. Select Properties 3. Select Routing 4. Enter the AS Number as 100
5. Select Protocols 6. Verify that BGP is enabled

8 5 12
The following steps will cover the configuration of an iBGP mesh, which will be used for the advertisement of VPRN routes from each customers VRFs. An BGP mesh will be required among all participating sites in the VPRN service.
Configure BGP AS
Select the Routing view in the tree window Select each Router in turn where a VPRN site is required Select the Routing instance-1 and then Properties. Select the Routing tab, and enter the Autonomous System Number; 100 is used here as an example. Leave all other entries as the defaults.
Enable BGP
On the Protocols tab Check that BGP is enabled; if not, select the BGP Enabled check box, select OK or Apply.
Configure BGP AS
1. Select the BGP Routing Instance 2. Select Properties
3.Verify the Site ID is the System Interface Address
8 5 13
Select the BGP routing instance for your router from the Navigation Tree Routing view, right click and select Properties. In the General tab, verify the Site ID is the system interface IP address.
Configure BGP AS [Cont.]

1. Select the AS Properties tab 2. Verify the AS number is 100
3.In the VPN tab, enable Family: VPN-IPVN4 and IPv4
8 5 14
Select the AS properties tab, and verify that the AS number is 100; 100 is used here as an example. In the VPN tab, enable Family: VPN-IPV4 and IPv4. It is essential that you enable the VPN-IPV4 family as this is required to carry VPRN routes. Click Apply or OK.
Create Peer Group

1. Select the Group tab 2. Select Add 3. Specify the Name.
4. Select the AS Properties tab 5. Set the Peer AS to 100 6. Select OK, OK, Apply and Yes
8 5 15
Select the Group tab. Select Add. Specify the Name. Click Apply and OK. Select the AS Properties tab and set the Peer AS to 100. Other parameters will be inherited from the global configuration. Select OK, OK, Apply and Yes.
Create BGP Peers

1. Select the Peer tab 2. Select Add
3.Enter the System ID for the other router 4.In the General tab, choose Select under the Routing Instance group
8 5 16
Select the Peer tab, and create a BGP peer to one of the PE routers. Select Add, and enter the system ID for the other router in the Peer Address field. Under Routing Instance Group: choose Select.
Create BGP Peers [Cont.]
1. Select the Peer Group from the list 2. Click OK, OK, Apply and Yes 3. Click Close or Cancel
8 5 17
Select the peer group from the list. Click OK, OK, Apply and Yes. Click Close or Cancel.
Verify BGP Configuration
1. Double click on a Peer
2. Ensure the connection state is Established
8 5 18
Repeat the steps on the previous two pages for all PE routers in your network. Your peering relationships will be up when all objects and aggregated alarms have cleared. Double click on each peer and check that the connection state is Established.
1.Select Manage Customers
2.Select Create
8 5 19
Services must be associated with a customer. Though a service may only have one customer, that customer may have more than one associated to them. To create a Customer using the 5620 SAM, the network administrator or operator will use the following sequence: From the Main Menu, select Manage Customers In the new window, click on the Create button Complete the customers details as provided in the configuration window Click on the OK button. To verify that the customer was created, or edit any detail: Select Manage Customers from the Main Menu Click on the Search button Double-click on the appropriate entry or, select the appropriate customer and click on the Edit button. Review or modify the details, as required. Click OK or Apply to save the changes or Cancel to disregard any modifications and close the window.
8 5 20

Create a VPRN
1. Select Create Service VPRN 2.Choose Select
Service Name Description (optional)
8 5 21
To create a service, select the service type and assign the managed devices upon which the service will terminate, referred to as the Service Sites. To create a VPRN: Select Create Service VPRN from the Main Menu Click the Select button in the Customer block Select a customer from the list that appears and click the OK button Complete the remaining parameters, as required. Though optional, providing a service name and relevant description will enable the network administrator or operator to find the service using the Search filter. Click Apply
Create a VPRN [Cont.]

1. Select the Components Tab
2. Select the Site IDs (PE Sites) participating in the service 3. Click OK
4. Select the Components Tab to view the service sites
8 5 22
Add and configure PE Sites: Click on the Components Tab then right click on VPRN. Select Create Site Select the sites participating in the service. Click OK Select the Components Tab to view the service sites.
1. 2.
Select the Routing Instance Select Properties
3.Give a selected site a Name and Description
8 5 23
Select the first Routing Instance Right click and select Properties. Give the site a Name and a Description.
1.Assign values as shown
8 5 24
Click on the Routing tab. This enables us to configure the virtual router instance. Configure the following properties: Router id = the system address of the router AS number = 100 Route Distinguisher Type = Type 0 (use an assigned value as a route distinguisher) Type 0 Administrative Value = 100 Type 0 Assigned Value = a unique identifier in order to make the network address unique to this VPRN; 60 is used as an example.
1. Assign values as shown
8 5 25
Click on the VRF-Target sub tab and set the VRF route target properties as follows: VRF Target Type = Define Default Target Format = AS Target AS Value = 100 Target Extended Community Value = unique value, which must match each distant end Route Target Value of the other sites participating in the service in order to allow the population of network addresses in the VRF; 95 is used as an example.
1. Set the transport to MPLS:LDP 2. Click OK and OK
8 5 26
Click on the Auto-Bind tab and set the Transport to MPLS:LDP. This will enable the use of LDP signaled LSPs to reach each remote site, rather than SDPs. Click OK and OK.
Layer 3 Access Interfaces

1.Select Access Interfaces 2.Select Create L3 Access Interface 3.Select a Site
4.Give the Layer 3 Access Interface a Name and Description
8 5 27
In the Components window, select Access Interfaces, Right click and select on the Create L3 Access Interface. This will add a Layer 3 customer facing interface to the virtual router on this site for this VPRN instance. Give the interface a Name and Description.
Layer 3 Access Interfaces [Cont.]
1.Choose Select 2.Click OK
3.Click Search 4. Select a Port 5. Click OK
8 5 28
Port Selection
Add a SAP to the interface via the Port tab In the Port tab, Choose Select in the Terminating Port Region. Click OK. In the Select Terminating Port window, select Search.

1.Select a port 2.Click OK
3.Assign an Outer Encapsulation Value 4.Enter a SAP Description
8 5 29
Outer Encapsulation Value Assignment

In the Port tab, assign the port an Outer Encapsulation Value or use the Auto-Assign ID feature. Enter a SAP Description.
Configure the IP address for a specific site as shown.
8 5 30
IP Address Assignment
Select the Address tab. Click Add. Configure an address on the interface of the specific router. Note: Unlike IES, it does not matter if customer address spaces overlap on each VPRN service as the route distinguisher keeps them unique. In the IP Address window, type in the IP Address and Prefix Length, and click OK, OK, OK, OK. Repeat all of the previous steps, starting with assigning a Name and Description for the other site(s) participating in the service. In this example, the other site is node 146.
Confirm Configuration Changes
1.Click Apply, Yes 2. Select Topology View
8 5 31
Final Steps
In the Components window, select Apply, Yes and then Topology View to view the newly created VPRN.
Service Topology View
8 5 32
Service Topology View

Having selected Topology View, the Service Topology window above will appear. An alternative is to elect Manage Click on the Topology View button. View the properties of the service. Services, search for your VPRN service, select it.
Questions
?
8 5 33
1. What method does a VPRN service use to differentiate overlapping customer address space? a. Router target b. Policies c. Route Distinguisher d. Filters 2. Select all CE to PE routing methods or protocols supported on the SR: a. Static Routes b. RIP c. OSPF d. IS-IS e. BGP 3. Which two types of Route Distinguisher are used in the SR? a. IP-Address and Autonomous System Number b. Router Id and Autonomous System Number c. IP-Address and Cluster-Id d. Router-Id and Cluster-Id 4. What method is used to exchange routes between PEs? a. OSPF b. RIP c. Static d. MP-BGP
Answers
1. What method does a VPRN service use to differentiate overlapping customer address space?
a. Router target b. Policies c. Route Distinguisher d. Filters
2. Select all CE to PE routing methods or protocols supported on the SR:

a. Static Routes b. RIP c. OSPF d. IS-IS e. BGP
3. Which two types of Route Distinguisher are used in the SR?

a. IP-Address and Autonomous System Number b. Router Id and Autonomous System Number c. IP-Address and Cluster-Id d. Router-Id and Cluster-Id
8 5 34
4. What method is used to exchange routes between PEs?

a. OSPF b. RIP c. Static d. MP-BGP
End of Module VPRN Configuration
8 5 35
Last Blank Page

8 5 36
91
Section 9 Create Services from Template

Module 1 Create Epipe from Template
TOS36013_09_01 Issue 1.0
Document History
912
Create Services from Template Create Epipe from Template 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Document History Edition 01 Date 2009-06-02 Author BLAIN, Claude Remarks First edition
Module Objectives
Identify the appropriate service templates Create an Epipe service from a service template
913
914
Services must be associated with a customer. Though a service may only have one customer, that customer may have more than one associated to them. To create a Customer using the 5620 SAM, the network administrator or operator will use the following sequence: From the Main Menu, select Manage Customers; In the new window, click on the Create button; Complete the customers details as provided in the configuration window; Click on the OK button. To verify that the customer was created, or edit any detail: Select Manage Customers from the Main Menu; Click on the Search button; Double-click on the appropriate entry or, select the appropriate customer and click on the Edit button; Review or modify the details, as required.
915
As discussed, a service requires a port facing the customer edge to be configured for Access and an Encapsulation type specified. To configure a port: Navigate to the Equipment view in the Navigation Tree; Expand the tree and select the appropriate port or ports. It is possible to configure multiple ports at the same time by through the Shift Click or Ctrl Click method; Right-click and select Properties from the contextual menu; From the Mode drop-down menu, select Access; From the Encapsulation Type drop-down menu, select the appropriate encapsulation type; Set the port MTU. Remember that the port MTU must be set to a value set to support the largest service MTU to be supported on that port; Select OK to complete the configuration.
Create Epipe Service from Template
916
To create a service from a template, select the service template to be used and assign the managed devices upon which the service will terminate, referred to as the Service Sites. To create a VLL Epipe service: Select Create Service from Template from the Main Menu; Select the appropriate template from the search list. Service provisioning personnel can apply a filter to the list so as to reduce the number of entries; Click the OK button.
Create Epipe Service
Service Name.
Green arrow indicates mandatory change as per template configuration.
May Modify.
White parameter box indicates optional changes as per template configuration.
OK or Apply.
Bolded only after mandatory parameters configured.
917
The Create VLL Epipe Service from Template opens to the General tab of the template. Set the parameters as required. Customer in this case, the customer has already been associated to the template. Personnel may verify customer properties or select a new user by using the Properties, Clear and Select keys, as required. Service ID based upon the template configuration, the Auto-Assign ID is enabled by default. To manually assign and ID, uncheck the box and enter a unique ID number in the attributes box. Default VC ID set for manual assignment of the ID number. For ease of keeping track of service ID and VC ID numbers, the client will select Inherit Service ID Value. Service Name based upon the template, this is a mandatory input, as indicated by the highlighted attributes box and the green arrow. Description, Service Tier, Administrative State and Automatic SDP Binding Creation optional parameters that are set according to corporate policy. Once the General parameters for the service have been configured, click on the Apply button to effect the changes to the 5620 SAM database but keep the Template window open.
Create Service Site from Template
918
Once the configuration changes have been effected to the 5620 SAM database, the configuration window will return with the remaining tabs to complete the process to create the service. As with creating a service using the step-by-step procedure of the wizard, the remaining portions of the service may be configured through the Components tab. To complete the service creation process: Open the Components tab of the window; Select the Service, Epipe Service in this case, and right click; Select Create Epipe Site From Template.
Create Epipe Site from Template
919
The site templates, associated child templates previously generated. will appear in the drop down menu. Select the appropriate site template: The Create VLL Epipe service Site Template window opens. Configure the parameters according to the provisioning instruction and corporate policy; Click on the OK button to save the changes and return to the Components window.
Create L2 Access Interface from Template
9 1 10
The next component to add to the service would be the Service Access Points, or L2 Access Interface (Epipe) service. From the Components tab: Navigate to the Access Interface entry under the appropriate service site; Right click and select Create L2 Access Interface From Template from the drop down menu. A list of available access interface templates will appear; Select the appropriate template from the drop down menu. The Create VLL L2 Access Interface From Template opens; Open each tab to ensure that all parameters are set according to the work order. In the example above, the Outer Encapsulation Value attribute under the Port tab has been set to must modify in the template. OK and Apply buttons will not appear until the parameter has been changed from the default.
Create SDP Bindings from Template
9 1 11
Service Distribution Paths are required when Service Access Points are located on separate network devices (distributed service). To add SDP Bindings from a template: Navigate to the Spoke SDP Bindings entry under the appropriate service site; Right click and select Create Spoke SDP Binding From Template from the contextual menu. A list of available Spoke SDP Binding templates will appear; Select the appropriate Spoke SDP Binding from the list; Step through each of the configuration tabs to ensure that all of the configurable parameters are set according to the work order and corporate policy. Click on the Apply button to save the changes and return to the Components window.
View Service Configuration
9 1 12
The operator completes the service configuration by repeating this process for the second service site for the service where the service access points are on different routers. Verify to ensure all the required components are included in the service. Verify that the Epipe service contains: At least one service site (for a single site service) or two for a multiple site (distributed) service; Two (2) service access points (SAPs); Endpoints if SAP redundancy is being configured; Two Service Distribution Path Bindings, if distributed service is being configured. Once the network engineer has determined all necessary components are present, click on the OK or Apply to save the service configuration to the 5620 SAM database, which in turn generates SNMP messages to the affected devices.
Manage Epipe Service
9 1 13
Once created, the network administrator or operator is able to view and/or manage the Epipe service from the 5620 SAM GUI. To manage or view the Epipe service configuration: Select Manage Services from the Main Menu Set the Search filter parameters, as required Click on the Search button Select the service from the list and click on either the Properties button or the Topology View button at the right side of the screen. The Properties button opens the configuration window under the General tab for the selected service. Service configuration information is provided under the appropriate tabs listed at the top of the window. Parameters in drop-down menus or in the white blocks may be changed. Changes to an existing service will prompt a warning to which the network administrator or operator will be required to acknowledge before changes will be affected. Viewing a graphical representation of the service is possible by clicking on the Topology View button of either window. An example is provided on the next page.
Manage Epipe Service Topology View
Service Site.
Service Type, Service Name and Site ID.
Service Distribution Path.
Service Access Point.

9 1 14
Create Services from Template Create Epipe from Template 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
The Topology View, provides the network administrator or operator with a wealth of information about the service through a graphical representation. All components, and their status, will be represented in the window. The network administrator or operator will be able to determine: Site IDs Service Type; Service Name; Service Access Points, including the Encapsulation IDs; Service Distribution Path Bindings Status and fault conditions of each of the above. As is the case throughout the 5620 SAM, it is possible to view any components Properties by selecting the component, then right-click and select the appropriate function from the contextual menu. Color coding is used to indicate Fault conditions based upon the ITU-T X.733 standard (discussed later in the course). In the picture above, green indicates that the service components are reporting a normal operational status. The check mark within the service site icon indicates that the managed device is in active communication with the 5620 SAM.
Last Blank Page

9 1 15
End of Module Create Epipe from Template
9 1 16
92
Section 9 Create Services from Template

Module 2 Create VPLS from Template
TOS36013_09_02 Issue 1.0
Document History
922
Create Services from Template Create VPLS from Template 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Document History Edition 01 Date 2009-06-09 Author BLAIN, Claude Remarks First edition
Module Objectives
Upon completion of this module, the student will be able to:
Create a VPLS from a base Service template; View Service Properties; View the Service topology
923
924
Services must be associated with a customer. Though a service may only have one customer, that customer may have more than one associated to them. To create a Customer using the 5620 SAM, the network administrator or operator will use the following sequence: From the Main Menu, select Manage Customers; In the new window, click on the Create button; Complete the customers details as provided in the configuration window; Click on the OK button. To verify that the customer was created, or edit any detail: Select Manage Customers from the Main Menu; Click on the Search button; Double-click on the appropriate entry or, select the appropriate customer and click on the Edit button; Review or modify the details, as required.
925
As discussed, a service requires a port facing the customer edge to be configured for Access and an Encapsulation type specified. To configure a port: Navigate to the Equipment view in the Navigation Tree; Expand the tree and select the appropriate port or ports. It is possible to configure multiple ports at the same time by through the Shift Click or Ctrl Click method; Right-click and select Properties from the contextual menu; From the Mode drop-down menu, select Access; From the Encapsulation Type drop-down menu, select the appropriate encapsulation type; Set the port MTU. Remember that the port MTU must be set to a value set to support the largest service MTU to be supported on that port; Select OK to complete the configuration.
Create a VPLS
926
To create a service from a template, select the appropriate template from a list and complete the configuration as would be done through the wizard. To create a VPLS from a template: Select Create Service From Template from the Main Menu; Select the appropriate template from the list in the new window. The network engineer can use the Search function to reduce the number of entries to be sorted through using filters; Click the OK button.
Create a VPLS
Customer Information.
Mandatory.
Service Information.
Auto-Assign ID or manually assign values based upon work order.
SDP Binding Information.

VC ID, Automatic Mesh Binding and Transport Type.
Object Life Cycle.

Maintenance or In Service
927
When the Create VPLS Service From Template window opens, the General tab will be populated as per the XML API script used to generate the template. The General tab provides the following information: Customer information this parameter may be already populated however, the network engineer can modify this entry by clicking in the Clear button and then use the Select button to reassign a customer to this service; Service information this information provides the unique identifiers for the service. The ability to change these parameters will depend upon the template configuration. In the example above, the template has been configured to allow service provisioning personnel to change these parameters (bolded text in white configuration boxes); Mesh SDP Binding these parameters define the characteristics of the Mesh SDP Binding. The service provisioning personnel will be required to define the VC ID, automatic Mesh SDP Bindings (where specific LSPs are not required) and the underlying Transport Type. In this example, it has been decided that the VC IP will be inherited from the Service ID, the automatic SDP Binding feature will be used and that the SDP will use RSVP-signaled LSPs; OLC (Object Life Cycle) sets the status of the service for alarm recognition purposes. In service is used to signal network operations personnel that the service is passing customer traffic whereas Maintenance is intended to indicate that the service is under repair and not used for carrying customer data. Click on the Apply button to save the changes and keep the window open.
Create a VPLS
928
Having clicked the Apply button, the configuration window remains open and the changes are saved in the 5620 SAM database. However, service components (Service Sites, Access Interfaces and SDP Bindings) have yet to be configured for the service to be commissioned. To configure service sites: Navigate to the Components window of the service configuration form; Select Sites from under the VPLS Service and right-click; Select Create VPLS Site From Template from the contextual menu and select the sites to participate in the VPLS service from the list. Each site is added individually, as shown above; The site template opens with the various tabs associated to it when it was first configured. Ensure all of the required attribute values are properly configured. Click the OK button.
Create Access Interfaces
Encapsulation Value.
Auto-Assign ID or manually assign values based upon port mode.
929
Service Access Points are virtual interfaces to provide customer access to the service providers network. A SAP consists of: a physical port configured to support Access points; an encapsulation type; and, an encapsulation ID value unique to the port. To create a SAP: Navigate to the Component window for the service; Navigate to the Create L2 Access Interface From Template of the appropriate Site;; Click the Port tab. The port may already be selected however, it may be possible to change the port assignment by clicking first the Clear button and then the Select button; Set the port Encapsulation Value, as required by the work order and click the OK button.
Add SDP Bindings
Automatic Mesh Binding.

From General tab at start of configuration.
Manually assign Mesh Binding.

Select SDP Binding and right-click. Create SDP Binding From Template
9 2 10
Service Distribution Paths are required when Service Access Points are located on separate network devices (distributed service). An SDP is created when a service is associated (bound) to a Service Tunnel. The network administrator or operator has the option of either manually or automatically creating SDP bindings. To manually create the SDP Bindings: Expand the Site listing under the Components window for the service; Navigate to Mesh SDP Bindings entry in the list. Where the automatic Mesh SDP Bindings feature was selected under the General tab, as is teh case in this example, the Bindings will automatically be created; If service provisioning personnel are to manually assign SDP Bindings, select the appropriate Binding type, right-click and select Create <xxx> SDP Bindings From Template (A VPLS supports both Spoke and Mesh SDP bindings); Select the appropriate template from the list provided and complete the configuration of the SDP Bindings, as per the work order.
VPLS Service Components
9 2 11
The network engineer completes the service configuration by ensuring that all the required components are included in the service. This is easily accomplished by selecting the Components tab and expanding the configuration tree for each of the service components, as shown above. Verify that the VPLS contains: At least one service site (for a single site service) or two for a multiple site (distributed) service; At least two (2) service access points (SAPs); Endpoints, if SAP redundancy is being configured; Service Distribution Path Bindings, mesh and/ or spoke, as required to support the network topology. Once it has been determined that all necessary components are present, click on the OK or Apply to save the service configuration to the 5620 SAM database, which in turn generates SNMP messages to the affected devices.
Manage the VPLS
9 2 12
Once created, the network administrator or operator is able to view and/ or manage the Epipe service from the 5620 SAM GUI. To manage or view the Epipe service configuration: Select Manage Services from the Main Menu Set the Search filter parameters, as required Click on the Search button Select the service from the list and click on either the Properties button or the Topology View button at the right side of the screen. The Properties button opens the configuration window under the General tab for the selected service. Service configuration information is provided under the appropriate tabs listed at the top of the window. Parameters in drop-down menus or in the white blocks may be changed. Changes to an existing service will prompt a warning to which the network administrator or operator will be required to acknowledge before changes will be affected. Viewing a graphical representation of the service is possible by clicking on the Topology View button of either window. An example is provided on the next page.
VPLS Topology View
Service Site.
Service Type, Service Name and Site ID.
Service Distribution Path.
Service Access Point.

9 2 13
Create Services from Template Create VPLS from Template 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
The Topology View, provides the network administrator or operator with a wealth of information about the service through a graphical representation. All components, and their status, will be represented in the window. The network administrator or operator will be able to determine: Site IDs Service Type; Service Name; Service Access Points, including the Encapsulation IDs; Service Distribution Path Bindings Status and fault conditions of each of the above. As is the case throughout the 5620 SAM, it is possible to view any components Properties by selecting the component, then right-click and select the appropriate function from the contextual menu. Color coding is used to indicate Fault conditions based upon the ITU-T X.733 standard (discussed later in the course). In the picture above, green indicates that the service components are reporting a normal operational status. The check mark within the service site icon indicates that the managed device is in active communication with the 5620 SAM.
Blank Page
9 2 14
End of Module Create VPLS from Template
9 2 15
Last Blank Page

9 2 16
101
Section 10 Alarm Management

Module 1 Fault Management - Alarms
TOS36013_10_01 Issue 1.1
Document History
10 1 2
Alarm Management Fault Management - Alarms 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Set global alarm policies Set alarm history behavior Set specific alarm policies Identify alarms raised against equipment and services Identify alarm details Identify all network alarms using the dynamic list
10 1 3
Alarm Management - Overview
SNMP Traps SNMP Traps X.733-standard X.733-standard Alarm fields Alarm fields
operator notes operator notes and and acknowledgement acknowledgement
impact analysis impact analysis and correlation and correlation
updated operational updated operational Status in Status in Near-real-time Near-real-time
alarm policy alarm policy control control
point-and-click point-and-click alarm alarm management management
correlated data correlated data in a historical in a historical alarm database alarm database
10 1 4
Fault Management Using Alarms Overview

The 5620 SAM converts SNMP traps from network devices to events and alarms. These are then correlated against the managed equipment and configured services and policies. Alarms are applied against the appropriate equipment and services. The fault management system provides: conversion of SNMP traps of device events to many X.733-standard alarm fields impact analysis and correlation of alarms to equipment and service-affecting faults updated operational status of equipment, services, and interfaces in near-real-time from the network device resources alarm policy control by network administrators so the administrators can determine how to handle individual incoming alarms and how alarm logs are created and stored point-and-click alarm management from both the dynamic alarm list and from equipment and services configured on the 5620 SAM GUI operator notes and acknowledgement to track the work undertaken to fix the problem that caused the alarm correlated data in a historical alarm database to provide trend analysis and records
Alarm Handling
Business Business Logic Logic
Rules Rules Methods Methods
Card 1/1 down
7x50
List of failed objects Card 1/1 down Affected objects Port 1 SAP-a Service-z SAP-b Service-y etc Client GUI
OSS
10 1 5
Alarm Management Fault Management - Alarms 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
Correlated Alarms
Correlated alarms mean that one alarm may cause fault conditions for many other objects. When alarms are correlated, the alarms will appear in multiple places. For example, if an alarm is raised because a port goes down, any services using that port would receive indication of the alarm, viewable from the service property form. This means that nearly all object information forms contain a Faults tab, which lists alarms affecting the object. All alarms appear on the Dynamic Alarm list. In the example above, MDA 1/1 reports an alarm that it is down. This event is passed to the Server which then passes it along to the Database. Through the business logic and other policies that have been configured, the 5620SAM determines that this event results in various ports, SAPs, Services and network interfaces will be affected. As a result, the Alarm Manager reports the affected MDA as an Object Alarm and all others as Affected Objects.
Viewing Correlated Alarms
10 1 6
The screens above display an example of a Correlated Alarm. The View Correlating Alarm button is now active. The Correlating Alarm ID field contains the parent alarm.
Outstanding Alarms
Dynamic Alarm Window
red
Critical Service affecting / Requires immediate attention Major Possibly Service affecting / Requires attention ASAP Minor Non Service affecting / Requires attention when possible Warning Information Only Condition Info acknowledged alarms Indeterminate Cleared
Navigation Tree orange

yellow aqua marine brown blue
white grey
10 1 7
Alarm Status, Severity, and Aggregation

Alarm status for the network is indicated in the navigation tree and the dynamic alarm window. Use the navigation tree to view the status of alarms on individual objects, and the aggregated alarm status. Events are mapped to the ITU-T X.733 Alarm Reporting, as shown above. Alarm Status Red Severity Critical Description Conditions that have an impact on service and require immediate attention Conditions that may have an impact on services and require attention as soon as possible Conditions that have no impact on services but require attention when possible Conditions that are reported for information purposes only
Orange
Major
Yellow
Minor
Cyan Mocha Blue Grey
Warning Condition Info Cleared
Reports alarms that have been acknowledged Reports alarms that have been cleared
Dynamic Alarm Window

Alarm Counter
Alarm details
Window Configuration - Right click on Title Bar
10 1 8
The Dynamic Alarm window provides the network operator with a mechanism to keep track of outstanding alarms as well as session alarms; that is, alarms that occur from the time that they have logged into the 5620 SAM. Outstanding alarms are listed as soon as the network operator starts a session. The colour coded blocks along the top report the total number of new alarms by severity since the session was started and the time of the most recent. Clicking on the flag resets the counter to zero. Note that this merely resets the counter and does not clear nor delete the alarms from the Alarm list. The alarm information presented is configurable by right-clicking on the Title Bar (as shown above) and selecting, or deselecting) the appropriate box next to the information item. These changes will revert to the default settings unless the network operator commits them to the database. To save modifications, select Save Table Preferences from the drop down menu. Note that these changes are saved on a peruser, per-workstation basis.
Session Alarm Counters
10 1 9
Additionally, it is possible for the network operator or administrator to keep track of alarms as they occur during a session. This would mean that while they are working on existing alarms, new alarms appearing in the list would be displayed using session counters. To enable session counters: Select Application > User Preferences from the main menu; Check the box next to Show Alarm Flags and then OK or Apply. A series of color-coded boxes appears above the title columns in the list. The colors correspond to the alarm severity as defined by the ITU-T X.733 standard for alarm reporting. The number corresponds to the number of alarms with that particular severity that have occurred since the network operator or administrator has logged into this session. The last box corresponds to the 5620 SAM Server date and time of the most recent alarm. Counters can be reset to zero by clicking on the flag.
Dynamic Alarm Statistics
Summary of session alarms by type and status
10 1 10
The Alarm Statistics tab enables the network operator to keep track of the session alarms statistics at a glance. It provides a summary of all session alarms by type and status (acknowledged or unacknowledged).
Alarm Status Acknowledged
Description Alarms to which a network operator has indicated that it has been noted. Acknowledged alarms are neither cleared nor removed from the outstanding alarms list. It is merely a mechanism to indicate that the alarm(s) has (have) been seen. Alarms to which no network operator has indicated that it has been noted. Unacknowledged alarms remain in the outstanding alarms list pending intervention
Unacknowledged
Alarm Status Navigation Tree
Aggregate alarm status
Object alarm status
Object Alarm specific object declaring the alarm condition. Aggregate Alarm all alarms below the listed object in the hierarchy. Most severe alarm declared at top of each branch.
10 1 11
The Navigation Tree can also be used to determine alarm status within the network. In this window, alarms are displayed in a hierarchical method whereby a child reports an alarm condition to its parent (the next higher level). This is repeated up the navigation tree to the next higher level until it reaches the top of the tree. Several child objects may declare different alarm severities to their parent, at which point the parent will report the highest severity to the next level. These alarms are declared either as Object alarms or Aggregate alarms. Object alarms are declared in the box that appears next to objects in the Navigation tree. This indicates the specific object that has declared the alarm condition. The alarm type and its severity are displayed according to its color code and letter. Note that a major alarm is indicated with a capital M and a minor alarm is indicated by a lower case m. Aggregate alarms are declared in the circle that appears next to objects in the Navigation tree. This indicates alarms exist in child objects. The alarm type and its severity are displayed according to its colour code and letter. Note that a major alarm is indicated with a capital M and a minor alarm is indicated by a lower case m. On the Navigation tree, an aggregated alarm may appear but no child object in the tree shows an alarm. This is because the navigation tree is a filter, which presents different views of Information. Aggregation of alarms on the navigation tree is affected by the view chosen. Change the view, for example, from Equipment to Network from the drop-down menu. The aggregated alarm on the child object may be visible from the new view.
Alarm Status - Icons
Aggregate alarm Object alarm
Equipment
Connectivity
(resync status)
Aggregate alarm Aggregated Connectivity

(resync status)
Group
Aggregated link
(resync status)
10 1 12
Network operators are also able to obtain alarm status in their network from the icons available in the topology views. Two different icons are available in the 5620 SAM; Equipment icons and Group icons.
Equipment
Each node managed by the 5620 SAM has a unique icon. There are three (3) boxes along the side of each icon.
Aggregate alarms are declared in the top-most box; alarm type and severity indicated by the colour and
the letter for the most severe alarm being declared for that equipment.
Object alarms are displayed in the center box; alarm type and severity indicated by the colour and the
letter for the most severe alarm being declared for that equipment.
Connectivity alarms, are displayed in the bottom box and indicate the resync status of the node which is
related to the SNMP connectivity between the node and the 5620 SAM. The color of the icon itself is directly related to Connectivity status. Grey-Green - SNMP connectivity between the node and the 5620 SAM is good (a checkmark will also appear in the right hand box. Yellow - Database transfer in progress. Red -SNMP connectivity between the node and the 5620 SAM is down. This may be an indication of a network failure, as well as a resync failure.
Alarm Status Icons [Cont.]

Group Switch to notes view!
Network operators have the ability to create groups of nodes for easier navigation throughout their network. The group icon is shown on the next page and provides aggregated alarm status for nodes in that group.
Aggregate Alarms As in the Navigation Tree, alarms within the group are reported to the highest level
of each node and aggregated within the group. The highest severity alarm will be reported, indicated by the appropriate letter/ color in the upper right hand block.
Aggregated Connectivity As with the equipment icon, this block indicates the status of the SNMP
connectivity to the nodes within the group. The status will be declared by colour in the center block.
Aggregated Links The status of the physical inks within a group will be reported in the lower right
hand block of the icon. This requires that the physical links between nodes be created and the status will be declared by color in the lower right hand block.
10 1 13
Alarm Status - Properties
Object alarm
Related Object alarms
10 1 14
Any managed object could possibly report a alarm condition. The 5620 SAM Alarm Manager enables the network operator to view these alarms through the Properties tab of any selected object. The Faults tab provides the ability to view Object Alarms, Affecting Alarms, Aggregate Alarms and Alarms on Related Objects. The definitions for each of these categories is as already discussed. Alarms are considered related or affecting when there is a relationship between objects. The 5620 SAM business logic determines that, for example, if a port goes down, and the port is used as a SAP, then a customer must be affected by the port down alarm.
Alarm Status - Details

Alarm Details
Alarms List
10 1 15
The detailed information about an alarm is available any time that they are listed. From the list, using the scroll bar to move right or left will provide the network operator with all pertinent information dealing with the selected alarm. Additionally, double-clicking on a selected alarm entry will open the Alarm Info window, which will display all alarm information in a single window. As previously discussed, the details to be displayed can be configured on a per-user, per-session basis by right-clicking on the Title bar and selecting or deselecting alarm information, as required. Note that these changes will revert back to the default settings unless the network operator saves the changes prior to terminating the session.
Alarm Filter Management
10 1 16
Network operators or administrators can filter the Dynamic Alarm List based upon various selectable criteria. Selecting the Manage Filter button, as indicated above, opens a Search Filter window. A list of selection properties appears in the Unused Properties portion of the window. To create a filtered alarm list: Select an Unused Property from the list; Click on the arrowhead pointing to the right; Using the dropdown menus, select the appropriate filter criteria. Using multiple Unused Properties in a single filter permits the network operator or administrator to further refine the alarm list; Click on OK or Apply. The filtered list will be displayed in the Outstanding Alarm window. Instead of having to reconfigure filters each time one is to be used, it is possible to save a filter for future use. Once the filter criteria has been defined, click on the Save Filter button. Provide a name for the filter and click on the Save button. To use the filter, click on the Select Filter dropdown menu and select it from the list.
Alarm Model
Alarm filters are now ordered alphabetically.
Paused or Active Alarm Status
A new field in the alarm window that shows the operator that acknowledged the alarm.
10 1 17
It is now much more noticeable for operators to notice when the dynamic list is paused. The text is filled with red.
Alarm Management
Select Alarm(s) Right-click on the Selected Alarm
10 1 18
Managing outstanding alarms is accomplished from the Dynamic Alarm List. Selecting an alarm, or multiple alarms, provides the network operator or administrator a series of function available by right-clicking on an alarm and selecting an action from the contextual menu, as show above. As is the industry standard, Acknowledgement of an alarm will not remove it from the Outstanding alarm list. This is merely an indication to the Network Operation Center personnel that someone has recognized the existence of this condition and is dealing with the issue. Clearing an alarm sends a copy to an alarm log file somewhere (to be discussed later) and removes it from the outstanding alarm list. Deleting the alarm removes it from the list and keeps no record of its existence. However, some service providers may deem this to be too dangerous; therefore, this default action may be modified in the 5620 SAM (to be discussed later in this module).
Implicitly Cleared and Correlated Alarms
10 1 19
To facilitate alarm suppression, the following changes will be made to the Alarm Object: This field indicates which alarm the current alarm is correlated under. An Implicitly Cleared field indicates whether the alarm is automatically cleared or not. A Correlating Alarm ID field has been added as of SAM 6.0. The operator can turn suppression on or off through User Preferences. Suppression will be enabled by default. When it is enabled correlated alarms will not be visible.
Correlated Alarms
The operator can turn suppression on or off through User Preferences.
Affected Objects Screen
10 1 20
Suppression will be enabled by default. When it is enabled correlated alarms will not be visible. The alarm information window will have the following changes: The Affected Object tab will be renamed to Affected Objects. A new Affecting Objects tab has been added. A new Correlated Alarms tab will be added. The Affecting and Affected Objects tabs contain the list of relevant full names with the ability to sort and filter.
Correlated Alarms
Example of a Correlating (Parent) Alarm. Known this because the Number of Correlated Alarms field contains a value.
10 1 21
The example screenshot above shows Alarm Tab / info Tab of a correlating (parent) alarm. Correlating alarms display a numeric value in the Number of Correlated Alarms field. On the example above there are 7 correlated alarms. The network operator can find more details about these correlated alarms by opening the Correlated Alarms tab, as shown above.
Alarm Thresholds
The 5620 SAM provides tools to escalate and de-escalate the severity of alarms using alarm threshold Switch to notes view! measures, configurable using the specific alarm parameters. Escalation rules are applied when the number of instances of the alarm, also called the frequency, reaches the configured value. De-escalation rules are applied when the number of instances of the alarm drops below the configured frequency value. When the escalation value is reached, the alarm is escalated to the configured value. When the appropriate frequency to escalate and de-escalate is reached, the alarm is first escalated in severity and then de-escalated. However, if the alarm is deleted, then the frequency calculation is affected. When no de-escalation policy is applied, escalated alarms are not de-escalated once the frequency of the alarm drops below the alarm escalation threshold. Escalation policies are affected by the auto parameter of the global alarm deletion policy. When an escalation policy uses the default when cleared option, the escalation policy does not work. The parameter must be configured to a value other than when cleared to ensure the escalation policy is successful.
Alarm Suppression
The 5620 SAM is designed to suppress alarms when numerous SNMP traps are sent in quick succession for the same type of event. This prevents alarm storms during intermittent outages in the network caused by bouncing devices; for example, when links go up and down rapidly. The 5620 SAM continues to resynchronize the network, and if the bouncing devices continue to send down state SNMP traps, the 5620 SAM eventually receives the trap and generates the appropriate alarm. To indicate how often an alarm is raised, the number of occurrences of each instance of the alarm is All Rights Reserved 10 1 22 tracked within Management - Alarms record of the initial alarm.Alcatel-Lucent 2009the Statistics tab of an individual Alarm the alarm Click on Alarm Management Fault 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator Info form to see how often the alarm was raised. To cause alarm severity to escalate if an alarm reoccurs a specific number of times, use the threshold crossing alert function
Alarm Policy
10 1 23
The 5620 SAM provides the ability to configure the characteristics for how alarms will be managed. By selecting Administration Alarm Settings, the network operator is presented with the Global settings for the manner in which the Alarm Manager will treat alarms. This includes: manual or automatic alteration of alarm severity; manual or automatic alteration of alarm deletion, alarm history database behavior; and specific alarm behavior.
Automatic Purging of Alarms

Large numbers of outstanding alarms can affect system performance. To eliminate this, outstanding alarms are purged based on the severity of the alarm, until the system limit of 60,000 is reached, and all alarms are purged to the historical alarm log. No automatic purging of alarms is necessary when historical alarm logging and purging policies are configured. When alarm policies are not configured, the system purges alarms in the following sequence: When the outstanding alarm count reaches 50,000, non-critical alarms are purged to the historical alarm log until the alarm count drops to 45,000. An alarm is raised indicating an alarm purge. When the outstanding alarm count reaches 60,000, all alarms are purged to the historical alarm log until the alarm count drops to 45,000. An alarm is raised indicating an alarm purge.
Alarms Object Life Cycle Status Example

I only want to see alarms on equipment that is In-service
NOC Operations
I only want to see alarms on equipment that is Maintenance
NOC Operations
10 1 24
Object Life Cycle

A new status for network objects is introduced with 5602 SAM Release 6.0, that allows alarm filtering. Network objects can be in Maintenance or In-Service state. When nodes are being commissioned, or under maintenance, and generate many alarms, these alarms can be filtered out for the operational NOC. Operators doing commissioning can filter out alarms from operational equipment and focus on equipment being commissioned. The alarm display is de-cluttered and now the user can easily see important alarms, which enables quicker troubleshooting.
Details
OLC states are Maintenance and In-Service. Commissioning is equivalent to Maintenance. OLC states are set manually by an operator for a specific port or for an entire node which will mark all ports or for multiple nodes at once. The alarm window can be filtered using the OLC state to manage what is shown on the alarm windows. Special check boxes make this easy. The OLC status can be set to either Maintenance or In Service and can be configured by the user on the following objects: Network Element Card Slot Daughter Card Slot Port Composite Service Service Site Changing the OLC state of an object also changes the OLC state of other related objects.
Object Life Cycle
The configuration form for each OLC configurable object contains a new attribute displaying the OLC state.
10 1 25
If a parent object has its OLC state set to Maintenance it is not possible to change the OLC state of the child back to In Service. When an object that contains an OLC state attribute is created within SAM, the value of the OLC will be determined by the related higher level object. In cases where an object has multiple related higher level objects, some set to In-Service and some set to Maintenance, the new object is set to Maintenance.
Object Life Cycle [Cont.]

SAM supports a new discovery rule to allow the user to specify the value of the NE OLC State upon discovery of the NE. By default the NE OLC is set to In-Service.
10 1 26
A new option serviceOLCState is specified in the nms-server.xml file. This specifies the OLC state SAM will use as the default on creation of a service or composite service. By default serviceOLCState is set to true. <serviceOLCState isServiceCreatedInMaintenanceState="true" />
Note
[Inserted Note] This is a change from existing behavior, but would only effect OSS clients if they were choosing to take action based on this new attribute, which would necessitate a change of their application in any case. Also if old behavior is required the flag can be changed in xml.
The OLC state of the alarm is configurable by right clicking on the alarm entry and choosing Assign OLC State
The alarm list can be filtered by OLC State using the existing filter mechanism
10 1 27
On creation of an alarm, SAM checks the OLC state of the object on which the alarm is being raised, and also the OLC state of the NE. If either of these states is set to Maintenance then the OLC state of the alarm is set to Maintenance, otherwise the OLC is set to In-Service. OLC state of an existing alarm does not change if the objects OLC state changes
10 1 28
SAM provides a new window within the GUI called OLC, accessed from the admin menu. Administration OLC From this window the user is able to list objects with a specific OLC state. Only the objects on which the user can specifically configure the OLC are listed, not those related objects that are set by SAM indirectly when the user configures higher level objects.
Alarms - Historical
10 1 29
Historical alarms are a mechanism by which the 5620 SAM enables the network operator to keep track of what has transpired in their network and the frequency to which things occur. Selecting Tools Historical Alarms opens a filter window. Once the filter has been defined, clicking on the Search button will provide a list of the appropriate alarms. Double-clicking on any of the alarms listed will open its Properties window with detailed information as shown on the next page.
Alarms Historical [Cont.]
10 1 30
Understanding what has transpired in a network goes a long way to helping the network operator to isolate problems within their network. The information available under the tabs in the Historical Alarms window provides a useful data in helping to isolate problems within their network. Information pertaining to each alarm is presented in four separate windows: Info - Provides information about the specific alarm, such as: site ID; Site Name; Alarmed Object type; Alarmed Object name; alarm type; alarm severity; etc Severity - Provides information pertaining to the severity of the alarm and any changes that may have occurred as a result of escalation and/ or demotion. This also includes the time that the alarm was declared and at which any changes occurred. Statistics - Provides information pertaining to the frequency at which the alarm has occurred. Additional Information - self explanatory.
Alarm History
10 1 31
As of SAM 6.0, the Alarm History filter is further refined to only list history objects related to the alarmed object.
Questions
?
10 1 32
1. The 5620 SAM converts SNMP traps to X.733 standard alarm fields.
a. True b. False
2. Alarms status can be determined by the network operator through:

a. the Dynamic Alarm list b. the Navigation Tree c. the network Topology View d. all of the above
3. The circle next to a Daughter Card icon in the Equipment tab of the Navigation tree is orange and contains the letter M. This indicates:
a. a the MDA has declared a minor object alarm b. the MDA has declared a major object alarm c. the MDA has declared a minor aggregated alarm d. the MDA has declared a major aggregated alarm
Questions [Cont.]
4. A network operator would expect to see a link failure declared on the Group icon.
a. True
b. False
5. The 5620 SAM Alarm Manager declares every alarm independently and has no mechanism to relate alarms to others.
a. True b. False
6. SNMP traps are sent with any change in node status providing for near real-time operational status.
a. True b. False
10 1 33
Answers
1. The 5620 SAM converts SNMP traps to X.733 standard alarm fields.
a. True
b. False
2. Alarms status can be determined by the network operator through:

a. the Dynamic Alarm list b. the Navigation Tree c. the network Topology View d. all of the above
3. The circle next to a Daughter Card icon in the Equipment tab of the Navigation tree is orange and contains the letter M. This indicates:
a. a the MDA has declared a minor object alarm b. the MDA has declared a major object alarm c. the MDA has declared a minor aggregated alarm d. the MDA has declared a major aggregated alarm
4. A network operator would expect to see a link failure declared on the Group icon.
a. True 34 10 1 b. False
5. The 5620 SAM Alarm Manager declares every alarm independently and has no mechanism to relate alarms to others.
a. True b. False
6. SNMP traps are sent with any change in node status providing for near real-time operational status.
a. True b. False
End of Module Fault Management - Alarms
10 1 35
Last Blank Page

10 1 36
111
Section 11 Performance Monitoring

Module 1 Performance Management
TOS36013_10_01 Issue 1.1
Document History
11 1 2
Performance Monitoring Performance Management 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Module Objectives
Describe how statistics are applied to services Create a file policy Create multiple accounting policies Modify existing accounting policies Monitor statistics data on:
Services based on applied accounting policies Equipment using near-real-time statistics logged from the 7x50 router
Plot statistical data
11 1 3
Overview
Two types of statistics collected:
Performance Statistics
Equipment and object-based performance statistics. Logs show equipment and logical network object usage rates.
Accounting Statistics
SAPs measure usage on each service queue, which can be rolled up for billing. Network port statistics measure usage within each forwarding class queue, as defined on the network port.
11 1 4
Statistics Type
The 5620SAM, 5620SAM-O, and service- and equipment-related statistics counters can be configured to collect statistics from the managed devices. The 5620SAM supports the following types of statistics: performance statistics for network objects accounting statistics for network ports and SAPs The benefits of statistics collection from the 5620 SAM are: equipment statistics monitoring in near-real time service-based enforcement of SLAs detailed accounting statistics for billing detailed control of statistics collection counters, collection intervals, and application to network objects
Equipment and object-based performance statistics help operators monitor the use of physical and logical network elements in near-real time. Statistics logs show equipment and logical network object usage rates.
Accounting statistics for SAPs measure usage on each service queue, which can be rolled up for billing. These accounting records can be used to determine customer service usage, and to feed into a billing application. Network port statistics measure usage within each forwarding class queue, as defined on the network port. This information can be used to track link utilization and network traffic patterns and trends, to help capacity planning and traffic-engineering efforts.
Statistics Collection Process

SAM Server XML request to retrieve log OSS Client 1 5 JMS event to signify request completed 4 6 OSS initiated FTP session 3 Query response from database Database
Query sent to database 2
XML-formatted stats file stored in server directory
11 1 5
Statistics Collection Process

The figure above provides and overview of the synchronous statistics collection process and the relationship between the 5620SAM and OSS client components. Step 1: An XML request is sent to retrieve log records from the OSS client. Step 2: A query is sent from the SAM Client to the SAM database. Step 3: The SAM database returns a query response to the SAM Client. Step 4: An XML-formatted statistics file is generated from the SAM database query response. This file is stored on the SAM Server in the directory defined during installation. Subdirectories are not supported. Step 5: A JMS message is sent from the SAM Client to the OSS Client application to signal that the request to generate the statistics file is completed. Step 6: The OSS Client initiates an ftp session to transfer the file from the server to the OSS Client. It is possible to transfer files through an ftp or Secure (scp) session. To configure which method will be used, select Mediation Mediation Security. From the list, select the appropriate SNMP mediation policy and select Properties. Scroll down through the window to find File Transfer Protocol and select either FTP or Secure (scp) from the drop down menu.
Stats MIB Policies - Scheduled
11 1 6
Stats MIB Policies - Scheduled

Performance statistics are counters that typically provide information for monitoring and troubleshooting purposes on physical equipment, routing, and other aspects of the NE. Collecting performance statistics can be CPU intensive and therefore, all statistics are turned down after the initial installation of the 5620 SAM. The network administrator or operator may configure the 5620 SAM to collect statistics automatically, referred to as Scheduled, or they may initiate an instance for collecting statistics at any time, also referred to as Non-Scheduled Selective. Scheduled statistics collection is performed through configuring a policy which will permit the network administrator or operator to specify the collected object MIB, set the collection time interval and then enable the policy. To configure a Stats MIB Policy: Choose Tools Click on Search. Configure the ftp or scp parameters to reflect those on the NE. Click on the Create button to create a new policy or select the Default Policy and click on the Properties button to modify the existing policy. Statistics MIB Policies from the 5620 SAM main menu.
Select a MIB Statistics Policy from the Manage MIB Statistics Policies window.
Stats MIB Policies Scheduled [Cont.]

Displayed Name optional Displayed Name optional Polling Synchronization Time server time Polling Synchronization Time server time when window opened when window opened
11 1 7
Stats MIB Policies Scheduled

Should the network administrator or operator decide to create a new policy by clicking in the Create button, the NE MIB Statistics Policy (Create) window appears. The new policy will require: a Policy ID Displayed Name which is optional but can be used to filter against when searching for the appropriate entry at a later date. Poller Synchronization Time which will be used as the reference for the statistics collection interval. By default, this parameter is populated with the server time when the window was opened bit may be modified, as required. Polling Admin State sets the administrative level for this policy. Select OK or Apply to save the changes. Note that the new policy now appears in the list of available statistics policies. Select the new policy from the list and click on the Properties button on the right side of the configuration window. Click on the MIB Entry Policies tab.
Configure Stats MIB Policies - Scheduled
11 1 8
Stats MIB Policies Scheduled

Within the MIB Entry Policies tab, the network administrator or operator is presented with all of the statistical MIBs for each of the 5620SAM managed devices. Refer to the AlcatelLucent 5620 Service Aware Manager, Release 6.1, Statistics Management Guide for the definitions of the various MIBs. Scrolling through the list, the network administrator or operator may select individual or multiple entries, as required. Once selected, click on the Properties button and the details for the selected entry, or entries. Configure the policy by defining the: Polling Interval from the drop-down menu, select the appropriate interval between 5 minutes to 48 hours. Note that stats polling increases traffic on the network management segment therefore, the polling interval should be calculate with care. Administrative State enables or disables the polling policy, as required. Click on the OK or Apply button to save the policy changes.
Statistics Collection Non-Scheduled Selective
11 1 9
Statistics Non-Scheduled Selective

Equipment and object-based performance statistics help operators monitor the use of physical and logical network elements in near-real time. Statistics logs show equipment and logical network object usage rates. Though the network administrator or operator may have enabled automatic collection of statistics, as already discussed, it may become necessary to take a snapshot of the statistics of a monitored object before the next collection interval. The 5620 SAM enables the accommodation of this situation through the collection of Non-Scheduled Selective statistics. To start the collection process, navigate to the device to be monitored and select Properties from the contextual menu. From the Properties window, open the Statistics tab. All available categories of statistics for the selected device will appear under various tabs. At this point, the network operator has the option to collect individual classes of statistics or to collect all available classes by selecting either the Collect or Collect All button. Collect capture the current statistical values of the selected statistic (tab from within the Statistics window) for the selected object. Collect All capture the current statistical values for all statistics associated with the selected object.
Statistics Collection Non-Scheduled Selective [Cont.]
11 1 10
Once the network administrator or operator has selected the class of statistics to be collected, a Non-Scheduled Selective entry will appear in the Results list, which can be viewed from the SAM Client GUI. A new entry will exist for each time a Non-Scheduled Selective collection event is initiated. Navigate to the appropriate class of statistics to be viewed. From the list, highlight an entry and select the Properties button. The results for that file are now displayed. Scrolling to the bottom of the window displays two columns of numbers. The left side column displays the total number of statistics collected since the process was launched. The right hand side displays the difference (delta) between collection intervals. The collection interval depends upon how often the network operator selects the Collect or Collect All button.
Real-Time Statistics and Graphing
Select an Object and the Statistics tab Select a Statistics class and an entry.
Click on the Plotter button and select New Plot.
11 1 11
With Release 6.0 of the 5620 SAM, statistics can now be plotted on a graph. To add entries to this list, select an object from the map or the navigation tree, and then select the Statistics tab. Select a statistics class, and then select an entry from the listed statistics. The plotter button gets enabled. Click on the plotter button, and select an existing graph window or the New Plot option from the popup menu.
Real-Time Plot Button Historical Plot Button
Real-Time Plot Real-Time Plot point time Indicator of current plot area
Tabular View
11 1 12
To initiate a real-time plot, click on the real-time plot button Moving the cursor over a plot point displays plot point time.
This historical plot button plots the historical statistics already available in the SAM DB for the selected statistics counters in the Graph Configuration list described in the previous section. Log messages are available at a debug level to indicate the number of active collection sessions. Messages will be printed to the log when collection sessions start or end. The user can save the plotted data to file in either tabular (.CSV/HTML file) or graphical format (JPG / PNG file). For saving the tabular data, right-click on the table header and select Save to File option. For saving the current view of the graph, click on the Save Current View toolbar. button on the
The Polling Interval controls the time interval between successive real- time sample polls. This interval will range from 10 seconds to 3600 seconds (one hour). The default value at start up is ten seconds. The bottom of the plot area contains a summary area, showing a zoomed out view of the entire plot data. An indicator shows the area of the plot that is currently being displayed in the main plot window above. When the indicator is moved, the area being plotted will change. When real-time collection is in progress, the indicator always scrolls to the latest data being collected. Double-clicking on the indicator will stop this auto-scrolling, so the user can view the older entries. Indicator color changes from green to red on double clicking to indicate that autoscrolling is turned off.
Tabular View
Tabular Options
11 1 13
A tabular view of the statistics is displayed below the plot area. Entries in the table are highlighted when mouse points to the corresponding data-point on the main plot. Right click on the table header, provides various SAM table options like number of records, sorting, show/hide columns, saving the table in CSV/HTML formats, and saving table preferences options.

Application User Preferences Statistics Plotter
11 1 14
The User Preferences window has a new Statistics Plotter Tab. The user can set the following options: Default Polling Interval (Max =3600 seconds) Maximum data retention time (Max = 86400 seconds)
Accounting statistics for SAPs and network ports, which can be used for billing and traffic-analysis purposes Consists of Accounting Policy associated to File Policy
Log 1 Log 1
Log 2 Log 2
SAP 1 SAP 1 SAP 2 SAP 2 SAP 3 SAP 3 SAP n SAP n SDP 1 SDP 1 SDP 2 SDP 2 SDP 3 SDP 3 SDP n SDP n
Log 1 Log 1
Log 2 Log 2
11 1 15
Accounting statistics for SAPs measure usage on each service queue, which can be rolled up for billing. These accounting records can be used to determine customer service usage, and to feed into a billing application. Network port statistics measure usage within each forwarding class queue, as defined on the network port. This information can be used to track link utilization and network traffic patterns and trends, to help capacity planning and traffic-engineering efforts. Collecting accounting statistics requires that an accounting policy be associates to a file policy. The network operator can then apply the accounting policy to the appropriate SAP or SDP without service interruption. Based upon the File Policy parameters, the collected data is written to a log which the network operator can view once it has completed its active log interval.
File Policy
11 1 16
File Policy
A file policy is used in tandem with an accounting policy to manage statistics collection. It defines the Rollover, Retention, and the Drive to which the log file will be written. Multiple file policies can be configured on the 5620 SAM however, only one file policy can be associated with one accounting policy. Rollover defines the time for which the log file will be open. Retention defines the time for which the log file will be kept before being deleted. Drive defines where the log file will be stored. Network operators should note that managed devices have sufficient resources to support largescale statistical policy usage. Ensure that all collection intervals, file retention intervals, and rollover intervals are sufficient. Also, ensure that statistics are retrieved from the storage devices on a regular basis.
Accounting Policy
11 1 17
Accounting Policy
An accounting policy is used in tandem with a file policy to manage statistics collection. It defines the type of information and the interval at which data will be collected. Accounting statistics for SAPs measure usage on each service queue, which can be rolled up for billing. These accounting records can be used to determine customer service usage, and to feed into a billing application. Network port statistics measure usage within each forwarding class queue, as defined on the network port. This information can be used to track link utilization and network traffic patterns and trends, to help capacity planning and traffic-engineering efforts.
Type defines the information that is to be collected. This data can be in the form of Octets
or Packets and can be selected on an SAP or SDP (Service Tunnel).
Collection Interval defines the interval, in minutes (5 min. is the minimum), to which the data will be sent to the log file.
Statistical Logs
11 1 18
Viewing Statistical Logs

Statistics logs contain the statistics data for equipment and services that collect statistics. Choose Tools Statistics Browser from the 5620 SAM main menu. The browse log records filter window appears. Modify the filter to generate a list of statistical data. Choose from a drop-down list of log types. The log types indicate the classes of statistics available. Available stats are a combination of the following: Choose from a drop-down list of the types of log records, for example the most current set of data for the statistics class, or data that has already been logged. Select a filter. Available filters are determined by the log class. For each log class, there are multiple individual statistics upon which the network operator can filter.
Questions
?
11 1 19
Performance Monitoring Performance Management 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
1. What policy is used in tandem with an accounting policy to manage statistics collection?
a. Ping policy b. Network policy c. File policy d. Alarm policy
2. Statistics policies can be created for which of the following?

a. Service access points b. Network ports c. SONET/SDH channels d. All of the above
3. What protocol is used to transfer statistics files from the 7x50 router to the 5620 SAM Server?
a. FTP b. SNMP c. OSPF d. None of the above
Answers
1. What policy is used in tandem with an accounting policy to manage statistics collection?
a. Ping policy c. File policy d. Alarm policy
b. Network policy
2. Statistics policies can be created for which of the following?

a. Service access points b. Network ports c. SONET/SDH channels d. All of the above
3. What protocol is used to transfer statistics files from the 7x50 router to the 5620 SAM Server?
a. FTP b. SNMP c. OSPF d. None of the above
11 1 20
End of Module Performance Management
11 1 21
Last Blank Page

11 1 22
App1
Appendix
Appendix 1 Redundancy
TOS36013_A_01 Issue 1.0 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator TOS36010 Issue 1.0
All Rights Reserved Alcatel-Lucent 2009 TOS36013_A_01 Issue 1.0 Section 12 Module 1 Page 1
Blank Page
This page intentionally left blank

Appendix 1 2
Appendix Redundancy 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
Module Objectives
List the components and configurations for a redundant 5620 SAM Explain the communications process for each component under normal conditions Explain the communications process for each component during the various fault conditions
Appendix 1 3
Appendix Redundancy 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Redundancy Overview
Redundancy is only supported on Solaris workstations. In typical installations, redundancy between the Switch to notes view! 5620 SAM server and database is used to ensure network visibility in case of NMS domain LAN errors or workstation problems. The current state of each server and database determines whether it is primary or standby. The primary server actively manages the network and the primary database is open in read/write mode. Two redundancy configurations are supported: collocated and distributed. In a collocated installation, the 5620 SAM server and database are on the same workstation. In a distributed installation, the 5620 SAM server and the 5620 SAM database are on separate workstations. The servers and databases are four separate entities regardless of the physical or geographical deployment. The 5620 SAM servers provide redundancy by pinging each other periodically. If the standby server cannot reach the primary server for 60 seconds, the standby server activates and becomes the primary server. The 5620 SAM databases provide redundancy using Oracle functions. The 5620 SAM client GUIs are connected to the server that is the primary server. Following a server activity switch, when the standby server becomes the primary server, the 5620 SAM client GUIs are connected to the primary server, which was formerly the standby server. Server activity switches are transparent to the 5620 SAM client. OSS clients are also connected to the server that is the primary server, but following a server activity switch, the connection is lost as the primary server becomes the standby server. OSS clients need to know which server is the new primary server and reconnect to it. Both the primary and standby servers have visibility of the redundant databases. The 5620 SAM GUI can be used to: check the status of redundant 5620 SAM servers and databases
Appendix 1 4
perform a switchover from the primary to the standby 5620 SAM database
Caution
To help avoid 5620 SAM performance problems, ensure that the primary database and server are installed and running on the same side of the WAN. Recommendations Consider the following: Only 5620 SAM or system administrators with appropriate workstation and user privileges on the server workstation, or client GUI users with admin user group privileges, can perform the server activity switch or database switchover. Both the server and the database must be redundant. For example, redundant servers and a standalone database are not supported. The terms active and secondary may be used instead of the terms primary and standby. The NMS domain configuration must be able to handle the latency and bandwidth requirements described in the 5620 SAM Planning Guide. Ensure that the active server and database are installed on the same side of the WAN.
Overview
OSS or GUI clients Configurations: Distributed; or Collocated
SAM Server
SAM Server
Primary
Standby
Components: Primary (Active) Server Standby (Secondary) Server Primary (Active) Database Standby (Secondary) Database
Oracle DataGuard
db
Primary
db
Standby
Legend Normal Communication Database Replication Activated during failure
Appendix 1 5
5620 SAM Collocated Redundancy

Consider the following: The operating system installed on the collocated primary and standby 5620 SAM server/database workstations must be the same versions and at the same patch level. The layout and partitioning of the disks that contain the 5620 SAM software, the Oracle software and the database data must be identical on the collocated primary and standby 5620 SAM server/database workstations. The workstation that is initially used as the collocated primary 5620 SAM server/database must be installed before the workstation that is initially used as the collocated standby.
5620 SAM Distributed Redundancy

Consider the following: The operating system installed on the primary and standby 5620 SAM server and the primary and standby 5620 SAM database workstations must be the same version and at the same patch level. The layout and partitioning of the disks that contain the 5620 SAM software, the Oracle software, and the database data must be identical on the primary and standby 5620 SAM database workstations. The workstations for the primary 5620 SAM server and 5620 SAM database should be installed on the same LAN with high-quality network connectivity.
Communications under Normal Conditions

OSS Clients 7 7 5
SAM Server
3 SAM Clients
db
Primary
Traps Traps
6
Primary
Data Data
1 4 4 2
Managed Network
Traps Traps
6
SAM Server
db
4
Legend Read/ Writes to Primary Database Replication Monitor for availability
Standby Standby
Appendix 1 6
The sequence for each component to establish communications under normal conditions is as follows:
1. Upon initial boot up, the SAM Servers will negotiate between themselves to determine which will
become the Primary and which will become the Standby. Usually, the workstation that completes its boot sequence first will become the Primary server. The Standby server regularly pings the Primary to ensure its availability.
2. During installation, each of the SAM databases is configured to be the Primary or Standby database upon
initial start up. Therefore, the two will assume their respective role.
3. Once the Primary database is online, the Primary server will establish a communications session. 4. The Standby server regularly monitors the availability of the Primary and Standby databases so as to be
ensure connectivity in the case of a server activity switch.

5. Once the primary server is online, data reads and writes are processed by the Primary server and
directed to the Primary database.

6. Traps are sent to both servers but are directed only to the Primary database. 7. During the installation process, the SAM clients (GUI and OSS) are configured to recognize the redundant
servers and will be directed to the Primary server.
Database Replication
database write sent to primary database from active server
db Engine 1
directed to primary redo log and to remote via real-time apply full redo log, sent to database tablespace and archive log
Server
redo log 1Gb? 2
real-time apply
redo log 1Gb?
3 db tablespace db tablespace
archive log
archive log
Appendix 1 7
5620 SAM database redundancy is based on Oracle Data Guard Replication, which keeps the standby database synchronized with data changes that take place on the primary database. When an event is to be written to the SAM database, the Server Business Logic directs the message to the database engine. The database engine sends the write message to the redo log of the primary SAM database. This log is a flat text file and is an adjunct of the database tablespace. At the same time, the real-time apply function, a feature of Oracles Data Guard Replication, sends the message to the redo log on the standby database. Once 1 GByte of information has been written to the redo log, the contents of that file are written to the database tablespace, the log file is written to the archive log and a new redo log file is automatically opened. Archive log files are stored until a database backup is performed at which time they are removed. This process also occurs on the standby database and is independent of the primary database.
Server Activity Switch

Before Activity Switch Primary Standby After Activity Switch Primary Standby Primary Standby
db Primary
Legend
db Standby
db Primary
db Standby
No interruption to 5620 SAM GUI Clients

Read/ Writes to primary Database Replication Monitor for availability
OSS clients must be reactivated
Appendix 1 8
A 5620 SAM server activity switch can be performed to: Recover from subnet failures or errors Test redundancy in case of a catastrophic failure Prepare workstations for a software upgrade There are two types of activity switches for servers: Automatic Manual
Server Activity Switch [Cont.]

Automatic Activity Switch - occurs if the standby 5620 SAM server detects a communication failure. Switch to notes view!
The assumption is that the primary 5620 SAM server cannot manage the network. The standby 5620 SAM server attempts to take over management of the network by establishing a connection to the primary 5620 SAM database. A manual activity switch can be performed as required, for example, for planned server maintenance. A successful connection results in the standby 5620 SAM server taking over management of the network. If a communication failure is detected by the Primary 5620 SAM server, a message informs 5620 SAM client GUI operators that the standby server is no longer visible. An activity switch occurs automatically if the primary server is unreachable for more than one minute. During the activity switch, client GUIs show a message indicating that the server is not available, and that the servers are up or down, depending on the state of the activity switch. The server does not process SNMP traps from the network, and all regularly scheduled resynchronizations do not occur. For example, if a statistics polling interval occurs during an activity switch, statistics for that interval are not collected. After an activity switch: GUI clients communicate with the new primary server and are aware of the status of the switch. OSS clients must reconnect to the primary server, as described in the Alcatel-Lucent 5620 SAM-O OSS Interface Developer Guide. If a Appendix 1 9 request from a client was not completed by the primary server before the activity switch, deployment All Rights Reserved Alcatel-Lucent 2009 Appendix Redundancy the new primaryAware Manager)attempts to redeploy the requests. server R7.0 Operator 5620 SAM 5620 SAM (Service
Manual Activity Switch - can be performed by executing the nmsserver.bash file with the force restart
option on the primary server.
Database Switchover
Before Activity Switch Primary Standby After Switchover Primary Standby
db
Primary
db
Standby
db
Standby Primary
db
Primary Standby
Legend Read/ Writes to primary Database Replication Monitor for availability
Appendix 1 10
Database Failover
Before Failover Primary Standby After Failover Primary Standby
db
Primary
db
Standby
db
db
Primary
Legend Read/ Writes to primary Database Replication Monitor for availability

Appendix 1 11
A failover is the transition of a standby database to the primary database role; for example, if there is a catastrophic failure of the primary database. A failover occurs automatically if the primary server cannot communicate with the primary database. After a failover, the former primary database can be restored to the redundancy system as the new standby database. If the primary 5620 SAM server detects a communication failure to the standby 5620 SAM database, the client GUIs are notified that the standby 5620 SAM database is not reachable. After the problem that caused the communication failure is restored, client GUIs are notified that database redundancy is operational. If the primary 5620 SAM server detects a communication failure to the primary 5620 SAM database, client GUIs are informed that the primary 5620 SAM database is not reachable. A failover results in a minimal loss of data.
Database Failover [Cont.]

Configuration
Scenario
Minimum Length of Communications Failure 5 minutes
Collocated
Primary database crashes, or otherwise ceases to communicate with primary server Primary database workstation loses power Primary database workstation becomes unreachable
15 minutes
15 minutes
Distributed
Primary database crashes, or otherwise ceases to communicate with primary server Primary database workstation All Rights Reserved Alcatel-Lucent 2009 loses power Primary database workstation becomes unreachable
5 minutes
Appendix 1 12
5 minutes
5minutes
Re-instantiation
Before Standby Primary Standby After Primary
db
Primary
Legend
db
db Primary
db Standby
Administrator initiated from primary server

Read/ Writes to primary Database Replication Monitor for availability
Database copied from primary to standby db Redundancy reestablished

Appendix 1 13
Re-establishing Database Redundancy

After a failover, the former standby database becomes the primary database, and the former primary database is no longer part of the database redundancy system. To reestablish redundancy, a new standby is created out of the former primary database (referred to as reinstantiating the database). The network system administrator must perform a manual re-instantiation on the primary server. This action causes the server to perform a backup of the primary database and transfer this file to the secondary database when complete. The standby database is now online and database redundancy is restored. Notification is sent to the GUI.
After Re-instantiation
Re-instantiating the primary database as the new standby database depends on three conditions: The failover was successful The workstation on which the server or database failure occurred is restored to full operation The former primary proxy port is configured and running so that it can receive switchover and failover commands on the database workstation
Questions
?
Appendix 1 14
1. Which of the following statements is true? a. The operating system installed on the primary and standby SAM server and SAM database workstations must be the same version and at the same patch level. b. Both the primary and secondary server has visibility of the redundant databases. c. The two redundancy configurations supported are; distributed and collocated. d. Redundancy is supported on Solaris and Windows workstations. 2. The servers and databases are four separate entities regardless of the physical or geographical deployment. a. True b. False 3. Which of the following statements is false? a. SAM server activity switch can be initiated manually or automatically. b. SAM server activity switch can be performed to prepare workstations for a software upgrade. c. During an activity switch, the SAM server does not process SNMP traps from the network. d. After a server activity switch, the SAM GUI clients must be reactivated to be able to communicate with the new active server. 4. a. b. c. Which of the following statements is true? For a database switchover to occur, only the standby database need be functioning correctly. 5620 SAM GUI clients are never made aware when a database switchover is in progress. When the database switchover is successful, the primary server will not establish communications with the new primary database without manual intervention. d. If a database switchover is not successful, the dtabases revert to their original primary and standby status.
Questions [Cont.]
5. A database failover results in total loss of data. a. True
b. False 6. Communication between the primary and the standby database is automatically reestablished after a database switchover.
a. True b. False
Appendix 1 15
Answers
1. Which of the following statements is true? Switch to notes view! a. The operating system installed on the primary and standby SAM server and SAM database workstations must be the same version and at the same patch level. b. Both the primary and secondary server has visibility of the redundant databases. c. The two redundancy configurations supported are; distributed and collocated. d. Redundancy is supported on Solaris and Windows workstations. 2. The servers and databases are four separate entities regardless of the physical or geographical deployment. a. True b. False 3. Which of the following statements is false? a. SAM server activity switch can be initiated manually or automatically. b. SAM server activity switch can be performed to prepare workstations for a software upgrade. c. During an activity switch, the SAM server does not process SNMP traps from the network. d. After a server activity switch, the SAM GUI clients must be reactivated to be able to communicate with the new active server. 4. Which of the following statements is true? a. For a database switchover to occur, onlyAllthe Reserved Alcatel-Lucent 2009 need be functioning correctly. standby database Rights Appendix 1 16 Appendix Redundancy b. If aSAM 5620 SAM (Service Aware Manager) R7.0 Operator successful, the databases revert to their original primary and standby 5620 database switchover is not status. c. When the database switchover is successful, the primary server will not establish communications with the new primary database without manual intervention. d. 5620 SAM GUI clients are never made aware when a database switchover is in progress. 5. A database failover results in total loss of data. a. True b. False 6. Communication between the primary and the standby database is automatically reestablished after a database switchover. a. True b. False
End of Module Redundancy
Appendix 1 17
Last Blank Page

Appendix 1 18
App2
Appendix
TOS36013_A_02 Issue 1.0
Appendix 2 Hardware and Software Specifications
Blank Page

Appendix 2 2
Appendix Hardware and Software Specifications 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
Objectives
Upon successful completion of this module, the student will be able to:
List the hardware specifications for the 5620 SAM, and List the software specifications for the 5620 SAM
Appendix 2 3
Appendix Hardware and Software Specifications 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Operating Systems
Sun Solaris 9 09/04 (and higher) Solaris 10 01/06
Server
OR
db
Windows OS
OR Linux Red Hat
Client
Appendix 2 4
(GUI Client only)
Operating Systems
Alcatel-Lucent 5620 SAM Release 6.0 is supported on the following operating systems: Windows, and Solaris (SPARC and x86 64-bit Solaris on Sun platforms) for the SAM Server, SAM Auxiliary, SAM Database and SAM Client. The 5620 SAM Client is supported on the Linux Red Hat Enterprise WS 3.0.
Operating Systems [Cont.]

Solaris (SPARC Solaris on Sun Platforms)

Alcatel-Lucent 5620 SAM Release 6.0 is supported on the Solaris 9 09/04 release (and higher) and the Solaris 10 01/06 (and higher) for the 5620 SAM Server,5620 SAM Auxiliary, 5620 SAM Database and 5620 SAM Client. Refer to the Alcatel-Lucent 5620 SAM Release 6.0 Release Notice documents for up-to-date information about the recommended Solaris maintenance update and patch levels. The Solaris support of the Alcatel 5620 SAM Release 6.0 is only applicable to AMD and SPARC 64-bit platforms provided by Sun Microsystems only. The redundancy feature of 5620 SAM is supported when the 5620 SAM Server, 5620 SAM Auxiliary and 5620 SAM Database software is installed on Solaris Sun platforms. In this situation, the 5620 SAM Client software can be installed on Solaris, Windows or Linux Red Hat platforms. The Solaris operating system must be installed in 64-bit mode on workstations that will contain the 5620 SAM Server, 5620 SAM Auxiliary, 5620 SAM Database or 5620 SAM Client software. 32-bit mode is not supported. 5620 SAM can be installed in a collocated configuration, where the 5620 SAM Server and the 5620 SAM Database are installed on the same SUN workstation.
Appendix 2 5
Microsoft Windows
The Windows support of the 5620 SAM Server and 5620 SAM Database is only applicable to small network deployments. The 5620 SAM Server and 5620 SAM Database platforms are supported on the Microsoft Windows operating systems provided that the network being managed does not exceed either of the following dimensions: 50 MDAs and three clients, or 30 MDAs and five clients Note: a client is either a SAM Client (GUI) or a SAM-O OSS client. 5620 SAM Release 5.0 is supported on the following versions of Microsoft
Windows: Windows 2000 (for SAM Server, SAM Database and SAM Client) Windows Server 2003 (for SAM Server, SAM Database and SAM Client) Windows XP Professional Edition (for SAM Server, SAM Database and SAM Client) Neither the redundancy feature of the 5620 SAM, nor the collocation of the SAM server and database are supported when running on the Microsoft Windows platform. The 5620 SAM Auxiliary is not supported on the Windows operating system.
Linux Red Hat

The 5620 SAM Client is supported on Linux Red Hat Enterprise WS 3.0. The 5260 SAM Server, 5620 SAM Auxiliary and 5620 SAM Database platforms, including redundancy, are not supported on the Linux operating system.
Software Specifications - Summary

5620 SAM Application Sun SPARC or x86 64-bit Solaris 9 09/04 Solaris 10 01/06 Supported up to 5620 SAM Release 6.0 scalability limits Microsoft Windows Red Hat Enterprise Linux Not Supported Not Supported
5620 SAM Server 5620 SAM Database
Supported when network does not exceed either of the following criteria: 50 MDAs and 3 clients 30 MDAs and 5 clients where one client is either a 5620 SAM GUI client or a 5620 SAM-O OSS client. Not supported
Collocated 5620 SAM Server/ Database 5620 SAM Client 5620 SAM Redundancy 5620 SAM Client Delegate 5620 SAM Auxiliary Server Supported Supported Supported Supported
Not Supported
Supported Not supported Not Supported Not Supported
Supported Not supported Not supported Not Supported
Appendix 2 6
Hardware Specifications SUN AMD
COLLOCATED CONFIGURATION MINIMUM SPECIFICATION (SUN AMD) SUPPORTS 675 MDAs, 1000 GNEs AND 5 SIMULTANEOUS CLIENTS WHERE A CLIENT IS EITHER A GUI OR AN OSS 1000 elemental STM tests every 10 minutes 10,000 performance OR 100,000 accounting statistics records every 15 minutes 5620 SAM Application 5620 SAM Server/ Database (Collocated) Configuration 2 * AMD Dual Core 8 Gbytes RAM 4 disk drives of size 146 Gytes is recommended for performance and storage capacity (minimum required: 2 disk drives of size 73 Gbytes) Example Sun Fire x4200 Server
Appendix 2 7
For new installations, Alcatel-Lucent strongly recommends the use Sun AMD Workstations. Their performance exceeds similar sized SPARC workstations and has a more attractive price point.
Hardware Specifications SUN AMD [Cont.]

DISTRIBUTED CONFIGURATION MINIMUM SPECIFICATION (SUN AMD) SUPPORTS 1875 MDAs AND 5 SIMULTANEOUS CLIENTS WHERE A CLIENT IS EITHER A GUI OR AN OSS OR SUPPORTS 1275 MDAs and 25 SIMULTANEOUS CLIENTS WHERE A CLIENT IS EITHER A GUI OR AN OSS SUPPORTS MAXIMUM Number of GNEs (5,000) 2000 elemental STM tests every 10 minutes (both cases) 150,000 performance OR 200,000 accounting statistics records every 15 minutes (both cases) 5620 SAM Application 5620 SAM Server Configuration 2 * AMD Dual Core 8 Gbytes RAM 2 disk drives that are at least 73 Gbytes each in size Example Sun Fire x4200 Server
5620 SAM Database
2 * AMD Dual Core 8 Gbytes RAM 2 disk drives that are at least 4 disk drives of size 146 GB is recommended for performance and storage capacity (minimum required: 2 disk drives of size 73 GB)
Sun Fire x4200 Server
Appendix 2 8
Hardware Specifications Solaris (Collocated)
COLLOCATED CONFIGURATION MINIMUM PLATFORM SPECIFICATION (SPARC SOLARIS) SUPPORTS 75 MDAs, 200 GNEs AND 5 SIMULTANEOUS CLIENTS WHERE A CLIENT IS EITHER A GUI OR AN OSS 50 elemental STM tests every 10 minutes 10,000 performance OR 50,000 accounting statistics records every 15 minutes 5620 SAM Application 5620 SAM Server and Database (Collocated) Ultra Sparc IIIi/III/IV/IV+ Architecture
2 * CPU @ 1 GHz or faster 8 GB RAM Recommended for performance (4 GB minimum for lab trials only) 4 disk drives of at least 73 Gbytes in size is recommended for performance and storage capacity (minimum required: 2 disk drives of size 73 Gytes) Example Platform: Sun Fire v240/v245 Server/Sun Netra 240
Appendix 2 9
The table above lists the minimum hardware platform requirements for deployments of the 5620 SAM Release 6.0 product on the SPARC and x86 Solaris operating system. Alcatel-Lucent continues to support deployments of 5620 SAM Release 6.0 on SPARC Solaris platforms from Sun which are based on the UltraSPARC III, UltraSPARC IIIi, UltraSPARC IV, UltraSPARC IV+, and SPARC T1. The Sun Fire T2000 platform only supports Solaris 10. The minimum collocated platforms will deliver acceptable performance in situations in small network which are expected to be relatively static. If the rate of changes in the network or if the rate of transactions through the OSS application(s) are expected to exceed a few changes per second, the collocated minimum platform specified below will not be sufficient to deliver adequate performance. In that case, the distributed minimum platform is recommended.
Hardware Specifications Solaris (Distributed)

DISTRIBUTED CONFIGURATION MINIMUM PLATFORM SPECIFICATION (SPARC SOLARIS) SUPPORTS 300 MDAs AND 15 SIMULTANEOUS CLIENTS WHERE A CLIENT IS EITHER A GUI OR AN OSS SUPPORTS MAXIMUM NUMBER OF GNEs (1000) 2000 elemental STM tests every 10 minutes 150,000 performance OR 100,000 accounting statistics records every 15 minutes 5620 SAM Application 5620 SAM Server Ultra Sparc IIIi/III/IV/IV+ Architecture
2 * CPU @ 1 GHz or faster 4 Gbytes RAM 2 disk drives that are at least 73 Gbytes each Example Platform: Sun Fire v240/v245 Server/Sun Netra 240 2 * CPU @ 1 GHz or faster 4 Gbytes RAM 4 disk drives of at least 73 GB in size is recommended for performance and storage capacity (minimum required: 2 disk drives of size 73 Gytes) Example Platform: Sun Fire v240/v245 Server/Sun Netra 240
5620 SAM Database
Appendix 2 10
The table above lists the minimum hardware platform requirements for deployments of the 5260 SAM 5.0 product on the Sparc Solaris operating system where the 5620 SAM Server and 5620 SAM Database are distributed. Alcatel support deployments of 5620 SAM 5.0 on the new SunFire T2000 platform from Sun. This platform supports Solaris 10 only. Alcatel-Lucent continues to support deployments of 5620 SAM 5.0 on Sparc Solaris platforms from Sun which are based on the UltraSparc III, UltraSparc IIIi, UltraSparc IV and UltraSparc IV+. As such, the minimum hardware platform is specified for both types of platforms. The minimum hardware specifications listed above are also applicable in situations where the 5620 SAM server and database are installed in a redundant configuration.
Hardware Specifications Client Delegate
CLIENT DELEGATE MINIMUM SPECIFICATION (SPARC SOLARIS) Number of Simultaneous GUI clients on Platform 5 10 Number of CPUs required 1 2 Amount of RAM required 2 Gbytes 4 Gbytes Example Platform Sun Ultra 45 Workstation Sun Fire v240/v245 Server/Sun Netra 240 or Sun Fire x4100 Server Sun Fire v440/v445 Server /Sun Netra 440 or Sun Fire x4100 Server
20
8 Gbytes
Appendix 2 11
5620 SAM Release 6.0 allows multiple GUI clients to be installed on a single SUN SPARC or AMD workstation running Solaris. This option enables customers to launch multiple 5620 SAM GUI Clients from a single Solaris workstation. These GUI clients can be displayed using the X11 protocol to other Solaris desktops or native X displays. The Client Delegate platform provides an option to consolidate multiple installations of the 5620 SAM GUI Client on a single Solaris workstation. It does not currently provide the ability to have multiple SAM users share a single installation of the 5620 SAM GUI Client software. In fact, in order to preserve debug information for each individual 5620 SAM user, one installation of the 5620 SAM Client software is required for every SAM user. Please note that on computers running Windows, only one instance of a 5620 SAM GUI Client can be running at any given time. The table above describes platforms requirements for this type of workstation. For situations where more than 20 simultaneous GUI sessions are required, Alcatel-Lucent recommends deploying multiple 5620 SAM Client Delegate workstations. Displaying GUI clients to computers running X-emulation software is not currently supported. In cases where the GUI client is to be displayed to a PC computer running Windows, Alcatel-Lucent supports installing the GUI client directly on the PC. Please note the 5620 SAM Client Delegate configuration is only supported for Sun SPARC or AMD workstations running Solaris.
Hardware Specifications Auxiliary
AUXILIARY SERVER MINIMUM SPECIFICATIONS Architecture SUN SPARC Configuration 2 * CPU @ 1 GHz or faster 8 Gb RAM 4 disk drives that are at least 73 Gbytes each in size 2* AMD Dual Core 8 Gbytes RAM 4 disk drives that are at least 73 Gbytes each in size Example Sun Fire v440/v445 Server/Sun Netra 440
SUN AMD
Sun Fire x4200 Server
Appendix 2 12
Hardware Specifications - Windows

FOR NETWORKS NOT EXCEEDING: 50 MDAs, 50 GNEs AND 3 SIMULTANEOUS CLIENTS OR 30 MDAs, 50 GNEs AND 5 SIMULTANEOUS CLIENTS, WHERE A CLIENT IS EITHER A GUI OR OSS 50 elemental STM tests every 10 minutes (both cases) 1,000 performance OR 1,000 accounting statistics records every 15 minutes (both cases) 5620 SAM Application Hardware Platform Requirements
5620 SAM Server and Database (Collocated) 5620 SAM Server
Not Supported
1 CPU @ 2 GHz or higher 2 Gbytes RAM 15 Gbytes available disk space
5620 SAM Database
1 CPU @ 2 GHz or higher 2 Gbytes RAM 50 Gbytes available disk space
Appendix 2 13
The table above lists the minimum hardware platform requirements for deployments of the 5260 SAM 6.0 product on the Windows operating system where the 5620 SAM Server and 5620 SAM Database are distributed. Only 32-bit Windows platforms are supported at this time.
Hardware Specifications GUI Client
5620 SAM GUI CLIENT Sun Sparc and AMD Platforms 1 CPU @ 1 GHz or higher (UltraSPARC III or IIIi) 512 Mb dedicated RAM 1 Gb available disk space 1280 * 1024 Display resolution Example Platform: Sun Ultra 45 Workstation Microsoft Windows 1 CPU @ 2 GHz or higher 512 Mb dedicated RAM 1 Gbyte available disk space 1280 * 1024 Display resolution Red Hat Linux 1 CPU @ 1 GHz or higher 512 Mb dedicated RAM 1 Gbyte available disk space 1280 * 1024 Display resolution
Appendix 2 14
The table above lists the minumum requirements for hardwar ethat will host 5620 SAM GUI Client software.
Hardware Specifications Larger Networks
Expected number of MDAs to be managed Maximum number of simultaneous SAM GUI clients Server
Expected number of SAM-O OSS clients Expected number of subscribers, specifically for triple-play networks Whether SAM redundancy is to be utilized
db
Send to Alcatel-Lucent representative who can provide appropriate recommendations

Appendix 2 15
Hardware Platform Requirements for Larger Networks

5620 SAM Release 6.0 may require larger computer workstations in order to successfully manage networks that exceed any of the dimensions supported by the minimum hardware platforms. In order to determine which computer resources are required to successfully manage a larger networks, the following information is required: Expected number and types of Network Elements to be managed Expected number of MDAs in the network to be managed Expected services and SAPs in the network to be managed. Maximum expected number of 5620 SAM Clients (GUI) simultaneously monitoring the network Expected number of OSS applications that will connect as clients to the 5620 SAM-O interface Expected number of subscribers, specifically for triple-play network deployments Expected performance and accounting statistics collection Whether 5620 SAM redundancy is to be utilized For networks which contain, or are expected to contain, 7250 SAS or Telco T5C CLE equipment, the number of managed MDAs can be obtained by adding 2 MDAs for each 7250 or Telco T5C elements in the network to the current or expected number of MDAs on 7750 SR routers and 7450 ESS switches. The information above must then be sent to an Alcatel-Lucent representative who can provide the required hardware specifications. Ensure that any projected growth in the network is taken to account when specifying the expected network dimensioning attributes. For existing 5620 SAM systems, the user may determine the number of MDAs deployed in the network using the help button on the 5620 SAM GUI. It is also possible to determine the number of statistics being handled by the system by looking at the 5620 SAM GUIs Statistics Collection information window. Select the Tools, then Statistics, then Server Performance Menu. List the Statistics Collection objects. From this list window, check the Scheduled Polling Stats Processed Periodic and the Accounting Stats Processed Periodic columns for the performance and accounting stats that your system is currently processing within the time interval defined by the collection policy (15 minutes by default).
Distributed SAM Server/ Database

Switch to lists the minimum and recommended bandwidth requirements for the The table oppositenotes view! connections between the components of a 5620 SAM Collocated installation. Alcatel recommends that sufficient bandwidth be made available to the 5620 SAM workstations within the Data Communication Network. The table does not specify the underlying infrastructure required to support these bandwidth requirements.
The minimum bandwidth requirements are suitable for small networks or networks where the rate of changes is expected to be low. Large networks and networks with high rates of changes should use the recommended bandwidth values. For existing networks which are deployed with the minimum bandwidth recommendations, the bandwidth utilization between the various components should be measured and plans should be developed to eventually increase the amount of available bandwidth between the 5620 SAM components.
SAM GUI
The bandwidth specifications provided for 5620 SAM GUI Clients are based on the fact that information about changes in the network is forwarded to the 5620 SAM GUI Clients. The 5620 SAM Client updates information visible to the user based on recent changes in the network. A few examples of network changes which will be reported to 5620 SAM include status changes of physical equipment, status changes of Layer 2 or Layer 3 interfaces, configuration of network elements, provisioning of new equipment or services, status changes in services or any attributes thereof, configuration changes of routing protocols and several others.
Appendix 2 16
In an environment where network changes are infrequent, it is possible to successfully operate the 5620 SAM Client when the available bandwidth between the 5620 SAM Client and the 5620 SAM Server is less than the quantity specified in the tables, possibly as little as 128 Kbps. However, in situations where the frequency of network changes increases, the performance of the 5620 SAM Client will degrade.
SAM GUI on X Displays

5620 SAM GUI Clients can be displayed remotely on terminals using the X11 protocol for graphical displays. In these cases, it is important to ensure the bandwidth availability between the workstation running the 5620 SAM Client and the host displaying the 5620 SAM Client be at least 512 Kbps. Also, it is important to ensure the network latency between these two hosts is quite low (20-30ms). Situations where the available bandwidth is lower or the network latency is higher will result in poor usability of the 5620 SAM GUI Client.
Bandwidth Requirements
Distributed Server and Database
Available Bandwidth Requirements From a 5620 SAM Server to a 5620 SAM database Minimum Bandwidth 3 Mbps Recommended Bandwidth 5-10 Mbps
5620 SAM Server to 5620 SAM Auxiliary
1 Mbps
1 Mbps
From a 5620 SAM Server to a 5620 SAM Client
512 Kbps
512 Kbps
Between a primary and a standby 5620 SAM Server
1 Mbps
1 Mbps
Between a primary and a secondary 5620 SAM Database
3 Mbps
6 Mbps
From a 5620 SAM Server to a 5620 SAM-O Client
1 Mbps
1 Mbps
Appendix 2 17
Bandwidth Requirements SAM-O OSS Clients

There are two main factors affecting the bandwidth requirements between the 5620 SAM Server and a 5620 SAM-O OSS Client: Design and behavior of the application using the 5620 SAM-O OSS Rate of changes in the network Applications which listen to network changes via the JMS interface provided by 5620 SAM-O or applications which retrieve large pieces of information via 5620 SAM-O, such as statistics information or network inventory information, will require access to dedicated bandwidth from the machine hosting the application to the 5620 SAM Server according to the tables above. Applications which do not perform the functions listed above may operate with acceptable performance when the bandwidth between the machine hosting the application and the 5620 SAM Server is less than the quantity specified in the tables above. In an environment where network changes are infrequent, it is possible to successfully operate an application using the 5620 SAM-O when the bandwidth between the machine hosting this application and the 5620 SAM Server is less than the quantity specified in the tables above, possibly as little as 128 kbps. However, in situations where the frequency of network changes increases, the performance or responsiveness of the application will degrade.
Bandwidth Requirements [Cont.]

Collocated Server and Database
Available Bandwidth Required from Primary 5620 SAM Server/database Workstation From a 5620 SAM Server to a 5620 SAM Client Recommended Bandwidth Excluding statistics bandwidth requirements 512 Kbps
Between a primary and a secondary 5620 SAM Database/ Server From a 5620 SAM Server to a 5620 SAM-O Client (The bandwidth will depend on the OSS application.)
5-10 Mbps
1 Mbps
Appendix 2 18
Bandwidth Requirements Collocated SAM Server/ Database

The table above lists the minimum and recommended bandwidth requirements for the connections between the components of a 5620 SAM Collocated installation. The minimum bandwidth requirements are suitable for small networks or networks where the rate of changes is expected to be low. Large networks and networks with high rates of changes should use the recommended bandwidth values. For existing networks which are deployed with the minimum bandwidth recommendations, the bandwidth utilization between the various components should be measured and plans should be developed to eventually increase the amount of available bandwidth between the 5620 SAM components.
Bandwidth Requirements
SAM Server/ Network Elements
Number of MDAs/CMAs Network Element Example Bandwidth Requirement from 5620 SAM Server(s) to the Network Element 200 Kbps
7450 ESS-1/Telco T5C/7250
N/A
OmniSwitch 6850
600 Kbps
10 20 12
7450 ESS-7 (fully loaded) 7750 SR-12 (fully loaded) 7710 C-12 (fully loaded)
1 Mbps 2 Mbps 600 Kbps
Appendix 2 19
5620 SAM Bandwidth Requirements for Communicating with Network Elements

In order to effectively manage the network, 5620 SAM must have access to sufficient bandwidth between the 5620 SAM Server(s), 5620 SAM Auxiliary(s) and the network elements. This bandwidth will be used to carry the management traffic between 5620 SAM and the network element. The following table describes the bandwidth requirements for a particular network element. The recommended bandwidth described above is a conservative figure that is meant to ensure that the performance of 5620 SAM and its ability to manage successfully each network element will not be affected by unusual network conditions. Specifically, the bandwidth recommendation ensures that 5620 SAM can fully discover (or resynchronize) all of the objects contained in the network element, within a reasonable amount of time, usually no more than a few minutes for a densely populated network element.
Bandwidth Requirements [Cont.]

The following are the main operations that result in significant amounts of information being exchanged between 5620 SAM and the network elements. These factors are therefore the principal Switch to notes view! contributors to the bandwidth requirements. Network Element Discovery: Upon first discovery of the network element, a significant amount of data is exchanged between 5620 SAM and the network element. SNMP traps: SNMP traps do not result directly in significant data being sent from the network element to the 5620 SAM. Several of the SNMP traps however do not contain all of the information required for 5620 SAM to completely represent the new status of the network element. As a result, 5620 SAM will subsequently perform a poll of a certain number of the SNMP MIBs to obtain the required information from the network element. Consequently, SNMP traps do result in a certain quantity of data and therefore cause bandwidth utilization. The exact quantity of bandwidth utilized will vary based on the number and the type of trap that is sent from the network element. In the worst case however, this bandwidth utilization will be less than that utilized during a network element discovery. SNMP polling: It is possible to configure 5620 SAM to poll the SNMP MIBs on the network elements at various intervals. By default, 5620 SAM 5.0 will perform a complete poll of the SNMP MIBs every 24 hours for 7750 SR, 7450 ESS and 7710 SR 3.0 and above network elements. During the polling cycle, the amount of data transferred between 5620 SAM and the network element is equivalent to the amount of data transferred during the network element discovery. Statistics collection: It is possible to configure 5620 SAM to poll the SNMP MIBs on the network elements that contain performance statistics information. By default, 5620 SAM 5.0 will perform a poll of these SNMP MIBs every 15 minutes for 7750 SR, 7450 ESS and 7710 3.0 and above network elements. During the polling cycle, the amount of data transferred between 5620 SAM and the network element is less than the amount of data transferred during the network element discovery.
Appendix 2 20
All Rights Reserved Alcatel-Lucent 2009 Appendix Hardware and Software Specifications 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Network element backup: It is possible to configure 5620 SAM to request a backup of the network element at specified interval. During the polling cycle, the amount of data transferred between 5620 SAM and the network element is less than half of the amount of data transferred during the network element discovery. Provisioning of services and deployment of configuration changes: When network elements are configured or when services are provisioned via the 5620 SAM GUI or via application using the 5620 SAM-O interface, a small quantity of network bandwidth is utilized. The amount of data transferred is significantly less than during the network element discovery. Initiation and collection of STM tests and their results: When STM tests are initiated, the 5620 SAM Server sends individual requests per elemental test to the network elements. Once the test
is complete, the network elements report back using a trap. The 5620 SAM server then requests the information from the network element, and stores it in the database. This can result in a significant increase in network traffic to the network elements. Possible Consequences of Insufficient Bandwidth In situations where there is less than the recommended bandwidth between the 5620 SAM and the network element, the following are possible consequences: The length of time required to perform a network element discovery will increase The length of time required to perform a SNMP poll of the network element will increase The length of time required to retrieve statistics from the network element will increase The proportion of SNMP traps that will not reach 5620 SAM because of congestion will increase. This is significant since 5620 SAM will detect it has missed traps from the network element and will result in 5620 SAM performing additional SNMP polling to retrieve the missing information. This will result in additional data being transferred, which will increase the bandwidth requirements, possibly exacerbating the situation.
Questions
1. The 5620 SAM software can be installed on which of the following operating systems? a. Sun Solaris 9 or 10 b. Windows 2000, 2003 and XP Professional Edition c. Red Hat Linux d. All of the above
2. 5620 SAM redundancy is supported on any operating system environment. a. True b. False
3. A client wishes to manage a network with 200 MDAs with 5 simultaneous GUIs. They have a
2*AMD dual core platform operating at 2 Ghz, 8 Gbytes of RAM and four 175 Gbyte hard drives. The hardware platforms are sufficient for the 5620 SAM to function adequately in a distributed configuration.
a. True b. False
Appendix 2 21
4. Deploying the 5620 SAM with a collocated server and database on a Windows operating system to manage a large network is acceptable and supported by Alcatel-Lucent.
a. True b. False
Answers
1. The 5620 SAM software can be installed on which of the following operating systems?
a. Sun Solaris 9 or 10 b. Windows 2000, 2003 and XP Professional Edition c. Red Hat Linux d. All of the above 2. 5620 SAM redundancy is supported on any operating system environment. a. True b. False 3. A client wishes to manage a network with 200 MDAs with 5 simultaneous GUIs. They have a
2*AMD dual core platformoperating at 2 Ghz, 8 Gbytes of RAM and four 175 Gbyte hard drives. The hardware platforms are sufficient for the 5620 SAM to function adequately in a distributed configuration.
a. True
Appendix 2 22
b. False
4. Deploying the 5620 SAM with a collocated server and database on a Windows operating system to manage a large network is acceptable and supported by Alcatel-Lucent.
a. True b. False
End of Module Hardware and Software Specifications
Appendix 2 23
Last Blank Page

Appendix 2 24
App3
Appendix
TOS36013_A_03 Issue 1.0
Appendix 3 Routing Protocol Overview
Blank Page

Appendix 3 2
Appendix Routing Protocol Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
Objectives
Upon successful completion of this module, the student will have a basic understanding of:
Basic router functionality IP Routing protocols (RIP, OSPF, IS-IS, & BGP) Routing policies Link aggregation groups (LAG) Equal cost multipath (ECMP)
Appendix 3 3
Appendix Routing Protocol Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Routing Overview
Routing
What is a router? Routing versus switching Static and dynamic routing Routing design goals Interior and exterior gateway protocols
Appendix 3 4
Routing Fundamentals
Routing is the process of moving information across an internetwork from a source to a destination. Routers maintain routing tables that describe how to get to destinations in the network. Routers use a routing protocol to exchange routing information with other routers to update their routing tables. Routing tables contain information such as: Protocol type Destination/next hop associations Routing metrics Outbound interface
Routing versus Switching

Routers and switches both move information from source to destination, but they use different information to accomplish the task: Switching normally occurs at Layer 2 (data link layer) and routing occurs at Layer 3 (network layer) Switches act upon the MAC address and routers act upon the IP address Switches keep tables of MAC addresses and routers keep tables of IP networks
Static and Dynamic Routing

Static routesto notes view! routing table manually and do not change unless someone Switch are entered into a manually changes them. Dynamic routing builds routing tables using routing protocols and continuously updates the tables as the network topology changes.
Routing Design Goals

Routing algorithms have some of the following goals: Optimal Route Selection Simplicity Robustness and stability Rapid convergence Flexibility Delay Load Reliability Path Length Cost some paths may cost more to use than others. Operators may prefer to use links that they own because of lower costs.
Dynamic Routing Protocols

Appendix 3 5
Interior Gateway Protocol (IGP)

Used for exchanging routing information within an autonomous system (AS). Uses routing metrics such as hop count Commonly used: OSPF, RIP, IS-IS, iBGP
Exterior Gateway Protocol (EGP)

Used for routing between autonomous systems Routing protocols may be different between ASs Chosen path may not be optimal since it cant compare routing metrics from multiple ASs Commonly used: BGP-4 Note: An autonomous system (AS) is a network under a single administrative authority.
RIP v1
Features:
Classful protocol Distance Vector (Bellman-Ford) routing algorithm using hop count as the metric Hop count limited to 15, anything further is considered unreachable Uses broadcast for updates Very simple and stable
Routing update timer (30 seconds) Route timeout timer Route flush timer
Convergence is very slow, in the order of minutes Not suitable for large networks
Appendix 3 6
RIP v1
Routing Information Protocol (RIP) was originally distributed as part of the UNIX operating system and was not intended to be an Internet standard. RIP uses a distance vector algorithm. The algorithm associates a distance (number of hops) with a specific vector (destination network or host). The best route to a destination is stored in a local routing table. Each router issues updates every 30 seconds that advertise all the paths that it has discovered so that all other devices on the network will eventually learn the best routes to all destinations. If a router stops issuing updates for 180 seconds the other routers on the network assume that it is dead and stop issuing routes that go through it. RIP has a 15 hop limit which means that any device that is advertised with a distance of 16 hops is considered unreachable. This makes RIP suitable for small to midsize networks due to scalability issues.
RIP v2
Features:
RIP v1 with the following additional features:
Support for classless routing Support for route aggregation Rudimentary authentication Multicast option in addition to broadcast for route updates Triggered updates
Same scalability limitations as RIP v1
Appendix 3 7
RIP v2
RIP v2 has all of the features and limitations of RIP v1. Both v1 and v2 can coexist on the same network. RIP v2 does offer some enhancements such as: The subnet mask information is included with the destination address. Multicasting can be used to reduce the load on systems that do not want RIPv2 updates. Simple authentication to prevent accidental updates from misconfigured hosts.
RIP on the 7750 SR

Features
Support for both RIP v1 and v2. Able to specify what RIP version will be sent to RIP neighbors and what version of RIP updates will accepted and processed Supports plain text or Message Digest (MD5) authentication Metrics - support for split horizon and poison reverse to protect against counting to infinity problems Routing policies Hierarchical configuration Global, Group, and Neighbor
Appendix 3 8
Metrics
In addition to standard RIP metrics Alcatel-Lucent products support the use of split horizon with poison reverse techniques to protect against counting to infinity problems. Split horizon prevents a router from advertising routes on the link from which those routes were obtained. Poison reverse makes a router advertise routes with an infinite distance on the link from which the routes were obtained. Split horizon with poison reverse means that routes learned from a neighbor through a given interface are advertised in updates out of the same interface but with a metric of 16 (infinity).
Routing Policies
You can configure import policies to determine which routes are accepted from RIP neighbours and export policies to determine which routes are exported to RIP.
OSPF Features
Main features:
Interior gateway protocol Open standards protocol Link state protocol this uses the Shortest Path First (SPF) or Dijkstra algorithm Hierarchical - divides network into areas; always need a backbone area 0 Supports route aggregation Rapid convergence due to flooding Supports designated router (DR) to minimize broadcasts on multiple access networks Supports authentication As of R4.0, OSPFv3 for IPv6 is supported
Appendix 3 9
OSPF
Open Shortest Path First (OSPF) is a public-domain Interior Gateway Protocol (IGP) that uses a linkstate routing algorithm. As is the case with all link-state protocols, OSPF's major advantages over distance vector protocols are fast re-convergence, support for much larger networks, and less susceptibility to bad routing information.
Neighbors and Adjacencies

Before Link State Advertisements (LSA) can be sent, OSPF must establish neighbours and adjacencies. Because OSPF routing is dependent on the status of the link between two routers, neighbour routers must recognize each other before they can share information. This is done using the "Hello" protocol. The "Hello" protocol is responsible for establishing and maintaining bidirectional communications between neighbours. Hello packets are sent periodically from each interface that is OSPF enabled. Information on attached interfaces, metrics used, and other variables are included in OSPF LSAs. As OSPF routers accumulate link-state information, they use the Shortest Path First (SPF) algorithm to calculate the shortest path to each node. When the link-state databases of two neighboring routers are synchronized, the routers are said to be adjacent. On multi-access networks, the designated router determines which routers should become adjacent. Each router periodically sends an LSA to provide information on a routers adjacencies or to inform others when a routers state changes.
Switch to Router (DR) Designated notes view! and Backup Designated Router (BDR)
Routers on a segment (Ethernet or Token Ring) must elect a DR and BDR to represent the network. The concept behind the DR is that the network itself is considered a "node". Each router on the segment forms an adjacency with the DR and BDR, which represents the "node". The DR is responsible for sending LSA's to the rest of the inter-network. The BDR does not perform any of the DR's functions when the DR is active. Instead it will receive all of the information but allows the DR to perform the forwarding and synchronization tasks. The BDR will only take over on a DR failure.
OSPF Network Types

Broadcast
For the purposes of OSPF, a Broadcast interface is an interface that has native Layer 2 broadcast/multicast capabilities. The typical example of a broadcast network is an Ethernet network. Designated Router (DR) and Backup Designated Router (BDR) are selected on Broadcast networks.
Non-Broadcast Multi-Access (NBMA)

Appendix 3 10
The NBMA network type was created so All Rights Reserved Alcatel-Lucent 2009 that OSPF can correctly model multi-access networks such as ATM that have no native Layer 2 broadcast/multicast capabilities. Instead of multicasting its HELLOs, OSPF uses unicast to send them. Designated Router (DR) and Backup Designated Router (BDR) are selected on NBMA networks.
Point-to-Point
The point-to-point interface type is reserved for point-to-point links, i.e. links that can only have two routers attached to them. Typical examples of those are PPP or POS. On point-to-point and multi-point links, all routers form adjacencies with all other routers on the link in a mesh style. Designated Router (DR) and Backup Designated Router (BDR) are NOT selected on Point-to-Point networks.
Point-to-Multipoint
The Point-to-Multipoint interface type was originally created for networks that otherwise would have been NBMA, but cannot satisfy the full-mesh connectivity requirement of NBMA. Like pointto-point interfaces, Point-to-Multipoint links do not select a DR or BDR.
OSPF Areas
Standard Area
Standard Area
Backbone Area
Virtual Link
Stub Area NSSA
Appendix 3 11
OSPF Areas
Standard Area: This area can accept link updates, route summaries and external routes. Backbone Area: Also known as the Transit Area. When interconnecting multiple areas, the backbone area is the central entity that all other areas connect to. The backbone area is always area 0. All other areas must connect to this area in order to exchange information. Stub Area: An area that does not accept information about routes external to the AS such as nonOSPF sources. If routers need to route to networks outside the AS, they use a default route (0.0.0.0). Not-so-stubby Area (NSSA): A stub area with one less restriction, it has the added ability to support external connections. External routes learned by OSPF routers in the NSSA area are advertised as type-7 LSAs within the NSSA area and are translated by an Autonomous Border Router (ABR) into type-5 external route advertisements for distribution into other areas of the OSPF domain.
Virtual Link
The OSPF backbone area, area 0.0.0.0, must be contiguous and all other areas must be connected to the backbone area. The backbone distributes routing information between areas. If it is not practical to connect an area to the backbone, then the area border routers must be connected via a virtual link. The two area border routers form a point-to-point-like adjacency across the transit area.
Intermediate System to Intermediate System (IS-IS) Protocol

IS-IS is the International Standards Organization (ISO) Intra-domain routing protocol for Switch to notes view! Connectionless Network Protocol (CLNP). CLNP is the OSI worlds equivalent of IP.
Components
Area ID Since the IS-IS router resides entirely inside a single area, the area ID is associated with the router itself rather that an interface. System ID The IS-IS system ID perform the same function as the OSPF router ID. Combined, the Area ID and the System ID form a single addressing entity called the Network Entity Title (NET). NET The length of the NET can range from 8-20 octets and describes both Area and System ID. The System ID can itself range from 1-8 octets but the System ID of all routers within the same area must be the same length. Normally the System ID would be six octets, the MAC address, there by keeping each router NET unique. When selecting an address for an IP environment, there are two things to take into account: The NET must begin with a single octet (07.xxxx). The NET must end with a single octet, which in a pure IP environment should be zero (xxx.00).
Appendix 3 12
Level 1 and Level 2 Routers
Routers with no connectivity to other areas are referred to as Level 1 routers while routers that have links going to multiple areas are referred to as Level 1/Level 2 (L1/L2) routers. An IS router can be a L1 router, a L2 router, or a combination L1/L2 router. L2 routers are similar in concept to back bone routers with links in multiple areas. L1/L2 routers would be comparable to Area Border Routers in OSPF.
Neighbors and Adjacencies

IS-IS discovers neighbors and forms adjacencies by the exchange of "Hello" messages. These protocol data units are transmitted every 10 seconds to maintain the adjacency. The IS-IS router uses the "Hello" messages to identify itself and describe the parameters of the interface being used. If both ends agree then an adjacency is formed. IS-IS forms separate adjacencies dependent upon whether it is an L1 or L2 router. L1 goes to L1 and L2 goes to L2. Once the adjacencies are formed, the "Hello" messages are used as "Keep Alive" messages. Each router has a hold time. This is the length of interval that a router will wait without receiving a packet before declaring the link dead. This interval is a multiple of the "Hello" transmit rate, i.e. Hello sent every 10 sec, hold time is set to 3 therefore the actual hold time is 30 seconds.
IS-IS Areas
Appendix 3 13
Designated IS
IS-IS routers will elect an IS for the same reasons as OSPF routers elects a DR. Instead of having each router connected to a LAN advertise an adjacency with all of the other routers on the LAN, the network itself is considered a node. Each router, including the IS, will advertise a single link to the node. The DR, acting as a representative of the node, advertises a link to the attached routers. IS-IS does not elect a Backup IS. If the IS fails, the election process must begin again. Also, if a new router with a higher priority, or the same priority and a higher System ID, is added to the network, the election process will begin again.
IS-IS Addressing
IS-IS uses ISO network addresses. Each address identifies a point of connection to the network, Switch to notes view! such as a router interface, and is called a Network Service Access Point (NSAP). Each network entity has a special network address called a Network Entity Title (NET). Structurally, an NET is identical to an NSAP address but has an NSAP selector of 00. Most end systems have one NET. Intermediate systems can have up to three area IDs (area addresses). NSAP addresses are divided into three parts. Only the area ID portion is configurable. Area ID A variable length field between 1 and 13 bytes long. This includes the Authority and Format Identifier (AFI) as the most significant byte and the area ID. System ID A six-byte system identification. This value is not configurable. The system ID is derived from the system or router ID. Selector ID A one-byte selector identification that must contain zeros when configuring a NET. This value is not configurable. The selector ID is always 00. Note that the AFI filed describes format and length of the Initial Domain Identifier (IDI) (and therefore the format of the rest of the NSAP). There are some predefined AFI values as shown in the following examples:
Appendix 3 14
AFI =49 Addresses starting with value 49 are considered as local addresses (as network All Rights Reserved Alcatel-Lucent 2009 10.0.0.0/8 in IP). These addresses are routed by IS-IS routing protocol. However, they should not be advertised to other IS-IS networks. With AFI 49 the IDI value is null and IDP length is 2 digits.
ISO Network Addressing

NSAP Address Format
IDP AFI IDI High Order DSP
Variable Length Area Address
DSP System ID
6 bytes
NSEL
1 byte
ISO Network Addresses:

IS-IS uses ISO network addresses Network Entity Title (NET) is an NSAP address with the NSAP selector (NSEL) set to 0
Appendix 3 15
BGP-4 Features
Main Features:
Exterior gateway protocol (EGP) Policy-based protocol, can be based on:
Economic factors Security Political considerations
Path vector protocol As of R4.0, BGP4+ for IPv6 is supported
Note: whenever we refer to BGP in this course we assume BGP-4

Appendix 3 16
Border Gateway Protocol (BGP- 4)

BGP is an inter-domain, classless, path vector, routing protocol, also known as an Exterior Gateway Protocol (EGP). The primary function of BGP is to exchange network reachability information with other BGP systems. This network reachability information includes information on all of the Autonomous Systems (AS) that it passes through. BGP devices called speakers, exchange routing information upon initial data exchange and after incremental updates. BGP uses a single routing metric to determine the best path to a given network. There are two subtypes of BGP: Interior BGP (IBGP) - IBGP exchanges routing information with BGP Speakers within an AS Exterior BGP (EBGP) - EBGP exchanges routing information with other BGP Speakers among ASs
BGP-4
Company B Company A
IB
P G
AS500
IBGP
AS200
IBG
EBGP
P
IBGP
IBGP
P IBG
Appendix 3 17
Peers
BGP uses TCP for reliable, connection-oriented, exchange of routing information between routing devices. Any two routing devices that have set up a TCP connection to exchange BGP routing information are called BGP peers.
Routing Information Base

The Routing Information Base (RIB) within a BGP speaker consists of three distinct parts: Adj-RIBs-In: The Adj-RIBs-In store routing information that has been learned from inbound Update messages. Their contents represent routes that are available as an input to the decision process. Loc-RIB: The Loc-RIB contains the local routing information that the BGP speaker has selected by applying its local policies to the routing information contained in its Adj-RIBs-In. Adj-RIBs-Out: The Adj-RIBs-Out stores the information that the local BGP speaker has selected for advertisement to its peers. The routing information stored in the Adj-RIBs-Out will be carried in the local BGP speaker's Update messages and advertised to its peers.
Large Scale BGP Management

As Switch to attempting to create fully meshed IBGP peers can be an extremely difficult task. an AS grows, notes view! BGP provides four different tools that can simplify the management of these BGP peer groups. Peer Groups Communities Route Reflectors Confederations
Peer Groups
When dealing with large BGP networks, policies that are applied to one router can often be applied to multiple routers. In these cases configuration and management can be simplified by adding the routers that share common policies to a peer group. This way any policy changes are automatically applied to all of the routers belonging to the group.
Communities
In contrast to Peer Groups, where the policies are applied to routers, in BGP communities the policies are applied to routes. A router can add a route to a configured community by setting its COMMUNITY attribute to the value that identifies the particular community. Neighboring routers can then apply policies such as filtering or re-distribution to the route community.
Route Reflectors
Route Reflectors are extremely useful when an AS has a large number of IBGP peers. Unless the All Rights Reserved Alcatel-Lucent 2009 EBGP routes are re-distributed into the AS Interior Gateway Protocol (IGP) the IBGP peers must be Appendix Routing Protocol Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator fully meshed. This can become very cumbersome for every n routers, there will be n(n-1)/2 connections in the AS. For example an AS with 6 IBGP peers would require 15 IBGP connections.
Appendix 3 18
Route reflectors are an alternative to fully meshed IBGP peers. A single router is configured as a route reflector, while the remaining IBGP routers are configured as clients and peer only with the route reflector forming a Route Reflector Cluster. This reduces the number of connections required to the number of clients. The clients can peer with external routers but the only internal router that it can peer with is the route reflector. Routing updates received by a client are sent to the route reflector and it will forward to the other clients in the cluster. A single route reflector introduces a single point of failure within a network. Normally a network would be configured with multiple route reflectors. This does increase the number of IBGP connections but does give the security of redundancy. If one route reflector fails the clients still have a connection to the other route reflector.
BGP Route Reflectors

AS 3
AS 5 AS 6
IBGP EBGP IBGP Client Client EBGP
EBGP Route Reflector IBGP EBGP IBGP Client Client EBGP
AS 4
AS 7
Appendix 3 19
BGP Confederations
AS 6 BGP Confederation
EBGP
AS 5
AS 11113 IBGP
EBGP AS 11114
EBGP AS 11116
IBGP
IBGP
EBGP
EBGP
AS 7
AS 3
Appendix 3 20
BGP Confederations
Confederations are another method to manage large numbers of IBGP peers. A confederation is simply an AS that has been divided up into sub-autonomous systems called member autonomous systems. The BGP speakers within the confederation speak IBGP to peers in the same member autonomous system and use EBGP to communicate with peers in other member autonomous systems. The confederation is assigned a confederation ID number, which is presented to external peers as the AS number. External peers are unaware of the structure of the AS, they see only a single AS.
Blank Page

Appendix 3 21
Basic BGP Configuration

The following must be configured for basic BGP operation: Switch to notes view! Router autonomous system number Router ID BGP peer group BGP neighbor to peer with BGP peer AS associated with the above peer Three hierarchical levels are included in BGP configurations: Global level Group level Neighbor level Commands and parameters configured on the global level are inherited to the group and neighbor levels although parameters configured on the group and neighbor levels take precedence over global configurations.
Creating an Autonomous System

A router can belong to only one autonomous system. config router# autonomous-system 100
Appendix 3 22
Configuring a Router ID
If a new or different router ID value is entered in the BGP context, then the new
router ID value is used instead of the router ID configured on the router level, system interface level, or inherited from the MAC address. The router-level router ID value remains intact. config router# router-id 10.10.10.104 Note: it is not necessary to configure a router ID; the software will use the system IP address by default.
Routing Policies
Routing information is maintained in two databases: Switch to notes view! Routing Information Base (RIB) contains the routing information learned by the routing protocols running on the router. Forwarding Information Base (FIB) contains the routing information selected from the RIB that is actually used to forward traffic through the router. Interior gateway protocols such as OSPF and IS-IS also maintain link state databases. Routing policies control the size and content of the routing tables, the routes that are advertised, and the best route to take to reach a destination. Routing policies can be used when: You want to control a protocol to allow all routes to be imported into the routing table. This enables the routing table to learn about particular routes to enable packet forwarding and redistribution of packets into other routing protocols. You want to control the exporting of a protocols learned active routes. You want a routing protocol to announce active routes learned from another routing protocol, which is sometimes called route redistribution. You want unique behaviors to control route characteristics. For example, change the route preference, AS path, or community values to control the route selection. You want to control BGP route flapping (damping).
Policy Statements
Appendix 3 23
A policy-statement is a logical grouping All Rights Reserved and action criteria that controls the flow of of match Alcatel-Lucent 2009 routing information to and from a given protocol, set of protocols, or a particular BGP neighbor. Policy statement entries should be sequenced from the most explicit to least explicit. Packet forwarding and routing is carried out according to policies defined by the policy statements. Policy-based routing allows you to control: Where traffic can be routed Whether to forward or drop the traffic The policy implementation process stops when the first complete match is found and the action defined in the policy is executed. You can specify matching criteria based on source, destination, or particular properties of a route.
Routing Policies
Extensive scaling allowing over 64K policies with over 64K entries per policy Routing policies:
Control redistribution of routes between protocols Control BGP route flapping
Match criteria include:

Prefix lists Community lists (BGP) AS path matching (BGP) Regular expression matching (BGP)
Appendix 3 24
Default Route Policy Actions
Protocol
OSPF
Import
Not applicable. All OSPF routes are accepted from OSPF neighbors and cannot be controlled via route policies.
Export
Internal routes: All OSPF routes are automatically advertised to all neighbors. External routes: By default, all nonOSPF routes are learned. Internal routes: All IS-IS routes are automatically advertised to all neighbous. External routes: By default all non-IS-IS learned routes are not advertised to ISIS peers. External routes: By default all non-RIP learned routes are not advertised to RIP peers. Internal routes: By default all active BGP routes are advertised to BGP peers. External routes: By default all non-BGP learned routes are not advertised to BGP peers.
IS-IS
Not applicable. All IS-IS routes are accepted from IS-IS neighbors and cannot be controlled via route policies.
RIP
By default all RIP learned routes are accepted.
BGP
By default all routes from BGP peers are accepted and passed to the BGP route selection process.
Switch to notes view! Routing Protocol Characteristics

Protocol DV or LS DV IGP or EGP IGP Update Type Update Time Classful or Classless Classful Metric Hierarchical
RIP v1
Broadcast Table 30 seconds
Hop count max. 16
NO
RIP v2
DV
IGP
Multicast Table & 30 seconds Broadcast
Classless
Hop count max. 16
NO
OSPF
LS
IGP
Multicast
Change only
Classless
Cost based on BW
YES
Appendix 3 25
IS-IS
LS
IGP
All Rights MulticastReserved Alcatel-Lucent 2009 Classless SNP 10 5 seconds
Default metric
YES
BGP
DV
EGP
Unicast
Changes only
Classless
Based on policies
NO
Default Route Preferences
Route Type Direct Attached Static Route OSPF Internal Routes IS-IS Level 1 Internal IS-IS Level 2 Internal RIP OSPF External IS-IS Level 1 External IS-IS Level 2 External BGP
Preference 0 5 10 15 18 100 150 160 165 170

Configurable NO YES YES YES YES YES YES YES YES YES
Blank Page

Appendix 3 26
Questions
1. Routing is a layer 3 function and uses the MAC address to make routing decisions.
a. True b. False
2. Which of the following is not an advantage of RIPv2 over RIPv1?
a. Additional subnet mask information b. Authenticated updates c. Carries next-hop details
d. Updates are broadcast rather than multicast
3. The backbone area in OSPF is also known as area: a. 100 b. 0 c. 1 d. Main area
Appendix 3 27
?
4. Based on route preference, which route will a router prefer, an internal OSPF or RIP route?
a. RIP b. OSPF
Answers
1. Routing is a layer 3 function and uses the MAC address to make routing decisions.
a. True b. False
2. Which of the following is not an advantage of RIPv2 over RIPv1?
a. Additional subnet mask information b. Authenticated updates c. Carries next-hop details

d. Updates are broadcast rather than multicast
3. The backbone area in OSPF is also known as area: a. 100 b. 0 c. 1 d. Main area
Appendix 3 28
4. Based on route preference, which route will a router prefer, an internal OSPF or RIP route?
a. RIP b. OSPF
End of Module Routing Protocol Overview
Appendix 3 29
Last Blank Page

Appendix 3 30
App4
Appendix
Appendix 4 MPLS Overview
TOS36013_A_04 Issue 1.0 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator TOS36010 Issue 1.0
Blank Page

Appendix 4 2
Appendix MPLS Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
Objectives
Upon successful completion of this module, the student will understand:

Concepts of MPLS networks including terminology, signaling, FEC, LSP types, and MPLS labels LDP and RSVP-TE signaling, CSPF Backup paths and fast reroute Configuration of an MPLS network
Appendix 4 3
Appendix MPLS Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
MPLS Features
MPLS brings the following benefits to IP networks: Traffic Engineering - the ability to set the path that traffic will take through the network and the ability to set performance characteristics for a class of traffic. Layer 2 Transport - new standards allow service providers to carry Layer 2 services including Ethernet, Frame Relay and ATM over an IP/MPLS core.
Appendix 4 4
Multi-Protocol Label Switching (MPLS) encompasses a growing set of protocols defined by the IETF. MPLS combines the performance capabilities of Layer 2 (data link layer) switching with the scalability of Layer 3 (network layer) 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 that which is relevant to forwarding the packet. This information is then compared to the routing table to determine the packets next hop. In the most common case, the only relevant field in the header is the destination address field. However, the header analysis must be done independently at each router that the packet passes through. This means that a complicated lookup, on each packet header, must be done at each router. 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 signalled value.
MPLS Terminology
LSR LER
LSR LER LSR
LSR
LSP
Appendix 4 5
Label Edge Router (LER): An LER sits at the edge of an MPLS domain, either at the beginning (ingress) or end (egress) of a Label Switched Path. Label Switch Router (LSR): a device that typically resides somewhere in the middle of an MPLS network and is capable of forwarding datagrams based upon a label. An LSR will develop a Label Information Base (LIB) and switch packets according to the label value assigned to the packet. Label Switch Path (LSP): is a specific, unidirectional path set up across the MPLS network between two LERs. Label Switch Paths are established by network operators for a variety of purposes, such as to guarantee a certain level of performance, to route around network congestion, or to create IP tunnels for network-based virtual private networks. Label Information Base (LIB): As a packet arrives on an MPLS node, its label is compared to an onboard database called the label information base (LIB). The LIB contains a table that is used to add a label to a packet, or change/remove the existing label, while determining the outgoing interface to which the data will be sent. Every MPLS-enabled router will have its own LIB.
Multi-Protocol Label Switching
Label swapping networking technology that forwards packets over multiple, underlying layer 2 media. Integrates layer 2 switching and layer 3 routing by linking the layer 2 infrastructure with layer 3 routing characteristics. Layer 3 routing occurs only at the edge of the network, and layer 2 switching takes over in the MPLS core. LER LSR LSR LER
LSP
IP
IP
IP Forwarding
label
IP
label
IP
label
IP
LABEL SWITCHING
IP Forwarding
Appendix 4 6
Label Functions
The initial choice of label need not be based on the contents of the packet header: it can also be based on policy. This allows forwarding decisions at subsequent hops to be based on policy as well. Once a label is chosen, the label header is put at the front of the packet header, so that the label value can be carried across the network with the packet. At each subsequent hop, the Label Switch Router (LSR) simply looks up the label to make the forwarding decision. There is no need to reanalyse the complete header. Since the label is a fixed length, looking it up is fast and simple.
MPLS Label
Ethernet Ethernet PPP PPP
Shim Label(s) Shim Label(s)
MPLS Shim Headers (1-n) n Layer 2 Header (eg. PPP, 802.3)
1 Network Layer Header and Packet (eg. IP)
4 Octets
Label Stack Entry Format
Label
Label: Exp.: S: TTL:
Exp.
TTL
Packet-based encoding
Label Value, 20 bits (0-15 reserved) Experimental, 3 bits (Class of Service) Bottom of Stack, 1 bit (1 = last entry in label stack) Time to Live, 8 bits
Appendix 4 7
MPLS labels are the key forwarding mechanisms in an MPLS network. The labels used in an MPLS network can take two different forms: a. the shim, used in packet based networks like Ethernet and Packet over SONET native Layer 2 encoding, seen with link layer technologies like Asynchronous Transfer Mode and Frame Relay; b. The 32-bit shim label has four parts: i. a 20 bit label ii. 3 experimental bits (for QoS/Diffserv) iii. 8 bit time-to-live (TTL) field (to prevent loops) iv. an S bit (to enable label stacking). The S bit at the bottom of a label stack is set to 1; the S bit on all other labels is set to 0. Both types of labeling techniques, shim and link layer encoding, can co-exist in the same network along the same LSP, as long as the routers connecting the two disparate label capable link layers has the ability to perform the necessary conversion.
Label Operations
Push
Push the first label on the packet or Push a label on existing label stack For IP packets, set the TTL value of the label to the value in the IP packet
Pop
Remove the top label from the packet Copy the TTL value of the label to the TTL value of the IP Packet
Swap (applies to LSR only)

Combination of POP and PUSH operation Copy the TTL value from incoming label to new label after decrementing it
Appendix 4 8
Label processing is independent of the level of hierarchy. Processing is always based on the top label in the stack which includes information about the operations to perform on the packet's label stack. Operations can be one of the following: a. push (add) a new label to the top of the label stack; b. pop (remove) the top label in the label stack; c. swap (replace) the label at the top of the label stack with a specified new label.
Forwarding Equivalence Classes
LER LSR LSR LER
LSP IP1 IP1 IP1 #L1 IP2 #L1 IP1 #L2 IP2 #L2 IP1 #L3 IP2 #L3 IP2
IP2
Packets are destined for different address prefixes, but can be Packets are destined for different address prefixes, but can be mapped to common path mapped to common path FEC = A subset of packets that are all treated the same way by a router The concept of FECs provides for a great deal of flexibility and scalability In conventional routing, a packet is assigned to a FEC at each hop (i.e. L3 lookup), in MPLS it is only done once at the network ingress.
Appendix 4 9
Appendix MPLS Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
The Forwarding Equivalence Class (FEC) is an important concept in MPLS. An FEC is any subset of packets that are treated the same way by a router. When a packet enters the MPLS network at the ingress node, the packet is mapped into an FEC. The mapping can be based on a variety of parameters, including: a. b. c. d. forwarded out the same interface with the same next hop and label; given the same class of service; output on the same queue; given same drop preference or any other option available to the operator.
Using MPLS, the aggregation of packet flows into FECs of variable granularity provides scalability that meets the demands of the public Internet as well as enterprise applications.
LSP Types: Static LSP
All Routers are configured manually with labels No signalling is required
Dest 47.1 Dest 47.1 Int In Label Out 123 Int Out 123 123 2 123 123
Int In 3
Label In 123
Int Out 4
Label Out 456
456 456
Dest 47.1 456 456
Int In 5
Label In 456
Int Out -
47.1 5
Appendix 4 10
Static LSP
A static LSP uses a manually configured MPLS path where the nexthop IP address and the outgoing label are explicitly specified. No signaling, such as RSVP or LDP, is required to set up the path. As networks change, get larger and more complex with increased dynamics, the static approach becomes increasing complex and resource intensive to operate.
Switch to notes Signaled LSP view!

Dynamic signalling protocols allow MPLS-enabled routers to exchange information and request the establishment and label binding to an FEC for an end-to-end path. Signaling is triggered by the ingress router. Configuration is required only on the ingress router and is not required on intermediate routers.
LDP
The 7x50 router supports tunnel LSPs based on LDP. This capability may be deployed in service provider networks where traffic engineering capabilities are not required or for multi-vendor interoperability scenarios where RSVP tunnels are not currently supported for VLL or VPLS services. The 7x50 router implementation of LDP includes: a. downstream unsolicited advertisement mode b. ordered distribution control mode c. liberal label retention mode
TLDP
Targeted LDP sessions are LDP sessions between non-directly connected peers. When an SDP is All labeling Alcatel-Lucent 2009 automatic ingress and egress Rights Reserved (targeted LDP) is enabled by default and ingress Appendix MPLS Overview and 5620 SAM (Service Aware Manager) R7.0 Operator 5620 SAM egress service labels are signalled over a TLDP connection. If signaling is turned off on an SDP, ingress and egress service labels must be manually configured when the SDP is bound to a configured, Appendix 4 11 service.
RSVP-TE
Hop-by-Hop LSP
This method determines a path through the network based on the interior gateway protocols view of the network. If no constraints are applied to the LSP then the routers simply send the request for a path to the active next hop for that destination, no explicit routing. The IGP at each router is free to select active next hops based on the link state database.
LSP Types: Signaled LSP
LSPs are setup using a signaling protocol RSVP-TE or LDP Signaling protocol facilitates: Assignment of labels from ingress router to the egress router Signaling is triggered by the ingress routers no configuration is required on intermediate routers Path Selection
Dest 47.1 Dest 47.1 Int In Label Out 123 Int Out 2
e Requ
Int In 3
Label In 123
Int Out 4
Label Out 456

Re q
7.1 st: 4
ue st:
47 .1
Dest 47.1
Int In 5
Label In 456
Int Out -
123 ing: Mapp
Ma pp ing :4 56
47.1 5
Appendix 4 12
Explicit-path LSP
MPLS uses RSVP-TE to set up an explicit path LSP. The hops within the LSP are configured manually and can be configured as strict or loose. A strict hop indicates that the two nodes must be adjacent to one another with no intermediate hops separating them. A loose hop indicates the nodes do not have to be adjacent to each other and the IGP can be used to determine the best path to the loose hop.
LDP Signaling (Downstrean Unsolicitted)

LDP enabled on each router Interface(s) included in LDP instance Rtr B listens for 224.0.0.2 from Rtr A router ID address Rtr B responds with its system interface address Rtr A responds with its system interface address TCP session (port 646) established Label exchanged between both routers (stored in LIB)
Router A
Router B Router C LDP enabled on each router Interface(s) included in LDP instance Rtr C listens for 224.0.0.2 from Rtr B router ID address Rtr C responds with its system interface address Rtr B responds with its system interface address TCP session (port 646) established Label exchanged between both routers (stored in LIB)
Appendix 4 13
Label Distribution Protocol (LDP)

Label Distribution Protocol (LDP) is defined as a set of procedures by which one Label switched Router (LSR) informs another of the meaning of labels used to forward traffic between and through them. There are four categories of LDP messages: Discovery messages - used to announce and maintain the presence of an LSR in a network Session messages - used to establish, maintain, and terminate sessions between LDP peers Advertisement messages - used to create, change, and delete label mappings for FECs Notification messages - used to provide advisory information and to signal error information LDP on the 7x50 is used for: Tunnel LSPs based on LDP Targeted LDP sessions between non-directly connected peers
Switch to notes view! LDP

The Label Distribution Protocol (LDP) is a protocol defined by the IETF for the purpose of distributing labels in an MPLS environment. LDP relies on the underlying routing information provided by an IGP in order to forward label packets. The router Forwarding Information Base, or FIB, is responsible for determining the hop-by-hop path through the network. Unlike traffic engineered paths, which use constraints and explicit routes to establish end-to-end LSPs, LDP is used only for signaling best-effort LSPs.
Neighbor Discovery
LDP includes a neighbor discovery protocol that runs over UDP. Each LSR periodically multicasts a hello message to a well-known UDP port to which all LSRs listen. When a neighbor is discovered, a hello-adjacency is formed and the LSR with the numerically greater IP address is denoted as the active LSR. Hello messages must continue to be received periodically for the hello-adjacency to be maintained. Targeted LDP sessions between non-directly connected LSRs are supported using an extended discovery mechanism. In this case, targeted hello messages are periodically sent to a specific IP address. After the hello-adjacency is formed, the active LSR initiates establishment of a TCP connection to the peer LSR. At this point, an LDP session is initiated over the TCP connection. The LDP session consists of an exchange of LDP messages that are used to setup, maintain, and release Appendix 4 14 the session. The 7750 SR supports MD5 All Rights Reserved Alcatel-Lucent 2009 to provide for the authenticity and integrity of session Appendix MPLS Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator messages. LDP associates a FEC with each LSP it creates. A FEC is a collection of common actions associated with a class of packets. The FEC associated with an LSP specifies which packets are mapped to that LSP. LDP allows an LSR to request a label from a downstream LSR so it can bind the label to a specific FEC. LSRs can distribute a FEC label binding in response to an explicit request from another LSR Downstream-On-Demand (DOD) or LSRs can also distribute label bindings to LSRs that have not explicitly requested them - Downstream Unsolicited (DUS).
Targeted LDP Signaling
Router A
Router B
Router C
LDP enabled on Router A & C Interface(s) included in LDP instance on Router A & C Rtr A sends a unicast message to Router ID of Rtr C Rtr C responds with its system interface address Rtr A acknowledges with its system interface address TCP session (port 646) established Label exchanged between both routers (stored in LIB)
Appendix 4 15
Targeted LDP Signaling

Targeted LDP signaling permits the service provider to establish an LDP peering session between indirectly connected routers without requiring intermediary routers to also participate. In the example above, Router A will establish a peering session with Router C and it has been decided that Router B will not be included. To establish the LDP session, it will be necessary to define Routers A & C as Targeted Peers. To initiate label exchange and establish LDP peers, LDP is enabled on routers A & C and the appropriate interfaces included in the LDP instance. A unicast message from Router A is sent to the Router ID of Router C using the network interface address associated with the LDP interface. Router C responds with its system interface address through the IGP. Router A acknowledges the message from Router C with its system interface address and a TCP session is established. With TCP set, the LDP protocol initiates the label exchange process and each router builds a Label Information Base.
Switch to Reservation Resource notes view! Protocol (RSVP)

The Resource Reservation Protocol (RSVP) is a network control protocol that defines procedures for signaling QoS requirements and reserving the necessary resources for a router to provide a requested level of service to all nodes along a data path. RSVP is not a routing protocol. RSVP operates with unicast and multicast routing protocols which determine where packets are forwarded. RSVP is concerned with the QoS of those packets that are forwarded in accordance with the routing protocol.
RSVP Message Types

RSVP reservations are unidirectional in nature and uses two basic message types to set up LSPs, PATH and RESV.
PATH Message
The RSVP PATH message is used to store state information about each node in the path. Each RSVP sender periodically transmits a path message downstream along the route for each data path. The path state includes, at minimum, the IP address of the previous hop node. This IP address is used to route the reserve message on a hop-by-hop basis, in the reverse direction. In addition to the previous hop address, the path message contains the sender Traffic Specification (Tspec) object and optional Adspec object. The Tspec describes the source traffic characteristics in terms of peak data rate, average data rate, burst size, and minimum/maximum packet sizes. An optional AdSpec object is updated byRights Reserved Alcatel-Lucent 2009 along the path to indicate network elements All Appendix 4 16 Appendix MPLS Overview such as the availability of particular QoS services, the maximum bandwidth available information Aware Manager) R7.0 Operator 5620 SAM 5620 SAM (Service along the path, the minimum path latency, and the path MTU. State is installed at each device traversed by the PATH message, but no resources are reserved. Among other things, this state identifies the adjacent RSVP nodes, which pins down the path for the reservation. Resources are not actually reserved until the receiver responds to the PATH message with a RESV message.
RESV Message
Each receiver host transmits an RSVP reservation request to its upstream neighbor. Reservation messages follow the reverse path that the data packets use. The reservation message creates and maintains a reservation state in each node on the path. Reservation messages are eventually delivered to the sender, so that the sender can configure appropriate traffic control parameters for the first hop node.
RSVP: How does it work?
RSVP uses two message types for resource reservation Sender sends PATH message towards receiver indicating characteristics of the traffic Each Router along the path makes note of the traffic type Receiver sends RESV message back towards sender Each Router reserves the resources requested (if available) for the micro-flow Path Refresh and RESV Refresh messages are sent periodically
ILER
Resv Error Path Tear Path Refresh Path: 30.30.30.1

0. 1 30.3 : 30. Path
Pa th
Path Error
:3 0.3 0.3 0.1
ResV Tear ResV Refresh
ResV: 10.10.10.1 Resv Conf
0.1 10.1 : 10. ResV
Re s
V: 10 .10 .1
0.1
Path: 30.30.30.1
ResV: 10.10.10.1
ELER
Appendix 4 17
RSVP Operation
The slide above depicts the process used to establish an LSP: The sender [the ingress LER (ILER)], sends PATH messages toward the receiver, [the egress LER (ELER)], to indicate the FEC for which label bindings are desired. PATH messages are used to signal and request label bindings required to establish the LSP from ingress to egress. Each router along the path observes the traffic type. PATH messages facilitate the routers along the path to make the necessary bandwidth reservations and distribute the label binding to the router upstream. The ELER sends label binding information in the reserve (RESV) messages in response to PATH messages received. The LSP is considered operational when the ILER receives the label binding information.
Switch to notes view! RSVP Traffic Extensions (RSVP-TE)

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 LSP-tunnels. 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. Because traffic is aggregated, the number of LSP-tunnels (therefore the number of RSVP sessions) does not increase proportionally with the number of flows in the network. Therefore, the RSVP-TE specification addresses a major scaling issue with the original RSVP protocol, namely the large amount of system resources that would otherwise be required to manage reservations and maintain state for potentially thousands or even millions of RSVP sessions.
Reservation Styles
LSPs can be signaled with explicit reservation styles. The 7750 SR supports two different reservation styles :

Fixed filter (FF) Shared explicit (SE)

Appendix 4 18
The style information is part of the LSP configuration.
Fixed Filter (FF) Style

The FF reservation style specifies an explicit list of senders and a distinct reservation for each of them. Each sender has a dedicated reservation that is not shared with other senders. Each sender is identified by an IP address and a local identification number, the LSP_ID. Because each sender has their own reservation, a unique label and a separate LSP can be constructed for each sender-receiver pair. For traditional RSVP applications, the FF reservation style is ideal for a video distribution application in which each channel (or source) requires a separate pipe for each of the individual video streams.
RSVP: TE Extensions
RSVP-TE has extensions to support operation with MPLS:

Provide the mechanism to setup an explicitly routed LSP that could differ from the normal path calculated by the IGP. Perform downstream on demand label allocation, distribution, and binding among LSRs in the path, thus establishing path state in network nodes. Optionally provide resource reservations (bandwidth) along the path to meet the requirements of the traffic flow. Provide users information about the actual path traversed by the LSP. LSP preemption based on administrative policy control. Loop detection and avoidance during the initial LSP set-up and rerouting an existing LSP. Monitor and maintain the state of an explicitly routed LSP
Appendix 4 19
Admin Group
An MPLS interface can be configured to belong to a particular admin group. This information is advertised as part of OSPF and IS-IS to help CSPF compute constrained LSPs that must include or exclude certain admin groups.
RSVP: TE Extensions
RSVP Refresh Reduction PATH Refresh and RESV Refresh are sent out for each LSP Multiple messages are bundled into a single message to reduce network overhead Each bundled message contains Multiple Message-ids of the associated PATH and RESV messages for which the state needs to be refreshed
Appendix 4 20
Reducing RSVP Traffic

Bundle Messages
Support for RSVP bundle messages is optional. While the bundle message helps in scaling RSVP and in reducing processing overhead and bandwidth consumption, a node is not required to transmit every RSVP message in a bundle message. The bundle message extension reduces the overall volume of RSVP messages that must be periodically transmitted and received. The bundle message is used to aggregate multiple RSVP messages within a single protocol data unit (PDU). Only PATH and RESV messages can be bundled.
Message IDs
The reliable delivery of RSVP messages is improved by implementing an acknowledgment mechanism. When refresh messages (using PATH and RESV messages) are generated, the message ID object of RSVP can be used to provide an indication of when a message represents a new state. A receiving node can use this information to reduce the amount of time it spends processing refresh messages.
Signaled LSPs with CSPF
TE Capable IGP TE Capable IGP OSPF-TE OSPF-TE IS-IS-TE IS-IS-TE
Routing Table Routing Table
Traffic Traffic Engineering Engineering Database (TED) Database (TED)
Constrained Constrained Shortest Path First Shortest Path First (CSPF) (CSPF)
User User Requirements Requirements
Explicit Route Explicit Route Object Object (ERO) (ERO)
Signaling Signaling
Appendix 4 21
CSPF LSP
The Constraint-based Shortest Path First, or CSPF, process is an extension to the SPF process performed by link state routing protocols. The CSPF calculation uses constrains, obtained from the traffic engineering database and local input, to compute the shortest path through the network that matches the configured requirements. Once a path is found by CSPF, the explicit route object (ERO) in the RSVP message is updated with the path requirement information and RSVP uses the CSPF path to request the LSP set up. CSPF is also used to calculate the detour routes when fastreroute is enabled. Constraints taken into account by CSPF include: Admin groups, including link colors and resource classes (from TED) Bandwidth requested (from the TED) Hop limits (local user input)
RSVP: TE Extensions
RSVP Failure Detection Hello Message exchanged between neighbors Enables failure detection in milliseconds
ESR ESR
ESR
Secondary LSP
ESR
Hell o REQ
ESR or Core Router
Hot Standby Detour
Primary LSP
Hell
Hello REQ
o AC K
Hell
o RE
Q K o AC
Hello ACK
Hell
ESR
ESR
ESR
Appendix 4 22
Improved Failure Detection

The Hello protocol detects the loss of a neighbor node or the reset of a neighbors RSVP state information. In standard RSVP, Hello messages are sent between neighbors at regular intervals. If a response to an Hello message is not received within a specified time interval, the LSR assumes that either the neighbor node has been lost or its RSVP state information has been reset. The Hello protocol extension is composed of a Hello message, a Hello request object and a Hello ACK object. Hello processing between two neighbors supports independent selection of failure detection intervals. Each neighbor can automatically issue Hello request objects. Each Hello request object is answered by a Hello ACK object.
LSP Traffic Protection: Secondary Path (1)
Secondary Path LSPs can be: Standby (preconfigured) Signaled and set up upon failure of the primary LSP
ESR ESR ESR
LSP Secondary Path (Non-Fate Sharing )

ESR
Hello REQ
ESR or Core Router
LSP Primary Path

PATH Refresh
Hell
Hello REQ
o AC K
Hell
o RE
Q K o AC
Hello ACK
Hell
ESR RESV Refresh
ESR
ESR
Appendix 4 23
Secondary Paths
A secondary path is an alternative path that an LSP uses if the primary path is not available. Up to eight secondary or standby LSPs can be specified for each primary LSP. All the secondary paths are considered equal and the first available path is used. A standby secondary path LSP is signaled and maintained indefinitely in a hot standby state. When the primary path is re-established then the traffic is switched back to the primary path LSP. Make-Before-Break An LSP can be configured to be adaptive when it is attempting to reroute itself. In this case, the LSP holds onto existing resources until the new path is successfully established and traffic has been cut over to the new LSP.
LSP Traffic Protection: Secondary Path (2)
When Primary Path Fails The first secondary path becomes active Attempts are made to restore primary path (retry timer) Software will revert back to primary when it recovers
ESR ESR ESR
LSP Secondary Path (Non-Fate Sharing )

ESR
Hello REQ
ESR or Core Router
Hell
Hello REQ
o AC K
Hell
o RE
Q K o AC
LSP Primary Path

PATH ERR ESR
Hello ACK
Hell
ESR
RESV ERR ESR
Appendix 4 24
Secondary Paths
After a switchover from the primary to the secondary path, the system continuously tries to revert to the primary path. The switch back to the primary path is based on the retry-timer interval. The system will not switch back among secondary paths. The system starts the signaling of all nonstandby secondary paths at the same time. Retry counters are maintained for each unsuccessful attempt. Once the retry limit is reached on a path, the system will not attempt to signal the path and administratively shuts down the path. The first successfully established path is made the active path for the LSP.
LSP Traffic Protection: Fast-Reroute (1)
Difficult to quickly restore connectivity using traditional IP protocols because:

Failures are not detecting quickly Takes time to compute an alternate route Takes time to signal an alternate LSP and update forwarding tables
Appendix 4 25
Fast Reroute
A common problem with IP networks is the restoration time after a link or node failure. With traditional routing protocols, it can take anywhere from several seconds up to nearly a minute for a failure to be bypassed. There are multiple problems with traditional IP routing protocols when it comes to fast restoration of connectivity: Detecting the failure quickly, performing time consuming Dijkstra computations to find an alternative route, signaling an LSP when using MPLS, and installing new information in the forwarding table. MPLS Fast Reroute addresses these issues by defining ways of pre-computing and signaling backup paths before a failure, so that traffic can immediately be switched over to the backup path by the nearest node upon a failure. This allows traffic to flow almost continuously, without waiting for routing protocol convergence and signaling overhead. MPLS Fast Reroute depends on LSPs being established using the RSVP-TE. Using RSVP-TE, it is possible to predetermine the path an LSP should take by specifying an explicit path for the LSP. This allows for the creation of alternative LSPs that do not depend on the same link or node as the LSP being protected.
LSP Fast-Reroute: One-to-one Backup Method
R2 R1 R6 R3 R9 R7 R8 R4
R5
Protected LSP: R1>R2>R3>R4>R5 R1s backup: R1>R6>R7>R8>R3 R2s backup: R2>R7>R8>R4 R3s backup: R3>R8>R9>R5 R4s backup: R4>R9>R5
Appendix 4 26
One-to-One LSP Fast Reroute

Each upstream node sets up a detour LSP that avoids only the immediate downstream node, and merges back on to the actual path of the LSP as soon as possible. If it is not possible to set up a detour LSP that avoids the immediate downstream node, a detour can be set up to the downstream node on a different interface. The detour LSP may take one or more hops before merging back on to the main LSP path. In the diagram above, if R2 fails, or the link between R1 and R2 fails, traffic in the protected LSP from R1 is switched onto the R1 backup LSP, traversing R6, R7, and R8 before merging onto the original path at R3, also called the merge point (MP). This method does not require an extra label to be pushed onto the packet when the backup LSP is used for forwarding. The LSP can be protected in a similar manner from failures on other routers or links.
LSP Fast Reroute: Facility Backup Method
R4 R3 R9 R6 R7
R8 R1
R2
R5
Protected LSP 1: R1>R2>R3>R4>R5 Protected LSP 2: R8>R2>R3>R4 Protected LSP 3: R2>R3>R4>R9 Bypass LSP Tunnel: R2>R6>R7>R4
Appendix 4 27
Facility Backup LSP Fast Reroute

The facility backup fast reroute method uses a facility backup tunnel, or bypass, to bypass a failed link or a failed node. This method takes advantage of MPLS label stacking capabilities, and all LSPs protected using this method are protected using a single, common bypass tunnel. The original labels are left intact, and another label is pushed on top to direct it through the bypass tunnel. At the egress end of the tunnel, the traffic is merged back into the original path by popping the outer label and examining the inner label to find out where the packet should go. In the example shown in the diagram above, three LSPs, one from R1, R2 and R8 respectively, are protected by a single bypass tunnel going from R2 through R6, R7 and egress on R4. If the link between R2 and R3 fails, all three LSPs are directed through the bypass tunnel by pushing an extra label onto the packet. The bypass tunnel can protect a link between two nodes, or protect against the failure of an entire node through bypassing the node via other nodes in the network. This is called link and node protection, respectively.
LSP Record Route
RSVP supports the Record Route Object (RRO) RRO records all hops that the LSP transits RRO is a useful debugging tool RRO is enabled by default
Appendix 4 28
Route Recording
The route a path takes can be recorded. Recording the path allows the ingress LER to know, on a hop-by-hop basis, which LSRs the path traverses. Knowing the actual path of an LSP can be especially useful for diagnosing various network issues. The record route object (RRO) of RSVP is used by the sender to receive information about the actual route traversed by the RSVP-TE LSP. It is also used by the sender to request notification if there are changes to the routing path. Intermediate or transit nodes can optionally use the RRO to provide loop detection.
Questions
Questions
1. MPLS labels are located after the Layer 2 header and before the IP header. a. False
b. True
2. An LSP configuration that specifies that two nodes must be adjacent to one another with no intermediate hops separating them is known as what type of an LSP: a. Explicit strict
b. Explicit loose
3. A standby secondary MPLS path must be signaled when the primary path fails. a. True
b. False
?
4. Which type of LSP relies on a information provided by an IGP with traffic engineering extensions to determine a suitable path. a. Static b. Explicit loose
Appendix 4 29
c. Constrained
Answers
Answers
1. MPLS labels are located after the Layer 2 header and before the IP header. a. False b. True
2. An LSP configuration that specifies that two nodes must be adjacent to one another with no intermediate hops separating them is known as what type of an LSP a. Explicit strict b. Explicit loose
3. A standby secondary MPLS path must be signaled when the primary path fails. a. True b. False
4. Which type of LSP relies on a information provided by an IGP with traffic engineering extensions to determine a suitable path. a. Static
Appendix 4 30 b. Explicit
loose
c. Constrained
End of Module MPLS Overview
Appendix 4 31
Last Blank Page

Appendix 4 32
App5
Appendix
TOS36013_A_05 Issue 1.0
Appendix 5 Basic Services Overview
Blank Page

Appendix 5 2
Appendix Basic Services Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator All Rights Reserved Alcatel-Lucent 2009
Objectives
Upon successful completion of this module, the student will have a basic understanding of:
Services and the Alcatel-Lucent service model Service types - VLL, VPLS, IES and VPRN Service components
Customers Service Access Points (SAP) Service Distribution Paths (SDP) Service Tunnels and Labels
Service policies MTU considerations
Appendix 5 3
Appendix Basic Services Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
Understanding Services
Two main types of services: Internet connectivity

Represented by the Internet Enhanced Service (IES) is a global service Its purpose is to provide connectivity to the world as defined in the global routing table of a 7x50 router
VPN services
VPN services (VLL, VPLS, and VPRN) are restricted; the scope of the VPN must be defined what is allowed into it and how the nodes are connected to each other
Appendix 5 4
Naming Conventions
PE P CE P PE
P CE = customer edge PE = provider edge P = provider router CE
Appendix 5 5
Network Components
Customer Edge Devices (CE)
A customer edge (CE) device provides customer access to the service provider network over a data link to one or more provider edge (PE) routers. The end-user typically owns and operates these devices. The CE devices run the routing protocol(s) of the end-user and support the IP address scheme implemented by the end-user. They are unaware of the existence of the MPLS protocol or the VPNs (Virtual Private Networks). CE devices used in Layer 2 VPNs may be an Ethernet switch, in which case they do not need to participate in routing protocols. They must only be aware of VLANs (Virtual Local Area Networks) running in the customer network.
Provider Edge Devices (PE)

A PE router is directly connected to the customer edge (CE) devices. In an MPLS network PE routers are LERs (Label Edge Routers).
Provider Router (P)

The routers in the provider core network. In an MPLS provider network routers are LSRs (Label Switch Routers).
Internet Enhanced Service (IES)

Internet
Company C
Service Provider Network

PE A
PE C
PE B Company A Company B
Internet Enhanced Service provides direct internet access for the customer with the added function of providing for traffic engineering, QoS, accounting, etc.
Appendix 5 6
IES Service
An Internet Enhanced Service (IES) is a routed connectivity service where the subscriber communicates with an IP (Layer 3) router interface to send and receive Internet traffic. The 7750 SR buffers service traffic and shapes it to conform to SLA parameters. Buffer allocation is programmable per-service to accommodate different maximum burst sizes (MBS). Each service can use multiple queues to enable shaping, policing and marking of different flows. The 7750 SR can also shape and police on service egress so customers can purchase sub-rate services (e.g. Internet services) with asymmetric SLAs.
Characteristics
Service Access Point (SAP) acts as the access point to the subscribers network SAP supports multiple encapsulation types, such as: Ethernet null, dot1q, q-in-q, SONET/SDHIPCP, BCP-null, BCP-dot1q and ATM. Supports VRRP, Cflowd, secondary IP addresses, and ICMP options on customer IP interfaces Interface supports RIP, OSPF, IS-IS, and BGP. QoS and filter policies Does not require a Service Distribution Path (SDP); traffic is routed rather than being encapsulated in a tunnel
Virtual Leased Line (VLL) Service

PE B
PE A
PE C
IP / MPLS Network
VLL
PE D
A VLL service provides a point to point connection between two nodes.

Appears as if a leased link exists between the two locations. The Service provider can apply billing, ingress/egress shaping and policing No MAC learning required
Appendix 5 7
Virtual Leased Line (VLL)

The 7x50 router supports a Layer 2 point-to-point service commonly known as a Virtual Leased Line (VLL). The VLL service encapsulates customer data and transports it across a service providers IP or MPLS network in a GRE or MPLS tunnel. Customer access to the service providers network is through a Service Access Point (SAP). An VLL connects two access points (SAP) on the same node or two SAPs on different nodes through two uni-directional tunnels. Each node requires a SDP (Service Distribution Path) to provide access to the service tunnel. A basic VLL service must have the following: A locally unique SDP identification number System IP address of the originating and far-end nodes SDP encapsulation type GRE or MPLS QoS and filter ingress and egress policies can be applied to VLL services. Types of VLLs are: Epipe (Ethernet to Ethernet/ATM/FR) Cpipe (CEM to CEM) (as of Release 6.0) Apipe (ATM to ATM/FR) Fpipe (FR to FR) Ipipe (IP Interworking VLL)
Switch Private LAN Virtual to notes view! Service

The 7750 SR supports Virtual Private LAN Service (VPLS) multipoint switched services. A VPLS is a multipoint Layer 2 service that allows multiple customer sites to be connected in a single bridged domain contained within a provider-managed IP/MPLS network. Customer sites in the VPLS appear to be on the same LAN, even if the sites are geographically dispersed. A VPLS: Uses an Ethernet interface on the customer access side to simplify provisioning Enables customers to control and simplify routing strategies, as all routers in the VPLS are part of the same LAN, which simplifies IP addressing Is protocol independent, which means there is no Layer 2 protocol conversion between LAN and WAN technologies. A VPLS can span a single node or multiple nodes. On a VPLS that spans a single node subscriber data is distributed through multiple service access points (SAP) on the node. A VPLS on a single node does not require an SDP. On a VPLS that spans multiple sites customer data enters the service using at least one SAP on each node. Data is transported among the nodes through service tunnels over an IP/MPLS provider core network. A VPLS that spans multiple nodes requires at least one SDP at each node. VPLS services switch traffic based on MAC addresses (associated to the appropriate SAP).
Appendix 5 8
Customer Edge (CE) Equipment
Although VPLS is a Layer-2 VPN service and allows the use of Layer-2 switches as the CE device, most customers use routers at the LAN/WAN boundary. Using a router as the CE device means that the PE device only has to learn one MAC address persite per-service. Using a Layer-2 switch as the CE device means that the PE device has to learn potentially hundreds of MAC addresses per-site per-service. The number of MAC addresses that the PE device has to learn can be limited through the use of MAC filters and/or by limiting the maximum number of MAC addresses accepted by the PE device.
Virtual Private LAN Service (VPLS)
PE B
PE A
PE C
IP / MPLS Network
VPLS
PE D
Connects multiple sites in a single bridged domain Reuse IP/MPLS infrastructure to offer multiple services Billing, ingress/egress shaping and policing can be applied
Appendix 5 9
Virtual Private Routed Network (RFC4364)

MP-BGP Route MP-BGP Route Exchange Exchange For all Services For all Services
PE B
RI-1 RI-1 RI-2 RI-2
PE A
RI-1 RI-1 RI-2 RI-2
PE C
RI-1 RI-1 RI-2 RI-2
VPRN 1 VPRN 2
RI-1 RI-1 RI-2 RI-2
RI-1 RI-2
PE D
Connects multiple sites in a routed domain over a provider managed IP/MPLS network:
Appears that all sites are connected to a private routed network administered by the service provider for a particular customer Service provider can reuse the IP/MPLS infrastructure to offer multiple services Each VPRN appears like an additional routing instance, routes for a service between the various PEs are exchanged using MP-BGP
Appendix 5 10
Virtual Private Routed Networks (VPRN)

RFC 4364 details a method of distributing routing information and forwarding data to provide a Layer 3 Virtual Private Networks (VPN) service to end customers. Each Virtual Private Routed Network (VPRN) consists of a set of customer sites connected to one or more PE routers. Each associated PE router maintains a separate IP forwarding table for each VPRN. Additionally, the PE routers exchange the routing information configured or learned from all customer sites via Multi-Protocol BGP (MP-BGP) peering. Each route within a VPN is assigned an MPLS label. When BGP distributes a VPN route, it also distributes an MPLS label for that route. Before a customer data packet travels across the service provider's backbone, it is encapsulated with the MPLS label that corresponds, in the customer's VPN, to the route which best matches the packet's destination address. The MPLS packet is further encapsulated with either another MPLS label or GRE tunnel header, so that it gets tunneled across the backbone to the proper PE router. Each route exchanged by the MP-BGP protocol includes a route distinguisher (RD), which identifies the VPRN association. Thus the backbone core routers do not need to know the VPN routes.
Service Configuration Model
To provision a service, the following must be defined:

Customer Service Type Service Access Point (SAP) a logical entity that serves as the customer access to the service
To provision a VPN service (VPRN, VPLS or ePipe), must also define Service Distribution Path (SDP). Consists of:
Network interface with appropriate encapsulation method Service Tunnel defines signaling mechanism to be used between service endpoints. RSVP-TE, LDP or Generic Router Encapsulation (GRE)
Appendix 5 11
Logical Service Level Connectivity

Tunnel supporting MartiniTunnel supporting Martinitype service type service encapsulations. Tunnels are encapsulations. Tunnels are unidirectional, but are unidirectional, but are usually paired to provide a usually paired to provide a bi-directional service. bi-directional service. SDP binds multiple services to a SDP binds multiple services to a tunnel. tunnel.
Egress and ingress VC label Egress and ingress VC label provisioned or dynamically provisioned or dynamically assigned. Uniquely assigned. Uniquely Identifies the service to the Identifies the service to the tunnels far end. tunnels far end.
SAP is the customer point of access.
PE-A
SAP Service 1
VC Label
SDP
SDP
VC Label Demux
VC Label
PE-B
SAP Service 1
VC Label Demux
Appendix 5 12
Service Connectivity
Customer
When a service is configured using the 5620 SAM, it must be associated with a customer.
Service Access Point (SAP)

Customer access point to the service Provisioned on access ports only; encapsulation must be specified
Service Distribution Path (SDP)

Locally unique ID number System address of the originating and far-end 7750 SR routers SDP encapsulation type; GRE or MPLS
Service Components
Service Access Subscribers Points
Service Distribution Path
Service Distribution Path
Service Access Points
Subscribers
Customer 100
SAP
Service 50
Customer 100
Service 50
Customer 100
SAP
Customer 100
SDP 3
Demux
Customer200
Demux
SDP 5
Customer200
Customer 200
SAP
Service 25
Service 25
SAP
Customer 200
Service Tunnels
Appendix 5 13
SAPs, SDPs, and Tunnels

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, MPLS, LDP) type and services are mapped to the service tunnel that most appropriately supports the service requirements.

A SAP is a logical entity that serves as the customers point of access into a service. Each subscriber 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 you may need to reconfigure a port before you can configure a SAP on it. SAPs for IES and VPRN services are configured on IP interfaces.

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 multinode 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.
CE
PE
PE
SAP SAP
CE
Customer edge access to Provider network Consists of:

physical Ethernet port or POS port and channel encapsulation type encapsulation identifier (ID)
Appendix 5 14
SAP Characteristics
A SAP is the subscriber-side service entry and exit point for a service. A SAP is local to the 7750 SR and is uniquely identified by: physical Ethernet port or Packet-Over-SONET/SDH (POS) port and channel encapsulation type encapsulation identifier (ID) Depending on the encapsulation used, a physical port or POS channel can have more than one SAP associated with it. Using dot1q encapsulation or POS channels, the 7x50 router can support multiple services for a customer or services for multiple customers. Access interfaces can only be created on ports or channels that are configured as access ports in the physical port configuration. Access interfaces cannot be created on ports designated as network ports because these ports have a different set of features enabled in software.
Switch to notes view! SAP Encapsulation Types, Identifiers, and Characteristics

SAP encapsulation provides the router with a way of delineating services. Null means there is only one service on the port, the other encapsulations (dot1q, q-in-q and ATM) indicate that there can be multiple services on that port.
Ethernet Encapsulation
Three encapsulation types are supported on Ethernet access ports: Null - Supports a single service on the port and is used in situations where there is a single customer edge (CE) device connected to the port. The encapsulation identifier (ID) is set to zero. Dot1Q - A single qtag (qtag1) is used to delineate customer services. This tag can have a value from 0-4094. All tags are local to the port where the SAP is bound. Q-in-Q Up to two qtags (qtag1 and qtag2) are used to delineate customer services. Each tag can have a value from 0-4094. All tags can be local to the port where the SAP is bound or the inner label can be transported intact to the destination if the router is configured to do so.
SONET/SDH Encapsulation
IPCP - Internet Protocol Control Protocol (IPCP) supports a single IP service on a POS port or in the case of a channelized POS port, a single service per channel. Often used for router interconnection using Point-to-Point Protocol (PPP). BCP-Null - Bridging Control Protocol (BCP-Null) supports a single IP service on a POS port or in the case of a channelized POS port, a single service per channel. This protocol is used for All Rights Reserved Alcatel-Lucent 2009 Appendix 5 15 bridging a single service between two devices using PPP over SONET or SDH. Appendix Basic Services Overview 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator BCP-Dot1Q - Supports multiple services on a POS port or channel. This protocol is used for bridging multiple services between two devices using PPP over SONET or SDH. The Dot1Q VLAN tag is used to identify the different services. ATM Frame Relay
SAP Characteristics
Configuration of access interfaces is performed during service configuration or modification. SAPs have the following characteristics: An access interface is owned by and associated with the service in which it is created. An access interface is a local entity and is locally unique to a given device. The same access interface ID value can be used on another 7x50 router.
SAP Encapsulation Types and Identifiers

Null - supports a single service on a port Dot1q (802.1q) supports multiple services for a single customer or multiple services for multiple customers Q-in-Q provides a way to differentiate customer services based on Q tags
Ethernet Encapsulation
SAP Encapsulation Types

SONET/SDH Encapsulation
IPCP- supports a single IP service on a POS port or channel. SAP is identified by the channel BCP-Null - supports a single service on a POS port or channel BCP-dot1q - supports multiple services on a POS port or channel. ATM Frame Relay
Appendix 5 16
There are no default access interfaces. All access interfaces must be created. Once created, a SAP is administratively enabled by default. If a port or channel is shut down (either administratively or operationally), access interfaces on that port/channel will be operationally out of service. When a port/channel has a dot1q or BCP-dot1q encapsulation type, the traffic for the access interface is identified based on a specific IEEE 802.1Q VLAN ID value. The VLAN ID is stripped off at access interface ingress and the appropriate VLAN ID is placed on at access interface egress. As a result, VLAN IDs only have local significance, so the VLAN IDs for the access interfaces need not be the same at each access interface.
SAP Configuration Considerations
Consider the following when configuring a SAP:

Must be unique to the local router Associated with a single service Only configured on an Access port A port or channel can have more than one SAP configured on it Must be explicitly created and are administratively enabled at the time of creation (no default SAPs) VLAN IDs have local significance Can be configured with an: Ingress and Egress Filter Policy Ingress and Egress QoS Policy Ingress and Egress Scheduler Policy Accounting Policy
Appendix 5 17

SDP SDP
PE-B
MPLS or GRE
MPLS or GRE
PE-A
SDP SDP
Provider Edge to Provider Edge Consists of:
encapsulation type encapsulation identifier (ID) service type, ID and label service tunnel
Appendix 5 18
SDP (Service Distribution Path) Characteristics

An SDP is the edge-to-edge transport mechanism for a service within the providers network and is created when a service is associated to a service tunnel. In this manner, the service can be referred to as a Distributed service; terminating across different network elements. SDPs can only be created on ports or channels that are configured as Network ports in the physical port configuration. An SDP is local to the 7x50 network elements and is uniquely identified by: physical Ethernet port or Packet-Over-SONET/SDH (POS) port and channel encapsulation type encapsulation identifier (ID) service type, ID and VC label service tunnel
Tunnel Encapsulation
GRE
Encapsulates traffic in an IP/GRE header; appears like an IP packet. Low control plane overhead. Uses normal IP routing to find a path.
MPLS
Uses LDP or RSVP for label signaling. LDP auto-bind available to simplify configuration. LDP relies on an IGP to find its path RSVP
Requires manual configuration Can be loose or strict May reserve bandwidth Can use Fast ReRoute to speed convergence
Appendix 5 19
SDP Encapsulation
Generic Routing Encapsulation
Low control plane overhead Uses an IGP (ie. OSPF, IS-IS) to find a path from edge to edge Convergence depends on the IGP
MPLS
Uses Label Switched Paths (LSP). Primary and secondary paths provide LSP protection). Paths can be manually configured or signalled using LDP or RSVP-TE
Tunnel Encapsulation Labels

MPLS Packet Format
DLC DLC Header Header MPLS MPLS SW label SW label Service Service VC-Label VC-Label Optional Flags (e.g. for F/BECN) Sequence #
Control Control Word Word
Service Service Packet Packet
Martini Encapsulation
GRE Packet Format

DLC DLC Header Header IPv4 Header IPv4 Header GRE PID GRE PID GRE-header GRE-header MPLS-PID MPLS-PID Service Service VC-Label VC-Label
Optional: Flags (e.g. for F/BECN) Sequence #
Control Control Word Word
Service Service Packet Packet
Martini Encapsulation
Appendix 5 20
Tunnel Encapsulation
Tunnel Label
Identifies the LSP tunnel carrying the payload frame. This label gets swapped at each LSR between the source and destination routers.
VC Label
The VC label identifies a particular service. A tunnel may carry several services at the same time. At the customer ingress point to the provider network a provider edge (PE) router encapsulates the customer data in an inner VC label, then adds the outer tunnel label before forwarding the data.
VC Label Signaling
Customer 2
Customer 1
Customer 2
Customer 1 Customer 2
Customer 1 VPLS 1
VPLS Service Instances

Appendix 5 21
TLDP Signaling for Service Instances
VPLS 2
VC Label Signaling
Signaling protocols LDP or RSVP-TE are used to set up label switched paths that can then be used for VPN service tunnels. VC labels are used to encapsulate and identify customer traffic belonging to a particular service. This label is applied to the customer traffic before the LSP label is applied. VC labels for VPLS and VLL services are signalled using targeted LDP (TLDP).
Switch to Considerations MTU Size notes view!

Maximum Transmission Unit (MTU) size defines the maximum size, in bytes, for a single unit of data that can be sent over a given link. If a packet cannot fit into the MTU of a given link, it is fragmented, and the fragments reassembled on the other end of the connection. Since fragmentation is an expensive operation and cannot be done at line rates it is not supported on the 7750 SR. If there is an MTU mismatch, a service will not work. There is an MTU associated with all of the data links on the 7750 SR, including both physical virtual circuits. A virtual circuit can be built using either MPLS or GRE encapsulation.
Physical MTU:
This is configured on the physical ports of the 7x50 router and applies to both access and network ports. This MTU governs how large packets can be on a given physical wire. If the physical MTU on an egress interface or PoS channel indicates the next hop on an SDP path cannot support the current path-mtu, the operational path-mtu on that SDP will be modified to a value that can be transmitted without fragmentation.
Service MTU:
This MTU is associated with a service and determines how large packets can be that are sent from the customer across the service. The service-mtu defines the service payload capabilities of the service. It is used by the system to validate SAP creation and SDP binding within the service. Based on the encap-type and the physical mtu, a SAP created on an access interface will be limited All Rights Reserved that service payload is less than the required Appendix 5 22 to a maximum service payload size. If Alcatel-Lucent 2009 Appendix Basic Services Overview service-mtu, the SAP will not enter the operative state. 5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator
SDP Path MTU:

This MTU determines how large packets can be that are sent over the service path. Path MTU configures the Maximum Transmission Unit (MTU) in bytes that the Service Distribution Path (SDP) can transmit to the far-end without packet dropping or IP fragmentation overriding the SDP-type default path-mtu. Dynamic maintenance protocols on the SDP like RSVP may override this setting.
MTU Types
Access Port MTU Service payload + DLC Header + dot1q tag(s)
VC Label SAP Service
SDP
Service MTU dot1q tags removed
Port MTU Service Payload + VC label + MPLS Path Label + DLC Header
Appendix 5 23
Physical MTU Size - MPLS

Network interface MTU must be greater than maximum service MTU plus largest encapsulation type
Minimum MTU size for 1514-byte Service over MPLS

Packet over SONET 1514 bytes 4 bytes 4 bytes 4 bytes 2 bytes n/a 1528 bytes Ethernet 1514 bytes 4 bytes 4 bytes n/a n/a 14 bytes 1536 bytes Overhead Service Payload MPLS tag used as Service Identifier MPLS Tag used as Egress LSP MPLS External Header PPP MCLSP Header DLC Header Total
Appendix 5 24
Physical MTU Size - GRE

Network interface MTU must be greater than maximum service MTU plus largest encapsulation type
Minimum MTU size for 1514-byte Service over GRE

Packet over SONET 1514 bytes 4 bytes 4 bytes 20 bytes 2 bytes n/a 1544 bytes Ethernet 1514 bytes 4 bytes 4 bytes 20 bytes n/a 14 bytes 1556 bytes Overhead Service Payload MPLS tag used as Service Identifier Generic Router Encapsulation IP Header PPP IPCP Header DLC Header Total
Appendix 5 25
Physical MTU Default Values

Port Type
Ethernet Ethernet Fast Ethernet Other Ethernet PoS Channel PoS Channel PoS Channel PoS Channel
Mode
access access network network access access access network
Encap Type
null dot1q bcp-null bcp-dot1q ipcp -
Default (Bytes)
1514 1518 1514 9212 1522 1526 1502 9208
Blank Page

Appendix 5 26
Questions
Questions
1. A VPLS service requires an SDP. a. False
b. True
2. If a data packet within a VPN service cannot fit into the MTU of a given link it will be fragmented before being transmitted. a. False
b. True
3. What statement about service tunnels is not true?
a. The tunnel is locally unique to a participating 7x50 router b. Once a tunnel is created, multiple service circuits are aggregated over the tunnel. c. Service tunnels are bi-directional
d. A tunnel uses the system IP address to identify the far-end 7x50 edge router.
?
4. Which of the following are not considered Layer 2 services? a. VPLS

Appendix 5 27
b. IES
c. VLL d. VPRN
Answers
1. A VPLS service requires an SDP. a. False

b. True
2. If a data packet within a VPN service cannot fit into the MTU of a given link it will be fragmented before being transmitted. a. False
b. True
3. What statement about service tunnels is not true?
a. The tunnel is locally unique to a participating 7x50 router b. Once a tunnel is created, multiple service circuits are aggregated over the tunnel. c. Service tunnels are bi-directional A tunnel uses the system IP address to identify the far-end 7x50 edge router. 4. Which of the following are not considered Layer 2 services? a. VPLS
Appendix 5 28
b. IES
c. VLL d. VPRN
End of Module Basic Services Overview
Appendix 5 29
Last Blank Page

Appendix 5 30
Last But One Page

1
@@PRODUCT @@COURSENAME
All Rights Reserved Alcatel-Lucent @@YEAR @@COURSENAME - Page 1
All rights reserved Alcatel-Lucent 2009 Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent
All Rights Reserved Alcatel-Lucent @@YEAR @@COURSENAME - Page 2

5620 SAM (Service Aware Manager) R7 (1) .0 Operator Ed

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

5620 SAM (Service Aware Manager) R7 (1) .0 Operator Ed

Hochgeladen von

Copyright:

Verfügbare Formate

5620 SAM 5620 SAM (Service Aware Manager) R7.

All Rights Reserved Alcatel-Lucent 2009

Terms of Use and Legal Notices

All rights reserved Alcatel-Lucent 2009

All Rights Reserved Alcatel-Lucent 2009

This page is left blank intentionally

4. Topic/Section is Positioned Here

6. Topic/Section is Positioned Here 7. Topic/Section is Positioned Here

2. Topic/Section is Positioned Here

2. MPLS using LDP 3. Traffic Engineering

All Rights Reserved Alcatel-Lucent 2009

4. Topic/Section is Positioned Here 5. Topic/Section is Positioned Here 6. Topic/Section is Positioned Here

1. Performance Management 1. Redundancy

12. Appendix 1. Topic/Section is Positioned Here

2. Topic/Section is Positioned Here 3. Topic/Section is Positioned Here

All Rights Reserved Alcatel-Lucent 2009

Course Outline [cont.]

All Rights Reserved Alcatel-Lucent 2009

This page is left blank intentionally

Welcome to 5620 SAM (Service Aware Manager) R7.0 Operator

Upon completion of this course, you should be able to:

All Rights Reserved Alcatel-Lucent 2009

Course Objectives [cont.]

All Rights Reserved Alcatel-Lucent 2009

This page is left blank intentionally

About this Student Guide

All Rights Reserved Alcatel-Lucent 2009

5620 SAM 5620 SAM (Service Aware Manager) R7.0 Operator

Where you can get further information

About this Student Guide [cont.]

All Rights Reserved Alcatel-Lucent 2009

This page is left blank intentionally

Client (Company, Center) : Language : Switch

Number of trainees : Surname, First name :

Instructional objectives 1 To be able to XXX

Self-assessment of Objectives [cont.]

All Rights Reserved Alcatel-Lucent 2009

Thank you for your answers to this questionnaire

Do not delete this graphic elements in here:

Section 1 Product Overview

Module 1 Alcatel-Lucent IP Products Overview

All Rights Reserved Alcatel-Lucent 2009

All Rights Reserved Alcatel-Lucent 2009

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2009

5620 SAM R7.0 Supported Alcatel-Lucent Devices

All Rights Reserved Alcatel-Lucent 2009

The 5620 SAM supports the above listed Alcatel-Lucent devices.

7750 / 7710 Service Routers

7710 SR 7750 SR-12

7750 / 7710 Service Routers [Cont.]

[Inserted note] 400 G SF/CPMs can be installed as an alternative.

7710 Service Router

7705 Service Aggregation Router

All Rights Reserved Alcatel-Lucent 2009

7705 SAR Chassis

7450 Edge Service Switch

7450 Edge Service Switch [Cont.]

7450 Edge Service Switch [Cont.]

7250 Service Access Switch / Telco T5C

7250 Service Access Switch (SAS) / Telco T5C

OmniSwitch 6400 / 6850 / 6855