Table Of Contents
Release Notes for Cisco Service Control Operating System, Release 3.1.7
Functional Enhancements—Cisco SCE8000 Only
Simple Network Timing Protocol
Management Interface Configuration
Resolved Issues in Release 3.1.6
Identifying Subscribers per VLAN ID and IP
Flexible Subscriber Introduction
Resolved Issues in Releaser 3.1.5
Resolved Issues in Release 3.1.1
Unidirectional Classification for Support of Asymmetric Routing
Subscriber Synchronization in Cascade Setups
Resolved Issues in Release 3.1.0
Open Caveats—Cisco SCE 1000 and Cisco SCE 2000
Obtaining Documentation and Submitting a Service Request
Release Notes for Cisco Service Control Operating System, Release 3.1.7
Revised: September 15, 2009, OL-14438-14These release notes for the Cisco Service Control Operating System describe the functional enhancements and fixes provided in Cisco Service Control Operation System (SCOS) Release 3.1.7. These release notes are updated as needed.
For information regarding the features of the Cisco SCE8000 platform, refer to the Release Notes for Cisco Service Control Operating System Release 3.1.6S and Cisco Service Control Application for Broadband Release 3.1.6 with Cisco SCE8000.
For a list of caveats that apply to Cisco SCOS Release 3.1.7, see the "Open Caveats" section. Some caveats apply only to the Cisco SCE8000, some apply to the SCE 2000 or SCE 1000, while others apply to all SCE platforms.
Supports SCOS Release 3.1.7, SCOS Release 3.1.6, SCOS Release 3.1.5, SCOS Release 3.1.1, and SCOS Release 3.1.0.
•
Obtaining Documentation and Submitting a Service Request
Introduction
Cisco SCOS (Service Control Operating System) Release 3.1.7:
•
Functions on SCE platforms.
•
Is a maintenance release of SCOS Release 3.1.0.
•
Includes functional enhancements and fixes for issues that were identified during ongoing internal testing and customer interaction.
This document outlines the functional enhancements and resolved issues delivered in SCOS Release 3.1.7. It assumes the reader has substantial knowledge of the Cisco Service Control solution. For additional information, refer to the Cisco Service Control Engine documentation.
To access the new Cisco Service Control online documentation site, do the following:
1.
At Cisco.com, go to:http://www.cisco.com/cisco/web/psa/default.html?mode=prod
2.
From the Products list, select Service Exchange.
3.
From the list that appears, select Cisco Service Control.
4.
From the list that appears, select a Cisco Service Control product.
SCOS Release 3.1.7
•
Functional Enhancements—Cisco SCE8000 Only
Compatibility Information
You can install SCOS Release 3.1.7 on the following service control engine platforms:
•
Cisco SCE8000
•
Cisco SCE 2000 4 x GBE
•
Cisco SCE 1000 2 x GBE (2-U only)
SCOS Release 3.1.7 is not compatible with the following service control engine platform:
•
Cisco SCE 1000 2 x GBE (1.5 U)
Functional Enhancements—Cisco SCE8000 Only
•
Simple Network Timing Protocol
•
Management Interface Configuration
The following section lists the functional enhancements in SCOS release 3.1.7. These apply to the Cisco SCE8000 platform only. For more information regarding these features, see the Cisco Service Control Engine Software Configuration Guide.
High Availability
When redundancy and failover are required in a deployment, a topology with two cascaded SCE platforms is used. This cascaded solution provides both network link failover and failover of the functionality of the SCE platform, including updated subscriber state.
In SCOS Release 3.1.7, the cascade functionality is implemented on the Cisco SCE8000 platform
Simple Network Timing Protocol
The Simple Network Timing Protocol (SNTP) is a simple solution to the problem of synchronizing the clocks in the various elements of the network. SNTP provides access to a time source through the network. The system clock and calendar are then set in accordance with this external source.
In SCOS Release 3.1.7, the SNTP functionality is implemented on the Cisco SCE8000 platform.
Management Interface Configuration
The CLI for the management interface (GigatbitEthernet1/1) allows you to set the speed and duplex.
In SCOS Release 3.1.7, this CLI functionality is implemented on the Cisco SCE8000 platform.
Resolved Issues
•
Resolved Issues—All Platforms
Resolved Issues—All Platforms
CSCsj48885
The SCE was sometimes forced to reload due to a watchdog expiration. This occurred under the following conditions:
•
The system was over-utilized. CPU utilization at more than 75 percent and more than 1 million open hardware flows.
•
High error rate due to behavioral classification failures.
This issue is fixed in SCOS Release 3.1.7.
CSCso75895
Following a subscriber manager (SM) connection failure, subscriber resources leakage occurred. When a subscriber logged out, the subscriber context did not clear if the subscriber logged back in before the subscriber manager was notified of the logout. This was caused by a connection problem to the SM.
This issue is fixed in SCOS Release 3.1.7.
CSCsq44755
If a large number of IP mappings per subscriber existed, subscriber data sync between cascaded SCE platforms potentially caused a message overflow. When more than 200 IP mappings were found for a given subscriber, the resulting message overflow sometimes corrupted the stack.
This issue is fixed in SCOS Release 3.1.7.
CSCsq52330
Immediately after applying the PQB that has the P2P block policy, some problematic RST packets were sent. Both network and subscriber sides RST were sent with wrong MAC addresses, while all other details were correct. The problem occurred in the asymmetric-L2 topology, where MAC addresses are not the same in both directions.
This issue is fixed in SCOS Release 3.1.7.
CSCsr13246
The data flows for FTP transactions were not forwarded in Quick-forwarding mode, even though all of the traffic was marked by a flow filter rule for quick-forwarding.
This issue is fixed in SCOS Release 3.1.7.
CSCsr41722
When a subscriber with 200 IPs was added, many errors resulted on the SM, and subs sync error info messages on the umlog appeared on the SCE.
This issue is fixed in SCOS Release 3.1.7.
CSCsr59722
Delay-sensitive traffic was not automatically forwarded to the highest priority queue and therefore minimal latency was not guaranteed.
This issue is fixed in SCOS Release 3.1.7.
Resolved Issues—SCE8000 Only
CSCsj98923
Traffic rules configured for a specified direction were instead affecting traffic in both upstream and downstream directions on the specified link.
This issue is fixed in SCOS Release 3.1.7.
CSCsq67666
The ENTITY-STATE-MIB traps for the management interface used the incorrect index on the management IF status trap.
This issue is fixed in SCOS Release 3.1.7.
CSCsq88526
Line cards that were shut down caused congestion, test packet failure, and reboot. Executing the following commands in quick succession caused an internal health monitoring (test packet) failure:
SCE(config if)# shutdown
SCE(config if)# no shutdown
SCE(config if)# pqi install
SCE(config if)# pqi uninstall
SCE(config if)# pqi rollback
This issue is fixed in SCOS Release 3.1.7.
CSCsq93712
Attack detectors could not be configured with non-default rules using ACL. Attempts to configure ACL rules for the attack detector failed.
This issue is fixed in SCOS Release 3.1.7.
CSCsr08535
The support file only included statistics for the previous 10 hours by default configuration.
This issue is fixed in SCOS Release 3.1.7.
CSCsr19962
When the external optical bypass was set using a CLI command, a link-down of 2 seconds occurred. This did not occur when optical bypass was enabled due to system failure or reload.
This issue is fixed in SCOS Release 3.1.7.
CSCsu39933
The entity MIB showed that the SIP and the SCM SNMP OID were zero, while the EPROM showed valid SNMP OIDs.
This issue is fixed in SCOS Release 3.1.7.
CSCsu51741
When using the external-bypass command to activate the external optical bypass on a system with only two SPA modules (single link), the command failed.
This issue is fixed in SCOS Release 3.1.7.
CSCsv49142
SCOS Release 3.1.6S for the SCE8000 platform did not support management interface speed and duplex configuration, although the commands were available in the CLI.
This issue is fixed in SCOS Release 3.1.7.
CSCsw33750
When sending traps and performing SNMP queries in parallel, agentx failed to respond. This happened only under rare condition and in extreme cases of sending traps.
This issue is fixed in SCOS Release 3.1.7.
SCOS Release 3.1.6
•
Resolved Issues in Release 3.1.6
Compatibility Information
SCOS Release 3.1.6 may be installed on the following Service Control Engine platforms:
•
SCE 2020 4 x GBE
•
SCE 2020 4/8 x FE
•
SCE 1010 2 x GBE (2-U only)
SCOS Release 3.1.6 is not compatible with the following Service Control Engine platform:
•
SCE 1010 2 x GBE (1.5 U)
Functional Enhancements
The following section describes a functional enhancement in SCOS Release 3.1.6. For more information regarding this feature, see the Cisco Service Control Engine Software Configuration Guide.
IPinIP Protocol
IPinIP is an IP-based tunneling protocol in which the system must be specifically configured to recognize the flows inside the tunnel. The SCE platform then skips the external IP header, reaching the internal IP, which is the actual subscriber traffic.
For IPinIP traffic, DSCP marking can be configured to occur on either the external or the internal IP header exclusively.
For more information, see the Cisco Service Control Engine Software Configuration Guide, the section titled IPinIP.
Resolved Issues in Release 3.1.6
The following issues were resolved in Release 3.1.6.
CSCsc96282
Under rare conditions, the standby SCE platform of a cascaded pair stopped responding and restarted. This happened in a scenario involving a heavy load of anonymous subscribers in cascade topology.
This issue is fixed in SCOS Release 3.1.6.
CSCse10500
The FTP password appeared in the output of the show version command and also in the user logs of FTP operations.
This issue is fixed in SCOS Release 3.1.6.
CSCsg45606
The show snmp MIB pcube-SE-MIB port command returned an incorrect number of ports, because Mng port 2 was treated as a traffic port instead of a second management port.
This issue is fixed in SCOS Release 3.1.6.
CSCsh21957
'no service telnetd' command did not block the Telnet port
Disabling the Telnet server of the SCE (using the CLI command 'no service telnetd') disables any new Telnet connection to the SCE platform, but did not block the Telnet port.
This issue is fixed in SCOS Release 3.1.6.
CSCsh74673
No method existed to globally enable asymmetric Layer 2 support. A new CLI command [no] asymmetric-L2-support can be used to globally enable or disable asymmetric Layer 2 support.
Information regarding L2 symmetry was also added to the show flow-open-mode command output.
The command is supported in SCOS Release 3.1.6.
CSCsl22211
When working in MPLS Traffic-Engineering skip mode and using DSCP marking, a malformed packet was generated by the SCE when MPLS flows were redirected or blocked.
Flows were affected only if they combined all of the following:
•
DSCP marking
•
Performed redirect/block
•
VLAN or MPLS encapsulation
This issue is fixed in SCOS Release 3.1.6.
CSCsl25301
When the SSH server was enabled, no mechanism existed to enable only SSHv2 (the most recent version of SSH).
This issue is fixed in SCOS Release 3.1.6. You can now disable SSHv1 so that only SSHv2 is running.
CSCsl41385
When working in ToS-marking mode and the application injected over tunneled traffic (VLAN/MPLS), the injected packets were malformed because the ToS was updated at the incorrect offset in the packet.
This issue is fixed in SCOS Release 3.1.6.
CSCsl72585
Installing a protocol pack or applying a policy failed when performed under memory congestion and when the policy contained several LUT entries (such as URL flavors). An error was issued to the SCA broadband console.
This issue is fixed in SCOS Release 3.1.6.
CSCsl85709
Output of the admin-level show interface LineCard 0 counters command was changed to be more meaningful to the user by specifying traffic-counter names instead of FF counter numbers. The output of this command now shows all traffic counters defined by the user with their names and counting method.
The FF counters previously specified in the output were moved to the root- level show interface LineCard 0 counters flow-filter command.
The updated command outputs appear in SCOS Release 3.1.6.
CSCsm26002
The combination of an internal error in the DSCP marking logic in the SCOS together with a long processing time of one packet could have resulted in a false expiration of the SCE watchdog mechanism and a reload of the SCE platform.
This issue is fixed in SCOS Release 3.1.6.
CSCsm75247
Permitting sprayed flows to inject packets when in asymmetric tunneling modes made it possible that Layer 2 switches might be confused by the source MAC address, causing incorrect MAC learning in the connected Layer 2 switches.
This issue is fixed in SCOS Release 3.1.6.
CSCsm75266
In an asymmetric Layer 2 scenario, when requested to block a flow on which the software had not seen packets from the initiating side, the SCE used the Layer 2 information in the current packet instead of avoiding the inject, possibly disrupting MAC learning on the switches.
This issue is fixed in SCOS Release 3.1.6.
CSCsm93051
In an asymmetric Layer 2 scenario, when requested to block a flow on which the software had not seen packets from the non-initiating side, the SCE used the Layer 2 information in the current packet instead of avoiding the inject, possibly disrupting MAC learning on the switches.
This issue is fixed in SCOS Release 3.1.6.
CSCso14783
When the ICCF sanity check mechanism was enabled, it sometimes interfered with business-critical flows (such as DHCP or RADIUS), by placing them in bypass. This, in turn, halted RDR generation.
This issue is fixed in SCOS Release 3.1.6.
SCOS Release 3.1.5
•
Resolved Issues in Releaser 3.1.5
Compatibility Information
SCOS Release 3.1.5 may be installed on the following Service Control Engine platforms:
•
SCE 2020 4 x GBE
•
SCE 2020 4/8 x FE
•
SCE 1010 2 x GBE (2-U only)
SCOS Release 3.1.5 is not compatible with the following Service Control Engine platform:
•
SCE 1010 2 x GBE (1.5 U)
Functional Enhancements
The following section lists functional enhancements in SCOS Release 3.1.5. For more information regarding these features, see the either the Cisco Service Control Engine Software Configuration Guide or the Cisco Service Control Application for Broadband User Guide.
•
Identifying Subscribers per VLAN ID and IP
•
Flexible Subscriber Introduction
DSCP Marking Enhancements
SCOS Release 3.1.5 decouples DSCP marking from the SCE platform queuing mechanism and provides a simplified GUI configuration for DSCP marking based on seven possible DSCP values. After an application is classified by the SCE, the DSCP-marking functionality can mark the relevant packets per package, service, and traffic direction.
Managing MPLS-VPN Branches
SCOS Release 3.1.5 extends the functionality of managing an MPLS-VPN encapsulation as a managed subscriber by supporting the ability to define a branch or site as the managed subscriber. The solution provides DPI usage analysis and control per branch of an enterprise in an MPLS-VPN encapsulation.
Identifying Subscribers per VLAN ID and IP
SCOS Release 3.1.5 adds the ability to define a subscriber through a combination of VLAN ID and IP address range (subnet).
Flexible Subscriber Introduction
In SCA BB Release 3.1.5, the RADIUS Listener LEG component of the Subscriber Manager infrastructure can leverage a Regular Expressions infrastructure to extract and manipulate VSA attributes.
Backward Compatibility
MPLS L3-VPN
The Release 3.1.5 configuration supports several different use cases. For more information, consult the Cisco Service Control Engine (SCE) Software Configuration Guide and the Cisco Service Control MPLS/VPN Solution Guide.
DSCP Marking
The concept of mapping traffic portions to a specific DSCP value changed in Release 3.1.5. In previous releases of the SCA-BB solution, mapping was only possible based on the CoS (Diffserv Class of Service) to which the service was mapped. Starting at Release 3.1.5, you can map each service to one of seven configurable DSCP values independently. The old DSCP marking mode is no longer supported.
Resolved Issues in Releaser 3.1.5
The following issues were resolved in Release 3.1.5.
CSCse19753
After installing a SCA BB PQI file on the SCE platform and before applying a service configuration for the first time, the SCE application ignored all open flows. When a service configuration was applied for the first time, the SCE application started processing new flows. However, older flows that were opened earlier were not processed, and no RDRs were generated for them. RADIUS sniffing is susceptible to this limitation because it is likely that the relevant RADIUS flow was open before the first time a service configuration was applied
This issue is fixed in SCOS Release 3.1.5.
CSCsg85546
TCP Learning did not close flows that started with SYN-ACK. In MPLS/VPN autolearn mode, upstream SYN-ACK packets of unlearned labels reached the software even though they should not have.
This issue is fixed in SCOS Release 3.1.5.
CSCsh90944
In an MPLS environment, configuring a TIR with IP 0 caused the SCOS mechanism that classifies subscribers to TPs to stop responding.
This issue is fixed in SCOS Release 3.1.5.
CSCsi56724
After a change was made to the management IP/subnet, issuing the IP address command did not indicate to the user that a reload of the SCE was required for the changes to take effect.
This issue is fixed in SCOS Release 3.1.5.
CSCsi70273
The SCE platform performed failover procedure between active and standby SCE platforms in a cascaded pair when the connection to the SM failed, even if no failover behavior was configured for this situation.
This issue is fixed in SCOS Release 3.1.5.
CSCsi82338
After the cascade links are up, the active box synchronizes the subscriber database to the standby box at a rate of ~1000 updates/sec. However, the standby box can support this login rate only for dynamic subscribers. If static subscribers were configured, it took up to 1 hour to synchronize the subscriber database after the cascade links were up. However, after the standby box was synchronized, new subscribers were replicated to the standby box normally (at a maximum delay of 2 minutes).
This issue is fixed in SCOS Release 3.1.5.
CSCsi96575
When configuring RDR formatter RdrV1 destinations (even when using old, backward-compatible command syntax), the running-config and hence the startup-config were updated with the new (Release 3.1.0 and later) format of the command. This format implicitly states the protocol and transport type. Due to this behavior, in a downgrade scenario, the startup configuration failed to configure the RDR formatter destination, because protocol and transport type are not supported. This resulted in losing reports.
This issue is fixed in SCOS Release 3.1.5.
CSCsj21478
When the traffic-rule command was executed from the admin authorization level, no traffic rule was created and the following error message appeared:
Error - Required privilege level higher than current level.
This issue is fixed in SCOS Release 3.1.5.
CSCsj68557
In MPLS/VPN autolearn mode, misclassification and a high ratio of unidirectional flows occurred under certain traffic conditions. Warnings in the debug log from flow tunnel support and upstream labels aging were indicative of the problem.
This issue is fixed in SCOS Release 3.1.5.
CSCsj98757
When a VLAN mapping was removed from a VPN while subscriber mappings (IP@VPN) on the VPN were logged in, subsequent attempts to add a VLAN mapping to that VPN failed with an internal error.
This issue is fixed in SCOS Release 3.1.5.
CSCsk06749
The ip ftp username and ip ftp password commands did not work properly in SCOS Release 3.1.0
This issue is fixed in SCOS Release 3.1.5.
CSCsk10218
The first subscriber logged in using the SCE Lease Query LEG had no expiration time.
This issue is fixed in SCOS Release 3.1.5.
CSCsk38279
In rare cases, non-first fragments were misclassified to a different flow and thus potentially dropped.
This issue is fixed in SCOS Release 3.1.5.
CSCsk40370
If a logger get support-file command and a support file extraction operation through the SCA-BB console were executed simultaneously, both operations failed at timeout. Any subsequent support file extraction attempts failed as well. The SCE platform should block simultaneous get support-file commands from multiple interfaces.
This issue is fixed in SCOS Release 3.1.5.
CSCsk94488
The debug reset-to-default command caused a reboot with a fatal error.
This issue is fixed in SCOS Release 3.1.5.
CSCsk96368
Upgrading to PP11 both in Releases 3.1.0 and 3.1.1 resulted in the following error message during the first hours after the upgrade:
"Basic Host Context counter below zero!".
This issue is fixed in SCOS Release 3.1.5.
SCOS Release 3.1.1
•
Resolved Issues in Release 3.1.1
Compatibility Information
SCOS Release 3.1.1 may be installed on the following Service Control Engine platforms:
•
SCE 2020 4 x GBE
•
SCE 2020 4/8 x FE
•
SCE 1010 2 x GBE (2-U only)
SCOS Release 3.1.1 is not compatible with the following Service Control Engine platform:
•
SCE 1010 2 x GBE (1.5 U)
Resolved Issues in Release 3.1.1
The following issues were resolved in this release.
CSCsh99423
When querying the global-controllers MIB group counters, the following warning is printed to the log for any global-controller index above 64 and for every port:
<WARNING>[0x0b80:0x000e] SeMib: globalControllersEntry_lookup droppedCounters.actualNumberOfCounters=64 <= gcIndex=64 (port=1)!. <WARNING>[0x0b80:0x000e] SeMib: globalControllersEntry_lookup droppedCounters.actualNumberOfCounters=64 <= gcIndex=65 (port=1)!. ..... <WARNING>[0x0b80:0x000e] SeMib: globalControllersEntry_lookup droppedCounters.actualNumberOfCounters=64 <= gcIndex=1023 (port=1)!.This issue is fixed in SCOS Release 3.1.1.
CSCsi81920
When performing a get operation on port number 2 (a management port in rev G), the following message is added to the debug log:
05/04/07 22:55:47 [000000125119:265:475] | 000 | 0000014556 | 0000000 | <WARNING>[0x0b80:0x0011] SeMib: globalControllersEntry_lookup CARDS_GetLimiterBandwidthCfg failed. Error is: interface number must be between 1 and 4.This warning is generated each time the SNMP query is accepted and it means that the SCE responds to the SNMP query with a gen_error code, instead of either responding with a proper value, or responding with a no_such_instance error.
This issue is fixed in SCOS Release 3.1.1.
CSCsi82268
The SCE stops provisioning RADIUS transactions on certain flows. This can occur in the following situations:
•
Memory shortage—The SCE is working outside its capacity envelope (high probability).
•
RADIUS sniffer handler performs an illegal operation on the specific flow.
This issue is fixed in SCOS Release 3.1.1.
CSCsj05047
In rare cases, a log message may appear in the log as follows:
[0x0807:0x006c] FC: Total number of packets equals total number of non first fragments in flow countersThis can cause the following issues:
•
Incorrect fragments classification—This is a sanity check which implies that the direction is not computed correctly for certain fragments
•
The log fills up because the dump message is large.
This issue is fixed in SCOS Release 3.1.1.
CSCsj32733
An issue with the quota export function may cause a subtask to run indefinitely, which may cause the SCE platform to reload.
This issue is fixed in SCOS Release 3.1.1.
SCOS Release 3.1.0
•
Resolved Issues in Release 3.1.0
New Features
•
Unidirectional Classification for Support of Asymmetric Routing
•
Subscriber Synchronization in Cascade Setups
Unidirectional Classification for Support of Asymmetric Routing
In a situation in which the routing scheme directs the two directions of a flow to follow different routes, each direction flows through a different SCE platform. The effect of different routing is that each SCE platform can classify only one direction of the flow. The asymmetric routing mode enables the SCE platform to manage such traffic, allowing SCA BB to classify traffic based on a single direction and to apply basic reporting and global control features to unidirectional traffic.
See the Cisco Service Control Engine Software Configuration Guide, Chapter 7, Configuring the Connection, the section titled "Asymmetric Routing Topology" as well as the Cisco Service Control Application for Broadband User Guide
NetFlow Version 9
Starting in SCOS for Cisco Service Control Release 3.1.0, the product can deliver gathered reporting data over the NetFlow V9 export protocol. This protocol is an industry standard for delivering gathered reporting data for external application for collecting, aggregation, storage, and processing. The NetFlow export protocol enables the Service Control solution to integrate with a wide range of existing data collectors and reporters.
See the Cisco Service Control Engine Software Configuration Guide, Chapter 8, Raw Data Formatting: RDR Formatter and NetFlow Exporting.
Subscriber Synchronization in Cascade Setups
SCOS Release 3.1.0 enhances support of failover in cascade topologies by adding a synchronization process between the active and the standby SCE platforms. This process keeps the standby SCE platform constantly updated with the latest subscriber-related information (login, logout, and quota updates), to minimize information loss if failover.
See the Cisco Service Control Engine Software Configuration Guide, Chapter 9, Managing Subscribers, the section titled "Synchronizing Subscriber Information in a Cascade System."
Compatibility Information
SCOS Release 3.1.0 may be installed on the following Service Control Engine platforms:
•
SCE 2020 4 x GBE
•
SCE 2020 4/8 x FE
•
SCE 1010 2 x GBE (2-U only)
SCOS Release 3.1.0 is not compatible with the following Service Control Engine platform:
•
SCE 1010 2 x GBE (1.5 U)
Resolved Issues in Release 3.1.0
The following issues were resolved in Release 3.1.0.
CSCse63425
An error occurred when a user attempted to retrieve a support file using FTP. The failure to retrieve the support file was caused by a timeout on the FTP server. When the SCE produced the support file (in zip format), it first produced the contents locally and then added the contents to the zip file. When the support file is created over an FTP connection, lengthy periods of no data transfer during the creation of the zip internal data occur. These long periods of no data transfer can trigger a connection timeout on the FTP server.
This issue is fixed in SCOS Release 3.1.0.
CSCsf29452
The MIB object destConnectionStatus of the rdr-formatter group was missing in the show snmp MIB pcube-SE-MIB rdr-formatter command.
This issue is fixed in SCOS Release 3.1.0.
CSCsf97557
Part of the quota information was not exchanged between two cascaded SCE platforms. This caused the failover in SCE cascade topology to be stateless with regard to quota.
This issue is fixed in SCOS Release 3.1.0 (see the "Subscriber Synchronization in Cascade Setups" section).
CSCsg02338
A subscriber with several mappings did not send lease time expiration notification on some mappings.
This issue is fixed in SCOS Release 3.1.0
CSCsg37325
When configuring anonymous groups, the following two scenarios sometimes caused an access violation:
•
Configuring subscriber anonymous-group name sub1 IP-range 0.0.0.0/32, and transmitting traffic. Then removing this group and waiting for the flow to end. Then configure subscriber anonymous-group name sub1 IP-range 0.0.0.0/0, and transmit traffic.
•
Configuring anonymous-group name sub1 IP-range 0.0.0.0/32 and anonymous-group name sub2 IP-range 0.0.0.0/0. Then removing sub1.
This issue is fixed in SCOS Release 3.1.0.
CSCsg83522
After reload of the SCE platform, the proprietary trap rdrActiveConnectionTrap failed to send after completing a successful establishment of a connection with the RDR collector. The trap was not sent upon system initialization.
This issue is fixed in SCOS Release 3.1.0.
CSCsh31706
The SNMP traps link up/link down, which should be sent for each port upon system initialization, were sent only on the first 4 ports of the SCE platform.
This issue is fixed in SCOS Release 3.1.0.
CSCsh34432
The MIB object pmoduleType of PcubeSeMib returned an incorrect value in cascade setups, indicating that only 2 GBE ports in the SCE platform existed.
This issue is fixed in SCOS Release 3.1.0.
CSCsh49563
During SSH activity, which usually includes session logout and login operations, the system sometimes ended in an unstable state due to file system violation.
This issue is fixed in SCOS Release 3.1.0.
CSCsh71764
The PRPC connection to the SCE failed after restarting the PRPC server. This occurred when the security level was changed to a level other than the default (semi) and the PRPC server was restarted. After the restart, the security level reverted back to the default value.
This issue is fixed in SCOS Release 3.1.0.
CSCsh73979
Link failure reflection sometimes failed to operate on a system with uptime of more than 24 days.
This issue is fixed in SCOS Release 3.1.0.
CSCsh74592
When a flow using different links for upstream and downstream was redirected, the redirect packet to the subscriber was transmitted on the downstream link, but included the source MAC address from the GET packet seen on the upstream link as destination MAC address. This MAC address was sometimes unknown to the device receiving it.
This issue is fixed in SCOS Release 3.1.0.
CSCsh99422
The MIB-II variable ifMtu returned an incorrect value for the maximum packet size of the SCE platform traffic ports.
This issue is fixed in SCOS Release 3.1.0.
CSCsi01850
Global MIB objects in the RdrFormatterGrp in the PcubeSeMib should indicate total values for all categories of the RDR formatter. Previously, these objects contained only the values for Category 1.
This issue is fixed in SCOS Release 3.1.0.
CSCsi11990
When a port list was configured for an attack-detector, the specified ports were not saved correctly to the running-config. A list of random numbers was saved.
This issue is fixed in SCOS Release 3.1.0.
CSCsi24848
Under certain conditions, the Flow Filter rule used for congestion management took effect a few milliseconds too late, allowing some packets to be discarded.
This issue is fixed in SCOS Release 3.1.0.
CSCsi40164
Applying a policy using Dynamic Signature (DSS) sometimes caused an infinite loop, resulting in a reboot of the SCE platform.
This issue is fixed in SCOS Release 3.1.0.
CSCsi44806
In cases of sudden reboots, the running configuration of the application was not saved. In such cases, the SCE platform resulted in no application configuration.
This issue is fixed in SCOS Release 3.1.0.
CSCsi53483
Reload of the SCE due to an expiry of an internal watchdog mechanism
Under the following conditions, the SCE platform sometimes reloaded due to an expiration of an internal watchdog mechanism:
•
SCE platform working past its capacity envelope, and
•
The rate of the warning messages that BW controllers cannot be allocated is very high
This issue is fixed in SCOS Release 3.1.0.
Limitations and Restrictions
The upgrade to SCOS Release 3.1.7 may result in re-initialization of the SCE 1000 or SCE 2000 hardware bypass module. This re-initialization process may cause a failure of the GBE link where the system stalls for a period of less than 1 second.
Table 1 lists cases in which re-initialization may occur (marked Yes).
When you perform a port scan operation on the SCE platform management port, the SCE platform may experience a reboot. The reboot is initiated by the SCE platform due to scheduling optimization for detecting failover conditions in periods of less than 1 second in a configuration of two cascaded SCE platforms. The following is recommended:
•
Use IP access lists to eliminate port scans that take place due to actual attacks.
•
If the system administrator must perform a port scan operation as part of a security check, it is advisable to disable the SCE watchdog only for the period of time in which the port scan is performed.
To disable the SCE watchdog, use the following root-level CLI commands:
configure watchdog software-reset disabled interface linecard 0 no watchdog•
To re-enable the SCE watchdog, use the following root-level CLI commands:
configure watchdog software-reset enabled interface linecard 0 watchdogOpen Caveats
•
Open Caveats—Cisco SCE 1000 and Cisco SCE 2000
Open Caveats—All Platforms
CSCsd48922
The configured attack threshold is set for each PPC separately. For certain types of attacks, an attack is detected by the SCOS attack-filter module only if it is three times stronger (as measured by flow rate per second) than the configured value.
This occurs when the IP address common to all the flows of the attack is on the network side of the SCE platform, so all attacks of the 'single-side-network' type have this issue.
CSCsg46885
When link reflection on all ports with line- card aware is configured, a link failure may be reflected to all ports (rather than only to the relevant link) if one of the ports that is connected to the failed line card is flickering due to a hardware problem.
CSCsi80337
SCE may reload if stalled by flow control.
By design, the SCE platform reacts to Ethernet flow control and does not activate it. Therefore, a situation could arise in which flow control stalls the SCE platform by overflowing the SCE platform queues and thereby causing traffic to be dropped on the RX interfaces. If this situation persists for more than 5 seconds. It may trigger the SCE platform internal sanity checks mechanism, which may in turn trigger a reload of the SCE platform in an attempt to recover.
CSCsm01291
Issues may occur when an SCE that is configured to create anonymous subscribers is connected to a subscriber manager that is working in push mode. Subscriber login may fail, or the subscriber may log in successfully, but not receive any traffic.
This occurs because, by design, the combination of anonymous subscribers and introduced subscribers is not supported.
Workaround: None
CSCsm19587
Quota events are not received by the SCE subscriber API client or QM because the internal RDR connection to destination 127.0.0.1 port 33001 is not configured.
Workaround: Configure the internal RDR connection as follows:
Step 1
Configure the internal connection on category 4 to destination 127.0.0.1. port 33001.
Step 2
Name category 4 with a special, fixed name. Do not configure any additional destinations on category 4.
CSCsm52337
When the system is in L2TP skip mode, non-first fragments of pure IP traffic (not tunneled) are not managed correctly. Incorrect UDP/TCP ports are assumed, and the fragment is mapped to the incorrect flow, causing flow mismatch.
Workaround: Configure traffic rules that correctly define the ports. Refer to the CLI sample for specific command formats.
Step 1
Configure a traffic rule to set all traffic for quick-forwarding.
Step 2
Configure one traffic rule for UDP with Subscriber side Port=0 and Network side Port=0 with bypass action.
Step 3
Configure one traffic rule for TCP with Subscriber side Port=0 and Network side Port=0 with bypass action.
Step 4
Save the configuration.
Step 5
Reload the SCE platform.
configure interface LineCard 0 traffic-counter name tcp_frag count-packets traffic-counter name udp_frag count-packets traffic-rule name quick-forward-all IP-addresses all protocol all direction both traffic-counter none action quick-forwarding traffic-rule name tcp_frag IP-addresses all protocol TCP ports subscriber-side 0 network-side 0 flags all direction both traffic-counter name tcp_frag action ignore traffic-rule name udp_frag IP-addresses all protocol UDP ports subscriber-side 0 network-side 0 direction both traffic-counter name udp_frag action ignore exit exit copy running-config-all startup-config-all reloadCSCsu88206
When a pull response includes an IP range (as opposed to one IP address), the QM might mistakenly allocate two times the configured dosage.
This occurs because when a pull response includes an IP range, the subscriber is first overwritten with the new name and tunables, then removed, and then a new subscriber is recreated with the specified IP range and tunables. This results in the QM quota being allocated two times.
Workaround: If applicable (in single IP environments), make sure the SM holds single IP addresses rather than IP ranges.
There is currently no workaround for IP ranges.
CSCsw37717
Configuring two anonymous groups with overlapping IP ranges based on IP address 0.0.0.0 causes continuous reboot of the SCE platform, either immediately during reboot or later during PQI installation.
Workaround: Any anonymous groups with an IP range based on IP address 0 (with the exception of 0.0.0.0:0x00000000) must be deleted from the SCE configuration file. Do this by manually editing the file /system/config.txt.
CSCsw49078
TCP RST packets that are injected during the blocking of TCP flows are padded in the L7 layer instead of Layer 2, with the result that they are padded to 80 bytes in total length rather than 60 bytes.
Workaround: None
Open Caveats—Cisco SCE8000
CSCsm12163
SNMP protocol version v1 does not present 64-bit fields properly.
Workaround: Use SNMP v2.
CSCsq33416
FRU modules that are added after startup, such as an additional pluggable SPA optic, may not appear correctly in the entity MIB.
Workaround: After you install any new FRU units, execute a system reload.
CSCsq94141
In rare cases, a condition in which the SNMP agent does not respond to new SNMP requests exists.
Workaround: If the SNMP does not respond, use the following CLI commands to disable and enable it again:
SCE> enable 10SCE# configureSCE(config)# no snmp-serverSCE(config)#snmp-server enableCSCsq95048
The IP table contains entries for internal IP addresses and interfaces. This results in an inconsistency in the If index representation of the following components of the IP table:
•
ipAddrTable
•
ipRouteTable
•
ipNetToMediaTable
Workaround: Ignore all entries in the IP tables, with the exception of the management interface. Refer to the following example:
The If MIB represents five interfaces as follows:
1. if index 1—mng port
2. if index 2—Traffic port 0
3. If index 3—Traffic port 1
4. If index 4—Traffic port 2
5. If index 5—Traffic port 3
The Ip tables and the at tables represent six interfaces as follows:
1. if index 1—eth0 - currently simba to simba
2: if index 2—eth1 - mng port
3. if index 3—eth2 - cofico 1 that is not connected
4. if index 4—lo
5. ifDescr.5—dummy0 - configure to skynet
6. ifDescr.6—skynet0
The only relevant ifIndex in these tables is the management interface, with IfIndex 1 in the IF table being equal to IfIndex 2 in the IP tables.
CSCsq96310
The default gateway cannot be configured before there is an IP address already configured. Trying to set the default gateway when IP address is set results in an error.
Workaround: Before adding the default gateway, configure the IP address.
CSCsr83407
The input and output interface byte counters are not consistent with each other. The input counters include the 4 bytes of the CRC, while the output counters do not include those 4 bytes.
Workaround: None
CSCsu81281
On the SCE8000 V3.1.7 LA with default configuration, the SCE8000 clock is not updated by incoming NTP broadcasts. This is because the default configuration of SNTP broadcast client on the SCE8000 requires authentication of received NTP broadcasts. If the broadcast servers are not configured to authenticate sent NTP broadcasts, the NTP client fails to authenticate and therefore does not update the time.
Workaround: Configure the SCE8000 not to authenticate NTP broadcasts.
Step 1
Set the following flags using the following CLI command:
SCE> enable 15SCE#> debug db set ccConstDb.sntpLinux.NtpdCommandLineFlags 0 "-g -A"Step 2
Add the following line to the file system/usrconst.txt:
ccConstDb.sntpLinux.NtpdCommandLineFlags "-g -A"CSCsw34368
Attempting to modify only the subnet mask of the management IP using the ip address command results in the following error:
Error - Cannot replace management IP. Invalid state or parameters.
Workaround: If the IP address is modified as well as the subnet mask, the change is successful. Therefore, perform the change in two steps, as follows:
1.
Change the IP address.
2.
Change the IP address back to the original IP address and also modify the subnet mask to the desired value.
This example shows how to change the subnet mask from 255.255.255.0 to 255.255.254.0 for IP address 10.10.10.10:
SCE(config if)#> ip address 20.20.20.20 255.255.255.0SCE(config if)#> ip address 10.10.10.10 255.255.254.0CSCsx40066
When you establish a connection to Cisco SCE8000 using Telnet, the client failed to acquire the IP address and the connection is aborted.
Workaround: Implement any of the following workarounds:
•
Modify the DNS server entries to map the client IP address and hostname correctly.
•
Use a client with IP address which does not exist in the DNS table to avoid the IP address being converted to a hostname by the DNS.
•
Remove the DNS configuration from the Cisco SCE8000. Use the console to remove the DNS configuration.
•
Use SSH instead of Telnet.
Open Caveats—Cisco SCE 1000 and Cisco SCE 2000
CSCpu11798
When a PQI application file is installed or upgraded on the SCE, the SCE may lose a few packets for a few seconds. The overall percentage of this phenomenon is very low.
Workaround: Perform the upgrade in non-peak time.
CSCsc49573
When VAS mode is enabled, the system generally assumes that traffic with a VLAN tag is VAS traffic coming from the VAS servers, and therefore forwards it to the non-VAS link.
However, under the following conditions, a flow is forwarded by the SCE platform on the same link on which it was received and with no VLAN tag:
•
VAS mode is enabled
•
The FIF packet has a VLAN tag
•
A traffic rule to bypass the flow exists, or the SCE platform is in congestion
In some topologies, this behavior may cause VAS traffic to be incorrectly routed back to the VAS link.
CSCse05325
When the VAS Health Check initializes, the show interface linecard 0 VAS-traffic-forwarding VAS server-id <id> command shows the server being UP even if it is actually Down
The operative state of a VAS server while the Health Check is in Init state is considered to be Up as shown in the CLI command show interface linecard 0 VAS-traffic-forwarding VAS server-id <id>. In addition, during this time, the SCE platform may forward VAS traffic to this server.
CSCsj32282
A tunnel-id-based traffic rule defining DSCP marking applies the DSCP marking to non-tunneled traffic, also.
Workaround: When you define the traffic rule, always set the URG flag. For existing rules, replace with a new rule that is identical, with the addition of setting the URG flag.
CSCsj85601
When you remove all VPNs from the SM using the --force option, some management operations cannot be performed on the SCE until the operation completes. This occurs only when you remove several VPNs that have active subscriber mappings in the SCE.
Workaround: Instead of removing the VPNs along with their subscriber mappings by using the --force option, remove the subscribers first, and only then remove the VPNs (without the --force option).
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS Version 2.0.
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco Pulse, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, and Flip Gift Card are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Fast Step, Follow Me Browsing, FormShare, GainMaker, GigaDrive, HomeLink, iLYNX, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website 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. (0908R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2009 Cisco Systems, Inc. All rights reserved.