IP SLAs for MPLS Psuedo Wire via VCCV
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Contents
IP SLAs for MPLS Psuedo Wire via VCCVLast Updated: August 27, 2012
This module describes how to configure IP Service Level Agreements (SLAs) for MPLS Pseudo Wire (PWE3) via Virtual Circuit Connectivity Verification (VCCV) to schedule pseudo-wire ping operations and provide monitoring and alerts for round trip time (RTT), failure, and connection threshold violations via SNMP Traps.
Finding Feature InformationYour software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required. Information About IP SLAs for MPLS Pseudo Wire via VCCVIP SLAs VCCV OperationThe IP SLAs VCCV operation supports Virtual Circuit Connectivity Verification (VCCV) for Pseudo-Wire Emulation Edge-to-Edge (PWE3) services across MPLS networks. The IP SLAs VCCV operation type is based on the ping mpls pseudowire command, which checks MPLS LSP connectivity across an Any Transport over MPLS (AToM) virtual circuit (VC) by sending a series of pseudo-wire ping operations to the specified destination PE router. When MPLS LSP connectivity checking is performed through an IP SLAs VCCV operation (rather than through the ping mpls command with the pseudowire keyword), you can use the IP SLA proactive threshold monitoring and multioperation scheduling capabilities: The LSP discovery option does not support the IP SLAs VCCV operation. Proactive Threshold Monitoring for the LSP Health MonitorProactive threshold monitoring support for the LSP Health Monitor feature provides the capability for triggering SNMP trap notifications and syslog messages when user-defined reaction conditions (such as a connection loss or timeout) are met. Configuring threshold monitoring for an LSP Health Monitor operation is similar to configuring threshold monitoring for a standard IP SLAs operation. LSP Discovery Option EnabledIf the LSP discovery option for an LSP Health Monitor operation is enabled, SNMP trap notifications can be generated when one of the following events occurs:
Possible reasons for which LSP discovery can fail for a particular BGP next hop neighbor are as follows:
The table below describes the conditions for which the operational status of an LSP discovery group can change. Whenever an individual IP SLAs LSP ping operation of an LSP discovery group is executed, a return code is generated. Depending on the value of the return code and the current status of the LSP discovery group, the group status can change.
The return code for an individual IP SLAs LSP ping operation can be one of the following:
The status of an LSP discovery group can be one of the following:
Secondary Frequency OptionWith the introduction of the LSP Health Monitor feature, a new threshold monitoring parameter has been added that allows you to specify a secondary frequency. If the secondary frequency option is configured and a failure (such as a connection loss or timeout) is detected for a particular path, the frequency at which the path is remeasured will increase to the secondary frequency value (testing at a faster rate). When the configured reaction condition is met (such as N consecutive connection losses or N consecutive timeouts), an SNMP trap and syslog message can be sent and the measurement frequency will return to its original frequency value. How to Configure IP SLAs for MPLS Pseudo Wire via VCCMManually Configuring and Scheduling an IP SLAs VCCV OperationSUMMARY STEPS
DETAILED STEPS
Troubleshooting TipsUse the debug ip sla trace and debug ip sla error commands to help troubleshoot issues with an individual IP SLAs PWE3 service via VCCV operation. What to Do NextTo display the results of an individual IP SLAs operation use the show ip sla statistics and show ip sla statistics aggregated commands. Checking the output for fields that correspond to criteria in your service level agreement will help you determine whether the service metrics are acceptable. Configuration Examples for IP SLAs for MPLS Pseudo Wire via VCCMExample Manually Configuring an IP SLAs VCCV OperationThe following example shows how to manually configure an IP SLAs VCCV operation in conjunction with the proactive threshold monitoring and multioperation scheduling capabilities of the LSP Health Monitor. In this example, a VC with the identifier 123 has already been established between the PE device and its peer at IP address 192.168.1.103. IP SLAs VCCV operation 777 is configured with operation parameters and reaction conditions, and it is scheduled to begin immediately and run indefinitely. ip sla 777 mpls lsp ping pseudowire 192.168.1.103 123 exp 5 frequency 120 secondary-frequency timeout 30 tag testgroup threshold 6000 timeout 7000 exit ! ip sla reaction-configuration 777 react rtt threshold-value 6000 3000 threshold-type immediate 3 action-type traponly ip sla reaction-configuration 777 react connectionLoss threshold-type immediate action-type traponly ip sla reaction-configuration 777 react timeout threshold-type consecutive 3 action-type traponly ip sla logging traps ! ip sla schedule 777 life forever start-time now exit RTT ThresholdsThe threshold command configures 6000 milliseconds as the amount of time for a rising threshold to be declared on the monitored pseudo-wire. The first ip sla reaction-configuration command specifies that an SNMP logging trap is to be sent immediately if the round-trip time violates the upper threshold of 6000 milliseconds or the lower threshold of 3000 milliseconds. Connection LossThe second ip sla reaction-configuration command specifies that an SNMP logging trap is to be sent immediately if a connection loss occurs for the monitored pseudo-wire. Response TimeoutThe timeout command configures 7000 seconds as the amount of time that VCCV operation 777 waits for a response from its request packet before a timeout is declared. The secondary-frequency command specifies that, if a timeout occurs, the measurement frequency of the operation repeats is to be increased from 120 seconds (the initial measurement frequency specified using the frequency command) to a faster rate of 30 seconds. The third ip sla reaction-configuration command specifies that an SNMP logging trap is to be sent if three consecutive timeouts occur. Additional ReferencesRelated Documents
MIBsTechnical Assistance
Feature Information for IP SLAs for MPLS PWE3 via VCCMThe following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. © 2012 Cisco Systems, Inc. All rights reserved.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||