Table Of Contents
Release Notes for the Cisco 10000 Series Router for Cisco IOS Release 12.3(7)XI2
November 11, 2004
These release notes provide information about Cisco IOS Release 12.3(7)XI2, which provides broadband aggregation and leased-line features for the Cisco 10000 series router.
These release notes are updated as needed to describe new features, memory requirements, hardware support, software platform deferrals, and changes to the microcode and related documents.
Cisco IOS Release 12.3(7)XI2 is based on the following releases:
•Cisco IOS Release 12.2(16)BX
•Cisco IOS Release 12.3T
•Cisco IOS Release 12.3(7)XI1
To review the release notes for Cisco IOS Release 12.2(16)BX, go to the following URL:
To review the release notes for Cisco IOS Release 12.3, go to the following URL:
This document contains the following sections:
Cisco IOS Release 12.3(7)XI2 requires that you have the performance routing engine (PRE), Part Number ESR-PRE2 installed in the Cisco 10000 series router chassis. To verify which PRE is installed in the router, use the show version command.
Route Processor Redundancy Mode
The Cisco 10000 series router supports route processor redundancy (RPR) mode or RPR+ mode to provide fault resistance and to ensure high availability. In RPR mode, one supervisor engine is active and operational while the second supervisor engine is in standby mode waiting for the active supervisor to fail so that it can take over and maintain the operation of the router. In RPR+ mode, the standby supervisor engine is fully initialized and configured, which shortens the time needed to switch over to the standby supervisor.
When upgrading or downgrading the Cisco IOS software, the RPR mode used on the Cisco 10000 series router depends upon the Cisco IOS software currently running on the Cisco 10000 series router and the Cisco IOS software to which you want to upgrade or downgrade.
Table 1 lists the RPR modes used when upgrading or downgrading Cisco IOS software. For example, when upgrading to Cisco IOS Release 12.3(7)XI2 from Release 12.2(16)BX, the router uses RPR mode instead of RPR+ mode. When downgrading to Cisco IOS Release 12.2(16)BX from Cisco IOS Release 12.3(7)XI2, the router uses RPR mode.
Table 1 RPR Modes for Cisco IOS Software Releases
Releases 12.2(16)BX 12.3(7)XI2
Before You Upgrade the Cisco IOS Software
Before you upgrade (or downgrade) the Cisco IOS software running on the Cisco 10000 series router, save the running configuration file. In RPR mode, the router synchronizes only the startup configuration.
Upgrading to a New Software Release
For specific information about upgrading your Cisco 10000 series router to a new software release, refer to the Cisco 10000 Series Router Software Configuration Guide.
For additional information about ordering Cisco IOS software, refer to the Cisco IOS Software Releases.
New Features—Cisco IOS Release 12.3(7)XI2
The following new features and improvements are supported on the Cisco 10000 series router in Cisco IOS Release 12.3(7)XI2.
For more information about the new features in Cisco IOS Release 12.3(7)XI2, refer to the following documentation:
For information about new features supported on the Cisco 10000 series router in other releases, see the appropriate Release Notes at the following URL:
Define Interface Policy-Map AV Pairs AAA
The Define Interface Policy-Map AV Pairs AAA feature introduces two Cisco Remote Authentication Dial-In User Service (RADIUS) vendor-specific attributes (VSAs) that allow a policy map to be applied on the virtual circuit (VC) via RADIUS during a Point-to-Point Protocol over ATM (PPPoA) or Point-to-Point Protocol over Ethernet over ATM (PPPoEoA) session establishment.
The Define Interface Policy-Map AV Pairs AAA feature introduces two Cisco VSAs that allow you to apply a policy map at the ATM VC level using RADIUS. The purpose of the Cisco VSA (attribute 26) is to communicate vendor-specific information between the network access server (NAS) and the RADIUS server. The Cisco VSA encapsulates vendor specific attributes that allow vendors such as Cisco to support their own extended attributes.
The Define Interface Policy-Map AV Pairs AAA feature allows a policy map to be applied ("pulled") on the VC during a PPPoA or PPPoEoA session establishment.
In earlier releases a policy map could only be configured on a VC or ATM point-to-point subinterface by using modular QoS CLI (MQC). A service policy could be applied to the sessions on these VCs using RADIUS or manually with the virtual template. In this release, this feature allows a service policy to be applied on the VC using RADIUS for a PPPoA or PPPoEoA session. (However, configuring a service policy on the ATM subinterface still requires CLI configuration.)
In Cisco IOS Release 12.3(7)XI2, the Define Interface Policy-Map AV Pairs AAA feature allows a service policy to be applied on the VC using RADIUS for a PPPoA or PPPoEoA session. (However, configuring a service policy on the ATM subinterface still requires CLI configuration and enabling DBS
on the VC in particular.)
For more information about this feature, see the Define Interface Policy-Map AV Pairs AAA feature guide at http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123limit/123x/123xi7/123xiqos.htm#wp1043332
Dynamic ATM VP and VC Configuration ModificationIn Cisco IOS Release 12.3(7)XI1, when you change the weight of a VC or the VP shaping parameters, the VC or VP gets torn down at the SAR and the session goes down. In Cisco IOS Release 12.3(7)XI2, the Dynamic ATM VP and VC Configuration Modification feature allows you to change the VC weight or VP shaping parameters without affecting the state of the VC or VP. In other words, the VC and VP remain up and operational.
The dynamic parameters include ATM VP parameters (PCR or CDVT) and VC parameters (weight, PCR, SCR, MBS, and CDVT). When you change VC parameters or the VP rate, there can be a momentary change in the VP's shaped rate, in which the rate cells are sent might be over or under the configured rates. The session stays up and no data is lost.
In Cisco IOS Release 12.3(7)XI2, the range of integer values supported by the weight-value parameter of the weight command is 1 to 255. In Cisco IOS Release 12.3(7)XI1, the range is 5 to 255.
Local Template-Based ATM PVC Provisioning
The Local Template-Based ATM PVC Provisioning feature supports PVC autoprovisioning for an infinite range of VPI/VCI combinations on an ATM interface.
The Local Template-Based ATM PVC Provisioning feature enables ATM permanent virtual circuits (PVCs) to be provisioned automatically as needed from a local configuration, making the provisioning of large numbers of digital subscriber line (DSL) subscribers easier, faster, and less prone to error. ATM PVC autoprovisioning can be configured on a PVC, an ATM PVC range, or a VC class. If a VC class configured with ATM PVC autoprovisioning is assigned to the main interface, all the PVCs on that main interface will be autoprovisioned; this configuration is sometimes referred to as an infinite range.
MQC Policy Map Support on Configured VC Range ATM
In releases prior to Cisco IOS Release 12.3(7)XI2, MQC policy maps on ATM VCs were supported, but to attach a service policy to an ATM VC you had to configure the service policy in PVC mode. The MQC Policy Map Support on Configured VC Range ATM feature simplifies this configuration by allowing you to implement a service policy under range PVC mode and under PVC in range mode.
RADIUS Attribute 31: PPPoX Calling Station ID
The RADIUS Attribute 31: PPPoX Calling Station ID feature enables service providers to provide more information about the call originator to the RADIUS server in a DSL environment, such as the physical lines on which customer calls originate. Specifically, this feature allows operators to track customers through the physical lines on which customer calls originate. Service providers can better maintain the profile database of their customers as they move from one physical line to another.
Because this feature provides a virtual port that does not change as customers move from one physical line to another, RADIUS attribute 31 (Calling-Station-ID) can also be used for additional security checks. The Calling-Station-ID attribute is included in both ACCESS-REQUEST and ACCOUNTING-REQUEST messages.
Cisco IOS Release 12.3(7)XI2 provides increased limits with queue scaling and VC scaling.
At least two queues are allocated for every interface or subinterface for which separate queues are created. The first queue is the default queue for normal traffic, and the second queue, known as the system queue, is used for a small amount of router-generated traffic that bypasses the normal drop mechanisms. For 32,000 VCs, this would require the allocation of a minimum of 64,000 queues. While Cisco IOS Release 12.3(7)XI1 added support for up to 128,000 queues, a more effective use of these limited resources is realized by having the subinterfaces on a given main interface share the single system queue of the main interface.
In Cisco IOS Release 12.3(7)XI2, the subinterfaces on a given main interface share the single system queue of the main interface, and this allows for 32,000 subinterfaces with a three-queue model that supports assured forwarding (AF) queues and expedited forwarding (EF) queues, in addition to the default best effort (BE) queues. Because there isn't a system queue for every subinterface, this frees up queues for a 4-queue model.
When configured for hierarchical shaping, ATM line cards support the following number of VCs:
•OC-12 ATM line card supports a maximum of 16,384 VCs (previously 14,436)
•OC-3 ATM line card and the E3/DS3 line card support a maximum of 28,672 VCs (previously 8,192).
In atm pxf queuing mode, ATM line cards support the following number of VCs:
Line Card Maximum VCs per Port Maximum VCs per Module VBR, CBR, Shaped UBR VCs
You can configure the maximum number of VCs across the ports in any fashion, provided that you do not exceed the per-port maximum.
Shaped UBR PVCs
Prior to Cisco IOS Release 12.3(7)XI2, you could configure shaped unspecified bit rate (UBR) PVCs but only when the no atm pxf queuing command was configured. In Cisco IOS Release 12.3(7)XI2, you can configure shaped UBR PVCs when the atm pxf queuing command is configured.
When shaped UBR is specified, the layer 3 scheduling for the UBR VC is set up in the same fashion as VBR and CBR VCs are set up. The VC has its own VTMS link and a set of queues assigned to it. The rate of the link is based on the PCR you specify. Flowbits are assigned to the VC. Unlike VBR and CBR VCs, only a single flowbit is assigned to the VC; it is not based on rate.
Like VBR and CBR VCs, the shaped UBR VCs can have queuing service policies applied to them. The UBR VCs are not subject to any CAC checks, but the number of shaped UBR VCs must be within existing limits. These limits include: the maximum number of VCs per system, maximum number of VCs per port, and maximum number of VCs with flowbits.
Limitations and Restrictions
This section describes limitations and restrictions for the following areas. Be sure to review the following limitations and restrictions before using the features in the Cisco IOS Release 12.3(7)XI2:
For more information about the restrictions for a specific feature, refer to the Cisco 10000 Series Broadband Aggregation and Leased-Line Configuration Guide.
ATM PVC Autoprovisioning
The following restrictions apply to the ATM PVC Autoprovisioning feature:
•The SAR translates the external VPI/VCI values into an internal 32-bit logical header. Router interfaces can support 510 unique bit field combinations in the 32-bit logical header. While there are 512 total SAR pages, page 0 is unused due to a hardware limitation and page 511 is reserved for tunnels.
Note Note: The limit of 510 usable SAR pages in Cisco IOS Release 12.3(7)XI2 represents a reduction from the limit of 512 usable SAR pages in earlier releases.
•The Local Template-Based ATM PVC Provisioning feature (infinite range) can be configured only on a main ATM interface; that is, it cannot be configured on a subinterface. When you use the class-int command to attach an ATM VC class to a subinterface, the create on-demand command is ignored.
•PVCs or PVCs within a range specified as create on demand PVCs, count against the interface limit for configured PVCs, regardless of whether the PVCs become active. These PVCs count against the maximum number of VCs allowed per interface port.
Controlling the Rate of Logging Messages
It is important that you limit the rate that system messages are logged by the Cisco 10000 series router. This helps to avoid a situation in which the router becomes unstable and the CPU is overloaded. To control the output of messages from the system, use the logging rate-limit command.
Cisco recommends that you configure the logging rate-limit command as follows. This limits the rate of all messages to the console to 10 per second, except for messages with critical priority (level 3) or greater.Router(config)# logging rate-limit console all 10 except critical
For more information, refer to the logging rate-limit command in the Cisco IOS Configuration Fundamentals and Network Management Command Reference, Release 12.3.
Define Interface Policy-Map AV Pairs AAA
You cannot configure a service policy on a VC and on a session at the same time.
Dynamic ATM VP and VC Configuration Modification
The following restrictions apply to the Dynamic ATM VP and VC Configuration Modification feature:
•A weight of less than 10 should not be used, because it can adversely affect the performance of the ATM port.
•When you change VC parameters or the VP rate, there can be a momentary fluctuation in the VP's effective shaped rate, in which the rate that cells are sent might be over or under the configured rates.
•The Dynamic ATM VP and VC Configuration Modification feature does not allow you to dynamically change the queue depth or the type of VC (for example, from CBR to VBR-nrt).
The following limitations apply to the Cisco 10000 series router implementation of Frame Relay:
•The ip rtp reserve command is not supported.
•Only one priority queue per VC is allowed.
Local Template-Based ATM PVC Provisioning
The Local Template-Based ATM PVC Provisioning feature (infinite range) can be configured only on a main ATM interface; that is, it cannot be configured on a subinterface. When you use the class-int command to attach an ATM VC class to a subinterface, the create on-demand command is ignored.
MQC Policy Map Support on Configured VC Range ATM
The MQC Policy Map Support on Configured VC Range ATM feature applies to ATM VCs only.
PRE Network Management Ethernet Port
Ensure that the Fast Ethernet NME port on the PRE is configured for auto-negotiation mode, which is the system default. Duplex mode can cause problems, such as flapping. If the port is experiencing such problems and has been configured for duplex mode, use the no half-duplex or no full-duplex command to disable duplex mode.
RADIUS Attribute 31: PPPoX Calling Station ID
The following limitations apply to the RADIUS Attribute 31: PPPoX Calling Station ID feature:
•Do not use the RADIUS Logical Line ID feature with the RADIUS Attribute 31: PPPoX Calling Station ID feature. Using both features causes two instances of the attribute in the RADIUS IOS database for a particular user.
•While this feature can be used with any vendor's RADIUS server, some RADIUS servers can require modifications to their dictionary files to allow the Calling-Station-ID attribute to be presented correctly in the RADIUS logs.
•This feature supports only RADIUS; TACACS+ is not supported.
•Currently, PPPoEoVLAN and PPPoEoQinQ do not provide information on VLAN tags; only the MAC address is provided to the RADIUS server.
•RADIUS attribute 31 (Calling-Station-ID) is not supported for L2TP Network Server (LNS) environments. If you enable this attribute on an LNS, the attribute is not sent to the RADIUS server.
If you configure create on demand PVCs (individual and within a range) and PPP sessions, RP CPU utilization can be extremely high when bringing up and tearing down sessions and PVCs. This is only a concern when the configuration contains approximately 30,000 PPP sessions, and additional services are enabled such as DBS, ACLs, and service policies.
To reduce the RP CPU usage for PPPoA sessions, reduce the number of configured PVCs in a single subinterface. To reduce the RP CPU usage for PPPoEoA sessions, use call admission control (call admission limit command).
Shaped UBR PVCs
Only variable bit rate (VBR) VCs are allowed in the VP tunnel. You cannot configure unspecified bit rate (UBR) VCs or constant bit rate (CBR) VCs in the tunnels.
Testing Performance of High-Speed Interfaces
Cisco IOS software running on the Cisco 10000 series router has multiple queues for all classes of traffic over high-speed interfaces. The software selects a queue based on the source and destination address for the packet. This ensures that a traffic flow always uses the same queue and the packets are transmitted in proper order.
When the Cisco 10000 series router is installed in a real network, the high-speed interfaces work efficiently to spread traffic flow equally over the queues. However, using single traffic streams in a laboratory environment may result in less-than-expected performance.
Therefore, to ensure accurate test results, you should test the throughput of the gigabit Ethernet, Packet over SONET (POS), or ATM uplink with multiple source or destination addresses.
Tip To determine if traffic is being properly distributed, use the show hardware pxf cpu queue command.
This section provides important information about the following topics:
Configuring the aaa new-model Command
The aaa new-model command is disabled by default on the Cisco 10000 series router. In previous releases, the default configuration did not appear in the running configuration file. However, in Cisco IOS Release 12.3(7)XI2 or later releases, the running configuration file now includes the no aaa new-model command. This is an intentional change in behavior for this command and is the first step in a three-step process to change the default configuration to aaa new-model.
Note This change in behavior differs from Cisco IOS software, which typically does not include default configurations in the running configuration file.
For example, when you enter the show running-config command, no aaa new-model appears in the configuration if either of the following conditions previously occurred:
•You did not configure the aaa new-model command on the router and instead accepted the default configuration of the file: no aaa new-model.
•You entered the no aaa new-model command to remove the previously configured aaa new-model command.
Enhancing Scalability of Per-User Configurations
To enhance scalability of per-user configurations without changing the router configuration, use the ip:vrf-id and ip:ip-unnumbered RADIUS attributes. These per-user vendor specific attributes (VSAs) are used to map sessions to VRFs and IP unnumbered interfaces. The VSAs apply to virtual access subinterfaces and are processed during PPP authorization.
In releases earlier than Cisco IOS Release 12.2(16)BX1, the lcp:interface-config RADIUS attribute is used to map sessions to VRFs. This per-user VSA applies to any type of interface configuration, including virtual access interfaces. Valid values of this VSA are essentially any valid Cisco IOS interface command; however, not all Cisco IOS commands are supported on virtual access subinterfaces. To accommodate the requirements of the lcp:interface-config VSA, the per-user authorization process forces the Cisco 10000 series router to create full virtual access interfaces, which consume more memory and are less scalable.
In Cisco IOS Release 12.2(16)BX1 and later releases, the ip:vrf-id is used to map sessions to VRFs. Any profile that uses the ip:vrf-id VSA must also use the ip:ip-unnumbered VSA to install IP configurations on the virtual access interface that is to be created. PPP that is used on a virtual access interface to be created requires the ip:ip-unnumbered VSA. An Internet Protocol Control Protocol (IPCP) session is not established if IP is not configured on the interface. You must configure either the ip address command or the ip unnumbered command on the interface so that these configurations are present on the virtual access interface that is to be created. However, specifying the ip address and ip unnumbered commands on a virtual template interface is not required because any pre-existing IP configurations are removed when the ip:ip-vrf VSA is installed on the virtual access interface. Therefore, any profile that uses the ip:vrf-id VSA must also use the ip:ip-unnumbered VSA to install IP configurations on the virtual access interface that is to be created.
These per-user VSAs can be applied to virtual access subinterfaces; therefore, the per-user authorization process does not require the creation of full virtual access interfaces, which improves scalability.
Setting VRF and IP Unnumbered Interface Configurations in User Profiles
Although the Cisco 10000 series router continues to support the lcp:interface-config VSA, the ip:vrf-id and ip:ip-unnumbered VSAs provide another way to set the VRF and IP unnumbered interface configurations in user profiles. The ip:vrf-id and ip:ip-unnumbered VSAs have the following syntax:Cisco:Cisco-AVpair = "ip:vrf-id=vrf-name"Cisco:Cisco-AVpair = "ip:ip-unnumbered=interface-name"
Specify only one ip:vrf-id and one ip:ip-unnumbered value in a user profile. However, if the profile configuration includes multiple values, the Cisco 10000 series router applies the value of the last VSA received, and creates a virtual access subinterface. If the profile includes the lcp:interface-config VSA, the router always applies the value of the lcp:interface-config VSA, and creates a full virtual access interface.
Whenever you specify a VRF in a user profile, but you do not configure the VRF on the Cisco 10000 series router, in Cisco IOS Release 12.2(15)BX, the router accepted the profile. However, in Cisco IOS Release 12.2(16)BX1 and later releases, the router rejects the profile.
Setting VRF and IP Unnumbered Interface Configuration in a Virtual Interface Template
You can specify one VSA value in the user profile on RADIUS and another value locally in the virtual template interface. The Cisco 10000 series router clones the template and then applies the values configured in the profiles it receives from RADIUS, resulting in the removal of any IP configurations when the router applies the profile values.
Redefining User Profiles to Use the ip:vrf-id and ip:ip-unnumbered VSAs
The requirement of a full virtual access interface when using the lcp:interface-config VSA in user profiles can result in scalability issues, such as increased memory consumption. This is especially true when the Cisco 10000 series router attempts to apply a large number of per-user profiles that include the lcp:interface-config VSA. Therefore, when updating your user profiles, we recommend that you redefine the lcp:interface-config VSA to the scalable ip:vrf-id and ip:ip-unnumbered VSAs.
Example 1 shows how to redefine the VRF named newyork using the ip:vrf-id VSA.
Example 1 Redefining VRF ConfigurationsChange:Cisco:Cisco-Avpair = "lcp:interface-config=ip vrf forwarding newyork"To:Cisco:Cisco-Avpair = "ip:vrf-id=newyork"
Example 2 shows how to redefine the Loopback 0 interface using the ip:ip-unnumbered VSA.
Example 2 Redefining IP Unnumbered InterfacesChange:Cisco:Cisco-Avpair = "lcp:interface-config=ip unnumbered Loopback 0"To:Cisco:Cisco-Avpair = "ip:ip-unnumbered=Loopback 0"
Inserting a New Line Card
Unlike other Cisco routers, if you insert a new or different line card into a Cisco 10000 series router chassis slot that previously had a line card installed, the line card initially reports that it is administratively up.
Local AAA Server, User Database—Domain to VRF
The Local AAA Server, User Database—Domain to VRF feature is not working correctly in Cisco IOS Release 12.3(7)XI2. For more information, refer to CSCef83376 in Open Caveats—Cisco IOS Release 12.3(7)XI2.
Multilink PPP (MLPPP) is working correctly in Cisco IOS Release 12.3(7)XI2. (It was not working correctly in Cisco IOS Release 12.3(7)XI1).
Provisioning for Scaling
The following configuration parameters enhance scalability on the Cisco 10000 series router:
To configure the Cisco 10000 series router for high scalability, be sure to configure the configuration parameters as described in the sections that follow.
For more information, refer to the Cisco 10000 Series Broadband Aggregation and Leased-Line Configuration Guide.
PPPoA Sessions with IP QoS Static Routes
To scale to 32,000 PPPoA sessions with IP QoS enabled, you must limit the number of IP QoS static routes to 4,000 unidirectional QoS static routes.
AAA Authentication on the NME Port
If you use AAA authentication on the NME port, set both the in and out interface hold queues to 4096. For example:Router(config)# int fa 0/0/0Router(config-if)# hold-queue 4096 inRouter(config-if)# hold-queue 4096 out
Call Admission Control
We recommend that you set the Call Admission Control (CAC) to a maximum of 95. For example:Router(config)# call admission limit 95
Open Caveats—Cisco IOS Release 12.3(7)XI2
Table 2 describes Open Caveats in Cisco IOS Release 12.3(7)XI2.
Resolved Caveats—Cisco IOS Release 12.3(7)XI2
This section describes caveats that were fixed in Cisco IOS Release 12.3(7)XI2.
For information about caveats fixed in other Cisco IOS releases, refer to the appropriate Release Note document at the following URL:
Previously, the router reloaded with a bus error at tcp_outputpending after 2 users connected over a vty executed in parallel the sh running command and the format slot0: command.
Previously, a T3 link on a 4-port channelized OC-3 line card did not come up under Synchronous Digital Hierarchy (SDH) framing. This problem occurred when the 4-port channelized OC-3 line card interoperated with third-party vendor test equipment.
Previously, the traffic flow over multirouter automatic protection switching (MR- APS) connections stopped. This problem occurred under the following conditions:
•MR-APS was enabled on both a Cisco 10000 series router and a Cisco ONS15454 platform.
•The protect interface was configured on an interface of a 6-port OC-3 Packet-over-SONET (POS) line card in the Cisco 10000 series router.
•You entered the shutdown interface configuration command followed by the no shutdown interface configuration command on the interface that was configured as the Protect Group Protocol link while the protect interface was active.
The working interface that was configured for MR-APS on the Cisco ONS15454 platform should have become active but failed to do so, causing the traffic flow over MR-APS connections to stop
Previously, a Cisco device running Cisco IOS and enabled for the Open Shortest Path First (OSPF) Protocol was vulnerable to a Denial of Service (DoS) attack from a malformed OSPF packet. The OSPF protocol was not enabled by default.
The vulnerability was only present in IOS release trains based on 12.0S, 12.2, and 12.3. Releases based on 12.0, 12.1 mainlines and all IOS images prior to 12.0 were not affected. Refer to the Security Advisory for a complete list of affected release trains.
Previously, VPDN per user authentication was not working when "vpdn authen-before-forward" was configured on the LAC, authentication and authorization was via RADIUS, and the RADIUS full username profile did not contain tunnel attributes and contained service-type = outbound. Under these conditions, a second RADIUS request for domain authorization was not sent and the call was locally terminated.
Previously, there was a moderate memory leak that affected 120 bytes+ message data. Over a period of time and if the BGP session flapped frequently, there was a memory loss of a few megabytes.
Previously, SSG only supported one class attribute rather than several of them, although a RADIUS client was supposed to put all class attributes that it received in Access-Accept messages into Accounting-Request messages that it sent for a session. (See RFC2865/2866.) This problem occurred on a Cisco platform that was configured as an SSG.
Previously, the following error message appeared with debug vpdn l2x-errors enabled when users were trying to connect to an LNS and user@domain was the username and domain being used to connect with:
vpn_set_ppp_remote_name: Error inserting username, user@domain, into String DB
This problem occurred in a DSL environment with L2TP. The message appeared on the LNS. It did not affect the functioning of the router.
Previously, standby Performance Routing Engines (PREs) reloaded because of the configuration of each PRE. This problem occurred on a standby PRE that was installed in a Cisco 10000 series router that was running Cisco IOS Release 12.0(26) or 12.0(26)SZ. However, the problem also occurred in other releases.
Previously, when the load was increased to simulate multiple outstanding transactions, the default number of tries was not being calculated as per the formula defined to perform the computation.
Previously, time-based ACLs did not work when placed inside a policy map. The results of placing a time-based ACL inside a policy map was either that the time-based rules were always active or inactive.
Previously, BGP update generation entered a deadlock. This problem occurred when the RR configuration was changed.
Previously, extra network Accounting STOP records were seen when an sync call failed on authentication. These were unwanted records and should not have been generated. This problem occurred for an async call on a 5300-T1 platform running Cisco IOS Release 12.3(5.8).
Previously, there was spurious memory access at atm_vcmode_subcommands. This problem occurred under low memory conditions.
Previously, when a policy map was configured on a Cisco 10000 series router running 12.3(7)XI and the queue limit was set to something higher than the default of 64, the interface queue limit on the serial interface did not change when the service policy was applied.Policy Map downlinkClass class-defaultqueue-limit 128shape 1500
Previously, a memory leak may occurred in the "dead process" on a Cisco router, and memory allocation failures (MALLOCFAIL) was reported in the processor pool. The authentication, authorization, and accounting (AAA) User Identifier (UID) database could leak about 200,000 bytes for each failed EXEC call or vty session because of internal errors during the initiation process. This problem occurred when EXEC Accounting and Network Accounting were enabled and when a failure occurred during an EXEC call or a vty session. The reasons for the EXEC call failure or vty session failure could have been low processor memory on the Cisco router, an internal message processing error, or a timeout during the prompting for a username and password.
Previously, a Cisco router that functioned as a PPPoX aggregator reloaded because of a bus error. this problem occurred in a highly scaled environment when many sessions were simultaneously established and torn down.
Cisco Internetwork Operating System (IOS) Software is vulnerable to a Denial of Service (DoS) attack from crafted IPv6 packets when the device has been configured to process IPv6 traffic. This vulnerability requires multiple crafted packets to be sent to the device which may result in a reload upon successful exploitation.
More details can be found in the security advisory, which is posted at http://www.cisco.com/warp/public/707/cisco-sa-20050126-ipv6.shtml.
Previously, an SNMP trap configuration was erased when you entered the snmp-server enable traps snmp global configuration command with any trap type followed by the snmp-server enable traps [syslog | entity] global configuration command. This problem occurred on multiple Cisco platforms that run Cisco IOS Release 12.2 or Release 12.3.
This caveat consisted of 6 separate problems, of which the first 3 apply to all Cisco IOS releases and the last 3 apply only to Cisco IOS Release 12.3 T:
1) There were 3 symptoms for this problem:
•There was an inconsistent or duplicate display of files between the show disk slot-number and dir disk slot-number commands.
•When a file was deleted from the CLI, the file was deleted but a "No such file" message appeared.
•One cluster leaked. Entering the fsck command truncated the original file and created an orphan file for the leaked cluster.
This problem occurred when an application created or opened a file without the O_TRUNC: mode, as in the following example:show version | append disk#:Router#conf tEnter configuration commands, one per line. End with CNTL/Z.Router(config)#vtp file newSetting device to store VLAN database at filename new.Router(config)#^Z
2) The show disk slot-number and dir disk slot-number commands showed inconsistent information (such as inconsistent file sizes) when multiple images were copied. This problem occurred when you make two copies of the image file to the disk by using two vtys and by entering the dir disk slot-number command at the same time.
3) There were 2 symptoms for this problem:
•The show disk slot-number and dir disk slot-number commands may showed inconsistent information.
•Entering the fsck command deleted or truncated the valid files or created an orphan file for an unused cluster.
This problem occurred when you renamed a directory that consisted of many subdirectories or files.
4) There were two symptoms for this problem:
•There was a duplicate entry for each file when you entered the show disk slot-number command.
•An SNMP Get on a ciscoFlashFileSize object entered a loop.
This problem occurred on a router running Cisco IOS Release 12.3 T after the router booted up.
5) There were 2 symptoms for this problem:
•The show disk slot-number and dir disk slot-number commands may showed inconsistent information.
•Entering the fsck command deleted or truncated the original file.
This problem occurred on a router running Cisco IOS Release 12.3 T when an application or a CLI command overwrote a file on the disk.
6) A router running Cisco IOS Release 12.3 T reloaded. This problem occurred when an application created or opened a file without the O_TRUNC mode and attempted to delete the file, as in the following example:show version | append disk0:redirect.out" and issuingdelete disk0:disk0:redirect.out
Previously, a LAC sent incorrect connection speed information in the L2TP setup message to the LNS, which in turn was forwarded to the AR RADIUS server for authentication. Conditions: This problem occurred on a router running Cisco IOS Release 12.3(6.2)T2. This problem could also occur in other releases.
Previously, a Cisco router reloaded unexpectedly with a bus error when you entered the show caller command. This problem occurred when PPP was configured on a router running Cisco IOS Release 12.3, 12.3(3)B1, or 12.3 T. The problem was more likely to occur when the show caller output was lengthy, and particularly so if the output causes a ---More--- prompt. The problem was also more likely to occur when there was a high rate of connection and disconnection of PPP sessions, for example, when an interface flapped.
Previously, when virtual-access interfaces were created for PPP over ATM connections, the bandwidth set on the virtual-access interface was not correctly set to match the bandwidth of the underlying ATM virtual circuit. This in turn impaired other facilities that needed the bandwidth value for their own purposes.
Previously, a router reloaded unexpectedly with a bus error with the same address. The system was restarted by a bus error at PC 0x606B2BE4, address 0xB0D0C11. Decodes indicated that a PPP problem could be the cause of the symptom. This problem was not platform dependent and occurred with any type of IP PPP connection. This problem also occurred when there was a high volume of call connections and disconnections, for example, when an interface carrying multiple calls flapped.
Previously, the interface counters through Virtual Access sub interfaces on ATM OC3 and OC12 line cards, did not get updated when configured as SSG interfaces. The output of the show int vi interface command indicated the input and output counters could be zero when a subinterface was configured as SSG.
Previously, a Cisco router reloaded unexpectedly when a bgp debug command was enabled, and if IPv4 unicast was disabled for a BGP peer but there was vpnv4 configured with that same BGP peer. This problem occurred on a Cisco router running Cisco IOS Release 12.0S, 12.2S, or 12.3T.
Previously, when scaling to 128K PXF queues with a policer configured on all queues, the router's CPU utilization ran at approximately 48 percent of capacity. This problem occurred with 128K PXF queues configured on ATM interfaces
Previously, a Cisco router that was configured for SSG reloaded with a bus error. This problem occurred on a Cisco router that was configured for SSG and that had PPP SSG users when there were IPCP renegotiations on an active PPP session and a new IP address was assigned to the session.
Cisco Internetwork Operating System (IOS) Software release trains 12.1YD, 12.2T, 12.3 and 12.3T, when configured for Cisco's IOS Telephony Service (ITS), Cisco CallManager Express (CME) or Survivable Remote Site Telephony (SRST) may contain a vulnerability in processing certain malformed control protocol messages.
A successful exploitation of this vulnerability may cause a reload of the device and could be exploited repeatedly to produce a Denial of Service (DoS). This advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20050119-itscme.shtml
Cisco has made free software upgrades available to address this vulnerability for all affected customers.
This vulnerability is documented by Cisco bug ID CSCee08584.
Previously, a Cisco platform reloaded because of a watchdog timer expiration. This problem occurred on a Cisco platform running Cisco IOS Release 12.2(20)S2 or Release 12.3 under the following conditions: a service policy A was attached to an ATM PVC, policy map A was renamed to B, and service policy B was attached to the ATM PVC.
Previously, the idle-timeout command under Auto VC range disappeared upon reload of the router. This problem occurred when a Cisco 7200 series router with a PA-A6 and running 12.3(5a)B was reloaded.
Previously, the router did not respond to valid packet of disconnect (PoD) packets by disconnecting the user. Instead, the router returned a RADIUS-format packet with a Code of Disconnect-Request-NAKed (42 in decimal) and a Reply-Message attribute with a value set to the string "No Matching Session." This problem occurred when you used PoD to disconnect users, and have aaa pod server ... auth-type all ... configured, and used a PoD server that included an exact copy of RADIUS attribute 151 from an earlier accounting request in the PoD packet.
In RADIUS accounting packets, Cisco IOS generates attribute 151 values as a string of hexadecimal digits, corresponding to a 32-bit integer. When running an IOS version affected by this bug, the router IOS expects a copy of that 32-bit unsigned integer as a 32-bit unsigned integer, rather than as a string of ASCII characters representing a hexadecimal number. In Cisco IOS versions where the fix for this bug has been integrated, Cisco IOS will accept either the string which IOS sent out, or the 32-bit unsigned integer which unfixed versions accept.
Previously, when a match criteria for a class was changed in a class that was attached to an interface, the change was rejected even though it was valid.
Previously, on a Cisco 10000 series router running Cisco IOS Release 12.3(7)XI1, when configuring a service policy that contained a priority queue on a multilink interface the delay experienced by packets in queues other than the priority queue were sometimes very high. On MLPPP the delays experienced were as high as 2 seconds. When the same service policy was placed on a PPP or HDLC link the delays were acceptable.
Previously, a router that was configured for multicast routing could reload due to a bus error. This problem occurred on a Cisco router running a Cisco IOS software release that contains the fix for CSCec80252.
Previously, the router experienced a Spurious Accesses Violation when attempting to change an SSG service binding with live sessions under it.
Previously, a child policy bandwidth calculation was wrongly mixed with the specified rate of an old parent policy. This problem occurred after you changed the configuration of a policy map in a hierarchical policy.
Previously, with the command radius-server dead-criteria [time seconds] [tries number-of-tries] configured, the ALLDEADSERVER event was not sent when all servers were declared DEAD. This event was sent only after all servers had been re-tried for the configured number of tries.
Previously, the Cisco 10000 series router did not forward traffic after changing the PVC settings of CBR, VBR or UBR.
Previously, for PPPoX sessions, the Calling-Station-Id Radius Attribute (31) had to be filled with a customized field like: hostname.domainname:VPdescription:vpi:vci or hostname.domainname:VPdescription:macaddress. This problem occurred only for PPPoEoE, PPPoEoA and PPPoA (autodetecting and non-configurable) sessions.
Previously, if you configured or modified random detect parameters for a policy map that was already applied to an interface, the router displayed an error message. This problem occurred if the modified policy map was part of a hierarchical policy map configuration.
Previously, users were unable to authenticate using RADIUS, or accounting was not sent to the RADIUS server. In addition, when you entered the debug radius command, the following information was generated:RADIUS(00000049): sending%RADIUS-3-NOSERVERS: No Radius hosts configured.RADIUS/DECODE: parse response no app start; FAILRADIUS/DECODE: parse response; FAIL
The output of the show running-config command indicated that there were in fact RADIUS servers in the server group.
This problem occurred after following these steps:
1. Remove and recreate a server group that was still referenced by one or more method lists, by entering the following commands:no aaa group server radius XXXXaaa group sever radius XXXXserver x.x.x.x ...
2. Allow one of these method lists to be used, causing a transaction to be sent to a RADIUS or TACACS+ server in the server group.
3. Remove and re-add the radius-server host ... command lines for all authentication-capable (or accounting-capable if this group is used for accounting) servers in this server group.
If you entered the debug aaa sg-ref-count command before Step 2 a debug message similar to the following one was generated: AAA/SG: Server group ref count decoalesced sg_type for public group XXXX and is reduced by 2 to 0.
Previously, when vpdn authen-before-forward and aaa authorization network default local group radius were configured, a second unwanted access request for authorization was sent.
Previously, if the SAR page limit was reached while you were creating ATM PVCs, the router continued to create ATM PVCs but they were inactive. This problem has been fixed so that the router checks the SAR page limit before creating an ATM PVC. If the SAR page limit has been reached, a message displays indicating that there are no more SAR pages available for the PVC.
Previously, AAA server counters, private and global, were not cleared. The AAA server counters were not reset to 0 (zero) when the clear aaa counters servers radius all command or clear aaa counters servers all command was issued.
Previously, clearing the counter did not clear the police counter in a Virtual-Access interface. This problem occurred when you attached an input police policy map under a Virtual-Template, attached an output cbwfq policy map under an ATM subinterface, sent traffic, and then cleared the counter.
Previously, if you reloaded the peer router (containing 768CGs MLPPP configuration in startup-config) while the traffic was flowing over the configured bundles, upon reload the configured interface remained in an up/down state, and bundles in a down/down state. Additionally, the router log indicated traceback and IPC failure messages.
Previously, a router sent 3 access requests for 1 call session: the first request was the normal request, the second request had the right password but the wrong user name, and the third request had just the domain name as the user name. This problem occurred with a call rate condition of above 20 calls per second and occurred randomly for a view call sessions only.
Previously, when traffic engineering tunnels were active, issuing the show pxf cpu statistics drop tunnel command caused the following traceback message to appear:*May 31 20:12:04.947: %GENERAL-3-EREVENT: pxf_drop_interface: No c10k_tt_hwdb -Traceback= 60D8F458 60D8BD98 60D8D9BC 603B322C 601404D0 603CD1B4 6045DD88 6045DD6C PE-1#
Previously, the debug condition username command did not filter as expected. This problem occurred on Cisco 10000 series routers running a Cisco IOS 12.2.16BX2a based release.
Previously, in Lawful Intercept mode, the intercept stream sometimes was not deleted after the configured time to live (TTL) expired. This problem occurred if the TTL value was changed while the intercept was active.
Previously, when a new bandwidth value was assigned using the bandwidth x command to an interface configured with hierarchical policy maps, the child QoS policy map (if configured with percentage values) incorrectly showed the earlier allocated bandwidth value and the new value assigned was not reflected in the child QoS policy map. This problem occurred only when changing the bandwidth value of the interfaces.
Previously, the radius-server attribute 4 NAS IP address attribute was not accepted This problem occurred when you tried to configure RADIUS attribute 4.
Previously, when changing the MTU of a serial interface on a CH-OC12 or CH24E1T1 line card, the optional sizes provided was in the range 64-17940. This was not correct. The correct range should have been 64-9108. If you changed the MTU to a value greater than 9108, the following error appeared:%GENERAL-3-EREVENT: c10k_ttcm_icb_update: attempt to set max_mtu to 9320 , overriden to 9216-Traceback= 60D24E68 60D28294 6011B36C 60423510 604241A0 603B3110 601405A8 603CD098 6045DD30 6045DD14
example:router(config-if)#int s3/0/23:0router(config-if)#mtu ?<64-17940> MTU size in bytesrouter(config-if)#mtu 9200router(config-if)#*Jun 8 16:45:50.950 EDT: %GENERAL-3-EREVENT: c10k_ttcm_icb_update: attempt to set max_mtu to 9320 , overriden to 9216-Traceback= 60D24E68 60D28294 6011B36C 60423510 604241A0 603B3110 601405A8 603CD098 6045DD30 6045DD14router(config-if)#router(config-if)#
Previously, on a Cisco 10000 series router configured as PTA device, some very small amount of memory was not released as PPP sessions were brought up and torn down. This problem caused the router to run out of memory after a long period of time.
Previously, PPP sessions got stuck in the TERMSENT state. This problem occurred on a Cisco platform that has a high CPU utilization.
Previously, the following errors appeared when setting up 31,500 PPPoX sessions on a PRE2 as LAC with DBS enabled:Jun 9 12:34:48.520: %C10KATM-3-DBS: C10K internal DBS error, DBS: modify() failure: validation of params unsuccessful(1) ATM3/0/0 2277 1/2377 -Traceback= 600878C0 60162C30 60C6C344 60C6C4D8 60C68348 60C6ACE8 60C6B2EC 60C63094Jun 9 12:34:48.524: %ATM-3-FAILMODIFYVC: ATM failed to modify VC(VCD=2277, VPI=1, VCI=2377) on Interface ATM3/0/0, (Cause of the failure: Failed to have the driver to modify the VC)Jun 9 12:34:48.524: %C10KATM-3-DBS: C10K internal DBS error, DBS: modify() failure: vali dation of params unsuccessful(1) ATM3/0/0 2277 1/2377 -Traceback= 600878C0 60162C30 60C6C344 60C6C508 60C6989C 60C60F00 60C6B1A8 60C6B2EC 60C63 094Jun 9 12:34:48.524: %C10KATM-3-DBS: C10K internal DBS error, DBS: modify() failure: vali dation of params unsuccessful(1) ATM3/0/0 2279 1/2379
The result was that QoS parameters that should be derived from RADIUS via DBS were not set for some ATM VCs.
Previously, the class attribute was not sent in prepaid authorization requests for PPP users. This problem occurred in all releases after 12.3(2)T.
Previously, after the installation of an IPCP negotiated IP address, the peer IP address was missing from various show commands, such as the show user and show caller ip commands. The actual IP address and the IP route were installed correctly. This problem occurred whenever an IPCP negotiated IP address was installed. The data was removed after being used, but it should have been retained for display purposes.
Previously, All SWIDBs were used. This problem occurred when PPPoE or VPDN sessions flapped continuously.
Previously, the ATM line card experienced a crash when there was a lot of change activity going on (VCs being added and deleted). On the Cisco IOS console, messages similar to the following appeared:#sh log Jun 16 15:19:00.423 BST: %SYS-5-CONFIG_I: Configured from console by provuser on vty2 (address deleted) Jun 16 15:56:56.961 BST: %IPCGRP-3-SYSCALL: System call for command 405 (slot3/0) : ipc_send_rpc_blocked failed (Cause: timeout) -Traceback= 6053D6BC 6053D994 6053DB50 60096EAC 60083294 60164CC8 60DB8FB4 60DB96F0 60DB9BE8 Jun 16 15:57:02.962 BST: %IPCGRP-3-SYSCALL: System call for command 401 (slot3/0) : ipc_send_rpc_blocked failed (Cause: timeout) -Traceback= 6053D6BC 6053D994 6053DB50 60096EAC 60083294 60164CC8 60DB8FB4 60DB96F0 60DB9BE8 Jun 16 15:57:03.962 BST: %IPCOIR-3-TIMEOUT: Timeout waiting for a response from slot 3/0. Jun 16 15:57:03.962 BST: %IPCOIR-2-CARD_UP_DOWN: Card in slot 3/0 is down. Notifying 4oc3atm-1 driver. Jun 16 15:57:03.962 BST: %IPCGRP-3-CMDOP: IPC command 401 (slot3/0): line card ipc is disabled - dropping non-blocking ipc command -Traceback= 6053D940 6053E410 Jun 16 15:57:05.970 BST: %LINK-3-UPDOWN: Interface ATM3/0/1, changed state to down Jun 16 15:57:08.362 BST: %LINK-3-UPDOWN: Interface ATM3/0/0, changed state to down Jun 16 15:57:08.786 BST: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM3/0/1, changed state to down Jun 16 15:57:09.362 BST: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM3/0/0, changed state to down Jun 16 15:57:14.123 BST: %IPCOIR-5-CARD_DETECTED: Card type 4oc3atm-1 (0x2D8) in slot 3/0 Jun 16 15:57:14.123 BST: %IPCOIR-5-CARD_LOADING: Loading card in slot 3/0 Jun 16 15:57:15.315 BST: %C10K-5-LC_NOTICE: Slot[3/0] 4oc3atm-1 Image Downloaded...Booting... Jun 16 15:57:37.124 BST: %IPCOIR-5-CARD_DETECTED: Card type 4oc3atm-1 (0x2D8) in slot 3/0 Jun 16 15:57:37.124 BST: %IPCOIR-2-CARD_UP_DOWN: Card in slot 3/0 is up. Notifying 4oc3atm-1 driver. Jun 16 15:57:50.161 BST: %LINK-3-UPDOWN: Interface ATM3/0/0, changed state to up Jun 16 15:57:50.421 BST: %LINK-3-UPDOWN: Interface ATM3/0/1, changed state to up Jun 16 15:57:51.201 BST: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM3/0/0, changed state to up Jun 16 15:57:51.421 BST: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM3/0/1, changed state to up Jun 16 16:19:04.759 BST: %IPCGRP-3-CMDOP: IPC command 405 (slot3/0): waiting for a keepalive -Traceback= 6053D6BC 6053D994 6053DB50 60096EAC 60083294 60166834 601637E8 60DB8E90 60DB9A14 60DB9BE8(display text omitted)
On the line card console the following appeared:#if-con 3/0 Connecting console for slot 3/0 Type "^C^C^C" or "if-quit" to end this session log dump ----- Start of console log ----- oc3atm-3/0> FPGA: fatal FPGA interrupt encountered (0x00000010) ASSERT Failed: in ../src-c10k-atm/ocXatm_fpga.c::fpga_int_handler() L1407 backtrace: 8000CCA4 80008334 8003A754 80007880
Previously, the router experienced a CPUHOG when querying the cbQosQueueingCfgBandwidth MIB variable. This problem occurred in a Cisco 10008 (PRE2) with 28K ATM PVC configured when querying with snmpbulkwalk or snmpwalk.
Previously, a router could reload if an NM-CEM-4TE1 and an NM-2CE1T1-PRI/NM-1CE1T1-PRI were used on the same router.
Previously, the ability to configure CDVT in PVC and PVC-in-Range mode was not available. This problem occurred while configuring a VC in PVC mode or in PVC-in-Range mode.
Previously, with broadband queue scaling with an input police policy on virtual-template and output CBWFQ policy on ATM 31,500 subinterfaces was configured, and then the output policy was removed, an XCM access error message occurred continuously. This problem occurred with broadband queue scaling with input and output policies configured, and then the output policy was subsequently removed.
Previously, Cisco IOS could crash when receiving a malformed PPPoE packet. Without having a PPPoE configuration on the router, the router could crash if it received a PPPoE session Packet (0x8864) with Session ID = 0. This problem occurred on a Cisco 10000 series router running the 12.3(7)XI image.
Previously, error messages that occurred during bandwidth oversubscription with ATM PVPs did not contain information for which interfaces or features were oversubscribed. Messages indicated the peak rate exceeding the available bandwidth Link oversubscribed by 92240 kbps. The error messages occurred when the sum of ATM PVP Peak Cell Rates exceeded the interface bandwidth.
Previously, with SSG configured, VPDN parameters were locally provisioned but VPDN tunnels were not established between the LAC and the LNS. SSG VPDN services were not working.
Previously, the following errors appeared when starting up 31,500 PPPoX sessions at 5 CPS on a PRE2 as PTA with SSG auto-logon configured:*Jul 7 10:05:38.602: SSG-CTL-ERR: Unable to add HostRoute in CEF table x.x.x.x *Jul 7 10:05:38.602: SSG-CTL-ERR: host route addition failed *Jul 7 10:05:41.770: SSG-CTL-ERR: Unable to add HostRoute in CEF table x.x.x.x *Jul 7 10:05:41.770: SSG-CTL-ERR: host route addition failed
The result was that the Active HostObject Count in sho ssg host output did not match the ConnectionCount in sh ssg serv output. There was no upstream traffic on these lost connections.
Previously, an unexpected spurious memory access error occurred when executing a show atm command.
Previously, Cisco IOS Release 12.3(9.11) and later releases displayed an INVALIDTCB error message on the terminal after exiting a telnet session. This problem did not affect router functionality.
Previously, under load conditions with a high number of PPP sessions in transit, a traceback in the ipigrp2_network_command displayed.
Previously, the "%ATM-3-FAILCREATEVC: ATM failed to create VC" and "Attempting to over-subscribe tunnel bandwidth" messages were erroneously logged upon deletion and addition of VCs and VPs (hierarchical traffic shaping).
Previously, an SNMP trap was not received. The DS3 line status object did not change.
Previously, a performance degradation occurred when VP and VC shaping were configured on the same interface. Output drops occurred at the SAR level and affected the established PPPoX sessions. This problem occurred with a configuration that included shaped VPs (hierarchical traffic shaping), as well as VC's not mapping to any of the shaped VPs all configured on the same interface.
Previously, the PVC weight configurable parameter was not visible under the show atm pvc or show atm vc command. This problem occurred when configuring the weight parameter of a VC mapping to a shaped VP (hierarchical traffic shaping).
Previously, the CPU stayed at 100 percent utilization after a session was cleared. This problem occurred with 1000 VLANs and 32k sessions and 32 sessions per VLAN, clearing sessions while traffic was being sent over the sessions.
Previously, ATM common code needed to classify VCs traffic-class versus rate change for Cisco 10000 series router platforms because they did not allow dynamic modification of the ATM QoS Traffic Class.
Previously, there were traceback messages and malloc failures while running MLPPP regressions.This problem occurred when a bundle was bounced for some reason during high traffic. When this problem occurred, a CRITEVENT appeared in the log and the message "IPC Bundle Flush Failure" appeared.
Previously, some memory was lost when you configured and removed several Multilink PPP interfaces. This problem led to buffer exhaustion over time and required a reload of the router.
Previously, when a service policy configured with the police percent command was applied onto a Virtual-Access interface bound to a shaped PVC, the calculated police class bandwidth was not based on the PVC rate but on a 100 Mbps value.
Previously, accounting of input packets/bytes was not happening correctly. When a client was connected to SSG and further on to a service linked via a gigabit Ethernet uplink subinterface, on an extended ping from client to service, the accounting of input packets/bytes was erroneous. The same result was reflected in output of the RADIUS accounting logs.
Previously, a traceback message appeared when trying to log in an rfc1483 SSG host to a service over a gigabit Ethernet uplink. With a gigabit Ethernet uplink interface to the services, when an rfc1483 SSG host tried to log in to the service, a traceback message appeared.
Previously, when changing the parameters of a VC class on an active PVC, a number of PVCs became locked in an INAC state while viewing PVC status using the show atm vc interface atm interface command. The following type of message appeared in the log:%ATM-3-FAILREMOVEVC: ATM failed to remove VC(VCD=X, VPI=X, VCI=X) on Interface ATM X/X/X, (Cause of the failure: PVC removal during recreation failed)
Previously, an ACL had no effect even though it was configured. In show pxf cpu statistics security, packets were neither denied nor permitted. In show pxf cpu context, there were no feedback packets. The ACL had to be split. In show pxf cpu access-list security, the value of the table column had to be greater than 1 to have a split ACL.
Previously, when a router had over 100 BGP peers, traceback messages appeared on the console after an RPR+ switchover. The system recovered and normal activities were resumed afterwards. This problem occurred only when the router had over 100 BGP peers and a switchover was performed.
Previously, adding a new T1 on a 4OC3-CHSTM1 line card caused all other existing T1 lines on same STS to flap. Corresponding serial interfaces also flapped. All T1 lines then recovered by themselves. This problem did not occur when SDH framing, Au-4-tug-3,mode C-12 were used. This problem occurred under normal operational conditions for both HDLC and PPP encapsulation on serial links.
Previously, if Multilink PPP was configured, Quality of Service (QoS) did not function properly when using a strict priority queue with other bandwidth queues. This problem occurred when the traffic sent to the priority queue exceeded the configured policer bandwidth. All traffic was forwarded through the priority queue regardless of the policer configuration, which had a negative effect on the effective bandwidth of the other queues.
Previously, PPPoX sessions failed to connect on an ATM interface with the following error message logged on the console port:XCM access error at../toaster/c10k_rp/c10kds2_qos.c (4874)
This problem occurred when several thousand QoS service policies were applied on the ATM PVCs.This problem potentially cause the active PRE2 to crash if the ATM PVCs were configured as create on-demand and the idle-timeout was enabled.
Previously, when a router had over 8000 PPPoEoQinQ active sessions and input and output policing applied to all subinterfaces, the router reported a spurious memory access after you executed the microcode reload pxf command. This problem occurred only when the microcode reload pxf command was executed.
Previously, on Cisco 10000 series routers running as PTA and terminating 31,500 PPPoA sessions, the router could run out of I/O memory when communications to the RADIUS server was lost and PPPoA sessions continued to be established. This problem occurred when the router could not communicate with the RADIUS server.
Previously, with Q-in-Q configured on the subinterfaces, policy maps applied to the main interface were not inherited by the subinterfaces. This problem only affected subinterfaces configured with Q-in-Q. Policy maps applied to the main interface were not inherited by the subinterfaces.
Previously, when booting up an 8e3ds3 ATM line card, 8 of the following messages appeared in the syslog: Failed to assert Physical Port Link Down alarm for ATMx/x/x.
Previously, during the reload of a primary PRE2, the standby PRE2 logged numerous messages indicating that SNMP interface indices were exhausted. These messages displayed on the console log for the standby PRE2, and were also logged to a syslog server, if used. There could also be another error message and traceback in the standby PRE2 log indicating that the SONET MIB was not initializing:%IFINDEX-4-NOIFINDEX: All SNMP if indices are exhausted %C10KATM-3-MIBINITFAIL: Sonet MIB initialization failed, ATM7/0/3 2-Traceback= 6007D5C4 6007F304 6009E5F8 60543224 6054A14C 603B468C 603CC044 603CC220 603CC384 603CC428 604B9798 604B4934 604AEA20 604B6AB4 604B6CA0 601343C4
These error messages occurred only on the standby PRE2 and appeared only when the router reloaded. The router continued to function normally, for example, when the standby PRE2 was fully booted up to become primary, traffic and management functioned properly.
Previously, the input traffic for PPPoEoE sessions was not displayed when the show int gi command was executed. The output rate was displayed.
Previously, a CPU hog message was generated when you executed the show pppoe summary command. This problem occurred when there were high-scaling unambiguous QinQ sessions and interfaces configured.
Previously, traffic did not go through when authen-before-forward was configured on UUT with default search order. This problem occurred on a Cisco 7200 series router running 12.3(10) images.
Previously, the DS3-MIB dsx3LineType shows as dsx3other for full rate t3 on 6ct3, 1choc12 and 4chstm1 au-3 mode c-3 with cbitparity. This problem occurs when using the SNMP DS3-MIB to get the line type for full rate T3.
Previously, on a Cisco 10000 series router running Multi-Router Automatic Protection Switching (MRAPS), the 4-port ChSTM1 line card crashes when the controller port is in physical loopback. This problem occurs on a router running the 12.3(7)XI image.
Previously, when applying new VC class parameters to the existing established PPPoEoA session, the virtual-access values for the session remained unchanged until the VC virtual-access interface was removed and added back to the configuration. This problem occurred during modification of VC class ATM PVC parameters on a VC over which a PPPoEoA session was established.
Previously, there was a timing violation in the PRE2/PRE1 temperature sensor routine. Because the temperature sensor routines violated timing requirements, the temperature reading failed in a new device from a new vendor.
Previously, the output of the show pxf cpu queue interface command was stuck in an infinite loop when VCs were configured on that interface. You could not track the output queues for the specified interface, and you had to use a different telnet session to continue using the device.
Previously, Some PVCs on a router acting as a LAC and also terminating PTA became locked. This problem occurred after the primary PRE2 was pulled from the chassis several times.
Previously, the counters displayed with the show policy-map interface virtual-access command could be invalid and return negative rate values, especially when modifying the policy map parameters.
Previously, a specifically crafted Transmission Control Protocol (TCP) connection to a telnet or reverse telnet port of a Cisco device running Internetwork Operating System (IOS) could block further telnet, reverse telnet, Remote Shell (RSH), Secure Shell (SSH), and in some cases Hypertext Transport Protocol (HTTP) access to the Cisco device. Telnet, reverse telnet, RSH and SSH sessions established prior to exploitation were not affected. All other device services operated normally.
This problem occurred if you initiated a specially crafted TCP connection to a telnet or reverse telnet port, which resulted in blocking further telnet sessions. Services such as packet forwarding, routing protocols, and all other communication to and through the device remained unaffected.
Previously, the chassis reset while modifying the running configuration with service compress-config enabled The L2 Watchdog timeout occurred after 4-24 hours of consistent running-config modifications and write-mem (~ 80 per hour).
Previously, you could not change the VP rate without VC teardown.
Previously, the input rate counter of the virtual access interface belonging to PPPoEoE of Gigabit Ethernet was not displayed when the sh int virtual-access command was executed. The output rate was displayed.
Previously, the primary PRE2 experienced a software forced crash due to memory corruption. This problem occurred with a Cisco 10000 series router connected to a 6400 via 8 unprotected OC3 ATM connections and 4 APS protected connections. The crash occurred when the working 4-port ATM linecard in the Cisco 10000 series router was reset using the hw-module slot 7 reset command.
Previously, as part of nas-port feature extensions in DDTS CSCee08931, format D was modified to include the Session-id in the 24 least-significant bits. Further discussion with devtest and PPPoX groups concluded that this change was inappropriate for format D, because it would cause more confusion than solve any problem. As such, this change was backed out.
Previously, a router reloaded when it attempted to access a TACACS+ server. This problem occurred when the TACACS+ server was not up or was unreachable.
Previously, when configuring more than 128,000 queues, "cannot create default queues" messages were displayed.
Previously, after a PXF crash the per User statistics for L2TP sessions active at the Cisco 10000 series router acting as a LAC were much to high. This affected only very few sessions out of a couple of thousand.
Previously, when configuring an ATM interface, under pvc-in-range mode, the queue depth and weight options were not available.
Previously, the show pxf cpu police command caused a console hang or system crash. This problem occurred when a Virtual template, with sessions, and the same service policy was configured on both input and output. If you changed the input service policy and then changed the output service policy, executing the show pxf cpu police command caused a console hang or system crash.
Previously, the router experienced a software forced crash when executing the show atm vc interface command and at the same time changing the class on several VCs. This problem occurred when VCs are configured for create on-demand.
Previously, a Multilink interface was in a down/down state. All MLPPP member interfaces were in an up/up state. This problem occurred right after the Multilink interface was created or the member interfaces changed state to up/up. There were no queues associated with the Multilink interface. This could confirm using the show pxf cpu queue multilink number command. The system log also had following message: "Cannot attach bundle FIFO".
Previously, the router reloaded upon clearing the PPPoEoA session when MQC with fair queue was configured on the ATM VC and a pulled policy is rejected.
Previously, it was not possible to configure a VC weight to a value less than 5. The weight controls how many cells the VC can send into the VP tunnel before the SAR moves to the next VC. It is only applicable when shaped VPs are configured. A weight of 5 limited the dynamic range of bandwidths the VCs within a VP could get, but it helped ensure the ATM port could reach line rate performance. Lowering the weight increased the dynamic range and allows better delay characteristics, at the expense of significant degradation relative to line rate performance for some configurations.
Previously, the PRE2 as PTA/PE was not able to setup more than +/- 21500 PPPoA sessions due to a leak in rewrite strings. This problem occurred when the following features were enabled: MPLS/VPN + HDVRF, DBS, output policy per VC, input policy via RADIUS, no PVC range, create on-demand, auto encapsulation, mini ACLs on all sessions, and hierarchical shaping.
Previously, SSG authentication and accounting requests were sent with nas-port-type = Ethernet.
Previously, the in range pvc mode output policy was incorrectly accepted with MLPPPoATM
Previously, a Cisco 7200 series router with an ATM PA-A3 might crash when ATM PA-A3 was OIR removed. This problem occurred when dynamic VC modification was enabled on the interface using the dbs enable command and the ATM PA-A3 is OIR removed.
Previously, you could not recreate PPPoE sessions after removing a PVC range on an interface and then reinserting the same PVC range on that interface.
Previously, on a Cisco 10000 series router using Multilink PPP interfaces, control packets such as keepalives and routing updates were dropped when the interface was congested. This problem occurred only on congested MLPPP links.
Previously, removing the vbr-nrt parameter from the VC class did not change the attributes of the existing PVCs correctly. Changing a parameter in the VC class did not recreate the PVCs and so they did not acquire the new parameters. If they were infinite range VCs, removing and re-adding "create on-demand" brought up the PVCs up with the new attributes.
Previously, an MLP member could not pass IP traffic after having been added back to the bundle. This problem occurred only with the PRE2.
Previously, changing the ATM over subscription factor dynamically, with active VCs on the interface, caused all the VCs to go down and become permanently inactive.
Previously, the following traceback messages were displayed on the Cisco 10000 series router:*Sep 24 20:35:57.035: -Traceback= 60D1DB6C 60D67FB8 60DA70C4 60DA6CF4 60C68020 6 0C5E618 60847618 6084411C 6083A760 60847168 60420B00 6001A2E8 6003CE20 60C6C770 60C6C988 60517474*Sep 24 20:35:57.035: Illegal attempt to direct read from PXF memory in an interrupt context.
Previously, the router generated line status change traps for an interface with errors continuously, even though it was not flapping or experiencing any state transitions.
Previously, if a create on demand PVC that was initially configured as part of range was changed to a pvc-in-range (with a vc-class change as well), the VC remained inactive and a traceback message was displayed.
Previously, in a network topology where thousands of PPPoX clients were disrupted on an L2TP LAC, there was the opportunity for client traffic to have null or zero session IDs. This condition caused an LNS router to reload and display the message, "*** System received an abort due to Break Point ***."
Previously, when running Multilink PPP (MLPPP), traceback error messages appeared on the router's logging buffer when member links were removed from the MLPPP bundle on the neighbor router. This problem occurred only when the neighbor router removed member links.
The traceback error message displayed was:*Sep 30 16:21:49.059: %GENERAL-3-EREVENT:diverted MLP packet's bundle vcci 2 has invalid master idb-Traceback= 60EBA164 60DAF224 60EB0EDC 60EA9BD4 60EA5980 60517668 604862FC
Once this message appears, all outgoing local traffic is dropped.
The configuration was: MLPPP was configured on 2 different channelized T3 (CT3) line cards. 2 T1s were configured on one T3, and 2 T1s were configured on another T3 but on a different line card. These 4 T1s were in the same multilink group. Multilink fragmentation was disabled.
Previously, when a PRE2 failed with this configuration, traffic forwarding through the MLPPP T1 circuits took over 70 seconds to start forwarding traffic on the new PRE2.
If these 4 T1s were configured on the same T3 port or on different T3 ports but on the same CT3 card, the failover recovery time was a lot quicker for traffic to be forwarded again (less than 20 seconds is typical). This indicated something was broken with RPR+ in this configuration.
When using a PRE1 with 12.0(27)S and doing this same test of configuring T1s across multiple CT3 line cards, RPR+ seemed to work. Failover time was approximately 20 seconds.
Previously, some Multilink PPP member links went up/down after an MR-APS switchover. This problem occurred with T1 interfaces over a 4CHOC3 line card on the Cisco 10000 series router. The T1 Multilink PPP member links were going up/down after a couple of MR-APS switchovers.
Previously, some PPP interfaces were up/down before and between MR-APS switchovers. This problem occurred with the 4CHOC3 line card on the Cisco 10000 series router, on both the MR-APS Working and Protect ports.
Previously, on a Cisco 10000 series router running Cisco IOS Release 12.3(7)XI1, some PPPoA sessions did not come up after a router reload if the PVC range was high.
Previously, a service policy was not applied on a VC. This problem occurred when a QoS configuration depended on the DBS AV pair that was applied by AAA code after the policy AV pair.
Previously, MPLS core routers did not establish LDP neighbors to directly connected routers even though the routers were able to ping each other's router_id IP address. In the show mpls ldp discovery command, LDP only had transmit instead of both transmit and receive to the neighbors. This problem occurred when OSPF was in the core and between PE/CE routers.
Previously, on a Cisco 10000 series router running Cisco IOS Release 12.3(7)XI1, input and Giant errors occurred on the serial T1 interfaces when running MR-APS on a 4-port channelized STM-1 line card. Giants incremented continuously even when fiber was pulled from an OC3 port or if the inactive (protect) OC3 was up/down.
Previously, hanging the queue depth parameter on a VC with active PPP sessions and bidirectional traffic distorted the counters on a VAI. Virtual Access interface input packet and byte counters were unusable.
Previously, a standalone auto VC came up after a reload. The state machine at reload was behaving differently and led to further complications.
Previously, the subscribed bandwidth for ATM VCs was not calculated properly.
Previously, a system crash occurred when adding a class map to a policy map. This problem occurred when the virtual-template interface had a service policy that was the same as the physical interface, but configured for the reverse direction, and there were active sessions. Adding or removing a class map from the policy map caused a system crash.
Previously, the SAR counter was not decrementing while removing a PVC range.
Previously, support for shaped UBR VCs under atm pxf queueing was not working.
Previously, when attempting to bring up a multilink bundle, the bundle interface got stuck in a state where it continued to bounce up and down. This problem occurred when attempting to bring up large numbers of multilink interfaces at the same time. For instance, initiating a PXF reload caused this problem to occur.
Previously, PPP could hang after an LCP renegotiation on a serial interface.
Previously, the command to set the weight was not available in vc mode or in pvc-in-range mode. Also, the weight had a minimum value of 5.
Previously, the show l2tun command needed large contiguous memory (64MB/128MB) to display 16,000/32,000 sessions.
Previously, when a server group was reconfigured while there was an active transaction, that transaction went into an infinite loop.
Previously, the LAC could crash when 8,000 or more PPPoA/LT2P sessions were retrying to connect all at the same time after the LNS and user had all their sessions cleared. The LAC crashed only under low memory conditions.
Previously, traceback messages were reported when doing the following show commands on the POS interface configured with frame-relay encapsulation: sh pxf cpu queue POS x/y/z sum and sh pxf cpu queue POS x/y/z.a sum. The tracebacks were reported only if the subinterfaces were without DLCI configuration.
Previously, PPP sessions for SSG users went down immediately after coming up. This problem occurred when the virtual-template was configured as a downlink interface with the ssg direction downlink command. The PPP session went down immediately after IPCP came up.
Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain 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:
You can access the Cisco website at this URL:
International Cisco websites can be accessed from this URL:
You can find instructions for ordering documentation at this URL:
You can order Cisco documentation in these ways:
•Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Ordering tool:
•Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
You can submit e-mail comments about technical documentation to firstname.lastname@example.org.
You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Obtaining Technical Assistance
For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, the Cisco Technical Assistance Center (TAC) provides 24-hour-a-day, award-winning technical support services, online and over the phone. Cisco.com features the Cisco TAC website as an online starting point for technical assistance. If you do not hold a valid Cisco service contract, please contact your reseller.
Cisco TAC Website
The Cisco TAC website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The Cisco TAC website is available 24 hours a day, 365 days a year. The Cisco TAC website is located at this URL:
Accessing all the tools on the Cisco TAC website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a login ID or password, register at this URL:
Opening a TAC Case
Using the online TAC Case Open Tool is the fastest way to open P3 and P4 cases. (P3 and P4 cases are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Case Open Tool automatically recommends resources for an immediate solution. If your issue is not resolved using the recommended resources, your case will be assigned to a Cisco TAC engineer. The online TAC Case Open Tool is located at this URL:
For P1 or P2 cases (P1 and P2 cases are those in which your production network is down or severely degraded) or if you do not have Internet access, contact Cisco TAC by telephone. Cisco TAC engineers are assigned immediately to P1 and P2 cases to help keep your business operations running smoothly.
To open a case by telephone, use one of the following numbers:
Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447
For a complete listing of Cisco TAC contacts, go to this URL:
TAC Case Priority Definitions
To ensure that all cases are reported in a standard format, Cisco has established case priority definitions.
Priority 1 (P1)—Your network is "down" or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.
Priority 2 (P2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.
Priority 3 (P3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.
Priority 4 (P4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.
Obtaining Additional Publications and Information
Information about Cisco products, technologies, and network solutions is available from various online and printed sources.
•Cisco Marketplace provides a variety of Cisco books, reference guides, and logo merchandise. Go to this URL to visit the company store:
•The Cisco Product Catalog describes the networking products offered by Cisco Systems, as well as ordering and customer support services. Access the Cisco Product Catalog at this URL:
•Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press online at this URL:
•Packet magazine is the Cisco quarterly publication that provides the latest networking trends, technology breakthroughs, and Cisco products and solutions to help industry professionals get the most from their networking investment. Included are networking deployment and troubleshooting tips, configuration examples, customer case studies, tutorials and training, certification information, and links to numerous in-depth online resources. You can access Packet magazine at this URL:
•iQ Magazine is the Cisco bimonthly publication that delivers the latest information about Internet business strategies for executives. You can access iQ Magazine at this URL:
•Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:
•Training—Cisco offers world-class networking training. Current offerings in network training are listed at this URL:
Copyright © 2004 Cisco Systems, Inc. All rights reserved.