EMC Smarts MPLS Manager · EMC Corporation Corporate Headquarters: Hopkinton, MA 01748-9103...

EMC CorporationCorporate Headquarters:

Hopkinton, MA 01748-91031-508-435-1000www.EMC.com

EMC® Smarts®MPLS Manager

Version 3.0

Discovery GuideP/N 300-008-581

REV A01

EMC Smarts MPLS Manager Version 3.0 Discovery Guide2

Copyright © 2004 - 2009 EMC Corporation. All rights reserved.

Published February, 2009

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.

All other trademarks used herein are the property of their respective owners.

EMC Smarts MPLS Manager Version 3.0 Discovery Guide 3

Preface

Chapter 1 Discovery Overview Terminology............................................................................................................. 14 LSP support ............................................................................................................. 15 VPN support............................................................................................................ 16 Device support ........................................................................................................ 17 SNMP and CLI discovery support ....................................................................... 18 Overlapping IP address support .......................................................................... 19 VPN-Tagging Server support................................................................................ 19 Multi-VRF CE support ........................................................................................... 19 Discovery overview................................................................................................ 20 IP Availability Manager discovery....................................................................... 22 MPLS Topology Server discovery ........................................................................ 23 When discovery occurs .......................................................................................... 28

Chapter 2 MPLS VPN Overlapping IP Discovery Introducing the VPN-Tagging Server .................................................................. 30 Functional overview............................................................................................... 32 Discovery in the Cisco environment.................................................................... 33 Discovery in the Alcatel-Lucent environment.................................................... 35 Discovery assumptions and criteria..................................................................... 38 Overlapping IP naming format ............................................................................ 38 Configuring the VPN-Tagging Server ................................................................. 39 Starting the VPN-Tagging Server ......................................................................... 39

Chapter 3 Discovery Process Discovery process overview.................................................................................. 42 Discovery process details ...................................................................................... 44

Chapter 4 Discovery of MPLS Objects MPLS discovery overview..................................................................................... 52 MPLS TE tunnel discovery.................................................................................... 53 MPLS discovery process ........................................................................................ 56

Contents


Contents

Chapter 5 Discovery of L2VPN Objects L2VPN discovery overview................................................................................... 68 L2VPN discovery process ...................................................................................... 69

Chapter 6 Discovery of L3VPN Objects L3VPN discovery overview................................................................................... 80 L3VPN discovery process ...................................................................................... 80

Chapter 7 Preparing and Initiating Discovery Preparing for discovery.......................................................................................... 86 Initiating discovery ................................................................................................. 87 Synchronizing with IP Availability Manager...................................................... 88 Synchronizing with the MPLS Topology Server................................................. 89 Specifying a different IP Availability Manager source ...................................... 92

Chapter 8 Understanding Discovery Results Discovery results ..................................................................................................... 96 Discovery error resolutions ................................................................................... 97 Error message formatting .................................................................................... 100 Examples of error messages in CLI log files...................................................... 102 Pending Elements list ........................................................................................... 103

Chapter 9 Invoking Full or Pending Discovery Discovery methods ............................................................................................... 106 Full discovery......................................................................................................... 106 Pending discovery................................................................................................. 107

Appendix A MIBs Accessed for Discovery and Remote Ping SNMP versions supported................................................................................... 110 MIBs accessed for MPLS discovery .................................................................... 110 MIBs accessed for L2VPN discovery.................................................................. 112 MIBs accessed for L3VPN discovery.................................................................. 114 MIBs accessed for remote ping............................................................................ 115

Appendix B CLI Commands Invoked for Discovery and LSP Ping CLI commands overview..................................................................................... 118 CLI commands invoked on Cisco devices......................................................... 118 CLI commands invoked on Huawei devices .................................................... 120 CLI commands invoked on Juniper M/T devices............................................ 121 CLI commands invoked on Juniper ERX devices ............................................ 122 CLI commands invoked for LSP ping................................................................ 123

Index


Title Page

1 A multi-VRF CE device deployment serving five clients ............................................... 192 MPLS Manager discovery .................................................................................................... 213 Physical-transport domain discovered by IP Availability Manager ............................. 224 MPLS domain discovered by the MPLS Topology Server .............................................. 235 Network recovery through link protection ....................................................................... 246 Network recovery through node protection ..................................................................... 247 Network recovery through path protection ...................................................................... 258 L2VPN VPWS domain discovered by the MPLS Topology Server ............................... 259 L2VPN VPLS domain discovered by the MPLS Topology Server ................................. 2610 L3VPN domain discovered by the MPLS Topology Server ........................................... 2711 Example of overlapping IPs in MPLS-enabled VPNs ...................................................... 3012 IP overlapping configuration 1: separate PE-CE pairs .................................................... 3113 IP overlapping configuration 2: common PE, separate CEs ........................................... 3114 IP overlapping configuration 3: common PE and CE, separate VRFs ........................... 3215 VPN-Tagging Server discovery in the Cisco environment ............................................. 3316 MPLS VPN overlapping IP discovery flow in the Cisco environment ......................... 3417 VPN-Tagging Server discovery in the Alcatel-Lucent environment ............................. 3518 Discovery flow for the MPLS Topology Server ................................................................ 4419 FRR switching for a failed link ............................................................................................ 5420 FRR switching for a failed node .......................................................................................... 5421 Path-protection switching for a failed TE tunnel ............................................................. 5522 Simplified view of ICIM MPLS data model ...................................................................... 5623 The LSP table manager and LSP discovery ....................................................................... 6024 LSP segment entries for an LSP that consists of two LSP segments .............................. 6125 Relationships for the link/node and path-protected TE tunnel examples ................... 6426 Relationships between the MPLS and transport models ................................................ 6627 Simplified view of ICIM LDP L2VPN data model ........................................................... 6928 Simplified view of ICIM BGP L2VPN data model ........................................................... 7029 Relationships between the LDP L2VPN, MPLS, and transport models ....................... 7730 Relationships between the BGP L2VPN, MPLS, and transport models ....................... 7831 Simplified view of ICIM L3VPN data model .................................................................... 8032 Relationships between the L3VPN, MPLS, and transport models ................................ 8333 Topology subsets imported by the MPLS Monitoring and Analysis Servers .............. 9134 Attach Manager dialog box ................................................................................................. 9835 Domain Manager Administration Console ....................................................................... 9936 EMC Smarts exception message formatting ................................................................... 10037 Pending Elements list containing one pending element ............................................... 103

Figures


Figures


Title Page

1 Discovery sources for supported devices .......................................................................... 182 Initial topology added to the MPLS Topology Server repository .................................. 463 Additional topology added to the MPLS Topology Server repository ......................... 494 MPLS Discovery sources ...................................................................................................... 575 Device type definitions ......................................................................................................... 586 MPLSService relationship set .............................................................................................. 597 L2VPN Discovery sources ................................................................................................... 718 Some EMC Smarts subsystems and their descriptions .................................................. 1019 MIB objects accessed for MPLS discovery ....................................................................... 11010 MIB objects accessed for L2VPN discovery .................................................................... 11211 MIB objects accessed for L3VPN discovery .................................................................... 11412 MIBs access for remote ping .............................................................................................. 11513 CLI commands for discovery on Cisco devices .............................................................. 11814 CLI commands for discovery on Huawei devices ......................................................... 12015 CLI commands for discovery on Juniper M/T devices ................................................. 12116 CLI commands for discovery on Juniper ERX devices .................................................. 122

Tables


Tables


Preface

As part of an effort to improve and enhance the performance and capabilities of its product lines, EMC periodically releases revisions of its hardware and software. Therefore, some functions described in this document may not be supported by all versions of the software or hardware currently in use. For the most up-to-date information on product features, refer to your product release notes.

If a product does not function properly or does not function as described in this document, please contact your EMC representative.

Audience This document is part of the EMC Smarts MPLS Management Suite documentation set. It is intended for IT managers seeking to understand how the MPLS Manager discovery process works, and for system administrators responsible for the administration, configuration, or use of MPLS Manager.

EMC Smarts MPLSManagement Suite

installation directory

In this document, the term BASEDIR represents the location where EMC Smarts software is installed:

◆ For UNIX, this location is: /opt/InCharge/.

◆ For Windows, this location is: C:\InCharge\.

The represents the EMC Smarts software platform version number. The represents the EMC Smarts product suite to which the product belongs. For example, on UNIX operating systems, EMC Smarts MPLS Management Suite is, by default, installed to /opt/InCharge7/MPLS/smarts. On Windows operating systems, this product is, by default, installed to C:\InCharge7\MPLS\smarts. This location is referred to as BASEDIR/smarts.

Optionally, you can specify the root of BASEDIR to be something other than /opt/InCharge7 (on UNIX) or C:\InCharge7 (on Windows), but you cannot change the location under the root directory.

The EMC Smarts System Administration Guide provides detailed information about the directory structure for EMC Smarts software.

EMC Smarts MPLSManagement Suite

products

The EMC Smarts MPLS Management Suite includes the following products:

◆ EMC Smarts MPLS Manager

◆ EMC Smarts Adapter for Cisco ISC

◆ EMC Smarts VPN-Tagging Server

Relateddocumentation

In addition to this document, EMC Corporation provides a Help system for command line programs and product documentation.


Preface

Help for command line programsDescriptions of command line programs are available as HTML pages. The index.html file, which provides an index to the various commands, is located in the BASEDIR/smarts/doc/html/usage directory.

EMC Smarts documentationReaders of this guide may find the following related documentation helpful. These documents can be found in the BASEDIR/smarts/doc/pdf directory:

Note: These documents are updated periodically. Electronic versions of the updated manuals are available on the Powerlink website:http://Powerlink.EMC.com

◆ EMC Smarts Documentation Catalog

◆ EMC Smarts System Administration Guide

◆ EMC Smarts ICIM Reference

◆ EMC Smarts Common Information Model Infrastructure Models Chart

◆ EMC Smarts Common Information Model Application/Business Models Chart

◆ EMC Smarts ASL Reference Guide

◆ EMC Smarts Perl Reference Guide

◆ EMC Smarts Dynamic Modeling Tutorial

◆ EMC Smarts MODEL Reference Guide

EMC Smarts MPLS Management Suite documentationThe following documents are relevant to users of the EMC Smarts MPLS Management Suite:

◆ EMC Smarts MPLS Management Suite Release Notes

◆ EMC Smarts MPLS Management Suite Installation Guide

◆ EMC Smarts MPLS Management Suite Third-Party Copyright Read Me

◆ EMC Smarts MPLS Manager Configuration Guide

◆ EMC Smarts MPLS Manager Discovery Guide

◆ EMC Smarts MPLS Manager User Guide

◆ EMC Smarts Adapter for Cisco ISC User Guide

Suggestions forsearching PDF files

You may search across multiple PDF files by using the Adobe Acrobat Reader software:

1. If the documentation is not accessible to all users of the EMC Smarts product suite, copy the contents of the BASEDIR/smarts/doc/pdf directory to a central location, such as a shared drive on your LAN, so that operators and others can view the documentation.

2. To search throughout the documentation library, open the Acrobat Reader software:

a. Select Edit > Search, and type a word or phrase.

b. Select All PDF Documents in, in the Where would you like to search option, and type the pathname of the location where the PDF documents reside.

If you have more than one EMC Smarts product suite installed, you can set up cross-product document searches by copying files from the

http://Powerlink.EMC.com


Preface

BASEDIR/smarts/doc/pdf directory for each product suite into this common documentation directory path.

Conventions used inthis document

EMC uses the following conventions for special notices.

Note: A note presents information that is important, but not hazard-related.

CAUTION!A caution contains information essential to avoid data loss or damage to the system or equipment.

IMPORTANT!An important notice contains information essential to software or hardware operation.

Typographical conventionsEMC uses the following type style conventions in this document:

Pathname conventionsDirectory pathnames are shown with forward slashes (/). Users of the Windows operating systems should substitute back slashes (\) for forward slashes.

Normal Used in running (nonprocedural) text for:• Names of interface elements (such as names of windows, dialog boxes, buttons,

fields, and menus)• Names of resources, attributes, pools, Boolean expressions, buttons, DQL

statements, keywords, clauses, environment variables, functions, utilities• URLs, pathnames, filenames, directory names, computer names, filenames, links,

groups, service keys, file systems, notifications

Bold Used in procedures for:• Names of interface elements (such as names of windows, dialog boxes, buttons,

fields, and menus)• What user specifically selects, clicks, presses, or types

Italic Used in text for:• Full titles of publications referenced in text• Emphasis (for example a new term)

Courier Used for:• System output, such as an error message or script • URLs, complete paths, filenames, prompts, and syntax when shown outside of

running text

Courier bold Used for:• Specific user input (such as commands)

Courier italic Used in procedures for:• Variables on command line• User input variables

< > Angle brackets enclose parameter or variable values supplied by the user

[ ] Square brackets enclose optional values

| Vertical bar indicates alternate selections - the bar means “or”

{ } Braces indicate content that you must specify (that is, x or y or z)

... Ellipses indicate nonessential information omitted from the example


Preface

Graphical conventionsThe figures that illustrate consoles represent the consoles as they appear in Windows. Under UNIX, the consoles appear with slight differences. For example, in views that display items in a tree hierarchy such as the Topology Browser, a plus sign appears for Windows and an open circle appears for UNIX.

Smarts ManagerUnless otherwise specified, the term Smarts Manager is used to refer to EMC Smarts programs such as Domain Managers, Global Managers, and adapters.

Where to get help EMC support, product, and licensing information can be obtained as follows.

Product information- For documentation, release notes, software updates, or for information about EMC products, licensing, and service, go to the EMC Powerlink website (registration required) at:


Technical support- For technical support, go to EMC Customer Service on Powerlink. To open a service request through Powerlink, you must have a valid support agreement. Please contact your EMC sales representative for details about obtaining a valid support agreement or to answer any questions about your account.

Your comments Your suggestions will help us continue to improve the accuracy, organization, and overall quality of the user publications. Please send your opinion of this document to:

[email protected]

If you have issues, comments, or questions about specific information or procedures, please include the title and, if available, the part number, the revision (for example, A01), the page numbers, and any other details that will help us locate the subject you are addressing.


Discovery Overview 13

1

This chapter introduces EMC Smarts MPLS Manager and describes the concepts of using MPLS Manager to discover MPLS and VPN topology. It consists of the following sections:

◆ Terminology .................................................................................................................... 14◆ LSP support..................................................................................................................... 15◆ VPN support ................................................................................................................... 16◆ Device support................................................................................................................ 17◆ SNMP and CLI discovery support .............................................................................. 18◆ Overlapping IP address support.................................................................................. 19◆ VPN-Tagging Server support ....................................................................................... 19◆ Multi-VRF CE support .................................................................................................. 19◆ Discovery overview ....................................................................................................... 20◆ IP Availability Manager discovery .............................................................................. 22◆ MPLS Topology Server discovery................................................................................ 23◆ When discovery occurs ................................................................................................. 28

Discovery Overview


Discovery Overview

TerminologyEMC® Smarts® MPLS Manager is an EMC Smarts Domain Manager. A Domain Manager is a service-assurance application that is associated with a particular type of information-technology domain, such as networks, systems, applications, or application services. For MPLS Manager, the domain is the Multiprotocol Label Switching (MPLS) network and the MPLS virtual private network (VPN). Each Domain Manager is autonomous in the sense that it:

◆ Maintains its own data models, repository, and problem signatures.

◆ Monitors and analyzes the discovered objects in its own domain.

System and deviceThe term “system” is a generic term that represents a computer-based network entity, such as a host, router, or switch. The term “device” has essentially the same meaning as system except that, in some cases, “device” also conveys the sense of specific model, such as a specific model of host, router, or switch.

DiscoveryEMC Smarts discovery is the process of using EMC Smarts ICIM class models to create a representation of the managed topology within the repository, or database, of a Domain Manager. For MPLS Manager, data is collected from MPLS-enabled devices in the managed network to create instances of MPLS and VPN topology objects, their relationships, and their logical connections.

When an MPLS-enabled device is added to the managed network, MPLS Manager performs discovery on the device to determine the MPLS and VPN topology objects associated with the device. When an MPLS-enabled device is removed from the managed network and deleted from the topology, MPLS Manager removes the device and all the device’s associated MPLS and VPN topology objects from the modeled topology.

ObjectThe term “object” is intended to have a dual meaning: To simultaneously represent both (1) an instance (ICIM object) in the modeled topology and (2) an instance (physical or logical entity) in the real topology. The ICIM object corresponds to the entity in the real topology.

LSP support 15

Discovery Overview

LSP supportMPLS Manager discovers the following types of label switched paths (LSPs):

◆ Traffic engineering (TE) tunnels

◆ TE LSPs

◆ Label Distribution Protocol (LDP) LSPs

An LSP is a sequence of switch hops that together form a path that is traversed by labeled packets across an MPLS network.

TE tunnelsTE tunnels are virtual paths between headend and tailend routing devices in an MPLS network. The routing devices may be Provider Edge (PE) or Provider (P) devices. A TE tunnel is associated with one or more TE LSPs.

MPLS Manager is able to discover the following types of TE tunnels:

◆ Link- and node-protected TE tunnels

MPLS Manager discovers the primary and backup TE LSPs for TE tunnels that have been configured for link and node protection.

◆ Path-protected TE tunnels

MPLS Manager discovers the primary and secondary TE LSPs for TE tunnels that have been configured for path protection.

TE LSPs

Also known as tunnel LSPs, TE LSPs are constrained paths that are constructed by a signaling protocol such as Resource Reservation Protocol (RSVP-TE). RSVP-TE distributes and assigns labels, manages quality of service (QoS) issues, and handles error conditions.

LDP LSPs

Also known as generic LSPs, LDP LSPs are paths that are constructed by standard routing protocols and the Label Distribution Protocol. LDP is an MPLS signaling protocol that distributes and assigns labels within an MPLS network.

The standard routing protocols and LDP consider only the shortest path across the network when building LSPs. They do not take into account any constraints such as QoS or LSP protection.


Discovery Overview

VPN supportMPLS Manager discovers the following types of provider-provisioned VPNs:

◆ MPLS Layer 2 VPNs (L2VPNs)

◆ MPLS Layer 3 VPNs (L3VPNs)

The fundamental principles of LSPs are based on traffic separation and segmentation, which means that by design, MPLS lends itself well to the concept of VPNs.

MPLS L2VPNs

Commonly called Martini VPNs, MPLS L2VPNs extend the customer’s Layer 2 connectivity through an MPLS network by emulating different types of traditional data-link layer protocols, including Ethernet, Frame Relay, ATM, and others.

MPLS Manager is able to discover two types of L2VPN services:

◆ Virtual Private Wire Service (VPWS)

◆ Virtual Private LAN Service (VPLS)

VPWS is an L2 service that uses a pair of Martini Tunnels to emulate a point-to-point circuit across an MPLS network. VPLS is an L2 service that uses a full mesh of Martini Tunnels to emulate a LAN across an MPLS network.

In addition, MPLS Manager is able to discover the following implementations of the L2VPN services:

◆ LDP VPWS L2 services

◆ BGP VPWS and VPLS L2 services

MPLS Manager requires a Level 2 VPN feature license for the discovery of VPWS and VPLS L2 services. The EMC Smarts System Administration Guide provides information about licensing.

MPLS L3VPNsDefined by IETF RFC-2547bis, MPLS L3VPNs use extensions to the existing Internet routing protocol (BGP-4) to interconnect remote customer sites through an MPLS network. L3VPN is a virtual private routed network solution for IP data traffic only.

Central to an L3VPN is the VPN routing and forwarding (VRF) table, which allows for separate and private VPN forwarding decisions to co-exist within a PE device. The VRF is the fundamental mechanism that enables the partitioning of discrete subscribers over the shared IP routed infrastructure.

MPLS Manager requires a Level 3 VPN feature license for the discovery of L3VPNs. The EMC Smarts System Administration Guide provides information about licensing.

Device support 17

Discovery Overview

Device supportMPLS Manager supports the discovery, monitoring, and analysis of MPLS networks in any of the following vendor-specific environments:

◆ Cisco

◆ Huawei

◆ Juniper

Fully tested Cisco, Huawei, and Juniper devices

The EMC Smarts MPLS Certification Matrix identifies the Cisco, Huawei, and Juniper, devices that have been fully tested for this release of MPLS Manager. This document is found on Powerlink at http://Powerlink.EMC.com.

Device types supported

The device types supported by MPLS Manager are:

◆ Physical routers

◆ Virtual routers

◆ Router switch modules (RSMs)

◆ Router switch feature cards (RSFCs)

◆ Multilayer switch feature cards (MSFCs)

◆ Hybrids

Virtual routers are implemented within physical routers or switches.

RSMs, RSFCs, and MSFCs are device type cards in Layer 3 (network) switches. They perform routing between virtual LANs (VLANs).

Hybrids are switch devices that provide a routing capability.



Discovery Overview

SNMP and CLI discovery supportAs indicated in Table 1 on page 18, MPLS Manager supports both Simple Network Management Protocol (SNMP) discovery and command line interface (CLI)) discovery.

Table 1 Discovery sources for supported devices

Device MPLS core objects MPLS L2VPN objects MPLS L3VPN objects

Cisco MPLS-TE-MIB, MPLS-TE-STD-MIB, MPLS-LSR-MIB, and,MPLS-LSR-STD-MIBMPLS Manager uses SNMP discovery to discover MPLS objects on Cisco devices.If SNMP discovery fails or is not supported by the Cisco device, MPLS Manager uses CLI discovery to discover the MPLS objects.

CLI, CISCO-IETF-STD-MIB, MPLS-LDP-MIB, and MPLS-LDP-STD-MIBMPLS Manager uses:• CLI and SNMP discovery to

discover VPWS L2VPN objects on Cisco devices.

• SNMP discovery to discover targeted LDP objects associated with the Cisco L2VPN objects.

MPLS-VPN-MIBMPLS Manager uses SNMP discovery to discover the L3VPN objects on Cisco devices.If SNMP discovery fails or is not supported by the Cisco device, MPLS Manager uses CLI discovery to discover the L3VPN objects.

Huawei CLIMPLS Manager uses CLI discovery to discover MPLS objects on Huawei devices.

CLI and MPLS-LDP-STD-MIBMPLS Manager uses:• CLI discovery to discover

VPWS L2VPN objects on Huawei devices.

• SNMP discovery to discover targeted LDP objects associated with the Huawei L2VPN objects.

MPLS-VPN-MIBMPLS Manager uses SNMP discovery to discover L3VPN objects on Huawei devices.If SNMP discovery fails or is not supported by the Huawei device, MPLS Manager uses CLI discovery to discover the L3VPN objects.

Juniper M/T JUNIPER-MPLS-MIBMPLS Manager uses SNMP discovery to discover MPLS objects on Juniper M/T devices.If SNMP discovery fails or is not supported by the Juniper M/T device, MPLS Manager uses CLI discovery to discover the MPLS objects.

JUNIPER-VPN-MIB, JUNIPER-MPLS-LDR-MIB, and CLIMPLS Manager uses:• SNMP discovery to discover

VPWS and VPLS L2VPN objects on Juniper M/T devices.

• SNMP and CLI discovery to discover targeted LDP objects on Juniper M/T devices.

JUNIPER-VPN-MIBMPLS Manager uses SNMP discovery to discover L3VPN objects on Juniper M/T devices.If SNMP discovery fails or is not supported by the Juniper M/T device, MPLS Manager uses CLI discovery to discover the L3VPN objects.

Juniper ERX CLIMPLS Manager uses CLI discovery to discover MPLS objects on Juniper ERX devices and virtual routers.

CLIMPLS Manager uses CLI discovery to discover VPWS L2VPN objects on Juniper ERX devices and virtual routers.

CLIMPLS Manager uses CLI discovery to discover L3VPN objects on Juniper ERX devices and virtual routers.

Overlapping IP address support 19

Discovery Overview

Overlapping IP address supportMPLS Manager supports (understands) VRF IP objects and IPNetwork objects that have been tagged by IP Availability Manager.

Tagged IP and IPNetwork objects enable IP Availability Manager to discover overlapping IP addresses and store them in its modeled topology. By importing tagged IP and IPNetwork objects from IP Availability Manager, MPLS Manager is able to store overlapping IP addresses in its modeled topology.

The inclusion of overlapping IP addresses in the modeled topology results in a more accurate and more complete model of the topology, which enables IP Availability Manager and MPLS Manager to perform more accurate correlation analysis.

By default, IP Availability Manager is not enabled to perform discovery of overlapping IP addresses. The EMC Smarts MPLS Manager Configuration Guide provides instructions for enabling this feature.

VPN-Tagging Server supportThe VPN-Tagging Server assists IP Availability Manager in the creation of certain overlapping IP-address configurations. Chapter 2, ”MPLS VPN Overlapping IP Discovery,” provides information about how the VPN-Tagging Server accomplishes this task.

Multi-VRF CE supportIn addition to discovering MPLS core devices and traditional Customer Edge (CE) devices, MPLS Manager is able to discover multi-VRF CEs. These devices maintain VRF tables for the purpose of extending the privacy and security of an MPLS L3VPN from the PE device to the branch office.

In Figure 1 on page 19, for example, the multi-VRF CE maintains five VRF tables in order to provide five client organizations with their own IP address space.

Figure 1 A multi-VRF CE device deployment serving five clients

MPLS network

Client 510.1/24

Client 3

12.1/26

Client 2

11.1/16

Client 1

10.1/16

One T1 line with multiple point-to-point subinterfaces

Multi_VRF_CE

Client 4

12.1/26

Provider Edge router


Discovery Overview

The PE that is connected to the multi-VRF CE maintains the same five VRFs that the multi-VRF CE maintains. The use of a T1 line with multiple point-to-point subinterfaces enables traffic between the multi-VRF CE and the PE to be segmented into separate VRFs.

No MPLS label exchange, no LDP adjacency, and no labeled packet flow occur between a multi-VRF CE and a PE. The packets flow as IP packets between the two devices.

Client route advertisement

The multi-VRF CE learns a client’s routes from an attached interface and installs the routes into the VRF that is associated with that interface. The PE learns the client’s routes from the VRF and installs them into the related VRF on the PE.

The multi-VRF CE learns a client’s routes through a routing protocol or a static route that propagates routes from the client to the multi-VRF CE. The PE learns the routes through a routing protocol or a static route that propagates routes from a specific VRF on the multi-VRF CE to the related VRF on the PE.

Single-homed or multi-homed configurationThe multi-VRF CE in Figure 1 on page 19 is a single-homed configuration, meaning that the multi-VRF CE has VRF interface connections to just one PE. In a multi-homed configuration, the multi-VRF CE has VRF interface connections to more than one PE, with the following restriction: a VRF interface may connect to one and only one PE.

Discovery overviewAs shown in Figure 2 on page 21, MPLS Manager is split into three components, known as the MPLS Topology Server, the MPLS Monitoring Server, and the MPLS Analysis Server. As their names suggest, one component discovers the MPLS and VPN topology, one component monitors the topology for status updates, and one component analyzes the status updates to diagnose MPLS and VPN impacts. The MPLS Topology Server works with IP Availability Manager to discover the logical and physical objects in the physical-transport domain, the MPLS domain, and the VPN domain.

Discovery overview 21

Discovery Overview

Figure 2 MPLS Manager discovery

MPLS network

SNMP pollingSNMP discovery,polling, & traps

CC API Server

MPLS Monitoring Server

(administratorrole)

Topology Problems& impacts

Statusupdates

Topology

SNMP or CLIdiscovery

MPLS Manager

MPLS TopologyServer

Subset oftopology

MPLS AnalysisServer

(same host machine)

IP Availability Manager Global ManagerTopology, problems,& impacts

MPLS & network maps

(administrator roleor operator monitoring role)

GlobalConsole

CLI deviceaccess objects

Polling & remoteping objects

(attach toMPLS Topology

Server only)

Statusupdates


Discovery Overview

IP Availability Manager discoveryIn the physical-transport domain, IP Availability Manager discovers Layer 2 (data-link) and Layer 3 (network) connectivity in multivendor, switched, and routed networks. It discovers the network systems by sending them Internet Control Message Protocol (ICMP) and SNMP polls.

In an MPLS network, as shown in Figure 3 on page 22, IP Availability Manager discovers the Layer 2 and Layer 3 network object connectivity between PE, P, and CE devices.

Figure 3 Physical-transport domain discovered by IP Availability Manager

IP Availability Manager uses the discovered topology to model the network, and uses SNMP polling and traps to diagnose and pinpoint the root cause of network failures. It exports the analysis results along with topology information to the Global Manager. IP Availability Manager also exports router topology and CLI device-access objects to the MPLS Topology Server, and exports router-relevant status updates to the MPLS Monitoring Server.

The router topology exported to the MPLS Topology Server includes SNMPAgent objects, which carry SNMPv1, v2c, or v3 credential information. The SNMP credentials are required by the MPLS Topology Server for two purposes:

◆ To perform SNMP discovery

◆ To execute on-demand remote ping requests

The CLI device-access objects exported to the MPLS Topology Server carry CLI login credential information. The CLI login credentials are required by the MPLS Topology Server for two purposes:

◆ To perform CLI discovery

◆ To execute on-demand label switched path (LSP) ping requests

The EMC Smarts MPLS Manager Configuration Guide provides information about creating CLI device-access objects.

MPLS network

Customer Edge router

Provider Edge router

Provider router

Link

MPLS Topology Server discovery 23

Discovery Overview

MPLS Topology Server discoveryThe MPLS Topology Server discovers the MPLS and VPN logical topology and models (represents) that topology in its repository. It maps the MPLS and VPN topology to the router topology discovered by IP Availability Manager.

Imports routing devices from IP Availability ManagerFrom IP Availability Manager, the MPLS Topology Server imports the initial router topology and CLI device-access objects. The router topology consists of router and switch objects along with Interface, IP, IPNetwork, SNMPAgent, and other network objects associated with the router and switch objects.

Initiates discoveryAfter importing the initial router topology and CLI device-access objects from IP Availability Manager, the MPLS Topology Server uses SNMP polling and/or CLI commands to query the routing devices for MPLS and VPN topology information. If SNMP polling fails or is not supported by a device, and assuming that CLI discovery is enabled, the MPLS Topology Server logs in to the device (through Telnet, SSH1 or SSH2) and issues CLI commands to query the device for the required information.

The EMC Smarts MPLS Manager Configuration Guide provides information about enabling CLI discovery.

Performs MPLS discoveryIn the MPLS domain, shown in Figure 4 on page 23, the MPLS Topology Server discovers the LSPs that are implemented by the devices imported from IP Availability Manager.

Figure 4 MPLS domain discovered by the MPLS Topology Server

MPLS network

LSP hop

Attachment circuit

Access link

LSP


Discovery Overview

In addition to discovering generic (LDP) LSPs, the MPLS Topology Server discovers the TE tunnels and tunnel (TE) LSPs that are shown in Figure 5 on page 24, Figure 6 on page 24, and Figure 7 on page 25.

Figure 5 Network recovery through link protection

Figure 6 Network recovery through node protection

Link-protected interface

R1 R2 R5 R7 R8

MPLS network R4R3

Reroutable LSP

IngressLSP segment

EgressLSP segment

R6

TE tunnelTE tunnel

Backup TE LSPPrimary TE LSP

Node-protected interface

Reroutable LSP

R1 R2 R5

R6

R7 R8

MPLS network R4R3 EgressLSP segment

IngressLSP segment

R6

TE tunnelTE tunnel

Primary TE LSP Backup TE LSP


Discovery Overview

Figure 7 Network recovery through path protection

Performs L2VPN discoveryIn the L2VPN domain, shown in Figure 8 on page 25 and Figure 9 on page 26, the MPLS Topology Server discovers VPN objects for L2VPNs, such as VPNs, Forwarders, and PseudoWires.

Figure 8 L2VPN VPWS domain discovered by the MPLS Topology Server

Path-protectedinterfaceRa Rb Rd Rf Rg

MPLS network

ReRc

TE tunnel

Secondary TE LSPPrimary TE LSP

Forwarder Backbone tunnel (2 LSPs)

Attachment circuit Pseudowire (2 virtual circuits)

MPLS network


Discovery Overview

Figure 9 L2VPN VPLS domain discovered by the MPLS Topology Server

Performs L3VPN discovery

In the L3VPN domain, shown in Figure 10 on page 27, the MPLS Topology Server discovers VPN objects for L3VPNs, such as VPNs, VRFs, and RouteTargets.

Forwarder Backbone tunnel (2 LSPs)

Attachment circuit Pseudowire (2 virtual circuits)

MPLS network

Emulated LAN


Discovery Overview

Figure 10 L3VPN domain discovered by the MPLS Topology Server

Builds a complete modelThe MPLS Topology Server combines the discovered MPLS, L2VPN, and L3VPN objects with the physical objects discovered by IP Availability Manager, to build a complete model of the MPLS network, the VPNs, and the attached customer sites. It also exports one subset of topology objects to the MPLS Monitoring Server and another to the MPLS Analysis Server.

Logs discovery messagesWhenever a discovery cycle completes, the MPLS Topology Server prints a report to its log file. The log file is named .log (for example, INCHARGE-MPLS-TOPOLOGY.log) and is located in the BASEDIR/smarts/local/logs directory.

In addition, the MPLS Monitoring Server and the MPLS Analysis Server each have a log file in the BASEDIR/smarts/local/logs directory.

MBGP session Access link

VRF instances VRF instances

MPLS network

Spoke 2

Mesh

Full Mesh

Spoke 1

Hub

Ra Rc

Rb

Exports route target RT3Imports route target RT2RcRc

VPN 2VPN 1

Ra

Exports route target RT3Imports route target RT2Ra

Exports route target RT1Imports route target RT1

Exports route target RT2Imports route target RT3RcRbRc

Exports route target RT1Imports route target RT1

Mesh


Discovery Overview

Creates CLI log files

During a discovery cycle, the MPLS Topology Server creates a CLI log file for each device that either failed SNMP discovery or does not support SNMP discovery, or when additional information is needed for a device. Each CLI log file contains a record of the Telnet, SSH1, or SSH2 session with the particular device, and includes the CLI commands issued by the MPLS Topology Server and the responses returned by the device. The MPLS Topology Server parses the log file to create topology objects in its repository.

A CLI log file is named CLI--.txt (for example, CLI-CISCO-lab-gw.emc.com.txt). All CLI log files are located in the BASEDIR/smarts/local/logs directory.

The MPLS Topology Server overwrites the CLI log files during each successive discovery cycle.

When discovery occursThe MPLS Topology Server initiates a discovery cycle of the MPLS and VPN objects whenever:

◆ IP Availability Manager is added as a source to the MPLS Topology Server, as explained in Chapter 7, ”Preparing and Initiating Discovery.”

◆ IP Availability Manager completes a discovery cycle.

By default, each time IP Availability Manager completes a discovery cycle, the MPLS Topology Server performs a topology synchronization to import router topology information from IP Availability Manager. The MPLS Topology Server then performs its own discovery by sending SNMP polls and/or CLI commands to the routing devices to discover or rediscover MPLS and VPN objects.

◆ The MPLS Topology Server is restarted or communication is lost and then reestablished between the MPLS Topology Server and IP Availability Manager.

MPLS VPN Overlapping IP Discovery 29

2

This chapter introduces the VPN-Tagging Server and describes how the server solves the overlapping IP discovery problem. It consists of the following sections:

◆ Introducing the VPN-Tagging Server.......................................................................... 30◆ Functional overview ...................................................................................................... 32◆ Discovery in the Cisco environment ........................................................................... 33◆ Discovery in the Alcatel-Lucent environment ........................................................... 35◆ Discovery assumptions and criteria ............................................................................ 38◆ Overlapping IP naming format.................................................................................... 38◆ Configuring the VPN-Tagging Server......................................................................... 39◆ Starting the VPN-Tagging Server................................................................................. 39

MPLS VPN OverlappingIP Discovery


MPLS VPN Overlapping IP Discovery

Introducing the VPN-Tagging ServerDue to the limited number of available IPv4 addresses, private IP addresses are frequently used in MPLS L3VPN networks. In Figure 11 on page 30, for example:

◆ Router PE1 uses IP address 10.1.0.2 on its interface that is facing router CE1, which is part of customer 2’s VPN.

◆ Router PE2 uses IP address 10.1.0.2 on its interface that is facing router CE5, which is in Customer 1’s VPN.

Moreover, router PE2 has two interfaces with the same IP address, 10.5.0.2. One interface is facing router CE3, and the other is facing router CE4.

Figure 11 Example of overlapping IPs in MPLS-enabled VPNs

When a network device has two or more interfaces that share the same private IP address, known as overlapping IP addresses, IP Availability Manager cannot automatically create the related IP objects for those interfaces, and cannot correctly identify the related network connections for those interfaces.

VPN-Tagging Server purposeThe VPN-Tagging Server, an optional server in the MPLS Management Suite of products, is different than other Domain Managers in the sense that it creates no system or network instances. Its sole purpose is to solve the overlapping IP address problem for IP Availability Manager by performing MPLS VPN overlapping IP discovery.

PE1CE1

Customer 1West Site

Customer 2West Site

Customer 2East Site

MPLS network

Customer 1East Site

CE3

CE4

CE2

P1

CE5PE2

.1

Overlapping IP address

Overlapping IP address

10.5.0.0/30

PE = Provider Edge router P = Provider router

.2

CE = Customer Edge router

Introducing the VPN-Tagging Server 31


VPLS-Tagging Server assistance

By interoperating with the VPN-Tagging Server, IP Availability Manager is able to correctly represent in its repository the overlapping IP configurations shown in Figure 12 on page 31, Figure 13 on page 31, and Figure 14 on page 32.

Figure 12 IP overlapping configuration 1: separate PE-CE pairs

Figure 13 IP overlapping configuration 2: common PE, separate CEs

10.1.0.1

PE

10.1.0.2

CE

PE

10.1.0.2

CE

10.1.0.1

PE

CE

CE



Figure 14 IP overlapping configuration 3: common PE and CE, separate VRFs

Note that the CE device in configuration 3 is a multi-VRF CE. A multi-VRF CE maintains VPN routing and forwarding (VRF) tables for the purpose of extending the privacy and security of an MPLS L3VPN from the PE to the branch office. The multi-VRF CE maintains a VRF table for each interface or subinterface, to provide each client organization with its own IP address space.

Functional overviewThe VPN-Tagging Server discovers VRF-based network connections and sends the connection information to IP Availability Manager. IP Availability Manager uses the connection information to distinguish the overlapping IPs in certain VRF overlapping IP configurations.

The VPN-Tagging Server writes the discovered VRF-related information to a single instance of “IP_External” on IP Availability Manager. IP_External is an ICIM class that stores the VRF- related information as four tables, one of which is the Network Connection table.

Using the IP tag and network connection information from the Network Connection table, IP Availability Manager is able to build the correct network connections for all three overlapping IP configurations in Figure 12 on page 31, Figure 13 on page 31, and Figure 14 on page 32. For configuration 3, IP Availability Manager is limited to building only system-level network connections.

The VPN-Tagging Server performs overlapping-IP and corresponding network-connection discovery in two vendor-specific environments:

◆ Cisco

◆ Alcatel-Lucent

The VPN-Tagging Server can perform discovery in both environments at the same time.

Blue VPN

Red VPN

10.9.0.110.9.0.2

PE

Black VPN

CE

Discovery in the Cisco environment 33


Discovery in the Cisco environmentFigure 15 on page 33 shows the design architecture of MPLS VPN overlapping IP discovery in the Cisco environment.

Figure 15 VPN-Tagging Server discovery in the Cisco environment

The VPN-Tagging Server performs SNMP discovery on Cisco routers or switches to discover VRF-based network connections for the devices. When the VPN-Tagging Server discovers these connections, it sends the connection information to IP Availability Manager so that IP Availability Manager is able to distinguish overlapping IPs on the same device.

The flowchart in Figure 16 on page 34 shows how MPLS VPN overlapping IP discovery works in the Cisco environment.

Attribute:IsDiscoveryInProgress

MPLS network

SNMP pollingSNMP & CLIdiscovery

SNMP discovery(Get VRF topology)

Topology &CLI device

access objects

Statusupdates

VPN-Tagging Server MPLS Monitoring Server

MPLS TopologyServer

MPLS AnalysisServer

IP tag &connectioninformation

MPLS Manager(same host machine)

CiscoSNMPAgents

SNMP discovery,polling, & traps

IP Availability Manager

Cisco



Figure 16 MPLS VPN overlapping IP discovery flow in the Cisco environment

Overlapping IP discovery of a Cisco device is triggered by IP Availability Manager when it sets a device’s IsDiscoveryInProgress attribute to True during the course of discovering the device. The VPN-Tagging Server subscribes to IsDiscoveryInProgress attributes.

When the VPN-Tagging Server receives an IsDiscoveryInProgress attribute = True for either a Cisco router or switch, it retrieves the address of the device’s SNMP agent from IP Availability Manager and places the address in its discovery queue. It then initiates SNMP discovery on the SNMP agent, obtains the IP route-distinguisher tag and other related network connection information by querying the agent’s VRF-related MIB, and writes that information to IP Availability Manager’s Network Connection table.

Monitor IsDiscoveryInProgress attributes of devices

IP RD tag and connection information

SNMPAgent

Connection table


VPN-TaggingServer

Discoverypostprocess:Read table,

build connections,and tag IPs

No

Yes

Read VRF-relatedMIB and discoverIP RD tags and

network connections

Do nothing

VPN-Tagging Serverdiscovery queue

Vendor = Cisco?

Is IsDiscovery-InProgress = True for

Router or Switch?

Device 1Device 2

Yes No

Discovery in the Alcatel-Lucent environment 35


Discovery in the Alcatel-Lucent environmentFigure 17 on page 35 shows the design architecture of MPLS VPN overlapping IP discovery in the Alcatel-Lucent environment.

Figure 17 VPN-Tagging Server discovery in the Alcatel-Lucent environment

For simplicity, only one IP Availability Manager is shown in Figure 17. A more typical deployment would include the Topology Split Manager, which would serve two or more IP Availability Managers. The Topology Split Server is described in the EMC Smarts Topology Split Manager (64-bit) User Guide.

MPLS network

SNMP pollingSNMP & CLIdiscovery

SNMP discovery,polling, & traps

Topology& alarms

Status updates

Topology

Topology &CLI device

access objects

Statusupdates


VPN-Tagging Server

Attribute:RouteChangedLastAt

Adapter for 5620 SAM EMS

Topology& status updates

MPLS Monitoring Server

MPLS TopologyServer

MPLS AnalysisServer

Alcatel-Lucentdevice topology

IP tag &connectioninformation

MPLS Manager(same host machine)

CLI discovery request(Get VRF information)

Topology & alarms

5620 SAM EMS

CLI_pass-

through

Alcatel-Lucent



The VPN-Tagging Server sends CLI discovery requests to the EMC Smarts Adapter for Alcatel-Lucent 5620 SAM EMS (the Adapter) in an attempt to discover VRF- based network connections for Lucent-Alcatel routers or switches. When the VPN-Tagging Server discovers these connections, it sends the connection information to IP Availability Manager so that IP Availability Manager is able to distinguish overlapping IPs on the same device.

Overlapping IP discovery of Alcatel-Lucent devices is triggered in any of the following ways:

◆ When the VPN-Tagging Server starts up.

At startup, the VPN-Topology Server imports a list of Alcatel-Lucent devices from its source IP Availability Manager and performs a full discovery. The devices are identified in the Global_TopologyCollection objects that the Adapter creates in IP Availability Manager.

◆ When the VPN-Tagging Server receives, from IP Availability Manager, a DiscoveredLastAt attribute update for a Global_TopologyCollection object.

The Adapter changes the date of a global object’s DiscoveredLastAt attribute whenever the Adapter:

• Connects to IP Availability Manager and creates the global object.

• Adds new devices to the global object.

The VPN-Tagging Server subscribes to DiscoveredLastAt attributes.

◆ When the VPN-Tagging Server receives, from the Adapter, a RouteChangedLastAt attribute update for an Alcatel-Lucent device.

The Adapter sets a device’s RouteChangedLastAt attribute to a new date whenever the Adapter learns of a new or changed route for the device. The VPN-Tagging Server subscribes to RouteChangedLastAt attributes.

When the VPN-Tagging Server receives a RouteChangedLastAt attribute update for a device, it places the device in its discovery queue. During the next scheduled full-discovery interval, as defined in the BASEDIR/smarts/conf/vpn-tagging/vpn-tagging.conf file, the VPN-Tagging Server will discover the device.

When initiating a discovery of an Alcatel-Lucent device, the VPN-Tagging Server sends to the Adapter a CLI request that includes the device’s name. The Adapter executes the request and returns the output to the VPN-Tagging Server.

A CLI request contains the following CLI command:

show router route-table

The execution of the CLI command yields the IP route-distinguisher tag and other related network connection information for the target device. The VPN-Tagging Server writes that information to IP Availability Manager’s Network Connection table.

Discovery in the Alcatel-Lucent environment 37


On-demand discovery

In addition to periodic discovery, on-demand discovery of Alcatel-Lucent devices is supported. An on-demand discovery can be initiated in any of the following ways:

◆ To initiate a discovery of all the devices in the VPN-Tagging Server’s discovery queue, go to the BASEDIR/smarts/bin directory in the MPLS Manager installation area and enter either of the following commands:

dmctl -s invoke VPNTagging_Manager::VPNTagging-Manager::invoke5620SAMDiscovery

dmctl -s put VPNTagging_Manager::VPNTagging-Manager::Force5620SAMDiscovery

TRUE

◆ To initiate a discovery of all the devices in the Global_TopologyCollection objects, go to the BASEDIR/smarts/bin directory in the MPLS Manager installation area and enter the following command:

dmctl -s put VPNTagging_Manager::VPNTagging-Manager::invokeDomainDiscovery

Where may be an IP Availability Manager’s name or an Adapter’s name.

Adapter Configuration

The EMC Smarts Adapter for Alcatel-Lucent 5620 SAM EMS User Guide describes the the Adapter in detail and presents configuration procedures for the Adapter.

Configuring the connection from the Adapter to a Domain Manager, such as IP Availability Manager or the MPLS Topology Server, is achieved by setting a particular parameter in the Adapter’s emsConfig.import file. For example, setting the AMServerName parameter value to the name of an IP Availability Manager will cause the Adapter to forward to that IP Availability Manager the topology data that is expected by an IP Availability Manager.

As an aside, the Domain Manager that is receiving the topology data will set the ServiceName attribute of each received object to the name of the Adapter, to identify the Adapter as the object’s source. By doing so, any other Domain Manager that imports or is assigned these objects will be able to use the ServiceName value to subscribe to the Adapter for status updates. By this means, for example, the VPN-Topology Server is able to subscribe to the Adapter for RouteChangedLastAt attribute updates.



Discovery assumptions and criteriaMPLS VPN overlapping IP discovery is based on the following assumptions and criteria:

◆ The loopback IP address of each CE device is unique and known.

◆ The loopback IP address of each CE device must be used to advertise the route in the VRF; that is, the CE device can be identified by its loopback IP address.

◆ The Loopback IP address is not tagged by any IP tag filter that a user has created by using the IP tagging feature in IP Availability Manager.

◆ Each VRF has a route distinguisher.

IP objects of interfaces associated with a single VRF have the same 8-byte route distinguisher value. The purpose of the route distinguisher is to allow the creation of distinct routes to separate instances of the same (overlapping) IPv4 address.

◆ VRF name is unique on each single device.

◆ IP address is unique on each CE device. This assumption is not applicable to the overlapping IP configuration shown in Figure 14 on page 32. For this reason, the overlapping IP discovery feature cannot be used to build interface-level network connections between the PE and CE for the configuration in Figure 14.

Overlapping IP naming formatEMC Smarts applications require unique instance name in their repositories. The conventional IP instance naming method, which is adding a prefix "IP-" to the IP address to create the name of the instance (for example, "IP-10.0.1.14"), is not applicable for overlapping IP addresses.

The Name of an overlapping IP instance will be in the following format:

IP-/

The DisplayName attribute will be in the following format:

: [host system name]

For example, router R1 has a VRF named "red." Interface 15, which is associated with this VRF, has a duplicated IP address 10.0.1.14 and is part of the subnet 10.0.1.12/30. The route distinguisher of VRF "red" is "4445:401." The name of this IP instance will be:

IP-10.0.1.14/4445:401

And its DisplayName will be:

4445:401:10.0.1.14 [R1]

In addition, the Tag attribute of the IP instance will have a value of "4445:401."

Configuring the VPN-Tagging Server 39


Configuring the VPN-Tagging ServerBy default, the VPN-Tagging Server is configured to connect to an IP Availability Manager named INCHARGE-AM. You can edit the VPN-Tagging Server’s configuration file named vpn-tagging.conf and change this name or add one or more additional IP Availability Managers as connections to the VPN-Tagging Server.

The EMC Smarts MPLS Manager Configuration Guide describes the parameters in the vpn-tagging.conf file and provides instructions for modifying the parameters. The configuration guide also describes the parameters and provides instructions for:

◆ Enabling IP Availability Manager to discover overlapping IP addresses.

◆ Enabling IP Availability Manager to interoperate with the VPN-Tagging Server.

Starting the VPN-Tagging ServerAs a prerequisite, the VPN-Tagging Server must be started before IP Availability Manager begins its discovery.

EMC Corporation recommends installing EMC Smarts products as services. On a UNIX system, a sample command for installing the VPN-Tagging Server as a service is:

/opt/InCharge7/MPLS/smarts/bin/sm_service install'--force''--unmanaged''--startmode=runonce''--name=ic-vpn-tagging''--description=EMC Smarts VPN-Tagging Server''/opt/InCharge7/MPLS/smarts/bin/sm_server''--name=VPN-TAGGING''--config=vpn-tagging''--subscribe=default''--ignore-restore-errors''--output'

The command for starting the service is:

/opt/InCharge7/MPLS/smarts/bin/sm_service start ic-vpn-tagging

At startup, the VPN-Tagging Server reads the vpn-tagging.conf file, saves the configuration information in that file to the repository, and attempts to connect to the one or more IP Availability Managers that are specified in the file.

If an IP Availability Manager is not running, the VPN-Tagging Server will periodically attempt to connect to the IP Availability Manager.

Discovery Process 41

3

This chapter describes the types of discovery performed by MPLS Manager and explains the phases of the discovery process. It consists of the following sections:

◆ Discovery process overview ......................................................................................... 42◆ Discovery process details .............................................................................................. 44

Discovery Process


Discovery Process

Discovery process overviewDuring the discovery process, the MPLS Topology Server component of MPLS Manager uses instances of certain EMC Smarts ICIM classes to create within its repository a data model representation of the discovered MPLS and VPN topology. The various data models supported by the MPLS Topology Server are shown in Chapter 4, ”Discovery of MPLS Objects,” Chapter 5, ”Discovery of L2VPN Objects,” and Chapter 6, ”Discovery of L3VPN Objects.”

The MPLS Topology Server discovers MPLS and VPN specific objects based on the router topology initially imported from the IP Availability Manager source. The router topology consists of router and switch objects, router and switch containment objects, and router and switch connectivity objects.

CLI device-access objects are also imported from IP Availability Manager.

Upon sending SNMP polls/and or CLI commands to the routing devices to discover the MPLS and VPN topology, the MPLS Topology Server models (represents) the discovered topology in its repository, and maps the discovered MPLS and VPN topology to the router topology discovered by IP Availability Manager.

Topology information needed for monitoring and analysis is then imported from the MPLS Topology Server by the MPLS Monitoring Server and the MPLS Analysis Server. The subset of topology imported by the MPLS Monitoring Server consists of just those classes and class attributes that are related to monitoring. The subset of topology imported by the MPLS Analysis Server consists of just those classes and class attributes that are related to causality.

Discovery typesThe MPLS Topology Server performs three types of discovery:

◆ MPLS discovery

◆ L2VPN discovery

◆ L3VPN discovery

During the discovery process, all three discoveries run in parallel. During the postprocessing phase, the discovery process associates the discovered L2VPN and L3VPN topology with the discovered MPLS topology.

Summary of MPLS discoveryThe MPLS Topology Server performs the following steps to discover MPLS topology:

1. Imports initial router topology and CLI device-access objects from IP Availability Manager and adds the objects to its repository.

2. Probes the imported routing devices for MPLS information.

3. Creates in its repository instances of the discovered MPLS topology objects and the relationships between them.

4. Combines the information collected from the various probes to create additional MPLS objects and relationships between the objects in its repository.

5. Exports the routing-device and MPLS topology to the Global Manager.

6. Exports a subset of the routing-device and MPLS topology to the MPLS Monitoring Server and the MPLS Analysis Server.

Discovery process overview 43

Discovery Process

Summary of L2VPN discovery

The MPLS Topology Server performs the following steps to discover L2VPN topology:

1. Probes the imported routing devices for L2VPN information and creates common L2VPN objects, LDP L2VPN objects, BGP L2VPN objects, and their relationships in its repository.

2. Combines the information collected from the various probes to create additional L2VPN objects and relationships between the objects in its repository.

3. Creates relationships that associate the discovered L2VPN objects with the discovered MPLS objects.

4. Exports the L2VPN topology to the Global Manager.

5. Exports a subset of the L2VPN topology to the MPLS Monitoring Server and the MPLS Analysis Server.

Summary of L3VPN discovery

The MPLS Topology Server performs the following steps to discover L3VPN topology:

1. Probes the imported routing devices for L3VPN information and creates L3VPN objects and their relationships in its repository.

2. Combines the information collected from the various probes to create additional L3VPN objects and relationships between the objects in its repository.

3. Creates relationships that associate the discovered L3VPN objects with the discovered MPLS objects.

4. Exports the L3VPN topology to the Global Manager.

5. Exports a subset of the L3VPN topology to the MPLS Monitoring Server and the MPLS Analysis Server.


Discovery Process

Discovery process detailsFigure 18 on page 44 identifies the phases of discovery for adding objects to the MPLS Topology Server repository.

Figure 18 Discovery flow for the MPLS Topology Server

The discovery phases are:

1. Import initial router topology from IP Availability Manager.

2. Probe each imported device for MPLS and VPN topology information and relationships.

3. Post-process the discovery information.

Phase 2:Device probing

Add MPLS and VPNobjects to repository

End

Add additional objects, associate VPN and MPLS objects with

themselves and with underlying physical objects, and remove

stale information

Phase 3:Postprocessing

Phase 1:Import initial

router topology fromIP Availability Manager

Also import CLI device access objects

Start

Pending Elements list

Isprobing

successful?

Yes

No

Discovery process details 45

Discovery Process

Phase 1: Import initial router topology

The first phase of the discovery process is carried out by MPLS Topology Server data exchange adapter (DXA) programs that import router topology information and CLI device-access objects from IP Availability Manager. The topology-import DXA program imports instances of the following ICIM classes:

Note: The indentations in the bullet list indicate class hierarchy.

◆ Router

• VirtualRouter

• Router switch module (RSM)

• Router switch feature card (RSFC)

• Multilayer switch feature card (MSFC)

◆ Switch

◆ Chassis

◆ Card

◆ Port

◆ Interface

◆ NetworkConnection

• Cable

• TrunkCable

◆ IP

• DuplicateIP

• VPNIP

◆ IPNetwork

• VPNIPNetwork

◆ VLAN

◆ Partition

◆ AD_PersistentDataSet

◆ SNMPAgent

• VRAgent

All of these classes are described in the EMC Smarts IP Availability Manager User Guide.

The imported SNMPAgent objects have a one-to-one relationship with the imported router or switch objects: When IP Availability Manager discovers an SNMPv1, v2c, or v3 device, it also discovers the device’s SNMP agent. The SNMP credentials for a device’s access are stored in the following attributes of the device’s SNMPAgent object:

◆ ReadCommunity (SNMPv1 or v2c only)

◆ User (SNMPv3 only)

◆ AuthPass (SNMPv3 only)

◆ AuthProtocol (SNMPv3 only)


Discovery Process

◆ PrivPass (SNMPv3 only)

◆ PrivProtocol (SNMPv3 only)

◆ EngineID (SNMPv3 only)

The values defined for the User, AuthPass, AuthProtocol, PrivPass, PrivProtocol, and EngineID attributes constitute an SNMPv3 credential set. Depending on the security level, some of these attributes may be empty; for example, if the security level is "authentication only," the PrivProtocol and PrivPass attributes will be empty. Also, whenever a value is defined for AuthPass or PrivPass, that value will be encrypted.

Phase 2: Probe each managed routing device

During the second phase of the discovery process, each imported device is probed to identify MPLS and VPN topology information. At the end of the probing, instances of MPLS and VPN specific objects are created in the MPLS Topology Server repository.

During this phase of the discovery process, the MPLS Topology Server creates instances of the classes identified in Table 2 on page 46.

Table 2 Initial topology added to the MPLS Topology Server repository (page 1 of 2)

Class name Description

MPLS core objects

MPLSService A logical object that is created for each device that is discovered in the managed MPLS network.

LspTableManager A table object that holds the LSP insegment and outsegment information that is gathered from all of the PE and P devices in the managed MPLS network.

L2VPN common objects

ForwarderEndpoint A type of service access point for each Forwarder logical interface. It terminates one end of a pseudowire connection and holds, from an endpoint's point of view, the status of the pseudowire connection.

L2VPN LDP-specific objects

LdpProtocolEndpoint A type of service access point for one end of a Label Distribution Protocol adjacency. It represents one of two LDP peers that are responsible for exchanging the virtual circuit identifiers (VC IDs) for an LDP L2VPN. The LDP peers reside on PE devices that may be multiple hops apart.

L2VPN BGP-specific objects

VRF A VPN routing and forwarding instance, maintained by a PE device, that contains the routing information that defines a customer Layer 2 VPN site.

RouteTarget A logical entity that identifies a set of customer VPN sites to which a PE device distributes routes. It is used to set up peering relationships between the VRF instances that belong to the same Layer 2 VPN.


Discovery Process

The probing of topology is accomplished by using the drivers in the .import files, which are located in the BASEDIR/smarts/conf/mpls-t directory of the MPLS Manager installation area. Seven representative .import files are:

◆ DISCOVERY.import

◆ DISCOVERY_CUSTOM.import

◆ CLI.import

◆ CLI_Huawei.import

◆ CLI_Juniper6.import

◆ CLI_ERX7.import

◆ CLI_ERX.import

The main drivers for SNMP and CLI discovery are identified in the DISCOVERY.import and CLIxxx.import files. Custom drivers, also known as discovery hook scripts, are identified in the DISCOVERY_CUSTOM.import file.

The main drivers performs preprocessing tasks (such as recording the time that discovery begins), launch the SNMP and CLI discovery, and perform postprocessing tasks.

SNMP discovery

For SNMP discovery, the drivers use SNMP to query certain MIB objects on Cisco, Huawei, and Juniper M/T devices for MPLS, VPN, and relationship information. One SNMP discovery probe instance is started for each device. Appendix A, “MIBs Accessed for Discovery and Remote Ping,” provides a description of the discovery MIB objects polled by an SNMP discovery probe.

Note: The MPLS Topology Server uses a synchronous, multithreaded SNMP discovery probe. SNMP discovery may run in as many as 10 concurrent threads.

L3VPN objects

VRF A VPN routing and forwarding instance, maintained by a PE device, that contains the routing information that defines a customer Layer 3 VPN site.

RouteTarget A logical entity that identifies a set of customer VPN sites to which a PE device distributes routes. It is used to set up peering relationships between the VRF instances that belong to the same Layer 3 VPN.

Table 2 Initial topology added to the MPLS Topology Server repository (page 2 of 2)



Discovery Process

The SNMPVersion attribute of a device’s SNMPAgent determines whether a probe sends an SNMPv1, v2, or v3 request to the device.

◆ If SNMPVersion is V1, the SNMP discovery probe creates and sends an SNMPv1 request that includes the SNMP credential specified in the SNMPAgent’s ReadCommunity attribute.

◆ If SNMPVersion is V2C, the SNMP discovery probe creates and sends an SNMPv2 request that includes the SNMP credential specified in the SNMPAgent’s ReadCommunity attribute.

◆ If SNMPVersion is V3, the SNMP discovery probe creates and sends an SNMPv3 request that includes the SNMP credentials specified in the SNMPAgent’s User, AuthPass, AuthProtocol, PrivPass, PrivProtocol, and EngineID attributes.

For an AuthPass or PrivPass attribute value, the probe uses the “site key” to decrypt a copy of the value just before it creates and sends the SNMPv3 request. As explained in the EMC Smarts System Administration Guide, the site key is created during the installation of EMC Smarts applications.

If the probing of a device is successful, the MPLS Topology Server creates an object for each discovered MPLS or VPN component and places the objects in its repository. If the probing is not successful, the MPLS Topology Server places the name of the probed device on the Pending Elements list. Chapter 8, ”Understanding Discovery Results,” provides information about discovery errors and the Pending Elements list.

CLI discovery

If SNMP discovery fails or is not supported by a Cisco, Huawei, or Juniper M/T device, or if additional information is needed for a device, the drivers invoke CLI commands to query the device for MPLS, VPN, and relationship information.

To discover MPLS information for Huawei devices, or to discover MPLS, L2VPN, and L3VPN information for Juniper ERX devices, the drivers invoke CLI commands exclusively to gather the required information.

One CLI discovery session is started for each device. Appendix B, “CLI Commands Invoked for Discovery and LSP Ping,” provides a description of the commands invoked by a CLI discovery session.

A CLI discovery session uses the appropriate CLI device-access object to access a device through the Telnet, SSH1, or SSH2 protocol. The session uses the “site key” to decrypt a copy of the user password in the CLI device-access object just before the session attempts to access the device. As explained in the EMC Smarts System Administration Guide, the site key is created during the installation of EMC Smarts applications.

If the probing of a device is successful, the MPLS Topology Server creates an object for each discovered MPLS or VPN component and places the objects in its repository. If the probing is not successful, the MPLS Topology Server places the name of the probed device on the Pending Elements list. Chapter 8, ”Understanding Discovery Results,” provides information about discovery errors and the Pending Elements list.


Discovery Process

Phase 3: Post-process the discovery information

During the postprocessing phase of discovery, the information that is collected from the various probes is consolidated to create additional logical objects in the repository. The information is also used to create connected relationships between the objects.

The postprocessing basic functions include:

◆ Creating LdpAdjacency connections between neighboring LdpProtocolEndpoints.

◆ Creating PseudoWire connections between neighboring ForwarderEndpoints.

◆ Creating Forwarders based on ForwarderEndpoints.

◆ Creating VPNs based on VRFs, RouteTargets, Forwarders, ForwarderEndpoints, and PseudoWires.

◆ Creating TE tunnels, tunnel LSPs, generic LSPs, and LSPHops based on entries in the LSPTableManager.

◆ Mapping VRFs, Forwarders, ForwarderEndpoints, and PseudoWires to the appropriate LSPs and layering the VRFs, Forwarders, ForwarderEndpoints, and PseudoWires over the LSPs.

◆ Creating relationships between the MPLS and VPN objects and the network objects imported from IP Availability Manager, such as the LayeredOver relationships that link LSPHops to the network connections that are underlying the LSPHops.

◆ Removing (pruning) stale objects and relationships from the repository.

◆ Setting the DisplayNames for the discovered objects.

◆ Printing a discovery report to the MPLS Topology Server’s log file.

Table 3 on page 49 identifies the additional objects created by the MPLS Topology Server during the postprocessing phase of discovery.

Table 3 Additional topology added to the MPLS Topology Server repository (page 1 of 2)


MPLS core objects

LSP A concatenation of LSPHops that represents the label-switched path taken by labeled packets across an MPLS network.

LSPHop A unidirectional logical link between two devices in an MPLS network across which MPLS-labeled packets are sent. No label processing occurs over the logical link.

L2VPN objects

Forwarder A logical entity within a PE device that makes switching and forwarding decisions for L2VPNs.

PseudoWire A bidirectional virtual connection that, in the MPLS environment, is carried over a pair of LSPs and is terminated by a pair of ForwarderEndpoints and bound to a pair of Forwarders.


Discovery Process

For any device placed on the Pending Elements list during the discovery, the MPLS Topology Server will attempt to discover that device during the next pending discovery. Pending discovery is described in Chapter 9, ”Invoking Full or Pending Discovery.”

VPN A collection of Forwarder, ForwarderEndpoint, and PseudoWire instances (and, for BGP L2VPNs, VRF instances), configured on PE devices in the MPLS network, that are members of the same virtual private network.

L2VPN LDP-specific objects

LdpAdjacency A logical connection that represents a targeted LDP session between LDP peers that are responsible for exchanging the VC IDs for an LDP L2VPN. The LDP peers reside on PE devices that may be multiple hops apart.

L3VPN objects

VPN A collection of VPN routing and forwarding (VRF) instances, configured on PE devices in the MPLS network, that are members of the same virtual private network.

Table 3 Additional topology added to the MPLS Topology Server repository (page 2 of 2)


Discovery of MPLS Objects 51

4

This chapter describes the MPLS discovery performed by MPLS Manager. It consists of the following sections:

◆ MPLS discovery overview ............................................................................................ 52◆ MPLS TE tunnel discovery ........................................................................................... 53◆ MPLS discovery process................................................................................................ 56

Discovery of MPLSObjects


Discovery of MPLS Objects

MPLS discovery overviewFor MPLS discovery, the MPLS Topology Server component of MPLS Manager is able to discover and model the following MPLS entities:

◆ TE tunnels and tunnel LSPs

Discovers traffic-engineered tunnels and associates backup or secondary tunnel LSPs with primary tunnel LSPs; applicable to TE tunnels that are built on Cisco or Juniper M/T devices.

◆ Generic LSPs

Discovers any combination of tunnel LSPs and generic LSPs in the managed network.

◆ Inter-AS LSPs

Discovers multi-stacked-label generic LSPs that span multiple autonomous systems; applicable to inter-AS LSPs that are built on Juniper M/T devices.

◆ Multi-vendor LSPs

Discovers tunnel LSPs and generic LSPs that are built on a mixture of multi-vendor devices.

◆ LSP load balancing

Discovers multi-path load balancing for generic LSPs on Juniper M/T devices; disabled by default.

◆ LDP adjacencies

Discovers targeted LDP adjacencies for Cisco, Huawei, and Juniper M/T devices.

◆ PE and P devices

Discovers PE and P devices that are implemented on any of the P- or PE-capable devices that are supported by MPLS Manager.

◆ CE and multi-VRF CE devices

Discovers traditional CE devices that are implemented on any of the CE-capable devices that are supported by MPLS Manager.

Discovers multi-VRF CE devices that are implemented on any of the multi-VRF CE capable Cisco devices that are supported by MPLS Manager.

All discovery features except the discovery of LSP load balancing are enabled by default. The EMC Smarts MPLS Manager Configuration Guide describes how to enable this feature. The enabling parameter is “EnableLoadBalancingLSP” in the BASEDIR/smarts/conf/mpls-t/mpls.conf file.

MPLS TE tunnel discovery 53

Discovery of MPLS Objects

LSP rediscovery

An LSP might reroute upon physical failure or reconfiguration. When an LSP reroutes, the MPLS Topology Server is able to detect the reroute and to rediscover the LSP, without the need to perform a full discovery.

Automated LSP rediscovery is supported for tunnel LSPs. By default, automated LSP rediscovery is disabled. The EMC Smarts MPLS Manager Configuration Guide describes how to use the Polling and Thresholds Console to enable this feature. The enabling polling group is “LSP SNMP Setting.”

PE-PE LSP discovery

By default, LSP discovery operates as follows:

◆ For a managed MPLS network that consists of Cisco and/or Juniper M/T devices, the MPLS Topology Server will discover every TE tunnel, tunnel LSP, and generic LSP in the network.

◆ For a managed MPLS network that consists of Huawei and/or Juniper ERX devices, the MPLS Topology Serve

EMC Smarts MPLS Manager · EMC Corporation Corporate Headquarters: Hopkinton, MA 01748-9103...

Documents

Transcript of EMC Smarts MPLS Manager · EMC Corporation Corporate Headquarters: Hopkinton, MA 01748-9103...