Configure an MPLS discovery to discover core MPLS networks and the VPNs that use these core networks.
In addition to the standard discovery configuration activities, you must perform some MPLS-specific discovery configuration activities:
v Configure MPLS agents
v Specify the discovery methods, that is, whether to run a route-target or label-switched path (LSP) discovery
v Configure SNP and Telnet to ensure that the agents can access network devices v Configure Network Manager to infer the existence of CE routers. This step is
necessary to enable operators to view service-affected events in the Active Event List (AEL).
These EMS-specific discovery configuration activities are described in the following topics.
Configuring MPLS agents:
As part of MPLS discovery configuration you must enable one or more MPLS agents. You can also resolve the problem of duplicate IP addresses in different Virtual Private Networks (VPNs) by configuring the AsAgent agent.
The following MPLS agents and the corresponding agent definition (.agnt) files are provided:
v Juniper Telnet agent (JuniperMPLSTelnet.agnt)
v Juniper ERX router agent (UnisphereMPLSTelnet.agnt) v Cisco MPLS Telnet agent (CiscoMPLSTelnet.agnt) v Cisco MPLS SNMP agent (CiscoMPLSSnmp.agnt) v Laurel MPLS Telnet agent (LaurelMPLSTelnet.agnt)
Note: The Laurel MPLS Telnet agent is intended for RT- (RouteTarget) based discoveries only.
These agents can discover MPLS VPN and Virtual Private LAN Service (VPLS) data from devices in the network.
Tip: Agents that retrieve VPLS information can retrieve large amounts of data.
Enabling these agents can add significant processing time to the discovery process.
If you do not need to rediscover VPLS information, disable these agents for a faster discovery.
Note: If you have an MPLS network that supports both Layer 3 and enhanced Layer 2 VPNs, then the same MPLS agents discover both types of VPN. Network Views can also partition both Layer 3 and enhanced Layer 2 VPNs simultaneously on the same core MPLS network.
If your MPLS network contains Cisco equipment, enable both the Cisco MPLS Telnet and Cisco MPLS SNMP agents. These two agents complement each other, as follows:
v Cisco MPLS SNMP agent targets only devices with an Internetwork Operating System (IOS) that fully supports SNMP-based MPLS discovery
v CiscoMPLSTelnet agent targets only devices running an IOS that does not fully support an SNMP-based discovery
Attention: Use caution when altering the CiscMPLSSnmp.agnt file. Some network devices might contain IOS versions that have a flaw that might affect the device when certain MPLS SNMP data is requested. These IOS versions have been filtered out by default in the CiscMPLSSnmp.agnt file.
In addition to these standard discovery configuration activities, you can also change the scope of the MPLS discovery by restricting the scope to specific VPNs or VRFs.
Related tasks:
“Defining the scope of an MPLS/VPN discovery” on page 113
When configuring the discovery of one or more Virtual Private Networks ( VPNs ) running across an MPLS core, you can restrict the scope of this discovery to a particular VPN name or VPN Routing and Forwarding (VRF) table name.
Configuring MPLS Telnet agents:
The CiscoMPLSTelnet, JuniperMPLSTelnet, LaurelMPLSTelnet, and
UnisphereMPLSTelnet agents obtain data from devices primarily through Telnet.
You must enable these agents and configure Telnet access to ensure that MPLS Telnet agents can access devices and can understand the output from devices.
Do the following to configure Telnet access for MPLS Telnet agents:
1. Populate the Telnet configuration file TelnetStackPasswords.cfg so the agents can access the target devices.
2. Configure the Telnet Helper so that agents can understand the output from devices.
Related tasks:
“Configuring device access” on page 23
Specify SNMP community strings and Telnet access information to enable helpers and Network Manager polling to access devices on your network.
Related reference:
“TelnetStackPasswords.cfg configuration file” on page 78
The TelnetStackPasswords.cfg configuration file defines access credentials for Telnet access to devices.
Configuring MPLS SNMP agents:
The CiscoMPLSSnmp agent obtains data from devices using SNMP. You must enable this agent and configure SNMP access to ensure that this agent can access devices and can understand the output from devices.
To configure SNMP access for MPLS SNMP agents:
Note: The CiscoMPLSSnmp.agnt attempts to retrieve the L2 VPNs using the telnet 'show' commands if the agent fails to retrieve the data via SNMP.
1. Configure SNMP access to devices.
2. Configure the SNMP Helper so that agents can understand the output from devices.
Related tasks:
“Configuring device access” on page 23
Specify SNMP community strings and Telnet access information to enable helpers and Network Manager polling to access devices on your network.
Related reference:
“SnmpStackSecurityInfo.cfg configuration file” on page 75
The SnmpStackSecurityInfo.cfg configuration file defines the community strings, versioning, and other properties used by any process that needs to interrogate devices using SNMP, for example, the SNMP helper. Community strings can be configured on a per-device or per-subnet basis, to allow the SNMP Helper to retrieve MIB variables from devices.
Configuring the AsAgent agent:
To resolve the problem of duplicate IP addresses in different VPNs, activate the AsAgent agent and provide Network Manager with a mapping file, ASMap.txt, that contains a complete list of devices in each VPN, together with an AddressSpace tag, which defines which VPN the device belongs to.
During an MPLS discovery, Network Manager might discover devices in different VPNs with identical IP addresses. In this case, Network Manager cannot
differentiate between these devices and might resolve device connectivity incorrectly. The devices in question might be the CE routers at the edge of the VPNs, or might be devices within the VPNs.
In the ASMap.txt mapping file, provide a complete list of devices in each VPN, together with an AddressSpace tag, which defines which VPN the device belongs to.
Table 10 provides a description of the AsAgent agent that you need to activate to resolve the problem of duplicate IP addresses.
Table 10. AsAgent agent Agent name Function
AsAgent Enables Network Manager to uniquely identify devices in different VPNs with identical IP addresses, and thereby correctly resolve device connectivity. This agent works in conjunction with the
ASRetprocessing.stchstitcher and with the ASMap.txt file in NCHOME/precision/etc.
Table 11 provides the format of the ASMap.txt file by showing an example of the content of this file. Fields in this text file must be separated by tabs.
Table 11. Format of ASMap.txt file
Base Name Address Space IP Address
CERouter-1 CUSTOMER-1 192.168.2.1
CEDevice-a CUSTOMER-1 192.168.2.21
CEDevice-b CUSTOMER-1 192.168.2.22
CEDevice-c CUSTOMER-1 192.168.2.23
CERouter-2 CUSTOMER-2 192.168.2.1
CEDevice-a CUSTOMER-2 192.168.2.31
CEDevice-b CUSTOMER-2 192.168.2.32
Configuring MPLS discovery method:
You can configure MPLS discovery in either of two ways: Route Target (RT)-based discovery; Label Switched Path (LSP)-based discovery.
The methods to configure MPLS discovery are:
v Route Target (RT)-based discovery: Network Manager uses VRF and RT information to determine which provider edge routers are involved in a VPN.
v Label Switched Path (LSP)-based discovery: Network Manager uses VRF and LSP information to determine which provider edge (PE) routers are involved in a VPN and which provider core (P) routers are traversed by the LSPs within that VPN.
Choose which MPLS discovery method to use by setting the Enable RT Based MPLS VPN Discoverycheck box in the Discovery Configuration GUI.
v Check the Enable RT Based MPLS VPN Discovery check box to enable RT-based MPLS discovery.
v Clear the Enable RT Based MPLS VPN Discovery check box to enable LSP-based MPLS discovery.
You can also perform this configuration manually by setting the value of the field m_RTBasedVPNs in the disco.config table.
Note: RT-based discoveries are based on a more later technology than LSP-based discoveries, and can improve discovery performance. To avoid performance
problems with LSP-based MPLS/VPN discoveries, use the default RT-based option.
The RT-based option is the default option set on the Advanced tab of the Network Discovery Configuration page. You can use VRF names with the RT-based option by editing the configuration file as described in “Using VRF names with RT-based discoveries” on page 109.
Table 12 summarizes the differences between RT-based discovery and LSP-based discovery.
Table 12. RT-based discovery and LSP-based discovery
Type of Discovery Label Data Core View VPN Resolution RT-based discovery No label data is
required for this type of discovery
Discovery is faster
Consists of all MPLS-enabled devices
VPNs resolved based on RT information
LSP-based discovery Label data is discovered in order to trace LSPs Discovery is slower
Consists of devices traversed by the relevant LSPs
VPNs resolved based on VRF and label path information
Related reference:
“Advanced discovery parameters” on page 37
Advanced settings control features of the discovery such as concurrent processes and timeouts. Use these parameters to increase the speed of the discovery, but balance the speed with the load on the server. Generally, a faster discovery results in more memory usage on the server.
“disco.config table” on page 183
The config table configures the general operation of the discovery process.
Using VRF names with RT-based discoveries:
You might prefer the LSP-based discoveries in order to use the more familiar VRF name for the VPNs. However, you can also use VRF names with the RT-based discoveries.
To use VRF names with RT-based discoveries:
1. Exit all instances of the Discovery Configuration GUI.
2. Go to the NCHOME/etc/precision directory.
3. Edit the DiscoConfig.DomainName.cfg file as follows:
a. Set the m_RTVPNResolution field to 2 in the disco.config table.
b. Ensure that the m_RTBasedVPNs value is set to 1.
4. Restart the ncp processes to read the configuration files again:
itnm_stop ncp itnm_start ncp
Alternatively, restart the ncp_config process.
Inferring the existence of CE routers:
You can infer the existence of your customers’ CE routers by making specifications in the advanced discovery configuration options within the Discovery
Configuration GUI.
If the host on which Network Manager is installed has no access to your customers’ CE routers, then Network Manager cannot discover these routers directly. This situation typically occurs when the company providing MPLS services owns the PE routers but has no access to CE routers, which are owned by the customers running the VPNs.
Note: This situation does not occur if the company providing MPLS services owns and manages both PE and CE routers and therefore has access to both sets of devices.
To infer the existence of your customers’ CE routers, specify this in the advanced discovery configuration options within the Discovery Configuration GUI.
Note: You should do this only where the PE interface is on a /30 subnet. In this case, the other device on the subnet must be the CE router, and the IP address of the CE will be the other address on the /30 subnet.
Limitations on inferring CE routers:
v Avoid inferring the existence of CE routers if your PE routers are connected to the CE routers by serial links and you know that there is IP address duplication among the CE routers and devices within the MPLS core network. Network
Manager will remove from the topology any discovered MPLS core routers that have the same IP address as an inferred CE IP address.
v If your PE routers are connected to the CE routers by Ethernet, you can infer the existence of CE routers without needing to perform any other checks. In this case, Network Manager can determine the MAC address of the CE router. If Network Manager has discovered another device with the same MAC address, then it must be the CE router. In this case, Network Manager uses the
discovered device data and does not infer the existence of the CE.
Related reference:
“Advanced discovery parameters” on page 37
Advanced settings control features of the discovery such as concurrent processes and timeouts. Use these parameters to increase the speed of the discovery, but balance the speed with the load on the server. Generally, a faster discovery results in more memory usage on the server.