Release Notes for the Cisco 7600 Wireless Security Gateway, Release 3.1.3

Table of Contents

Release Notes for the Cisco 7600 Wireless Security Gateway, Release 3.1.3

Contents

Features

Requirements

Caveats

WSG Release 3.1.3—Open Caveats

Open Caveats Prior to WSG Release 3.1.3

WSG Release 3.1.3—Resolved Caveats

Related Documentation

Obtaining Documentation and Submitting a Service Request

Release Notes for the
Cisco 7600 Wireless Security Gateway,
Release 3.1.3

---

July 2014

This document explains features, requirements, and caveats for the Cisco 7600 Wireless Security Gateway (WSG), Release 3.1.3.

Contents

This document has the following:

• Features
• Requirements
• Caveats
• Related Documentation
• Obtaining Documentation and Submitting a Service Request

Features

The WSG is a high-density IP Security (IPSec) gateway for mobile wireless carrier networks. IPSec is an open standards set. IPSec gives confidentiality, integrity, and authentication for data between IP layer peers. The WSG uses an IPSec-protected tunnel to connect outside endpoints.

The WSG runs on the Cisco Service and Application Module for IP (SAMI), a new-generation high performance service module for the Cisco 7600 series router platform.

For more information about the WSG, see the Cisco 7600 Wireless Security Gateway Configuration Guide, Release 3.1 . For more information about the Cisco SAMI, see the Cisco Service and Application Module for IP User Guide .

WSG Release 3.1.3 supports the following features:

• IPv6.
• Virtual Routing and Forwarding (VRF).
• Data Plane Routing.
• SSH server.
• Per Peer IP tunnel debug.
• Reverse Route Injection (RRI).
• Peer authentication through EAP-MD5, EAP-AKA and EAP-SIM.
• RADIUS Accounting.
• Traffic-based Phase 2 rekey.
• Blacklisting remote peer.
• Multiple IKE proposals.
• Multiple DH groups, EAP authentication algorithms, and transform sets.
• DHCP address allocation.
• High Availability.
• Site-to-Site scalability improvements.
• Certificate Management Protocol.
• Online Certificate Status Protocol.
• IKEv1 and IKEv2 and Public Key Infrastructure (PKI).
• Both remote access and site-to-site type profiles can be used in combination on a SAMI.
• The DPD initiation feature allows the WSG to send DPD to peers at a regular interval. This allows WSG to detect and remove dead connections or peers.
• WSG supports the extended form of traffic selectors.
• Multiple Child SAs—For a single IKE association with a peer, multiple child IPSec SAs can be created, each with its own traffic selector rules.
• DNS to AP feature allows the WSG to pass the DNS server IP address to the remote peer.
• The WSG supports platform traps for PPC CPU congestion and memory exhaustion.
• The OAM traffic routing feature allows the WSG to do static routes on the PPC to carry OAM traffic directly to a local network through a VLAN interface.
• Single Entity configuration allows you to configure the SAMI from a single login interface rather than going to each of the 6 PPCs individually and configuring them.
• All traps, syslog and SNMP stats are sent from a single PPC. For SNMP stats, the external SNMP manager goes to the single PPC to retrieve stats for all the PPCs.
• The PPC Traffic Throttle feature, throttles the number of IKE INIT messages sent to the PPC. This prioritizes the DPD traffic over new tunnel requests, and allows existing tunnels to remain intact.
• WSG supports debugs using the CLI.
• Diffie-Helman (DH) Groups 14, 15, 16, 17, and 18 are added to groups 1, 2 and 5 .
• WSG adds Extended Sequence Number (ESN) support as longer lifetimes are expected in customer deployments. Additionally, higher traffic is expected in site-to-site setups. Extended Sequence Number (64 bit sequence number) implementation is required in such cases.
• Processes Internet Key Exchange version 2 (IKEv2) initialization requests from endpoints.
• Creates IPSec tunnels.
• Exchanges information with endpoints.
• Authenticates endpoints.
• Assigns IP addresses to endpoints.
• Does cryptographic algorithm negotiation.
• Rekeys security associations (SAs).
• Does traffic selector negotiation.
• Supports network address translation (NAT) traversal.
• Encrypts, decrypts, authenticates, encapsulates, and decapsulates packets.

Requirements

For hardware requirements, such as power supply and environmental requirements, as well as hardware installation instructions, see the Cisco Service and Application Module for IP User Guide .

WSG Release 3.1.3 software application ships preloaded on the Cisco SAMI processors with fully-functional default settings. During an image upgrade, the image is automatically loaded onto each SAMI processor.

WSG Release 3.1.3 requires the following hardware and software:

• Any module with ports connected to the network.
• Cisco 7600 Series Supervisor Engine 720 (WS-SUP720-3BXL) with a Multilayer Switch Feature Card 3 (WS-SUP720) or Policy Feature Card 3 (WS-F6K-PFC3BXL) running
  Cisco IOS Release 12.2(33)SRC or later,

or

Cisco Supervisor Engine 32 with a Multilayer Switch Feature Card 2A (MSFC2A) or Policy Feature Card 3 (PFC3B) running Cisco IOS Release 12.2(33)SRC or later.

The Cisco Supervisor Engine 32 requires LCP ROMMON version 12.2[121] or later on the
Cisco SAMI.

For details on upgrading the Cisco IOS release running on the SUP, refer to the “Upgrading to a New Software Release” section in the Release Notes for Cisco IOS Release 12.2SR.

For details on verifying and upgrading the LCP ROMMON image on the Cisco SAMI, refer to the Cisco Service and Application Module for IP User Guide .

• Cisco Service and Application Module for IP (Cisco Product Number: WS-SVC-SAMI-BB-K9) with the 2 GB memory option (Cisco Product Number: MEM-SAMI-6P-2GB[=]).

To find out which IOS version your system is running, log in to the SUP and enter the show version command.

To find out which WSG version your system is running, establish a session with a PPC, and enter the show version command.

Caveats

Caveats are unexpected behavior in Cisco software releases. Severity 1 caveats are the most serious caveats; severity 2 caveats are less serious. Severity 3 caveats are moderate caveats. Typically, only Severity 1, Severity 2, and select Severity 3 and higher caveats are included in the caveats lists.

If you have an account with Cisco.com, you can use Bug Navigator II to find caveats the most current list of caveats of any severity for any software release. To reach Bug Navigator II, go to http://www.cisco.com/support/bugtools .

WSG Release 3.1.3—Open Caveats

There are no newly opened caveats in WSG Release 3.1.3.

Open Caveats Prior to WSG Release 3.1.3

The following caveats are unresolved in this release:

• CSCtw67551—SNMP walk of the ipv6InterfaceTable doesn't return any information

Description: When trying to SNMP walk or get the ipv6InterfaceTable IP-MIB, the WSG does not return any information:

segw-n240:9> snmpwalk -c public 88.88.33.33 .1.3.6.1.2.1.4.30

segw-n240:10>

 

Also, the WSG does not return any information for the IPv6 addresses when walking the ipAddrTable (ipAddrEntry). If more than one RADIUS server is configured, and the first RADIUS server is not working, WSG is not able to set up an IPSec tunnel.

Workaround: None.

• CSCty03287—WSG returns incorrect values for Enhanced-Ipsec-Flow SNMP MIB objects

Description: This occurs if a SNMP getnext is the first opertation performed on the objects after the tunnel is established.

Workaround: Do not perform getnext immediately after establishing the tunnel. If the getnext operation is the first one performed, the returned values will be correct after the tunnel has been established for at least 15 minutes.

• CSCtx65537—WSG logs 16 to 21 blocked rekeys when IPSec SA rekey occurs for blacklisted peer

Description: This occurs when blacklisting is enabled or resynced after tunnel establishment, and rekey occurs for a blacklisted peer.

Workaround: None. However, since the rekey is blocked, no rekey messages are sent to the blacklisted peer.

• CSCto86729—WSG linux is not gracefully shutdown when using SAMI removal procedure

Description: WSG linux application may not shutdown when using the specific removal procedures indicated in the SAMI IOS procedure manual.

Workaround: Use no power enable in configuration mode to completely shutdown the SAMI.

• CSCtq16332—Standby WSG shows remnant IKE SA's due to missing exported delete

Description: Standby WSG shows remnant IKE SA's which no longer exist on the active WSG. The high-availability state seems to be fine. This occurs when the configured remote traffic selector has a wider subnet than the configured WSG traffic selector. During the WSG-initiated Phase 2 rekey, the smaller subnet will be sent, the rekey will fail, and the tunnel will be deleted on the active card when the SA lifetime expires. The IPSec SA on the standby card will be deleted, but the ISAKMP SA will remain. If this happens to a large number of tunnels, the standby could run out of available ISAKMP SAs.

Workaround: Reboot the standby WSG.

• CSCtr73790—WSG does not query the next available IPv6 address of the CRL

Description: If the DNS server returns both an IPv4 and IPv6 address for the domain name of the HTTP/LDAP server, the WSG will only attempt the IPv4 address. If the IPv4 address fails, the WSG won't attempt the IPv6 address, and the tunnel setup will fail.

Workaround: None.

• CSCts72607—Tunnels torn down after copy start run

Description: Normally, the “copy start run” command is used at the begining of setup. In a case where the user used this command after the tunnels were created, we observed all of the tunnels were torn down (e.g. the start and running configurations were the same). This bug was filed to find a way to avoid it.

Workaround: None.

• CSCts80965—SNMP walk on some global stats does not show correct value

Description: The values returned by snmpwalk on ceipSecGlobalStats and some cikeGlobalStats objects are not accumulated across all PPCs.

Workaround: None.

• CSCth84463—HA: snmpwalk on CISCO-ENHANCED-IPSEC-FLOW-MIB stops abrubtly on switchover

Snmpwalk on CISCO-ENHANCED-IPSEC-FLOW-MIB stops.

The HA switchover occurs during the snmpwalk.

Workaround: Re-run the snmpwalk after the switchover is complete. The required statistics are not available immediately after the switchover

• CSCti57743—HA: IKEv1 S2S tunnels with MCSA: Standby Rekey Deletion Failures

Standby Card shows Child SAs (MCSA scenario, originally associated with same IKE SA) split to different IKE SAs.

MCSA scenario: The individual child SAs originally associated with one IKE SA, splits on P1 rekey. The above IPSec SAs end up having their independent IKE's on the standby card. The condition eventually gets resolved after the next P2 rekey.

This might happen to about 5% of all the IPSec SAs.

Workaround: None.

• CSCsy93899—Small Number of IPSec Tunnels are Deleted After a Phase-2 Re-key

After a phase-2 re-key, a small number of IPSec tunnels (approx. 10-20) may be deleted.

This has been seen with large number of tunnels (8500 tunnels on each PPC) established at a high rate and the lifetime was set to a short value in an engineering environment.

Workaround: None.

• CSCta29658—Phase-1 Re-keys Stop After WSG Receives Bad CREATE_CHILD_SA Response

Description: Gateway-initiated IKE SA re-key exchanges do not occur, but IPSec SA re-key exchanges occur as expected.

– IKEv2 protocol is used.

– The IPSec client experiences a re-key overlap condition such that an IKE SA rekey exchange occurs while an IPSec SA re-key is in progress, that is, the re-key exchange is successful, but the old IPSec SA is not yet deleted.

Workaround: If the client supports re-key initiation, the IKE SA re-key is handled by the client. This is a rare situation that was only observed on one particular IPSec client.

WSG Release 3.1.3—Resolved Caveats

The following caveat is resolved in WSG Release 3.1.3:

• CSCuc65113 — LCP Sysmgr Crash Due To Proc Mem Info Corruption

Description: Core Dump File includes Proc Mem Info Details. LCP Sysmgr crashes due to Proc

Memory Info Corruption.

The following caveats were resolved in WSG Release 3.1.2:

• CSCuc45124—Traffic fails on tunnel after IPSec SA rekey on a neighboring PPC

Description: Traffic fails on an IPSec tunnel. The tunnel does not pass traffic until a subsequent IPSec SA (phase-2) rekey occurs on the same tunnel.

– Remote access tunnels are terminated on WSG.

– Tunnels are terminated on two adjacent PPCs (e.g. 3 and 4, or 7 and 8).

– Multiple traffic selectors are configured or negotiated for the tunnels terminating on the higher numbered PPC.

– A phase-2 rekey occurs on a tunnel terminating on the higher numbered PPC. This triggers the traffic loss on a tunnel terminating on the lower numbered PPC.

Workaround: If remote-access tunnels with multiple traffic selectors are needed, do not terminate tunnels on an adjacent, lower numbered PPC.

• CSCtz71369 —asciiPending SAPS 611 wipes out the WSG configuration and enters into a cfg file

Description: The WSG has no configuration after a reboot. The startup configuration is corrupted.

– An error condition is encountered which prints an error message into the running configuration when it is displayed using the show running-configuration command. A "SAP->611" error is an example of such an error.

– The user attempts to save the running configuration.

– A WSG reboot occurs.

Workaround: If an error message is displayed during the execution of the show running-configuration command, do not attempt to save the running configuration.

• CSCub32115—Standby WSG usurps the primary MAC address

Description: The standby WSG will sporadically usurp the MAC address of the active WSG and announce itself causing ARP resolution to fail. This issue can also cause a failure to pass traffic on newly added routes. This issue is seen intermittently in a redundant HA setup when there is no traffic for a period longer than 5 minutes.

Workaround: Configure mac mac-address table timeout to 4 hours on the appropriate VLAN. Adding new routes requires a WSG reload to take effect.

• CSCub82872—WSG infra should send the appropriate msg when tearing the PPC VLAN down

Description: Traffic does not pass through the WSG even though the IPSec tunnel is successfully established. This issue has been observed after configuration changes to VLAN interfaces on different WSG instances (i.e. PPCs) on the same SAMI. Typically, the VLANs are reused but moved to interfaces on different WSG instances.

Workaround: Reload the SAMI.

• CSCtz92610—WSG is dropping all traffic in IXP due to wrongly HA bit programmed

Description: ESP packets are dropped at the WSG. This issue occurs when the VLAN currently configured on a PPC was previously configured on a lower numbered PCC and the SAMI was not reset since that last configuration change. The information pertaining to the previously configured VLAN is not removed from memory when the configuration changes.

Workaround: Reload the SAMI.

• CSCsq81533—System Manager (core-server) crash - incorrect reloading system syslog

Description: The following message may appear in the system log. However, the system does not reload:

Jun 9 2008 00:53:01 : %ACE-2-443001: System experienced fatal failure.Service name:System Manager (core-server)(30822) has terminated on receiving signal 11,reloading system

 

This process is not supposed to initiate a system reset. It is spawned upon demand and will be re-created as necessary.

Workaround: The message for this process should read “NOT reloading system.”

The following caveats were resolved in WSG Release 3.1.1:

• CSCth85737—WSG denies IKEv2 phase 1 rekey with multiple proposals

Description: Symptom occurs when the client is configured with multiple proposals for phase 1 algorithms. The SA is negotiated properly at tunnel bring-up. Yet, the multiple proposals are sent by the client during rekeys and WSG denies that negotiation.

Workaround: Configure the client with a single proposal. Alternatively, rekeys can be initiated by configuring a shorter lifetime on the WSG.

• CSCtx84326—Removal of BGP related config off WSG may result in abnormal SAMI reload

Description: With a BGP related configuration for the WSG Reverse Route Injection (RRI) feature, the removal of the BGP configuration off the WSG may result in an abnormal SAMI reload.

Workaround: Block the BGP neighbors from sending any routes to the WSG. Remove the BGP neighbor configurations one by one before removing the BGP configuration.

• CSCty52622—WSG BGP reset for first time in config mode after card reset

Description: The WSG has just reloaded, and a tunnel is successfully established. BGP then restarts after executing the router bgp <local-asn> command.

Workaround: None. However, this only happens once after the WSG reload.

• CSCtx87552—BGP peer session stuck in “Clearing” state

Description: This occurs after connectivity is lost with the BGP neighbor for more than 3 minutes.

Workaround: Remove and re-add the BGP neighbor configuration.

• CSCty05335—WSG delay sending BGP Update to Sup/RSP when a tunnel is created

Description: A 10 to 30 second traffic loss is observed after IPSec tunnel establishment. This occurs when a WSG BGP configuration is used in an MPLS VPN environment.

Workaround: None.

• CSCty22497—Flapping BGP session between WSG and Sup when 30 or more IPv6 tunnels setup

Description: Symptoms include all BGP routes are not injected to the 7600 Sup and BGP adjacency changes are observed. This occurs when at least 30 IPv6 tunnels are established at 45 tunnels per second... and WSG interface VLAN MTU is configured to a value greater than default.

Workaround: Use default WSG VLAN interface MTU setting.

• CSCtx81465—BGP removal doesn't properly clean up the configuration

Description: The internal BGP configuration is not completely removed. This occurs when the user executes the no router bgp <local-asn> command prior to deleting the BGP neighbors from the configuration.

Workaround: Delete the underlying BGP neighbor configuration prior to executing the no router bgp <local-asn> command.

• CSCty08345—RRI route add/delete counter is increasing when RRI route Invalid occurs

Description: RRI statistics are incorrect after an invalid route is detected. Invalid routes are incorrectly shown as added or deleted. This occurs when HA configuration RRI is used on WSG and the statistics are displayed using the show crypto ha stats command.

Workaround: None.

• CSCty74802—Few RRI routes deleted by standby WSG when 16666 clients P1-P2 rekeys

Description: Some routes are deleted from the standby WSG. This occurs with an HA configuration when 16666 tunnels terminate on the WSG and rekeys initiate by client.

Workaround: None.

• CSCty92834—HA redundancy lost with 3 Gig bi-directional traffic

Description: Lost HA redundancy when traffic is transmitted. This occurs when HA redundancy has been configured. As soon as traffic of 2.6 Gig or more is transmitted, the redundant PPC is reloaded due to missed HA heartbeat messages.

Workaround: Lower the traffic rate.

• CSCtz10823—Clear traffic does not pass through WSG in Active-Active/Standby mode

Description: With HA redundancy configured, traffic does not pass through the WSG from the clear side on all established tunnels except the first tunnel. This occurs when HA redundancy has been configured. Establish 12 IPSec (S2S) tunnels and push a small amount (10 MB) of bi-directional traffic. Observe that while traffic is passing through in both directions, it only passes through from the encrypted side on all remaining tunnels. Clear traffic is being dropped by the WSG.

Workaround: None.

The following caveats were resolved in WSG Release 3.0:

• CSCtg36835—Assertion on Attempting ssh-cmpclient INITIALIZE

The CMP initialize command returns error when executed.

This occurs when the access method (as indicated in the URL) to the CA server is TCP.

Workaround: Use the HTTP access method (http://...) in the CMP initialize command to communicate with the CA server.

• CSCtg65867—snmpd on Secondary PPC Gets Stuck

sh run in entity-all fails on one or another secondary PPC. snmpd does not respond to configuration request and times out with SAPS-->28 error.

This conditiona occurs when you execute snmpwalk on UDP-MIB in continous loop with sleep 200 usecs in between two successive iterations. In entity-all mode execute the show running-config command. snmpd on one or more secondary PPCs timeouts with SAPS-->28 error.

Workaround: On the bash shell of the secondary that got stuck, issue killall -9 snmpd command. This causes snmpd to re-spawn again.

• CSCth53865—HA: WSG Deletes Tunnels After Switchover

The WSG deletes tunnels after an HA switchover.

This conditions rarely occurs when there are 100,000 remote-access tunnels established. With 100,000 tunnels established, 12 were deleted.

Workaround: None.

• CSCth86683—snmpwalk, snmpget Misses Data From Secondarys Periodically

SNMP walk may periodically fail to poll MIB instances/elements on secondary WSGs.

SNMP walk fails to poll data from secondary WSG/PPC periodically. This situation occurs when CPU utilization on primary WSG increases considerably. However, the CPU utilization on secondary WSG always remain normal. High CPU utilization situation remains for very brief time period. The whole issue is not observed on tunnels established on primary WSG.

Workaround: None.

• CSCti00586—HA: StandbyWSG Cannott Recover From Failed SA Import

In the rare instance where a tunnel is not fully imported on the standby card, the standby cannot recover the tunnel from this issue.

To see if the standby card has a tunnel in this state, issue the show crypto isakmp summary command and show crypto ha db info command. This will show if a tunnel count mismatch has occurred.

Workaround: Reboot the standby card to force a new sync of the tunnels.

• CSCti06262—HA: snmpd Process Crashed on Active/SAMI Module

Observed SNMP crashinfo on SUP related to primary WSG/PPC3.

This condition occurred when we configured an SNMP related configuration on primary WSG/PPC. Leave these commands configured on the primary WSG for overnight tests. You may observe SNMP crashinfo files (on SUP disk0) due to SNMP process crash and re-initialization.

Workaround: None.

• CSCtd27881—Site-to-Site IKEv2 Phase 2 Rekey Does Not Happen For All Child SAs

WSG Initiated IKEv2 Phase 2 rekey happens only for one child SA.

IKE SA with multiple child IPSec SAs, with Phase 2 rekeys initiated by WSG (client Phase 2 rekey lifetime > the Phase 2 lifetime configured on WSG).

Workaround: Initiate rekeys from the client side (configure client Phase 2 rekey lifetime < WSG Phase 2 lifetime).

• CSCtd82379—Source Port Field is Not Updated Under show crypto ipsec sa remote-ip Display

The UDP source port is not correctly displayed using the show crypto ipsec sa remote-ip command.

This problem occurs under the following conditions:

– IPSec tunnel is established via a device performing PAT.

– A condition triggers a source port change (for example, a timeout).

Workaround: Use the show crypto isakmp sa command to display the UDP source port.

• CSCtd87234—ipsecpm Process Failed With auto-initiate and rsa-sig authentication

The ipsecpm process failed after tunnel failure with auto-initiate.

The ipsecpm failure is observed with the following conditions:

– IKEv1

– authentication rsa-sig

– auto-initiate

– IKE ID for the remote peer does not match the DN, and Certificate does not include a subjectALtName extension.

Workaround: Configure the remote peer to use DN as the ID.

• CSCte17787—Authentication failed sometimes with more than one trustpoint configured

Authentication sometimes fails when there is more than one trust point configured.

If you have two trust points configured, two entries of get certificate request in IKE_SA_INIT all point to the certificate in the first trust point.

Workaround: One trust point works.

The following caveat was resolved in WSG Release 2.2.2:

• CSCtr15452—Tunnel creation fails, "No Certificate Found Anywhere" is logged on WSG

Description: IPSec tunnel establishment fails when certificate based authentication is used. The messages "Certificate Path Construction Failed" or "No Certificate Found Anywhere" appear in the WSG event log. This symptom occurs when the certificates in use have an entry for "CAIssuers" in the AIA extension.

Workaround: Use certificates that do not use “CAIssuers” in the AIA extension.

The following caveats were resolved in WSG Release 2.2.1:

• CSCtq87296—WSG sends DHCP release prematurely under certain conditions

Description: The WSG sends DHCP release prematurely under certain conditions:

1. Access Point reboot on an existing IPSec tunnel.

2. The reboot cycle occurs before the WSG can delete the IPSec tunnel via dead-peer-detection.
The WSG sends the DHCP release when the old tunnel is deleted.

Workaround: The client IP address is re-assigned via DHCP when the IKE SA is rekeyed, provided

the address is still available. Otherwise, the tunnel is torn down, requiring re-establishment by the Access Point.

• CSCtq89837—WSG allows tunnels to be established with remote peer ID not matching the ID in the remote peer certificate

Description: WSG allows tunnels to be established with remote peer ID not matching the ID in the remote peer certificate. This issue is seen in 2.X images.

Workaround: None.

The following caveats were resolved in WSG Release 1.2:

• CSCta55527—show crypto isakmp summary IKE Error Counters do not Increment Though SA's Deleted

Description: Some tunnels are deleted by WSG. The corresponding IKE error counters do not show any errors.

This happens in multiple circumstances:

1. Immediately after a large number of tunnel creation (For example, when creating tunnels at 90 tunnels per second).

2. If the client does not respond to the INFORMATIONAL messages (and probably the IKE timeout happens).

Workaround: None.

• CSCtb18406—Snmpwalk Returned 0 For All Tunnel Instance Statistics

Description: The snmpwalk utility returns zero values for all instance statistics (per tunnel in/out packets and octets) for the cisco-enhanced-ipsec-flow-mib table.

Workaround: Use the snmpget utility to see valid statistics for each specific instance.

• CSCtb30242—Syslogd crashinfo File Created After SAMI Reset

Description: Crashinfo files for syslogd are created and saved to the SUP. No other problems are observed with syslog after the SAMI comes up. The files are saved to the SUP after the SAMI is reset. This could occur after upgrading the software image (a reset is required to complete the upgrade), or simply resetting the SAMI card.

Workaround: None.

Related Documentation

For more detailed installation and configuration information, see the following publications:

• Cisco Wireless Security Gateway Release Configuration Guide for Release 3.1
• Cisco Service and Application Module for IP User Guide
• Application Control Engine Module Server Load-Balancing Configuration Guide
• Release Notes for Cisco IOS Release 12.2SR for the Cisco 7600 Series Routers
• Cisco 7600 Series Cisco IOS Software Configuration Guide
• Cisco 7600 Series Cisco IOS Command Reference
• For information about MIBs, see:

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

• Cisco IOS Configuration Guides and Command References, Release 12.2—
  Use these publications to help you configure the Cisco IOS software that runs on the MSFC.

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, using the Cisco Bug Search Tool (BST), submitting a service request, and gathering additional information, see What’s New in Cisco Product Documentation at: http://www.cisco.com/c/en/us/td/docs/general/whatsnew/whatsnew.html .

Subscribe to What’s New in Cisco Product Documentation , which lists all new and revised Cisco technical documentation, as an RSS feed and deliver content directly to your desktop using a reader application. The RSS feeds are a free service.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

©2014 Cisco Systems, Inc. All rights reserved.