Configure an advanced MPLS discovery for extra customization facilities not included in the standard MPLS discovery.
When you configure an advanced MPLS discovery, you must perform the following activities in addition to the activities required for a standard MPLS discovery.
v Define the scope of the MPLS discovery: enables you to restrict the scope of this discovery to a particular VPN or VRF.
v Specify a VPN name: enables you to configure your own VPN naming convention
v Fine-tune label data discovery: enables you to force LSP discovery regardless of the MPLS discovery method selected
Configuring discovery of MPLS Traffic Engineered tunnels:
To discover MPLS Traffic Engineered tunnels, enable the StandardMPLSTE agent, configure the information that is retrieved, and configure the scope of the
discovery.
MPLS Traffic Engineered tunnel discovery modes:
Set the discovery mode according to how much detail you want to retrieve.
A mode-switch is provided in the discovery agent configuration file that configures specific tunnel instances, which can be wildcarded, to retrieve different amounts of tunnel data. You can choose any of the following modes.
HeadEndHops (default)
In HeadEndHops mode, the agent retrieves head-end and tail-end of the tunnel, and the transit LSRs and next-hop interfaces are identified by querying the head-end LSR for computed and actual-route hop data. The actual and computed route data is retrieved from the
mplsTunnelARHopTable and mplsTunnelCHopTable MIB tables
respectively. This discovery mode does not store transit and tail-end tunnel instances against transit and tail-end LSRs. A connection is created in the MPLS TE topology between the head-end and tail-end LSR interfaces via transit device hops (if present) which are associated with the head-end LSR tunnel object for the appropriate tunnel interface.
MPLS cross-connect pointers that are discovered and resolved on the head tunnel will be resolved to the appropriate LSP ID where possible.
You can use this information to determine if the actual path taken by a tunnel is different to the path computed by the Compute Shortest Path First (CSPF) calculations. You can see the computed and actual path, although there is no way to determine that an LSR is acting in a transit or tail capacity without looking at the head-end LSR tunnel data.
Note: Actual route data is only available if the Record Route Option (RRO) has been specified for the tunnel instance.
In the schema of the scope.mplsTe table, the HeadEndHops mode maps to value 1 of m_Mode.
HeadTailEnd
In HeadTailEnd mode, only MPLS TE tunnel head-end and tail-end points are resolved, by querying the head-end Label Switching Router (LSR). This mode provides the minimal amount of information about the MPLS TE tunnels. A connection in the MPLS TE topology is created between the head-end and tail-end LSR interfaces. A tunnel resource instance is associated with the head-end tunnel LSR entity.
In this mode, you cannot identify the transit LSRs, and computed and actual route data is not retrieved.
MPLS cross-connect pointers that are discovered and resolved on the head tunnel will be resolved to the appropriate LSP ID where possible.
In the schema of the scope.mplsTe table, the HeadTailEnd mode maps to value 2 of m_Mode.
AllLSRTunnelsAndHops
In AllLSRTunnelsAndHops mode, the agent retrieves the head-end and tail-end of the tunnel and identifies transit LSRs and next-hop interfaces by querying the head-end LSR for computed and actual route hop data. The actual and computed route data is retrieved from the
mplsTunnelARHopTable and mplsTunnelCHopTable MIB tables respectively. This discovery mode stores transit and tail-end tunnel instances against transit and tail-end LSRs. The mode creates a connection in the MPLS TE topology between the head-end and tail-end LSR
interfaces that are associated with the head-end (for the tunnel interface) and transit and tail-end LSR tunnel objects. Computed and actual-route connections are associated with Computed and Actual connection entity types, which are aggregated in sequence from the head-end LSR tunnel entity. A tunnel resource instance is associated with the head-end tunnel LSR entity.
You can use this information to determine if the actual path taken by a tunnel is different to the path computed by the CSPF calculations. You can see the computed and actual path and determine the transit or tail-end role of an LSR without looking at the headend LSR tunnel instance.
Note: Actual route data is only available if the Record Route Option (RRO) has been specified for the tunnel instance.
MPLS cross-connect pointers that are discovered and resolved on the head tunnel will be resolved to the appropriate LSP ID where possible.
In the schema of the scope.mplsTe table, the AllLSRTunnelsAndHops mode maps to value 3 of m_Mode.
Related reference:
“mplsTe table” on page 203
The mplsTe table defines the scope of MPLS Traffic Engineered (TE) tunnel discovery, and defines what information is retrieved.
Enabling the StandardMPLSTE agent:
To discover MPLS TE tunnels, you must enable the StandardMPLSTE agent and add the relevant SNMP community strings.
To enable the StandardMPLSTE agent, complete the following steps.
1. Click Discovery > Network Discovery Configuration. From the Domain list, select the required domain.
2. Click the Full Discovery Agents tab. The Agents List is displayed, showing all available discovery agents for the selected discovery option.
3. Select the check box next to the StandardMPLSTE agent.
4. Click Save .
5. Optional: If you want to rediscover MPLS TE tunnels, enable the StandardMPLSTE agent for partial rediscoveries.
a. Click the Partial Rediscovery Agents tab.
b. Select the check box next to the StandardMPLSTE agent.
c. Click Save .
6. Ensure that the SNMP community strings are configured correctly to access the devices in the MPLS TE tunnels.
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.
Configuring the StandardMPLSTE agent:
Configure which tunnels to discover, and what details to retrieve.
To configure the StandardMPLSTE agent, complete the following steps.
1. Back up and edit the file NCHOME/etc/precision/DiscoScope.cfg.
2. Locate and edit the insert into the scope.mplsTe table, or create a new insert.
Create or edit an insert similar to the following:
insert into scope.mplsTe (
m_Protocol, m_Zones, m_Mode, m_TunnelFilter )
values (
1,
[{m_Subnet = ’192.168.1.0’, m_NetMask = 24 }], 2,
1 );
This insert configures the agent to behave in the following way:
v It uses IPv4.
v It includes (m_Tunnelfilter=1) the subnet 192.168.1.* in the discovery of tunnel heads.
v It retrieves data for the head and tail of the tunnel but not for the transit routers.
3. Save and close the file.
4. Stop and restart the discovery engine, the ncp_disco process, for your configuration changes to take effect.
Related reference:
“mplsTe table” on page 203
The mplsTe table defines the scope of MPLS Traffic Engineered (TE) tunnel discovery, and defines what information is retrieved.
Defining the scope of an MPLS/VPN discovery:
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.
You restrict the scope by configuring the optional DiscoAgentDiscoveryScoping section in the *.agnt file. The configurable options are described in Table 13.
Table 13. Defining MPLS scoping requirements
Option Function
IncludeVRF Allows the discovery of the named VRF IncludeVPN Allows the discovery of the named VPN
ExcludeVPN Does not discover any VRFs within the named VPN ExcludeVRF Does not discover the specified VRF
The order of precedence for Exclude and Include within the DiscoAgentDiscoveryScoping section is:
1. Exclude 2. Include
The order of precedence for VRF and VPN within the DiscoAgentDiscoveryScoping is:
1. VRF 2. VPN
For example, if you include a VPN, but another filter excludes a VRF in your VPN, then the VRF is excluded. If a VPN is excluded, but another filter includes a VRF within that VPN, then the VRF is included.
VRF names are case sensitive and an asterisk ( * ) represents a wildcard for any VRF or VPN name when used in the name part of the configuration. The wildcard can be used with any of the above options.
Scoping by VPN name works only when the VRF names configured on the devices discovered by the MPLS agents are in the Cisco-recommended VRF format. A VRF is named based on the VPN or VPNs serviced, and the topology type. The format for the VRF names are:
V [number assigned to make the VRF name unique]: [VPN_name]
For example, in a VPN called precision, a VRF for a hub edge router would be:
V1:precision
A VRF for a spoke edge router in the precision VPN would be:
V1:precision-s
A VRF for an extranet VPN topology in the precision VPN would be:
V1:precision-etc
The following example scopes a discovery in a system where there are four VRFs:
V65:Precision-etc, V65:Precision-s, V65:Precision, and V44:AcmeSheds.
//2 VRFs are to be included //
DiscoAgentDiscoveryScoping {
IncludeVRF = “V65:Precision-etc”;
IncludeVRF = “V44:AcmeSheds”;
}
//All 4 VRFs are to be included //
DiscoAgentDiscoveryScoping {
IncludeVPN = “Precision”;
IncludeVRF = “V44:AcmeSheds”;
}
Related reference:
“disco.config table” on page 183
The config table configures the general operation of the discovery process.
Configuring VPN naming conventions:
If you do not use the Cisco VRF naming convention, you can configure your own VPN naming convention by making the appropriate inserts into the
MPLSAddVPNNames.stchstitcher located in $NCHOME/precision/disco/stitchers/.
The MPLSAddVPNNames stitcher extracts and constructs a VPN name from the list of paths discovered by the Path Tracing stitchers. The MPLSAddVPNNames stitcher can then add the VPN name to the device interfaces that fall under the paths belonging to the VPN.
The following example shows where to modify the VPN name in the MPLSAddVPNNames.stchfile, located in $NCHOME/precision/disco/stitchers.
//VPN Name Assignment //
//Currently assigns the VRF name as the VPN Name if no VPN name //has been discovered by the agent, i.e., if the VRF name was not in //the Cisco format.
//
vpnName = eval(text, '&m_VPNName’);
if (vpnName == NULL) {
vpnName = vrfName; //VPN=VRF, customize as required.
}
Fine-tuning label data:
The MPLS discovery method (RT-based or LSP-based) determines whether the MPLS agents retrieve MPLS label data.
v If you choose RT-based discovery, the MPLS agents do not retrieve label data.
v If you choose LSP-based discovery, the MPLS agents retrieve label data.
If you choose an RT-based discovery, but want to retrieve label data, it is possible to do this manually with the following insert in the DiscoAgentDiscoveryScoping section of the appropriate MPLS.agnt file:
DiscoAgentDiscoveryScoping {
GetMPLSLabelData = 1;
}
Related tasks:
“Configuring MPLS discovery method” on page 108
You can configure MPLS discovery in either of two ways: Route Target (RT)-based discovery; Label Switched Path (LSP)-based discovery.