The Remote Access to Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) solution integrates dial, Digital Subscriber Line (DSL), and cable remote access technologies into an MPLS VPN. For more information about the Remote Access to MPLS VPN integration solution, refer to the Cisco Remote Access to MPLS VPN Integration 2.0 Overview and Provisioning Guide:
These release notes apply to the first office availability (FOA) 2 release of the solution.
Internal testing is in progress for additional features and platforms upcoming in FOA3, which is summarized below. New architectures, features, and platforms in this release are described in "New In This Release".
Support for large-scale dial-out (LSDO) remote access to MPLS VPN integration.
New feature:
Per VRF AAA. Per VRF AAA allows the service provider to partition AAA services based on VRF, eliminating the need for proxy AAA. The VHG/PE is able to communicate directly with an AAA RADIUS server associated with the user's VPN.
Method List / Server Group Scalability. This feature supports large numbers of methods lists and supports 100 or more server groups. The feature also lets you delete or add AAA servers on the fly.
L2TP Dial-out Load Balancing & Redundancy. This feature allows load balancing and failover with L2TP dialout to work similarly to the way it works in dialin. If a LAC is down, it would be possible for a LNS to failover to another LAC. Also the LNS would be able to load-balance between multiple LACs.
Radius Attribute Screening With Remote Profiles. This feature allows remote (configuration on radius server) profiles to be included in the VRF routing table as per VRF.
The hardware and software components required depend on the remote access architecture you are implementing. This section lists the various architectures supported in this release, followed by the hardware and software requirements for each one.
For more detailed requirements for your particular implementation, please contact your account system engineer.
This release of Remote Access to MPLS VPN Solution supports the following architectures:
Dial-in to MPLS VPN integration with multilink PPP
This section describes hardware and software requirements for L2TP dial-in (including dial backup), and dial-out architectures. All L2TP dial architectures require both a virtual home gateway/provider edge router (VHG/PE) and a network access server (NAS).
Virtual Home Gateway/Provider Edge Platforms
The platform requirements for the VHG/PE are listed in Table 1.
This section describes hardware and software requirements for direct ISDN PE dial-in and dial-out architectures, where a single router serves as network access server and provider edge router (NAS/PE).
Network Access Server/Provider Edge Platforms
The platform requirements for the NAS/PE are listed in Table 3.
1Cable products that have been included and tested in this document may be in end of life (EOL) status. The features and functionality which have been tested on the uBR7246 Universal Broadband Router and uBR 924 Cable Access Router may be available in current product models and software revisions. Please refer to the EOL page for further information http://www.cisco.com/univercd/cc/td/doc/pcat/elhw__g1.htm#xtocid0 and/or the Cisco Product page http://www.cisco.com/public/products_prod.shtml .
To determine the version of Cisco IOS software currently running, log in to the router and enter the show version EXEC command. The following sample output from the show version command indicates the version number on the second output line:
Router> show version
Cisco Internetwork Operating System Software
IOS (tm) 12.1 Software c5300-i-mz, Version 12.2(5), RELEASE SOFTWARE
This FOA2 release adds support for new remote access architectures, new platforms, and new features. See "About the FOA Release Schedule" for features that will be included in subsequent FOAs.
Table 6 summarizes the new features provided in this release. For a description of the features, refer to the Cisco Remote Access to MPLS VPN Integration 2.0 Overview and Provisioning Guide:
Note Please note that later rebuilds (12.2(11)T1, 12.2(11)T2, and so forth) are functionally equivalent and
may resolve critical caveats listed below. We recommend that you use the latest 12.2(11)T rebuild
available.
The next release of Remote Access to MPLS VPN Integration (FOA3) resolves the caveats listed in this section.
CSCdu79302
(duplicate of CSCdw67557; resolved in 12.2(11.3)T) A high rate of packet loss is observed when VHGW/PE passes traffic with L2TP Dialout/MPLS-VPN using dialer profiles. Almost half of traffic is lost giving pings a result of 50% success.
Workaround: To make all the packets to go through to the client, disable CEF on the dialer interface that is used by the MLP bundle; that is, on the dialer interface, issue the command no ip route-cache cef.
CSCdx68868
Direct dialout MPLS-VPN with dialer profiles does not work. A ping from the NAS/PE to the peer will trigger a call successfully but subsequent IP connectivity is unidirectional: IP packets are sent to the peer OK, but IP packets received are not correctly handled.
Workaround: Use multilink PPP.
CSCdx82181
Packets are not cef switched in a Remote Access MPLS/VPN dial-out scenario using dialer profiles on a Cisco 3640 platform.
Small ping packets on the VHG/PE are dropped with ISL turned on. pings from a remote access to MPLS VPN dial in PPP session with a packet size \> 40 bytes get a response but small ping packets between 36 and 40 bytes do not get a response packet back from the remote PE/CE IP destination. The reply packet is dropped when the tagged packet is received on the VHG/PE and should be sent out to a LAC via L2TP. To reproduce the problem, the interface on the VHG/PE used to connect to the LAC must be configured to use a second layer encapsulation like ISL when sending out the L2TP packets. There is no problem when ISL encapsulation is not used.
With debug mpls packet on on the VHG/PE, small ping packets have no problem. There is also no problem with MLPPP on the PPP sessions.
Workaround:
1) Enable debug mpls packet on the VHG/PE.
2) Enable multilink PPP on the PPP session.
3) Configure no ISL encapsulation in the L2TP packet being sent from the VHG/PE to LAC.
CSCdw91279
(Resolved in 12.2(8)T1) In 12.2(5.7)T and later, a Cisco router acting as an L2TP access concentrator or L2TP network access server may fail to process valid L2TP ZLB (Zero Length Block) Acknowledgement packets. This can cause sessions and tunnels to drop. This caveat applies to the VPN, not to remote access integration.
CSCdx20920
Crash when testing L2TP dial-out using dialer profiles under medium load. Calls are set up at a rate higher than 2 calls per second. Executing commands such as show run may crash the router at an even lower call rate.
CSCdw52946
The IP background task removes a newly IPCP installed route: When a user attempts to dial back in to a remote access MPLS VPN service for L2TP dial-in to either a VHG/PE router or a direct dial-in NAS/PE router, call setup is successful but data cannot be transferred because the virtual access interface is removed from the routing table after the call is set up.
There is no workaround.
CSCdw60489
(duplicate of CSCdw10495; resolved in 12.2(8.5)T) Dial MMP: Spurious memory access in ipfib_pas_fs_tag with SGBP.
CSCdw63402
(Resolved in 12.2(8.5)T) When MLP over ATM (MLPoATM) is configured on an MPLS VPN, packets that are not encapsulated by MLP are dropped on the input side. This condition occurs if the virtual access interface is placed into the VPN routing/forwarding instance (VRF) using RADIUS attributes.
Workaround: Select the VRF by configuring the virtual template using the ip vrf forwarding interface configuration command.
CSCdw89965
(Resolved in 12.2(9.1)T) An MPLS router that has several VPN or IP version 4 (IPv4) border gateway protocol (BGP) routes may experience a memory leak if the route to the BGP neighbor flaps. The memory leak is about 100 bytes per BGP route for each route flap. High memory consumption in the output of the Tag Forwarding Information Base (TFIB) of the show memory summary tfib EXEC command is an indication of the presence of a memory leak.
CSCdw89981
(Resolved in 12.2(9.1)T) Memory leak in process "PPP IPCP". Occurs when using AAA per user attributes.
CSCdw91157
(Duplicate of CSCdw10495; resolved in 12.2(8.5)T) While bringing up L2TP sessions on Cisco 7500 router running 12.2(8)T version, the LAC may fail establish connection with LNS.
CSCdx05656
(Resolved in 12.2(9.3)T) When the "peer default ip address dhcp-pool" command is cloned on a virtual-access interface via aaa per user settings (command defined in the cisco av-pair RADIUS record), the parsing of this command on the virtual-access interface generates the following output:
%Using local DHCP VRF pools for address-pooling.
CSCdx12524
When using ip unnumbered interfaces with VRF's, DHCP_Requests forwarded to a different VRF or to the global table, the DHCP_Reply does not have an outbound interface to the requesting client. The symptoms can be seen during a DHCP detail and dhcp server packet debug where the reply will be dropped with a message "no outbound_if".
CSCin09960
In L2F/L2TP dial-in cases will fail due to PPP not invoking AAA.
A Cisco 7500 series router may produce spurious access messages in rsp_ipfib_feature_switch and rsp_ipfib_flow_switch. These messages occur only in centralized RSP-based CEF. They may cause a higher CPU usage than expected.
CSCdt82370
(Duplicate of CSCdt78572) In MMP or MLP L2TP dial-in MPLS-VPN, one cannot ping to the loopback interface in the VRF on the VHG/PE router because reply echo packets are not routable. No workaround.
CSCdu36397
(Duplicate of CSCdp86381) Dial: Memory leak in MLP.
CSCdv05421
When no ip route-cache cef is configured on the virtual-template for the LNS and several tens of thousand packets per second are sent downstream (toward the LAC), packets are dropped at the LAC and the "show controller" command shows an increase in the rx_no_buffer counter.
Workaround: configure ip route-cache cef (the default).
CSCdv43029
(Duplicate of CSCdt97779 ) Traceback messages are observed on an L2TP Network Server (LNS) and on an L2TP access concentrator (LAC) after 2000 sessions and 2000 tunnels are brought up. This is a minor problem, because no session or tunnels drops were observed as a result of these traceback messages.
CSCdv46738
(Duplicate of CSCdw00924 ) When MLP over ATM (MLPoATM) is configured on a Cisco 7200 Route Processor Module (RPM) along with Fancy Queuing and link fragmentation and interleaving (LFI), the output may pause indefinitely and performance may degrade.
Workaround: To prevent the packets from getting queued and stuck at the weighted fair queuing (WFQ) queue, avoid congesting the link.
CSCdv32799
(Duplicate of CSCdt83679) DSL RBE: Unable to pass traffic with RBE with a 28 bit mask.
CSCdv57640
(Resolved in 12.2(9)T) When a virtual-template interface is configured for IP virtual routing and forwarding (VRF) in L2TP dial-in, only about 50 percent of the data packets pass across the tunnel.
Workaround: Disable the ip route-cache cef as well as "ip route-cache" interface configuration commands on the virtual template interface to allow all packets to go through the process-switching. This also fixes the problem with Vaccess counters, observed after CSCdw01642. The problem was that the counters on the Vaccess interfaces used for L2TP sessions (on the LAC and LNS) showed wrong values. That happened only when IP CEF was enabled on high end routers.
CSCdu42456
(Duplicate of CSCdt59038) When MLPoATM is configured, the VC may experience throughput problems and very low link utilization.
CSCdu62885
(Duplicate of CSCdu62885) When RSP is used with MLP, an access alignment error occurs causing a performance problem.
CSCdw49172
(Duplicate of CSCdw45057) In L2TP dial-in, IPCP is rejected because of a AAA problem. Authentication does not start and IPCP is rejected from the VHG/PE. The same test was done without aaa new-model and passed. Direct dial-in works.
CSCdw45491
When RADIUS user profiles contain an "ip:route" VSA which itself contains VRF information, the route is parsed incorrectly. This leads to an error when the route is applied, and causes the call to go down.
CSCdw23475
Subnet allocation option is sent by the DHCP client when it is requesting a subnet from the DHCP Server (ODAP). This option is being sent properly by the client when in SELECTING, REQUESTING or RENEWING states, but not sent when the client is in REBINDING state. This can be checked by enabling "debug dhcp detail" in the client.
CSCdv64583
Spurious memory access might occur on SGBP offload server on.
CSCdv70150
In L2TP dial-out, data packets are transmitted with incorrect encapsulation. This behavior occurs if MLP is not configured on a VHG/PE router that supports MPLS VPN.
CSCdw45622
In L2TP dial-out, returned data may be corrupted.
CSCdv41786
Crash in rsp_optimum_tagswitch accessing null taginfo: A 7500 router running non distributed MPLS may reload when per packet loadsharing is configured. The reload is likely to happen in MPLS VPN environments. This is suspected to be a duplicate of CSCdt04761.
CSCdt04761
MPLS VPN: router crashes when the IGP/LDP label is unavailable.
CSCdv37118
A Cisco router that is running Cisco IOS Release 12.2(3) and that is configured with MPLS, MLP, CEF may record spurious memory accesses and log the following messages:
Router# show log
%ALIGN-3-SPURIOUS: Spurious memory access made at 0x60D8382C reading 0x0
The effect on the router is poor performance and high CPU utilization, even when there is little traffic.
CSCdv36038
ppp_fixup required() does not support multiple fixups for interface: In Cisco IOS Release 12.2 T, Cisco Express Forwarding (CEF) may not function properly with PPP over L2TP in dial-out environments.
(Duplicate of CSCdt30297; resolved in 12.2(6.7)T) per user static route is not being added to the VRF routing table. Debugging a working setup on the VHG/PE with 12.2(2.5)T shows that the av pair is accepted, whereas in the same setup with 12.2(4)T on the VHG/PE it is not. With 12.2(4)T, there is no debugging info that shows that the route is implemented into the routing table (debug ip routing vrf V1.1.com):
In 12.2(2.5)T:
Nov 23 12:58:31.730: RT(V1.1.com): add 172.21.104.64/29 via 42.1.1.10, static metric [1/0]
In 12.2(4)T this debugging is not present, nor are there any errors seen. The configuration is the same as on 12.2(2.5)T, so no errors were expected.
CSCdw49355
In dial-out, the MLP header is not added with the MPLS packet.
CSCdv68767
The CEF "receive" entry may not be created in the VRF instance for an imported secondary IP address, causing difficulties in pinging this secondary IP address in the VRF instance. There is no workaround.
CSCdv38127
A Cisco router that is using MLP, VPDN MPLS and has keepalives enabled may reload when the router is attempting to bring up the second link.
(Duplicate of CSCdv54349; resolved in 12.2(5.7)T) When using the configuration command aaa authentication ppp default local group radius, if a user name does not exist locally on the router, the system does not fail over to the RADIUS AAA server to look up the user name.
Workaround: Use the configuration command aaa authentication ppp default group radius.
CSCdu62885
(Duplicate of CSCdu62885; resolved in 12.2(5.4)T) When RSP is used with MLPPP, an access alignment error occurs causing a performance problem.
CSCdv00143
Border Gateway Protocol (BGP) virtual private network version 4 (VPNv4) address family routes are not being aggregated even though route aggregation is configured. The more specific routes that are supposed to be aggregated are advertised and the less specific aggregate route is not being generated or advertised. There is no workaround.
CSCdu63368
When a local pool is used to assign IP addresses to a PPP user, pings cannot be sent between a PPP user and a Virtual Home Gateway (VHG) or provider edge (PE) router after the PPP user receives an IP address. There is no workaround.
CSCdv46476
In Cisco IOS Release 12.2(5.2)PI and Release 12.2(5.4)T, the access request reports only attribute 31 and contains both the Calling Line ID (CLID) and the dialed number identification service (DNIS). The access request is altered against what is specified in the RFC, which specifies that attributes 30 and 31 are used for reporting information on the DNIS and the CLID. This condition occurs only on an L2TP network server (LNS) when PPP user sessions that are forwarded over an L2TP tunnel are authenticated.
When a DHCP proxy client mechanism is used to assign IP address to the remote end of a PPP over ATM connection, that PPPoA connection is not brought down upon expiration of the DHCP lease.
This caveat affects only PPPoA deployment scenarios where PPP is terminated on the access concentrator. It does not affect PPP sessions forwarded to a tunnel, such as an L2TP tunnel.
Workaround: Use a local IP address pool configured on the access concentrator to give the IP address to the remote end of PPPoA connection.
CSCdu19512
The idle timer is not reset in a direct dial out MPLS-VPN setup using dialer profiles. Disabling CEF on the dialer profile will enable interesting traffic to reset the idle timer.
Packets may be dropped when a Cisco Network Services Engine (NSE-1) is used with Parallel eXpress Forwarding (PXF) in an MPLS tag switching environment. This problem affects only PXF in a MPLS switching environment on a Cisco NSE-1.
Workaround: Disable PXF on NSE-1 or use another Network Services Engine.
In L2TP the combination of CEF switching, MLP, and VRF (VPN Routing/Forwarding Instance) does not work: CEF switched packets are dropped. All routers that support CEF and all releases have this problem.
Workaround: Disable either CEF or MLP.
CSCdv69266
CEF is stuck in Glean Adjacency when not using 32 bit host rate on the Cisco 6400 router running 12.2(03.06)B03.
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.
Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, U.S.A.) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
You can submit comments electronically on Cisco.com. In the Cisco Documentation home page, click the Fax or Email option in the "Leave Feedback" section at the bottom of the page.
You can e-mail your comments to bug-doc@cisco.com.
You can submit your comments by mail by using the response card behind the front cover of your document or by writing to the following address:
Cisco Systems Attn: Document Resource Connection 170 West Tasman Drive San Jose, CA 95134-9883
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain online documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.
Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you with these tasks:
Streamline business processes and improve productivity
Resolve technical issues with online support
Download and test software packages
Order Cisco learning materials and merchandise
Register for online skill assessment, training, and certification programs
If you want to obtain customized information and service, you can self-register on Cisco.com. To access Cisco.com, go to this URL:
The Cisco Technical Assistance Center (TAC) is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two levels of support are available: the Cisco TAC Web Site and the Cisco TAC Escalation Center.
Cisco TAC inquiries are categorized according to the urgency of the issue:
Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration.
Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.
Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.
Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.
The Cisco TAC resource that you choose is based on the priority of the problem and the conditions of service contracts, when applicable.
You can use the Cisco TAC Web Site to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to this URL:
All customers, partners, and resellers who have a valid Cisco service contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to this URL to register:
If you are a Cisco.com registered user, and you cannot resolve your technical issues by using the Cisco TAC Web Site, you can open a case online by using the TAC Case Open tool at this URL:
The Cisco TAC Escalation Center addresses priority level 1 or priority level 2 issues. These classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer automatically opens a case.
To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to this URL:
Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled: for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). When you call the center, please have available your service agreement number and your product serial number.
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
CCIP, the Cisco Arrow logo, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, Networking Academy, ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That's Possible, The Fastest Way to Increase Your Internet Quotient, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site 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. (0208R)
