EMC Ionix MPLS Manager

Transcription

1 EMC Ionix MPS Manager Version 9.0 Discovery Guide P/N REV A01

2 Copyright EMC Corporation. All rights reserved. Published in the USA. Published December, 2011 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. EMC 2, EMC, EMC Centera, EMC ControlCenter, EMC ifeine, EMC OnCourse, EMC Proven, EMC Snap, EMC SourceOne, EMC Storage Administrator, Acartus, Access ogix, AdvantEdge, AlphaStor, ApplicationXtender, ArchiveXtender, Atmos, Authentica, Authentic Problems, Automated Resource Manager, AutoStart, AutoSwap, AVAONidm, Avamar, Captiva, Catalog Solution, C-Clip, Celerra, Celerra Replicator, Centera, CenterStage, CentraStar, ClaimPack, ClaimsEditor, CARiiON, ClientPak, Codebook Correlation Technology, Common Information Model, Configuration Intelligence, Connectrix, CopyCross, CopyPoint, CX, Dantz, Data Domain, DatabaseXtender, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, Document Sciences, Documentum, elnput, E-ab, Xaminer, Xtender, Enginuity, eroom, Event Explorer, FarPoint, FirstPass, FARE, FormWare, Geosynchrony, Global File Virtualization, Graphic Visualization, Greenplum, HighRoad, HomeBase, InfoMover, Infoscape, InputAccel, InputAccel Express, Invista, Ionix, ISIS, Max Retriever, MediaStor, MirrorView, Navisphere, NetWorker, OnAlert, OpenScale, PixTools, Powerlink, PowerPath, PowerSnap, QuickScan, Rainfinity, RepliCare, RepliStor, ResourcePak, Retrospect, RSA, Safeine, SAN Advisor, SAN Copy, SAN Manager, Smarts, SnapImage, SnapSure, SnapView, SRDF, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix, Symmetrix DMX, Symmetrix VMAX, TimeFinder, UltraFlex, UltraPoint, UltraScale, Unisphere, Viewlets, Virtual Matrix, Virtual Matrix Architecture, Virtual Provisioning, VisualSAN, VisualSRM, VMAX, VNX, VNXe, Voyence, VPEX, VSAM-Assist, WebXtender, xpression, xpresso, YottaYotta, the EMC logo, and the RSA logo, are registered trademarks or trademarks of EMC Corporation in the United States and other countries. Vblock is a trademark of EMC Corporation in the United States. All other trademarks used herein are the property of their respective owners. For the most up-to-date regulatory document for your product line, go to the technical documentation and advisories section on the EMC online support website. 2 EMC Ionix MPS Manager Version 9.0 Discovery Guide

3 CONTENTS Preface Chapter 1 Discovery Overview Terminology System and device Discovery Object SP support TE tunnels TE SPs P2MP SPs subsps DP SPs VPN support MPS 2VPNs MPS 3VPNs DP adjacency and RSVP session support Device support SNMP and CI discovery support Overlapping IP address support MPS VPN-Tagging Server support Multi-VRF CE support Client route advertisement Single-homed or multi-homed configuration Multicast VPN support P2MP SPs and subsps Inclusive and selective P2MP SPs Discovered multicast topology BGP support Metro Ethernet support Discovery overview IP Availability Manager discovery MPS Topology Server discovery Imports topology from IP Availability Manager Initiates discovery Performs MPS discovery Performs 2VPN discovery Performs 3VPN discovery Builds a complete model ogs discovery messages Creates CI log files When discovery occurs How discovery is conducted Initial discovery Subsequent discovery Use cases for discovery EMC Ionix MPS Manager Version 9.0 Discovery Guide 3

4 Contents Chapter 2 Chapter 3 Chapter 4 Chapter 5 MPS VPN Overlapping IP Discovery Introducing the MPS VPN-Tagging Server MPS VPN-Tagging Server purpose MPS VPN-Tagging Server assistance Functional overview Discovery in the Cisco environment Discovery in the Alcatel-ucent environment On-demand discovery Adapter Configuration Discovery assumptions and criteria Overlapping IP naming format Configuring the MPS VPN-Tagging Server Starting the MPS VPN-Tagging Server Discovery Process Discovery process overview Discovery types Summary of MPS discovery Summary of 2VPN discovery Summary of 3VPN discovery Summary of BGP discovery Discovery process details Phase 1: Import initial topology Phase 2: Probe each managed device Phase 3: Post-process the discovery information Discovery of MPS Objects MPS discovery overview More about SPs and SP discovery TE tunnels and TE SPs P2MP SPs and subsps DP SPs SP discovery More about DP adjacencies and DP adjacency discovery More about RSVP sessions and RSVP session discovery MPS discovery process SNMP and CI discovery Per-device discovery for MPS Postprocessing discovery for MPS Relationships between the MPS and transport models Discovery of 2VPN Objects 2VPN discovery overview More about 2VPNs and 2VPN discovery VPN encapsulation Virtual private wire service Virtual private AN service VPN discovery More about targeted DP adjacencies and DP adjacency discovery EMC Ionix MPS Manager Version 9.0 Discovery Guide

5 Contents More about EVC over MPS discovery EVC endpoints and EVCs EVC endpoint discovery EVC discovery VPN discovery process SNMP and CI discovery Per-device discovery for 2VPN Postprocessing discovery for 2VPN Relationships between the 2VPN, MPS, and transport models Chapter 6 Chapter 7 Chapter 8 Chapter 9 Discovery of 3VPN Objects 3VPN discovery overview More about 3VPNs and 3VPN discovery Unicast 3VPN data plane Multicast 3VPN data plane VPN encapsulation VPN components VPN discovery VPN discovery process SNMP and CI discovery Per-device discovery for 3VPN Postprocessing discovery for 3VPN Relationships between the 3VPN, MPS, and transport models Discovery of BGP Objects BGP discovery overview Associating BGP sessions with MPS 3VPNs Resynchronizing BGP topologies BGP discovery details Preparing and Initiating Discovery Preparing for discovery Prepare the Global Manager for discovery Prepare IP Availability Manager for discovery Prepare MPS Manager for discovery Initiating discovery Synchronizing with IP Availability Manager Topology synchronization CI device-access object synchronization Synchronizing with the MPS Topology Server MPS Monitoring Server synchronization MPS Analysis Server synchronization Imported topology subsets Other synchronizations for the MPS Monitoring Server Specifying a different IP Availability Manager source Procedure for specifying a different IP Availability Manager source Understanding Discovery Results Discovery results Successful discovery Unsuccessful discovery EMC Ionix MPS Manager Version 9.0 Discovery Guide 5

6 Contents Discovery error resolutions Open the Domain Manager Administration Console Check the Discovery Progress window Check the server log files Check the CI log files Error message formatting Examples of error messages in CI log files Pending Elements list Information provided by the Pending Elements list Management of individual pending element entries Chapter 10 Appendix A Appendix B Appendix C Using Full or Pending Discovery Discovery methods Full discovery Automatic full discovery Manual full discovery Pending discovery Automatic pending discovery Manual pending discovery MIBs Accessed for Discovery and Remote Ping SNMP versions supported MIBs accessed for MPS discovery MIBs accessed for 2VPN discovery MIBs accessed for 3VPN discovery MIBs accessed for BGP discovery MIBs accessed for remote ping CI Commands Invoked for Discovery and SP Ping CI commands overview CI commands invoked on Cisco devices CI commands invoked on Huawei devices CI commands invoked on Juniper M/T devices CI commands invoked on Juniper ERX devices CI commands invoked for SP ping Manually Stitching EVCs to PseudoWires Overview Syntax of entries in pw-evc.conf Creating entries for pw-evc.conf Adding entries to pw-evc.conf Index 6 EMC Ionix MPS Manager Version 9.0 Discovery Guide

7 FIGURES Title Page 1 MPS VPN implementations DP adjacencies and RSVP sessions A multi-vrf CE device deployment that serves five clients A P2MP SP with two destinations Ethernet-MPS-Ethernet Metro Ethernet network MPS Only Metro Ethernet network MPS Manager discovery Data transfer between components in an MPS Manager deployment Physical-transport domain discovered by IP Availability Manager MPS domain discovered by the MPS Topology Server Network recovery through link protection Network recovery through node protection Network recovery through path protection VPWS 2VPN domain discovered by the MPS Topology Server VPS 2VPN domain discovered by the MPS Topology Server Unicast 3VPN domain discovered by the MPS Topology Server Multicast 3VPN domain discovered by the MPS Topology Server Example of overlapping IPs in MPS-enabled VPNs IP overlapping configuration 1: separate PE-CE pairs IP overlapping configuration 2: common PE, separate CEs IP overlapping configuration 3: common PE and CE, separate VRFs MPS VPN-Tagging Server discovery in the Cisco environment MPS VPN overlapping IP discovery flow in the Cisco environment MPS VPN-Tagging Server discovery in the Alcatel-ucent environment Discovery flow for the MPS Topology Server MPS encapsulation and transport FRR switching for a failed link FRR switching for a failed node Path-protection switching for a failed TE tunnel Non-targeted DP adjacencies RSVP session SP modeling in MPS data model Non-targeted DP adjacency modeling in MPS data model RSVP session modeling in MPS data model The SP table manager and SP discovery Relationships for the link/node and path-protected TE tunnel examples Relationships between the MPS and transport models MPS 2VPN encapsulation and transport Using VPWS to connect customer sites over an MPS network Using VPS to connect customer sites over an MPS network Discovering a VPWS instance that is configured with SP protection Targeted DP adjacency Key components of an E-M-E Metro Ethernet network Key components of an MPS Only Metro Ethernet network EP versus EVP DP-signaled 2VPN data model BGP-signaled 2VPN data model VAN modeling in the 2VPN data model EVC modeling in the 2VPN data model (E-M-E Metro Ethernet network) EVC modeling in the 2VPN data model (MPS Only Metro Ethernet network) EMC Ionix MPS Manager Version 9.0 Discovery Guide 7

8 Figures 51 Relationships between the DP-signaled 2VPN, MPS, and transport models Relationships between the BGP-signaled 2VPN, MPS, and transport models MPS 3VPN encapsulation and transport Using unicast 3VPNs to connect sites over an MPS network Using multicast 3VPNs to connect sites over an MPS network VPN data model Multicast VPN modeling in the 3VPN data model Relationships between the 3VPN, MPS, and transport models BGP data model Topology subsets imported by the MPS Monitoring and Analysis Servers Attach Manager dialog box Domain Manager Administration Console EMC Ionix exception message formatting Pending Elements list containing one pending element EVC-endpoint-to-pseudowire path in an E-M-E network EMC Ionix MPS Manager Version 9.0 Discovery Guide

9 TABES Title Page 1 Discovery sources for supported devices Initial topology added to the MPS Topology Server repository Additional topology added to the MPS Topology Server repository Discovery sources for MPS SPs Discovery sources for MPS DP adjacencies and RSVP sessions Device type definitions MPSService relationship set Discovery sources for MPS DP- and BGP-signaled 2VPNs Discovery sources for MPS 3VPNs Some EMC Ionix subsystems and their descriptions MIB objects accessed for MPS discovery MIB objects accessed for 2VPN discovery MIB objects accessed for 3VPN discovery MIB objects accessed for BGP discovery MIBs access for remote ping CI commands for discovery on Cisco devices CI commands for discovery on Huawei devices CI commands for discovery on Juniper M/T devices CI commands for discovery on Juniper ERX devices EMC Ionix MPS Manager Version 9.0 Discovery Guide 9

10 Tableses 10 EMC Ionix MPS Manager Version 9.0 Discovery Guide

11 PREFACE As part of an effort to improve its product lines, EMC periodically releases revisions of its software and hardware. Therefore, some functions described in this document might not be supported by all versions of the software or hardware currently in use. The product release notes provide the most up-to-date information on product features. Contact your EMC representative if a product does not function properly or does not function as described in this document. Note: This document was accurate at publication time. New versions of this document might be released on the EMC online support website. Check the EMC online support website to ensure that you are using the latest version of this document. Purpose Audience This document describes the EMC Ionix MPS Manager discovery process and presents procedures for preparing and initiating MPS Manager for discovery. This document is part of the EMC Ionix MPS Management Suite documentation set. It is intended for IT managers who are seeking to understand how the MPS Manager discovery process works, and for system administrators who are responsible for the administration, configuration, or use of MPS Manager. EMC Ionix MPS Management Suite installation directory In this document, the term BASEDIR represents the location where EMC Ionix software is installed: For UNIX, this location is: /opt/incharge/<productsuite>. For Windows, this location is: C:\InCharge\<productsuite>. EMC Ionix MPS Management Suite products The <productsuite> represents the EMC Ionix product suite to which the product belongs. For example, on UNIX operating systems, EMC Ionix MPS Management Suite is, by default, installed to /opt/incharge/mps/smarts. On Windows operating systems, this product is, by default, installed to C:\InCharge\MPS\smarts. This location is referred to as BASEDIR/smarts. Optionally, you can specify the root of BASEDIR to be something other than /opt/incharge (on UNIX) or C:\InCharge (on Windows), but you cannot change the <productsuite> location under the root directory. The EMC Ionix ITOps System Administration Guide provides detailed information about the directory structure for EMC Ionix software. The EMC Ionix MPS Management Suite includes the following products: EMC Ionix MPS Manager EMC Ionix Adapter for Cisco ISC EMC Ionix MPS VPN-Tagging Server EMC Ionix Adapter for Cisco ISC Version 9.0 User Guide 11

12 Preface Related documentation In addition to this document, EMC Corporation provides a Help system for command line programs as well as product documentation. Help for command line programs Descriptions of command line programs are available as HTM pages. The index.html file, which provides an index to the various commands, is located in the BASEDIR/smarts/doc/html/usage directory. EMC Ionix documentation Readers of this guide may find the following related documentation helpful. These documents are updated periodically. Electronic versions of the updated manuals are available on the EMC online support website: EMC Ionix ITOps Documentation Catalog EMC Ionix ITOps System Administration Guide EMC Ionix ITOps ICIM Reference EMC Ionix ITOps AS Reference Guide EMC Ionix ITOps Perl Reference Guide EMC Ionix ITOps MODE Reference Guide EMC Ionix MPS Management Suite documentation The following documents are relevant to users of the EMC Ionix MPS Management Suite: EMC Ionix MPS Management Suite Release Notes EMC Ionix MPS Management Suite Installation Guide EMC Ionix MPS Manager Configuration Guide EMC Ionix MPS Manager Discovery Guide EMC Ionix MPS Manager User Guide EMC Ionix Adapter for Cisco ISC User Guide EMC Ionix MPS Certification Matrix EMC Ionix MPS Management Suite Powerlink and Documentation Updates EMC Ionix MPS Management Suite Documentation Portfolio 12 EMC Ionix Adapter for Cisco ISC Version 9.0 User Guide

13 Preface Conventions used in this document EMC uses the following conventions for special notices: DANGER indicates a hazardous situation which, if not avoided, will result in death or serious injury. WARNING indicates a hazardous situation which, if not avoided, could result in death or serious injury. CAUTION, used with the safety alert symbol, indicates a hazardous situation which, if not avoided, could result in minor or moderate injury. NOTICE is used to address practices not related to personal injury. Note: A note presents information that is important, but not hazard-related. IMPORTANT An important notice contains information essential to software or hardware operation. Typographical conventions EMC uses the following type style conventions in this document: 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, DQ statements, keywords, clauses, environment variables, functions, and utilities URs, pathnames, filenames, directory names, computer names, links, groups, service keys, file systems, and notifications Bold Used in running (nonprocedural) text for names of commands, daemons, options, programs, processes, services, applications, utilities, kernels, notifications, system calls, and man pages Used in procedures for: Names of interface elements, such as names of windows, dialog boxes, buttons, fields, and menus What the user specifically selects, clicks, presses, or types Italic Used in all text (including procedures) for: Full titles of publications referenced in text Emphasis, for example, a new term Variables EMC Ionix Adapter for Cisco ISC Version 9.0 User Guide 13

14 Preface Courier Courier bold Courier italic Used for: System output, such as an error message or script URs, complete paths, filenames, prompts, and syntax when shown outside of running text Used for specific user input, such as commands Used in procedures for: Variables on the 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 enclose content that the user must specify, such as x or y or z... Ellipses indicate nonessential information omitted from the example Where to get help EMC support, product, and licensing information can be obtained as follows: Product information For documentation, release notes, software updates, or information about EMC products, licensing, and service, go to the EMC online support website (registration required) at: Technical support For technical support, go to EMC online support and select Support. On the Support page, you will see several options, including one to create a service request. Note that to open a service request, you must have a valid support agreement. Contact your EMC sales representative for details about obtaining a valid support agreement or with questions about your account. Your comments Your suggestions will help us continue to improve the accuracy, organization, and overall quality of the user publications. Send your opinions of this document to: [email protected] 14 EMC Ionix Adapter for Cisco ISC Version 9.0 User Guide

15 CHAPTER 1 Discovery Overview This chapter introduces EMC Ionix MPS Manager and describes the concepts of using MPS Manager to discover MPS and VPN topology. It consists of the following sections: Terminology SP support VPN support DP adjacency and RSVP session support Device support SNMP and CI discovery support Overlapping IP address support MPS VPN-Tagging Server support Multi-VRF CE support Multicast VPN support BGP support Metro Ethernet support Discovery overview IP Availability Manager discovery MPS Topology Server discovery When discovery occurs How discovery is conducted Discovery Overview 15

16 Discovery Overview Terminology EMC Ionix MPS Manager is an EMC Ionix 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 MPS Manager, the domain is the Multiprotocol abel Switching (MPS) network and the MPS 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 device The 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. Discovery EMC Ionix discovery is the process of using EMC Ionix object class models to create a representation of the managed topology within the repository, or database, of a Domain Manager. For MPS Manager, data is collected from MPS-enabled devices in the managed network to create instances of MPS and VPN topology objects, their relationships, and their logical connections. When an MPS-enabled device is added to the managed network, MPS Manager performs discovery on the device to determine the MPS and VPN topology objects that are associated with the device. When an MPS-enabled device is removed from the managed network and deleted from the topology, MPS Manager removes the device and all the device s associated MPS and VPN topology objects from the modeled topology. Object The term object is intended to have a dual meaning: To simultaneously represent both (1) an EMC Ionix object in the modeled topology and (2) a physical or logical entity in the real topology. An EMC Ionix object corresponds to a physical or logical entity in the real topology. 16 EMC Ionix MPS Manager Version 9.0 Discovery Guide

17 Discovery Overview SP support MPS Manager discovers the following types of label switched paths (SPs): Traffic engineering (TE) tunnels TE SPs Point-to-multipoint (P2MP) SPs subsps abel Distribution Protocol (DP) SPs An SP is a sequence of switch hops that together form a path that is traversed by labeled packets across an MPS network. TE tunnels TE tunnels are point-to-point virtual paths between headend and tailend routing devices in an MPS network. The routing devices may be Provider Edge (PE) or Provider (P) devices. A TE tunnel is associated with one or more TE SPs. MPS Manager discovers the following types of TE tunnels: ink- and node-protected TE tunnels MPS Manager discovers the primary and backup TE SPs for TE tunnels that have been configured for link and node protection. Path-protected TE tunnels MPS Manager discovers the primary and secondary TE SPs for TE tunnels that have been configured for path protection. TE SPs Also known as tunnel SPs, TE SPs are constrained paths that are constructed by a signaling protocol such as Resource Reservation Protocol with TE extensions (RSVP-TE). RSVP-TE distributes and assigns labels, manages quality of service (QoS) issues, and handles error conditions. P2MP SPs Also known as P-tunnels, P2MP SPs are point-to-multipoint virtual paths between headend and tailend routing devices in an MPS network. The routing devices are PE devices. A P2MP SP is associated with two or more subsps. subsps Also known as source-to-leaf (S2) sub-sps, subsps are constrained paths that are constructed by the RSVP-TE signaling protocol. SP support 17

18 Discovery Overview DP SPs Also known as generic SPs, DP SPs are paths that are constructed by standard routing protocols and the abel Distribution Protocol. DP is an MPS signaling protocol that distributes and assigns labels within an MPS network. The standard routing protocols and DP consider only the shortest path across the network when building SPs. They do not take into account any constraints such as QoS or SP protection. VPN support MPS Manager discovers the MPS provider-provisioned VPNs that are identified in Figure 1 on page 18. MPS VPNs ayer 2 VPNs ayer 3 VPNs VPWS VPS DP-signaled VPWS BGP-signaled VPWS DP-signaled VPS BGP-signaled VPS RFC 2547bis VPN Figure 1 MPS VPN implementations The fundamental principles of MPS SPs are based on traffic separation and segmentation, which means that by design, MPS lends itself well to the concept of VPNs. MPS 2VPNs Commonly called Martini VPNs, ayer 2 VPNs (2VPNs) extend the customer s ayer 2 connectivity through an MPS network by emulating different types of traditional data-link layer protocols, including Ethernet, Frame Relay, ATM, and others. MPS Manager discovers two types of 2VPN services: Virtual private wire service (VPWS) Virtual private AN service (VPS) 18 EMC Ionix MPS Manager Version 9.0 Discovery Guide

19 Discovery Overview VPWS is an 2 service that uses a pair of Martini Tunnels to emulate a point-to-point circuit across an MPS network. VPS is an 2 service that uses a full mesh of Martini Tunnels to emulate a AN across an MPS network. In addition, MPS Manager discovers the following implementations of the 2VPN services: DP-signaled VPWS and VPS The signaling protocol for DP-signaled 2VPNs is abel Distribution Protocol. BGP-signaled VPWS and VPS The signaling protocol for BGP-signaled 2VPNs is Multiprotocol Border Gateway Protocol, also known as BGPv4. MPS Manager requires a evel 2 VPN feature license for the discovery of VPWS and VPS 2 services. The EMC Ionix ITOps System Administration Guide provides information about licensing. MPS 3VPNs Defined by IETF RFC-2547bis and RFC-4364, ayer 3 VPNs (3VPNs) use extensions to the existing Internet routing protocol BGPv4 to interconnect remote customer sites through an MPS network. 3VPN is a virtual private routed network solution for IP data traffic only. Central to an 3VPN 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 individual customers over the shared IP routed infrastructure. MPS Manager requires a evel 3 VPN feature license for the discovery of 3VPNs. VPN support 19

20 Discovery Overview DP adjacency and RSVP session support MPS Manager discovers the adjacencies and sessions that are identified in Figure 2 on page 20. Three non-targeted DP adjacencies PE P P PE DP SP A. Non-targeted DP adjacencies Targeted DP adjacency PE P P PE B. Targeted DP adjacency Pseudowire (two SPs) RSVP session PE P P PE C. RSVP session TE SP Figure 2 DP adjacencies and RSVP sessions where: Non-targeted DP adjacencies are sessions between peer DP speakers, on directly connected PE or P devices, that are used to construct DP SPs. Targeted DP adjacencies are sessions between peer DP speakers, on PE devices, that are used to construct bidirectional SP paths for DP-signaled 2VPNs. The bidirectional SP paths are known as pseudowires. RSVP sessions are sessions between peer RSVP-TE speakers, on PE or P devices, that are used to construct TE SPs. RSVP sessions are also sessions between peer RSVP-TE speakers, on PE devices, that are used to construct subsps. 20 EMC Ionix MPS Manager Version 9.0 Discovery Guide

21 Discovery Overview Device support MPS Manager supports the discovery, monitoring, and analysis of MPS networks in any of the following vendor-specific environments: Cisco Huawei Juniper The EMC Ionix MPS Certification Matrix identifies the Cisco, Huawei, and Juniper devices that have been tested for this release of MPS Manager. SNMP and CI discovery support MPS Manager uses both Simple Network Management Protocol (SNMP) and command line interface (CI) to perform discovery on the supported devices in the managed MPS network. MPS Manager supports IPv4 SNMP; SNMPv1, v2c, and v3; and Telnet and Secure Shell (SSH) CI. Table 1 on page 21 shows the discovery sources for the supported devices. Table 1 Discovery sources for supported devices (page 1 of 3) Device/platform MPS objects 1 MPS 2VPN objects 1 MPS 3VPN objects 1 Cisco IOS MPS-TE-MIB, MPS-SR-MIB, MPS-DP-MIB, and CI MPS Manager uses: SNMP discovery to discover TE tunnel and TE SP objects on Cisco IOS devices. CI discovery to discover nested link/node protected TE tunnel objects on Cisco IOS devices. SNMP discovery to discover DP SP objects on Cisco IOS devices. If SNMP discovery fails or is not supported by the Cisco IOS device, MPS Manager uses CI discovery to discover the DP SP objects. SNMP discovery to discover non-targeted DP adjacency objects on Cisco IOS devices. CI discovery to discover RSVP session objects on Cisco IOS devices. CISCO-IETF-PW-MIB, CISCO-IETF-PW-MPS-MIB, MPS-DP-MIB, and CI MPS Manager uses: SNMP discovery to discover DP VPWS objects on Cisco IOS devices. CI discovery to discover DP VPS objects on Cisco IOS devices. CI discovery to discover VAN objects that are associated with the Cisco IOS VPWS and VPS objects. SNMP discovery to discover targeted DP adjacency objects that are associated with the Cisco IOS VPWS and VPS objects. MPS-VPN-MIB MPS Manager uses SNMP discovery to discover 3VPN objects on Cisco IOS devices. If SNMP discovery fails or is not supported by the Cisco IOS device, MPS Manager uses CI discovery to discover the 3VPN objects. 1 SNMP-discovered objects are monitored for status, but CI-discovered objects are not. Device support 21

22 Discovery Overview Table 1 Discovery sources for supported devices (page 2 of 3) Device/platform MPS objects 1 MPS 2VPN objects 1 MPS 3VPN objects 1 Cisco IOX MPS-TE-STD-MIB, MPS-SR-STD-MIB, and CI MPS Manager uses: SNMP and CI discovery to discover TE tunnel and TE SP objects on Cisco IOX devices. SNMP discovery to discover DP SP objects on Cisco IOX devices. If SNMP discovery fails or is not supported by the Cisco IOX device, MPS Manager uses CI discovery to discover the DP SP objects. CISCO-IETF-PW-MIB, CISCO-IETF-PW-MPS-MIB, MPS-DP-STD-MIB, and CI MPS Manager uses: SNMP discovery to discover DP VPWS and VPS objects on Cisco IOX devices. CI discovery to discover VAN objects that are associated with the Cisco IOX VPWS and VPS objects. SNMP discovery to discover targeted DP adjacency objects that are associated with the Cisco IOX VPWS and VPS objects. MPS-3VPN-STD-MIB MPS Manager uses SNMP discovery to discover 3VPN objects on Cisco IOX devices. Huawei CI MPS Manager uses CI discovery to discover DP SP objects on Huawei devices. MPS-DP-STD-MIB and CI MPS Manager uses: CI discovery to discover VPWS objects on Huawei devices. CI discovery to discover VAN objects that are associated with the Huawei VPWS objects. SNMP discovery to discover targeted DP adjacency objects that are associated with the Huawei VPWS objects. MPS-VPN-MIB MPS Manager uses SNMP discovery to discover 3VPN objects on Huawei devices. If SNMP discovery fails or is not supported by the Huawei device, MPS Manager uses CI discovery to discover the 3VPN objects. 1 SNMP-discovered objects are monitored for status, but CI-discovered objects are not. 22 EMC Ionix MPS Manager Version 9.0 Discovery Guide

23 Discovery Overview Table 1 Discovery sources for supported devices (page 3 of 3) Device/platform MPS objects 1 MPS 2VPN objects 1 MPS 3VPN objects 1 Juniper M/T JUNIPER-MPS-MIB, JUNIPER-MPS-DP-MIB, JUNIPER-RSVP-MIB, and CI MPS Manager uses: SNMP and CI discovery to discover TE tunnel and TE SP objects on Juniper M/T devices. SNMP discovery to discover P2MP SP and subsp objects on Juniper M/T devices. CI discovery to discover DP SP objects on Juniper M/T devices. SNMP discovery to discover non-targeted DP adjacency objects on Juniper M/T devices. If SNMP discovery fails or is not supported by the Juniper M/T device, MPS Manager uses CI discovery to discover the non-targeted DP adjacency objects. SNMP discovery to discover RSVP session objects on Juniper M/T devices. JUNIPER-VPN-MIB, JUNIPER-MPS-DP-MIB, and CI MPS Manager uses: SNMP discovery to discover BGP VPWS and VPS objects on Juniper M/T devices. CI discovery to discover DP VPS objects on Juniper M/T devices. CI discovery to discover VAN objects that are associated with the Juniper M/T VPS objects. SNMP discovery to discover targeted DP adjacency objects that are associated with the Juniper M/T DP VPS objects. If SNMP discovery fails or is not supported by the Juniper M/T device, MPS Manager uses CI discovery to discover the targeted DP adjacency objects. JUNIPER-VPN-MIB and CI MPS Manager uses SNMP discovery to discover 3VPN objects on Juniper M/T devices. If SNMP discovery fails or is not supported by the Juniper M/T device, MPS Manager uses CI discovery to discover the 3VPN objects. MPS Manager also uses CI discovery to discover multicast groups and their relationship to P2MP SPs. Juniper ERX CI MPS Manager uses CI discovery to discover the following MPS objects on Juniper ERX devices and virtual routers: DP SP objects Non-targeted DP adjacency objects CI MPS Manager uses CI discovery to discover the following 2VPN objects on Juniper ERX devices and virtual routers: DP VPWS and VPS objects Targeted DP adjacency objects that are associated with the Juniper ERX DP VPWS and VPS objects CI MPS Manager uses CI discovery to discover 3VPN objects on Juniper ERX devices and virtual routers. 1 SNMP-discovered objects are monitored for status, but CI-discovered objects are not. SNMP and CI discovery support 23

24 Discovery Overview Overlapping IP address support MPS Manager supports (understands) VRF IP objects and IPNetwork objects that have been tagged by EMC Ionix 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, MPS 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 MPS Manager to perform more accurate correlation analysis. By default, IP Availability Manager is not enabled to perform discovery of overlapping IP addresses. The EMC Ionix MPS Manager Configuration Guide provides instructions for enabling this feature. MPS VPN-Tagging Server support Multi-VRF CE support The MPS VPN-Tagging Server assists IP Availability Manager in the creation of certain overlapping IP-address configurations. Chapter 2, MPS VPN Overlapping IP Discovery, provides information about how the MPS VPN-Tagging Server accomplishes this task. In addition to discovering MPS core devices and traditional Customer Edge (CE) devices, MPS Manager discovers multi-vrf CEs. These devices maintain VRF tables for the purpose of extending the privacy and security of an MPS 3VPN from the PE device to the branch office. In Figure 3 on page 24, for example, the multi-vrf CE maintains five VRF tables in order to provide five client organizations with their own IP address space. Client 1 Client /16 One T1 line with multiple point-to-point subinterfaces Client /16 Multi_VRF_CE MPS network /26 Client /26 Client /24 Provider Edge router Figure 3 A multi-vrf CE device deployment that serves five clients 24 EMC Ionix MPS Manager Version 9.0 Discovery Guide

25 Discovery Overview Client route advertisement The PE that is connected to the multi-vrf CE maintains five VRFs that are related to the 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 MPS label exchange, no DP 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. 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 configuration Multicast VPN support P2MP SPs and subsps The multi-vrf CE in Figure 3 on page 24 is a single-homed configuration, which means 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. In addition to discovering unicast MPS 3VPNs, as described in MPS 3VPNs on page 19, MPS Manager discovers multicast MPS 3VPNs, as defined in draft-ietf-l3vpn-2547bis-mcast and draft-ietf-l3vpn-2547bis-mcast-bgp. Specifically, MPS Manager discovers Next Generation Multicast VPNs (NG MVPNs) that are implemented on Juniper M/T Series routers running JUNOS 9.0 or higher. NG MVPN extends the 2547 unicast VPN service offering to include support for IP multicast. ike 2547 VPN unicast, NG MVPN uses BGPv4 for signaling and MPS SPs for data transport. Unlike 2547 VPN unicast, which uses point-to-point SPs, NG MVPN uses point-to-multipoint (P2MP) SPs. As shown in Figure 4 on page 26, a P2MP SP is a TE tunnel with a single source and multiple destinations. Multicast VPN support 25

26 Discovery Overview Source Ingress PE MPS network BGP session Egress PE Receiver Sender, site 1 P2MP SP CEa PEa PEb CEb Receiver A, site 2 BGP session Egress PE PEc CEc Receiver B, site 3 Multicast VPN VRF instances (3) Receiver Figure 4 A P2MP SP with two destinations A P2MP SP is composed of two or more point-to-point SPs, called subsps, which are formed between the ingress and egress PEs to form the P2MP SP. Each subsp is a separate RSVP session that is signaled end-to-end. The P2MP in Figure 4 is composed of two subsps: PEa -> P -> PEb PEa -> P -> PEc Inclusive and selective P2MP SPs A P2MP SP for an MVPN can be inclusive or selective. An inclusive P2MP SP enables a sender PE in the sender site set of an MVPN to send multicast data to all PEs that are members of that MVPN. A selective P2MP SP enables a sender PE in the sender site set of an MVPN to send multicast data to a subset of the PEs. Selective P2MP SPs are used to form multicast groups within an MVPN. A selective P2MP SP can send traffic for one multicast group, or can send traffic for several multicast groups. Each selective P2MP SP is attached to one or more multicast groups, and each multicast group is assigned a unique multicast group address in the range through inclusive. 26 EMC Ionix MPS Manager Version 9.0 Discovery Guide

27 Discovery Overview Discovered multicast topology MPS Manager discovers the following multicast topology: Multicast VPNs Modeled as instances of the MulticastVPN class Multicast groups Modeled as instances of the MulticastGroup class P2MP SPs and subsps Modeled as instances of the SP class MPS Manager discovers just enough attribute information for MulticastVPNs and MulticastGroups to be able to detect MulticastVPN and MulticastGroup impact events. The impact events are due to underlying VRF, P2MP SP, or subsp impairments. To view the draft-rosen MulticastVPNs and MulticastGroups in the managed environment, a user should include an EMC Ionix Multicast Manager in the MPS Manager deployment. Because Multicast Manager supports draft-rosen MVPNs, not NG MVPNs, it cannot discover MulticastVPNs that are built on P2MP SPs. It can, however, discover all of the MulticastGroups in the deployment, including the ones that are discovered by MPS Manager. BGP support MPS Manager works with EMC Ionix Network Protocol Manager for BGP to perform MPS-BGP cross-domain correlation. The correlation associates MPS 3VPNs with their underlying BGP sessions, which enables MPS Manager to identify and report BGP failures or misconfigurations that impact the 3VPNs. When MPS-BGP cross-domain correlation is enabled, MPS Manager discovers BGP topology and subscribes to status updates in Network Protocol Manager for BGP. It imports BGP-enabled devices from IP Availability Manager and queries the devices to discover the following BGP topology: Autonomous systems BGP services BGP protocol endpoints BGP sessions MPS Manager computes an UnderlyingVPN relationship between the discovered BGP sessions and the discovered 3VPNs, and uses the relationship to generate VPN-impacted events for failed, misconfigured, or manually disabled BGP sessions. By default, MPS Manager is not enabled to perform MPS-BGP cross-domain correlation. The EMC Ionix MPS Manager Configuration Guide provides instructions for enabling this feature. BGP support 27

28 Discovery Overview Metro Ethernet support MPS Manager works with IP Availability Manager to discover Ethernet virtual connections (EVCs) in any of the following types of Metro Ethernet networks: Ethernet-MPS-Ethernet (E-M-E) (Figure 5 on page 28) MPS Only (Figure 6 on page 29) Ethernet Only Because an Ethernet Only network contains no MPS core, an EVC in an Ethernet Only network contains no VPWS or VPS in its connection path. Customer Ethernet access MPS core Ethernet access Customer CE-VAN EVC (Implements a Metro Ethernet service) CE-VAN 802.1Q 802.1Q -or ad VPWS or VPS 802.1Q -or ad 802.1Q EVC endpoint Service provider network EVC endpoint Ethernet MPS Ethernet CE UNI U-PE PE PE U-PE UNI CE egend: 802.1Q: Ethernet VAN tagging U-PE: User-facing PE 802.1ad: Ethernet VAN double tagging VPS: Virtual private AN service CE-VAN: Customer VAN VPWS: Virtual private wire service Figure 5 Ethernet-MPS-Ethernet Metro Ethernet network 28 EMC Ionix MPS Manager Version 9.0 Discovery Guide

29 Discovery Overview Customer Service provider Customer CE-VAN EVC (Implements a Metro Ethernet service) CE-VAN 802.1Q VPWS or VPS 802.1Q EVC endpoint MPS network EVC endpoint CE UNI PE P P PE UNI CE Figure 6 MPS Only Metro Ethernet network An EVC endpoint, which is discovered by IP Availability Manager, represents the flow point where a Metro Ethernet service passes through a physical interface or port known as a user network interface (UNI). An EVC endpoint defines the instance of the service, identifies all Ethernet data and control frames that belong to the service, and provides the capability of applying the configured features to those frames. An EVC, which is discovered by MPS Manager, implements a Metro Ethernet service by providing a point-to-point or multipoint-to-multipoint connection between the EVC endpoints that belong to the service. Note: Currently, MPS Manager discovers only point-to-point EVCs. Metro Ethernet support 29

30 Discovery Overview Discovery overview As shown in Figure 7 on page 30, MPS Manager is split into three components, known as the MPS Topology Server, the MPS Monitoring Server, and the MPS Analysis Server. As their names suggest, one component discovers the MPS and VPN topology, one component monitors the topology for status updates, and one component analyzes the status updates to diagnose MPS and VPN impacts. The MPS Topology Server works with IP Availability Manager to discover the logical and physical objects in the physical-transport domain, the MPS domain, and the VPN domain. Global Console MPS & network maps Topology & notifications IP Availability Manager Topology & events Global Manager Topology Topology Events CI device access objects Status updates MPS Manager (same host machine) MPS Topology Server Subset of topology MPS Analysis Server Polling & remote ping objects Status updates MPS Monitoring Server CC API Server SNMP discovery, polling, & traps SNMP or CI discovery SNMP polling MPS network Figure 7 MPS Manager discovery 30 EMC Ionix MPS Manager Version 9.0 Discovery Guide

31 Discovery Overview Figure 8 on page 31 presents another view of the interoperability between the components in an MPS Manager deployment. Network Protocol Manager for BGP is included in the deployment only if the MPS-BGP cross-domain correlation feature is enabled. Global Manager Topology & events Topology & events Topology (Includes events for 3VPNs impacted by underlying BGP session impairments) Events MPS Topology Server Topology MPS Analysis Server IP Availability Manager MPS-enabled topology & BGP-enabled topology Topology (Discovered MPS, VPN, & BGP topology) Status updates BGP-enabled topology Status updates Status updates Network Protocol Manager for BGP (optional) BGP status updates MPS Monitoring Server Figure 8 Data transfer between components in an MPS Manager deployment As shown in Figure 8, MPS Manager imports the same BGP-enabled topology from IP Availability Manager that Network Protocol Manager for BGP imports. The two Managers perform BGP discovery independently. MPS Manager monitors the discovered BGP topology by subscribing to BGP status updates in Network Protocol Manager for BGP. IP Availability Manager discovery In the physical-transport domain, IP Availability Manager discovers ayer 2 (data-link) and ayer 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 MPS network, as shown in Figure 9 on page 32, IP Availability Manager discovers the ayer 2 and ayer 3 network object connectivity between PE, P, and CE devices. IP Availability Manager discovery 31

32 Discovery Overview MPS network Customer Edge device Provider Edge device Provider device ink Figure 9 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 MPS-relevant topology and CI device-access objects to the MPS Topology Server, and exports MPS-relevant status updates to the MPS Monitoring Server. The topology exported to the MPS Topology Server includes SNMPAgent objects, which carry SNMPv1, v2c, or v3 credential information. The SNMP credentials are required by the MPS Topology Server for two purposes: To perform SNMP discovery To execute on-demand remote ping requests The CI device-access objects exported to the MPS Topology Server carry CI login credential information. The CI login credentials are required by the MPS Topology Server for two purposes: To perform CI discovery To execute on-demand label switched path (SP) ping requests The EMC Ionix MPS Manager Configuration Guide provides information about creating CI device-access objects. 32 EMC Ionix MPS Manager Version 9.0 Discovery Guide

33 Discovery Overview MPS Topology Server discovery The MPS Topology Server discovers the MPS and VPN logical topology and models (represents) that topology in its repository. It maps the MPS and VPN topology to the network topology that is discovered by IP Availability Manager. Imports topology from IP Availability Manager Initiates discovery Performs MPS discovery From IP Availability Manager, the MPS Topology Server imports the initial topology and CI device-access objects. The topology consists of router and switch objects along with Interface, IP, IPNetwork, SNMPAgent, and other network objects that are associated with the router and switch objects. After importing the initial topology and CI device-access objects from IP Availability Manager, the MPS Topology Server uses SNMP polling and/or CI commands to query the imported devices for MPS and VPN topology information. If SNMP polling fails or is not supported by a device, the MPS Topology Server logs in to the device (through Telnet, SSH1 or SSH2) and issues CI commands to query the device for the required information. In the MPS domain, shown in Figure 10 on page 33, the MPS Topology Server discovers the SPs that are implemented by the devices that are imported from IP Availability Manager. MPS network SP hop Access link SP Figure 10 MPS domain discovered by the MPS Topology Server MPS Topology Server discovery 33

34 Discovery Overview TE tunnels and TE SPs In addition to discovering DP SPs, the MPS Topology Server discovers the TE tunnels and TE SPs that are shown in Figure 11 on page 34, Figure 12 on page 34, and Figure 13 on page 35. TE tunnel TE tunnel Ingress SP segment R3 MPS network R4 Egress SP segment R1 R2 R5 R7 R8 Reroutable SP ink-protected interface R6 Primary TE SP Backup TE SP Figure 11 Network recovery through link protection TE tunnel TE tunnel Ingress SP segment R3 MPS network R4 Egress SP segment R1 R2 R5 R7 R8 Reroutable SP Node-protected interface R6 Primary TE SP Backup TE SP Figure 12 Network recovery through node protection 34 EMC Ionix MPS Manager Version 9.0 Discovery Guide

35 Discovery Overview TE tunnel MPS network Path-protected interface Ra Rb Rd Rf Rg Rc Re Primary TE SP Secondary TE SP P2MP SPs and subsps Figure 13 Network recovery through path protection In addition to discovering TE tunnels and TE SPs, the MPS Topology Server discovers PM2P SPs and their subsps, examples of which are shown in Figure 4 on page 26. Non-targeted DP adjacencies and RSVP sessions The MPS Topology Server also discovers non-targeted DP adjacencies and RSVP sessions. Figure 2 on page 20 presents examples. A non-targeted DP adjacency provides a bidirectional signaling path through which two directly connected peering devices exchange MPS label information for the purpose of constructing, maintaining, or deleting DP SPs. An RSVP session provides a bidirectional signaling path through which two peering devices exchange MPS label information for the purpose of constructing, maintaining, or deleting TE SPs or subsps. MPS Topology Server discovery 35

36 Discovery Overview Performs 2VPN discovery In the 2VPN domain, shown in Figure 14 on page 36 and Figure 15 on page 36, the MPS Topology Server discovers VPN objects for 2VPNs, such as VPNs, Forwarders, ForwarderEndpoints, and PseudoWires. For the sake of simplicity, no ForwarderEndpoints are shown in the figures. MPS network Forwarder Backbone tunnel (2 SPs) Attachment Circuit Pseudowire (2 virtual circuits) Figure 14 VPWS 2VPN domain discovered by the MPS Topology Server MPS network AN segment (part of VAN) AN segment (part of VAN) Emulated AN AN segment (part of VAN) Forwarder Backbone tunnel (2 SPs) Attachment Circuit Pseudowire (2 virtual circuits) Figure 15 VPS 2VPN domain discovered by the MPS Topology Server 36 EMC Ionix MPS Manager Version 9.0 Discovery Guide

37 Discovery Overview Performs 3VPN discovery For DP-signaled 2VPNs, the MPS Topology Server also discovers targeted DP adjacencies. (Figure 2 on page 20 presents an example.) A targeted DP adjacency provides a bidirectional signaling path through which the peering PE devices in an DP-signaled 2VPN exchange reachability information for the purpose of constructing, advertising, maintaining, or deleting pseudowires. For BGP-signaled 2VPNs, the MPS Topology Server also discovers VRFs. In a BGP-signaled 2VPN, every customer site to which a PE device attaches is associated with a VRF. In the 3VPN domain, as shown in Figure 16 on page 37, the MPS Topology Server discovers VPN objects for unicast 3VPNs, such as VPNs, VRFs, and RouteTargets. When MPS-BGP cross-domain correlation is enabled, the MPS Topology Server also discovers the BGP session (BGPSession) objects that are underlying the VPN objects. MPS network Customer A, site 1 BGP session Customer A, site 2 CEa PEa PEb CEb BGP session Customer B, site 3 Customer B, site 4 CEd PEc CEc VPN tunnel (2 SPs) Access link VPN 1 (full-mesh) VPN 2 (full-mesh) VRF instances (2) VRF instances (2) PEa PEb Exports route target RT1 Imports route target RT1 Exports route target RT1 Imports route target RT1 PEa PEc Rc Exports route target RT2 Imports route target RT2 Exports route target RT2 Imports route target RT2 Figure 16 Unicast 3VPN domain discovered by the MPS Topology Server As shown in Figure 17 on page 38, the MPS Topology Server also discovers VPN objects for multicast 3VPNs, such as MulticastVPNs, MulticastGroups, VRFs, and RouteTargets. For the sake of simplicity, no MulticastGroups are shown in the figure. MPS Topology Server discovery 37

38 Discovery Overview Source MPS network Receiver Ingress PE BGP session Egress PE Sender, site 1 Receiver A, site 2 CEa PEa PEb CEb BGP session Egress PE PEc CEc Receiver B, site 3 P2MP SP with two subsps MulticastVPN (sender-only, receiver-only) VRF instances (3) PEa PEb PEc Rc Exports route target RT3 Imports route target RT4 Exports route target RT4 Imports route target RT3 Exports route target RT4 Imports route target RT3 Receiver Builds a complete model ogs discovery messages Figure 17 Multicast 3VPN domain discovered by the MPS Topology Server A VRF can be configured to transport unicast traffic, multicast traffic, or both. The MPS Topology Server models (represents) a VRF that transports both unicast and multicast traffic as being part of a VPN and a MulticastVPN. The MPS Topology Server combines the discovered MPS, 2VPN, and 3VPN objects with the physical objects that are discovered by IP Availability Manager, to build a complete model of the MPS network, the VPNs, and the attached customer sites. It also exports one subset of topology objects to the MPS Monitoring Server and another to the MPS Analysis Server. Whenever an MPS discovery cycle completes, the MPS Topology Server prints a report to its log file. The log file is named <MPS Topology Server name>_en_us_utf-8.log (for example, INCHARGE-MPS-TOPOOGY_en_US_UTF-8.log) and is located in the BASEDIR/smarts/local/logs directory. The EMC Ionix ITOps System Administration Guide provides information about log file naming conventions. In addition, the MPS Monitoring Server and the MPS Analysis Server each have a log file in the BASEDIR/smarts/local/logs directory. 38 EMC Ionix MPS Manager Version 9.0 Discovery Guide

39 Discovery Overview Creates CI log files During an MPS discovery cycle and by default, the MPS Topology Server creates a CI log file for each device that it attempts to discover. The log file for a device may be populated with the following: Command and response information when CI discovery of the device is successful Error information when access credentials are incorrect Failed command-response sequences when the device is being queried for a configuration that is specified for the device s certification type but is not available on the device When discovery occurs For a successful-related log file, the MPS Topology Server parses the response information in the log file to create topology objects in its repository. A CI log file is named CI-<device vendor>-<device name>.txt (for example, CI-CISCO-lab-gw.emc.com.txt). All CI log files are located in the BASEDIR/smarts/local/logs directory. The MPS Topology Server overwrites the CI log files during each successive discovery cycle. The MPS Topology Server initiates a discovery whenever: IP Availability Manager is added as a source to the MPS Topology Server, as explained in Chapter 8, Preparing and Initiating Discovery. IP Availability Manager completes a discovery cycle: an initial discovery, a full discovery, a pending discovery, or a single-device discovery. By subscribing to DiscoveredastAt attribute updates on IP Availability Manager, the MPS Topology Server becomes aware of discovery cycle completions in IP Availability Manager. The MPS Topology Server is restarted or communication is lost and then reestablished between the MPS Topology Server and IP Availability Manager. The MPS Topology Server receives a manual discovery (Discover All) request, as explained in Chapter 10, Using Full or Pending Discovery. When discovery occurs 39

40 Discovery Overview How discovery is conducted Initial discovery The MPS Topology Server imports its initial topology from IP Availability Manager in accordance to the BASEDIR/smarts/conf/mpls-t/dxa-am.conf file. Thereafter, it synchronize its topology with IP Availability Manager in accordance to the dxa-am.conf file. The dxa-am.conf file is described in the EMC Ionix MPS Manager Configuration Guide. During its initial discovery, the MPS Topology Server imports from IP Availability Manager an MPS topology collection set named MPS-System. MPS-System contains MPS-enabled router and switch devices as well as CE and other non-mps-enabled devices that connect directly to the MPS-enabled devices. The MPS-enabled devices are not differentiated from the non-mps-enabled devices. The MPS Topology Server conducts a full-scope discovery on all devices in MPS-System and learns the identity of each device during the discovery: PE P Multi-VRF CE CE Subsequent discovery A full-scope discovery uses SNMP and/or CI to discover all supported features, such as TE tunnels, SPs, VRFs, ayer 2 VPNs, and ayer 3 VPNs, to name a few. During a subsequent discovery, the MPS Topology Server conducts a full-scope discovery on PE and P devices, but does not conduct a full-scope discovery on Multi-VRF CE or CE devices. Instead, the MPS Topology Server conducts an SNMP discovery of just VRFs on Multi-VRF CE and CE devices. If the MPS-BGP cross-domain correlation feature is enabled, the MPS Topology Server also conducts an SNMP discovery of exterior BGP (ebgp) sessions on Multi-VRF CE and CE devices. Of course, as in previous releases, the MPS Topology Server performs a subsequent discovery in accordance to the following algorithm: Performs a topology synchronization with IP Availability Manager and compares the current IP Availability Manager topology with the previously imported topology. Conducts discovery only on new devices, or on known devices that have a newer discovery timestamp. For a new device or a known PE or P device that has a newer discovery timestamp, the MPS Topology Server conducts a full-scope discovery on the device. For a known Multi-VRF CE or CE device that has a newer discovery timestamp, the MPS Topology Server conducts an SNMP discovery of just VRFs on the device. 40 EMC Ionix MPS Manager Version 9.0 Discovery Guide

41 Discovery Overview Use cases for discovery Here are a few use cases that describe the discovery behavior for the MPS Topology Server. The MPS Topology Server becomes aware of topology changes in IP Availability Manager by subscribing to DiscoveredastAt attribute updates on IP Availability Manager. A new MPS-enabled or CE device is added to IP Availability Manager The MPS Topology Server performs a topology synchronization with IP Availability Manager and detects the new device. The MPS Topology Server conducts a discovery on just the newly added device. An existing MPS-enabled or CE device is deleted from IP Availability Manager The MPS Topology Server performs a topology synchronization with IP Availability Manager and removes the device and its associated objects from the MPS topology. An existing MPS-enabled or CE device is updated in IP Availability Manager The MPS Topology Server performs a topology synchronization with IP Availability Manager and conducts a discovery on just the newly updated device. How discovery is conducted 41

42 Discovery Overview 42 EMC Ionix MPS Manager Version 9.0 Discovery Guide

43 CHAPTER 2 MPS VPN Overlapping IP Discovery This chapter introduces the MPS VPN-Tagging Server and describes how the server solves the overlapping IP discovery problem. It consists of the following sections: Introducing the MPS VPN-Tagging Server Functional overview Discovery in the Cisco environment Discovery in the Alcatel-ucent environment Discovery assumptions and criteria Overlapping IP naming format Configuring the MPS VPN-Tagging Server Starting the MPS VPN-Tagging Server MPS VPN Overlapping IP Discovery 43

44 MPS VPN Overlapping IP Discovery Introducing the MPS VPN-Tagging Server Due to the limited number of available IPv4 addresses, private IP addresses are frequently used in MPS 3VPN networks. In Figure 18 on page 44, for example: Router PE1 uses IP address on its interface that is facing router CE1, which is part of customer 2 s VPN. Router PE2 uses IP address 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, One interface is facing router CE3, and the other is facing router CE4. Overlapping IP address Customer 2 East Site Customer 1 West Site CE3 MPS network CE /30.1 CE4 P1 PE2 CE5 CE1 PE1 Customer 1 East Site Customer 2 West Site Overlapping IP address CE = Customer Edge router PE = Provider Edge router P = Provider router Figure 18 Example of overlapping IPs in MPS-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. 44 EMC Ionix MPS Manager Version 9.0 Discovery Guide

45 MPS VPN Overlapping IP Discovery MPS VPN-Tagging Server purpose MPS VPN-Tagging Server assistance The MPS VPN-Tagging Server, an optional server in the MPS Management Suite of products, differs from 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 MPS VPN overlapping IP discovery. By interoperating with the MPS VPN-Tagging Server, IP Availability Manager is able to correctly represent in its repository the overlapping IP configurations that are shown in Figure 19 on page 45, Figure 20 on page 45, and Figure 21 on page CE PE CE PE Figure 19 IP overlapping configuration 1: separate PE-CE pairs CE PE CE Figure 20 IP overlapping configuration 2: common PE, separate CEs Introducing the MPS VPN-Tagging Server 45

46 MPS VPN Overlapping IP Discovery Blue VPN Black VPN CE PE Functional overview Red VPN Figure 21 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 MPS 3VPN 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. The MPS 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 MPS VPN-Tagging Server writes the discovered VRF-related information to a single instance of IP_External on IP Availability Manager. IP_External is a 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 19 on page 45, Figure 20 on page 45, and Figure 21 on page 46. For configuration 3, IP Availability Manager is limited to building only system-level network connections. The MPS VPN-Tagging Server performs overlapping-ip and corresponding network-connection discovery in two vendor-specific environments: Cisco Alcatel-ucent The MPS VPN-Tagging Server can perform discovery in both environments at the same time. 46 EMC Ionix MPS Manager Version 9.0 Discovery Guide

47 MPS VPN Overlapping IP Discovery Discovery in the Cisco environment Figure 22 on page 47 shows the design architecture of MPS VPN overlapping IP discovery in the Cisco environment. MPS Manager (same host machine) IP Availability Manager Topology & CI device access objects MPS Topology Server MPS Analysis Server Status IP tag & updates connection information Attribute: IsDiscoveryInProgress Cisco SNMPAgents MPS VPN-Tagging Server MPS Monitoring Server SNMP discovery, polling, & traps SNMP discovery (Get VRF topology) SNMP & CI discovery SNMP polling Cisco MPS network Figure 22 MPS VPN-Tagging Server discovery in the Cisco environment The MPS VPN-Tagging Server performs SNMP discovery on Cisco routers or switches to discover VRF-based network connections for the devices. When the MPS 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 23 on page 48 shows how MPS VPN overlapping IP discovery works in the Cisco environment. Discovery in the Cisco environment 47

48 MPS VPN Overlapping IP Discovery IP RD tag and connection information Network Connection table IP Availability Manager Monitor IsDiscoveryInProgress attributes of devices SNMPAgent VPN-Tagging Server Discovery postprocess: Read table, build connections, and tag IPs Is IsDiscovery- InProgress = True for Router or Switch? No Read VRF-related MIB and discover IP RD tags and network connections Yes Yes No Vendor = Cisco? Do nothing VPN-Tagging Server discovery queue Device 2 Device 1 Figure 23 MPS 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 MPS VPN-Tagging Server subscribes to IsDiscoveryInProgress attributes. When the MPS 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. 48 EMC Ionix MPS Manager Version 9.0 Discovery Guide

49 MPS VPN Overlapping IP Discovery Discovery in the Alcatel-ucent environment Figure 24 on page 49 shows the design architecture of MPS VPN overlapping IP discovery in the Alcatel-ucent environment. MPS Manager (same host machine) IP Availability Manager Topology & CI device access objects MPS Topology Server MPS Analysis Server Topology Status updates IP tag & connection information Topology & status updates Alcatel-ucent device topology MPS VPN-Tagging Server MPS Monitoring Server Attribute: RouteChangedastAt Adapter for 5620 SAM EMS CI discovery request (Get VRF topology) Status updates Topology & alarms 5620 SAM EMS CI_ passthrough Topology & alarms SNMP discovery, polling, & traps SNMP & CI discovery SNMP polling Alcatel-ucent MPS network Figure 24 MPS VPN-Tagging Server discovery in the Alcatel-ucent environment The MPS VPN-Tagging Server sends CI discovery requests to the EMC Ionix Adapter for Alcatel-ucent 5620 SAM EMS (the Adapter) in an attempt to discover VRF-based network connections for ucent-alcatel routers or switches. When the MPS 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. Discovery in the Alcatel-ucent environment 49

50 MPS VPN Overlapping IP Discovery Overlapping IP discovery of Alcatel-ucent devices is triggered in any of the following ways: When the MPS VPN-Tagging Server starts up. At startup, the MPS VPN-Tagging Server imports a list of Alcatel-ucent 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 MPS VPN-Tagging Server receives, from IP Availability Manager, a DiscoveredastAt attribute update for a Global_TopologyCollection object. The Adapter changes the date of a global object s DiscoveredastAt attribute whenever the Adapter: Connects to IP Availability Manager and creates the global object. Adds new devices to the global object. The MPS VPN-Tagging Server subscribes to DiscoveredastAt attribute updates. When the MPS VPN-Tagging Server receives, from the Adapter, a RouteChangedastAt attribute update for an Alcatel-ucent device. The Adapter sets a device s RouteChangedastAt attribute to a new date whenever the Adapter learns of a new or changed route for the device. The MPS VPN-Tagging Server subscribes to RouteChangedastAt attribute updates. When the MPS VPN-Tagging Server receives a RouteChangedastAt 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 MPS VPN-Tagging Server discovers the device. When initiating a discovery of an Alcatel-ucent device, the MPS VPN-Tagging Server sends to the Adapter a CI request that includes the device s name. The Adapter executes the request and returns the output to the MPS VPN-Tagging Server. A CI request contains the following CI command: show router <VRF name> route-table The execution of the CI command yields the IP route-distinguisher tag and other related network connection information for the target device. The MPS VPN-Tagging Server writes that information to IP Availability Manager s Network Connection table. 50 EMC Ionix MPS Manager Version 9.0 Discovery Guide

51 MPS VPN Overlapping IP Discovery On-demand discovery In addition to periodic discovery, on-demand discovery of Alcatel-ucent devices is supported. To enable the discovery of Alcatel-ucent devices, you must add the following parameter and value to the vpn-tagging.conf file: Enable5620SAMDiscovery = TRUE Configuring the MPS VPN-Tagging Server on page 53 refers to the vpn-tagging.conf file and provides information about configuring the MPS VPN-Tagging Server. An on-demand discovery can be initiated in any of the following ways: To initiate a discovery of all the devices in the MPS VPN-Tagging Server s discovery queue, go to the BASEDIR/smarts/bin directory in the MPS Management Suite installation area and enter either of the following commands: dmctl -s <MPS VPN-Tagging Server name> invoke VPNTagging_Manager::VPNTagging-Manager::invoke5620SAMDiscovery dmctl -s <MPS VPN-Tagging Server name> 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 MPS Management Suite installation area and enter the following command: dmctl -s <MPS VPN-Tagging Server name> put VPNTagging_Manager::VPNTagging-Manager::invokeDomainDiscovery <domain name> Where <domain name> may be an IP Availability Manager s name or an Adapter s name. Adapter Configuration The EMC Ionix Adapter for Alcatel-ucent 5620 SAM EMS User Guide describes 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 MPS 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 Adapter will set the ServiceName attribute of each object that it forwards to a Domain Manager 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 MPS VPN-Tagging Server is able to subscribe to the Adapter for RouteChangedastAt attribute updates. Discovery in the Alcatel-ucent environment 51

52 MPS VPN Overlapping IP Discovery Discovery assumptions and criteria MPS 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 oopback 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 that are 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 that is shown in Figure 21 on page 46. 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 21. Overlapping IP naming format EMC Ionix 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 "), is not applicable for overlapping IP addresses. The Name of an overlapping IP instance will be in the following format: IP-<IP address>/<route distinguisher> The DisplayName attribute will be in the following format: <route distinguisher>:<ip address> [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 and is part of the subnet /30. The route distinguisher of VRF red is 4445:401. The name of this IP instance will be: IP /4445:401 And its DisplayName will be: 4445:401: [R1] In addition, the Tag attribute of the IP instance will have a value of 4445: EMC Ionix MPS Manager Version 9.0 Discovery Guide

53 MPS VPN Overlapping IP Discovery Configuring the MPS VPN-Tagging Server By default, the MPS VPN-Tagging Server is configured to connect to an IP Availability Manager named INCHARGE-AM. You can edit the MPS 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 MPS VPN-Tagging Server. The EMC Ionix MPS Manager Configuration Guide describes the parameters in the vpn-tagging.conf file and provides instructions for modifying the parameters. The Configuring IP Availability Manager chapter of the configuration guide also describes these parameters and provides instructions for: Enabling IP Availability Manager to discover overlapping IP addresses. Enabling IP Availability Manager to interoperate with the MPS VPN-Tagging Server. Starting the MPS VPN-Tagging Server As a prerequisite, the MPS VPN-Tagging Server must be started before IP Availability Manager begins its discovery. EMC recommends installing EMC Ionix products as services. On a UNIX system, a sample command for installing the MPS VPN-Tagging Server as a service is: /opt/incharge/mps/smarts/bin/sm_service install --force --unmanaged --startmode=runonce --name=ic-vpn-tagging --description="emc Ionix MPS VPN-Tagging Server" /opt/incharge/mps/smarts/bin/sm_server --name=vpn-tagging --config=vpn-tagging --ignore-restore-errors --output The command for starting the service is: /opt/incharge/mps/smarts/bin/sm_service start ic-vpn-tagging At startup, the MPS 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 MPS VPN-Tagging Server will periodically attempt to connect to the IP Availability Manager. Configuring the MPS VPN-Tagging Server 53

54 MPS VPN Overlapping IP Discovery 54 EMC Ionix MPS Manager Version 9.0 Discovery Guide

55 CHAPTER 3 Discovery Process This chapter describes the types of discovery that are performed by MPS Manager and explains the phases of the discovery process. It consists of the following sections: Discovery process overview Discovery process details Discovery Process 55

56 Discovery Process Discovery process overview During the discovery process, the MPS Topology Server component of MPS Manager uses instances of certain EMC Ionix object classes to create within its repository a data model representation of the discovered MPS, VPN, and (optional) BGP topology. The various data models that are supported by the MPS Topology Server are shown in: Chapter 4, Discovery of MPS Objects Chapter 5, Discovery of 2VPN Objects Chapter 6, Discovery of 3VPN Objects Chapter 7, Discovery of BGP Objects The MPS Topology Server discovers MPS-, VPN-, and BGP-specific objects in accordance to the topology that is initially imported from the IP Availability Manager source. The imported topology consists of router and switch objects, router and switch containment objects, and router and switch connectivity objects. CI device-access objects are also imported from IP Availability Manager. Upon sending SNMP polls/and or CI commands to the imported devices to discover the MPS, VPN, and BGP topology, the MPS Topology Server models (represents) the discovered topology in its repository, and maps the discovered topology to the router and switch topology that is discovered by IP Availability Manager. Topology information that is needed for monitoring and analysis is then imported from the MPS Topology Server by the MPS Monitoring Server and the MPS Analysis Server. The subset of topology that is imported by the MPS Monitoring Server consists of just those classes and class attributes that are related to monitoring. The subset of topology that is imported by the MPS Analysis Server consists of just those classes and class attributes that are related to causality. 56 EMC Ionix MPS Manager Version 9.0 Discovery Guide

57 Discovery Process Discovery types The MPS Topology Server performs the following types of discovery: MPS discovery 2VPN discovery 3VPN discovery BGP discovery (optional) Summary of MPS discovery Summary of 2VPN discovery During the discovery process, the first three discoveries and the optional BGP discovery run in parallel. During the postprocessing phase, the discovery process (1) associates the discovered 2VPN and 3VPN topology with the discovered MPS topology and (2) associates the discovered 3VPN topology with the discovered BGP topology if MPS-BGP cross-domain correlation is enabled. The MPS Topology Server performs the following steps to discover MPS topology: 1. Imports initial topology and CI device-access objects from IP Availability Manager and adds the data to its repository. 2. Probes the imported MPS-relevant router and switch devices for MPS topology information (such as SP hops) and creates MPS objects and their relationships in its repository. 3. Combines the information that is collected from the various probes to create additional MPS objects and relationships. 4. Exports the device and MPS topology to the Global Manager. 5. Exports a subset of the device and MPS topology to the MPS Monitoring Server and the MPS Analysis Server. The MPS Topology Server performs the following steps to discover 2VPN topology: 1. Probes the imported MPS-relevant router and switch devices for 2VPN topology information and creates 2VPN objects and their relationships in its repository. 2. Combines the information that is collected from the various probes to create additional 2VPN objects and relationships. 3. Creates relationships that associate the discovered 2VPN objects with the discovered MPS objects. 4. Exports the 2VPN topology to the Global Manager. 5. Exports a subset of the 2VPN topology to the MPS Monitoring Server and the MPS Analysis Server. Discovery process overview 57

58 Discovery Process Summary of 3VPN discovery Summary of BGP discovery The MPS Topology Server performs the following steps to discover 3VPN topology: 1. Probes the imported MPS-relevant router and switch devices for 3VPN topology information and creates 3VPN objects and their relationships in its repository. 2. Combines the information that is collected from the various probes to create additional 3VPN objects and relationships. 3. Creates relationships that associate the discovered 3VPN objects with the discovered MPS objects. 4. Exports the 3VPN topology to the Global Manager. 5. Exports a subset of the 3VPN topology to the MPS Monitoring Server and the MPS Analysis Server. The MPS Topology Server performs the following steps to discover BGP topology: 1. Probes the imported BGP-relevant router and switch devices for BGP topology information and creates BGP objects and their relationships in its repository. 2. Combines the information that is collected from the various probes to create additional BGP objects and relationships. 3. Creates relationships that associate the discovered BGP objects with the discovered 3VPN objects. 4. Exports the BGP topology to the Global Manager. 5. Exports a subset of the BGP topology to the MPS Monitoring Server and the MPS Analysis Server. 58 EMC Ionix MPS Manager Version 9.0 Discovery Guide

59 Discovery Process Discovery process details Figure 25 on page 59 identifies the phases of discovery for adding objects to the MPS Topology Server repository. Start Phase 1: Import initial topology from IP Availability Manager Also import CI device-access objects Phase 2: Device probing Is probing successful? Yes No Pending Elements list Add MPS, VPN, and (optional) BGP objects to repository Yes Any more devices *? No * Phase 3 occurs after all devices have been probed. Phase 3: Postprocessing Add additional objects, associate VPN, MPS, and BGP objects with themselves and with underlying physical objects, and remove stale information End Figure 25 Discovery flow for the MPS Topology Server Discovery process details 59

60 Discovery Process The discovery phases are: Phase 1: Import initial topology 1. Import initial topology from IP Availability Manager. 2. Probe each imported device for MPS, VPN, and (optional) BGP topology information and relationships. 3. Post-process the discovery information. The first phase of the discovery process is carried out by MPS Topology Server data exchange adapter (DXA) programs that import topology and CI device-access objects from IP Availability Manager. The topology-import DXA program imports instances of the following EMC Ionix object classes: Note: The indentations in the bullet list indicate class hierarchy. Router Switch BGP_TopologyCollection Chassis IP IPNetwork Interface Card Port NetworkConnection Cable TrunkCable AD_PersistentDataSet EVCEndPoint SNMPAgent 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) 60 EMC Ionix MPS Manager Version 9.0 Discovery Guide

61 Discovery Process PrivPass (SNMPv3 only) PrivProtocol (SNMPv3 only) EngineID (SNMPv3 only) Phase 2: Probe each managed device The values that are 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. During the second phase of the discovery process, each imported router or switch is probed to identify MPS, VPN, and (optional) BGP topology information. At the end of the probing, instances of MPS-, VPN-, and BGP-specific objects are created in the MPS Topology Server repository. During this phase of the discovery process, the MPS Topology Server creates instances of the classes that are identified in Table 2 on page 61. Table 2 Initial topology added to the MPS Topology Server repository (page 1 of 2) Class name Description MPS objects MPSService SP table manager (represents a collection of SP table manager objects) dpprotocolendpoint (in the MPS signaling and control plane) 1 RsvpProtocolEndpoint A logical object that is created for each device that is discovered in the managed MPS network. A collection of SP table manager objects that hold the SP-related information that is gathered from all of the PE and P devices in the managed MPS network. A type of service access point for one end of a abel Distribution Protocol adjacency. It represents one of two DP peers that are responsible for exchanging the MPS labels for an DP SP. The DP peers reside on PE or P devices that are one hop apart. A type of service access point for one end of a Resource Reservation Protocol session. It represents one of two RSVP-TE peers that are responsible for exchanging the MPS labels for a TE SP or subsp. The RSVP-TE peers reside on PE or P devices that may be multiple hops apart. 2VPN 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. 1 The MPS signaling and control plane is entirely separate from the VPN control plane. Discovery process details 61

62 Discovery Process Table 2 Initial topology added to the MPS Topology Server repository (page 2 of 2) Class name Description 2VPN DP-specific objects dpprotocolendpoint (in the VPN control plane) 1 A type of service access point for one end of a abel Distribution Protocol adjacency. It represents one of two DP peers that are responsible for exchanging the virtual circuit identifiers (VC IDs) for an DP-signaled 2VPN. The DP peers reside on PE devices that may be multiple hops apart. 2VPN BGP-specific objects VRF RouteTarget A VPN routing and forwarding instance, maintained by a PE device, that contains the routing information that defines a customer 2VPN site. 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 2VPN. 3VPN objects VRF RouteTarget A VPN routing and forwarding instance, maintained by a PE device, that contains the routing information that defines a customer 3VPN site. 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 3VPN. BGP objects AutonomousSystem BGPService BGPProtocolEndpoint A routing-protocol domain that consists of one or more devices that are running BGP services. A BGP protocol process that is running on a device. A type of service access point that is defined for each BGP physical interface on the BGP device. 1 The MPS signaling and control plane is entirely separate from the VPN control plane. 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 MPS Management Suite installation area. Eleven representative.import files are: DISCOVERY.import DISCOVERY_CUSTOM.import SP.import MPSVPN.import MBGP.import CI.import CI_ERX.import 62 EMC Ionix MPS Manager Version 9.0 Discovery Guide

63 Discovery Process CI_ERX7.import CI_Huawei.import CI_IOX35.import CI_Juniper6.import The main drivers for SNMP and CI discovery are identified in the DISCOVERY.import, SP.import, MPSVPN.import, MBGP.import, and CI_xxx.import files. Custom drivers, also known as discovery hook scripts, are identified in the DISCOVERY_CUSTOM.import file. The main drivers perform preprocessing tasks (such as recording the time that discovery begins), launch the SNMP and CI 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 MPS, VPN, and relationship information. The drivers also query certain MIB objects on Cisco and Juniper M/T devices for BGP 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 that are polled by an SNMP discovery probe. Note: The MPS Topology Server uses a synchronous, multithreaded SNMP discovery probe. SNMP discovery may run in as many as 10 concurrent threads. 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 that is 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 that is 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 that are 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 Ionix ITOps System Administration Guide, the site key is created during the installation of EMC Ionix applications. If the probing of a device is successful, the MPS Topology Server creates an object for each discovered MPS, VPN, or BGP component and places the objects in its repository. If the probing is not successful, the MPS Topology Server places the name of the probed device on the Pending Elements list. Chapter 9, Understanding Discovery Results, provides information about discovery errors and the Pending Elements list. Discovery process details 63

64 Discovery Process CI 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 CI commands to query the device for MPS, VPN, BGP, and relationship information. To discover MPS information for Huawei devices, or to discover MPS, 2VPN, and 3VPN information for Juniper ERX devices, the drivers invoke CI commands exclusively to gather the required information. One CI discovery session is started for each device. Appendix B, CI Commands Invoked for Discovery and SP Ping, provides a description of the commands that are invoked by a CI discovery session. A CI discovery session uses the appropriate CI 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 CI device-access object just before the session attempts to access the device. As explained in the EMC Ionix ITOps System Administration Guide, the site key is created during the installation of EMC Ionix applications. If the probing of a device is successful, the MPS Topology Server creates an object for each discovered MPS, VPN, or BGP component and places the objects in its repository. If the probing is not successful, the MPS Topology Server places the name of the probed device on the Pending Elements list. Chapter 9, Understanding Discovery Results, provides information about discovery errors and the Pending Elements list. 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 dpadjacency connections between peering dpprotocolendpoints. Creating RsvpSession connections between peering RsvpProtocolEndpoints. Creating PseudoWire connections between peering ForwarderEndpoints. Creating BGPSession connections between peering BGPProtocolEndpoints. Creating TE tunnels, TE SPs, P2MP SPs, subsps, DP SPs, and SPHops based on entries in the SP table manager. Creating Forwarders based on ForwarderEndpoints. Creating VPNs based on VRFs, RouteTargets, Forwarders, ForwarderEndpoints, and PseudoWires. Creating VANs and associating them with the appropriate Ethernet-VAN VPWS or VPS instances. Creating Ethernet virtual connections (EVCs) for each group of EVC endpoints that belong to the same Metro Ethernet service. 64 EMC Ionix MPS Manager Version 9.0 Discovery Guide

65 Discovery Process Mapping VRFs, Forwarders, ForwarderEndpoints, and PseudoWires to the appropriate SPs and layering the VRFs, Forwarders, ForwarderEndpoints, and PseudoWires over the SPs. Creating relationships between the MPS, VPN, and BGP objects and the network objects that are imported from IP Availability Manager, such as the ayeredover relationships that link SPHops to the network connections that are underlying the SPHops. Removing (pruning) stale objects and relationships from the repository. Setting the DisplayNames for the discovered objects. Printing a discovery report to the MPS Topology Server s log file. Table 3 on page 65 identifies the additional objects that are created by the MPS Topology Server during the postprocessing phase of discovery. Table 3 Additional topology added to the MPS Topology Server repository (page 1 of 2) Class name Description MPS objects SP SPHop A TE tunnel, TE SP, P2MP SP, subsp, or DP SP. For a TE SP, subsp, or DP SP, an SP is a concatenation of SPHops that represents the label-switched path that is taken by labeled packets across an MPS network. A unidirectional logical link between two devices in an MPS network across which MPS-labeled packets are sent. No label processing occurs over the logical link. dpadjacency (in the MPS signaling and control plane) 1 A logical connection that represents an DP session between DP peers that are responsible for exchanging the MPS labels for an DP SP. The DP peers reside on PE or P devices that are one hop apart. RsvpSession A logical connection that represents an RSVP session between RSVP-TE peers that are responsible for exchanging the MPS labels for a TE SP or subsp. The RSVP-TE peers reside on PE or P devices that may be multiple hops apart. 2VPN objects Forwarder PseudoWire A logical entity within a PE device that makes switching and forwarding decisions for 2VPNs. A bidirectional virtual connection that, in the MPS environment, is carried over a pair of SPs and is terminated by a pair of ForwarderEndpoints and bound to a pair of Forwarders. 1 The MPS signaling and control plane is entirely separate from the VPN control plane. Discovery process details 65

66 Discovery Process Table 3 Additional topology added to the MPS Topology Server repository (page 2 of 2) Class name VPN VAN Description A collection of Forwarder, ForwarderEndpoint, and PseudoWire instances (and, for BGP-signaled 2VPNs, VRF instances), configured on PE devices in the MPS network, that are members of the same virtual private network. A virtual AN that is associated with an Ethernet-VAN VPWS or a VPS. 2VPN DP-specific objects dpadjacency (in the VPN control plane) 1 A logical connection that represents a targeted DP session between DP peers that are responsible for exchanging the VC IDs for an DP-signaled 2VPN. The DP peers reside on PE devices that may be multiple hops apart. EVC objects EVC A logical point-to-point or multipoint-to-multipoint connection between the EVC endpoints that belong to the same Metro Ethernet service. 3VPN objects VPN MulticastVPN MulticastGroup A collection of VRF instances, configured on PE devices in the MPS network, that are members of the same unicast VPN. A collection of VRF instances, configured on PE devices in the MPS network, that are members of the same multicast VPN. A collection of multicast senders and receivers in a multicast VPN that provides an IP multigroup address (in the range to inclusive) for sending information to multiple recipients. BGP objects BGPSession A logical connection between two BGP protocol endpoints. 1 The MPS signaling and control plane is entirely separate from the VPN control plane. For any device that is placed on the Pending Elements list during the discovery, the MPS Topology Server will attempt to discover that device during the next pending discovery. Pending discovery is described in Chapter 10, Using Full or Pending Discovery. 66 EMC Ionix MPS Manager Version 9.0 Discovery Guide

67 CHAPTER 4 Discovery of MPS Objects This chapter describes how MPS Manager discovers and models MPS topology objects. It consists of the following sections: MPS discovery overview More about SPs and SP discovery More about DP adjacencies and DP adjacency discovery More about RSVP sessions and RSVP session discovery MPS discovery process Discovery of MPS Objects 67

68 Discovery of MPS Objects MPS discovery overview For MPS discovery, the MPS Topology Server component of MPS Manager is able to discover and model the following MPS entities: TE tunnels and TE SPs Discovers traffic-engineered tunnels and associates backup or secondary TE SPs with primary TE SPs; applicable to TE tunnels that are built on Cisco or Juniper M/T devices. P2MP SPs and subsps Discovers traffic-engineered point-to-multipoint (P2MP) SPs and their subsps; applicable to P2MP SPs that are built on Juniper M/T devices that are running JUNOS 9.0 or higher. DP SPs Discovers any combination of TE SPs and DP SPs in the managed network. Inter-AS SPs Discovers multi-stacked-label DP SPs that span multiple autonomous systems; applicable to inter-as SPs that are built on Juniper M/T devices. Multi-vendor SPs Discovers TE SPs and DP SPs that are built on a mixture of multi-vendor devices. SP load balancing Discovers multi-path load balancing for DP SPs on Juniper M/T devices; disabled by default. DP adjacencies Discovers non-targeted DP adjacencies for Cisco IOS and Juniper devices. RSVP sessions Discovers RSVP sessions for Cisco IOS and Juniper M/T devices. PE and P devices Discovers PE and P devices that are implemented on any of the PE- or P-capable devices that are supported by MPS 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 MPS Manager. Discovers multi-vrf CE devices that are implemented on any of the multi-vrf CE capable Cisco devices that are supported by MPS Manager. All discovery features except SP load balancing are enabled by default. The enabling parameter for SP load balancing is EnableoadBalancingSP, which is described in the EMC Ionix MPS Manager Configuration Guide. 68 EMC Ionix MPS Manager Version 9.0 Discovery Guide

69 Discovery of MPS Objects In addition, the MPS Topology Server supports the following SP discovery related features: Automated SP rediscovery Detects the reroute of TE SPs and subsequently rediscovers the TE SPs, without the need to perform a full discovery; disabled by default. The enabling polling group for this feature is SP SNMP Setting, which is described in the EMC Ionix MPS Manager Configuration Guide. Associate SP to DP More about SPs and SP discovery Creates ayeredover relationship between discovered DP SPs that are layered over one or more discovered TE SPs; enabled by default. The enabling parameter for this feature is ASSOCIATE_SP_TO_DP, which is described in the EMC Ionix MPS Manager Configuration Guide. An SP is a path that is traversed by MPS packets across an MPS network. Once the path is established, all subsequent MPS packets follow the same SP. As indicated in Figure 26 on page 69, packet-forwarding decisions for an MPS packet from the ingress PE to the egress PE are made solely on the content of the tunnel label. Outer label Inner label Data ayer 2 header Tunnel label (SP) VC/VPN label ayer 3 header Customer ayer 2 data Time A. MPS encapsulation Punultimate Tunnel label hop popping VC/VPN label xx PE xx P xx P xx PE Data Ingress PE device Intermediate P devices B. Transporting MPS packets over an MPS network Egress PE device Figure 26 MPS encapsulation and transport When the MPS packet arrives at the egress PE, the egress PE uses the virtual circuit (VC) or VPN label to deliver the data to the correct end-user. MPS permits multiple labels, called label stacks, to be added to an MPS packet. All traffic-forwarding decisions are based on the outer label of the stack. Multiple labels are used to implement MPS ayer 2 and ayer 3 VPNs, to send MPS packets over multiple MPS networks, and to reroute MPS packets over TE protection tunnels. More about SPs and SP discovery 69

70 Discovery of MPS Objects TE tunnels and TE SPs Traffic engineering (TE) broadly encapsulates both ayer 2 protection mechanisms as well as quality of service (QoS) mechanisms. The MPS Topology Server supports the ayer 2 protection aspect of MPS traffic engineering. It detects the following protection mechanisms on TE tunnels and performs impact analysis on the tunnels: ink protection Node protection Path protection ink/node protection using fast reroute ink/node protection is a mechanism that locally repairs a primary TE SP if a link or node in the SP path fails. In contrast, path protection is a mechanism that routes traffic onto a secondary TE SP when the primary fails. Figure 27 on page 70 and Figure 28 on page 71 show a link (R2 -> R5) and a node (R5) that have been configured with fast reroute (FRR) protection. The primary tunnel, R1 -> R8, is protected by two backup tunnels, R2 -> R5 and R2 -> R7. Stated in a different way, the primary TE SP, R1 -> R2 -> R5 -> R7 -> R8, is protected by two backup TE SPs, R2 -> R6 -> R5 and R2 -> R3 - > R4 -> R7. TE tunnel 2 TE tunnel 1 R3 MPS network R4 PR FRR-protected interface R1 R2 R5 MP R7 R8 TE FRR label TE label VC/VPN label Data 5 xx 12 5 xx R6 5 xx Primary TE SP (SP 1) Backup TE SP (SP 2) PR Point of local repair MP Merge point Figure 27 FRR switching for a failed link 70 EMC Ionix MPS Manager Version 9.0 Discovery Guide

71 Discovery of MPS Objects TE tunnel 1 TE tunnel 3 R3 MPS network R4 R1 PR R FRR-protected interface R R7 MP R8 TE FRR label 12 5 xx xx TE label VC/VPN label Data 5 xx R6 Primary TE SP (SP 1) Backup TE SP (SP 3) PR Point of local repair MP Merge point Figure 28 FRR switching for a failed node FRR, which is defined in RFC 4090, is a network recovery technique that has a restoration time within the range of milliseconds. The FRR restoration time for a failed link is less than 50 milliseconds, whereas the FRR restoration time for a failed node is somewhat longer and depends on the failure detection time. FRR is a form of SP local repairing, where a failed SP is recovered automatically by the device that is located directly upstream from the point of the failed link or node. This device, known as the headend or point of local repair (PR) for the FRR, is R2 in Figure 27 on page 70 and Figure 28 on page 71. The PR selects an SP from a preconfigured list of backup TE SPs onto which to route the traffic from the primary path. The PR swaps the incoming label and pushes a TE FRR label onto the label stack. The backup TE SP terminates on the device known as the merge point (MP), where the traffic rejoins the primary path. More about SPs and SP discovery 71

72 Discovery of MPS Objects Path protection Path protection is different from link/node protection in the following ways: The traffic reroute is made at a PE device. The rerouted traffic is to a different TE SP. Path protection can be used in any scenario where multiple TE SPs exist between two PE devices and bear the same service at the same service level. If the primary SP fails, the ingress PE device redirects the subscriber traffic to the secondary SP. The primary and secondary SPs share the same headend and tailend, but are diversely routed, as shown in Figure 29 on page 72. TE tunnel A Path-protected interface MPS network Ra 9 xx Rb Rd Rf 9 xx Rg xx xx TE label VC/VPN label 9 Rc Re Data xx Primary TE SP (SP A) Secondary TE SP (SP B) Figure 29 Path-protection switching for a failed TE tunnel In the figure, the primary TE SP, Ra -> Rb -> Rd -> Rf -> Rg, is protected by the secondary TE SP, Ra -> Rc -> Re -> Rg. Typically, the restoration time for a path-protection mechanism is longer compared to the restoration time for a link/node protection mechanism. 72 EMC Ionix MPS Manager Version 9.0 Discovery Guide

73 Discovery of MPS Objects P2MP SPs and subsps DP SPs SP discovery Point-to-multipoint (P2MP) SPs are used to forward multicast VPN traffic across MPS networks. A P2MP SP is a TE tunnel that starts at a single PE source and ends at multiple PE destinations within a multicast VPN. A P2MP SP is composed of two or more RSVP-TE signaled subsps. A subsp originates at the PE source and terminates at a particular PE destination. P2MP SPs for multicast VPNs are supported for intra-autonomous-system (AS) environments, but not for inter-as environments. DP SPs are SPs that are constructed by using the abel Distribution Protocol, which was specifically designed for MPS. Because DP does not support traffic engineering, no protection-path capability is available for DP SPs. For a managed MPS network that consists of Cisco and/or Juniper M/T devices, the MPS Topology Server will discover every TE tunnel and every TE SP in the network. For a managed MPS network that consists of Juniper M/T devices, the MPS Topology Server will discover every P2MP SP and every subsp in the network. The MPS Topology Server will also discover every DP SP between any pair of PE devices in the network as long as at least one of those SPs is used by a VPN to carry traffic. In contrast, if none of the DP SPs between a pair of PEs are used by a VPN, the MPS Topology Server will not discover any of those SPs. The latter behavior prevents the discovery of DP SPs that are not being used by customers. Discovering just the VPN-associated SPs not only saves computer resources but also leads to more meaningful service impact analysis. For a managed MPS network that consists of Huawei and/or Juniper ERX devices, the MPS Topology Server will discover at most one bidirectional pair of VPN-related DP SPs for each pair of PE devices in the network. More about SPs and SP discovery 73

74 Discovery of MPS Objects More about DP adjacencies and DP adjacency discovery The establishment of DP SPs is accomplished by PE and P devices through the use of the abel Distribution Protocol. DP is responsible for assigning tunnel labels to an DP SP and for handling error conditions. Note: An DP SP is PE to PE. PE and P devices exchange DP ink Hello messages to locate and establish DP sessions with their directly connected neighbors. Three such sessions, or adjacencies, are shown in Figure 30 on page 74. MPS network dpprotocolendpoint SP hop DPAdjacency DP SP Figure 30 Non-targeted DP adjacencies Peer DP speakers establish a TCP-based communications session with each other. Once the session is established, tunnel label data can be exchanged to construct DP SPs. The MPS Topology Server discovers the DP speakers and DP sessions that are associated with DP SPs. The MPS Topology Server also discovers the DP speakers and DP sessions that are associated with 2VPNs, as described in More about targeted DP adjacencies and DP adjacency discovery on page EMC Ionix MPS Manager Version 9.0 Discovery Guide

75 Discovery of MPS Objects More about RSVP sessions and RSVP session discovery The establishment of TE SPs and subsps is accomplished by PE and P devices through the use of the Resource Reservation Protocol with TE extensions. RSVP-TE is responsible for assigning tunnel labels to a TE SP or subsp, managing quality of service issues, and handling error conditions. Note: A TE SP may be PE to PE, PE to P, P to PE, or P to P. A subsp may only be PE to PE. The headend of a TE tunnel initiates the establishment of an RSVP session and a TE SP by sending an RSVP Path message toward the tailend of the TE tunnel. When the headend successfully receives from the tailend an RSVP Resv message that matches the sent RSVP Path message, an RSVP session and a TE SP are established between the headend and the tailend, as shown in Figure 31 on page 75. MPS network TE tunnel headend TE tunnel tailend RsvpProtocolEndpoint SP hop RsvpSession TE SP Figure 31 RSVP session For a P2MP SP, RSVP Path and Resv messages are used in a similar manner to establish the subsps between the PE source (headend) and the two or more PE destinations (tailends). Peer RSVP-TE speakers establish a TCP- or UDP-based communications session with each other. During the establishment of the session, the tailend allocates a label for the TE SP or subsp, places the label in an RSVP Resv message, and sends the Resv message toward the headend. By using the Resv message, the devices in the reverse path exchange tunnel label data to construct the TE SP or subsp. The MPS Topology Server discovers the RSVP-TE speakers and RSVP sessions that are associated with TE SPs and subsps. More about RSVP sessions and RSVP session discovery 75

76 Discovery of MPS Objects MPS discovery process During the MPS discovery process, the MPS Topology Server creates within its repository a data model representation of the discovered MPS topology. The MPS data model is shown in Figure 32 on page 76 through Figure 34 on page 77. TE SP / subsp / DP SP ayeredover ayeredover ayeredover SP Hop NextHop SP Hop NextHop SP Hop Source ayeredover ayeredover ayeredover Destination NetworkConnection NetworkConnection NetworkConnection egend: Hosts MPSService Relationships Figure 32 SP modeling in MPS data model Incoming label and interface Outgoing label and interface DP SP ayeredover dpprotocolendpoint dpadjacency dpprotocolendpoint Endpoint1 ConnectedTo Peer Endpoint2 ConnectedTo HostedBy HostedBy SP Hop NextHop Source Source ayeredover Destination Destination NetworkConnection egend: Hosts MPSService Relationships Figure 33 Non-targeted DP adjacency modeling in MPS data model 76 EMC Ionix MPS Manager Version 9.0 Discovery Guide

77 Discovery of MPS Objects TE SP / subsp ayeredover RsvpProtocolEndpoint Endpoint1 ConnectedTo Source RsvpSession Peer RsvpProtocolEndpoint Endpoint2 ConnectedTo Destination TE tunnel headend HostedBy SP Hop NextHop SP Hop NextHop SP Hop HostedBy TE tunnel tailend Source Source Destination ayeredover ayeredover ayeredover Destination NetworkConnection NetworkConnection NetworkConnection egend: Hosts MPSService Relationships Figure 34 RSVP session modeling in MPS data model SNMP and CI discovery Note: Typically, every relationship has an inverse relationship. For example, the relationship Underlying is the inverse relationship of ayeredover. Table 2 on page 61 and Table 3 on page 65 present descriptions of the MPSService, SP, SPHop, dpprotocolendpoint, dpadjacency, RsvpProtocolEndpoint, and RsvpSession classes. More detailed descriptions of these classes are available in the EMC Ionix MPS Manager User Guide. A TE tunnel and the TE SPs that are associated with the TE tunnel originate on a PE or P device and terminate on a PE or P device. A P2MP SP originates on a PE device and terminates on multiple PE devices; the subsps that are associated with the P2MP SP originate on a PE device and terminate on a PE device. An DP SP originates on a PE device and terminates on a PE device. The MPS Topology Server discovers MPS-specific objects by probing the router and switch objects that are imported from IP Availability Manager. Table 4 on page 78 and Table 5 on page 78 identify the MPS discovery sources. MPS discovery process 77

78 Discovery of MPS Objects Table 4 Discovery sources for MPS SPs Device/platform TE tunnels, TE SPs, P2MP SPs, and subsps 1 DP SPs 1 Cisco IOS Cisco IOX MPS-TE-MIB and CI The MPS Topology Server uses: SNMP discovery to discover Cisco IOS TE tunnel and TE SP objects. CI discovery to discover Cisco IOS nested link/node protected TE tunnel objects. MPS-TE-STD-MIB and CI The MPS Topology Server uses: SNMP discovery to discover Cisco IOX TE tunnel and TE SP objects. CI discovery to associate the primary TE SPs with their backup/secondary TE SPs. MPS-SR-MIB If SNMP discovery fails or is not supported by the Cisco IOS device, the MPS Topology Server uses CI discovery to discover the DP SP objects. MPS-SR-STD-MIB If SNMP discovery fails or is not supported by the Cisco IOX device, the MPS Topology Server uses CI discovery to discover the DP SP objects. Huawei Not supported CI Juniper M/T JUNIPER-MPS-MIB and CI The MPS Topology Server uses: SNMP discovery to discover Juniper TE tunnel objects that are configured for link/node protection. CI discovery to discover Juniper TE tunnel objects that are configured for path protection. SNMP discovery to discover Juniper P2MP SP and subsp objects. CI Juniper ERX Not supported CI 1 SNMP-discovered objects are monitored for status, but CI-discovered objects are not. Table 5 Discovery sources for MPS DP adjacencies and RSVP sessions Device/platform Non-targeted DP adjacencies 1 Targeted DP adjacencies 1 RSVP sessions 1 Cisco IOS MPS-DP-MIB MPS-DP-MIB CI Cisco IOX Not supported MPS-DP-STD-MIB Not supported Huawei Not supported MPS-DP-STD-MIB Not supported Juniper M/T JUNIPER-MPS-DP-MIB 2 JUNIPER-MPS-DP-MIB 2 JUNIPER-RSVP-MIB Juniper ERX CI CI Not supported 1 SNMP-discovered objects are monitored for status, but CI-discovered objects are not. 2 If SNMP discovery fails or is not supported, CI discovery is used to discover the DP adjacencies. Appendix A, MIBs Accessed for Discovery and Remote Ping, provides a description of the discovery MIB objects that are polled by an SNMP discovery probe. Appendix B, CI Commands Invoked for Discovery and SP Ping, provides a description of the commands that are invoked by a CI discovery session. 78 EMC Ionix MPS Manager Version 9.0 Discovery Guide

79 Discovery of MPS Objects Per-device discovery for MPS Per-device (Phase 2) discovery for MPS pertains to the discovery of MPS objects on a per-router or per-switch basis. During this phase of the MPS discovery process, the MPS Topology Server creates instances of the following classes: MPSService on page 79 SP table manager on page 80 dpprotocolendpoint (non-targeted) on page 82 RsvpProtocolEndpoint on page 82 MPSService The MPS Topology Server creates an MPSService instance for each device that is imported from IP Availability Manager, regardless of whether the device supports MPS. The MPS Topology Server also creates a HostedBy relationship between each MPSService instance and its associated device. MPSService device type In addition to identifying the MIBs that are supported by the host device, an MPSService instance identifies the device type of the host device. Device types are defined in Table 6 on page 79. Table 6 Device type definitions Hosts these components... Has this relationship... Device type P SP segment VRF, ForwarderEndpoint, or both ConnectedTo -> PE AttachedTo -> VRF x PE x x CE x Multi-VRF CE x 1 x Other 1 A multi-vrf CE will host one or more VRFs. The MPS Topology Server assigns the device type to an MPSService instance during the postprocessing phase of discovery. A device type of Other indicates that the host device is not a PE, P, CE, or multi-vrf CE. For an Other host device, the only relationship that is created for an MPSService instance is HostedBy. MPSService relationships For a PE, P, CE, or multi-vrf CE host device, the relationships that are created for an MPSService instance depend on two things: the device type of the host device, and the MPS and VPN services that are supported by the host device. The relationships are described in Table 7 on page 80. MPS discovery process 79

80 Discovery of MPS Objects Table 7 MPSService relationship set Device type Relationship Description Comment P MPSInterfaces Points from an MPSService to all interfaces on the host device that are MPS-enabled. PE MPSInterfaces Same as above. VRFInterfaces VRFs Forwarders ForwarderEndpoints DPSessions Points from an MPSService to all interfaces on the host device that are associated with VRFs. Points from an MPSService to all VRFs that are hosted by the host device. Points from an MPSService to all Forwarders that are hosted by the host device. Points from an MPSService to all ForwarderEndpoints that are hosted by the host device. Points from an MPSService to all dpprotocolendpoints that are hosted by the host device. Applicable to BGP-signaled 2VPNs and 3VPNs. Applicable to 2VPNs. Applicable to DP-signaled 2VPNs. CE ConnectedTo Points from an MPSService to the PE device to which the host device is connected. Multi-VRF CE AttachedTo Points from an MPSService to the one or more VRFs to which the host device is attached. Applicable to 2VPNs and 3VPNs. Applicable to 3VPNs. SP table manager SP table manager represents a collection of SP table manager objects that hold the SP-related information that is discovered during per-device discovery. By default, none of the SP table manager objects are viewable through a Global Console that is attached to the MPS Topology Server. To discover TE tunnels, P2MP SPs, TE SPs, and subsps, the MPS Topology Server probes the managed devices for SP-tunnel header information and writes that information to the SP table manager. Included in an SP-tunnel header are the source and destination devices and all of the SP hops from the source to the destination. To discover DP SPs, the MPS Topology Server probes the managed devices for SP-hop information and writes that information to the SP table manager. Figure 35 on page 81 provides a snapshot of the SP table manager and SP discovery. 80 EMC Ionix MPS Manager Version 9.0 Discovery Guide

81 Discovery of MPS Objects MPS Manager (same host machine) MPS Topology Server Topology model repository MPS Analysis Server SP table manager External interface TE SP discovery subsp discovery DP SP discovery SP-hop data SP-hop data from other (& dpprotocolendpoint, x external Forwarder, sources ForwarderEndpoint, & VRF objects) MPS Monitoring Server Adapter for 5620 SAM EMS Topology 5620 SAM EMS Topology SNMP & CI discovery SNMP discovery SNMP & CI discovery CI discovery Alcatel-ucent Cisco Juniper M/T Juniper ERX MPS network Huawei Figure 35 The SP table manager and SP discovery As shown in Figure 35, the SP table manager is able to accept SP-hop information from the EMC Ionix Adapter for Alcatel-ucent 5620 SAM EMS (the Adapter) through an external interface. The external interface enables the MPS Topology Server to create SPs that traverse Alcatel-ucent devices, or traverse a mixture of Alcatel-ucent and other vendor devices. The only limitation is that the SPs originate and terminate on same-vendor devices (a pair of Alcatel-ucent PEs, for example). MPS discovery process 81

82 Discovery of MPS Objects dpprotocolendpoint (non-targeted) In an environment that is using DP signaling to establish SPs, the MPS Topology Server discovers the PE and P devices and the DP speakers that are associated with the SPs. All links in the environment have interior gateway protocol adjacencies as well as DP adjacencies. The complete MPS forwarding path for an DP SP is determined by IP forwarding. The MPS Topology Server creates an dpprotocolendpoint instance for each discovered DP speaker that is associated with an DP SP. It sets the instance s IsTargetedPeer attribute to False, to indicates that this instance s termination point is to a non-targeted peer. Here are some relationships that are created for dpprotocolendpoint (non-targeted): dpprotocolendpoint relationship HostedBy Relates an dpprotocolendpoint to the PE or P device that hosts the DP speaker that is represented by the dpprotocolendpoint. dpprotocolendpoint relationship ayeredover Points from an dpprotocolendpoint to the interface and IP address, on the host PE or P device, that are associated with the dpprotocolendpoint. dpprotocolendpoint relationship Peer Points from an dpprotocolendpoint to the endpoint at the other end of the dpadjacency. RsvpProtocolEndpoint In an environment that is using RSVP-TE signaling to establish SPs, the MPS Topology Server discovers the PE and P devices and the RSVP-TE speakers that are associated with the SPs. The complete MPS forwarding path for a TE SP or subsp is determined by IP forwarding and the explicit constraints that are applied to the SP. The MPS Topology Server creates an RsvpProtocolEndpoint instance for each discovered RSVP-TE speaker that is associated with a TE SP or subsp. Here are some relationships that are created for RsvpProtocolEndpoint: RsvpProtocolEndpoint relationship HostedBy Relates an RsvpProtocolEndpoint to the PE or P device that hosts the RSVP-TE speaker that is represented by the RsvpProtocolEndpoint. RsvpProtocolEndpoint relationship ayeredover Points from an RsvpProtocolEndpoint to the interface and IP address, on the host PE or P device, that are associated with the RsvpProtocolEndpoint. RsvpProtocolEndpoint relationship Peer Points from an RsvpProtocolEndpoint to the endpoint at the other end of the RsvpSession. 82 EMC Ionix MPS Manager Version 9.0 Discovery Guide

83 Discovery of MPS Objects Postprocessing discovery for MPS During this phase (Phase 3) of the MPS discovery process, which starts after per-device discovery completes, the MPS Topology Server creates instances of the following classes by combining the information that is collected during the per-device MPS discovery: SP on page 83 SPHop on page 87 dpadjacency (non-targeted) on page 87 RsvpSession on page 88 For SP discovery on Cisco or Juniper M/T devices, the MPS Topology Server uses the SP table manager to create the SP and SPHop instances. For SP discovery on Huawei or Juniper ERX devices, the MPS Topology Server uses similar software to create the SP and SPHop instances. That software employs the SP discovery method that was used in MPS Management Suite 2.1: Create SPInSegment and SPOutSegment objects, and from those objects, create the SP and SPHop objects. SP The MPS Topology Server uses the SP class to create instances of the discovered TE tunnels, TE SPs, P2MP SPs, subsps, and DP SPs. TE tunnels and a P2MP SPs are compound objects that contain primary/backup/secondary TE SPs and subsps, respectively. As such, neither a TE tunnel nor a P2MP SP has SP hops, and neither is directly associated with any interfaces. SP creation To create TE tunnels, P2MP SPs, TE SPs, and subsps, the MPS Topology Server consults the SP table manager and examines the SP-tunnel header information to create instances of the SPs. To create DP SPs, the MPS Topology Server consults the SP table manager and stitches SP hops together to create instances of the SPs. An SP ID for a TE SP or subsp is a 2-byte identifier that is used by the SP-tunnel headend to set up the SP. The MPS Topology Server discovers the SP ID during per-device discovery. During postprocessing discovery, the MPS Topology Server converts the SP ID to a 4-byte identifier that identifies the destination IP address of the SP. An SP ID for an DP SP is a 4-byte identifier that identifies the destination IP address of the SP. The MPS Topology Server determines the SP ID during postprocessing discovery. Also, during postprocessing discovery, the MPS Topology Server determines the name of the destination PE device by traversing the HostedBy relationship of the SP ID IP object to the device. MPS discovery process 83

84 Discovery of MPS Objects SP naming convention for TE tunnels and TE SPs The MPS Topology Server uses the following convention to name a Cisco-based TE tunnel: TETunnel-<tunnel name>/<device name>_<tunnel ID> For example: TETunnel-dev-VPS5-t579/dev-Vpls5_579 The MPS Topology Server uses the following convention to name a Cisco-based primary or backup/secondary TE SP: <tunnel name>_primary Secondary For example: dev-vps5-t579_primary For discovered TE tunnels and TE SPs that are built on Juniper M/T devices, the MPS Topology Server uses the tunnel names that are available in the JUNIPER-MPS-MIB. Because no tunnel IDs are available in the JUNIPER-MPS-MIB, no tunnel ID appears in the name of a TE tunnel that is discovered on a Juniper M/T device; for example: TETunnel-QA-MPSp8-to-DEV-VPS0/qa-MPSp8 The EMC Ionix MPS Manager User Guide describes in detail the naming formats that are used to create MPS and VPN object names. SP naming convention for P2MP SPs and subsps The MPS Topology Server uses the following convention to name a P2MP SP: P2MP-<discovered P2MP SP name> For example: P2MP :6800:mvpn:NGMVPN_SP2 The MPS Topology Server uses the following convention to name a subsp: subsp-<discovered subsp name> For example: subsp : :6800:mvpn:ngmvpn_sp2 SP naming convention for DP SPs The MPS Topology Server uses the following convention to name DP SPs: SP-<source device name>-><destination device name>/-<first hop (source device) outgoing label>-<next hop outgoing label>-...-<last hop outgoing label (3 = POP)> For example: SP-qa-vpls4->qa-vpls2/ EMC Ionix MPS Manager Version 9.0 Discovery Guide

85 Discovery of MPS Objects SP relationships Here are some relationships that are computed for TE SPs, subsps, and DP SPs: SP relationship Source Points from an SP to the source PE or P device for the SP. SP relationship Destination Points from an SP to the destination PE or P device for the SP. SP relationship ayeredover Points from an SP to all SPHops that belong to the SP. Also points to the outgoing and incoming interfaces that are associated with the SPHops that belong to the SP. For a TE SP or subsp, points from the SP to the RsvpSession that constructs the SP. For an DP SP, points from the SP to the non-targeted dpadjacencies that construct the SP. Here are three additional relationships that are computed for TE tunnels: TE tunnel relationship ProtectedBy For a link-protected and/or node-protected tunnel, points from the TE tunnel to the primary TE SP and the one or more backup TE tunnels that protect this tunnel. For a path-protected tunnel, points from the TE tunnel to the primary TE SP and the one or more secondary TE SPs that protect this tunnel. TE tunnel relationship PrimarySP Points from a TE tunnel to the primary TE SP that protects this tunnel. This relationship ensures that the primary tunnel appears as a solid line in MPS map displays. TE tunnel relationship SecondarySPs Points from a TE tunnel to the one or more backup TE tunnels or secondary TE SPs that protect this tunnel. This relationship ensures that a backup tunnel or a secondary TE SP appears as a dashed line in MPS map displays. Figure 36 on page 86 shows these three relationships for the link/node and path-protected TE tunnels that are presented in Figure 27 on page 70, Figure 28 on page 71, and Figure 29 on page 72. MPS discovery process 85

86 Discovery of MPS Objects SP TE tunnel 1 - R PrimarySP - - R - - SP + SP 1 ProtectedBy SP + SP 1 SP + SP 2 - R ProtectedBy - SP + SP 2 - TE tunnel 3 - R PrimarySP - SP + SP 3 - R ProtectedBy - SP + SP 3 SecondarySPs SP + TE tunnel 2 + TE tunnel 3 TE tunnel A R PrimarySP - R R - - R TE tunnel 2 R PrimarySP - SP + SP A ProtectedBy SP + SP A + SP B SecondarySPs SP + SP B Figure 36 Relationships for the link/node and path-protected TE tunnel examples An additional relationship for P2MP SPs is ComposedOf, which points from a P2MP SP to the subsps that are part of the P2MP SP. SP rediscovery After SP discovery, MPS Manager monitors the TE SPs and DP SPs that are built on Cisco or Juniper M/T devices. It also monitors the subsps that are built on Juniper M/T devices. If MPS Manager detects that SP rerouting has occurred (applicable to TE SPs only), it initiates rediscovery of the rerouted SP. SP monitoring and rediscovery are controlled by the SP polling group in the Polling and Thresholds Console, as explained in the EMC Ionix MPS Manager Configuration Guide. 86 EMC Ionix MPS Manager Version 9.0 Discovery Guide

87 Discovery of MPS Objects SPHop For each TE SP, subsp, or DP SP instance that the MPS Topology Server creates, the MPS Topology Server also creates the SPHop instances along the path of the SP. It starts with the source SP segment for the SP and uses the nexthopkey value in the SP table manager to create the SPHops from the SP source to the SP destination, hop by hop. If an SPHop is the first one for an SP, the MPS Topology Server creates the Source relationship between that SPHop and the source device for the SP. If an SPHop is the last one for an SP, the MPS Topology Server creates the Destination relationship between that SPHop and the destination device for the SP. Here are some other relationships that are computed for SPHops: SPHop relationship ayeredover Points from an SPHop to the network connection that is underlying the SPHop. SPHop relationship Underlying Points from an SPHop to the SP to which the SPHop belongs. SPHop relationship NextHop Points from an SPHop to the next SPHop along the path of an SP. This relationship is computed only for an SPHop that is not the last hop in the path of an SP. SPHop relationship PreviousHop dpadjacency (non-targeted) Points from an SPHop to the previous SPHop along the path of an SP. This relationship is computed only for an SPHop that is not the first hop in the path of an SP. In an environment that is using DP signaling to establish SPs, the MPS Topology Server matches various attributes (ocaladdress, PeerAddress) that are associated with the dpprotocolendpoints that are discovered on different PE and P devices, and creates an dpadjacency instance for each complementary match. the MPS Topology Server sets each instance s istargeted attribute to False, to indicates that this DP session is not targeted. An dpadjacency is ConnectedTo two dpprotocolendpoints, where one dpprotocolendpoint is HostedBy one PE or P device, and the second is HostedBy a peering PE or P device. The dpadjacency provides a bidirectional signaling path through which the two directly connected peering devices exchange MPS label information for the purpose of constructing, maintaining, or deleting DP SPs. MPS discovery process 87

88 Discovery of MPS Objects Here are some other relationships that are computed for dpadjacency (non-targeted): dpadjacency relationship Endpoint1 Points from an dpadjacency to the dpprotocolendpoint that has the lower IP address of the two endpoints that are associated with the dpadjacency. dpadjacency relationship Endpoint2 Points from an dpadjacency to the dpprotocolendpoint that has the higher IP address of the two endpoints that are associated with the dpadjacency. dpadjacency relationship Underlying Points from an dpadjacency to the DP SP that is associated with the dpadjacency. RsvpSession In an environment that is using RSVP-TE signaling to establish SPs, the MPS Topology Server matches various attributes (ocaladdress, FromIP, ToIP) that are associated with the RsvpProtocolEndpoints that are discovered on different PE and P devices, and creates an RsvpSession instance for each complementary match. An RsvpSession is ConnectedTo two RsvpProtocolEndpoints, where one RsvpProtocolEndpoint is HostedBy one PE or P device, and the second is HostedBy a peering PE or P device. The RsvpSession provides a bidirectional signaling path through which the two peering devices exchange MPS label information for the purpose of constructing, maintaining, or deleting TE SPs or subsps. Here are some other relationships that are computed for RsvpSession: RsvpSession relationship Endpoint1 Points from an RsvpSession to the RsvpProtocolEndpoint that represents the source RSVP-TE speaker for the session. RsvpSession relationship Endpoint2 Points from an RsvpSession to the RsvpProtocolEndpoint that represents the destination RSVP-TE speaker for the session. RsvpSession relationship Source Same as Endpoint1. RsvpSession relationship Destination Same as Endpoint2. RsvpSession relationship Underlying Points from an RsvpSession to the TE SP or subsp that is associated with the session. 88 EMC Ionix MPS Manager Version 9.0 Discovery Guide

89 Discovery of MPS Objects Relationships between the MPS and transport models Figure 37 on page 89 shows most of the relationships that can appear in the SP modeling portion of the MPS data model. The underlying transport network objects in the model, shown as white text on black background, are managed by IP Availability Manager. From CE PE Source HostedBy MPSService Card M Source Interface NC SPHop Interface Card M MPSService HostedBy NextHop SP P M Card Interface NC SPHop Interface Card M Destination MPSService HostedBy PE Destination To CE egend: NC = NetworkConnection = ayeredover M = MPSInterfaces Figure 37 Relationships between the MPS and transport models MPS discovery process 89

90 Discovery of MPS Objects 90 EMC Ionix MPS Manager Version 9.0 Discovery Guide

91 CHAPTER 5 Discovery of 2VPN Objects This chapter describes how MPS Manager discovers and models 2VPN topology objects. It consists of the following sections: 2VPN discovery overview More about 2VPNs and 2VPN discovery More about targeted DP adjacencies and DP adjacency discovery More about EVC over MPS discovery VPN discovery process Discovery of 2VPN Objects 91

92 Discovery of 2VPN Objects 2VPN discovery overview For 2VPN discovery, the MPS Topology Server component of MPS Manager is able to discover and model the following MPS ayer 2 VPN entities: DP-signaled 2VPNs This 2VPN uses abel Distribution Protocol (DP) signaling to set up and maintain the pseudowires between PE devices in an MPS network. BGP-signaled 2VPNs This 2VPN uses Multiprotocol Border Gateway Protocol (MBGP) signaling to set up and maintain the pseudowires between PE devices in an MPS network. VPWS Virtual private wire service, also known as point-to-point 2VPN, is a technology that uses a pseudowire to emulate a point-to-point circuit across an MPS network. VPS Virtual private AN service, also known as point-to-multipoint 2VPN, is a technology that uses a full mesh of pseudowires to emulate a AN across an MPS network. EVC over MPS Ethernet virtual connection over MPS is the implementation of a Metro Ethernet service across an MPS network through a VPWS or VPS. The MPS Topology Server requires a evel 2 VPN feature license for the discovery of VPWS and VPS 2VPNs. The EMC Ionix ITOps System Administration Guide provides information about licensing. More about 2VPNs and 2VPN discovery 2VPNs are provider-provisioned ayer 2 VPNs that extend the customer s ayer 2 connectivity through an MPS network. They do so by emulating different types of traditional data-link layer protocols, including Ethernet, Frame Relay, ATM, and others. ike 3VPNs, 2VPNs depend entirely on the PE devices. Unlike 3VPNs, 2VPNs do not require that the PE devices participate in the customer s routing algorithms. The latter statement means that a customer may run any type of ayer 3 protocol between sites, including IP. An 2VPN may be implemented as a VPWS or a VPS, where a VPWS provides point-to-point connectivity between two sites, and a VPS provides point-to-multipoint connectivity between multiple sites. The control plane for either implementation may use DP or BGP. The 2VPN data plane is based on the pseudowire, which represents two virtual circuits between a pair of PE devices that are participating in an 2VPN. One virtual circuit is carried over an outgoing SP, and the other is carried over an incoming SP. Together, the two virtual circuits provide bidirectional communication for a customer. 92 EMC Ionix MPS Manager Version 9.0 Discovery Guide

93 Discovery of 2VPN Objects 2VPN encapsulation Pseudowires require that the ingress and egress PE devices use common service-specific techniques to encapsulate the customer ayer 2 data. The ingress PE encapsulates the data in accordance to the Martini draft proposal, attaches a virtual circuit (VC) label and a tunnel label, and forwards the packet over the SP. Figure 38 on page 93 shows the encapsulation and data transport. Data Tunnel Control ayer 2 header label VC label ayer 3 word header Customer ayer 2 data (SP) (optional) Time A. ayer 2 data encapsulation in accordance to the Martini draft proposal Tunnel label VC label Punultimate hop popping xx PE xx P xx P xx PE Send data to end-user xx CE Data Ingress PE device Intermediate P devices B. Transporting ayer 2 VPN packets over an MPS network Figure 38 MPS 2VPN encapsulation and transport Egress PE device Destination CE device Virtual private wire service When the MPS packet arrives at the egress PE, the egress PE uses the VC label to deliver the data to the correct CE device with the appropriate ayer 2 encapsulation. A VPWS is a provider-provisioned point-to-point service that connects two CE devices. Figure 39 on page 94 identifies the basic components of a VPWS. More about 2VPNs and 2VPN discovery 93

94 Discovery of 2VPN Objects same circuit type MPS network Customer A, site 1 Attachment Circuit 1 DP/BGP session Pseudowire Attachment Circuit 2 Customer A, site 2 CE1 PE1 PE2 CE2 Customer B, site Q or traditional Ethernet VAN 200 DP/BGP session 802.1Q or traditional Ethernet Pseudowire VAN 200 Customer B, site 4 CE3 PE3 PE4 CE4 Peer Forwarder instances (2) Peer Forwarder instances (2) VPWS 1 VPWS 2 Figure 39 Using VPWS to connect customer sites over an MPS network A VPWS consists of two Attachment Circuits, two Forwarders, and a pseudowire. The pseudowire emulates a ayer 2 circuit. In Figure 39, the Attachment Circuit pair for VPWS 1 represents one of many circuit types that have been defined for encapsulating different ayer 2 protocols in MPS packets. One such circuit type, Ethernet VAN, is shown in VPWS 2. The most popular proposal for VPWS is the Martini draft proposal, which defines 10 circuit types and recommends DP signaling. Other VPWS proposals support the 10 circuit types but recommend BGP signaling. DP or BGP signaling is used by the PE pair in a VPWS to construct, advertise, maintain, and delete label bindings for the pseudowire. The PEs must agree on the meaning of the labels that the PEs will use to forward traffic to each other. In an DP-signaled VPWS, the pseudowire is identified by a VC ID. In a BGP-signaled VPWS, the pseudowire is identified by a combination of an incoming VC ID and an outgoing VC ID. Note that in an DP-signaled VPWS, VC ID is an identifier for both virtual circuits of a pseudowire. In a BGP-signaled VPWS, incoming VC ID is an identifier for one virtual circuit of a pseudowire, and outgoing VC ID is an identifier for the other virtual circuit. 94 EMC Ionix MPS Manager Version 9.0 Discovery Guide

95 Discovery of 2VPN Objects Virtual private AN service A VPS is a provider-provisioned service that emulates the full functionality of a traditional AN. Figure 40 on page 95 identifies the basic components of a VPS Q MPS network 802.1Q Customer C, site 5 CE5-C VAN 400 DP/BGP session Pseudowire 400 Pseudowire 600 VAN 400 CE6-C Customer C, site 6 Customer D, site 7 CE7-D VAN 600 Traditional Ethernet PE5 Pseudowire 400 Pseudowire 600 DP/BGP session Pseudowire 400 Pseudowire 600 DP/BGP session PE6 VAN 600 Traditional Ethernet CE8-D Customer D, site Q PE7 VAN 400 VAN 600 Traditional Ethernet Customer C, site 9 Customer D, site 10 CE9-C CE10-D Peer Forwarder instances (3) Peer Forwarder instances (3) Associated with Pseudowire 400 Associated with VAN 400 VPS 1 Associated with Pseudowire 600 Associated with VAN 600 VPS 2 Figure 40 Using VPS to connect customer sites over an MPS network A VPS makes the remote AN segments behave as one single AN. CE devices that belong to a specific VPS appear to be on a single bridged Ethernet. Two separate VPS standards, RFC 4761 and RFC 4762, define almost identical approaches to implementing the VPS data plane, but define significantly different approaches to implementing the VPS control plane. RFC 4761 recommends BGP signaling, and RFC 4762 recommends DP signaling. Both standards extend the Martini VPN capabilities by defining a new circuit type for Ethernet VAN. The new circuit type enables VPS to support 802.1Q VANs, traditional Ethernet encapsulation, and broadcast and multicast functions. Although the hub-and-spoke topology type is considered, both standards recommend the use of a full mesh topology for all members of a VPS. For the full mesh topology, each PE must run a Forwarder instance for each individual VPS that the PE supports. More about 2VPNs and 2VPN discovery 95

96 Discovery of 2VPN Objects In a VPS, a Forwarder makes forwarding decisions by examining the destination MAC addresses, or destination MAC addresses and VAN tags, in a data packet s ayer 2 header. In essence, a Forwarder operates as a virtual ayer 2 bridge or switch. As such, each Forwarder must maintain a routing table so that it can forward an incoming user data packet to the correct pseudowire. DP-signaled VPS The pseudowire identifier VC ID in an DP-signaled VPWS also has significance in an DP-signaled VPS. In an DP-signaled VPS, each pseudowire may be configured with the same VC ID, or each pseudowire may be configured with a different VC ID. RFC 4762 allows both configurations, but recommends the former. For the former, the VC ID is considered the VPS ID for the VPS. A VC ID is locally significant on a PE, but is not globally significant. In other words, two pseudowires with the same VC ID, say 100, one between PEa => PEb and the other between PEx => PEy, are independent of each other. No connection exists between the two pseudowires. ForwarderEndpoints are peers only when both of them use the same VC ID and point to each other s IP address. The combination of VC ID and peer IP address for a ForwarderEndpoint is globally unique. BGP-signaled VPS In a BGP-signaled VPS environment, each VPS on each PE must be assigned a unique route target. The route target must be the same for a particular VPS across all PEs that belong to the VPS. The route target is the VPS ID for a BGP-signaled VPS. Also, each PE must be assigned a unique site identifier. The site identifier is the same as the virtual edge identifier (VEID) that is defined in RFC ForwarderEndpoints are peers only when they share complementary incoming VC ID and outgoing VC ID values. That is, the incoming VC ID for the one is the outgoing VC ID for the other, and the outgoing VC ID for the one is the incoming VC ID for the other. 96 EMC Ionix MPS Manager Version 9.0 Discovery Guide

97 Discovery of 2VPN Objects 2VPN discovery The MPS Topology Server is able to discover DP-signaled VPWS and VPS instances, and BGP-signaled VPWS and VPS instances. Because VPS has many prototypes and is configured in many different ways from vendor to vendor, the MPS Topology Server focuses on support of the more dominant types of VPS. Specifically, the MPS Topology Server focuses on the following: VPS architectural type: flat architecture The MPS Topology Server discovers VPS instances that employ the flat architecture type of VPS, but does not discover VPS instances that employ the hierarchical architecture (H-VPS) type of VPS. The latter type of VPS is used to overcome control-plane scalability issues in an DP-signaled VPS. VPS topology type: full mesh MPS Manager discovers VPS instances that employ the full mesh topology, but does not discover VPS instances that employ the hub-and-spoke topology. VPS signaling protocol types: DP, BGP The MPS Topology Server discovers VPS instances that are exclusively signaled by either DP or BGP, but does not discover VPS instances that are signaled by both DP and BGP. The MPS Topology Server is able to discover all independent pseudowires (VPWS instances), even if some of those pseudowires use the same VC ID. For DP-signaled VPS, the MPS Topology Server assumes that: All pseudowires within a VPS instance use the same VC ID. No two VPS instances in the managed MPS network use the same VC ID. Figure 41 on page 98 is an example of one of the more complex 2VPN deployments that the MPS Topology Server is able to discover. Because the default value of the ASSOCIATE_SP_TO_DP parameter in the mpls.conf file is TRUE, the MPS Topology Server will create by default the DP-SP-to-TE-SP ayeredover relationships that are shown in the figure. More about 2VPNs and 2VPN discovery 97

98 Discovery of 2VPN Objects Juniper ERX access device MPS network Targeted DP session Pseudowire Juniper ERX access device PEa1 PEa2 DP SP1 TE tunnel TE SP1 (primary) Juniper M distribution device PEd1 P2 TE SP2 (secondary) PEd2 Juniper M distribution device P1 P3 Juniper T core devices Peer Forwarder instances (2) VPWS Attachment Circuit ayeredover (relationship) Primary data path: DP label VC label TE label Punultimate hop popping Punultimate hop popping 11 Send data to end-user CE xx PE xx PE xx P xx PE xx PE xx CE Source CE device Data PEa1 PEd1 P2 PEd2 PEa2 Destination CE device Note: For simplicity, only one SP path of the bidirectional pseudowire is shown. Figure 41 Discovering a VPWS instance that is configured with SP protection 98 EMC Ionix MPS Manager Version 9.0 Discovery Guide

99 Discovery of 2VPN Objects More about targeted DP adjacencies and DP adjacency discovery The establishment of pseudowires in DP-signaled 2VPNs is accomplished by PE devices through the use of the abel Distribution Protocol. DP is responsible for constructing, advertising, maintaining, and deleting label bindings for pseudowires. PE devices exchange Targeted Hello messages to locate and establish DP sessions, or adjacencies, with other PE devices. One such session, or adjacency, is shown in Figure 42 on page 99. MPS network dpprotocolendpoint Backbone tunnel (2 SPs) DPAdjacency Pseudowire (2 virtual circuits) Figure 42 Targeted DP adjacency Peer DP speakers on peer PEs establish a TCP-based communications session with each other. Once the session is established, tunnel label data can be exchanged to construct pseudowires. The MPS Topology Server discovers the DP speakers and DP sessions that are associated with pseudowires. The MPS Topology Server also discovers the DP speakers and DP sessions that are associated with DP SPs, as described in More about DP adjacencies and DP adjacency discovery on page 74. More about EVC over MPS discovery EVC over MPS enables service providers to use an MPS network to deliver Metro Ethernet services to two or more VPN customer sites. The Ethernet frames are transported across the MPS network in a pseudowire (VPWS) or a full mesh of pseudowires (VPS), and the Attachment Circuits that are associated with the pseudowires employ the Ethernet technology. More about targeted DP adjacencies and DP adjacency discovery 99

100 Discovery of 2VPN Objects The MPS Topology Server works with IP Availability Manager to discover EVCs in Ethernet-MPS-Ethernet (E-M-E), MPS Only, and Ethernet Only Metro Ethernet networks. Because an Ethernet Only network contains no MPS core, an EVC in an Ethernet Only network contains no VPWS pseudowire or VPS pseudowires in its connection path. Figure 43 on page 100 and Figure 44 on page 100 show the key component of Ethernet-MPS-Ethernet (E-M-E) and MPS Only Metro Ethernet networks. Customer Ethernet access MPS core Ethernet access Customer CE-VAN EVC (Implements a Metro Ethernet service) CE-VAN 802.1Q 802.1Q -or ad VPWS or VPS 802.1Q -or ad 802.1Q EVC endpoint Service provider network EVC endpoint Ethernet MPS Ethernet CE UNI U-PE PE PE U-PE UNI CE egend: 802.1Q: Ethernet VAN tagging CE-VAN: Customer VAN 802.1ad: Ethernet VAN double tagging U-PE: User-facing PE Figure 43 Key components of an E-M-E Metro Ethernet network Customer Service provider Customer CE-VAN EVC (Implements a Metro Ethernet service) CE-VAN 802.1Q VPWS or VPS 802.1Q EVC endpoint MPS network EVC endpoint CE UNI PE P P PE UNI CE Figure 44 Key components of an MPS Only Metro Ethernet network 100 EMC Ionix MPS Manager Version 9.0 Discovery Guide

101 Discovery of 2VPN Objects EVC endpoints and EVCs EVC endpoint discovery EVC discovery The addition of customer-specified service attributes and parameters to an Ethernet service is what makes the service a Metro Ethernet service. Data is transported across point-to-point and multipoint-to-multipoint EVCs in accordance to the attributes and definitions of the E-ine, E-AN, and E-Tree services. An EVC endpoint represents the flow point where a service passes through a user network interface (UNI), which is a physical interface or port. It defines the instance of the service, identifies all Ethernet data and control frames that belong to the service, and provides the capability of applying the configured features to those frames. An EVC provides a point-to-point or multipoint-to-multipoint connection between the EVC endpoints that belong to the service. Discovering EVC endpoints requires that the MetroEthernetEnabled parameter in IP Availability Manager s discovery.conf file be set to TRUE. By default, MetroEthernetEnabled is FASE. When MetroEthernetEnabled is set to TRUE, IP Availability Manager sends SNMP requests to the Cisco devices to discover EVC endpoint topology. It supports SNMPv1, v2c, and v3 access to the CISCO-EVC-MIB objects. IP Availability Manager exports the EVC endpoints to the MPS Topology Server. The MPS Topology Server discovers EVCs by examining the EVC identifier of the imported EVC endpoints. For each group of EVC endpoints that have the same EVC identifier, the MPS Topology Server creates an EVC. The MPS Topology Server is able to discover EVCs for the following types of Metro Ethernet services: Ethernet private line (EP) A port-based service that is based on the Metro Ethernet E-ine service type. It provides a point-to-point EVC between two UNIs. Because an EP does not allow for service multiplexing (all service frames at the UNI are mapped to a single EVC), no CE-VAN-ID-to-EVC mapping is needed. See Figure 45 on page 102 for clarification. Ethernet virtual private line (EVP) A VAN-based service that is based on the Metro Ethernet E-ine service type. It provides a point-to-point EVC between two UNIs. Because an EVP allows for service multiplexing (service frames at the UNI may be mapped to more than one EVC), CE-VAN-ID-to-EVC mapping is needed. See Figure 45 on page 102 for clarification. More about EVC over MPS discovery 101

102 Discovery of 2VPN Objects Customer side CE-VAN1 CE-VAN2 CE-VAN3 UNI Service provider side EVC endpoint EVC (Bundling = no) ServiceMultiplexing = no, AllToOneBundling = yes A. An EP service Customer side CE-VAN4 CE-VAN5 CE-VAN6 UNI Service provider side EVC endpoint1 EVC1 (Bundling = yes) EVC2 (Bundling = no) EVC endpoint2 Figure 45 EP versus EVP 2VPN discovery process ServiceMultiplexing = yes, AllToOneBundling = no B. Two EVP services A complete EVC discovery requires the enabling of MPS light discovery in IP Availability Manager. (By default, IP Availability Manager is not enabled to perform MPS light discovery.) Instructions for enabling MPS light discovery are given in the EMC Ionix MPS Manager Configuration Guide. During the 2VPN discovery process, the MPS Topology Server creates within its repository a data model representation of the discovered 2VPN topology. The DP-signaled 2VPN data model is shown in Figure 46 on page 103, and the BGP-signaled 2VPN data model is shown in Figure 47 on page 104. The VAN modeling for Ethernet-VAN VPWS and VPS is shown in Figure 48 on page 105. The EVC modeling for Metro Ethernet services is shown in Figure 49 on page 106 and Figure 50 on page EMC Ionix MPS Manager Version 9.0 Discovery Guide

103 Discovery of 2VPN Objects Peer dpprotocolendpoint Endpoint1 ConnectedTo dpadjacency Endpoint2 ConnectedTo dpprotocolendpoint HostedBy ayeredover HostedBy VPN ComposedOf Connected- Systems ComposedOf Forwarder Forwarder Connected- Systems ComposedOf ForwarderEndpoint ayeredover Termination1 Terminates Peer PseudoWire ayeredover Termination2 Terminates ComposedOf ForwarderEndpoint ayeredover SP SPHop NextHop SPHop NextHop SPHop CE PE P P PE CE egend: Hosts MPSService Figure 46 DP-signaled 2VPN data model Relationships 2VPN discovery process 103

104 Discovery of 2VPN Objects VPNPeer VRF Exports Imports RouteTarget Imports Exports VRF HostedBy ComposedOf Implements ComposedOf HostedBy Connected- Systems ComposedOf Forwarder VPN ComposedOf ComposedOf Forwarder Connected- Systems ComposedOf ForwarderEndpoint ayeredover Termination1 Terminates Peer PseudoWire ayeredover Termination2 Terminates ComposedOf ForwarderEndpoint ayeredover SP ConnectedTo SPHop NextHop SPHop NextHop SPHop ConnectedTo CE PE P P PE CE egend: Hosts MPSService Relationships Figure 47 BGP-signaled 2VPN data model 104 EMC Ionix MPS Manager Version 9.0 Discovery Guide

105 Discovery of 2VPN Objects PE PE VAN ayeredover ayeredover ayeredover ayeredover ayeredover IF Forwarder ComposedOf VPN ComposedOf Forwarder IF ComposedOf ComposedOf ComposedOf ComposedOf ComposedOf ForwarderEndpoint Terminates PseudoWire Terminates ForwarderEndpoint ayeredover ayeredover ayeredover SP ayeredover Discovered objects SPHop Postprocessed-created objects ayeredover IF ayeredover IF Figure 48 VAN modeling in the 2VPN data model 2VPN discovery process 105

106 Discovery of 2VPN Objects PE PE EVC ayeredover Forwarder ComposedOf VPN ComposedOf Forwarder ComposedOf ComposedOf ComposedOf ComposedOf ComposedOf ForwarderEndpoint Terminates PseudoWire Terminates ForwarderEndpoint ayeredover ayeredover ayeredover TerminatedBy SP TerminatedBy ayeredover EVCEndPoint SPHop EVCEndPoint ayeredover Interface ayeredover Interface Discovered objects Postprocessed-created objects Figure 49 EVC modeling in the 2VPN data model (E-M-E Metro Ethernet network) 106 EMC Ionix MPS Manager Version 9.0 Discovery Guide

107 Discovery of 2VPN Objects PE EVC PE ayeredover Forwarder ComposedOf VPN ComposedOf Forwarder ComposedOf ComposedOf ComposedOf ComposedOf ComposedOf ForwarderEndpoint Terminates PseudoWire Terminates ForwarderEndpoint ayeredover ayeredover ayeredover TerminatedBy SP TerminatedBy ayeredover EVCEndPoint SPHop EVCEndPoint ayeredover ayeredover ayeredover ayeredover Interface or Port Interface Interface Interface or Port Discovered objects Postprocessed-created objects Figure 50 EVC modeling in the 2VPN data model (MPS Only Metro Ethernet network) Note: Typically, every relationship has an inverse relationship. For example, the relationship Underlying is the inverse relationship of ayeredover. Table 2 on page 61 and Table 3 on page 65 present descriptions of the dpprotocolendpoint, dpadjacency, Forwarder, ForwarderEndpoint, PseudoWire, VRF, RouteTarget, VPN, VAN, and EVC classes. More detailed descriptions of these classes are available in the EMC Ionix MPS Manager User Guide. The discovery and modeling of the dpprotocolendpoint and dpadjacency objects is specific to DP-signaled 2VPNs. The discovery and modeling of the VRF and RouteTarget objects is specific to BGP-signaled 2VPNs. 2VPN discovery process 107

108 Discovery of 2VPN Objects SNMP and CI discovery The MPS Topology Server discovers 2VPN-specific objects by probing the router and switch objects that are imported from IP Availability Manager. Table 8 on page 108 identifies the 2VPN discovery sources, and Table 5 on page 78 describes the targeted DP adjacency discovery sources. Table 8 Discovery sources for MPS DP- and BGP-signaled 2VPNs DP-signaled 2VPNs 1 BGP-signaled 2VPNs 1 Device/platform VPWS 2 VPS 2 VPWS VPS 2 Cisco IOS Cisco IOX CISCO-IETF-PW-MIB, CISCO-IETF-PW-MPS-MIB CISCO-IETF-PW-MIB, CISCO-IETF-PW-MPS-MIB CI Not applicable Not applicable CISCO-IETF-PW-MIB, CISCO-IETF-PW-MPS-MIB Huawei CI Not supported Juniper M/T Not supported CI JUNIPER-VPN-MIB JUNIPER-VPN-MIB Juniper ERX CI CI Not supported Not supported 1 SNMP-discovered objects are monitored for status, but CI-discovered objects are not. 2 CI discovery gathers VAN-related information and associates VANs with discovered VPWS/VPS instances. Per-device discovery for 2VPN Appendix A, MIBs Accessed for Discovery and Remote Ping, provides a description of the discovery MIB objects that are polled by an SNMP discovery probe. Appendix B, CI Commands Invoked for Discovery and SP Ping, provides a description of the commands that are invoked by a CI discovery session. Per-device (Phase 2) discovery for 2VPN pertains to the MPS Topology Server discovery of 2VPN objects on a per-router or per-switch basis. During this phase of the 2VPN discovery process, the MPS Topology Server creates instances of the following classes for each discovered routing device that is operating as a PE: ForwarderEndpoint on page 109 dpprotocolendpoint (targeted) on page 109 VRF and RouteTarget on page EMC Ionix MPS Manager Version 9.0 Discovery Guide

109 Discovery of 2VPN Objects ForwarderEndpoint In an DP-signaled 2VPN, the MPS Topology Server creates a ForwarderEndpoint instance for each discovered virtual circuit identifier (VC ID). The VC ID identifies a particular pseudowire and represents the two virtual circuits that are associated with the pseudowire. One virtual circuit is carried over an outgoing SP, and the other is carried over an incoming SP. Together, the two virtual circuits provide bidirectional communication for a customer. dpprotocolendpoint (targeted) In a BGP-signaled 2VPN, the MPS Topology Server creates a ForwarderEndpoint instance for each discovered incoming VC ID/ outgoing VC ID pair. The incoming VC ID identifies one virtual circuit of a particular pseudowire, and the outgoing VC ID identifies the other virtual circuit. In an environment that is using DP signaling to establish 2VPNs, the MPS Topology Server discovers the PE devices and the DP speakers that are associated with the 2VPNs. It creates an dpprotocolendpoint instance for each discovered DP speaker, and sets the IsTargetedPeer attribute of each instance to True, to indicates that each instance s termination point is to a targeted peer. DP-signaled 2VPNs use DP signaling to construct, advertise, maintain, and delete pseudowires. Here are some relationships that are created for dpprotocolendpoint (targeted): dpprotocolendpoint relationship HostedBy Relates an dpprotocolendpoint to the PE device that hosts the DP speaker that is represented by the dpprotocolendpoint. dpprotocolendpoint relationship ayeredover Points from an dpprotocolendpoint to the interface and IP address, on the host PE device, that are associated with the dpprotocolendpoint. dpprotocolendpoint relationship Peer Points from an dpprotocolendpoint to the endpoint at the other end of the dpadjacency. Because an DP session is TCP-based, a peer dpprotocolendpoint can terminate on a PE device that is multiple ayer 3 hops away. VRF and RouteTarget In an environment that is using BGP signaling to establish 2VPNs, the MPS Topology Server creates a VRF instance and a RouteTarget instance for each discovered VRF and route target that are associated with the 2VPN. BGP-signaled 2VPNs not only use BGP signaling to construct, advertise, maintain, and delete pseudowires, but also use BGP and route targets to discover all the VRFs that belong to an 2VPN. In a BGP-signaled VPS, the route target is the same for the VPS across all VRFs/PEs that belong to the VPS. The route target is the VPS ID for a BGP-signaled VPS. 2VPN discovery process 109

110 Discovery of 2VPN Objects Postprocessing discovery for 2VPN As with the discovery and modeling of 3VPNs, the MPS Topology Server relates VRFs and RouteTargets through the Imports/ImportedBy and Exports/ExportedBy relationship sets, and then discovers which interfaces are associated with each VRF. By matching the VRF interfaces to the ForwarderEndpoint interfaces, the MPS Topology Server discovers which Forwarders, ForwarderEndpoints, and PseudoWires are part of a VPN. VRF and RouteTarget on page 125 describes additional relationships that are created for VRFs and RouteTargets. During this phase (Phase 3) of the 2VPN discovery process, which starts after per-device discovery completes, the MPS Topology Server creates instances of the following classes by combining the information that is collected during per-device 2VPN and MPS discovery: PseudoWire on page 110 Forwarder on page 112 dpadjacency (targeted) on page 113 VPN on page 113 VAN on page 114 EVC on page 114 Also, during this phase, the MPS Topology Server creates the relationships that associate the 2VPN with the underlying SPs. PseudoWire In an DP-signaled 2VPN, the MPS Topology Server checks the VC IDs and peer ForwarderEndpoint IP addresses that are associated with the discovered ForwarderEndpoints, and creates a PseudoWire instance for each complementary match. For example, due to the following complementary match, the MPS Topology Server will create a PseudoWire instance between ForwarderEndpoint1 and ForwarderEndpoint2: ForwarderEndpoint1: VC ID = 122, peer IP = , local IP = ForwarderEndpoint2: VC ID = 122, peer IP = , local IP = In a BGP-signaled 2VPN, the MPS Topology Server checks the incoming VC ID/ outgoing VC ID pairs that are associated with the discovered ForwarderEndpoints, and creates a PseudoWire instance for each complementary match. For example, due to the following complementary match, the MPS Topology Server will create a PseudoWire instance between ForwarderEndpointA and ForwarderEndpointB: ForwarderEndpointA: incoming VC ID/ outgoing VC ID = / ForwarderEndpointB: incoming VC ID/ outgoing VC ID = / EMC Ionix MPS Manager Version 9.0 Discovery Guide

111 Discovery of 2VPN Objects A PseudoWire is TerminatedBy two ForwarderEndpoints, where one ForwarderEndpoint is HostedBy one PE device, and the second ForwarderEndpoint is HostedBy another PE device. The PseudoWire is associated with a pair of SPs, and provides a bidirectional data path between the two PE devices. The SPs can be TE SPs or DP SPs. Because the MPS Topology Server can discover SPs that traverse a mixture of multi-vendor devices as long as the SPs originate and terminate on same-vendor devices, the same can be said of PseudoWires. For example, the MPS Topology Server can discover a PseudoWire that traverses any mixture of Cisco and Juniper M/T devices, as long as the PseudoWire originates and terminates on same-vendor PE devices (a pair of Cisco PEs, for example). The MPS Topology Server relates a ForwarderEndpoint with a PseudoWire and other discovered objects through the following computed relationships: ForwarderEndpoint relationship Terminates Relates a ForwarderEndpoint to the PseudoWire that is terminated by the ForwarderEndpoint. ForwarderEndpoint relationship ayeredover Points from a ForwarderEndpoint to the pair of SPs that are underlying the PseudoWire. Also points to the interface, on the host PE device, that is associated with the ForwarderEndpoint. ForwarderEndpoint relationship Underlying For a ForwarderEndpoint that is associated with an Ethernet VAN, points from the ForwarderEndpoint to the VAN. ForwarderEndpoint relationship Peer Points from a ForwarderEndpoint to the ForwarderEndpoint that terminates the other end of the PseudoWire. ForwarderEndpoint relationship PartOf Points to the Forwarder to which this ForwarderEndpoint belongs. Points to the VPN to which this ForwarderEndpoint belongs. ForwarderEndpoint relationship HostedBy Relates a ForwarderEndpoint to the PE device that is hosting the ForwarderEndpoint. BGP-signaled 2VPN only: ForwarderEndpoint relationship RT Relates a ForwarderEndpoint to the RouteTarget of the 2VPN to which the ForwarderEndpoint belongs. 2VPN discovery process 111

112 Discovery of 2VPN Objects Some computed relationships for PseudoWires are: PseudoWire relationship ayeredover Points from a PseudoWire to the pair of SPs that are underlying the PseudoWire. Points to the interface, on the host PE device, that is associated with the PseudoWire. DP-signaled 2VPN only: Points from a PseudoWire to the dpadjacency that is providing the signaling for the 2VPN to which the PseudoWire belongs. PseudoWire relationship VANs For a PseudoWire that is associated with an Ethernet VAN, points from the PseudoWire to the VAN. Forwarder A Forwarder is hosted by a PE device and contains the procedures to make the switching and forwarding decisions for an 2VPN. In VPWS, a Forwarder binds exactly one MPS-side PseudoWire to exactly one customer-side Attachment Circuit a VAN or an Ethernet port, for example that is attached to a CE. A VPWS Forwarder has exactly one ForwarderEndpoint. In VPS, a Forwarder binds a set of PseudoWires to an Attachment Circuit. A VPS Forwarder has multiple ForwarderEndpoints. For a VPWS discovered on a PE device, the MPS Topology Server creates a Forwarder instance for the ForwarderEndpoint that it discovered and created for the VPWS on the PE device. For a VPS discovered on a PE device, the MPS Topology Server creates a Forwarder instance for the set of ForwarderEndpoints that it discovered and created for the VPS on the PE device. The MPS Topology Server relates a Forwarder with its one or more ForwarderEndpoints and other discovered objects through the following computed relationships: Forwarder relationship ComposedOf Relates the Forwarder to its one or more ForwarderEndpoints. Forwarder relationship ayeredover Points from a Forwarder to all SPs that are underlying the one or more PseudoWires that are terminated by the one or more ForwarderEndpoints that are part of the Forwarder. Forwarder relationship Underlying Points from a Forwarder to the one or more PseudoWires that are terminated by the one or more ForwarderEndpoints that are part of the Forwarder. For a Forwarder that is associated with an Ethernet VAN, points from the Forwarder to the VAN. Forwarder relationship HostedBy Relates a Forwarder to the PE device that is hosting the Forwarder. 112 EMC Ionix MPS Manager Version 9.0 Discovery Guide

113 Discovery of 2VPN Objects dpadjacency (targeted) In an environment that is using DP signaling to establish 2VPNs, the MPS Topology Server matches various attributes (ocaladdress, PeerAddress) that are associated with the dpprotocolendpoints that are discovered on different PE devices, and creates an dpadjacency instance for each complementary match. The MPS Topology Server sets each instance s istargeted attribute to True, to indicates that the DP session is targeted. An dpadjacency is ConnectedTo two dpprotocolendpoints, where one dpprotocolendpoint is HostedBy one PE device, and the second is HostedBy another PE device. The dpadjacency provides a bidirectional signaling path through which the two PE devices exchange VC ID and other types of information for the purpose of constructing, advertising, maintaining, or deleting PseudoWires between the two PE devices. Here are some other relationships that are computed for dpadjacency (targeted): dpadjacency relationship Endpoint1 Points from an dpadjacency to the dpprotocolendpoint that has the lower IP address of the two endpoints that are associated with the dpadjacency. dpadjacency relationship Endpoint2 Points from an dpadjacency to the dpprotocolendpoint that has the higher IP address of the two endpoints that are associated with the dpadjacency. dpadjacency relationship Underlying Points from an dpadjacency to the one or more PseudoWires that are associated with the dpadjacency. VPN For discovered DP-signaled 2VPNs, the MPS Topology Server infers VPNs from Forwarder, ForwarderEndpoint, and PseudoWire instances and the relationships between the instances. An DP-signaled 2VPN is composed of Forwarders, ForwarderEndpoints, and PseudoWires. In an DP-signaled VPS, the VC ID is the same for each pseudowire that belongs to the VPS. The VC ID is the VPS ID for an DP-signaled VPS. For discovered BGP-signaled 2VPNs, the MPS Topology Server infers VPNs from Forwarder, ForwarderEndpoint, PseudoWire, VRF, and RouteTarget instances and the relationships between the instances. The MPS Topology Server matches the underlying interfaces of the VRFs with the underlying interfaces of the ForwarderEndpoints to determine which Forwarders, ForwarderEndpoints, and PseudoWires belong to a VPN. A BGP-signaled ayer 2 VPN is composed of Forwarders, ForwarderEndpoints, PseudoWires, VRFs, and RouteTargets. In a BGP-signaled VPS, the route target is the same for the VPS across all PEs that belong to the VPS. The route target is the VPS ID for a BGP-signaled VPS. For a VPN that is associated with an Ethernet VAN, the VPN relationship Underlying points to the VAN. 2VPN discovery process 113

114 Discovery of 2VPN Objects VAN The MPS Topology Server discovers encapsulated VAN information from physical or logical interfaces, CE-facing interfaces, or from PE-facing interfaces. Those interfaces are associated with certain 2VPNs. A VAN is ayeredover a single VPWS or VPS, two or more Forwarders, and two or more interfaces. EVC The MPS Topology Server examines the EVCId attribute of the EVCEndPoints to determine which EVCEndPoints belong to an EVC. For each group of EVCEndPoints that have the same EVCId, the MPS Topology Server creates an EVC. 2VPN association with underlying SPs Through a configuration file, a user can specify an EVC-to-PseudoWire ayeredover relationship for EVCs. The relationship enables the MPS Topology Server to pinpoint an impacted EVC due to an underlying MPS failure, even when the endpoints of the EVC do not have EVC status. Instructions for specifying the ayeredover relationship are given in Appendix C, Manually Stitching EVCs to PseudoWires. The MPS Topology Server maps the Forwarders, ForwarderEndpoints, and PseudoWires of an 2VPN to the appropriate SPs, and then creates a ayeredover relationship from the Forwarders, ForwarderEndpoints, and PseudoWires to the SPs. A ForwarderEndpoint and a peer ForwarderEndpoint are layered over an SP if: The PE device that is hosted by the ForwarderEndpoint is the source device for the SP. The PE device that is hosted by the peer ForwarderEndpoint is the destination device for the SP. If multiple SPs exist between the two PEs, the ForwarderEndpoint and the peer are layered over the first found SP that matches the criteria. This algorithm results in the layering of both the ForwarderEndpoint and the peer over a pair of SPs, where the one SP is incoming and the other is outgoing. The PseudoWire that is terminated by the ForwarderEndpoint and its peer, in addition to the Forwarders to which the ForwarderEndpoint and its peer belong, are also layered over the pair of SPs. To compute Forwarder, ForwarderEndpoint, and PseudoWire ayeredover relationships to SPs, the MPS Topology Server: Traverses ForwarderEndpoint Peer, HostedBy, Terminates, and PartOf (inverse of ComposedOf) relationships. Traverses SP Source relationships. Compares SP identifiers (SP IDs) with PE addresses. 114 EMC Ionix MPS Manager Version 9.0 Discovery Guide

115 Discovery of 2VPN Objects Relationships between the 2VPN, MPS, and transport models Figure 51 on page 115 and Figure 52 on page 116 show most of the objects and relationships that can appear in the 2VPN and MPS data models. The underlying transport network objects in the model, shown as white text on black background, are managed by IP Availability Manager. From CE PE HostedBy ConnectedSystems Source HostedBy MPSService Card M Forwarder C VPN dpprotocolendpoint Interface ComposedOf NC ForwarderEndpoint Endpoint1 Interface Termination1 Peer ConnectedTo Card MPSService HostedBy P M M Same as Figure 37 on page 89 SP Terminates PseudoWire C dpadjacency Peer Card Terminates Interface Termination2 ConnectedTo NC ForwarderEndpoint Endpoint2 Interface ComposedOf Card M Forwarder C dpprotocolendpoint MPSService HostedBy PE To CE Destination ConnectedSystems HostedBy egend: NC = NetworkConnection C = ComposedOf = ayeredover M = MPSInterfaces Figure 51 Relationships between the DP-signaled 2VPN, MPS, and transport models 2VPN discovery process 115

116 Discovery of 2VPN Objects From CE PE CEs ConnectedTo ConnectedSystems Source HostedBy HostedBy MPSService Card M V Forwarder C C VRF Interface ComposedOf NC ForwarderEndpoint Imports Interface Termination1 Peer Exports Card MPSService HostedBy P M M Same as Figure 37 on page 89 SP Terminates PseudoWire C VPN Implements RouteTarget VPNPeer Card Terminates Interface Termination2 Imports NC ForwarderEndpoint Exports Interface ComposedOf Card M V Forwarder C C VRF MPSService HostedBy PE To CE Destination ConnectedSystems ConnectedTo CEs HostedBy egend: NC = NetworkConnection C = ComposedOf = ayeredover M = MPSInterfaces V = VRFInterfaces Figure 52 Relationships between the BGP-signaled 2VPN, MPS, and transport models 116 EMC Ionix MPS Manager Version 9.0 Discovery Guide

117 CHAPTER 6 Discovery of 3VPN Objects This chapter describes how MPS Manager discovers and models 3VPN topology objects. It consists of the following sections: 3VPN discovery overview More about 3VPNs and 3VPN discovery VPN discovery process Discovery of 3VPN Objects 117

118 Discovery of 3VPN Objects 3VPN discovery overview For 3VPN discovery, the MPS Topology Server component of MPS Manager is able to discover and model MPS ayer 3 VPN entities. It relates the discovered 3VPNs to the MPS and transport domains by creating logical and physical relationships between the 3VPN entities and the underlying MPS entities and ayer 3 devices. The MPS Topology Server requires a evel 3 VPN feature license for the discovery of 3VPNs. The EMC Ionix ITOps System Administration Guide provides information about licensing. More about 3VPNs and 3VPN discovery Unicast 3VPN data plane Multicast 3VPN data plane 3VPNs are provider-provisioned ayer 3 VPNs that extend the customer s IP (ayer 3) connectivity through an MPS network. They use extensions to the existing Internet routing protocol BGPv4 to interconnect customer sites. ike 2VPNs, 3VPNs depend entirely on the PE devices. Unlike 2VPNs, 3VPNs require that the PE devices participate in the customer s routing algorithms. The PE devices run the routing protocols of the customer s choice, and they support the IP address scheme that is implemented by the customer. For unicast or multicast 3VPNs, the signaling for the control plane is Multiprotocol Border Gateway Protocol, which is referred to as BGP in the discussions that follow. The PE devices in an 3VPN use BGP signaling to exchange reachability information with one another. For unicast 3VPNs, the signaling for the data plane is the VPN tunnel. For multicast 3VPNs, the signaling for the data plane is the point-to-multipoint (P2MP) SP. The VPN tunnel consists of two SPs between a pair of PE devices that are participating in a unicast 3VPN. One SP is outgoing, and the other is an incoming. The VPN tunnel and its SPs provide bidirectional communication. The P2MP SP consists of multiple subsps from a source PE device to the multiple destination PE devices that are participating in a multicast 3VPN. Each subsp is outgoing. The P2MP SP and its subsps provide unidirectional communication. 118 EMC Ionix MPS Manager Version 9.0 Discovery Guide

119 Discovery of 3VPN Objects 3VPN encapsulation The ingress PE attaches a VPN label and a tunnel label to each customer IP packet, and forwards each packet over the SP. Figure 53 on page 119 shows the encapsulation and data transport. Data ayer 2 header Tunnel label (SP) VPN label IP header Customer IP datagram Time A. ayer 3 data encapsulation in accordance to RFC 2547bis Punultimate Tunnel label hop popping VPN label xx PE xx P xx P xx PE Data Ingress PE device Intermediate P devices B. Transporting ayer 3 VPN packets over an MPS network Egress PE device Forward data to end-user xx CE Destination CE device Figure 53 MPS 3VPN encapsulation and transport When the MPS packet arrives at the egress PE, the egress PE uses the VPN label to deliver the data as a traditional IP packet to the correct CE device. The CE uses standard IP routing procedures to forward the data to its final destination. 3VPN components Figure 54 on page 120 and Figure 55 on page 121 identify the basic components of an 3VPN. Because an 3VPN is designed for interconnecting routing devices, each PE and CE in the figure must be a router or a routing-capable switch. More about 3VPNs and 3VPN discovery 119

120 Discovery of 3VPN Objects MPS network BGP session Spoke 2 Customer A, site 1 Customer A, site 2 Hub PEa BGP session Customer A, site 3 Customer B, site 3 Spoke 1 Mesh PEb BGP session PEc Mesh Customer B, site 4 VPN tunnel (2 SPs) Access link VPN 1 (hub-and-spoke) VPN 2 (full-mesh) VRF instances (3) VRF instances (2) PEa PEb PEc Exports route target RT2 Imports route target RT1 Exports route target RT1 Imports route target RT2 Exports route target RT1 Imports route target RT2 PEb PEc Rc Exports route target RT3 Imports route target RT3 Exports route target RT3 Imports route target RT3 Figure 54 Using unicast 3VPNs to connect sites over an MPS network 120 EMC Ionix MPS Manager Version 9.0 Discovery Guide

121 Discovery of 3VPN Objects Source MPS network Receiver Ingress PE BGP session Egress PE Sender, site 1 Receiver A, site 2 CEa PEa PEb BGP session BGP session CEb Egress PE Egress PE Receiver C, site 4 Receiver B, site 3 CEd PEd PEc CEc Receiver P2MP SP with three subsps MulticastVPN (sender-only, receiver-only) VRF instances (4) PEa PEb PEc Rc PEd Rc Exports route target RT4 Imports route target RT5 Exports route target RT5 Imports route target RT4 Exports route target RT5 Imports route target RT4 Exports route target RT5 Imports route target RT4 Receiver Figure 55 Using multicast 3VPNs to connect sites over an MPS network An 3VPN consists of multiple access links, multiple VPN routing and forwarding (VRF) tables, and multiple VPN tunnels or multiple P2MP SPs. An 3VPN can be configured to connect two or more customer sites. Central to an 3VPN is the VRF, which allows for separate and private VPN forwarding decisions to co-exist within a PE device. A VRF is created on a per VPN basis within each PE. The VRF is the fundamental mechanism that enables the partitioning of individual customers over the shared IP routed infrastructure. Note: A VRF can be configured to transport unicast traffic, multicast traffic, or both. Even if a service provider s customers have overlapping IP address spaces, for example, 10.x.x.x networks, the VRFs effectively segment those addresses so that the control traffic and the data traffic remain exclusively within the correct VPNs. 3VPN discovery The MPS Topology Server is able to discover 3VPNs that employ either the full-mesh topology or the hub-and-spoke topology. Route targets, shown in Figure 54 on page 120 and Figure 55 on page 121, are the means by which 3VPN topology types are configured. More about 3VPNs and 3VPN discovery 121

122 Discovery of 3VPN Objects 3VPN discovery process During the 3VPN discovery process, the MPS Topology Server creates within its repository a data model representation of the discovered 3VPN topology. The 3VPN data model is shown in Figure 56 on page 122. Multicast VPN modeling is shown in Figure 57 on page 123. Connected- Systems VPN Connected- Systems ComposedOf Implements ComposedOf HostedBy VRF Exports Imports RouteTarget VPNPeer Imports Exports VRF HostedBy SP ConnectedTo SPHop NextHop SPHop NextHop SPHop ConnectedTo CE PE P P PE CE egend: Hosts MPSService Relationships Figure 56 3VPN data model 122 EMC Ionix MPS Manager Version 9.0 Discovery Guide

123 Discovery of 3VPN Objects MulticastGroup PE ayeredover ayeredover PE VRF ComposedOf MulticastVPN ComposedOf VRF ayeredover ayeredover ayeredover To CE IF SP data collection P2MP SP (SP) ComposedOf SP data collection IF To CE subsp (SP) ayeredover ayeredover SPHop Discovered objects Postprocessed-created objects ayeredover IF ayeredover IF Figure 57 Multicast VPN modeling in the 3VPN data model Note: Typically, every relationship has an inverse relationship. For example, the relationship Underlying is the inverse relationship of ayeredover. Table 2 on page 61 and Table 3 on page 65 present descriptions of the VRF, RouteTarget, VPN, MulticastVPN, and MulticastGroup classes. More detailed descriptions of these classes are available in the EMC Ionix MPS Manager User Guide. 3VPN discovery process 123

124 Discovery of 3VPN Objects SNMP and CI discovery The MPS Topology Server discovers 3VPN-specific objects by probing the router and switch objects that are imported from IP Availability Manager. Table 9 on page 124 identifies the 3VPN discovery sources. Table 9 Discovery sources for MPS 3VPNs Device/platform 3VPN objects 1 Cisco IOS Cisco IOX Huawei Juniper M/T Juniper ERX MPS-VPN-MIB If SNMP discovery fails or is not supported by the Cisco IOS device, MPS Manager uses CI discovery to discover the 3VPN objects. MPS-3VPN-STD-MIB MPS-VPN-MIB If SNMP discovery fails or is not supported by the Huawei device, MPS Manager uses CI discovery to discover the 3VPN objects. JUNIPER-VPN-MIB and CI If SNMP discovery fails or is not supported by the Juniper M/T device, MPS Manager uses CI discovery to discover the 3VPN objects. MPS Manager also uses CI discovery to discover multicast groups and their relationship to P2MP SPs. CI 1 SNMP-discovered objects are monitored for status, but CI-discovered objects are not. Per-device discovery for 3VPN Appendix A, MIBs Accessed for Discovery and Remote Ping, provides a description of the discovery MIB objects that are polled by an SNMP discovery probe. Appendix B, CI Commands Invoked for Discovery and SP Ping, provides a description of the commands that are invoked by a CI discovery session. Per-device (Phase 2) discovery for 3VPN pertains to the discovery of 3VPN objects on a per-router or per-switch basis. During this phase of the 3VPN discovery process, the MPS Topology Server creates instances of the following classes for each discovered routing device that is operating as a PE: VRF RouteTarget 124 EMC Ionix MPS Manager Version 9.0 Discovery Guide

125 Discovery of 3VPN Objects VRF and RouteTarget The MPS Topology Server relates VRFs and RouteTargets through the Imports/ImportedBy and Exports/ExportedBy relationship sets, and then discovers which interfaces are associated with each VRF. RouteTargets are used to identify peering relationships between VRFs and to identify different ayer 3 VPN types (full-mesh, hub-and-spoke). Some computed relationships for VRFs are: VRF relationship SendsRoutesTo Points from a VRF to all other VRFs that import a RouteTarget that this VRF exports. The other VRFs get route advertisements from this VRF by having a route target on their import list that matches a route target on this VRF s export list. VRF relationship ReceivesRoutesFrom Points from a VRF to all other VRFs that export a RouteTarget that this VRF imports. The other VRFs advertise routes to this VRF by having a route target on their export list that matches a route target on this VRF s import list. VRF relationship VPNPeer Points from a VRF to all other VRFs that are related to this VRF by both SendsRoutesTo and ReceivesRoutesFrom. VRF relationship CEs Points from a VRF to the CE or multi-vrf CE device attached to this VRF. VRF relationship HostedBy Postprocessing discovery for 3VPN Relates a VRF to the PE device that is hosting this VRF. During this phase (Phase 3) of the 3VPN discovery process, which starts after per-device discovery completes, the MPS Topology Server creates instances of the following classes by combining the information that is collected during per-device 3VPN and MPS discovery: VPN MulticastVPN MulticastGroup Also, during this phase, the MPS Topology Server creates the relationships that associate the 3VPN with the underlying SPs. 3VPN discovery process 125

126 Discovery of 3VPN Objects VPN and MulticastVPN The MPS Topology Server infers ayer 3 VPNs from VRF and RouteTarget instances and the relationships between the instances. It infers and creates the following types of VPNs: Full-mesh Hub-and-spoke The MPS Topology Server creates a full-mesh VPN for each RouteTarget (R1, for example) that has the same set of VRFs in its Imports/ImportedBy and Exports/ExportedBy relationship sets. The VPN is ImplementedBy R1 and is ComposedOf the VRFs that are ExportedBy (and ImportedBy) R1. The MPS Topology Server creates a hub-and-spoke VPN for each pair of RouteTargets (R2 and R3, for example) that has the following characteristics: The R2 relationship ImportedBy is identical to the R3 relationship ExportedBy. The set of VRFs that export R2 but do not import R2 is identical to the set of VRFs that import R3 but do not export R3. The R2 relationship ExportedBy is not identical to the R3 relationship ImportedBy, or at least one VRF exists that both Imports and Exports R2, or both conditions are true. The VPN is ImplementedBy the two RouteTargets R2 and R3. The VPN is ComposedOf all the VRFs in the R2 relationship ImportedBy and the R2 relationship ExportedBy. VPN relationship Spokes is the set of VRFs in the R2 relationship ExportedBy but not in the R2 relationship ImportedBy. VPN relationship Hubs includes the rest of the VRFs. The MPS Topology Server accesses certain MIB objects in the JUNIPER-MPS-MIB to determine whether the VPN is a unicast VPN or a multicast VPN. If the VPN is associated with a P2MP SP, the MPS Topology Server models (represents) the VPN as an instance of the MulticastVPN class. Otherwise, the MPS Topology Server models the VPN as an instance of the VPN class. A unicast VPN has a ayeredover one-to-many relationship to one or more TE tunnels or DP SPs. A multicast VPN has a ayeredover one-to-many relationship to one or more P2MP SPs. MulticastGroup The MPS Topology Server performs CI discovery on Juniper M/T Series routers that are running JUNOS 9.0 or higher to discover multicast groups and their relationship to P2MP SPs. When a multicast group is found, the MPS Topology Server uses the P2MP SP to associate the multicast group with a multicast VPN. MultcastGroups have a ayeredover many-to-one relationship to a MulticastVPN. They also have a ayeredover many-to-one relationship to an inclusive P2MP SP. 126 EMC Ionix MPS Manager Version 9.0 Discovery Guide

127 Discovery of 3VPN Objects 3VPN association with underlying SPs The MPS Topology Server maps the VRFs of a unicast 3VPN to the appropriate SPs, and then creates a ayeredover relationship from the VPN to which the VRFs belong to the SPs. A VRF and a peer VRF are mapped to an SP if: The PE device that is hosted by the VRF is the source device for the SP. The PE device that is hosted by the peer VRF is the destination device for the SP. If multiple SPs exist between the two PEs, the VRF and the peer are mapped to the first found SP that matches the criteria. This algorithm results in the mapping of both the VRF and the peer to a pair of SPs, where the one SP is incoming and the other is outgoing. To map VRFs to SPs, the MPS Topology Server traverses VRF VPNPeer relationships, VRF HostedBy relationships, and SP Source relationships, and compares SP identifiers (SP IDs) with PE device addresses. Relationships between the 3VPN, MPS, and transport models Figure 58 on page 128 shows most of the objects and relationships that can appear in the 3VPN and MPS data models. The underlying transport network objects in the model, shown as white text on black background, are managed by IP Availability Manager. 3VPN discovery process 127

128 Discovery of 3VPN Objects From CE CEs ConnectedTo HostedBy ConnectedSystems PE Source HostedBy MPSService Card M V Source VRF ComposedOf Interface NC SPHop Imports Exports Interface Card M VPNPeer MPSService HostedBy NextHop SP RouteTarget Implements VPN P M Card Interface NC SPHop Exports Imports Interface Card M V Destination VRF ComposedOf MPSService HostedBy PE Destination To CE HostedBy ConnectedTo CEs ConnectedSystems egend: NC = NetworkConnection C = ComposedOf = ayeredover M = MPSInterfaces Figure 58 Relationships between the 3VPN, MPS, and transport models 128 EMC Ionix MPS Manager Version 9.0 Discovery Guide

129 CHAPTER 7 Discovery of BGP Objects This chapter describes how MPS Manager discovers and models BGP topology objects. It consists of the following sections: BGP discovery overview Associating BGP sessions with MPS 3VPNs Resynchronizing BGP topologies BGP discovery details Discovery of BGP Objects 129

130 Discovery of BGP Objects BGP discovery overview When the MPS-BGP cross-domain correlation feature is enabled, the MPS Topology Server component of MPS Manager imports from IP Availability Manager a BGP topology collection set named BGP-System. BGP-System contains BGP-enabled router and switch devices. The MPS Topology Server uses SNMP and the BGP4-MIB to query the imported routers and switches for BGP information, and uses instances of certain EMC Ionix object classes to create within its repository a data model representation of the discovered BGP topology. The BGP data model is shown in Figure 59 on page ConsistsOf Router HostedBy BGPService ComposedOf Card ConnectedSystems ConnectedTo AccessedVia ConsistsOf Interface BGPProtocolEndpoint Endpoint1 AutonomousSystem BGPSession Endpoint2 Interface BGPProtocolEndpoint ConsistsOf Card ComposedOf AccessedVia BGPService ConnectedTo ConsistsOf HostedBy Router ConnectedSystems = ayeredover Figure 59 BGP data model The MPS Topology Server also invokes CI commands to query the managed network for BGP route reflector information. 130 EMC Ionix MPS Manager Version 9.0 Discovery Guide

131 Discovery of BGP Objects Associating BGP sessions with MPS 3VPNs During the postprocessing phase of discovery, the MPS Topology Server creates an UnderlyingVPN relationship between the discovered BGP services/ BGP protocol endpoints/ BGP sessions and the VPNs that are discovered during 3VPN discovery: BGPService UnderlyingVPN VPN BGPProtocolEndpoint UnderlyingVPN VPN BGPSession UnderlyingVPN VPN The UnderlyingVPN relationship is what makes MPS-BGP cross-domain correlation possible. It enables the MPS Topology Server to generate VPN-impacted events for underlying BGP sessions that are impacted by BGP failures, misconfigurations, or manually disabled BGP protocol endpoints. Resynchronizing BGP topologies BGP discovery details The MPS Topology Server imports the same BGP-enabled topology from IP Availability Manager that Network Protocol Manager for BGP imports. The two Managers perform BGP discovery independently. At times the BGP topology in the MPS Topology Server might differ from the BGP topology in Network Protocol Manager for BGP. One reason for this discrepancy is that some BGP objects in Network Protocol Manager for BGP are updated more frequently because they are instrumented. When differences occur, resynchronize the two topologies by invoking Discover All in both Managers. Consult the procedure in Manual full discovery on page 159 to invoke Discover All in the MPS Topology Server. For more information about BGP discovery, refer to the EMC Ionix Network Protocol Manager Discovery Guide. Associating BGP sessions with MPS 3VPNs 131

132 Discovery of BGP Objects 132 EMC Ionix MPS Manager Version 9.0 Discovery Guide

133 CHAPTER 8 Preparing and Initiating Discovery This chapter describes how to prepare and initiate discovery for an MPS Manager deployment. It consists of the following sections: Preparing for discovery Initiating discovery Synchronizing with IP Availability Manager Synchronizing with the MPS Topology Server Specifying a different IP Availability Manager source Preparing and Initiating Discovery 133

134 Preparing and Initiating Discovery Preparing for discovery Prepare the Global Manager for discovery Preparing an MPS Manager deployment for discovery requires configuring all component applications in the deployment so that they can form the proper physical and logical connections to one another. Some of these tasks are performed before the components are started, such as the editing of configuration files, while others are performed through the Global Console when the components are up and running. Preparing the Global Manager for discovery involves attaching the Global Console to the Global Manager and configuring the Global Manager to import topology and status from the underlying MPS Manager domain group and the underlying IP Availability Manager domains. The EMC Ionix MPS Manager Configuration Guide provides instructions for preparing the Global Manager for discovery in an MPS Manager deployment. Prepare IP Availability Manager for discovery Preparing IP Availability Manager for discovery starts with seed systems, which serve as a starting point for autodiscovery. Autodiscovery automatically discovers the managed network from the seed systems. Procedures for preparing and initiating autodiscovery are given in the EMC Ionix IP Management Suite User Guide. In addition, an administrator performs the following configuration tasks that are described in the EMC Ionix MPS Manager Configuration Guide to prepare IP Availability Manager for discovery in an MPS Manager deployment: Enables MPS light discovery (mandatory in most cases). Enables BGP light discovery for MPS-BGP cross-domain correlation (optional). Enables overlapping IP address discovery (optional). Enables interoperability with the MPS VPN-Tagging Server (optional). Creates CI device-access objects for MPS Manager (mandatory). Enables Metro Ethernet discovery (optional). 134 EMC Ionix MPS Manager Version 9.0 Discovery Guide

135 Preparing and Initiating Discovery Prepare MPS Manager for discovery To prepare MPS Manager for its initial discovery, an administrator performs the following task: Specifies one or more IP Availability Managers in the mpls.conf file. When the MPS Topology Server component of MPS Manager starts up, it adds as topology sources the IP Availability Managers that are specified in the mpls.conf file, and imports topology and CI device-access objects from the IP Availability Managers. Initiating discovery The EMC Ionix MPS Manager Configuration Guide describes the mpls.conf and other MPS Manager configuration files, and provides instructions for preparing MPS Manager for discovery. After preparing your MPS Manager deployment for discovery, you initiate an IP Availability Manager discovery for each IP Availability Manager in the deployment. Then, you initiate an MPS Manager discovery by starting the MPS Manager component servers. During startup, the MPS Topology Server: Registers with the EMC Ionix Broker. oads its.import (probe) and configuration files, including mpls.conf and mpls-tma.conf. Adds as a topology source each IP Availability Manager that is listed in the mpls.conf file. Creates in its repository an InChargeDomain object (INCHARGE-AM, for example) for each IP Availability Manager instance that is added as a topology source. Establishes a connection to each IP Availability Manager source and probes each source for router and switch topology and CI device-access objects. Imports and stores in its repository the router and switch topology that is discovered by each IP Availability Manager source. Imports and stores in its repository the CI device-access objects from the IP Availability Manager source that is exporting CI device-access objects for MPS Manager operation. Initiates its own discovery by sending SNMP polls and/or CI commands to the router and switch devices to discover the MPS, VPN, and (optional) BGP information that is needed to build the MPS, VPN, and BGP topology. Chapter 9, Understanding Discovery Results, provides information about discovery errors and their solutions. Initiating discovery 135

136 Preparing and Initiating Discovery After initial discovery, and assuming that the StopAutoAMSync parameter in the mpls.conf file is FASE (default), the MPS Topology Server imports topology from IP Availability Manager whenever IP Availability Manager completes a discovery cycle. Synchronizing with IP Availability Manager on page 136 describes how the MPS Topology Server synchronizes its discovery with the discovery of IP Availability Manager. Synchronizing with the MPS Topology Server on page 137 describes how the MPS Monitoring Server and the MPS Analysis Server components of MPS Manager synchronize their topology import with the discovery of the MPS Topology Server. Synchronizing with IP Availability Manager After an IP Availability Manager is added as a topology source, the MPS Topology Server starts two synchronization programs: One that probes the IP Availability Manager repository for router and switch topology One that probes the IP Availability Manager repository for CI device-access objects Topology synchronization The synchronization programs are independent of one another. The topology synchronization program probes for topology immediately after an IP Availability Manager is added as a topology source, and then every time thereafter whenever: The IP Availability Manager completes a discovery cycle. Note: Assumes StopAutoAMSync parameter in mpls.conf file is FASE (default). The connection to IP Availability Manager is lost and then reestablished. Each time that an IP Availability Manager completes a discovery cycle, the MPS Topology Server performs the following incremental discovery: Compares the current IP Availability Manager topology with the previously imported topology. Conducts discovery only on new devices, or on known devices that have a newer discovery timestamp. For additional information about MPS topology synchronization, see When discovery occurs on page 39 and How discovery is conducted on page EMC Ionix MPS Manager Version 9.0 Discovery Guide

137 Preparing and Initiating Discovery CI device-access object synchronization The CI device-access object synchronization program probes for CI device-access objects immediately after an IP Availability Manager is added as a topology source, and then every time thereafter whenever: The CI device-access objects have changed in the IP Availability Manager. The connection to IP Availability Manager is lost and then reestablished. Each time that the MPS Topology Server imports CI device-access objects from an IP Availability Manager, it imports all of the CI device-access objects. The import of CI device-access objects does not trigger the import of topology from IP Availability Manager. The EMC Ionix MPS Manager Configuration Guide describes how to configure CI device-access groups for MPS Manager. Synchronizing with the MPS Topology Server The MPS component servers of MPS Manager may be started in any order, meaning that the MPS Monitoring Server and the MPS Analysis Server may be started before or after the MPS Topology Server performs its initial discovery. Whenever the MPS Monitoring Server and the MPS Analysis Server are started, the MPS Manager autoconfiguration program, described in the EMC Ionix MPS Manager Configuration Guide, automatically adds the MPS Topology Server as a topology source to the MPS monitoring and analysis servers, and creates an InChargeDomain object (INCHARGE-MPS-TOPOOGY, for example) in their repositories. After the MPS Topology Server is added as a topology source, the MPS Monitoring Server and the MPS Analysis Server each start a synchronization program that probes the MPS Topology Server repository for network, MPS, VPN, and BGP topology. The synchronization program probes for topology information immediately after the MPS Topology Server is added as a topology source, and then every time thereafter whenever: The MPS Topology Server completes a discovery cycle. The connection to the MPS Topology Server is lost and then reestablished. If the MPS Topology Server is not running when the MPS Monitoring Server/ MPS Analysis Server starts up, the synchronization program periodically attempts to probe for the topology. When the MPS Topology Server becomes available, the probing succeeds. During the probing of topology, the MPS monitoring and analysis servers also learn the names of their proxy (status) sources. The MPS Monitoring Server learns the names of the IP Availability Managers that are added as topology sources to the MPS Topology Server, and the MPS Analysis Server learns the name of the MPS Monitoring Server. When MPS-BGP cross-domain correlation is enabled, the MPS Monitoring Server also learns the name of its Network Protocol Manager for BGP proxy source from the MPS Topology Server. Synchronizing with the MPS Topology Server 137

138 Preparing and Initiating Discovery MPS Monitoring Server synchronization After the MPS Topology Server adds an IP Availability Manager as a topology source, imports topology, and performs its own discovery, the MPS Monitoring Server responds by performing the following tasks: 1. Imports from the MPS Topology Server and stores in its repository: A subset of network, MPS, VPN, and BGP topology (identified in Imported topology subsets on page 140), to be used for monitoring purposes. An InChargeDomain object (INCHARGE-AM, for example) that represents the IP Availability Manager topology source. 2. Starts a remote repository (proxy) accessor probe. The probe adds the IP Availability Manager as a proxy source to the MPS Monitoring Server. To associate a network object in the repository of the MPS Monitoring Server repository with its proxy source, the object s ServiceName attribute is set to the name of the IP Availability Manager. For an object that is monitored by multiple proxy sources, the object s ServiceName attribute is set to the name of the last added active IP Availability Manager. 3. Starts another remote repository (proxy) accessor probe if MPS-BGP cross-domain correlation is enabled. The probe adds the Network Protocol Manager for BGP as a proxy source to the MPS Monitoring Server. To associate a BGP object in the repository of the MPS Monitoring Server repository with its proxy source, the object s ServiceName attribute is set to the name of the Network Protocol Manager for BGP. Thereafter, at startup or whenever the connection to the MPS Topology Server is lost and then reestablished, the MPS Monitoring Server re-imports topology from the MPS Topology Server and re-runs the proxy probes. Also, whenever the MPS Monitoring Server imports topology from the MPS Topology Server, the MPS Topology Server stores the name of the MPS Monitoring Server (INCHARGE-MPS-MONITORING, for example) as a reference for the MPS Analysis Server. 138 EMC Ionix MPS Manager Version 9.0 Discovery Guide

139 Preparing and Initiating Discovery MPS Analysis Server synchronization After the MPS Topology Server adds an IP Availability Manager as a topology source, imports topology, and performs its own discovery, the MPS Analysis Server responds by performing the following tasks: 1. Imports from the MPS Topology Server and stores in its repository a subset of network, MPS, VPN, and BGP topology (identified in Imported topology subsets on page 140), to be used for analysis purposes. It also imports the reference (INCHARGE-MPS-MONITORING, for example) that identifies the name of the MPS Monitoring Server. 2. Starts a remote repository (proxy) accessor probe. The probe creates an InChargeDomain object (INCHARGE-MPS-MONITORING, for example) that has the instance name of the MPS Monitoring Server and adds the MPS Monitoring Server as a proxy source to the MPS Analysis Server. To associate a network, MPS, VPN, or BGP object in the repository of the MPS Analysis Server with its proxy source, the object s ServiceName attribute is set to the name of the MPS Monitoring Server. Thereafter, at startup or whenever the connection to the MPS Topology Server is lost and then reestablished, the MPS Analysis Server re-imports topology from the MPS Topology Server and re-runs the proxy probe. Note that if the MPS Analysis Server imports its initial topology before the MPS Monitoring Server imports its initial topology, the MPS Analysis Server will not be able to determine its MPS Monitoring Server proxy source. However, as soon as the MPS Monitoring Server import its topology, the MPS Topology Server will send a proxy update message to the MPS Analysis Server, and the MPS Analysis Server will add the MPS Monitoring Server as a proxy source. Synchronizing with the MPS Topology Server 139

140 Preparing and Initiating Discovery Imported topology subsets Figure 60 on page 140 shows the individual topology subsets that are imported by the MPS Monitoring Server and the MPS Analysis Server. Topology Subset Imported By MPS Monitoring Server Topology Subset Imported By MPS Analysis Server Contains CI ogin Credentials (currently not used) Contains SNMPv1, v2c, and v3 Credentials class CI_AccessSetting class Router class Switch class Interface class Card class Port class NetworkConnection class SNMPAgent class MPSManager class MPSService class SP class VPN class VRF class RouteTarget class Forwarder class ForwarderEndpoint class PseudoWire class dpprotocolendpoint class dpadjacency class RsvpProtocolEndpoint class RsvpSession class BGPService class BGPProtocolEndpoint class BGPSession class EVCEndPoint class Vendor_Instrumentation_Probes class Router class Switch class Interface class Card class NetworkConnection class MPSService class SP class VPN class VRF class RouteTarget class Forwarder class PseudoWire class dpadjacency class RsvpSession class BGPService class BGPProtocolEndpoint class BGPSession class VAN class SPRedundancyGroup class MulticastGroup class EVCEndPoint class EVC Figure 60 Topology subsets imported by the MPS Monitoring and Analysis Servers The MPS Monitoring Server and the MPS Analysis Server each synchronize their topology objects with the topology objects on the MPS Topology Server. 140 EMC Ionix MPS Manager Version 9.0 Discovery Guide

141 Preparing and Initiating Discovery Other synchronizations for the MPS Monitoring Server From the MPS Topology Server, the MPS Monitoring Server also imports CI device-access objects, polling objects, and remote ping objects. The MPS Monitoring Server synchronizes its CI device-access objects with the CI device-access objects on the MPS Topology Server, synchronizes its polling objects with the polling objects on the MPS Topology Server, and synchronizes its remote ping objects with the remote ping objects on the MPS Topology Server. Note: Currently, the CI device-access objects on the MPS Monitoring Server are not used. The topology, CI device-access, polling, and remote ping synchronizations are independent of one another, meaning that a synchronization in progress does not trigger other synchronizations. As an example, when the MPS Monitoring Server detects that its polling objects are out-of-date, it re-imports the polling objects from the MPS Topology Server but does not re-import the topology, CI device-access, or remote ping objects from the MPS Topology Server. The EMC Ionix MPS Manager Configuration Guide describes how to configure CI device-access groups, polling groups, and remote ping groups for MPS Manager. Specifying a different IP Availability Manager source You can specify a different IP Availability Manager source for the MPS Topology Server by performing the following two steps: 1. In the mpls.conf file, replace the IP Availability Manager entry with the new entry. 2. Stop the MPS Topology Server, the MPS Monitoring Server, and the MPS Analysis Server and then restart them with startup command lines that contain the --norestore option. Including the --norestore option in the startup command line will start the MPS servers without restoring any saved objects from their respective repository files. Repository files are located in the BASEDIR/smarts/local/repos/icf directory. This mode of startup deletes from the repository the topology and instrumentation objects that are associated with the current IP Availability Manager source. Because the MPS service startup commands that are created during the MPS Manager installation do not contain the --norestore option, you will need to do one of the following: Temporarily modify the service startup commands by substituting --ignore-restore-errors with --norestore. Create new service startup commands or new native startup commands that contain the --norestore option. Specifying a different IP Availability Manager source 141

142 Preparing and Initiating Discovery Procedure for specifying a different IP Availability Manager source What follows is an example procedure of specifying a different IP Availability Manager source. The procedure replaces an IP Availability Manager source named INCHARGE-AM with a source named INCHARGE-AM3. Native startup commands that contain the --norestore option are included in the procedure. To specify a different IP Availability Manager source named INCHARGE-AM3: 1. Go to the BASEDIR/smarts/bin directory in the MPS Management Suite installation area and type the following command to open the mpls.conf file: sm_edit conf/mpls-t/mpls.conf Press Enter. 2. Find the section, Instances of AM Server, and then find the following five lines: InChargeDomain::InChargeDomain_INCHARGE-AM { Type = "AM" DomainName = "INCHARGE-AM" DisplayName = "INCHARGE-AM" } 3. On the InChargeDomain, DomainName, and DisplayName lines, change INCHARGE-AM to INCHARGE-AM3: InChargeDomain::InChargeDomain-AM3 { Type = "AM" DomainName = "AM3" DisplayName = "AM3" } 4. Save and close the file. The modified version of the mpls.conf file is saved to the BASEDIR/smarts/local/conf/mpls-t directory. 5. Enter the following three commands from BASEDIR/smarts/bin to stop the MPS Topology Server, the MPS Monitoring Server, and the MPS Analysis Server: sm_service stop --force ic-mpls-topology sm_service stop --force ic-mpls-monitoring sm_service stop --force ic-mpls-analysis On a Windows system, you can also stop the MPS servers by selecting Start > Programs > Administrative Tools > Services to launch the Services window, then right-clicking the service names of the MPS servers (right-clicking EMC Ionix MPS Topology Server, for example), and then selecting Stop from the pop-up menus. 142 EMC Ionix MPS Manager Version 9.0 Discovery Guide

143 Preparing and Initiating Discovery 6. Enter the following native command from BASEDIR/smarts/bin to start the MPS Topology Server: On a Windows system: start sm_server --name=incharge-mps-topoogy --config=mpls-t --norestore --output On a Windows system, including start at the beginning of the command line launches another command-line window in which the EMC Ionix process starts and runs until the process is terminated. aunching a separate window leaves the original command-line window free to receive more commands. On a UNIX system: sm_server --name=incharge-mps-topoogy --config=mpls-t --norestore --output --daemon On a UNIX system, including the --daemon option in the command line starts the EMC Ionix process running in the background, leaving the original UNIX shell free to receive more commands. The --daemon option is not a valid option for a Windows system. 7. Enter the following native command from BASEDIR/smarts/bin to start the MPS Monitoring Server: On a Windows system: start sm_server --name=incharge-mps-monitoring --config=mpls-m --norestore --output On a UNIX system: sm_server --name=incharge-mps-monitoring --config=mpls-m --norestore --output --daemon 8. Enter the following native command from BASEDIR/smarts/bin to start the MPS Analysis Server: On a Windows system: start sm_server --name=incharge-mps-anaysis --config=mpls-a --norestore --output On a UNIX system: sm_server --name=incharge-mps-anaysis --config=mpls-a --norestore --output --daemon At startup, the MPS Topology Server reads the mpls.conf file, loads the configuration information to its repository, and imports router and switch topology and CI device-access objects from the IP Availability Manager sources that are specified in the mpls.conf file. In this example, the MPS Topology Server will import new topology from the IP Availability Manager named INCHARGE-AM3. Specifying a different IP Availability Manager source 143

144 Preparing and Initiating Discovery 144 EMC Ionix MPS Manager Version 9.0 Discovery Guide

145 CHAPTER 9 Understanding Discovery Results This chapter describes MPS Manager discovery results, discovery error resolutions, and the Pending Elements list. It consists of the following sections: Discovery results Discovery error resolutions Error message formatting Examples of error messages in CI log files Pending Elements list Understanding Discovery Results 145

146 Understanding Discovery Results Discovery results When the MPS Topology Server component of MPS Manager attempts to discover MPS, VPN, and (optional) BGP topology by probing a router or switch device, one of the following results occurs: Discovery successfully completes, and the MPS, VPN, and BGP topology objects that are discovered by probing the device are added to the managed topology. Discovery starts but communication is lost between the MPS Topology Server and the device. Discovery starts but the device does not respond to SNMP polls and/or CI commands. Discovery starts but one or more of the MPS Topology Server probes encounters an error during the discovery process. Discovery is unable to start or successfully complete. Successful discovery Unsuccessful discovery When the probing of a device for topology information is successful, an object is created in the MPS Topology Server repository for each discovered MPS, VPN, or BGP topology element. If the probing of a device for topology information does not complete successfully, an entry for that device is placed on the MPS Topology Server s Pending Elements list. Pending Elements list on page 154 provides information about the Pending Elements list and the Discovery Progress window in which it appears. 146 EMC Ionix MPS Manager Version 9.0 Discovery Guide

147 Understanding Discovery Results Discovery error resolutions You use a number of means to resolve errors that might occur during MPS Manager discovery, including the checking of the following sources: Discovery Progress window og files You open the Domain Manager Administration Console view of the Global Console to check the Discovery Progress window and the Pending Elements list. Note: The MPS Topology Server does not notify discovery errors, which means that discovery errors do not appear in the Notification og Console view of a Global Console that is attached to the Global Manager. Open the Domain Manager Administration Console User accounts and passwords The Global Console is a collection of many consoles, or console views, two of which are the Domain Manager Administration Console and the Global Manager Administration Console. The consoles enable administrators to manage EMC Ionix Domain Managers and Global Managers. Attaching the Global Console to a Domain Manager (such as MPS Manager) or to a Global Manager requires an EMC Ionix user account. The default user accounts are as follows: Administration account: username: admin password: changeme Operator account: username: oper password: oper For users who are logged in with an administration account, the Global Console includes a Configure menu. This menu enables administrators to open the Domain Manager Administration Console and the Global Manager Administration Console. The EMC Ionix ITOps System Administration Guide provides information about changing the password for the default administration account (recommended) and configuring access privileges. The EMC Ionix Service Assurance Manager Configuration Guide provides information about configuring permissions to perform specific console operations. Discovery error resolutions 147

148 Understanding Discovery Results Procedure for opening the Domain Manager Administration Console To open the Domain Manager Administration Console: 1. Start the Global Console. On a Windows system, select Start > Programs > InCharge > EMC Ionix Global Console. On a UNIX system, go to the BASEDIR/smarts/bin directory in the Service Assurance Manager (Global Manager) installation area and type: sm_gui Press Enter. The Attach Manager dialog box opens as shown in Figure 61 on page 148. Figure 61 Attach Manager dialog box 2. In the dialog box: a. Ensure that the EMC Ionix Broker for your deployment appears in the Broker text box. b. Click the Manager list box or the Browse button to display a list of active (running) Managers, and from that list select the MPS Topology Server (for example, INCHARGE-MPS-TOPOOGY) in your deployment as the Manager to which you want to connect. In the split-server architecture available with MPS Manager, you attach the Global Console to the MPS Topology Server. Attaching the Global Console to the MPS Monitoring Server or the MPS Analysis Server is not permitted. c. Type your login username and password. d. Click OK. The Topology Browser Console opens. 148 EMC Ionix MPS Manager Version 9.0 Discovery Guide

149 Understanding Discovery Results 3. On the Console, select Configure > Domain Manager Administration Console. The Domain Manager Administration Console opens, an example of which is shown in Figure 62 on page 149. In the example display, the Domain Manager Administration Console is attached to an MPS Topology Server named INCHARGE-MPS-TOPOOGY. Figure 62 Domain Manager Administration Console The Domain Manager Administration Console is the primary tool for configuring discovery, initiating discovery, and managing topology for a Domain Manager or a Domain Manager topology server such as the MPS Topology Server. The EMC Ionix Service Assurance Manager Operator Guide provides detailed descriptions of the administration capabilities that are available through the Domain Manager Administration Console. Discovery error resolutions 149

150 Understanding Discovery Results Check the Discovery Progress window Check the server log files Check the CI log files In the Domain Manager Administration Console, click Topology > Show Discovery Progress to launch the Discovery Progress window. The Discovery Progress window is shown in Figure 64 on page 154. Check the messages on the Pending Elements list and in the Discovery Status section of the window. Each entry on the Pending Elements list has an accompanying comment that describes the discovery error. And in some cases, just below the Discovery Status section in the Discovery Progress window, a message will appear that explains the discovery error. Check the log file named <MPS Topology Server name>_en_us_utf-8.log (for example, INCHARGE-MPS-TOPOOGY_en_US_UTF-8.log) in the BASEDIR/smarts/local/logs directory in the MPS Management Suite installation area. The discovery process writes an error message to this log file when it encounters a discovery error. Error message formatting on page 151 explains how to read error messages. Checking the individual log files of the MPS Monitoring Server and the MPS Analysis Server might also yield useful information when troubleshooting discovery errors. Check the CI log files in the BASEDIR/smarts/local/logs directory in the MPS Management Suite installation area. When probing a device, a CI probe writes a record of the Telnet, SSH1, or SSH2 session with the device to a CI log file. The CI log file includes the CI commands that are issued by the probe and the responses that are returned by the device. Examples of error messages in CI log files on page 153 presents examples of messages that are printed to CI log files for various CI discovery problems. 150 EMC Ionix MPS Manager Version 9.0 Discovery Guide

151 Understanding Discovery Results Error message formatting A log file is created in the BASEDIR/smarts/local/logs directory for each EMC Ionix application that is started with the --output option. (Any EMC Ionix application that is installed as a service automatically has --output in its invocation.) The log file is the primary tool for tracking the startup and progression of an EMC Ionix application, and for resolving application and discovery errors. Figure 63 on page 151 shows through example the formatting structure of error (exception) messages that are written to an EMC Ionix log file. EMC Ionix Subsystem Severity level Error table name then a hyphen (-), followed by Error name Reporting Subsystem Chained exceptions (indented) AS-W-ERROR_RUE_SOURCE-While executing rule set 'C:\Raji\mpls-b97-5\MPS\smarts\rules\mpls-tma\ic-mpls-lsp-iox35.asl' AS-ERROR_ACTION-While executing action at: AS-CA_STACK_RUE- RuleName: CRETE_TE_TUNNE, ine: 636 AS-CA_STACK_RUE- RuleName: POST_PROCESS, ine: 548 AS-CA_STACK_RUE- RuleName: EOF, ine: 738 AS-ERROR_UNDEFINED_TABE_KEY_ACCESS-Attempted to access undefined key ' ' in table 'tepriminstabel' AS-BAD_HASH_TABE_KEY-The hash table key ' ' was not found Root cause Figure 63 EMC Ionix exception message formatting The first line of an error message identifies the following information: EMC Ionix software subsystem that reported the error Severity level of the error: F for Fatal E for Error W for Warning N for Notice I for Informational D for Debug Name of the error table from which the EMC Ionix subsystem took the error Name of the error In the example error message, the reporting subsystem is AS, for Adapter Scripting anguage, the message severity level is Warning, the error table name is ERROR_RUE_SOURCE, and the error name is While executing rule set. The combination of an error table name and an error name uniquely identifies a particular error. Error message formatting 151

152 Understanding Discovery Results The remaining lines in a message, referred to as chained exceptions, provide more detail about the exception appearing in the top line. The last chained exception identifies the root cause of the error. In the example message, the root cause of the error is that the code was instructed to open a file that it could not find. Table 10 on page 152 identifies and briefly defines some of the EMC Ionix subsystems. Table 10 Some EMC Ionix subsystems and their descriptions EMC Ionix subsystem AS DNS DVST DX ICF ICS MR OSA RTD TOPO <SYS> Description Adapter scripting language subsystem. (Most EMC Ionix Adapters are implemented in AS code.) Throws errors that are detected by AS code. Network name translation subsystem Device status polling subsystem Correlator subsystem EMC Ionix framework subsystem EMC Ionix service assurance subsystem Repository manager. Throws generic Repository errors; the Repository is the database that stores the discovered topology (inventory). Operating system accessor Module loading. Throws errors due to configuration problems that cause the code to be unable to locate parts of itself. Topology Not an EMC Ionix subsystem; represents an operating system component that threw an error. 152 EMC Ionix MPS Manager Version 9.0 Discovery Guide

153 Understanding Discovery Results Examples of error messages in CI log files The format for naming a CI log file is: CI-<device vendor>-<device name>.txt where <device vendor> is CISCO, HUAWEI, JUNIPER6, or ERX. Two example CI log file names are: CI-CISCO-qa-gw15.txt CI-JUNIPER txt Typically, one of four outcomes is recorded in a CI log file: Outcome 1: Target device does not support Telnet, SSH1, or SSH2; for a target device named qa-gw15, an example of this error is: Starting to telnet qa-gw15. Error: Unable to connect to remote host qa-gw15 : Connection refused Outcome 2: Target device supports Telnet, SSH1, or SSH2, but the login credentials (username, user password, enable password) are incorrect for the device; for a target device named , an example of this error is: Starting to telnet Error: Unable to login to Outcome 3: Target device does not match any CI device-access group: ***Warning: Missing CI_AccessSetting for <device name>. Outcome 4: Discovery successfully completes, and the MPS, VPN, and BGP topology objects that are discovered by probing the device are added to the managed topology; for example: Starting to telnet qa-vplsce1.... (What CI commands are invoked depends on the vendor and the configuration of the target device. The CI command set for each supported vendor are identified in Appendix B, CI Commands Invoked for Discovery and SP Ping. ) If debug tracing is enabled, the following new line of information appears as the first line in the CI log file: Information: running the perl_commands.pl at <device vendor> (for example, CISCO) : <device name> (for example, qa-gw8). To enable debug tracing, set the debug flag in the BASEDIR/smarts/conf/mpls-t/perl-cli.conf file to a nonzero value. For example: $vars{"debug"} = 1; The EMC Ionix MPS Manager Configuration Guide describes the parameters in the perl-cli.conf file and provides instructions for modifying the parameters. Examples of error messages in CI log files 153

154 Understanding Discovery Results Pending Elements list The Pending Elements list, which appears in the Discovery Progress window, shows devices for which the MPS Topology Server could not successfully complete the discovery of MPS, VPN, and BGP topology. The MPS Topology Server attempts to discover the MPS, VPN, and BGP topology that is associated with the devices on the Pending Elements list during the next scheduled pending discovery interval, or when a pending discovery is manually invoked. Pending discovery on page 160 provides details about scheduled pending discovery, pending discovery interval, and pending discovery. To view the Pending Elements list: 1. Attach the Domain Manager Administration Console to the MPS Topology Server. 2. Select Topology > Show Discovery Progress. Figure 64 on page 154 is an example of a Pending Elements list. Pending Elements list qa-gw27 Router Cannot resolve to valid IP address Discovery status messages ast discovery completed at 21-Nov :10:20 EST 241 Figure 64 Pending Elements list containing one pending element 154 EMC Ionix MPS Manager Version 9.0 Discovery Guide

155 Understanding Discovery Results Information provided by the Pending Elements list The Pending Elements list contains three columns that provide the following information for a pending element: Element Name: Name of the device (probe instance) for which the probing of MPS, VPN, or BGP topology information did not complete successfully. The name contains the assigned display name of the device. Element Type: Name of the probe (device type) that probes the device that is identified in the Element Name field. Discovery Error: Comment describing why the device that is identified in the Element Name field is on the Pending Elements list. To see all of the text that is associated with a particular element name, element type, or discovery error, position the mouse pointer over the element name, element type, or discovery error. Management of individual pending element entries If you right-click an element on the Pending Elements list, a pop-up menu appears that lists the following three selections: Remove, Rediscovery, and Show Discovery Time. Select Remove to remove the selected element from the Pending Elements list. Select Rediscovery to initiate an immediate discovery of the selected element. Select Show Discovery Time to view the last time that the selected element was discovered. If Show Discovery Time is unavailable (dimmed), the element has yet to be discovered. Pending Elements list 155

156 Understanding Discovery Results 156 EMC Ionix MPS Manager Version 9.0 Discovery Guide

157 CHAPTER 10 Using Full or Pending Discovery This chapter explains how to invoke full or pending discovery for MPS Manager. It consists of the following sections. Discovery methods Full discovery Pending discovery Using Full or Pending Discovery 157

158 Using Full or Pending Discovery Discovery methods MPS Manager supports two methods of discovery: Full discovery Pending discovery Full and pending discoveries may be invoked automatically or manually. Full discovery Automatic full discovery During the initial full discovery, the MPS Topology Server component of MPS Manager populates its repository with router and switch topology from IP Availability Manager, and then probes the devices to discover MPS, VPN, and (optional) BGP topology. The initial full discovery occurs when an IP Availability Manager is added as a source to the MPS Topology Server, as explained in Initiating discovery on page 135. Thereafter, whenever an IP Availability Manager source completes a discovery (an initial discovery, a full discovery, a pending discovery, or a single-device discovery), the MPS Topology Server performs a discovery as described in Topology synchronization on page 136. Automatic full discovery reveals any changes in the configuration or connectivity of a device and keeps the topology current. The parameters that control automatic full discovery are located on the Topology tab of the Domain Manager Administration Console. By default, automatic full discovery is disabled for the MPS Topology Server. Automatic full discovery should be enabled and scheduled for the one or more IP Availability Manager sources, not for the MPS Topology Server. That way, whenever an IP Availability Manager source performs an automatic full discovery, the MPS Topology Server performs an automatic full discovery. Also, when you configure automatic full discovery, say weekly or daily, you should schedule the full discovery during off hours (5 A.M., for example). Running the discovery more often will provide a more accurate MPS, VPN, and BGP topology, but will also cost more in terms of network and system resources. The EMC Ionix IP Management Suite User Guide provides instructions for enabling and scheduling automatic full discovery for IP Availability Manager. 158 EMC Ionix MPS Manager Version 9.0 Discovery Guide

159 Using Full or Pending Discovery Manual full discovery In general, as with automatic full discovery, manual full discovery should be performed at the IP Availability Manager sources, not at the MPS Topology Server. Performing a manual full discovery at IP Availability Manager will trigger a full discovery at the MPS Topology Server. The EMC Ionix IP Management Suite User Guide provides instructions for performing manual full discovery at IP Availability Manager. If you want to perform a manual full discovery at the MPS Topology Server, you do so by invoking Discover All through the Domain Manager Administration Console or the dmctl utility. Invoking Discover All results in the following discovery behavior: The MPS Topology Server performs a topology synchronization with IP Availability Manager and conducts a discovery on all PE, P, Multi-VRF CE, and CE devices in its topology, regardless of device discovery timestamps. For PE or P devices, the MPS Topology Server conducts a full-scope discovery. Full-scope discovery is defined in How discovery is conducted on page 40. For Multi-VRF CE or CE devices, the MPS Topology Server conducts an SNMP discovery of just VRFs. If the MPS-BGP cross-domain correlation feature is enabled, the MPS Topology Server also conducts an SNMP discovery of exterior BGP (ebgp) sessions. For any new device, that is, a device that was not present in the MPS-System topology collection set during the previous synchronization with IP Availability Manager, the MPS Topology Server conducts a full-scope discovery. Invoking full discovery manually from the console Invoking full discovery from the command line From the Domain Manager Administration Console, you manually invoke a full discovery by selecting Topology > Discover All. From the command line, you can invoke a full discovery by using the dmctl utility. To do so, go to the BASEDIR/smarts/bin directory in the MPS Management Suite installation area and invoke the following command on one line: dmctl -s <MPS Topology Server instance name> invoke ICF_TopologyManager::ICF-TopologyManager discoverall For example dmctl -s INCHARGE-MPS-TOPOOGY invoke ICF_TopologyManager::ICF-TopologyManager discoverall When prompted for a username and password, specify an administration account; for example, admin and changeme. The dmctl utility is described in the HTM pages that are located in the BASEDIR/smarts/doc/html/usage directory of the MPS Management Suite installation area. Full discovery 159

160 Using Full or Pending Discovery Pending discovery Automatic pending discovery During a pending discovery, the MPS Topology Server attempts to discover MPS, VPN, and BGP topology by probing the devices on the Pending Elements list. The Pending Elements list contains the names of the devices that initially could not be discovered by the MPS Topology Server. You can view the Pending Elements list at any time by selecting Topology > Show Discovery Progress from the Domain Manager Administration Console. Pending Elements list on page 154 describes the various aspects of the Pending Elements list. Scheduling an automatic pending discovery determines how often the MPS Topology Server attempts to discover MPS topology by probing the devices on the Pending Elements list. The parameters that control automatic pending discovery are located on the Topology tab of the Domain Manager Administration Console. By default, automatic pending discovery is disabled. The pending discovery interval is counted from the time when the MPS Topology Server is started. So, if the pending discovery interval is set to six hours and the MPS Topology Server is started at 5 A.M., the pending discovery will occur every six hours thereafter, that is, at 11 A.M., at 5 P.M., at 11 P.M., and so on. To enable automatic pending discovery and to specify a pending discovery interval: 1. Attach the Domain Manager Administration Console to the MPS Topology Server. Instructions for opening the Domain Manager Administration Console are presented in Open the Domain Manager Administration Console on page In the left panel of the Domain Manager Administration Console, click the MPS Topology Server name to display a multiple-tab window in the right panel of the console. 3. Select the Topology tab. 4. Click the Enable Discovery Pending checkbox. 5. Type a value in the Interval field for pending discovery and select a time interval (Seconds, Minutes, Hours, or Days) from the list. Ensure that the interval is equal to or greater than five minutes. 6. Click Apply. 160 EMC Ionix MPS Manager Version 9.0 Discovery Guide

161 Using Full or Pending Discovery Manual pending discovery Manually initiating a pending discovery for the MPS Topology Server can be done from the Domain Manager Administration Console or from the command line. Invoking pending discovery manually from the console From the Domain Manager Administration Console, you can use any of the following methods to manually invoke a pending discovery: To discover MPS, VPN, and BGP topology by probing all devices on the Pending Elements list, select Topology > Discover Pending. To discover MPS, VPN, and BGP topology by probing a single device on the Pending Elements list, right-click the device on the Pending Elements list and then select Rediscover from the pop-up menu. Invoking pending discovery from the command line From the command line, you can invoke a pending discovery by using the dmctl utility. To do so, go to the BASEDIR/smarts/bin directory in the MPS Management Suite installation area and invoke the following command on one line: dmctl -s <MPS Topology Server instance name> invoke ICF_TopologyManager::ICF-TopologyManager discoverpending For example dmctl -s INCHARGE-MPS-TOPOOGY invoke ICF_TopologyManager::ICF-TopologyManager discoverpending When prompted for a username and password, specify an administration account; for example, admin and changeme. The dmctl utility is described in the HTM pages that are located in the BASEDIR/smarts/doc/html/usage directory of the MPS Management Suite installation area. Pending discovery 161

162 Using Full or Pending Discovery 162 EMC Ionix MPS Manager Version 9.0 Discovery Guide

163 APPENDIX A MIBs Accessed for Discovery and Remote Ping This appendix identifies the SNMP MIBs that are accessed by MPS Manager to discover MPS, VPN, and BGP topology and to perform remote pings. It consists of the following sections: SNMP versions supported MIBs accessed for MPS discovery MIBs accessed for 2VPN discovery MIBs accessed for 3VPN discovery MIBs accessed for BGP discovery MIBs accessed for remote ping MIBs Accessed for Discovery and Remote Ping 163

164 MIBs Accessed for Discovery and Remote Ping SNMP versions supported The MPS Topology Server component of MPS Manager sends SNMP Get requests to supported devices to discover MPS, VPN, and (optional) BGP topology objects and their relationships. The MPS Topology Server also sends SNMP Set and Get requests to supported devices to execute periodic or on-demand remote pings. The MPS Topology Server supports SNMPv1, v2c, and v3 access to the MIB objects on supported devices. MIBs accessed for MPS discovery The MPS Topology Server reads the standard and enterprise MIB objects that are identified in this section to discover the following MPS topology objects and their relationships: MPSService SP SPHop dpprotocolendpoint (non-targeted) dpadjacency (non-targeted) RsvpProtocolEndpoint RsvpSession An SP object may be a TE tunnel, TE SP, P2MP SP, subsp, or DP SP instance. After discovering and creating the MPS topology objects in its repository, the MPS Topology Server monitors the status of the MPS objects by periodically establishing SNMP sessions to the managed devices and polling the MIB objects. Table 11 on page 164 lists the MIB objects that are accessed by the MPS Topology Server for MPS discovery. Table 11 MIB objects accessed for MPS discovery (page 1 of 3) MIB object OID MPS-TE-MIB mplstunnelrole mplstunnelhoptableindex mplstunnelname mplstunnelhopipaddr mplstunnelarhoptableindex mplstunnelarhopipaddr mplstunnelchoptableindex EMC Ionix MPS Manager Version 9.0 Discovery Guide

165 MIBs Accessed for Discovery and Remote Ping Table 11 MIB objects accessed for MPS discovery (page 2 of 3) MIB object OID mplstunnelchopipaddr mplstunnelprimaryinstance mplstunnelpathchanges MPS-TE-STD-MIB mplstunnelrole mplstunnelhoptableindex mplstunnelname mplstunnelhopipaddr mplstunnelarhoptableindex mplstunnelarhopipaddr mplstunnelchoptableindex mplstunnelchopipaddr MPS-SR-MIB mplsinterfaceabelparticipationtype mplsinsegmentxcindex mplsoutsegmentindexnext mplsoutsegmentifindex mplsoutsegmenttopabel mplsoutsegmentnexthopipv4addr mplsoutsegmentxcindex mplsxcspid MPS-SR-STD-MIB mplsinterfaceabelparticipationtype mplsinsegmentabel mplsinsegmentxcindex mplsoutsegmentifindex mplsoutsegmenttopabel mplsoutsegmentnexthopaddrtype mplsoutsegmentnexthopaddr mplsoutsegmentxcindex mplsxcspid

166 MIBs Accessed for Discovery and Remote Ping Table 11 MIB objects accessed for MPS discovery (page 3 of 3) MIB object OID MPS-DP-MIB mplsdpentityadminstatus mplsdpentityoperstatus mplsdpentitykeepaliveholdtimer mplsdpentitytargetedpeer mplsdpentitytargetedpeeraddr mplsdphelloadjacencytype JUNIPER-MPS-MIB mplsspname mplspathexplicitroute mplsspstate mplspathrecordroute mplsspinfoto JUNOS 9.0 or later. Destination IP address of this SP. mplspathinfoname JUNOS 9.0 or later. SP name when parent tunnel is P2P SP. No value when tunnel is P2MP SP for multicast. mplspathinforecordroute JUNOS 9.0 or later. Hop IPs for this SP JUNIPER-MPS-DP-MIB jnxmplsdpsesstate JUNIPER-RSVP-MIB jnxrsvpsessionfrom jnxrsvpsessionto jnxrsvpsessionrole jnxrsvpsessiontunnelid jnxrsvpsessionspid If SNMP discovery is not successful or is not supported for a device, or if additional information is needed for a device, the MPS Topology Server performs CI discovery by invoking the commands that are identified in Appendix B, CI Commands Invoked for Discovery and SP Ping. 166 EMC Ionix MPS Manager Version 9.0 Discovery Guide

167 MIBs Accessed for Discovery and Remote Ping MIBs accessed for 2VPN discovery The MPS Topology Server reads the standard and enterprise MIB objects that are identified in this section to discover the following 2VPN topology objects and their relationships: VPN VRF RouteTarget Forwarder ForwarderEndpoint PseudoWire dpprotocolendpoint (targeted) dpadjacency (targeted) After discovering and creating the 2VPN topology objects in its repository, the MPS Topology Server monitors the status of the 2VPN objects by periodically establishing SNMP sessions to the managed devices and polling the MIB objects. Table 12 on page 167 lists the MIB objects that are accessed by the MPS Topology Server for 2VPN discovery. Table 12 MIB objects accessed for 2VPN discovery (page 1 of 2) MIB object OID CISCO-IETF-PW-MIB CpwVcType cpwvcpeeraddr cpwvcid cpwvcname CISCO-IETF-PW-MPS-MIB cpwvcmplsoutboundsrxcindex MPS-DP-MIB mplsdpentityadminstatus mplsdpentityoperstatus mplsdpentitywellknowndiscoveryport mplsdpentitykeepaliveholdtimer mplsdpentityhelloholdtimer mplsdpentityabeldistributionmethod mplsdpentitytargetedpeer mplsdpentitytargetedpeeraddrtype

168 MIBs Accessed for Discovery and Remote Ping Table 12 MIB objects accessed for 2VPN discovery (page 2 of 2) MIB object OID mplsdpentitytargetedpeeraddr mplsdphelloadjacencytype MPS-DP-STD-MIB mplsdpentityadminstatus mplsdpentityoperstatus mplsdpentitytcpport mplsdpentitykeepaliveholdtimer mplsdpentityhelloholdtimer mplsdpentityabeldistmethod mplsdpentitytargetpeer mplsdpentitytargetpeeraddrtype mplsdpentitytargetpeeraddr JUNIPER-VPN-MIB jnxvpndescriptionoid jnxvpnidentifiertypeoid jnxvpnidentifieroid jnxvpnifassociatedpw jnxvpnpwassociatedinterface jnxvpnpwocalsiteid jnxvpnpwremotesiteid jnxvpnremotepeidaddrtype jnxvpnremotepeidaddress jnxvpnpwtunneltype jnxvpnpwtunnelname jnxvpnpwreceivedemux jnxvpnpwtransmitdemux jnxvpnrttypeoid jnxvpnrtoid jnxvpnrtfunctionoid mplsvpnifconfrowstatusoid JUNIPER-MPS-DP-MIB jnxmplsdpsesstate jnxmplsdpentitykeepaliveholdtimer EMC Ionix MPS Manager Version 9.0 Discovery Guide

169 MIBs Accessed for Discovery and Remote Ping If SNMP discovery is not successful or is not supported for a device, or if additional information is needed for a device, the MPS Topology Server performs CI discovery by invoking the commands that are identified in Appendix B, CI Commands Invoked for Discovery and SP Ping. MIBs accessed for 3VPN discovery The MPS Topology Server reads the standard and enterprise MIB objects that are identified in this section to discover the following 3VPN topology objects and their relationships: VPN VRF RouteTarget After discovering and creating the 3VPN topology objects in its repository, the MPS Topology Server monitors the status of the 3VPN objects by periodically establishing SNMP sessions to the managed devices and polling the MIB objects. Table 13 on page 169 lists the MIB objects that are accessed by the MPS Topology Server for 3VPN discovery. Table 13 MIB objects accessed for 3VPN discovery (page 1 of 2) MIB object OID MPS-VPN-MIB mplsvpnconfiguredvrfs mplsvpnifconftable mplsvpnvrftable mplsvpnvrfroutetargettable MPS-3VPN-STD-MIB mplsvpnconfiguredvrfs mplsvpnifvpnclassification mplsvpnvrfroutedistinguisher mplsvpnvrfroutetarget JUNIPER-VPN-MIB jnxvpndescriptionoid jnxvpnidentifiertypeoid jnxvpnidentifieroid jnxvpnifassociatedpw jnxvpnpwassociatedinterface jnxvpnpwocalsiteid

170 MIBs Accessed for Discovery and Remote Ping Table 13 MIB objects accessed for 3VPN discovery (page 2 of 2) MIB object OID jnxvpnpwremotesiteid jnxvpnremotepeidaddrtype jnxvpnremotepeidaddress jnxvpnpwtunneltype jnxvpnpwtunnelname jnxvpnpwreceivedemux jnxvpnpwtransmitdemux jnxvpnrttypeoid jnxvpnrtoid jnxvpnrtfunctionoid mplsvpnifconfrowstatusoid If SNMP discovery is not successful or is not supported for a device, or if additional information is needed for a device, the MPS Topology Server performs CI discovery by invoking the commands that are identified in Appendix B, CI Commands Invoked for Discovery and SP Ping. MIBs accessed for BGP discovery The MPS Topology Server reads the standard and enterprise MIB objects that are identified in this section to discover the following BGP topology objects and their relationships: AutonomousSystem BGPService BGPProtocolEndpoint BGPSession After discovering and creating the BGP topology objects in its repository, the MPS Topology Server monitors the status of the BGP objects by subscribing to status updates in Network Protocol Manager for BGP. 170 EMC Ionix MPS Manager Version 9.0 Discovery Guide

171 MIBs Accessed for Discovery and Remote Ping Table 14 on page 171 lists the MIB objects that are accessed by the MPS Topology Server for BGP discovery. Table 14 MIB objects accessed for BGP discovery MIB object OID BGP4-MIB bgpversion bgpocalas bgpidentifier bgppeeridentifier bgppeerstate bgppeerocaladdr bgppeerremoteaddr bgppeerremoteas MIBs accessed for remote ping For on-demand remote pings, the MPS Topology Server sends remote ping requests to supported devices to write remote ping entries to their Ping MIBs, and to read remote ping test results from their Ping MIBs. For periodic remote pings, the MPS Monitoring Server sends remote ping requests to supported devices to write remote ping entries to their Ping MIBs, and to read remote ping test results from their Ping MIBs. Periodic remote pings (objects) are created on the MPS Topology Server, transferred to the MPS Monitoring Server, and started on the MPS Monitoring Server. Table 15 on page 171 identifies the device and MIB support for remote ping. Table 15 MIBs access for remote ping Device Cisco devices Huawei devices Juniper M/T, ERX, or ERX virtual routers MIB CISCO-PING-MIB NQA-MIB DISMAN-PING-MIB Procedures for enabling the remote ping server tool and creating periodic remote pings are given in the EMC Ionix MPS Manager Configuration Guide. Directions for invoking on-demand remote pings are given in the EMC Ionix MPS Manager User Guide. 171

172 MIBs Accessed for Discovery and Remote Ping 172 EMC Ionix MPS Manager Version 9.0 Discovery Guide

173 APPENDIX B CI Commands Invoked for Discovery and SP Ping This appendix identifies the CI commands that are invoked by MPS Manager to discover MPS, VPN, and BGP topology and to perform SP pings. It consists of the following sections: CI commands overview CI commands invoked on Cisco devices CI commands invoked on Huawei devices CI commands invoked on Juniper M/T devices CI commands invoked on Juniper ERX devices CI commands invoked for SP ping CI Commands Invoked for Discovery and SP Ping 173

174 CI Commands Invoked for Discovery and SP Ping CI commands overview The MPS Topology Server component of MPS Manager uses CI commands to perform CI discovery for any of the following conditions: SNMP discovery fails. MIB is not supported by the target device. MIB cannot provide the required information. For these conditions, the MPS Topology Server establishes a Telnet, SSH1, or SSH2 connection to the target device and issues specific CI show commands to discover MPS and VPN topology objects and their relationships. The MPS Topology Server also uses CI commands to execute on-demand SP ping requests. For SP ping execution, the MPS Topology Server establishes a Telnet, SSH1, or SSH2 connection to the target device and issues a specific CI ping command to start the SP ping, and parses the ping command output to obtain the SP ping test results. CI commands invoked on Cisco devices The CI show commands for Cisco devices are listed and described in Table 16 on page 174. Table 16 CI commands for discovery on Cisco devices (page 1 of 3) Command Description Comment CI commands for general session operation terminal length 0 CI commands for MPS discovery show ip rsvp fast-reroute detail show mpls traffic-eng fast-reroute database Prevents the device from pausing between screens of output. Identifies link/node protected tunnels that are protected by the SNMP-discovered link/node protected tunnels. Identifies which of the backup TE SPs is active after a fast-reroute (FRR) occurs. During the session, the Cisco device uses the terminal length value to determine when to pause during multiple-screen output. A value of 0 prevents the device from pausing between screens of output. Cisco IOS command: Invoked during TE tunnel discovery to discover nested link/protected TE tunnels. SNMP discovery cannot be used to obtain this information. Cisco IOX (3.5) command: Invoked during TE tunnel discovery to identify which TE SP is active after an FRR. SNMP discovery cannot be used to obtain this information 174 EMC Ionix MPS Manager Version 9.0 Discovery Guide

175 CI Commands Invoked for Discovery and SP Ping Table 16 CI commands for discovery on Cisco devices (page 2 of 3) Command Description Comment show tag-switching interfaces show tag-switching forwarding-table show mpls traffic-eng tunnels role head show explicit-paths show mpls forwarding brief Shows information about the interfaces that have been configured for label switching. Shows the tag-switching forwarding table, which is the label switching equivalent of the IP routing table for standard IP routing. It contains incoming and outgoing labels and descriptions of the packets. Shows information about the traffic engineering (TE) tunnels that originate at the device where this command is executed. Shows configured IP explicit paths. Shows configuration and statistics for SPs. Entries may have only an In line, only an Out line, or both In and Out lines. Entries with only an "In" line refer to egress SPs; entries with only an "Out" line refer to ingress SPs; and entries with both In and Out lines refer to transit SPs. Cisco IOS command. Cisco IOS command. Used to discover and associate backup/secondary TE SPs with primary SPs. show ip rsvp host senders Shows RSVP session information. Cisco IOS command. CI commands for 2VPN discovery show mpls l2transport vc show l2vpn xconnect Shows information about Any Transport over MPS (AToM) virtual circuits (VCs) that have been enabled to route ayer 2 packets on a device. Shows ForwarderEndpoints for point-to-point topology. Cisco IOS command. Cisco IOX command: Used to discovery VPWS instances. Note: A VPWS is also SNMP-discovered; CI-discovered values do not overwrite SNMP-discovered values. show l2vpn bridge-domain Shows ForwarderEndpoints for VPS topology. Cisco IOX command: Used to discover VPS instances. Note: A VPS is also SNMP-discovered; CI-discovered values do not overwrite SNMP-discovered values. 175

176 CI Commands Invoked for Discovery and SP Ping Table 16 CI commands for discovery on Cisco devices (page 3 of 3) Command Description Comment show vlan interface Shows VAN information. Cisco IOX command: Used to discover and map VANs to discovered VPWS and VPS instances. CI commands for 3VPN discovery show ip vrf detail show route-map show ip bgp vpnv4 all tags Shows the VRF tables and their associated route distinguishers (RDs) and interfaces. Shows the contents of the configured route maps. Shows VPN address information in the BGP table. Each output block starts with Route Distinguisher and is associated with a VRF; the name of the VRF appears in parenthesis at the beginning of the block. Cisco IOS command. Cisco IOS command. Cisco IOS command. CI commands for BGP route reflector discovery (IOS) show ip bgp update-group Cisco IOS command CI commands for BGP route reflector discovery (IOX) show bgp neighbors include BGP neighbor is Route-Reflector Client Cisco IOX command 176 EMC Ionix MPS Manager Version 9.0 Discovery Guide

177 CI Commands Invoked for Discovery and SP Ping CI commands invoked on Huawei devices The CI show commands for Huawei devices are listed and described in Table 17 on page 177. Table 17 CI commands for discovery on Huawei devices Command Description Comment CI commands for general session operation system-view display users user-interface vty <number> screen-length 0 Change to system view from current user view. View the login information of the users on each user interface. Enter single-user interface view or multi-user interface view. Enter the view of the VTY user interface by entering the view of the user interfaces VTY 0 through VTY 3. Set the number of displayed lines. Setting the screen length to zero disables multiple-screen output. CI commands for MPS discovery display mpls interface display mpls lsp verbose View all MPS-enabled interfaces. View SP information. By default, the display mpls lsp command displays all SP information. By adding verbose, you display detailed information. CI commands for 2VPN discovery display mpls l2vc Display information about Martini VCs configured on the device. If you specify an interface, the command displays information about Martini VCs configured on the CE interface. CI commands for 3VPN discovery display ip vpn-instance verbose display bgp vpnv4 all routing-table label View the VPN instance configuration on PEs. Display information about labeled routes in the BGP routing table. 177

178 CI Commands Invoked for Discovery and SP Ping CI commands invoked on Juniper M/T devices The CI show commands for Juniper M/T devices are listed and described in Table 18 on page 178. Table 18 CI commands for discovery on Juniper M/T devices (page 1 of 2) Command Description Comment CI commands for MPS discovery show mpls lsp detail ingress show mpls interfaces show mpls lsp transit up match Up show mpls lsp ingress detail up match. show rsvp session ingress show rsvp neighbor detail match via show route forwarding-table family mpls show ldp neighbor Shows the configured and active dynamic SPs that originate from the device. Shows the MPS interfaces, their state, and administrative groups. For transit SPs, shows the incoming and outgoing labels and SPID. For ingress SPs, shows the SPID, the SP name, and the full SP path. For RSVP-based ingress SPs, shows the outgoing label, the SPID, and the SP name. For each RSVP neighbor, shows the interface that talks to that neighbor and the IP of the facing interface on that neighbor. Shows the MPS forwarding table, including the incoming and outgoing labels and the outgoing interface. Also identifies load balancing SPs. Shows peer DP speakers, their IP address, and the interface used to exchange labels with them. show ldp database match "-- /32" Shows the DP database only /32 routes (and headers). show ldp route match /32 Shows the DP routes only /32 routes (and headers). show ldp session detail Shows DP session information. Used to discover non-targeted DP adjacencies. CI commands for 2VPN discovery show ldp session detail Shows DP session information. Used to discover targeted DP adjacencies. 178 EMC Ionix MPS Manager Version 9.0 Discovery Guide

179 CI Commands Invoked for Discovery and SP Ping show vpls connections extensive Shows VPS connection information. Used to discover VPS show interfaces Table 18 CI commands for discovery on Juniper M/T devices (page 2 of 2) Command Description Comment Shows status information about the management Ethernet and internal Ethernet interfaces. instances, and to discover and map VANs to discovered VPS instances. Note: A BGP-signaled VPS is also SNMP-discovered; CI-discovered values do not overwrite SNMP-discovered values. CI commands for 3VPN discovery show route table <vrf name>.inet.0 match bgp Shows the BGP entries in the routing table of each VRF. show routeinstance detail match ^[^ _]*:$ Router Type: target Interfaces:.*/.*/ show mvpn instance Used to identify both the multicast group and its relation with the P-tunnel (P2MP SP). CI commands for BGP route reflector discovery (JunOS) show bgp neighbors match ^Peer: Type: 179

180 CI Commands Invoked for Discovery and SP Ping CI commands invoked on Juniper ERX devices Because the MPS and VPN MIBs are not supported by Juniper ERX devices and virtual routers, the MPS Topology Server uses CI discovery exclusively to discover MPS topology objects and their relationships for these devices. The CI show commands that are invoked for MPS discovery on Juniper ERX devices and virtual routers are listed in Table 19 on page 180. Table 19 CI commands for discovery on Juniper ERX devices (page 1 of 2) Command Description Comment CI commands for MPS discovery show mpls l2transport interface brief show vlan subinterface show mpls for brief show mpls forwarding brief show mpls interfaces brief show route table inet.3 show route table mpls.0 show rsvp session detail show mpls lsp detail show mpls lsp detail ingress Shows status and configuration for ayer 2 services over MPS, also known as Martini or ayer 2 transport, on the device or on specific interfaces. Shows status and configuration for a specified VAN subinterface, or for all VAN subinterfaces that are configured on the device. Shows summary information for MPS labels that are being used for forwarding. Shows configuration and statistics for SPs. Entries may have only an "In" line, only an "Out" line, or both "In" and "Out" lines. Entries with only an "In" line refer to egress SPs; entries with only an "Out" line refer to ingress SPs; and entries with both "In" and "Out" lines refer to transit SPs. Shows the MPS interfaces, their IP addresses, protocol, and status. Shows the route entries in the inet.3 table. Shows the route entries in the mpls.0 routing table. Shows detailed RSVP session information. Shows information about configured and active dynamic SPs in which the device participates. Using the detail keyword displays detailed SP information, including all current state information and all parameters and counters that are part of the SP. Same as show mpls lsp detail command above. Using the ingress keyword displays sessions that originate from the device. Used in conjunction with the show mpls forwarding brief command to discover DP SPs and TE SPs, and to discover the stacking of DP SPs on TE SPs. 180 EMC Ionix MPS Manager Version 9.0 Discovery Guide

181 CI Commands Invoked for Discovery and SP Ping Table 19 CI commands for discovery on Juniper ERX devices (page 2 of 2) Command Description Comment show ldp neighbor CI commands for 2VPN discovery show ip bgp vpnv4 all fields best out-label peer next-hop extended-communities show ldp neighbor show mpls l2transport interface brief show vlan subinterface show mpls ldp vpls show vpls connections details CI commands for 3VPN discovery show ip vrf detail Shows peer DP speakers, their IP address, and the interface used to exchange labels with them. Shows IP BGP prefixes, outgoing labels, peer IP addresses, next hop addresses, and extended communities. Entries with Next-hop are ignored. Shows peer DP speakers, their IP address, and the interface used to exchange labels with them. Shows status and configuration information about ayer 2 services over MPS. Using the brief keyword displays limited interface information. Shows configuration and status information for all VAN subinterfaces that are configured on the device. Shows VPS instance name, VPS Id, remote PE, in-label, and out-label information Shows connection information for all VPS instances that are configured on the device. Using the details keyword displays detailed configuration and status information for VPS connections. Shows the VRF tables and their associated route distinguishers (RDs) and interfaces. Each block in the output of this command starts with the keyword "VRF" followed by the VRF name and the route distinguisher. In some cases a VRF description will also appear. Used to discover non-targeted DP adjacencies. Used to discover Targeted DP adjacencies. Used to discover VPWS and VPS instances, and to discover and map VANs to discovered VPS instances. CI commands for BGP route reflector discovery (ERX) ip bgp neig include REmote IP Neighbor is a route reflect 181

182 CI Commands Invoked for Discovery and SP Ping CI commands invoked for SP ping SP Ping is an on-demand user tool that verifies that a source device in the managed MPS network is able to reach a target device through a specified SP. The SP ping functionality is built on the CI tool framework that is described in the EMC Ionix MPS Manager Configuration Guide. The configuration guide also provides a procedure for enabling the SP ping server tool. The EMC Ionix MPS Manager User Guide describes how to use the SP ping. SP Ping is supported on Cisco and Juniper M/T devices. Default SP ping command line for Cisco devices By default, for Cisco devices, the MPS Topology Server includes the following command options in the SP ping command lines that it constructs and invokes for SP ping server tool invocations: ping mpls ipv4 <destination-address destination-mask> [repeat 5] [timeout 2] [size 100] [interval 0] Here is an example of an SP ping command line and the ping test results. The remote computer shell prompt Router# indicates that the MPS Topology Server has established a Telnet, SSH1, or SSH2 session with the originating device. dev-vps5#ping mpls ipv repeat 5 timeout 2 size 100 interval 0 Sending 5, 100-byte MPS Echos to /32, timeout is 2 seconds, send interval is 0 msec: Codes: '!' - success, 'Q' - request not sent, '.' - timeout, '' - labeled output interface, 'B' - unlabeled output interface, 'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch, 'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry, 'P' - no rx intf label prot, 'p' - premature termination of SP, 'R' - transit router, 'I' - unknown upstream index, 'X' - unknown return code, 'x' - return code 0 Type escape sequence to abort. QQQQQ Success rate is 0 percent (0/5) 182 EMC Ionix MPS Manager Version 9.0 Discovery Guide

183 CI Commands Invoked for Discovery and SP Ping Default SP ping command line for Juniper M/T devices By default, for Juniper M/T devices, the MPS Topology Server includes the following command options in the SP ping command lines that it constructs and invokes for SP ping server tool invocations: ping mpls ldp <destination-address> [count 5] Here is an example of an SP ping command line and the ping test results. The remote computer shell prompt indicates that the MPS Topology Server has established a Telnet, SSH1, or SSH2 session with the originating device. juniper@dev-mpsp8> ping mpls ldp count 5!!!!! --- lsping statistics packets transmitted, 5 packets received, 0% packet loss SP ping customization In you so choose, you can change the global values that are specified for the options in the default SP ping command line. The procedure for doing so is given in the EMC Ionix MPS Manager Configuration Guide. 183

184 CI Commands Invoked for Discovery and SP Ping 184 EMC Ionix MPS Manager Version 9.0 Discovery Guide

185 APPENDIX C Manually Stitching EVCs to PseudoWires This chapter describes the pw-evc.conf file and presents the procedure for manually stitching EVC objects to PseudoWire objects. It consists of the following sections: Overview Syntax of entries in pw-evc.conf Creating entries for pw-evc.conf Adding entries to pw-evc.conf Manually Stitching EVCs to PseudoWires 185

186 Manually Stitching EVCs to PseudoWires Overview Currently, the MPS Topology Server component of MPS Manager discovers point-to-point Ethernet virtual connections (EVCs) in any of the following types of Metro Ethernet networks: Ethernet-MPS-Ethernet (E-M-E), MPS Only, and Ethernet Only. Figure 43 on page 100 and Figure 44 on page 100 show the key component of E-M-E and MPS Only networks. In an E-M-E network, a point-to-point EVC consists of a pseudowire and two service-provider VAN (S-VAN) traffic paths. In an MPS Only network, a point-to-point EVC consists of just a pseudowire; the EVC and pseudowire terminate on the same user network interfaces (UNIs). In an Ethernet Only network, because the network contains no MPS core, a point-to-point EVC contains no pseudowire. Through the pw-evc.conf file, which is located in the BASEDIR/smarts/conf/mpls-t directory, a user can specify an EVC-to-pseudowire ayeredover /Underlying relationship for EVCs that are discovered in E-M-E networks. The relationship enables the MPS Topology Server to pinpoint an impacted EVC due to an underlying MPS failure, even when the endpoints of the EVC do not have EVC status. In an MPS Only network, because an EVC and its pseudowire terminate on the same UNIs, the EVC-to-pseudowire ayeredover relationship is optional. 186 EMC Ionix MPS Manager Version 9.0 Discovery Guide

187 Manually Stitching EVCs to PseudoWires Syntax of entries in pw-evc.conf Here is the syntax of an entry in the pw-evc.conf file: <PW information> <EVC ID> where <PW information> identifies the pseudowire that underlies the EVC that has an EVC identifier of <EVC ID>. The <PW information> and <EVC ID> strings are separated by one or more spaces. The <PW information> string consists of three fields that are separated by a pipe ( ) delimiter: <pe_device_name> <pe_access_interface> <VAN/VC_ID> where: <pe_device_name> is the hostname or IP address of one of the two PE devices that terminate the pseudowire. <pe_access_interface> is the PE physical interface of the pseudowire s access link. Invoke the show interfaces CI command on the PE device and use the interface identifier that appears in the command output. If you have access to the MIB2 of the PE device, use either the ifdescr or ifindex value that is associated with the interface. <VAN/VC_ID> is the VAN/VC identifier of the PE physical interface of the pseudowire s access link. Each <PW information> <EVC ID> entry maps an EVC to a pseudowire. Here are two examples: dev-mpsp5 GigabitEthernet1/1/ FastEthernet0/1/1/2 155 EP_QnQ EVP_EVC_QnQ 187

188 Manually Stitching EVCs to PseudoWires Creating entries for pw-evc.conf Users learn an EVC endpoint interface to pseudowire interface mapping from their local provisioning system. The pseudowire interface, which is identified as a gray box in Figure 65 on page 188, is the PE physical interface of the pseudowire s access link; for example, GigabitEthernet1/1/1 on PE dev-mpsp5. U-PE (part of Ethernet network) PE (part of MPS core) EVCEndPoint EVC ayeredover S-VAN (VAN/VC ID) To/From CE... IF IF Access link IF IF PseudoWire SPs Figure 65 EVC-endpoint-to-pseudowire path in an E-M-E network To create a <PW information> <EVC ID> entry in the pw-evc.conf file: Replace <EVC ID> with the EVC identifier of the EVC endpoint. The EVC identifier is also the EVC identifier of the EVC endpoint s EVC. Replace <PW information> with the pseudowire information as specified in Syntax of entries in pw-evc.conf on page 187. The software module that reads the pw-evc.conf file will map the EVC to the corresponding PseudoWire object in the MPS modeled topology. The naming format for the PseudoWire object is described in the MPS Topology Naming Conventions appendix of the EMC Ionix MPS Manager User Guide. 188 EMC Ionix MPS Manager Version 9.0 Discovery Guide

189 Manually Stitching EVCs to PseudoWires Adding entries to pw-evc.conf To add entries to the pw-evc.conf file: 1. Go to the BASEDIR/smarts/bin directory in the MPS Management Suite installation area and type the following command to open the pw-evc.conf file: sm_edit conf/mpls-t/pw-evc.conf Press Enter. 2. Observe the syntax in Syntax of entries in pw-evc.conf on page 187 and add the pseudowire-to-evc entries that you want to stitch together. 3. Save and close the file. The modified version of the pw-evc.conf file is saved to the BASEDIR/smarts/local/conf/mpls-t directory. 4. Restart the MPS Topology Server to implement your changes. The ic-mpls-manual-stitch-pw-evc.asl in the BASEDIR/smarts/rules/mpls-tma directory responds by performing the following actions: Reads the pw-evc.conf file. Writes a Starting manual stitching... message to the MPS Topology Server log file. Creates a ayeredover relationship from the EVC object to its associated PseudoWire object for each entry in the pw-evc.conf file. Writes a Done manual stitching message to the MPS Topology Server log file when finished. 189

190 Manually Stitching EVCs to PseudoWires 190 EMC Ionix MPS Manager Version 9.0 Discovery Guide

191 INDEX Symbols.import files 62, 135 A Adapters EMC Ionix Adapter for Alcatel-ucent 5620 SAM EMS 49 AutonomousSystem 62 Availability Manager Topology export 33, 60 B BGP autonomous systems 27 BGP protocol endpoints 27 BGP services 27 BGP sessions 27 BGP support BGP autonomous systems 27 BGP protocol endpoints 27 BGP services 27 BGP sessions 27 MPS-BGP cross-domain correlation 27 BGPProtocolEndpoint 62 BGPService 62 BGP-signaled 2VPN 92, 107 BGP-signaled 2VPNs 109 C CE device 79 Class EVC 114 Forwarder 112 ForwarderEndpoint 109 dpadjacency 87, 113 dpprotocolendpoint 82, 109 SP 83 SPHop 87 MPSService 79 MulticastGroup 126 MulticastVPN 126 PseudoWire 110 RouteTarget 109, 125 RsvpProtocolEndpoint 82 RsvpSession 88 VAN 114 VPN 113, 126 VRF 109, 125 CI og files 39 CI commands 173 CI support 21 D Device Definition of 16 Device support 21 Cisco 21 Huawei 21 Juniper 21 Devices CE 79 Multi-VRF CE 79 P 79 PE 79 Discovery.import files 62, 135 Definition of 16 Discover All command 159 Discover Pending command 161 Discovery errors 147 Initiating 133 Invoking 157 IP Availability Manager 31 Manual rediscovery 159 MPS objects 33 Multicast group 179 MulticastVPN objects 37 Overview 15, 30 Pending Devices list 160 Pending Elements list 63, 64, 154 Phases of 59 Phase 1 60 Phase 2 61 Phase 3 64 Preparing for 133 Process 55, 67, 91, 117 Progress window 147, 150 Route reflector 179 Scheduled discovery interval 160 Triggers 39 VPN objects 36, 37 Discovery errors 147 Discovery process 55, 67, 91, 117 Discovery Progress window 147, 150, 154 Discovery protocols SNMP 21 Telnet, SSH1, or SSH2 CI 21 dmctl 159, 161 Domain Manager Definition of 16 Domain Manager Administration Console 149 Discover All command 159 Discover Pending command 161 Discovery Progress window 147, 150 EMC Ionix MPS Manager Version 9.0 Discovery Guide 191

192 Index E EMC Ionix Adapter for Alcatel-ucent 5620 SAM EMS 49 EMC online support website 11 EVC 92 EVC class 114 F Forwarder 65 Forwarder class 112 ForwarderEndpoint 61 ForwarderEndpoint class 109 Full-mesh VPN 126 G Global Console Overview discussion 147 Type of Domain Manager Administration 147 Global Manager Administration 147 Global Manager 134 H Hub-and-spoke VPN 126 I IP address Special reserved block of 66 IPv4 support 21 2VPNs 18 BGP-signaled 92, 107, 109 EVC 92 EVC class 114 Forwarder class 112 ForwarderEndpoint class 109 dpadjacency class 113 dpprotocolendpoint class 109 DP-signaled 92, 107, 109 PseudoWire class 110 RouteTarget class 109 VAN class 114 VPN class 113 VRF class 109 3VPNs multicast 25 MulticastGroup class 126 MulticastVPN class 126 RouteTarget class 125 unicast 19 VPN class 126 VRF class 125 3VPNs, multicast 25 3VPNs, unicast 19 abel switched path (SP) 65 DP SPs 18, 20, 74, 82 dpadjacency 65, 66, 87, 113 dpadjacency class 87, 113 dpprotocolendpoint 61, 62, 82, 109 dpprotocolendpoint class 82, 109 DP-signaled 2VPNs 92, 107, 109 og files 38 CI 39 Probe 150 SP 65 SP class 83 SP support 17 DP SPs 18 P2MP SPs 17 subsps 17 TE SPs 17 TE tunnels 17 SPHop 65 SPHop class 87 SPs DP 20, 74, 82 subsps 20 TE 75, 82 TE SPs 20 M MIB support BGP4-MIB 170 CISCO-IETF-PW-MIB 21 CISCO-IETF-PW-MPS-MIB 21 JUNIPER-MPS-DP-MIB 23 JUNIPER-MPS-MIB 23 JUNIPER-RSVP-MIB 23 JUNIPER-VPN-MIB 23 MPS-3VPN-STD-MIB 22, 124 MPS-DP-MIB 21 MPS-DP-STD-MIB 22 MPS-SR-MIB 21 MPS-SR-STD-MIB 22 MPS-TE-MIB 21 MPS-TE-STD-MIB 22 MPS-VPN-MIB 21, 124 MPS domain 33 MPS Manager Topology import 33, 60 MPS-BGP cross-domain correlation 27 MPSService 61 MPSService class 79 Multicast group 179 multicast 3VPNs 25 MulticastGroup class 126 MulticastVPN class 126 Multi-VRF CE device 79 Multi-VRF CE support 24 O Object Definition of 16 Overlapping IP address support EMC Ionix MPS Manager Version 9.0 Discovery Guide

193 IndexIndex P P device 79 P2MP SPs 17 PE device 79 Pending Devices list 160 Pending Elements list 63, 64, 154, 155 Contents description 155 Rediscovery 155 Remove 155 Show Discovery Time 155 Probe og files 150 PseudoWire 65 PseudoWire class 110 pw-evc.conf file 186 R Rediscovery Starting manually 159 Route reflector 179 RouteTarget 62 RouteTarget class 109, 125 RsvpProtocolEndpoint 61, 82 RsvpProtocolEndpoint class 82 RsvpSession 65, 88 RsvpSession class 88 U unicast 3VPNs 19 V Virtual private network (VPN) 66 VAN 66 VAN class 114 VPN 66 VPN class 113, 126 VPN domain 36, 37 VPN Routing and Forwarding (VRF) 62 VPN support 18 2VPNs 18 multicast 3VPNs 25 unicast 3VPNs 19 VPN types Full-mesh 126 Hub-and-spoke 126 VPN-Tagging Server support 24 VRF class 109, 125 S Scheduled discovery interval 160 Seed system 134 SNMP Discovery BGP4-MIB objects ist of 171 Discovery 2VPN MIB objects ist of 167 Discovery 3VPN MIB objects ist of 169 Discovery MPS MIB objects ist of 164 SNMP MIB support 21 subsps 17, 20 Support CI 21 Device 21 IPv4 21 SP 17 Multi-VRF CE 24 Overlapping IP address 24 SNMP MIB 21 VPN 18 VPN-Tagging Server 24 System Definition of 16 T TE SPs 17, 20, 75, 82 TE tunnels 17 Topology import 33, 60 EMC Ionix MPS Manager Version 9.0 Discovery Guide 193

194 Index 194 EMC Ionix MPS Manager Version 9.0 Discovery Guide