-
Cisco MPLS Diagnostics Expert 2.1.3 User Guide on ISC 5.1
-
Index
-
About this Guide
-
Chapter 1: Introduction
-
Chapter 2: Getting Started
-
Chapter 3: Using Cisco MPLS Diagnostics Expert
-
Chapter 4: How Does Cisco MPLS Diagnostics Expert Work?
-
Appendix A: Frequently Asked Questions
-
Appendix B: VPN Topologies
-
Appendix C: Cisco MPLS Diagnostics Expert Supplemental License Agreement
-
Table Of Contents
Using Cisco MPLS Diagnostics Expert
3.1 Understanding the MDE Connectivity Tests
3.1.1 CE to CE Connectivity Test
3.1.2 PE to Locally Attached CE Connectivity Test
3.1.3 CE to Remote PE Across MPLS Core Connectivity Test
3.1.4 PE to PE in VRF Connectivity Test
3.1.5 PE to PE Core Connectivity Test
3.2 Performing an MPLS VPN Connectivity Verification Test
3.2.1 Opening the MPLS Diagnostics Feature Selection Window
3.2.2 Selecting, Configuring, and Running a CE to CE Test
3.2.3 Selecting, Configuring, and Running a PE to Attached CE Test
3.2.4 Selecting, Configuring, and Running a CE to PE Across Core Test
3.2.5 Selecting, Configuring, and Running a PE to PE (in VRF) Test
3.2.6 Selecting, Configuring, and Running a PE to PE (Core) Test
3.4 Interpreting the Test Results
3.5 Advanced Troubleshooting Options
3.6 Switching Tunnel Checking Off—For Networks with Non-Cisco P Routers
Using Cisco MPLS Diagnostics Expert
This chapter describes how to use Cisco MPLS Diagnostics Expert (MDE).
This chapter contains the following sections:
•
Understanding the MDE Connectivity Tests
•
•
•
•
Figure 3-1 describes the workflow for using MDE.
Figure 3-1 Using MDE Workflow
1.
2.
3.
4.
5.
6.
7.
3.1 Understanding the MDE Connectivity Tests
The connectivity tests are designed to troubleshoot subsections of the overall CE to CE network. The provided connectivity tests are as follows:
1.
2.
3.
4.
5.
3.1.1 CE to CE Connectivity Test
The CE to CE test (Figure 3-2) checks the MPLS VPN connectivity between two CEs or Customer devices where the Customer device IP address is known.
Figure 3-2 CE to CE Connectivity Test
MDE performs core, edge, and attachment circuit troubleshooting in this case.
3.1.2 PE to Locally Attached CE Connectivity Test
The PE to locally attached CE connectivity test (Figure 3-3) performs a VPN connectivity test between a PE and the locally attached CE. MDE performs edge and attachment circuit troubleshooting in this case.
Figure 3-3 PE to Locally Attached CE Connectivity Test
The PE to locally attached CE connectivity test cannot be run in the reverse direction.
The local attachment circuit is often responsible for a connectivity failure. You can test the local attachment circuit on its own, without requiring remote site PE and CE details that might not be available.
The PE to locally attached CE connectivity test allows you to diagnose the same attachment circuit connectivity outage reported by a VRF-aware IP SLA probe. The notification has all the information required to set up the corresponding access circuit connectivity test in MDE.
3.1.3 CE to Remote PE Across MPLS Core Connectivity Test
The CE to remote PE connectivity test (Figure 3-4) checks the MPLS VPN connectivity between a CE or Customer devices (where the Customer device IP address is known), and a PE across the MPLS core.
Figure 3-4 CE to Remote PE Across MPLS Core Connectivity Test
MDE troubleshoots the core, both edges, and the attachment circuit in this case.
3.1.4 PE to PE in VRF Connectivity Test
The PE to PE in VRF connectivity test (Figure 3-5) checks the MPLS VPN connectivity between two PEs. MDE troubleshoots the core and the edge on both sides.
Figure 3-5 PE to PE in VRF Connectivity Test
Some organizations provision the core or edge network but do not immediately allocate CEs. The PE to PE connectivity in VRF test allows you to deploy and test your network in phases. This test option also provides more flexibility and allows the edge or core network segment to be tested when CE information is not readily available.
The PE to PE connectivity in VRF connectivity test also allows you to diagnose the same short reach (PE to remote PE) VPN connectivity outage reported by a VRF-aware IP SLA probe. The notification has all the information to set up the corresponding edge connectivity test in MDE.
3.1.5 PE to PE Core Connectivity Test
The PE to PE core connectivity test (Figure 3-6) checks the MPLS connectivity between two PEs.
Figure 3-6 PE to PE Core Connectivity Test
The PE to PE core test is intended for cases where there is blocked access to the CE interface, such as using an access list, or cases where different groups within an organization are responsible for different network segments. For example, a Core group might have a P issue but does not have the end customer context to perform a full CE-CE or PE-PE test.
The PE to PE core test allows you to diagnose the same core connectivity outage reported by IP SLA Health monitor probes testing connectivity between MPLS enabled PEs. The notification has all the information to set up the corresponding core connectivity test in MDE.
3.2 Performing an MPLS VPN Connectivity Verification Test
This section describes how to perform an MPLS VPN Connectivity Verification test. This section contains the following information:
•
•
•
•
•
•
3.2.1 Opening the MPLS Diagnostics Feature Selection Window
Note
Step 1
Step 2
Note
Note
Figure 3-7 Diagnostics Tab
3.2.2 Selecting, Configuring, and Running a CE to CE Test
This section details how to select, configure, and run a CE to CE test type.
Step 1
Step 2
Tip
Tip
Tip
Tip
Figure 3-8 MPLS VPN Connectivity Verification Configuration Window—CE to CE Test Type
The MPLS VPN Connectivity Verification Configuration window allows you to configure the connectivity test you would like to perform.
This window displays the following components:
•
•
•
The network diagram is a static image that provides you with context for the information you must enter to configure the test.
MPLS VPN Connectivity Verification tests connectivity between two sites in a VPN. Throughout the test, these sites are referred to as the local site and remote site. It is anticipated that a connectivity problem will be reported or detected from the perspective of a particular site. This particular site would typically be used as the local site, and the test is performed from this site. However, this is not mandatory, as any site can be used as the local or remote site, because connectivity can be tested in both directions.
The scope of the L3 VPN connectivity test (see Figure 3-9) can be changed on a per-site basis. For each site you can test connectivity to a customer device within the site (shown in Figure 3-9 as 1), or to the CE access circuit interface (shown in Figure 3-9 as 2). The test scope is determined by the configuration that you provide.
Where the IP address of a customer device is known, it might be desirable to perform a connectivity verification test to that device. Where the IP address of a customer device is not known, the connectivity verification test can be performed to the CE for the site.
Figure 3-9 Test Scope
1.
2.
To test connectivity to a device within the customer site subnetwork, you should enter the IP address of the device in the Customer Device IP Address field. By default, if you specify only the required fields for a site, the test is performed to the CE access circuit interface.
Note
Note
Cisco IOS and Cisco IOS XR Access Control Lists (ACL) allow selected traffic to be blocked based on a wide variety of criteria. ACLs configured on the CE can lead to inconsistent results being reported when an MPLS VPN Connectivity Verification test is performed to a customer device or CE interface. Where possible, an MPLS VPN Connectivity Verification test reports that traffic is blocked by an ACL configured on the CE device. However, depending on ACL configuration, it is not always possible to determine that traffic is blocked by an ACL configured on the CE device. In some cases an MPLS VPN Connectivity Verification test might report an access circuit failure or unknown failure. In cases where it is suspected that traffic is being blocked at the CE, the Pings Blocked check box should be checked for that site. This allows MDE to take account the blocking access ACL when troubleshooting and therefore return a more accurate diagnosis of any problem found.
Note
Step 3
Note
Note
Table 3-1 Field Descriptions for the MPLS VPN Connectivity Verification Configuration Window
Populate from VRF button
All
Click the Populate from VRF button to open the Select Device for VRF Search window. The Select Device for VRF Search window allows you to configure the test using PE hostname or PE interface details identified using a VRF search. (See the "Configuring Using Customer VRF Information" section.)
PE Device Name (required field)
All
Enter the site PE Device Name in the PE Device Name field or select the site PE Device Name by clicking the Select button.
Note
The Device Name is the fully qualified hostname and domain name of the device. For example, router1.cisco.com. However, the domain name is optional so in many cases the Device Name is the device hostname. For example, router1.
The Device Name specified must match that of a PE device with role type of N-PE. For details of how to create PE devices, see the "2.7 Inventory Setup" section on page 2-5.
LSP Endpoint Loopback IP Address
PE to PE Core only
Enter the BGP next hop if different from the BGP router ID of the peer PE. You can enter the loopback IP address, or you can enter the loopback name that will be resolved to the IP address.
When testing the core, an MPLS OAM ping and trace is performed from the local PE to the remote PE. The destination of this ping causes an LSP to be selected based on the routing information on the local PE.
Customer traffic uses the BGP next hop address of the customer route as its destination, and to select the LSP. Make sure that the IP prefix MDE tests to matches the BGP next hop address used by the customer traffic. This ensures that MDE tests the same LSP as the customer traffic traverses.
In the case of PE to PE core testing, MDE does not have any customer route information. MDE therefore has no way to determine the BGP next hop and chooses the ping destination, not based on the next hop, but on the BGP router ID on the remote PE.
In some network configurations, this router ID does not match the next hop used by the customer traffic and the incorrect (or no) LSP is tested.
This happens when:
•
•
•
•
In the above bullet points you need to provide the correct BGP next hop.
Note
See the "Configuring the LSP Endpoint Loopback IP Address for a PE to PE (Core) Test" section for further information.
PE Access Circuit Interface (required field)
CE to CE
PE to locally attached CE
CE to remote PE across MPLS Core
PE to PE in VRF
Enter the interface name of the PE Access Circuit Interface in the PE Access Circuit Interface field or select the PE Access Circuit Interface by clicking the Select button.
Note
You must specify a valid PE Device Name before selecting the PE Access Circuit Interface. The interface specified should be the access circuit interface attached to the site's CE. The interface name specified must match an interface on the device, but the interface does not necessarily need to be in the ISC device inventory.
CE Access Circuit Interface IP Address (optional field)
CE to CE
PE to locally attached CE
CE to remote PE across MPLS Core
Enter the IP address of the CE access circuit interface for the local site. This should be the access circuit interface attached to the specified PE.
When a PE Access Circuit Interface configured with a /30 subnet mask (255.255.255.252) or a /31subnet mask (255.255.255.254) is selected, the CE Access Circuit Interface IP Address field is auto-completed with the remaining host address from that /30 or /31 subnet. When a PE Access Circuit Interface configured with a /31 mask (255.255.255.254) subnet mask has been manually entered, an attempt to derive the CE access circuit interface IP address is only made after the test is initiated. In this instance, the CE Access Circuit Interface IP Address field is not auto-completed before the OK button is clicked.
It is not possible to derive the correct CE access circuit interface IP address in cases where the PE access circuit interface is using IP unnumbered or the CE access circuit interface is on a different subnet.
The test supports managed and unmanaged Cisco CE devices, and non-Cisco CE devices.
Pings Blocked (optional field)
CE to CE
PE to locally attached CE
CE to remote PE across MPLS Core
Check this check box to specify that there is an ACL configured on the CE that will block ping and trace route packets originating from the provider core network.
Customer Device IP Address (optional field)
CE to CE
PE to locally attached CE
CE to remote PE across MPLS Core
Enter the IP address of a customer device on the local site customer network. Entering the customer device IP address causes the connectivity test to be performed to this device.
Populate from VPN button
All
Click the Populate from VPN button to open the Populate from VPN window. The Populate from VPN window allows you to configure the test using customer VPN information (see the "Configuring Using Customer VPN Information" section.)
OK button
All
Click OK to run the test.
Clear button
All
Click Clear to reset all the fields in the window.
Step 4
3.2.2.1 Selecting a PE Device
Click the Select button (for the Local/Remote PE Device Name) to open the Select PE Device window (see Figure 3-10) where you can choose the local/remote site PE. The Select PE Device window displays a table containing all the PE devices available in the inventory.
Note
Figure 3-10 Select PE Device Window
Note
3.2.2.2 Selecting a PE Access Circuit Interface
Click the Select button (for the Local/Remote PE Access Circuit Interface) to open the Select Device Interface window (see Figure 3-11) where you can choose the interface name. The Select Device Interface window displays a table containing all interfaces for the selected local/remote PE device.
Figure 3-11 Select Device Interface Window
You can perform a wildcard string search of all attributes displayed in the table. If you select a Local/Remote PE Access Circuit Interface from the ISC inventory, this overrides anything entered in the Local/Remote PE Access Circuit Interface field (see Figure 3-8).
Table 3-2 provides field descriptions for the Select Device Interface window.
Timesaver
Tip
Figure 3-12 displays an example of searching on the Interface Description using a wildcard search to find the appropriate interface.
Figure 3-12 Select Device Interface Window—Example of Searching on Interface Description
3.2.2.3 Testing Across Cisco IOS Multilink Access Circuit Interfaces
MDE supports troubleshooting across Cisco IOS multilink access circuit interfaces. Troubleshooting is performed on the multilink bundle interface only. No troubleshooting of the individual bundle links or multilink specific troubleshooting is performed. The following multilink technologies are supported:
•
•
•
•
•
•
Note
Note
Each multilink bundle has a number of interfaces associated with it. When configuring an MPLS VPN Connectivity Verification test over a multilink access circuit, you must ensure you enter the correct interface in the PE Access Circuit Interface field of the MPLS VPN Test Configuration window. The interface which you must enter varies depending on the multilink configuration used. Table 3-3 details the interface that must be entered in the PE Access Circuit Interface field for each multilink technology.
With the exception of Multilink Frame Relay (MFR), the interface that represents the multilink bundle must be entered in the PE Access Circuit Interface field. For Multilink Frame Relay, the Frame Relay interface, or subinterface against which the Virtual Circuit is configured must be entered. This might be the MFR interface or a subinterface of the MFR interface. In all cases the interface entered in the PE Access Circuit Interface field should have an IP address and VRF and be in the up/up state.
To determine the valid multilink bundle interfaces on a PE device, use the show ppp multilink or show frame-relay multilink IOS command. If there are no active multilink bundles on your PE device, then there might be none configured or all bundle links for any configured multilink bundles might be in the down/down state.
Note
3.2.2.4 Configuring Using Customer VRF Information
You need to supply PE hostname or PE interface details when entering information into the MPLS VPN Connectivity Verification window. In certain instances, you might not know the PE hostname or PE interface details. However, this information can be identified through a corresponding and known VRF name. You can identify a corresponding VRF name using a VRF search.
Note
Step 1
Note
Figure 3-13 Select Device for VRF Search Window
Step 2
Timesaver
Step 3
Tip
Tip
Step 4
Step 5
Step 6
3.2.2.5 Configuring Using Customer VPN Information
MDE can be used standalone, without any dependency on other ISC functionality. However, if ISC VPN Provisioning functionality is used to provision VPNs within the network, this provisioning information, associated with the customer and VPN, can be used as an alternative means to configure an MPLS VPN Connectivity Verification test. Rather than specifying device-specific configuration, you can specify a customer, VPN, local site, and remote site. All required test configuration is then derived from this information.
Note
Step 1
Figure 3-14 Populate from VPN Window
Step 2
Step 3
Note
Note
Step 4
3.2.2.6 VPN Topologies
By default, an MPLS VPN Connectivity Verification test assumes that the local and remote sites are connected through a full mesh VPN topology and that these sites can communicate directly. If the sites being tested are connected through a VPN topology other than full mesh, the required configuration for an MPLS VPN Connectivity Verification test might differ. In this situation, the test might produce misleading results, so you must take care when interpreting the test results. See Appendix B, "VPN Topologies" for details of the configuration required and how the test results should be interpreted for each supported VPN topology.
3.2.3 Selecting, Configuring, and Running a PE to Attached CE Test
This section details how to select, configure, and run a PE to attached CE test type.
Step 1
Step 2
The MPLS VPN Connectivity Verification Configuration window appears (Figure 3-15) displaying the fields corresponding to the PE to attached CE test type. The MPLS VPN Connectivity Verification Configuration window allows you to configure the connectivity test you would like to perform.
Figure 3-15 MPLS VPN Connectivity Verification Configuration Window—PE to attached CE Test Type
The MPLS VPN Connectivity Verification Configuration window displays the following components:
•
•
These components and the test scope are described in further detail in the "Selecting, Configuring, and Running a CE to CE Test" section.
Step 3
Step 4
3.2.4 Selecting, Configuring, and Running a CE to PE Across Core Test
This section details how to select, configure, and run a CE to PE across core test type.
Step 1
Step 2
The MPLS VPN Connectivity Verification Configuration window appears (Figure 3-16) displaying the fields corresponding to the CE to PE across core test type. The MPLS VPN Connectivity Verification Configuration window allows you to configure the connectivity test you would like to perform.
Figure 3-16 MPLS VPN Connectivity Verification Configuration Window—CE to PE Across Core Test Type
The MPLS VPN Connectivity Verification Configuration window displays the following components:
•
•
•
These components and the test scope are described in further detail in the "Selecting, Configuring, and Running a CE to CE Test" section.
Step 3
Step 4
3.2.5 Selecting, Configuring, and Running a PE to PE (in VRF) Test
This section details how to select, configure, and run a PE to PE (in VRF) test type.
Step 1
Step 2
The MPLS VPN Connectivity Verification Configuration window appears (Figure 3-17) displaying the fields corresponding to the PE to PE (in VRF) test type. The MPLS VPN Connectivity Verification Configuration window allows you to configure the connectivity test you would like to perform.
Figure 3-17 MPLS VPN Connectivity Verification Configuration Window—PE to PE (in VRF) Test Type
The MPLS VPN Connectivity Verification Configuration window displays the following components:
•
•
•
These components and the test scope are described in further detail in the "Selecting, Configuring, and Running a CE to CE Test" section.
Step 3
Step 4
3.2.6 Selecting, Configuring, and Running a PE to PE (Core) Test
This section details how to select, configure, and run a PE to PE (Core) test type.
Step 1
Step 2
The MPLS VPN Connectivity Verification Configuration window appears (Figure 3-18) displaying the fields corresponding to the PE to PE (Core) test type. The MPLS VPN Connectivity Verification Configuration window allows you to configure the connectivity test you would like to perform.
Figure 3-18 MPLS VPN Connectivity Verification Configuration Window—PE to PE (Core) Test Type
The MPLS VPN Connectivity Verification Configuration window displays the following components:
•
•
•
These components and the test scope are described in further detail in the "Selecting, Configuring, and Running a CE to CE Test" section.
Step 3
Step 4
3.2.6.1 Configuring the LSP Endpoint Loopback IP Address for a PE to PE (Core) Test
This section details how to configure the LSP endpoint loopback interface and IP address for the PE to PE (Core) test type.
3.2.6.1.1 Remote LSP Endpoint Loopback IP Address
L3 VPN Customer traffic uses the BGP next hop address of the customer route to select the LSP. When testing the core, an MPLS OAM ping and trace is performed from the local PE to the remote PE. To ensure that MDE tests the same LSP as your traffic traverses, the IP prefix MDE tests to is the BGP next hop address of the customer route.
MDE does not have customer route information for the PE to PE core test type. MDE therefore has no way to determine the BGP next hop. By default, MDE chooses the ping and trace destination, not based on the next hop, but on the BGP router ID on the remote PE. In some network configurations, such as those with multiple cores, or with multiple loopback addresses used for control and data plane traffic, this BGP router ID might not match the next hop used by the customer traffic and the incorrect (or no) LSP is tested.
3.2.6.1.2 Local LSP Endpoint Loopback IP Address
The PE to PE (core) test type allows you to perform the test in the reverse direction when running the test in the forward direction fails to find the problem. Configuring the local LSP endpoint loopback IP address ensures that the test selects the correct LSP when the test is run in the reverse direction.
3.2.6.1.3 When Should I Specify the LSP Endpoint Loopback IP Address?
Specify the LSP endpoint loopback IP address when:
•
•
•
•
Note
Figure 3-19 displays an example network topology that illustrates the LSP Endpoint Loopback IP Address field usage. This example network topology has three logical MPLS cores and some of the PE BGP router-ids are not associated with a loopback interface. In addition, two of the CEs are dual homed to different cores.
Figure 3-19 Example Network Topology
Table 3-6 provides IP addressing information relating to the example network topology displayed in Figure 3-19.
Table 3-7 specifies the IP addresses that can be used as the remote LSP Endpoint IP Address to test each LSP.
3.3 Progress Window
The Progress window appears (see Figure 3-20) while the test is being performed.
Note
The Progress window displays a one-line textual summary of each step that has been completed and the step that is currently executing.
Figure 3-20 Progress Window
Click the Cancel button to cancel the test if required. If you click Cancel, you are asked to confirm that you want to cancel the test. If you confirm, the test is cancelled when the current step has completed. If the current step involves device interaction, this completes before the test is cancelled. Upon cancellation, the Test Results window appears indicating that you cancelled the test. All completed steps are displayed in the test log.
When the test is complete, the Test Results window appears. See the "Interpreting the Test Results" section, for further details.
3.4 Interpreting the Test Results
This section describes how to interpret your test results. This section contains the following information:
Upon completion of a MPLS VPN Connectivity Verification test, the Test Results window appears (see Figure 3-21).
Figure 3-21 Test Results Window with Failure Specific Additional Information Displayed
The Test Result window displays the location and cause of the problem found, recommended actions, observations, and details of the automated troubleshooting and diagnostics steps performed. The Test Result window also allows you to invoke advanced troubleshooting options where appropriate (see Table 3-8).
The Test Results window consists of the following components:
Table 3-8 Field Descriptions for the Test Results Window
Data path
See the "Data Path" section
Test Details
See the "Test Details" section
Test Log
See the "Test Log" section
Export button
The Export button appears when the Test Log radio button is selected. See the "Export" section.
Advanced button
Click the Advanced button to launch advanced troubleshooting. See the "Advanced Troubleshooting Options" section. The options available on this button are dynamically configured depending on the test result and the test type.
Re-test button
Click the Re-test button to rerun the connectivity test using the existing configuration. This can be used to verify the fix implemented.
Cancel button
Click the Cancel button to cancel the current test and return to the Test Configuration window. You will not be asked to confirm the cancellation.
If multiple failures exist in the tested path, the failure reported is determined by the order in which MDE performs troubleshooting. For the CE to CE connectivity test type, MDE troubleshooting is performed in the following order:
1.
2.
3.
4.
The other test types troubleshoot in the same order, but do not perform all of the steps.
Note
3.4.1 Data Path
The Data Path (see Figure 3-22) shows a graphical representation of the path between the two sites that have been tested. If a failure is found on an MPLS Traffic Engineered tunnel, the tunnel is displayed in the Data Path.
Figure 3-22 Data Path
1.
2.
3.
4.
5.
6.
7.
8.
Where present, MPLS TE tunnels are displayed below the device path.
If a Customer Device IP address is specified, this IP address will appear beside the text "Customer Device."
Note
If a failure is found, the data path highlights the failed device or link. The device colors used in the data path are described in Table 3-9.
The link color used in the data path is described in Table 3-10.
Table 3-10 Data Path Link Color Code
Red
A connectivity failure has been found. This failure might be due to a problem on one or both attached devices.
For each core PE and P device, the following information is displayed:
•
•
•
•
The information displayed for CE devices and customer devices is minimal. Typically only the information provided during test configuration is displayed for these devices.
The following information is displayed for an MPLS Traffic Engineered tunnel:
•
•
•
Note
3.4.2 Test Details
The Test Details section of the Test Results window (see Figure 3-21) displays a summary of the automated troubleshooting and diagnostics results, observations made during troubleshooting, additional failure-specific information, and recommended action. See the Cisco MPLS Diagnostics Expert 2.1.3 Failure Scenarios Guide on ISC 5.1 for details of failures and observations reported by MDE, and for a list of all IOS and IOS XR commands executed by MDE as part of the troubleshooting.
The Test Details summary is displayed in all cases. The test details summary consists of three fields that detail:
•
•
•
Failure-specific additional information is displayed below the summary as required. When displayed, this provides additional information on the problem found. For example, Forwarding Information Base (FIB), Label Forwarding Information Base (LFIB), Border Gateway Protocol (BGP) table entries, and route target import/exports. This additional failure specific information helps highlight problems such as FIB, LFIB, BGP inconsistencies, and route target import/export mismatches. For some failures no additional information is displayed.
Figure 3-21 shows an example Test Results window with failure specific information below the Test Details summary. The Test Details radio button is selected by default.
Observations made during troubleshooting are displayed as notes below the Test Details summary. Observation notes detail observations made during troubleshooting which could be related to the failure. They should be considered as additional troubleshooting information. Figure 3-23 shows an example Test Results window with two observation notes. In some cases no observation notes are displayed, while in other cases multiple notes might be displayed.
Figure 3-23 Test Results Window with Observation Notes
3.4.3 Test Log
Click the Test Log (see Figure 3-24) radio button to display details of all troubleshooting and diagnostics steps in the order in which they were performed.
Figure 3-24 Test Results Window—Test Log
Some steps require device interaction involving the execution of IOS or IOS XR CLI commands. These steps appear in the Test Log as hyperlinks. Clicking a hyperlink opens a pop-up window that displays the IOS or IOS XR CLI transcript for the step (see Figure 3-25). This transcript includes the IOS or IOS XR commands run and all resulting output.
Figure 3-25 IOS CLI Transcript Window
3.4.4 Export
You might want to export the test log to include it in a trouble ticket, problem escalation, or when contacting Cisco TAC. The test log can be exported to file through the Export button located at the bottom of the Test Log (see Figure 3-24). All steps displayed in the test log, including IOS and IOS XR CLI transcripts, are exported in text format.
Step 1
Step 2
3.5 Advanced Troubleshooting Options
This section describes advanced troubleshooting options, as follows:
Advanced troubleshooting provides further options that you can use to troubleshoot your network.
The advanced troubleshooting options supported are detailed in Table 3-11.
The appropriate advanced troubleshooting options are made available through the Advanced drop-down button at the bottom of the Test Results window.
3.5.1 Reverse Path Testing
Note
In some cases, the MPLS VPN Connectivity Verification test detects a connectivity failure but is unable to identify the cause of this failure. By repeating the test in the reverse direction (that is, reversing the local and remote site configuration), it might be possible to identify the cause of the problem. In other cases, repeating the test in the reverse direction can result in a more precise diagnosis of the problem found. For example, while performing a connectivity test in the forward direction, an LSP connectivity problem might be identified on a device. However, this problem could be caused by an LDP misconfiguration on the downstream LSP neighbor. By repeating the test in the reverse direction, the misconfigured downstream router is encountered first and the LDP misconfiguration is diagnosed. When this situation occurs, the Test Details displayed in the Test Results window advises you to perform the test in the reverse direction. The Reverse Test option is available on the Advanced drop-down button in the Test Results window.
Selecting the Reverse Test advanced troubleshooting option invokes the MPLS VPN Connectivity Verification test in the reverse direction. No further configuration is required.
The results of the reverse path testing are displayed in the Test Results window.
3.5.2 LSP Visualization
Note
When no failure is found, the Test Results window data path displays a summary of the test performed. This does not show details of the path through the core that has been tested. LSP Visualization displays a hop-by-hop Data Path illustration of the MPLS label switched path (LSP) between the local and remote sites (see Figure 3-26). Any forward-path or reverse-path PE to PE MPLS TE tunnels are also displayed. The path shown is the path tested during the MPLS VPN Connectivity Verification test.
Figure 3-26 Test Results Window—LSP Visualization
The Data Path displays the following for each PE and P device in the tested path:
•
•
•
•
The Data Path displays the following for each PE to PE MPLS Traffic Engineered tunnel:
•
•
•
Note
For more details of what is displayed in the Data Path, see the "Data Path" section.
LSP Visualization is only offered when an MPLS VPN Connectivity Verification test does not detect a connectivity problem.
Note
3.6 Switching Tunnel Checking Off—For Networks with Non-Cisco P Routers
During tunnel diagnostics, MDE might be required to visit every device to determine if a tunnel is present at that point. Since MDE does not log in to non-Cisco devices, this can result in a misdiagnosis of a fault occurring at the non-Cisco device (even thought it might not be the actual source of the fault) as the troubleshooting workflow is unable to proceed. As a result, it is useful to disable tunnel diagnostics for networks that contain non-Cisco devices.
Tunnel diagnostics is enabled as default. The default value can be changed by an Admin user, within the the ISC Control Center (Administration tab > Control Center > Hosts). Tunnel diagnostics can be enabled or disabled within the Command Flow Runner (cfr) component (parameter disableTunnelDiagnostics). When the appropriate disableTunnelDiagnostics parameter is set to true, MDE does not perform tunnel diagnostics. See the Administration chapter in the Cisco IP Solution Center Infrastructure Reference, 5.1.
The Test Results window displays an observation message stating that MDE tunnel diagnostics are disabled. The error message indicating a device is not in the inventory mentions that a possible cause is a non-Cisco device on the path, and that the error might be on this device or a near neighbor.
