Feedback
|
Table Of Contents
MPLS VPN—BGP Local Convergence
Prerequisites for MPLS VPN—BGP Local Convergence
Restrictions for MPLS VPN—BGP Local Convergence
Information About MPLS VPN—BGP Local Convergence
How Link Failures Are Handled with BGP
How Links Are Handled with the MPLS VPN—BGP Local Convergence Feature
How Link Failures Are Detected
How to Enable MPLS VPN—BGP Local Convergence
Configuring MPLS VPN—BGP Local Convergence with IPv4
Configuring MPLS VPN—BGP Local Convergence with IPv6
Configuration Examples for MPLS VPN—BGP Local Convergence
Configuration Examples for MPLS VPN—BGP Local Convergence
Configuration Examples for MPLS VPN—BGP Local Convergence for 6VPE/6PE
Feature Information for MPLS VPN—BGP Local Convergence
MPLS VPN—BGP Local Convergence
First Published: December 31, 2007Last Updated: July 23, 2010This document provides information about reducing the downtime of a provider edge (PE), to customer edge (CE) link failure. It describes how to reroute PE-egress traffic onto a backup path to the CE, before BGP has reconverged. The MPLS VPN—BGP Local Convergence feature is also referred to as "local protection."
This document explains how to use PE-CE local convergence. For information on using BGP PIC-Edge for BGP local convergence support, see BGP PIC Edge for IP and MPLS-VPN.
Note
The MPLS VPN—BGP Local Convergence feature affects only traffic exiting the Virtual Private Network. Therefore, it cannot fully protect traffic end-to-end by itself.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see 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 for MPLS VPN—BGP Local Convergence" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for MPLS VPN—BGP Local Convergence
•
Restrictions for MPLS VPN—BGP Local Convergence
•
Information About MPLS VPN—BGP Local Convergence
•
How to Enable MPLS VPN—BGP Local Convergence
•
Configuration Examples for MPLS VPN—BGP Local Convergence
•
Feature Information for MPLS VPN—BGP Local Convergence
Prerequisites for MPLS VPN—BGP Local Convergence
•
Before MPLS VPN —BGP Local Convergence link protection can be enabled, the customer site must be connected to the provider site by more than one path.
•
Both the main forwarding path and the redundant backup path must have been installed within Border Gateway Protocol (BGP), and BGP must support lossless switchover between operational paths.
•
Any of the supported routing protocols can be used between the PE and CE as long as the path is redistributed into BGP. The supported protocols for IPv4 are External BGP (eBGP), Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), and static routing.The supported protocols for IPv6 are External BGP (eBGP) and static routing.
•
All PE routers that are serving as backup to the link must have assigned a unique Route Distinguisher to each VRF table involved with the link to ensure that the route reflectors advertise all available paths.
•
Although not required, it is recommended that the backup PE (shown as "PE2" in Figure 2) runs the same Cisco IOS release that is running on the PE ("PE1") whose link with the CE will be protected; that is, Cisco IOS Release 12.2(33) SRC, 12.2(33)SB, Cisco IOS 15.0(1)M, Cisco IOS 15.0(1)S, or a more recent version of those products.
Restrictions for MPLS VPN—BGP Local Convergence
•
This feature affects only traffic exiting the VPN. Therefore, it cannot fully protect traffic end-to-end by itself.
•
This link protection cannot be initiated during a High Availability (HA) stateful switchover (SSO). But links already configured with this protection before the switchover begins will remain protected after the switchover.
•
If you perform an in-service software downgrade from an image that does include this link protection to an image that does not support this feature, active protection will be halted when BGP routes are refreshed.
•
Any next-hop core tunneling technology that is supported by BGP is also supported for protection, including Multiprotocol Label Switching (MPLS), IP/Layer 2Tunneling Protocol version 3 (L2TPv3), and IP/Generic Routing Encapsulation (GRE). Enabling a Carrier Supporting Carrier (CsC) protocol between the PE and CE is also supported. Inter-autonomous system option A (back-to-back Virtual Routing and Forwarding (VRF)) is supported because it is essentially the same as performing the PE-CE link protection in both autonomous systems. However, inter-autonomous system options B and C protection are not supported.
•
MPLS VPN—BGP local convergence for IPv4 supports the External BGP (eBGP), Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), and static routing protocols only.
•
MPLS VPN—BGP local convergence for IPv6 supports the eBGP and static routing protocols only.
Information About MPLS VPN—BGP Local Convergence
To configure the MPLS VPN—BGP Local Convergence feature, you should understand the following concepts:
•
How Link Failures Are Handled with BGP
•
How Links Are Handled with the MPLS VPN—BGP Local Convergence Feature
•
How Link Failures Are Detected
How Link Failures Are Handled with BGP
Within a Layer 3 VPN network, the failure of a PE-CE link can cause a loss of connectivity (LoC) to a customer site, which is detrimental to time-sensitive applications. Several factors contribute to the duration of such an outage:
•
The time to detect the failure
•
The programming of the forwarding
•
The convergence of BGP (In large networks, the restored traffic arrival time at its destination varies according to the prefix.)
When BGP detects a PE-CE link failure, it removes all of the BGP paths through the failing link. BGP runs the best-path algorithm on the affected prefixes and selects alternate paths for each prefix. These new paths (which typically include a remote PE) are installed into forwarding. The local labels are removed and BGP withdrawals are sent to all BGP neighbors. As each BGP neighbor receives the withdrawal messages (typically indirectly using route reflectors), the best-path algorithm is called and the prefixes are switched to an alternate path. Only then is connectivity restored.
How Links Are Handled with the MPLS VPN—BGP Local Convergence Feature
The MPLS VPN—BGP Local Convergence feature requires that the prefixes to be protected on a PE-CE link have at least one backup path that does not include that link. (See Figure 1.) The customer site must have backup paths to the provider site.
Figure 1 Network Configured with Primary and Backup Paths
The MPLS VPN—BGP Local Convergence feature reduces LoC time by sending the broken link's traffic over a backup path (as shown in Figure 2) instead of waiting for total network convergence. The local label is maintained for 5 minutes while prefixes switch from the failing local path to the backup path. Because the label is not freed as had been the usual practice, forwarding continues to take place.
The best-path algorithm selects the backup path. Thus, the local label has been applied in place of the failed BGP best-path label (which is sometimes called "label swapping"). Traffic is restored locally while the network propagation of the BGP withdrawal messages takes place. Eventually, the egress PE router converges and bypasses the local repair.
Figure 2 Network Using the Backup Path After a PE-CE Link Failure on the Primary Path
Note
After the 5-minute label preservation, the local labels are freed. Any BGP prefix that is remote and is not part of a Carrier Supporting Carrier network does not have a local label and is removed. The delay in local label deletion does not modify normal BGP addition and deletion of BGP paths. Rather, BGP reprograms the new backup best-path into forwarding as usual.
How Link Failures Are Detected
Local protection relies on BGP being notified of the interface failure. Detection can occur using either the interface drivers or the routing tables. If an interface or route goes down, the corresponding path in the routing table is removed and BGP will be notified using the routing application programming interfaces (APIs).
However, when the routing table cannot detect the failure (as when a Layer 2 switch goes down), BGP determines that a neighbor is down through use of its hold-down timer. However, that determination can be extremely slow because of the 3-minute default for BGP session timeout.
You can reduce the detection delay by either reducing the BGP session timeout interval (as described in the Configuring Internal BGP Features document) or by enabling the Bidirectional Forwarding Detection protocol (BFD) within eBGP between the PE and CE. For complete instructions to enable BFD, see the Bidirectional Forwarding Detection document.
How to Enable MPLS VPN—BGP Local Convergence
This section contains the following tasks:
•
Configuring MPLS VPN—BGP Local Convergence with IPv4 (Required)
•
Configuring MPLS VPN—BGP Local Convergence with IPv6 (Required)
Configuring MPLS VPN—BGP Local Convergence with IPv4
Perform the following steps to configure MPLS VPN to BGP local convergence for IPv4 MPLS VPNs.
Note
To configure a Virtual Private Network (VPN) routing and forwarding (VRF) instance for IPv4 and IPv6 VPNs or to upgrade your existing single-protocol IPv4-only VRF to a multiprotocol VRF configuration, see MPLS VPN—VRF CLI for IPv4 and IPv6 VPNs.
Prerequisite
Ensure that the CE is already connected to the PE by a minimum of two paths.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
ip vrf vrf-name
4.
rd route-distinguisher
5.
protection local-prefixes
6.
do show ip vrf detail
DETAILED STEPS
Configuring MPLS VPN—BGP Local Convergence with IPv6
Perform the following steps to configure MPLS VPN to BGP local convergence for IPv6 MPLS VPNs.
Prerequisite
Ensure that the CE is already connected to the PE by a minimum of two paths.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
vrf definition vrf-name
4.
rd route-distinguisher
5.
address-family [ipv4 | ipv6]
6.
protection local-prefixes
7.
do show ip vrf detail
DETAILED STEPS
Examples
To verify that local link protection has been enabled, enter the VRF detail command show ip vrf detail. If the protection is enabled, the status message "Local prefix protection enabled" will be shown in the display:
Router# show ip vrf detailVRF vpn1 (VRF Id = 1); default RD 100:1; default VPNID <not set>Interfaces:AT1/0/1.1VRF Table ID = 1Export VPN route-target communitiesRT:100:1Import VPN route-target communitiesRT:100:1 RT:100:2No import route-mapNo export route-mapVRF label distribution protocol: not configuredVRF label allocation mode: per-prefixLocal prefix protection enabledTroubleshooting Tips
•
Ensure that a minimum of two paths are present for the protected prefix w.x.y.z in BGP in steady state condition on the PE. The path using the protected PE should be the BGP best-path before failover occurs. To display the configuration, enter the show ip bgp vpnv4 vrf vpn w.x.y.z command.
•
Ensure that local protection has been enabled in the protected PE by entering the show ip vrf detail command, as shown in the "Examples" section.
•
When route reflectors exist in the topology, ensure that each VRF has a unique route distinguisher.
Configuration Examples for MPLS VPN—BGP Local Convergence
This section contains the following examples:
•
Configuration Examples for MPLS VPN—BGP Local Convergence
•
Configuration Examples for MPLS VPN—BGP Local Convergence for 6VPE/6PE
Configuration Examples for MPLS VPN—BGP Local Convergence
The following examples show how MPLS VPN—BGP local convergence can prevent traffic loss after a link failure. You can display a detailed view of local link protection before, during, and after BGP convergence by using the show bgp vpnv4 and show mpls forwarding-table vrf commands as shown in the following three-stage example.
Note
The show bgp vpnv4 unicast command is equivalent to the show ip bgp vpnv4 command.
Example 1: Before the Link Failure
Both a primary path and a backup path have been configured:
Router# show bgp vpnv4 unicast all 172.16.0.1BGP routing table entry for 100:1:172.16.0.1/32, version 2Paths: (2 available, best #2, table v1)Flag: 0x820Advertised to update-groups:1100, imported path from 100:2:172.16.0.1/32172.16.0.6 (metric 21) from 172.16.0.7 (172.16.0.7)Origin incomplete, metric 0, localpref 100, valid, internalExtended Community: RT:100:0Originator: 172.16.0.6, Cluster list: 172.16.0.7mpls labels in/out 16/17100172.16.1.1 from 172.16.1.1 (172.16.0.1)Origin incomplete, metric 0, localpref 100, valid, external, bestExtended Community: RT:100:0mpls labels in/out 16/nolabelBGP routing table entry for 100:2:172.16.0.1/32, version 9Paths: (1 available, best #1, no table)Flag: 0x820Not advertised to any peer100172.16.0.6 (metric 21) from 172.16.0.7 (172.16.0.7)Origin incomplete, metric 0, localpref 100, valid, internal, bestExtended Community: RT:100:0Originator: 172.16.0.6, Cluster list: 172.16.0.7mpls labels in/out nolabel/17Label information for both paths can be displayed:
Router1# show bgp vpnv4 unicast all labelsNetwork Next Hop In label/Out labelRoute Distinguisher: 100:1 (v1)172.16.0.1/32 172.16.0.6 16/17172.16.1.1 16/nolabel172.16.0.5/32 172.16.0.4 nolabel/23172.16.0.22/32 0.0.0.0 17/nolabel(v1)172.16.0.44/32 172.16.0.4 nolabel/24172.16.0.66/32 172.16.0.6 nolabel/21172.16.1.0/24 172.16.1.1 18/nolabel0.0.0.0 18/nolabel(v1)172.16.5.0/24 172.16.0.4 nolabel/25172.16.8.0/24 172.16.0.6 19/23172.16.1.1 19/nolabelRoute Distinguisher: 100:2172.16.0.1/32 172.16.0.6 nolabel/17172.16.0.66/32 172.16.0.6 nolabel/21172.16.8.0/24 172.16.0.6 nolabel/23The PE1 (see Figure 1) forwarding table contains BGP best-path information:
Router1# show mpls forwarding-table vrf v1 172.16.0.1 detailLocal Outgoing Prefix Bytes Label Outgoing Next HopLabel Label or Tunnel Id Switched interface16 No Label 172.16.0.1/32[V] 570 Et0/0 172.16.1.1MAC/Encaps=14/14, MRU=1504, Label Stack{}AABBCC000B00AABBCC000C000800VPN route: v1No output feature configuredExample 2: After the Link Failure and Before BGP Convergence
After the link failure on only one path, the backup path remains available (see Figure 2):
Router1# show bgp vpnv4 unicast all 172.16.0.1BGP routing table entry for 100:1:172.16.0.1/32, version 19Paths: (1 available, best #1, table v1)Not advertised to any peer100, imported path from 100:2:172.16.0.1/32172.16.0.6 (metric 21) from 172.16.0.7 (172.16.0.7)Origin incomplete, metric 0, localpref 100, valid, internal, bestExtended Community: RT:100:0Originator: 172.16.0.6, Cluster list: 172.16.0.7mpls labels in/out 16/17BGP routing table entry for 100:2:172.16.0.1/32, version 9Paths: (1 available, best #1, no table)Not advertised to any peer100172.16.0.6 (metric 21) from 172.16.0.7 (172.16.0.7)Origin incomplete, metric 0, localpref 100, valid, internal, bestExtended Community: RT:100:0Originator: 172.16.0.6, Cluster list: 172.16.0.7mpls labels in/out nolabel/17The label information for the backup path label can be displayed:
Router1# show bgp vpnv4 unicast all labelsNetwork Next Hop In label/Out labelRoute Distinguisher: 100:1 (v1)172.16.0.1/32 172.16.0.6 16/17172.16.0.5/32 172.16.0.4 nolabel/23172.16.0.22/32 0.0.0.0 17/nolabel(v1)172.16.0.44/32 172.16.0.4 nolabel/24172.16.0.66/32 172.16.0.6 nolabel/21172.16.1.0/24 172.16.0.6 nolabel/22172.16.5.0/24 172.16.0.4 nolabel/25172.16.8.0/24 172.16.0.6 19/23Route Distinguisher: 100:2172.16.0.1/32 172.16.0.6 nolabel/17172.16.0.66/32 172.16.0.6 nolabel/21172.16.1.0/24 172.16.0.6 nolabel/22172.16.8.0/24 172.16.0.6 nolabel/23The PE1 (see Figure 1) forwarding table contains new label and next-hop information to direct traffic onto the backup path:
Router1# show mpls forwarding-table vrf v1 172.16.0.1 detailLocal Outgoing Prefix Bytes Label Outgoing Next HopLabel Label or Tunnel Id Switched interface16 17 172.16.0.1/32[V] 0 Et1/0 172.16.3.2MAC/Encaps=14/22, MRU=1496, Label Stack{21 17}AABBCC000D00AABBCC000C018847 0001500000011000VPN route: v1No output feature configuredExample 3: After Local Label Expiration and BGP Reconvergence
Because the local label preservation window has expired, the replacement local label is now gone from the PE1 forwarding table information:
Router1# show mpls forwarding-table vrf v1 172.16.0.1 detailLocal Outgoing Prefix Bytes Label Outgoing Next HopLabel Label or Tunnel Id Switched interfaceNone 17 172.16.0.1/32[V] 0 Et1/0 172.16.3.2MAC/Encaps=14/22, MRU=1496, Label Stack{21 17}AABBCC000D00AABBCC000C018847 0001500000011000VPN route: v1No output feature configuredThe new BGP information reverts to the configuration shown in Figure 1:
Router1# show bgp vpnv4 unicast all 172.16.0.1BGP routing table entry for 100:1:172.16.0.1/32, version 23Paths: (1 available, best #1, table v1)Not advertised to any peer100, imported path from 100:2:172.16.0.1/32172.16.0.6 (metric 21) from 172.16.0.7 (172.16.0.7)Origin incomplete, metric 0, localpref 100, valid, internal, bestExtended Community: RT:100:0Originator: 172.16.0.6, Cluster list: 172.16.0.7mpls labels in/out nolabel/17BGP routing table entry for 100:2:172.16.0.1/32, version 9Paths: (1 available, best #1, no table)Not advertised to any peer100172.16.0.6 (metric 21) from 172.16.0.7 (172.16.0.7)Origin incomplete, metric 0, localpref 100, valid, internal, bestExtended Community: RT:100:0Originator: 172.16.0.6, Cluster list: 172.16.0.7mpls labels in/out nolabel/17Router1# show bgp vpnv4 unicast all labelsNetwork Next Hop In label/Out labelRoute Distinguisher: 100:1 (v1)172.16.0.1/32 172.16.0.6 nolabel/17172.16.0.5/32 172.16.0.4 nolabel/23172.16.0.22/32 0.0.0.0 17/nolabel(v1)172.16.0.44/32 172.16.0.4 nolabel/24172.16.0.66/32 172.16.0.6 nolabel/21172.16.1.0/24 172.16.0.6 nolabel/22172.16.5.0/24 172.16.0.4 nolabel/25172.16.8.0/24 172.16.0.6 nolabel/23Route Distinguisher: 100:2172.16.0.1/32 172.16.0.6 nolabel/17172.16.0.66/32 172.16.0.6 nolabel/21172.16.1.0/24 172.16.0.6 nolabel/22172.16.8.0/24 172.16.0.6 nolabel/23Configuration Examples for MPLS VPN—BGP Local Convergence for 6VPE/6PE
You can display a detailed view of local link protection before, during, and after BGP local convergence for Cisco IOS VPN IPv6 provider edge routers (6VPE) and Cisco IOS IPv6 provider edge routers (6PE) over MPLS by using the show bgp vpnv6 and show mpls forwarding-table vrf commands as shown in the following three-stage example.
Figure 3 shows an MPLS VPN with BGP local convergence configured. The PE to CE routing protocol is eBGP, and the PE to route reflector (RR) sessions are BGP VPNv6. The protected prefix is the CE1 loopback (2001:0DB8::/128). The primary path is from PE1 to CE1. The secondary path is from PE1, through P and PE3, to CE1.
Figure 3 MPLS VPN BGP Local Convergence
Example 1: Before the Link Failure
Both a primary path and a backup path have been configured for the prefix 2001:0DB8::/128. The inlabel/outlabel settings for the two paths are 28/28 and 28/nolabel.
Router1# show bgp vpnv6 unicast all 2001:0DB8::/128BGP routing table entry for [1:1]2001:0DB8::/128, version 5Paths: (2 available, best #2, table v1)Advertised to update-groups:2100, imported path from [2:2]2001:0DB8::/128::FFFF:10.6.6.6 (metric 21) from 10.7.7.7 (10.7.7.7)Origin incomplete, metric 0, localpref 100, valid, internalExtended Community: RT:1:1Originator: 10.6.6.6, Cluster list: 10.7.7.7mpls labels in/out 28/281002001:0DB8:0:ABCD::1 (FE80::A8BB:CCFF:FE00:B00) from 2001:0DB8:0:ABCD::1 (10.1.1.1)Origin incomplete, metric 0, localpref 100, valid, external, bestExtended Community: RT:1:1mpls labels in/out 28/nolabelBGP routing table entry for [2:2]2001:0DB8::/128, version 11Paths: (1 available, best #1, no table)Not advertised to any peer100::FFFF:10.6.6.6 (metric 21) from 10.7.7.7 (10.7.7.7)Origin incomplete, metric 0, localpref 100, valid, internal, bestExtended Community: RT:1:1Originator: 10.6.6.6, Cluster list: 10.7.7.7mpls labels in/out nolabel/28The PE1 forwarding table contains new label and next-hop information to direct traffic onto the backup path:
Router1# show mpls forwarding-table vrf v1 2001:0DB8::/128 detailLocal Outgoing Prefix Bytes Label Outgoing Next HopLabel Label or Tunnel Id Switched interface28 No Label 2001:0DB8::/128[V] 804 Et0/0 FE80::A8BB:CCFF:FE00:B00MAC/Encaps=14/14, MRU=1504, Label Stack{}AABBCC000B00AABBCC000C0086DDVPN route: v1No output feature configuredExample 2: After the Link Failure
After the link failure, the backup path is still available, the original path is removed from BGP, and the backup path is activated:
Router1#show mpls forwarding-table vrf v1 2001:0DB8::/128 detailLocal Outgoing Prefix Bytes Label Outgoing Next HopLabel Label or Tunnel Id Switched interface28 28 2001:0DB8::/128[V] 0 Et1/0 10.3.0.2MAC/Encaps=14/22, MRU=1496, Label Stack{23 28}AABBCC000D00AABBCC000C018847 000170000001C000VPN route: v1No output feature configuredAfter a configured length of time, the local label expires. The output from the show mpls forwarding-table command also verifies that the local label has expired:
Router1#show mpls forwarding-table vrf v1 2001:0DB8::/128 detailLocal Outgoing Prefix Bytes Label Outgoing Next HopLabel Label or Tunnel Id Switched interfaceNone 28 2001:0DB8::/128[V] 0 Et1/0 10.3.0.2MAC/Encaps=14/22, MRU=1496, Label Stack{23 28}AABBCC000D00AABBCC000C018847 000170000001C000VPN route: v1No output feature configuredExample 3: After the Link Is RestoredWhen the link is restored the original path is added to BGP and the traffic switches back to this path:
Router1# show bgp vpnv6 unicast all 2001:0DB8::/128BGP routing table entry for [1:1]2001:0DB8::/128, version 28Paths: (2 available, best #1, table v1)Advertised to update-groups:21002001:0DB8:0:ABCD::1 (FE80::A8BB:CCFF:FE00:B00) from 2001:0DB8:0:ABCD::1 (10.1.1.1)Origin incomplete, metric 0, localpref 100, valid, external, bestExtended Community: RT:1:1mpls labels in/out 16/nolabel100, imported path from [2:2]2001:0DB8::/128::FFFF:10.6.6.6 (metric 21) from 10.7.7.7 (10.7.7.7)Origin incomplete, metric 0, localpref 100, valid, internalExtended Community: RT:1:1Originator: 10.6.6.6, Cluster list: 10.7.7.7mpls labels in/out 16/28BGP routing table entry for [2:2]2001:0DB8::/128, version 11Paths: (1 available, best #1, no table)Not advertised to any peer100::FFFF:10.6.6.6 (metric 21) from 10.7.7.7 (10.7.7.7)Origin incomplete, metric 0, localpref 100, valid, internal, bestExtended Community: RT:1:1Originator: 10.6.6.6, Cluster list: 10.7.7.7mpls labels in/out nolabel/28Router1#show mpls for vrf v1 2001:0DB8::/128 detailLocal Outgoing Prefix Bytes Label Outgoing Next HopLabel Label or Tunnel Id Switched interface16 No Label 2001:0DB8::/128[V] 0 Et0/0 FE80::A8BB:CCFF:FE00:B00MAC/Encaps=14/14, MRU=1504, Label Stack{}AABBCC000B00AABBCC000C0086DDVPN route: v1No output feature configuredAdditional References
The following sections provide references related to the MPLS VPN—BGP Local Convergence feature.
Related Documents
Standards
Standard TitleNo new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
Technical Assistance
Feature Information for MPLS VPN—BGP Local Convergence
Table 1lists the features in this module and provides links to specific configuration information.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 1 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.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at 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. (1005R)
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.
© 2010 Cisco Systems, Inc. All rights reserved.
Feedback


