Table Of Contents
Release Notes for Cisco MGX Route Processor Module (RPM-XF) for MGX 8850 Release 3.0.00 (PXM45)
Contents
About These Release Notes
Features
RPM-XF Redundancy Support
Features Not Supported in This Release
Network Management Features
SNMP MIB
RPM-XF Limitations and Restrictions
Notes and Cautions
RPM-XF auto_config File Management
Card Management
RPM-XF Bootflash Precautions
Known Anomalies for RPM-XF Platform Software and Service Module Firmware
Compatibility Notes
RPM-XF Boot File and Firmware File Names and Sizes
RPM-XF Compatibility Matrix
MGX RPM-XF Hardware
Cisco IOS Release Compatibility Information
Using XModem to Download Flash to RPM-XF Cards
Related Documentation
Obtaining Documentation
World Wide Web
Documentation CD-ROM
Ordering Documentation
Documentation Feedback
Obtaining Technical Assistance
Cisco.com
Technical Assistance Center
Cisco TAC Web Site
Cisco TAC Escalation Center
Release Notes for Cisco MGX Route Processor Module (RPM-XF) for MGX 8850 Release 3.0.00 (PXM45)
Contents
About These Release Notes
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription.
Note that for Release 3, the user documentation (command reference, overview, and installation and configuration guides) use the MGX Release 3 and Cisco IOS documents in addition to this release note.
Product documentation for MGX 8850 is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850r30/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850r30/rpm/index.htm
Features
The MGX RPM-XF is a next-generation, high performance model of the RPM for the MGX 8850 platform, using PXM45 processor modules. It is a router module based on an RM7000A MIPS processing engine that fits into slots 1-6 and slots 9-14 in MGX 8850.
The RPM-XF hardware provides forwarding technology for packet switching capabilities in excess of 2-million pps. The forwarding engine is packet based and is interfaced to the midplane of the system through a combination of switch interface technologies. For more information on the RPM-XF, refer to the Cisco MGX Route Processor Module (RPM-XF) Installation and Configuration Guide, Release 3.
RPM-XF Redundancy Support
RPM-XF 1:N redundancy is used to switch configuration and traffic from one RPM-XF module to another module. Route processing continues with minimal traffic loss even if an RPM-XF fails and there is no operator or direct access to swap the failed card or fix the problem. Currently we support RPM-XF warm redundancy, which ensures Layer 2 state restoration. Layer 3 state is restored via convergence.
The main benefits are:
•
An RPM-XF card with hardware problems can be fixed while the redundant standby card takes over its functionality.
•Software upgrades are easier and can be done with less downtime.
•LAN interface redundancy supported with MAC addresses of primary RPM-XF copied to standby RPM-XF.
•1:N Redundancy support for Gigabit Ethernet interface backcards during front card switchover.
•Y cable redundancy support for POS backcards during front card switchover. (With Y cable, 1:N redundancy is restricted to N = 1).
The following are the general guidelines for redundancy on the RPM--XF:
•Addred is not allowed between RPM-PR and RPM-XF.
•To configure redundancy, the Primary RPM-XF should be in Active state and Secondary RPM-XF card must be in Active/Standby state.
•Removal of the Active RPM-XF back card does not cause switchover to the standby RPM-XF.
•User has to make sure that E:RPM/auto_config_slot# is created before adding redundancy. This may require a login to primary card through the command line and manually adding boot config e:auto_config_slot# followed by a write mem.
•Executing switchcc back-to-back with switchredcd can cause problems. We recommend giving a gap of at least 5 seconds between switchredcd and a switchcc.
•IOS software on a standby card should be the same or higher version than the Active RPM-XF card.
•Booting the card from an image on tftp server is not recommended when the card is in redundancy group. The card should be booted from image in bootflash or PXM disk only.
•Configuring the standby RPM-XF is not recommended.
Features Not Supported in This Release
The following features are not supported in this release.
•LSC Redundancy
•MPLS TE tunnels on ATM Interfaces
•VC Merge
•RPM-PR to RPM-XF upgrade
•OIR of backcards without interfaces in shutdown mode
•Per packet load balancing
•Modem connectivity on Auxiliary port
•EIBGP Multipath load-balancing
Network Management Features
Network management features are detailed in the CWM Release 11.0 Release Notes at: http://cisco.com/univercd/cc/td/doc/product/wanbu/svplus/index.htm
SNMP MIB
SNMP MGX Release 3 MIB are provided with the delivery of this release. The MIB is in standard ASN.1 format and is located in the same directory within the release bundle on CCO. These files may be compiled with most standards-based MIB compilers. The tar file for MIB contains the file that contains the MIB release notes. This contains only MGX MIBS.
Cisco IOS MIBS are not part of this bundle. They are part of 12.2(8)T4 CCO release.
RPM-XF Limitations and Restrictions
The RPM-XF limitations and restrictions that apply to this release are as follows:
•E: RPM/auto_config_slot# must be created before adding redundancy. This may require a login through the CLI and manually adding the boot config command followed by a write mem.
•There is a traffic parameter mismatch between allowed PCR and actual PCR. When a UBR or VBR VC is configured, the CLI allows the value of up to 1198080 kbps, but the actual maximum value is 1197656 kbps. So any value greater than 1197656 kbps would be reset to 1197656kbps.
•PVPs can not operate at a rate greater than 599039 kbps.
•For VBR VCs, if the PCR is not equal to the SCR, the PCR can not be greater than half of the line rate.
•High speed VC (SCR greater than or equal to 500,000 kbps) would not get full-configured rate for single flow (unique source and destination IP address). This happens because for high speed VCs, the PXF creates two queues and these queues can't be shared for same stream. Sharing two queues for same stream would cause out of sequence packets.
•PXF queue selection algorithm may cause traffic drop for multiple stream going to same destination via multiple paths. When the PXF gets a packet, it selects the output queue based on source and destination IP address. These addresses hash into one of the queues for the selected destination. So if there are multiple paths for the same destination, there is a possibility that multiple streams would hash to one queue, causing some queues to overflow, while others might be under-utilized.
•PXF buffer depletion may occur if packets of the same size (especially packets greater than 640 bytes) are sent to a congested interface.
•Currently VBR-nrt and VBR-rt are treated with same priority system wide.
•RPM-XF PVP only supports UBR.
•PVP in RPM-XF is not OAM managed.
•If out-of-sync SPVC or SPVP exist on RPM-XF, shrinking of PNNI partition would not be permitted.
•A single RPM-XF can only function as either an Edge LSR or as an LSC, but not as both.
•Because RPM-XF only supports UBR, VBR-rt and VBR-nrt, on the PXM, dsppnportrsrc for RPM-XF port will show 0 available resource for CBR, ABR and signaling service types. Also, cnfpnportcac for CBR and ABR will be rejected.
•If RPM-XF is configured as an eLSR, RPM-XF does not support incoming VC-merge lvcs. There is a problem logged against LSC module that it cannot support both VC-merge/non-VC-merge supporting VSI slaves at the same time. So for now, if RPM-XF eLSR is part of a cell based MPLS network (with RPM-PRs or AXSMs in the same node), disable the VC-merge feature on LSC. (Note that VC-merge is enabled on LSC by default).
•RPM-XF eLSR only supports at most two MPLS sub-interfaces. Attempting to configure over the limit will result in an error message.
•Although RPM-XF VSI slave supports connections statistics Get command, only packets and bytes counts are available. Therefore, show xtag cross-connect traffic int xtagatm connection statistic display on LSC are actually packet counts from RPM-XF eLSR.
•There are known performance issues with LVCs cleanup/re-establishment in the case of TDP/LDP/VSI sessions flapping. TDP/LDP/VSI sessions flapping can be caused by shut/no shut of mpls/xtagatm interfaces or resetting any of the eLSRs. These performance issues are more noticeable when the number of LVCs exceeds the recommended limits of 4000.
•OIR of MGX-1GE and MGX-1OC12POS-IR back cards are supported only with interfaces in shutdown state.
•MGX-1GE back card does not have the capability to provide line loopback.
•Flow Control Option is not configurable with MGX-1GE back card.
•MGX-1GE back card does not support SFP security.
•Line loopback and internal loopback cannot be set at the same time for the MGX-1OC12POS-IR back card with AMCC Mux.
•pos ais-shut command is not supported on MGX-1OC12POS-IR back card.
•Net booting from the MGX-UI-XF fast ethernet ports does not work.
The performance limits supported in this release are the following:
•2K ATM SPVC Connection endpoints
•2K IDBs
•4K LVCs
•100 VPCs
•256 Policymap
•100 OSPF neighbors
•6 IOS-based cards in MGX shelf
•500 VRFs: 500
•500 BGP CE Peers
•100 RIP CE sessions
•500 Static CEs
•100,000 VPN Routes per PE
•250K non-VPN Routes per RPM-XF
•50 Xtag interfaces per RPM-XF
•300 OAM enabled connections
For more RPM-XF performance details, contact your sales representative.
Notes and Cautions
The following notes and cautions should be reviewed before using this release.
•Attempting to initiate RPM-XF switchover when write mem is in progress on the active RPM-XF card may lead to the card coming up with a partial configuration. When an addred is executed, an automatic write mem is triggered on the primary RPM-XF. If the primary card fails when the write mem is in progress, the card may come up with a partial configuration. The duration of write mem depends on the configuration size and can take up to 4 minutes to complete.
•There is a new stable "Boot-Hold" state displayed on the PXM45 when dspcds is executed. This state indicates that the RPM-XF is running only boot image. This state is reached when config register is set to 0x1 or when the bootldr cannot find the run-time image, but found the boot image. Enter cc to access the RPM-XF from the PXM45.
•Valid boot image need not be the first file in the boot flash. The RPM-XF will load from any valid boot image from the bootflash:. The run-time image can be the first file in the boot flash and RPM-XF will come up with that image.
•Trying to change PCR value of VP tunnel or changing MTU of switch interface with more than 4K VCs may cause CPU hog.
•If there is a large number of VCs (PVCs or LVCs or both) on RPM-XF card, executing disruptive operations on the main switch interface (int switch1) may cause flapping of protocols that run on these VCs. Examples of disruptive operations are clear int switch1 and modification of PVP parameters. These operations cause deactivation and re-activation of all VCs under the main switch interface. Depending on the number of VCs, the time required to complete such operations may exceed certain protocol timeout limit. Examples of protocols that may be affected are OSPF and TDP/LDP.
•RPM-XF VSI slave tends to output informational warning/trace back messages caused by misconfigurations and CAC failures (onto console/IOS log file). These messages are mostly for information/debugging purpose. When these messages are observed, confirm that connection status is still intact and traffic is still passing successfully.
•Due to PXF scr granularity, the configured scr on IOS pvc CLI may not be the same as the actual scr programmed in the PXF. PXF bandwidth chunk size is 18 kbps; all PXF VC scr will be programmed as multiples of 18 kbps. For instance, if the PVCs were configured with 50 kbps as pcr, 54 kbps would be programmed in PXF. show atm pvc display will show 50 kbps, and VSI Slave will account 50 kbps during CAC. However, 54 kbps is actually being used. So as a result, when bandwidth usage is reaching the maximum value, both VSI Slave and PNNI will continue to allow connection provisioning, because VSI Slave and PNNI available bandwidth shows more than PXF actually has left.
•Saveallcnf (issued on the PXM45/B card) captures configuration data saved by the RPM-XF card (as well as AXSM and PXM45 cards), and saves it on the active PXM45/B card's hard disk. Configure the RPM-XF to store its configuration on the PXM45/B hard disk (E:/RPM) by entering boot config e:auto_config_slot# in the running configuration of the RPM-XF. To ensure that the saved file contains the latest RPM-XF configuration, execute the write mem command on each RPM-XF card prior to the entering saveallcnf command. This also ensures that the RPM-XF files on the active PXM45 hard disk will contain the latest configuration to be saved.
•For ELSR to LSC connectivity, the default control VC used is 32. If PNNI partition exists with VCI 32 as part of its partition range, when an MPLS partition is added, there are two options to handle the situation:
–Add the MPLS controller and define its partition with available range. On eLSR, define control VC from any VCI value within the range defined in partition. The same VC should be defined on LSC on xTag interface.
–Reconfigure PNNI partition to spare the control VC usage both on RPM-XF and AXSM, AXSM/B or AXSM-E APS Management Information.
•Whenever the RPM-XF configuration is changed, enter the write mem command on the RPM-XF to save the configuration. If this is not done, the changed configuration will be lost on an RPM-XF card reboot or RPM-XF switchover, in the case of redundancy.
RPM-XF auto_config File Management
The RPM-XF auto_config_slot# file stores the configuration for the RPM-XF card. The slot# portion of the name should be set to the logical slot number that corresponds to the RPM-XF card. This file can be stored in bootflash or in the E:RPM directory on the PXM45 hard disk. The configuration is also stored in NVRAM using the name startup-config.
When the RPM-XF card is inserted or rebooted, it searches for the configuration file in the following sequence:
1. If there is an auto_config file corresponding to its logical slot on the PXM45 hard disk, the RPM-XF card uses the configuration stored on the hard disk.
2. If boot variable points to configuration stored in the PXM45 hard disk or Bootflash and if the file is not found, the card comes up as Active-F with the default configuration.
3. If there is no auto_config file on the hard disk, then the NVRAM version is used.
Note In case of RPM-XF redundancy, the configuration should always be stored in auto_config_slot# file in the E:RPM directory of the PXM45 hard disk. Failure to find the auto_config file will lead to aborting of a user-initiated switchover (switchredcd) and a fatal error will be flagged.
Card Management
The following card management notes and cautions should be reviewed before using this release.
•There is a new stable state displayed on the PXM dspcds command—Boot-Hold, which signifies that the RPM-XF is running the boot image only. On the RPM-XF, the prompt will display as boot>
•The run-time IOS image cannot be used as a bootloader to load a different IOS image.
•Change of console speed on the terminal server may cause the card to end up in the ROMMON state. To avoid this, set the config register to 0x2102.
Another workaround is to enter cont on the ROMMON within 2 minutes of going into ROMMON state. This will bring the card to its original stable state.
Note It is recommended to always use 9600 baud as the console speed.
•The IOS version of the runtime as well as the boot image will be displayed in the dspcd, dsprevs, and dsprevs -s output. The version will be displayed under the heading of IOS version. Revision Control is not available for RPM-XF (like RPM-PR).
Note The commands loadrev and setrev do not apply for RPM-XF.
RPM-XF Bootflash Precautions
The RPM-XF bootflash is used to store boot image, configuration and run- time files. Erasing the boot image from the Flash will cause the card to not boot.
The RPM-XF boot image, which comes loaded on the Flash, will work for all RPM-XF IOS images. Therefore, there is no reason to delete or move the factory installed boot image.
In order to avoid any unnecessary failures that would require card servicing, do the following:
•Never erase the boot file from the RPM Flash
•Never change the position of the boot file on the RPM Flash
•Use care when "squeezing" the Flash to clean it up.
As long as the boot file remains intact in the first position on the flash, the RPM-XF will boot successfully.
If the bootflash is corrupted, use the tftpdnld procedure described in the Cisco MGX Route Processor Module (RPM-XF) Installation and Configuration Guide or xmodem procedure described in "Using XModem to Download Flash to RPM-XF Cards" later is this document to download a new boot image.
Known Anomalies for RPM-XF Platform Software and Service Module Firmware
The following is the list of known anomalies in the RPM service module firmware and software for this release. Included with each is a brief discussion of the problem. A more in-depth discussion is available in the Release Note enclosure of the problem record in Bug Navigator.
Bug ID
|
Description
|
CSCdv59661
|
Symptom:
An SPVP connection goes into the mismatch state after modifying the PCR of the corresponding "atm pvp" tunnel.
Conditions:
The SPVP was either an incomplete connection, the master endpoint of a complete dax connection or any (master/slave) endpoint of a non-dax connection. The PCR of the corresponding "atm pvp" was modified to a new value.
Workaround:
Delete and readd the sw conn vpc.
|
CSCdv86389
|
Symptom:
No warning issued on backcard mismatch while executing addred on RPM-XF.
Condition:
When addred is performed on RPM-XF with backcard mismatch. The mismatch could be:
•Backcard present on one RPM-XF card in the redundancy group and missing on the other.
•Mismatching backcard types present on the upper bay (POS on one and GigE on the other).
Workaround:
None.
|
CSCdw04381
|
Symptom:
Unable to bring up RPM-XF card if runtime image is used as bootloader image.
Condition:
This happens when runtime image is used as bootloader. This can happen in two scenarios.
1. If the bootldr variable is set to runtime image in the bootflash.
At the router prompt, verify this by displaying the boot variables using
sh bootvar command on the RPM-XF. Look for the bootloader variable.
2. If the first valid image in the flash is a runtime image and the config register is set to 0x2.
Workaround:
Use boot image as the bootloader. This may require the user to break to ROMMON, boot with a valid image in the bootflash and then modify the bootldr variable. If the first file in the bootflash happens to be a runtime image, delete the file and squeeze the bootflash. Ensure that you have a valid boot image in the bootflash.
|
CSCdw06098
|
Symptom:
RPM-XF card issues port 161 socket error every 60 seconds to console.
Conditions:
1. snmp community is configured manually on the RPM-XF card or via the PXM.
2. Absence of an IP address on the RPM-XF.
Workaround:
1. Execute no snmp-server for RPM-XF in the configure mode. Only use this option if customer does not want to communicate directly with RPM-XF card via SNMP.
2. Create an interface or sub-interface with an ip address.
3. Create a dummy loopback with ip address.
|
CSCdw10370
|
Symptom:
Turning down the power on dumb terminal, caused RPM-XF to reset.
Condition:
Turning down the power on dumb terminal, caused RPM-XF to reset, when console break key is enabled in config register.
Workaround:
Disable the console break key in config register. To do this, OR the configregister (shown in sh ver command) with 0x100.
For example, if config register is 0x2, use 0x102 to disable it.
This would take effect after the next reboot.
|
CSCdw45040
|
Symptom:
RPM-XF comes up with partial configuration
Condition:
This could happen if write mem is issued on the RPM-XF that is transitioning from standby to Active state.
Workaround:
As a precautionary measure. do not execute write mem while the card is not in Active state.
To restore the original configuration, use the back-up config (if available).
|
CSCdw47209
|
Symptom:
The subIf not exist but sh ip int brief shows interface exist and is in up state.
Conditions:
If a user executes incomplete subif creation command, for example, int sw 1.333 without specifying the subifType (mpls/multi/point), an entry gets created in the subif table, which is visible through SNMP walk as well as in sh ip inter br but not in show run command. Users should use only show run as a guaranteed output for verifying whether an interface exists or not.
Workaround:
Reuse the interface if needed, or else ignore the interface.
|
CSCdw52111
|
Symptom:
Payload RDI alarm not shown in show facility-alarm status output.
Conditions:
Payload RDI being received on the only POS port of MGX-1OC12POS-IR backcard.
Workaround:
None. MGX-1OC12POS-IR backcard does not support the payload RDI alarm that is listed as optional in the GR-253 specification
|
CSCdw55382
|
Symptom:
The output of the command sh swi conn vcc/vpc doesn't show the value of the maximum cost field correctly.
Conditions:
Maximum cost was configured explicitly on the master endpoint of the connection to a value of 4294967295, i.e., 0xFFFFFFFF.
Workaround:
Use dspcon command on the PXM to look at the configured value.
|
CSCdw57105
|
Symptom:
Show sub-interface counter values become very large.
Switch1.1000 is up, line protocol is up
Hardware is Mxt4700 Based ATM PA
Internet address is 100.100.100.101/24
MTU 4470 bytes, BW 1197656 Kbit, DLY 100 usec,
reliability 248/255, txload 1/255, rxload 1/255
4294967294 packets input, 4294966558 bytes
5 packets output, 540 bytes
0 OAM cells input, 0 OAM cells output
Condition:
When there is some drop on the sub-interface, value becomes negative, causing the numbers to become very large.
Workaround:
Clear the counters and try again.
|
CSCdw61072
|
Symptom:
LDP traceback errors logged.
Conditions:
Happens when disabling mpls ldp protocol ldp on the LSC.
Workaround:
Unknown.
|
CSCdw63478
|
Symptom:
Standby RPM-XF card fails to take over after switchredcd, goes to ROMMON and recovers to Standby state.
Conditions:
RPM-XF will break to ROMMON mode if breaking to ROMMON is enabled and if the console speed is configured to be different from the terminal server line speed.
When a switchover is attempted, the standby RPM-XF reads the primary card's configuration. This issue happens if the primary card's configuration has a console speed different from the console speed setting on the standby. The card breaks to ROMMON if config register is NOT set to 0x2102. Else garbled characters are seen printed.
Workaround:
This problem can be prevented by always keeping the speed of terminal server port and console line speed on RPM-XF to 9600 baud and disabling break to ROMMON by setting the config reg to 0x2102.
|
CSCdw66204
|
Symptom:
The following error was observed on the RPM-XF card while parsing the config.
% Error: unsupported option
Conditions:
The config was originally generated by the RPM-XF card and was being copied over to the running config using the command copy c:<config_file> ru at that time.
Workaround:
None.
|
CSCdw68278
|
Symptom:
Allowed to add vbr-rt pvcs within a PVP.
Conditions:
Add a vbr-rt type of pvc with a PVP. Even though CLI allows it, actually these VC are converted back to UBR type.
Workaround:
None.
|
CSCdw68738
|
Symptom:
Cobalt From RP Own Errors counter increments in show hard pxf dma count output. This does not affect data/traffic.
Conditions:
Spontaneous increments of these counters have been noticed always with no specific side effect.
Workaround:
None.
|
CSCdw68935
|
Symptoms:
Occasionally, the following VSI Error appears on the RPM-XF:
VSICORE-4-VSICGENERR: VSICORE: VsiError: VsiErr:Connection Reassert Error
(VcoEntry),
0x5011,2327,810C1802,10D1802,D,0,0,38,46,41,131,1
Conditions:
Occasionally occurs when connection exists between RPM-XF and AXSM/AXSM-E and AXSM/AXSM-E is reloaded.
Workaround:
None.
When the VSI Error is displayed, connection is not impacted. It is confirmed that traffic still flows through connection correctly.
|
CSCdw69483
|
Symptom:
Standby RPM-XF reloads and does not take over upon active card failure or on issuing switchredcd command. The card that comes up as Active may have partial configuration.
Condition:
•write mem was in progress on the Active RPM-XF when the card failed or the switchredcd command was issued on the PXM.
•When an addred is executed, an automatic write mem is triggered on the primary RPM-XF. This issue is observed if the primary card fails when this write mem is in progress. The duration of write mem depends on the configuration size and can take around 3 - 4 minutes to complete.
Workaround:
•Wait for the write mem operation to complete before initiating the switchover.
•In case active card comes up with partial config, restore the previous configuration using the back-up configuration (if available).
|
CSCdw72465
|
Symptom:
Flow control parameter mismatch on two ends of GigE link as seen in show interface gigabitethernet 1/0 output.
Conditions:
Observed occasionally after clearing alarm on GigE with auto negotiation enabled on both ends.
Workaround:
Perform a shutdown followed by a no shutdown on the RPM-XF gigabit ethernet interface on the side displaying not supported. This forces acquisition of flow control parameter on other end in situations where both ends have autonegotiation enabled.
|
CSCdw75473
|
Symptom:
Secondary RPM-XF comes up Active when primary and secondary cards boot-up simultaneously.
Conditions:
•resetsys on the shelf.
•Shelf is power cycled.
•Both primary and secondary cards are inserted together.
•Both primary and secondary cards fail or are reset back-to-back.
Workaround:
switchredcd from secondary active to primary standby.
|
CSCdw76262
|
Symptom:
The alarm state of the switch connection was not displaying any alarm even though the corresponding PVC was receiving the AIS cells.
The PVC was also in UP state.
Condition:
The PVC was not OAM managed. The user intended to make the PVC OAM managed, but also wanted to disable the periodic OAM loopback test.
The command oam-pvc 0 was used to achieve this.
Workaround:
Use the command oam-pvc manage 0 instead of oam-pvc 0, if you want to disable the periodic OAM loopback test but also want the PVC to be OAM managed at the same time.
|
CSCdw76370
|
Symptom:
PPP session times out if idle timeout is configured even with traffic.
Conditions:
PPP timeout idle <sec> command when included as a part of ppp configuration then the PPP sessions keep flapping.
Workaround:
Current release of RPM-XF does not support this command.
Do not configure ppp session idle timeout.
|
CSCdw78246
|
Symptom:
1. A single VBR VC can not be greater than half line rate if SCR is not equal to PCR.
2. A PVP can not have PCR greater than half line rate.
Condition:
CLI does not allow to create a VC in above given range. If an internal IOS application tries to create a VC in that range, an error message would be logged indicating that above given range is not allowed.
Workaround:
Create a VBR VC with PCR equal to SCR if it has to be greater than half line rate.
|
CSCdw85742
|
Symptom:
With a large running configuration on RPM-XF, if user executes certain config-related operations, user may observe side effects due to high cpu utilization or cpu hog occurrences.
Conditions:
Release 3.0 recommended limits:
•2000 SPVCs
•4000 LVCs
The following operations should not cause any service impact:
•show run
•write mem to nvram or c: drive
•SNMP bulk files generation
•squeeze bootflash
However, the fol.lowing operation may cause cpu hog and ospf and ldp/tdp session to flap:
•clear int switch 1
•modify pvp parameters
Workaround:
User should stay with Release 3.0 recommended limits for RPM-XF cards.
When executing clear int switch1 or modify a pvp, users should expect ospf/ldp/tdp session to flap. Avoid executing these two operations. If execution is absolutely necessary, account for traffic disruption during processing of these two operations.
|
CSCdw86377
|
Symptoms:
During partition configuration, if the sum of the minimum connections exceeds the maximum number of connections supported on RPM-XF, VSI Slave CAC will reject the request.
This result in both error message from cli command:
ERR:VSI cannot modify LCN range
Also the following VSIS error will be displayed on console and logged:
%VSIS-4-VSISERR: VSI Error: VsiErr:0xD00F,2322,0,0,3D84,15744,0,0,0,0,0,0
-Traceback= 40AB0350 40AF6CF4 40AF50F8 40AF48B8 40AA5628 40AE3A80
40A7B780 40A7AFEC 40A79D4C 40AE6F94 40AA3DF4 40387E28 40387E14
This VSI traceback error is for information/debugging only and serves as an indication that VSI CAC rejected the request. This is not service impacting.
Conditions:
During partition configuration, if configured parameters result in VSI CAC failure, VSI Error with traceback will be displayed on console and logged.
This error is informational only.
Workaround:
No workaround to suppress the VSI traceback messages.
User should re-evaluate the partition parameters and re-execute the partition command.
|
CSCdw86381
|
Symptom:
Following error message was seen on the RPM-XF console/log.
%VSIS-4-VSISERR: VSI Error: VsiErr:0xD014,4292,0,0,0,0,0,0,0,0,0,0
-Traceback= 40AB0350 40AF896C 40ABC084 40ABE7E0
40AE3668 40A7B780 40A7AFEC 40A79D4C 40AE6F94 40AA3DF4 40387E28 40387E14
Conditions:
User tried to configure less bandwidth for a service type than its current usage. The command cnfpnportcac was used on the PXM to configure the bandwidth.
Workaround:
No workaround to suppress this message.
This message is just an informational message and is not service impacting.
User should re-evaluate current bandwidth usage for that servicetype and re-calculate the correct percentage when re-executing the cnfpnportcac command on PXM.
|
CSCdw86387
|
Symptom:
Following error message was displayed, when tried to modify a pvc (with switch connection)
rpmxf_swconn_update_hndlr, line 438:
<Failed to modify the connection>,
vpi.vci = 1.120, error = 0x5217
show atm pvc shows that the pvc modification is accepted.
show switch conn shows that the switch connection is in mismatch state.
dspcon on the PXM shows the old values of the parameters.
Conditions:
User tried to modify the pvc such that it exceeds the total available bandwidth.
Workaround:
User should either
•Re-execute pvc modification to use a smaller traffic parameter value that is within available bandwidth.
•Increase either per-COS or per-partition min/max bandwidth appropriately.
|
CSCdw91432
|
Symptom:
QPPB with extended access-list doesn't work.
Conditions:
Extended Access-list Matching source/destination and destination specific is not working with QPPB.
Workaround:
This Feature is not supported.
|
CSCdw94224
|
Symptom:
Some of the switch connections were missing on the RPM-XF card after copying the config from the PXM disk.
Conditions:
The config was empty on the card, i.e., even the resource partition was not there when the user tried to copy the config from the PXM disk using the command copy c:<file_name> running-config.
Workaround:
Do either of the following:
•Recopy c:/file to running_config.
•Add the PNNI resource partition manually and wait for all the connections to come to notOnRpm state. Then copy the file to running config.
|
CSCdw94346
|
Symptom:
The 'giants' counter on a GigE backcard always increments for frame size greater than 1548 bytes irrespective of the MTU size.
Conditions:
When data frames of size greater than or equal to 1548 bytes is received on the MGX-1GE backcard.
Workaround:
None. This is as per the design of the framer on MGX-1GE. Note that only those 'giant' frames that are of size greater than the configured MTU will be dropped. Therefore, the MGX-1GE does not drop or impact valid data frames whose lengths are less than the configured MTU even though they get counted as giants.
|
CSCdx00982
|
Symptom:
SNMP GET returns a different value for pcr/scr from what was configured.
Conditions:
The connection was added through CWM/SNMP with a value 'x' of pcr/scr such that
y = test rpm cmm util to-kbps 'x'
z = test rpm cmm util to-cps 'y'
where 'z' is not equal to 'x'.
Basically the values are such that on conversion from cps to kbps and then back to cps does not give back the original cps value.
Workaround:
While adding connections through CWM/SNMP, do not use such value (in cps) for scr/pcr for which conversion from cps to kbps and then back to cps does not give back the original value.
|
CSCdx06018
|
Symptom:
Output traffic drop on VBR VCs at or below SCR, when multiple streams going to same destination via multiple VBR VCs.
Conditions:
This happens when there are equal cost paths via VBR VCs. RPM-XF queue selection algorithm may cause traffic drop for multiple stream going to same destination via multiple paths. When RPM-XF gets a packet, it would select the out going interface based on source and destination IP address.
These addresses hash into one of the queues for selected destination. So if there are multiple paths for same destination, there is a possibility that multiple streams would hash to one queue, causing some queues to overflow while others to be under-utilized.
Workaround:
None.
|
CSCdx07534
|
Symptom:
VSI reassert error happened on elsr when switchredcd on elsr. When a switchredcd or a resetcd is done on an RPM-XF elsr and when it comes back up, LSC will try to resync all the LVCs with the elsr. It is observed rarely that some VSI Slave connection reassert errors will be displayed on console and logged.
Example of errors:
-Process= "RPMXF VSIS", ipl= 0, pid= 103
-Traceback= 40AB3774 40AD44A4 40AC1828 40AE6748 40A7DF28
40A7D794 40A7C4F4 40AEA074 40AA6E64 40389F34 40389F20
%VSICORE-4-VSICGENERR: VSICORE: VsiError: VsiErr:Connection Reassert
Error (VcoEntry),
0x5011,2313,810A1802,10B1803,12ED,202,202,5989,7975,201,125,1
AAAA0300 000C0103 02060003 081001B6 000100B8
The number of errors depends on the number of LVCs being established.
Conditions:
ELSR was in the redundancy group and a switchredcd was performed on the ELSR.
Workaround:
No workaround to suppress error messages. These error messages do not affect service; all LVCs will be established successfully.
|
CSCdx08155
|
Symptom:
On LSC, querying of lvc statistics for an xtagatm interface would not abort command upon user entering a ctrl-c.
If user uses show xtagatm cross-connect traffic to query on lvc statistics, normally, user can quit the command in the middle by giving the ctrl-c sequence.
However, the cli would not return the prompt until the VSI Master logic complete requesting statistics for all lvcs.
Conditions:
If the number of lvcs on LSC is small, user may not be able to notice the impact.
However, if the number of lvcs reach a few thousands (i.e. 4000 lvcs), user may experience no response from the cli session up to 2-3 minutes. But the rest of the system will still function normally.
Workaround:
If user needs to query on lvc statistics, try to let the command run to completion. Avoid aborting the command in the middle of execution with ctrl-c.
|
CSCdx11807
|
Symptoms:
Attempting to add incorrect redundancy for RPM-XF gives misleading error messages.
Conditions:
Attempting to add redundancy between RPM-PR and RPM-XF.
Attempting to add y-red between RPM-XF.
Attempting to add y-red between RPM-XF and RPM-PR (adding between RPM-PR and RPM-XF returns correct message).
Workaround:
None.
Add correct redundancy (RPM-XF 1:n to RPM-XF).
|
CSCdx15670
|
Symptom:
While stby PXM is in "init" state, entering a wr mem on RPM-XF takes a considerably longer time to complete.
Conditions:
A wr mem on RPM-XF card with a small configuration takes a long time (sometimes 40-60 secs) to complete if the standby PXM is in "init" state. This problem is not encountered if the standby PXM is in Empty or Standby state.
Workaround:
Wait until the redundant PXM comes to Standby state and then execute the wr mem command on the RPM-XF.
|
CSCdx20842
|
Symptom:
The pvc under an atm pvp goes into DOWN state.
sh ip interface brief command output shows the Status & Protocol to be "down"
Conditions:
The pvc was oam-managed. An atm pvp existed using the same vpi as that of the pvc, i.e., the pvc was under an atm pvp.
Workaround:
Do not enable oam for pvc under a pvp.
If a pvc under a pvp is oam-managed, the pvc will be put to down state.
This is a known behavior, because pvp currently does not support oam cells.
|
CSCdx23058
|
Symptoms:
If user attempts to modify a switch partition on RPM-XF without modifying any parameter before exiting command, the following error message displays.
ERR:Duplicate request
Conditions:
This error is only an indication that none of the switch partition parameters have not been modified.
Workaround:
No workaround to suppress the error message.
User should at least modify one parameter before quitting the switch partition command to avoid this error.
|
CSCdx28397
|
Symptom:
A rare situation exists where traffic never starts flowing on the line cards or the switch interface after a system reload.
Conditions:
Traffic never starts flowing through the line card or switch interfaces after a system reload. All inbound traffic gets dropped as input errors (ignored errors) and an error message is displayed when this condition is detected (IRONBUS-2-INIT_FAILED). This condition is intermittent.
Workaround:
There is no work around for this problem. To recover from this situation once it occurs, perform a pxf microcode reload (microcode reload pxf) or a system reload.
|
CSCdx29109
|
Symptom:
PXM switchcc caused the following error message related to RMIMSGIPCSNDERR on RPM-XF console.
*Jun 12 13:12:13.607: %RMI-4-RMIMSGIPCSNDERR: ssiRmiSyncDataSend, line
1089597844,Error DCD sending msgType 0, Epid B, Port 117440517, SeqNum 2
Condition:
This happens when switchcc is executed on PXM
Workaround:
None.
Further problem description:
On getting the PXM switchover message, RPM-XF calls an API to get the crossbar availability information from PXM. By that time, PXM would have already switched to the other slot and hence the send sync call for the API fails. With the next retry, at the send sync level, the PXM slot number gets corrected and the API goes through, thus getting the correct crossbar availability information. Hence, this traceback doesn't have any other side effects at all.
|
CSCdx29207
|
Symptom:
RPM-XF front card reset on removing POS or GigE back cards while POS or Gigabit Ethernet interface not in "shutdown" state.
Condition:
Occasionally, the RPM-XF front card encounters an unexpected reset when the back card is removed when the interface is not in "shutdown" state.
Workaround:
To eliminate the probability of a transient service impact due to a front card reset, removal of backcard is to be done when the RPM-XF front card is in a 'Standby' state in a 1:N card redundancy group in the case of Gigabit Ethernet OR in a Y-redundant configuration in the case of POS.
If such card redundancy is not available, the Gigabit Ethernet or POS interface should be placed in the "shutdown" state prior to removing the backcard.
Further Problem Description:
MGX-1GE, MGX-1OC12POS-IR backcard removal without the interface shutdown is not a supported feature.
|
CSCdx29405
|
Symptom:
RPM-XF Q for VBR-rt PVC overflows and shows taildrops.
Conditions:
Switch 1.201 is configured at 500 Mbps. Because this switch is at 500Mbps, we will create a buddy queue and divide the bandwidth in half for the two queues. Because there is only one flow, we are only using one queue and guarantee 1/2 of the configured bandwidth. This is to guarantee in-order packet. The input traffic rate of 55000 pps at 500 bytes per packet is at a rate of 256Mbps, which is greater than 1/2 of the configured bandwidth. Drops will occur.
Workaround:
If there is going to be only one flow (pair of source and destination address), keep the PVC bandwidth less than 500Mbps.
|
CSCdx42842
|
Symptom:
RX sar indicates cell drops & sw1 showing input errors.
Condition:
When Autosync feature is on, it cause the connections to be reprogrammed, which in turn cause cell drops in CAM of switch fpga.
Workaround:
Disable the autosync feature with live traffic.
|
CSCdx44836
|
Symptoms:
Modifying an existing pvp may cause the following VSI error to be displayed on console or logged:
04:57:14: %VSI_VRM-4-GENERR_NUM: VSIRmGetXConnectInfo, line 6658: Vsis RM
error <Failed to search Vco database for lcn =>>, info=1
Conditions:
This error only happens if the existing pvp has a configured switch-conn-vpc, but is not routed yet (only slave end is added).
This error is informational only to indicate that there is no remote cross-connect information to be returned, because the vpc is not routed yet. There is no service impact.
Workaround:
Complete the vpc connection by adding the remote end.
|
CSCdx49122
|
Symptom:
dspcd <slot#> for RPM-XF slot doesn't show the full CLEI code / Serial number. One character at the end is missing.
Condition:
When dspcd command is executed on PXM.
Workaround:
cc to RPM-XF card and enter sh rpm cdmgmt scmExtPollInfo to find the correct CLEI code and Serial number.
|
CSCdx49219
|
Symptom:
When sh tag atm-tdp bindings command is executed on LSC, there will few tag bindings that are indicated as "APIwaitParentLoss".
Condition:
With 4K LVCs are deleted all at once, LSC takes longer amount of time to release those LVC bindings. A few of these bindings, will be left behind with a status indicated above.
Workaround:
None.
|
CSCdx52025
|
Symptom:
Could not correlate output packet dropped on sub-interface with the main int sw1.
Condition:
Sub-interface counters don't have any drop counters, so if any packet is dropped on a particular sub-interface, it is shown on the main interface, but not on that sub-interface.
Workaround:
Use sh hard pxf cpu stat drop sw1.<subif#> and sh atm pvc <vpi/vci> to see all the input drops.
Use sh hard pxf cpu queue sw1.<subif#> and sh atm pvc <vpi/vci> to see all the output drops.
|
CSCdx52061
|
Symptom:
sh pol int sw1.<subif#> is not showing correct dropped counters and drop rate.
Condition:
When a policy map is applied to sub-interface, the drop counters and drop rate are not correct when sh pol int sw1.<subif#> is issued.
Workaround:
Use sh hard pxf cpu que sw1.<subif#> to get the proper drop count.
|
CSCdx58301
|
Symptoms:
When executing show xtag cross traffic on LSC for a RPM-XF eLSR xtagatm, the display may be very slow and user may observe the following VSI error on the RPM-XF eLSR.
%VSI_VRM-4-GENERR_NUM2: VSIRmGetConnStats, line 878: Vsis RM error
<Failed to get vc_info for vpi/vci>, info=11 3198
Conditions:
If user executes show xtag cross traffic on LSC while LSC/eLSR are in the process of bringing up LVCs, the display may be slower because both LSC and eLSR are busy with LVCs establishment.
Workaround:
User should wait until all LVCs are established before executing show xtag cross traffic on LSC.
|
CSCdx58312
|
Symptoms:
After a PXM setrev was done and when RPM-XF comes up, user may observe the following VSI error:
VSICORE-4-VSICGENERR: VSICORE: VsiError: VsiErr:Passthrough Rsp
Processing failed,
0xA004,382,0,0,2,0,0,0,0,0,0,0
Conditions:
This error is caused mostly by PNNI switching RPM-XF pnport signaling from uni to none. This message is not harmful and is only to flag that RPM-XF VSI slave does not handle ATM signalling PassDown commands from PNNI.
Workaround:
No workaround at this point. This message is not harmful and is only to flag that RPM-XF VSI slave does not handle ATM signaling PassDown commands from PNNI.
|
CSCdx67369
|
Symptom:
The following error message will be observed in the logs when this problem happens: "Cannot allocate local tags".
Condition:
When 80K to 100K VPN routes are flapped continuously, the tags sometimes do not get re-used effectively. Because of this, some of the tags are not released for particular prefixes and hence, tag allocation fails. With less number of routes, this problem should not happen.
Workaround:
Avoid route flapping when there are 80K to 100K routes in the network.
|
CSCdx73878
|
Symptom:
Packet drops when an output policy-map with CBWFQ is applied to an uncongested PVC.
Condition:
Three or more class queues in a VC with bandwidth distribution in the range of 80%, 10%, and 1%. Traffic going to the 80% queue is significantly lower than the configured bandwidth, and the traffic going to the 1% queue is significantly higher than the configured bandwidth. However, the traffic is still below the PVC SCR.
Workaround:
None.
|
CSCdx74452
|
Symptom:
The iBGP and eiBGP multi-path load balancing doesn't work.
Ping stops working on enabling iBGP multi-path. With eiBGP multi-path enabled, the packets that take the eBGP path pass through fine. The packets that take the iBGP path get dropped.
Conditions:
The iBGP or eiBGP multi-path load balancing was enabled on the card.
Workaround:
None.
Do not configure iBGP/eiBGP multi-path.
|
CSCdx84176
|
Symptoms:
When booting the system or bootloader images a LINK-NO_MAC error message is displayed on the console and system log. Netbooting from the fast ethernet ports does not work. On initial configuration, the fast ethernet ports initialize to the UP state instead of the ADMINDOWN state.
Conditions:
Everytime you boot the system or bootloader images a LINK-NO_MAC error message is displayed to the console along with a warning that a default MAC address has been assign to the RPM-XF. When trying to netboot an image through the fast ethernet ports, the bootloader exits with the "no usable interfaces" error message. After a clrallcnf, clrsmcnf, or during the initial configuration the fast ethernet interfaces initialize to the UP state instead of the Administratively Down state.
Workaround:
Alternate Boot/System image download method:
The boot and system images can be downloaded/booted from the PXM disk (directory C:/FW) instead of through the FE ports using the appropriate filenames (with x: prefix)
Example system image boot line:
boot system x:rpmxf-p12-mz.12.2-EXAMPLE
|
Compatibility Notes
RPM-XF Boot File and Firmware File Names and Sizes
The following table displays the RPM-XF boot and firmware file names and sizes for this release.
Table 1 RPM Boot and Firmware File Names and Sizes
| |
File Name
|
File Size (in bytes)
|
Boot File
|
rpmxf-boot-mz.122-8.YP
|
2650352
|
Firmware File
|
rpmxf-p12-mz.122-8.YP
|
7445884
|
RPM-XF Compatibility Matrix
MGX SW version
|
3.0.00
|
IOS Version
|
12.2(8)YP
|
CWM
|
11.0.00
|
MGX RPM-XF Hardware
Table 2 shows the front card and back card compatibility for the RPM-XF hardware supported in this release. The table lists the card model/ name, part numbers, the minimum version and the minimum revisions of each card supported. Note that there may be more than one 800 level part numbers for the same front cards. The minimum version is identified by the last 2 digits of the 800 level numbers.
Table 2 Hardware Compatibility Matrix
Front Cards
|
Part Number/
Min. Version
|
Rev.
|
Back Cards
|
Part Number/
Min. Version
|
Rev.
|
RPM-XF-512
|
800-09307-03
|
A0
|
MGX-XF-UI
MGX-1GE
MGX-1OC12POS-IR
|
800-09492-01
800-18420-03
800-08359-05
|
A0
A0
A0
|
Table 3 SFP Compatibility Matrix for MGX-1GE
SFPs
|
Part Number/
Min. Version
|
Rev.
|
MGX-GE-SX
MGX-GE-LHLX
MGX-GE-ZX
|
30-1301-01
30-1299-01
10-1439-01
|
A0
A0
A0
|
Cisco IOS Release Compatibility Information
All IOS firmware can be downloaded from CCO from the following location:
http://www.cisco.com/kobayashi/sw-center/sw-ios.shtml
Using XModem to Download Flash to RPM-XF Cards
Use the xmodem feature to download the flash to an RPM-XF card. During this process, the card should be connected to a target machine through HyperTerminal with settings of 9600, n, 8, and 1.
Step 1 Put the node in monitor mode by entering the priv command to gain access to the privileged commands as follows:
You now have access to the full set of monitor commands. Warning:
some commands will allow you to destroy your configuration and/or
system images and could render the machine unbootable.
Step 2 The xmodem command becomes available and the general syntax of this command and availability of this can be checked by giving xmodem command without any parameters on the CLI, as follows:
-s<speed> Set speed of download, where speed may be
1200|2400|4800|9600|19200|38400
The command line options for xmodem are as follows:
Option
|
Definition
|
-c
|
xmodem performs the download using CRC-16 error checking to validate packets. Default is 8-bit CRC.
|
-y
|
xmodem uses Ymodem-batch protocol for downloading, which uses CRC-16 error checking.
|
-s
|
Specifies the download speed. Default is 9600 bps.
|
Note If you do not find the xmodem commands, then the xmodem feature is not available on this rommom version. In that case, you must return the card to Cisco.
Note The rommon "xmodem/ymodem" transfer only works on the console port. You can only download files to the router. You cannot use "xmodem/ymodem" to get files from the router.
For example:
rommon 4> xmodem -cys 38400
Do not start sending the image yet...
Invoke this application for disaster recovery. Do you wish to
Note, if the console port is attached to a modem, both the
console port and the modem must be operating at the same baud
rate. Use console speed 38400 bps for download [confirm]
Step 3 At this point, change the preferences in HyperTerminal and adjust the speed from 9600 to 38400.
Note You can continue at the speed of 9600 as well by either not specifying the -s option in the command, or by specifying 9600 explicitly, but it will take longer.
The console will display the following message:
Download will be performed at 38400. Make sure your terminal
emulator is set to this speed before sending file. Ready to
Step 4 Use the Transfer-->Send File option in HyperTerminal to start the image transfer.
In the Filename box, browse and choose the image file to be downloaded. Also since we used the "y" option while invoking the xmodem, set the transfer protocol to ymodem or use Xmodem protocol by not specifying the -y option on the command line.
The transfer screen comes up and transfer starts. (The transfer may not start immediately; wait for some time and it should start.)
After the transfer is completed (it should typically take about 10-15 minutes), the following messages are displayed on HyperTerminal console:
Returning console speed to 9600.
Please reset your terminal emulator to this speed...
Step 5 Return the console speed back to 9600 through HyperTerminal's Preferences menu option.
Usually, due to time lag between changing HyperTerminal speed back to 9600, you might see a bunch of garbage. To avoid this, disconnect and reconnect the HyperTerminal to get the console back again.
The system will reset itself from here and will boot with new software image.
Related Documentation
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription.
Note that for Release 3, the user documentation (command reference, overview, and installation and configuration guides) use the MGX Release 3 and Cisco IOS documents in addition to this release note.
Product documentation for MGX 8850 is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850r30/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850r30/rpm/index.htm
Obtaining Documentation
The following sections explain how to obtain documentation from Cisco Systems.
World Wide Web
You can access the most current Cisco documentation on the World Wide Web at the following URL:
http://www.cisco.com
Translated documentation is available at the following URL:
http://www.cisco.com/public/countries_languages.shtml
Documentation CD-ROM
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.
Ordering Documentation
Cisco documentation is available in the following ways:
•Registered Cisco Direct Customers can order Cisco product documentation from the Networking Products MarketPlace:
http://www.cisco.com/cgi-bin/order/order_root.pl
•Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:
http://www.cisco.com/go/subscription
•Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
Documentation Feedback
If you are reading Cisco product documentation on Cisco.com, you can submit technical comments electronically. Click Leave Feedback at the bottom of the Cisco Documentation home page. After you complete the form, print it out and fax it to Cisco at 408 527-0730.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:
Cisco Systems
Attn: Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Obtaining Technical Assistance
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.
Cisco.com
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.
Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you to
•Streamline business processes and improve productivity
•Resolve technical issues with online support
•Download and test software packages
•Order Cisco learning materials and merchandise
•Register for online skill assessment, training, and certification programs
You can self-register on Cisco.com to obtain customized information and service. To access Cisco.com, go to the following URL:
http://www.cisco.com
Technical Assistance Center
The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC Web Site and the Cisco TAC Escalation Center.
Inquiries to Cisco TAC are categorized according to the urgency of the issue:
•Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration.
•Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.
•Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.
•Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.
Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of service contracts, when applicable.
Cisco TAC Web Site
The Cisco TAC Web Site allows you to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to the following URL:
http://www.cisco.com/tac
All customers, partners, and resellers who have a valid Cisco services contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to the following URL to register:
http://www.cisco.com/register/
If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a Cisco.com registered user, you can open a case online by using the TAC Case Open tool at the following URL:
http://www.cisco.com/tac/caseopen
If you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC Web Site.
Cisco TAC Escalation Center
The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority level 2; these classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer will automatically open a case.
To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following URL:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled; for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). In addition, please have available your service agreement number and your product serial number.
This document is to be used in conjunction with the Cisco WAN Switching MGX 8850 Release 3 publications.
CCIP, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, Internet Quotient, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, Networking Academy, ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That's Possible, The Fastest Way to Increase Your Internet Quotient, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, IOS, IP/TV, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0203R)
Copyright © 2002, Cisco Systems, Inc.
All rights reserved.
Feedback
