|
|
First Office Availability 3 March, 2003
These release notes cover the following topics:
The Remote Access to MPLS VPN solution integrates dial, Digital Subscriber Line (DSL), and cable remote access technologies into a Multiprotocol Label Switching (MPLS) Virtual Private Network (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:
http://www.cisco.com/univercd/cc/td/doc/product/vpn/solution/rampls2/ovprov/index.htm
The documentation set also includes:
Cisco Remote Access to MPLS VPN Solution Troubleshooting Guide 2.0:
http://www.cisco.com/univercd/cc/td/doc/product/vpn/solution/rampls2/trblsht/index.htm
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 the Remote Access to MPLS VPN solution supports the following architectures:
 |
Note DSL Remote Access PPPoX with Service Selection Gateway (SSG) to MPLS was tested with Remote Access to MPLS VPN Release 1.0 only. |
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).
The platform requirements for the VHG/PE are listed in Table 1.
Table 1 Platforms, Cisco IOS Release, and Memory Requirements
| Platform | Cisco IOS Release | Flash Memory Recommended | DRAM Memory Recommended |
|---|---|---|---|
| For dial-in and dial-out | |||
| For dial-in only | |||
The platform requirements for the NAS are listed in Table 2.
Table 2 Platforms, Cisco IOS Release, and Memory Requirements
| 1To ensure proper dial-out bidding with the "L2TP Dialout Load-Balancing" feature, it is recommended that you use Cisco IOS Release 12.2(2)XB or Cisco IOS Release 12.2(11)T or later releases on the LAC. |
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).
The platform requirements for the NAS/PE are listed in Table 3.
Table 3 Platforms, Cisco IOS Release, and Memory Requirements
| Platform | Cisco IOS Release | Flash Memory Recommended | DRAM Memory Recommended |
|---|---|---|---|
Platform requirements for DSL architectures are listed in Table 4.
Table 4 Platforms, IOS Release, and Memory Requirements
| Platform | Cisco IOS Release | Flash Memory Recommended | DRAM Memory Recommended |
|---|---|---|---|
Platform requirements for cable architecture are listed in Table 5.
Table 5 Virtual Home Gateway, Cisco IOS Release, and Memory Requirements
| Platform | Cisco IOS Release | Flash Memory Recommended | DRAM Memory Recommended |
|---|---|---|---|
| 1Cable products that have been included and tested in this document may be in end of life (EOL) status. The features and functionality that 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 h ttp://www.cisco.com/univercd/cc/td/doc/pcat/elhw__g1.htm#xtocid0 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:
No new hardware features in Release FA03.
Table 6 New Features in the Cisco Remote Access to MPLS VPN Solution for FA03
| Feature | Platform | Cisco IOS Release Introduced In |
|---|---|---|
It is recommended that you use Cisco IOS Release 12.2(2)BX or Cisco IOS Release 12.2(11)T or later releases on the LAC to ensure proper dial-out bidding with this feature.
This feature enables an LNS to dial out to multiple L2TP access concentrators (LACs). When the LAC with the highest priority goes down, it is possible for the LNS to failover to another lower priority LAC. The LNS can also load balance the sessions between multiple LACs that have the same priority settings.
In Cisco IOS software prior to Release 12.2(15)T, L2TP large-scale dial-out using the Stacked Group Bidding Protocol (SGBP) for dial-out connection bidding required configuring a primary and secondary LAC. Dial-out used the secondary LAC only when ports were not available on the primary LAC, or when more ports were available on the secondary LAC. However, the LNS could use the ports only on the primary LAC. Because the initiate-to VPDN group configuration command used to specify the IP address for the tunnel did not support multiple statements on an LNS, only the IP address of the primary LAC could be configured. Therefore, the LNS could not contact any other LACs when the primary LAC went down, and failover was not supported for dial-out calls by the LNS.
The L2TP Dial-Out Load Balancing and Redundancy feature introduced in Cisco IOS Release 12.2(15)T enables an LNS to dial out to multiple LACs (multiple initiate-to VPDN group configuration commands, and therefore multiple IP addresses, are supported).
The L2TP Dial-Out Load Balancing and Redundancy feature supports load balancing between multiple LACs that have the same priority settings in the initiate-to VPDN group configuration commands. You can also set redundancy and failover by configuring differing priority values in the initiate-to VPDN group configuration commands. When the LAC with the highest priority goes down, the LNS will failover to another lower priority LAC.
For more information refer to the L2TP Dial-Out Load Balancing and Redundancy document.
The L2TP Large-Scale Dial-Out per-User Attribute via AAA feature makes it possible for IP and other per-user attributes to be applied to an L2TP dial-out session from an LNS. Before this feature was released, IP per-user configurations from authentication, authorization, and accounting (AAA) servers were not supported; the IP configuration would come from the dialer interface defined on the router.
The L2TP Large-Scale Dial-Out per-User Attribute via AAA feature works in a way similar to virtual profiles and L2TP dial-in. The L2TP virtual access interface is first cloned from the virtual template, which means that configurations from the virtual template interface will be applied to the L2TP virtual access interface. After authentication, the AAA per-user configuration is applied to the virtual access interface. Because AAA per-user attributes are applied only after the user has been authenticated, the LNS must be configured to authenticate the dial-out user (configuration authentication is needed for this feature).
With the L2TP Large-Scale Dial-Out per-User Attribute via AAA feature, all software components can now use the configuration present on the virtual access interface rather than what is present on the dialer interface. For example, IP Control Protocol (IPCP) address negotiation uses the local address of the virtual access interface as the router address while negotiating with the peer.
Because per-user attributes are contained within the dialin AAA profile and are not supplied within the LSDO profile, you must enable bidirectional CHAP authentication with this feature.
You must enable bidirectional CHAP authentication to use this feature because per-user attributes are contained within the dialin AAA profile and these per-user attributes are not supplied within the LSDO profile.
For more information about this feature, refer to the L2TP Large-Scale Dial-Out per-User Attribute via AAA document.
The Per-VRF AAA feature allows a service provider to partition AAA services based on VRF which eliminates the need for proxy AAA. The virtual home gateway (VHG) or provider edge (PE) router is able to communicate directly with an AAA RADIUS server associated with the user's VPN. The Per-VRF AAA feature includes support for both static configuration of per-VRF data (local authorization) and downloading of the per-VRF data from a AAA RADIUS server (remote authorization).
As of Release FA03, attribute filtering for remote authorization is also supported on a per-domain basis. Attribute filtering for remote authorization is supported with a AAA attribute as part of the template downloaded from the AAA RADIUS server. In addition, framed routes downloaded with an AAA template are VRF-aware.
The VPDN Multihop feature allows packets to pass through multiple tunnels using both L2F and L2TP protocols in a VPDN environment with VRF awareness.
The VPDN Multihop with VRF Support feature enables an L2TP tunnel to start outside the MPLS VPN, and to terminate (or multihop) somewhere within the MPLS VPN. Before the introduction of this feature, because VPDN only uses global IP addresses, the IP addresses used by the VPDN tunnel cannot overlap across VPNs. With the VPDN Multihop with VRF Support feature support is possible for L2TP tunnels that terminate with the VRF and have overlapping IP addresses.
This release adds support for the following new platforms:
Table 7 summarizes the new features provided in this release.
Table 7 New Features in the Cisco Remote Access to MPLS VPN Solution for FA02
| Feature | Used With These Architectures | Platform | Cisco IOS Release Introduced In |
|---|---|---|---|
Dial: Dial-in L2TP and Direct ISDN, Dial-out L2TP and Direct ISDN |
|||
| 1DSL Remote Access PPPoX with Service Selection Gateway (SSG) to MPLS was tested with Remote Access to MPLS VPN Release 1.0 only. |
The Framed-Route VRF Aware feature introduces Virtual Route Forwarding support for RADIUS Attribute 22 (Framed-Route), Attribute 8 (Framed-IP-Address), and Attribute 9 (Framed-IP-Netmask). With this feature, static IP routes can be applied to a particular VRF table rather than to the global routing table.
In on-demand address pools (ODAP), a central service provider (SP) RADIUS server manages a block of addresses for each customer. Each pool is divided into subnets of various sizes, and the server assigns subnets to the VHG/PE or NAS/PE on request.
The VHG/PE or NAS/PE acts as a Dynamic Host Configuration Protocol (DHCP) server. On the VHG/PE or NAS/PE, one on-demand pool is configured for each customer VPN supported by that router. Upon configuration, the VHG/PE or NAS/PEs pool manager requests an initial subnet from the server.
Address management is on demand because address pool subnets are allocated or released based on a threshold. If use exceeds a defined ceiling threshold, the pool manager requests an additional subnet from the server and adds it to the on-demand pool. If use falls below a floor threshold, the pool manager attempts to free one, or more than one, of the on-demand pool's subnets to return it to the server. The VRF routing table on the VHG/PE or NAS/PE is updated with the subnet route whenever a range of addresses is requested from the Access Registrar (AR).
ODAP's benefits include efficient management of address space and dynamic address summarization on the VRF table. ODAP has two main drawbacks:
You can use ODAP if subnet management is more important than route summarization.
ODAP requires Access Registrar 1.7 or 1.7R1.
ODAP can be used with the following DSL architectures:
The DHCP Option 82 Support for Routed Bridge Encapsulation feature provides support for the DHCP relay agent information option when ATM routed bridge encapsulation (RBE) is used.
This feature enables the DHCP relay agent to communicate information to the DHCP server using a suboption of the DHCP relay agent information option called agent remote ID. The information sent in the agent remote ID includes an IP address identifying the relay agent and information about the ATM interface and the permanent virtual circuit (PVC) over which the DHCP request came in. The DHCP server can use this information to make IP address assignments and security policy decisions.
Packets are not CEF switched in a remote access Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) dial-out scenario using dialer profiles on a Cisco 3640 platform.
In an Layer 2 Tunneling Protocol (L2TP) Large-Scale Dial-Out (LSDO) environment, packets sent from a provider edge (PE) router to a network which recurses to the LSDO next-hop are dropped when they arrive as tagged packets on the virtual home gateway (vHGW). Packets are dropped when the system uses process-switching packet forwarding. Process-switching occurs when the mpls packet debug command is configured or any outbound feature, such as ACL logging, punts the packets to the process path. Packets are dropped only when the new L2TP-Dialout per-user feature is enabled.
A Cisco router running Cisco IOS Release 12.2(13.7)T1 or later will mark a radius server as DEAD when all of the following conditions are met:
1. A deadtime has been configured and is applicable either globally, per-group or per-server. Configure a deadtime globally by entering the radius-server deadtime minutes command in global configuration mode. Configure a per-group deadtime by entering the deadtime minutes command in server group configuration mode. Configure a per-server deadtime by entering the radius-server host ip-address deadtime minutes command.
2. No valid responses have been received from the RADIUS server for the applicable timeout, as configured globally by entering the radius-server timeout seconds command in global configuration mode or configured per-server by entering the radius-server host ip-address timeout seconds command in global configuration mode.
3. A total of the applicable number of RADIUS packet transmissions has been sent to the radius server without any response being received by the router. This number is determined by picking the applicable retransmit number and adding one. The applicable retransmit number defaults to 3, and can be configured globally by entering the radius-server retransmit retries command in global configuration mode or per-server by entering the radius-server host ip-address retransmit retries command in global configuration mode.
When the server is marked as DEAD, all new transmissions to that server cease, including those for transactions already outstanding.
Symptoms: If all configured RADIUS servers (within a server-group or globally, if server groups are not used) have been declared DEAD, the router will no longer issue RADIUS requests until the deadtime of at least one deadtime expires.
In this state, the router issues the following error message:
This problem can also be observed after booting-up when connectivity to the RADIUS servers has not been established and initial RADIUS requests (for example, an accounting-start record) have already timed out.
Conditions: This problem occurs only in Cisco IOS releases 12.2(13.7)T1 and later releases and if a deadtime is configured globally or within the server-group. With earlier IOS releases, the router skips the deadtime if all servers are declared DEAD.
Workaround: Do not configure RADIUS-server deadtime.
(duplicate of CSCdw67557; resolved in Release 12.2(11.3)T) A high rate of packet loss is observed when a virtual home gateway (VHGW) provider edge (PE) router passes traffic with layer 2 tunnel protocol (L2TP) dial-out and Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) using dialer profiles. Almost half of traffic is lost, giving pings a result of 50 percent 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 no ip route-cache cef command.
Direct dial-out Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) with dialer profiles does not work. A ping from the Network Access Server (NAS)/Provider Edge (PE) router to the peer will successfully trigger a call but subsequent IP connectivity is unidirectional: IP packets successfully sent to the peer are not correctly handled.
Workaround: Use multilink PPP.
Small ping packets on the virtual home gateway (VHG)/provider edge (PE) router are dropped with Inter-Switch Link (ISL) is turned on. Pings from a remote access to Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) dial-in PPP session with a packet size greater than 40 bytes get a response but small ping packets of 36 to 40 bytes do not get a response packet back from the remote PE/Customer Edge (CE) router IP destination. The reply packet is dropped when the tagged packet is received on the VHG/PE and should be sent out to a L2TP access concentrator (LAC) via Layer 2 Tunnel Protocol (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 L2TP packets. There is no problem when ISL encapsulation is not used.
This problem does not exist for small ping packets when debug mpls is configured on the VHG/PE. MLPPP on the PPP sessions do not experience this problem.
1) Enable debug mpls packet command 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.
(Resolved in Release 12.2(8)T1) In 12.2(5.7)T and later releases). A Cisco router acting as an Layer 2 tunnel protocol access concentrator (LAC) or L2TP network access server (NAS) may fail to process valid L2TP Zero Length Block Acknowledgement packets. This can cause sessions and tunnels to drop. This caveat applies to the VPN, not to remote access integration.
A Cisco router may reload when L2TP dial-out using dialer profiles under medium load is configured. Calls are set up at a rate higher than two calls per second. Executing commands such as show run may reload the router at an even lower call rate.
The IP background task removes a newly IPCP installed route. When a user attempts to dial back in to a remote access Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) service for layer 2 tunnel protocol (L2TP) dial-in to either a virtual home gateway (VHG)/provider edge (PE) router or a direct dial-in network access server (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.
Spurious memory access may be detected on a Layer 2 Tunneling Protocol (L2TP) access concentrator (LAC) and a L2TP network server (LNS). This symptom is observed when virtual private dialup network (VPDN) callout is performed using L2TP.
(Resolved in release 12.2(8.5)T) When Multilink PPP (MLP) over ATM (MLPoATM) is configured on an Multiprotocol Label Switching (MPLS) Virtual Private Network (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 and forwarding instance (VRF) using RADIUS attributes.
Workaround: Select the VRF by configuring the virtual template using the ip vrf forwarding interface configuration command.
(Resolved in Release 12.2(9.1)T) An Multiprotocol Label Switching (MPLS) router that has several Virtual Private Network (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.
(Resolved in Release 12.2(9.1)T) Memory leak in the "PPP IPCP" process. Occurs when using AAA per user attributes.
(Duplicate of CSCdw10495; resolved in Release 12.2(8.5)T) When layer 2 tunnel protocol (L2TP) sessions are brought up on a Cisco 7500 series routers running Cisco IOS Release 12.2(8)T, the L2TP access concentrator (LAC) may fail to establish a connection with L2TP network server (LNS).
(Resolved in Release 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:
When IP unnumbered interfaces are used with Virtual Route Forwarding instances (VRFs), Dynamic Host Configuration Protocol (DHCP) requests forwarded to a different VRF or to the global table, do not create 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".
In layer 2 forwarding (L2F)/layer 2 tunnel protocol (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.
(Duplicate of CSCdt78572) In Multichassis Multilink PPP (MMP) or Multilink PPP (MLP) layer 2 tunnel protocol (L2TP) dial-in Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN), one cannot ping to the loopback interface in the virtual routing forwarding instance (VRF) on the virtual home gateway (VHG)/provider edge (PE) router because reply echo packets are not routable. There is no workaround.
(Duplicate of CSCdp86381) Systems which use Virtual Private Dialup Network (VPDN) to tunnel PPP sessions may experience buffer memory leaks on the home gateway router when those PPP interfaces have also negotiated the use of PPP multilink.
In Cisco IOS releases prior to 12.2(1.1), this problem is only visible when multilink bundles which include VPDN tunneled PPP links are configured to use non-first-in, first-out (FIFO) queuing modes. As fancy queuing is not presently supported in conjunction with any form of VPDN session, correcting the bundle configuration to use FIFO queuing suffices to avoid the problem.
Starting with Cisco IOS Release 12.2(1.1), the problem may also be seen even in cases where FIFO queuing is in effect.
Workaround: Disable IP fastswitching (including CEF) on the interfaces which are carrying the VPDN tunnelled traffic between the network access server (NAS) and the home gateway (HGW).
When the no ip route-cache cef command is configured on the virtual template for the layer 2 tunnel protocol network server (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).
(Duplicate of CSCdt97779) Traceback messages are observed on an layer 2 tunnel protocol (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.
(Duplicate of CSCdw00924) When Multilink PPP (MLP) over ATM (MLPoATM) is configured on a Cisco 7200 route processor module (RPM) along with Fancy Queueing 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 queueing (WFQ) queue, avoid congesting the link.
(Duplicate of CSCdt83679) In Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) environment, where two service providers are connected to each other using a pair of autonomous system boundary router (ASBRs) providing InterAS VPN functionality, if the connection between the routers is Ethernet, the Tag Forwarding Information Base (TFIB) entry for the ASBR peer may disappear after clearing the routing table with the clear ip route command.
Workaround: Restart the BGP session between ASBRs.
(Resolved in Release 12.2(8)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 and ip route-cache interface configuration commands on the virtual template interface to allow all packets to go through the process-switching. This solution also fixes the incorrect value display with Vaccess counters, observed after CSCdw01642. Counters on the Vaccess interfaces used for L2TP sessions (on the LAC and LNS) displayed incorrect values when IP CEF was enabled on high end routers.
(Duplicate of CSCdt59038) When Multilink PPP (MLP) over ATM (MLPoATM) is configured, the Virtual Circuit (VC) may experience throughput problems and very low link utilization.
(Duplicate of CSCdu62885) When a route switch processor (RSP) is used with Multilink PPP (MLP), an access alignment error causes a performance problem.
(Duplicate of CSCdw45057) In layer 2 tunnel protocol (L2TP) dial-in, IP Control Protocol (IPCP) is rejected because of a AAA problem. Authentication does not start and IPCP is rejected from the virtual home gateway (VHG)/provider edge (PE) router. The same test was done without entering the aaa new-model command and passed. Direct dial-in worked.
When RADIUS user profiles contain an "ip:route" vendor-specific attribute (VSA) which itself contains virtual route forwarding (VRF) information, the route is parsed incorrectly. This leads to an error when the route is applied, and causes the call to go down.
Subnet allocation option is sent by the Dynamic Host Configuration Protocol (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 when the client is in REBINDING state. This can be checked by enabling the debug dhcp detail command in the client.
Spurious memory access might occur on Stack Group Bidding Protocol (SGBP) offload server on a Cisco 7200 series router.
In layer 2 tunnel protocol (L2TP) dial-out, data packets are sent with incorrect encapsulation. This behavior occurs if Multilink PPP (MLP) is not configured on a virtual home gateway (VHG)/provider edge (PE) router that supports Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN).
In layer 2 tunnel protocol (L2TP) dial-out, returned data may be corrupted.
A Cisco 7500 series router running nondistributed Multiprotocol Label Switching (MPLS) may reload when per packet load sharing is configured. The reload is likely to happen in MPLS virtual private network (VPN) environments. This is suspected to be a duplicate of CSCdt04761.
A provider edge (PE) router may reload while it is switching traffic if the Label Distribution Protocol (LDP) label becomes unavailable.
This condition if either of the following occurs:
A Cisco router that is running Cisco IOS Release 12.2(3) and that is configured with Multiprotocol Label Switching (MPLS), Multilink PPP (MLP), and Cisco express forwarding (CEF) may record spurious memory accesses and log the following messages:
The effect on the router is poor performance and high CPU utilization, even when there is little traffic.
Cisco Express Forwarding (CEF) may not function properly with PPP in a Layer 2 Tunneling Protocol (L2TP) dialout environment. This condition is observed on a Cisco router that is running Cisco IOS Release 12.2 T.
(Duplicate of CSCdt30297; resolved in Release 12.2(6.7)T)The per user static route command is not added to the virtual route forwarding (VRF) routing table. Debugging a working setup on the virtual home gateway (VHG)/provider edge (PE) router with Release 12.2(2.5)T shows that the attribute value (AV) pair is accepted, whereas in the same setup with Release 12.2(4)T on the VHG/PE it is not. With Release 12.2(4)T, there is no debugging info that shows that the route is implemented into the routing table
In 12.2(4)T this debugging is not present, nor are there any errors seen. The configuration is the same as on Release 12.2(2.5)T, so no errors were expected.
In dial-out, the Multilink PPP (MLP) header is not added with the Multiprotocol Label Switching (MPLS) packet.
The Cisco Express Forwarding (CEF) "receive" entry may not be created in the virtual route forwarding (VRF) instance for an imported secondary IP address, causing difficulties in pinging this secondary IP address in the VRF instance.
A Cisco router that is using Multilink PPP (MLP) and virtual private dial-up network (VPDN) Multiprotocol Label Switching (MPLS) and has keepalives enabled may reload when the router is attempting to bring up the second link.
Workaround: Disable keepalives.
(Duplicate of CSCdv54349; resolved in 12.2(5.7)T) When the configuration command aaa authentication ppp default local group radius is used, if a username 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 aaa authentication ppp default group radius configuration command.
(Duplicate of CSCdu62885; resolved in Release 12.2(5.4)T) When RSP is used with Multilink PPP (MLP), an access alignment error causes a performance problem.
Border Gateway Protocol (BGP) virtual private network version 4 (VPNv4) address family routes are not 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 are not generated or advertised.
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.
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 Dynamic Host Configuration Protocol (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 a layer 2 tunnel protocol (L2TP) tunnel.
Workaround: Use a local IP address pool configured on the access concentrator to give the IP address to the remote end of a PPPoA connection.
The idle timer is not reset in a direct dial out Multiprotocol Label Switching (MPLS) virtual private network (VPN) setup using dialer profiles. Disabling Cisco Express Forwarding (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 occurs only in PXF in a Multiprotocol Label Switching (MPLS) switching environment on a Cisco NSE-1.
Workaround: Disable PXF on NSE-1 or use another NSE.
In layer 2 tunnel protocol (L2TP) the combination of Cisco Express Forwarding (CEF) switching, Multilink PPP (MLP), and (VPN routing and forwarding instance) does not work: CEF switched packets are dropped. This caveat applies to all routers that support CEF and all releases.
Workaround: Disable either CEF or MLP.
Cisco Express Forwarding (CEF) is stuck in Glean Adjacency when not using 32-bit host rate on the Cisco 6400 router running Release 12.2(03.06)B03.
The documentation set for Cisco Remote Access to MPLS VPN Integration 2.0 comprises two guides:
Cisco Remote Access to MPLS VPN Solution Overview and Provisioning Guide 2.0:
http://www.cisco.com/univercd/cc/td/doc/product/vpn/solution/rampls2/ovprov/index.htm
Troubleshooting Cisco Remote Access to MPLS VPN Solution Troubleshooting Guide 2.0
http://www.cisco.com/univercd/cc/td/doc/product/vpn/solution/rampls2/trblsht/index.htm
The following platform release notes are available for the Remote Access to MPLS VPN Solution:
Cisco Access Registrar Release Notes, 1.7:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cnsar/1_7/relnote/index.htm
Release Notes for Cisco Digital Subscriber Line Manager, Release 3.2:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cdm/cdmrel32/cdm3_2rn.htm
Cisco IP Manager Release Notes, 2.0(43):
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/ip_mgr/rn2_43/index.htm
Release Notes for Cisco Info Center 2.0:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/info_ctr/2_0_0/relnot_2/notes.htm
Cisco Network Registrar Release Notes:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/ciscoasu/nr/nr3-5/relnote/index.htm
Release Notes for Cisco Resource Pool Manager Server Release 1.04:
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/rpms/rpms_1-0/rpmsnote.htm
Cisco 6400 Service Connection Manager v1.2 Engineering Release Note:
http://www.cisco.com/univercd/cc/td/doc/product/dsl_prod/scm/rl282b.htm
NetFlow Collector 3.0 Release Notes:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/vpnsc/mpls/1_1/install/vpn_ig_1.htm#xtoci d92954
Service Selection Dashboard (SSD) 2.2S(1.12) Release Notes:
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/ciscossd/ssdusr21/intro.htm#xtocid2 59362
VPN Solution Center 2.1 Release Notes:
h ttp://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/vpnsc/mpls/2_1/relnotes/relnotes.htm
Cisco VPN Solutions Center MPLS 2.1 documentation is available on Cisco.com or the Cisco Universal Documentation CD:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/vpnsc/mpls/2_1/index.htm
The following Cisco Network Management reference documentation is available on Cisco.com or the Cisco Universal Documentation CD:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cnsar/
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cdm/
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/ciscoasu/nr/index.htm
Cisco 6400 Service Connection Manager
http://www.cisco.com/univercd/cc/td/doc/product/dsl_prod/scm/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/ip_mgr/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/nfc/index.htm
The following Cisco Network Management reference documentation is available on Cisco.com or the Cisco Universal Documentation CD:
Dial Solutions Quick Configuration Guide
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12supdoc/dsqcg3/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5800/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/dsl_prod/6260/hig/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/dsl_prod/6015/user/hig/index.htm
Cisco 6400 Universal Access Concentrator
http://www.cisco.com/univercd/cc/td/doc/product/dsl_prod/6400/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/core/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/core/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8950/
The Cisco IOS 12.2 software documentation set:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/index.htm
Cisco provides several ways to obtain documentation, technical assistance, and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
You can access the most current Cisco documentation on the World Wide Web at this URL:
http://www.cisco.com/univercd/home/home.htm
You can access the Cisco website at this URL:
International Cisco web sites can be accessed from this URL:
http://www.cisco.com/public/countries_languages.shtml
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which may have 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.
Registered Cisco.com users can order the Documentation CD-ROM (product number DOC-CONDOCCD=) through the online Subscription Store:
http://www.cisco.com/go/subscription
You can find instructions for ordering documentation at this URL:
http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm
You can order Cisco documentation in these ways:
http://www.cisco.com/en/US/partner/ordering/index.shtml
http://www.cisco.com/go/subscription
You can submit comments electronically on Cisco.com. On the Cisco Documentation home page, click Feedback at the top 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: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883
Cisco provides Cisco.com, which includes the Cisco Technical Assistance Center (TAC) Website, as a starting point for all technical assistance. Customers and partners can obtain online documentation, troubleshooting tips, and sample configurations from the Cisco TAC website. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC website, including TAC tools and utilities.
Cisco.com offers a suite of interactive, networked services that let you access Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.
Cisco.com provides a broad range of features and services to help you with these tasks:
To obtain customized information and service, you can self-register on Cisco.com at this URL:
The Cisco 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 website and the Cisco TAC Escalation Center. The avenue of support that you choose depends on the priority of the problem and the conditions stated in service contracts, when applicable.
We categorize Cisco TAC inquiries according to urgency:
You can use the Cisco TAC website 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 website, 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 website. Some services on the Cisco TAC website require 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:
http://tools.cisco.com/RPF/register/register.do
If you are a Cisco.com registered user, and you cannot resolve your technical issues by using the Cisco TAC website, you can open a case online at this URL:
http://www.cisco.com/en/US/support/index.html
If you have Internet access, we recommend that you open P3 and P4 cases through the Cisco TAC website so that you can describe the situation in your own words and attach any necessary files.
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:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
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.
Information about Cisco products, technologies, and network solutions is available from various online and printed sources.
http://www.cisco.com/en/US/products/products_catalog_links_launch.html
http://www.cisco.com/en/US/about/ac123/ac114/about_cisco_packet_magazine.html
http://business.cisco.com/prod/tree.taf%3fasset_id=44699&public_view=true&kbns=1.html
http://www.cisco.com/en/US/about/ac123/ac147/about_cisco_the_internet_protocol_journal.html
http://www.cisco.com/en/US/learning/le31/learning_recommended_training_list.html
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, iQ Net Readiness Scorecard, Networking Academy, and ScriptShare are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, 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, iQ Expertise, the iQ logo, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, TransPath, 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. (0303R)
Copyright © 2003 Cisco Systems, Inc. All rights reserved.
Posted: Sun Mar 30 15:10:41 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.