Table Of Contents
2.0.01 Version Software Release Notes for Cisco WAN MGX 8850 Software
About These Release Notes
About the 2.0.01 Release
Phased Release Strategy
Software Release 2.0.01 and Related Hardware
Special Installation/Upgrade Requirements
General
Upgrade Procedure
Features Not Supported
Committed (but not delivered in this release)
Obsoleted
Notes & Cautions
Limitations
Release 2.0.01 System Content
Switch Software and Boot Codes
Hardware Products
Known Anomalies
Problems Fixed in Release 2.0.01
Obtaining Service and Support
Cisco Connection On-line
Additional Support Information
2.0.01 Version Software Release Notes for Cisco WAN MGX 8850 Software
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. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar, select Documentation, and click Enter the feedback form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
About the 2.0.01 Release
Phased Release Strategy
This is a first release of PXM45 and AXSM. Future releases are planned to add new feature contents.
Software Release 2.0.01 and Related Hardware
AXSM Cards
The AXSM is a double height ATM service module that is compatible with release 2.0 and later PXM45 based versions of the MGX. The AXSM uses the serial line traces on MGX chassis to access the 45Gbp crosspoint fabric of the PXM45 and the STRATM48 ASIC technology to accommodate a full duplex throughput of OC48c/STM16.
The AXSM provides ATM switching and line functionality, and is compatible with the feature set of the BXM card of the BPX, the UXM on the IGX, and AUSM of the release 1 MGX8850. Other Cisco ATM platforms, and other ATM manufacturers equipment have proven to be compatible.
Line Interfaces for the AXSM Cards
•
T3/E3
8 ports per back card, 2 back cards per dual height slot
G.703/Accunet Conformance
•OC3c/STM1
G.703/GR-253 Conformance
8 ports optical per back card, 2 back cards per dual height slot
MMF, SMF intermediate and long reach
4 port Electrical back card
•OC12c/STM4
G.703/GR-253 Conformance
2 Ports per back card, 2 back cards per dual height slot
SMF intermediate and long reach
•OC48c/STM16
G.703/GR-253 Conformance
Single port back card, one back card per slot
SMF Short, long and extra-long reach
ATM Layer Information
•Usage policing supported on all interfaces except OC48c/STM16
•T3 interfaces support both PLCP and direct cell mapping
•64 Logical interfaces -- ports, trunks, or virtual trunks (future)
•16 Class of Service queues for each class of service
•Supports independent queues for each ATM class of service
Network Management Features
•OAM functionality per ITU-T I.610
•Fault management - AIS/RDI at F4 and F5 flow
•User selectable continuity checking at connection endpoints
•Loopback diagnostics
•Automatic alarm generation and propagation for interface failures
The AXSM offers a complete ATM feature set and allows the MGX8850 to scale to the core of service provider networks from the T3/E3 edge to the OC48c core. Full line rate is achieved through the use of the serial line traces on the MGX8850 platform. The entirely standards based design and connection protocols enables the installation into any existing network, as well as building new ATM infrastructures.
PXM 45 Cards
The PXM-45 is a 45Gbps processor switch module. The architecture of the PXM-45 contains the CellBus fabric that is used in the current PXM-1, but adds the functionality of a 45Gbps cross point switching capacity. This allows for the use of the serial line broadband cards (AXSM) in the MGX8850. The PXM-45 provides a Stratum3 central clocking circuit conforming to GR-1244 and G.813 specifications. This is an improvement over the Stratum4 based PXM-1 design.
Reliability, Availability and Serviceablity (RAS) Features
The PXM-45 is designed to be fully redundant, there are two dedicated slots in the 8850 (dual height slots 7 and 8) that will house the PXM-45. Highlight of the RAS features are listed below:
•Switchover from active to standby is designed to result in no cell loss with the exception of cells that are physically on the fabric at the time of the swap.
•In-band arbitration/grant mechanism ensures that service module failure does not stop traffic flow
•Hardware design to ensure that if one or both hard disk fails, the cards will still pass traffic with no interruption, although provisioning could be suspended.
•MTBF Goal is calculated using a 99.9999% availability model which assumes two PXMs in a system. This was calculated at greater than 100,000 hours.
PNNI
The PXM-45 will support PNNI software. There are two other components that make the complete card set these are:
•PXM-UI-S3
The PXM-UI-S3 supports the following interfaces:
•One RJ45 10Mbps 802.3 Ethernet port
•Two RJ45 RS232 Data Termination Equipment (DTE) ports that can be Y cabled. Pinouts are as follows:
Pin
|
Signal
|
Direction
|
Description
|
1
|
RTS
|
OUTPUT
|
Request to Send
|
2
|
DTR
|
OUTPUT
|
Data Terminal Ready
|
3
|
TX
|
OUTPUT
|
Transmit Data
|
4
|
SG
|
|
Signal Ground
|
5
|
SG
|
|
Signal Ground
|
6
|
RX
|
Input
|
Receive Data
|
7
|
DSR
|
Input
|
Data Set Ready
|
8
|
CTS
|
Input
|
Clear to Send
|
•Two DB9 T1/E1 BITS input, with converted cables that can be Y cabled. The followingconnections are supported:
–RJ48. Pin Out conforms to Accunet1.5 Specification
–Wire Wrap
–BNC
–DB15
•One DB15 Alarm interface. Contacts are normally open. This interface can be Y cabled.
•PXM-HD
•This contains the hard disk for the processor.
PNNI
Defined by the ATM Forum for ATM networks, PNNI provides a dynamic routing protocol, is responsive to changes in network resource availability, and will scale to very large networks.
PNNI includes two categories of protocols. PNNI defines a protocol for distributing topology information between switches and clusters of switches. This information is used to compute paths through the network. PNNI topology and routing are based on the well-known link-state routing technique.
PNNI also defines a second protocol for signaling, that is, message flows used to establish point-to-point connections across the ATM network. This protocol is based on the ATM Forum UNI 4.0 signaling, with mechanisms added to support source routing, crankback, and alternate routing of call setup requests in case of connection setup failure. Whereas the UNI signaling protocol distinguishes between the user and network sides of a connection, PNNI is a symmetrical protocol.
PNNI provides dynamic ATM routing with QoS support as defined by the ATM Forum. PNNI uses link-state and source state route technology, supports aggregation for private ATM addresses and links between switches, and has the ability to scale the network and its performance by means of configuring PNNI peer groups and hierarchical levels. A key feature of the PNNI mechanism is its ability to automatically configure itself in networks in which the address structure reflects the topology.
The functions of the PNNI routing protocol include the following:
•Hello protocol (allows adjacent switches to exchange topology information)
•PTSE (PNNI Topology State Elements) database synchronization and management
•PTSE flooding
•Address summarization and advertisement
•Link and nodal aggregation
•Pre-computation of routing tables
•Quality of Service (QoS) based routing
•Multiple Routing Metrics
•Discovery of neighbors and link status
•Synchronization of topology databases
•Load balancing on equal cost paths
•Load balancing on parallel links
•Load balancing with redundant addresses
•Alternate paths
The following PNNI features are supported in Release 2.0 of the MGX.
•UNI 3.0/3.1
•PNNI 1.0 Single Peer Group
•ILMI 4.0
•Point to point ATM SVCC and SVPC
•Support for CBR, VBR, rt-VBR, and UBR
•Alternate call routing (See separate feature description)
•On demand call routing (See separate feature description)
•Native E.164 and AESA (E.164, ICD, DCC) - formerly NSAP - address format
•Enhanced CAC with per service class policy parameter (See separate feature description)
•Per Class of service overbooking
•Congestion control (See separate feature description)
•PNNI connection and path trace
•OAM fault management
•Address Filtering (see separate feature description)
•Intelligent CAC (see separate feature description)
•Call Processor Redundancy
PNNI networks are highly resilient due to their ability to quickly reroute connections around failed network elements, and to update routes and network topology based upon availability of network resources. Connections will generally route quickly using pre-computed routing tables, but in the case of congestion or during a network failure, on-demand routes will be calculated for connections.
Special Installation/Upgrade Requirements
General
SCT Files
With this image there are four new SCT files:
•AXSM_SCT.CARD.2
•AXSM_SCT.PORT.2
•AXSM_SCT.CARD.3
•AXSM_SCT.PORT.3
SCT-ID 2
1. Supports ATMF service types only.
2. Policing is enabled for all service types
3. CoSB CLR values are NOT corrected, ( Firmware does not use this parameter )
SCT-ID 3
1. Supports ATMF service types only.
2. Policing is disabled for all service types
3. CoSB CLR values are NOT corrected. (Firmware does not use this parameter.)
To use the new SCT files you must delete all connections, partitions and ports.
Upgrade Procedure
Loading the runtime images from 2.0.00 to 2.0.01
For Redundant Systems
Due to bug CSCdr50312 (see section Known Anomalies) graceful upgrade will not work with this image.
1. Upgrade the standby PXM45 boot code
2. Reset the card
3. Former active card should now be the standby card. When it is in standby status, upgrade its boot code.
4. Use the "SETREV" command to load the 2.0.01 release:
setrev <slot number> <primary version> <secondary version>
For example: setrev 7 2.0(1) 2.0(1)
For non-redundant systems
1. Upgrade the PXM45 boot code.
2. Use the "SETREV" comand to load the 2.0.01 release:
setrev 7 2.0(1) 2.0(1)
type sh (this will be you in the shell)
sh> revChgIgnoreStandby
After approximately 90 seconds the system will reboot with the new image.
Features Not Supported
Committed (but not delivered in this release)
1. AXSM cards with STM1 elecrical interface.
2. IISP.
3. Capable of graceful upgrade to future releases.
4. Inter operability with LS1010 and BPX-SES (BPX-SES is in beta phase).
5. Connection density: 50K connection per node is not supported.(25K connections per node are supported with Limitation listed below).
Obsoleted
None
Notes & Cautions
The following CLI commands were changed since publication of user documentation. Reason for the change is to make these commands consistent with other products.
Documented
|
Implemented
|
Purpose
|
addchan
|
addcon
|
Add SPVC endpoit
|
cnfchan
|
cnfcon
|
Change parameters of SPVC
|
delchan
|
delcon
|
Delete SPVC endpoint
|
dspchans
|
dspcons
|
Display all SPVCs in the node
|
dspchan
|
dspcon
|
Display a specific SPVC
|
The addslave and addmaster commands are obsolete.
Some of the available bandwidth is used by signaling (PNNI rcc, SSCOP and ILMI).
The database stores the backplane serial number and backcard serial numbers. Therefore if cards are moved from one node to other, console will display "SHM Alert !! Alert!!" . The first time a PXM is brought up in a shelf, a default database is created. The backplane, hard disk, and the UI backcard serial numbers are recorded as part of this database. A PXM nativity check is run when the PXM is coming up. This check will produce an SHM alert failure message if some of the serial numbers do not match. The serial numbers will not match if the card has been previously installed in another shelf. The mismatched serial numbers will trigger the following message:
***************** SHM ALERT ALERT *********************
The PXM card has failed. For the Failure Reason
run sysEventDisplay to display the log.
If a healthy peer PXM card is inserted, this local
PXM card will be reset to give up its mastership to the
peer PXM. If both PXM cards are not healthy, both cards
will remain in this fail state.
Use the shmDspRed (pxmSlot) command to find out which
PXM is the active PXM. Use the following shell
commands to further diagnose the problem
Shell commands to diagnose this problem:
********************************************************
In this situation follow the steps below:
Step 1 Enter shmFailDisplay. The display table will show that BRAM is not native.
Step 2 Enter shmFailRecoveryHelp. This will indicate that to "Ignore Nativity and Rebuild from Disk" the command to use is shmRecoverIgRblDisk.
Step 3 Enter shmRecoverIgRbldDisk.
Run the last shellconn command to get the failure resaon, typically the BRAM Non Native message.
* SHM Failed for the following reasons:
====== ===== =================
1. BRAM Clr Valid No Replace PXM Front Card
2. BRAM Read Valid No Rebuild from Disk or clrallcnf
3. BRAM Ver Mismatch No Rebuild from DIsk or clrallcnf
4. FC Mismatch No Program FC NVRAM or Replace FC
5. FC NVRAM Read Fail No Program FC NVRAM or Replace FC
6. Image Mismatch No Load right image
7. BRAM Non Native Yes Rebuild from Disk or clrallcnf
8. Disk Non Native No Ignore Nativity and Rebuild from Disk or clrallcnf
9. Disk Read Valid No clrallcnf
10. Disk Ver Mismatch No clrallcnf
11. Disk Access Fail No Reseat the Disk/FC or Replace Disk
12. Disk Not Synch No clrallcnf
13. Lower BC NVRAM Read No Program its NVRAM or Replace it
14. Upper BC NVRAM Read No Program its NVRAM or Replace it
15. Lower BC Mismatch No Program its NVRAM or Replace it
16. Upper BC Mismatch No Program its NVRAM or Replace it
17. Lower BC Missing No Insert a lower BC
18. Upper BC Missing No Insert an upper BC
19. Memory Init Fail No Reset the card
20. Timer Init Fail No Reset the card
21. EPID Init Fail No Reset the card
22. HW Init Fail No Manually Reset the card
23. SW Ver Mismatch No Load correct version image
********************************************************
Shell command for recovery help:
The workaround is:
•For redundant PXM systems, if you see this on the standby card, execute the sysClrallcnf command on the standby card.
•For single PXM systems, execute the sysClrallcnf command.
Non user data cells are not policed.
It is possible to add ports at cell rate fractionally higher than maximum line rate. This may cause cell drop.
Limitations
1. Support for 25,000 connections per node with limit of 25,000 connections per NNI. Also note following bugs under "known anomolies" section :
•CSCdr23168
•CSCdr35241
•CSCdr37025
•CSCdr38809
•CSCdr40126
•CSCdr47947
•CSCdr20887
•CSCdr26669
•CSCdr31492
•CSCdr40821
•CSCdr41012
•CSCdr44537
•CSCdr46945
•CSCdr47590
2. Cannot change card SCT without deletion of all connections, partitions and ports
3. To replace one type of AXSM card with other type, it is required to delete all connections, partitions , ports and down lines. In case of AXSM card failure, same type of AXSM card must be istalled in that slot.
4. If port(s) and trunk(s) are configured on same AXSM card and port level failure occurss, it will cause SPVC deroutes.
5. Connection statistics at CLI and Bucket level is not available in AXSM-1-2488 cards. However, connection debug statistics are available in all types of cards.
6. For PXM45, clock synchronization in E1 sync mode is not supported (T1 and E1 in data mode is supported).
7. OC48 BC intermittently fails to detect the optical input after power recycle. If this happens, theback Card should be reseeded.
Release 2.0.01 System Content
Switch Software and Boot Codes
The following four images are applicable to the 2.0.01 release:
•Boot Images
•axsm_002.000.000.001_bt.fw
•pxm45_002.000.000.001_bt.fw
•Runtime Images
•axsm_002.000.000.001.fw
•pxm45_002.000.000.001_mgx.fw
Hardware Products
Support hardware for Release 2.0.01:
Model
|
800 Part Number
|
Revision
|
PXM45
|
800-06147-05
|
A0
|
PXM-UI-S3
|
800-05787-01
|
A0
|
PXM-HD
|
800-05052-03
|
A0
|
AXSM-1-2488
|
800-05795-04
|
A0
|
SMFSR-1-2488-FC
|
800-05490-05
|
A0
|
SMFXLR-1-2488-FC
|
800-05793-05
|
A0
|
SMFLR-1-2488-FC
|
800-06635-04
|
A0
|
AXSM-16-155
|
800-05776-05
|
A0
|
AXSM-4-622
|
800-05774-07
|
A0
|
AXSM-16-T3/E3
|
800-05778-07
|
A0
|
SMFIR-2-622
|
800-05383-01
|
A1
|
SMFLR-2-622
|
800-05385-01
|
A1
|
SMB-8-T3-BC
|
800-05029-02
|
A0
|
SMB-8-E3-BC
|
800-04093-02
|
A0
|
MMF-8-155
|
800-04819-01
|
A1
|
SMFIR-8-155
|
800-05342-01
|
B0
|
SMFLR-8-155
|
800-05343-01
|
A1
|
Known Anomalies
The following is the list of known anomalies in this Switch Software delivery. 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
|
S1 Bugs
|
CSCdr15133
|
Symptom:
Many [vsierr] messages and [egress ConnID delete failure] messages are reported by the card hosting EP2_UNI_PORT_ON_TRK.
Condition:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.
(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.
(4) There are 20K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. (
5) Another UNI port (EP2_UNI_PORT_ON_TRK) is present in NODE_EP2 using the same AXSM card which also provides the lines as trunks between NODE_VIA and NODE_EP2.
(6) There are 5K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORT_ON_TRK.
(7) All these 25K (=20K+5K) SPVCs are routed through one trunk (TRK_A_BETWEEN_NODE_EP1_AND_NODE_VIA) while the other trunk (TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA) is downed.
(8) A [uppnport] is executed to TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA.
(9) A [dnpnport] is executed to TRK_A_BETWEEN_NODE_EP1_AND_NODE_VIA. This forces ALL 25K SPVCs to be rerouted to TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA.
Workaround:
One of the following: (1) Move the 5K SPVCs from EP2_UNI_PORT_ON_TRK to EP2_UNI_PORTS. (2) Reduce the number of SPVCs from 25K to 10K. (3) If the failure has already occured, rectify this problem by doing [resetsys] on every PXM45 in the network.
|
CSCdr15197
|
Symptom:
Some applications were holding a large number of unreleased buffers
Condition:
On a node with 10K SPVC and 1K SVC, after a number of switchcc, it was found that a application, pnsscop was holding many buffers (leaking).
Workaround:
None
|
CSCdr15911
|
Symptom:
Changing the backcard may sometimes cuase the front card to reset and loss service. It may occasionally difficult to bring up the AXSM.
Conditions:
This problem happens occasionally when someone reseats the backcard several times, the front card is reset.
It is also observed that during power on/off testing, sometime the PhyTask got suspended.
Workaround:
Try not to reseat the backcard too often. If the front card gets stuck during the power-on, try to reseat the front and back card to bring the system.
|
CSCdr19636
|
Symptom:
When there is mismatch between the dsplns alarm status and dspalms output.
Condition:
On a T3 card, if one side of the line is configured as adm mode and another as plcp mode, then the lines go into alarm. dsplns shows the lines in critical alarm, but dspalms or dspalm -ds3 on one of the lines says clear.
Workaround:
On the line that has plcp enabled use dspalm -plcp bay.line to see the alarm. The problem has now been fixed in such a way that even dspalm -ds3 bay.line on a plcp line will show its plcp alarm status.
|
CSCdr20887
|
Symptom:
After the trunk card comes back from reset, vsierr 0x5017 messages and [egress ConnID add failure] messages are observed.
Condition:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.
(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.
(4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through one trunk (TRK_A_BETWEEN_NODE_EP1_AND_NODE_VIA) while the other turnk (TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA) is downed.
(5) A [uppnport] is executed to TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA.
(6) Reset this trunk card (hosting TRK_A & TRK_B) while in [down in progress] state.
Workaround:
One of the following: (1) Do not reset trunk card while rerouting takes place. (2) If the failure has already occured, rectify this problem by doing [resetsys] on every PXM45 in the network.
|
CSCdr22185
|
Symptom:
VsiErr message with a string explaining the error such as
"Interslave timeout" and others get displayed; these messages
are indications of a recoverable condition and are not
meant to be displayed.
Conditions:
These messages can show up when the system is under stress, such
as on system rebuild, and VsiErr due to real errors are meant
to be displayed, but instead warning VsiErrs are displayed
Workaround:
None
|
CSCdr22569
|
Symptom:
ABR connections fail.
Condition:
There are parallel links at via node(s) to the next node on the routing path (DTL) of an ABR connection.
Workaround:
Don't configure parallel links at via nodes
|
CSCdr23168
|
Symptom:
Resetting the AXSM UNI card in the edge node while the PNNI is establishing connections on it might intermitantly cause the tVsiSlave task to crash on the AXSM UNI when it eventually comes up.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.
(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.
(4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks.
(5) Reset NODE_EP1.
(6) While SPVCs are being established (about 15K), reset the AXSM UNI card.
(7) After the AXSM has come up, a lot of VsiErrs are observed, and then the tVsiSlave task crashed.
Workaround:
(1) Do not reset the UNI AXSM while the PNNI is rebuilding the connections.
|
CSCdr34387
|
Symptom:
A few SPVCs are not seen after resetsys. Not all SPVCs on any one interface have been lost.
Condition:
Happens when a node is fully loaded to 50K connection capacity.
WorkAround:
Avoid connection addition during heavy connection re-routing, link status changes.
After the problem has occurred - SPVCs can be re-added.
|
CScdr35241
|
Symptom:
After reseting the AXSM (UNI) card in endnode, and performed pxm45 switchover while the port is still in down in progress, once the AXSM card is up, and all uni ports are in "up" state, vsi error 0x502a (connection reserve failure) are observed.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.
(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.
(4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks.
(5) Reset the UNI card in NODE_EP1.
(6) While the port is in "down in progress" state, perform pxm45 swithover.
(7) VsiErr 0x5017 are observed once the UNI AXSM card is up and all UNI ports are in "up" state.
Workaround:
One of the following: (1) Do not perform pxm45 swithover while any of the UNI port is in "down in progress" state. (2) If the failure has already occured, rectify this problem by resetting the UNI card.
|
CSCdr36772
|
Symptom:
Bucket statistics file name has incorrect file name.
Conditions:
Suppose the file is created at 5:30 it will have a time of 5:15. The interval is 15 to 30 min. This means that the beginning time is used instead ofthe ending time.
WorkAround:
None.
|
CSCdr36954
|
Symptom:
VC Failure due to insufficient LCNs used up by the user conns. The port stays in VC failure forever.
Conditions:
When more SPVCs are provisioned than the available LCNs, the port could go into VC failure upon few resets on the controller or the Slaves. This happens because of failure conditions to establish connections and if user connections could be established before the control VC connections.
Workaround:
Never provision more than the available LCNs.
|
CSCdr37025
|
Symptom:
Some of the provisioning command operation does not get reflected on standby and disk.
Condition:
When there are many spvcs are getting added/deleted/modified within ver short period of time and also at the same time many ports status is oscilatting between up and down in that case this may happen.
Work Around:
When port status is oscilating, do not add/mpdify/delete spvcs on it.
|
CSCdr37302
|
Symptom:
Unable to ping/telnet to the node intermittenly.
Conditions:
This problem occurs in a redundant PXM node. When ping the node from a workstation, the ifShow command shows that the receiving packet counts is inrementing while the send packet counts remains the same.
Workaround:
Reconfigure the interface with the same IP address again using command
|
CSCdr38809
|
Symptom:
After restoring the configuration using restoreallcnf command, and controller card switchover happend, the some of the SPVC end points may be missing and/or the attributes of some of the VCs may be changed.
Condition:
When restoreallcnf is performed, the configuration on the disk is overwritten by the restored configuration on the Active controller card and the configuration needs to be cleared on the Standby controller card before it could synchronize the configuration with that on the Active controller card. This clearing of configuration on the Standby controller card is not done as a part of restoreallcnf. This causes the problem.
Workaround:
You need to clear the configuration using clrallcnf before restoring the configuration. You should make sure that the Standby controller card is in operational state when configuration is cleared. If the Standby controller card is not in operatinal state when clrallcnf was performed on the node, you should clear the configuration on the Standby controller card when the card is in the boot state using sysClrallcnf command.
|
CSCdr39120
|
Symptom:
Reset of AXSM cards and switchover will cause SPVC to reroute.
Condition:
When ILMI is turned on the AXSM, when reset the Peer ILMI module will trigger a Loss of Connectivity and all the calls on the interface will be derouted.
Workaround:
If Using Orion 1.0.x or P-II 2.0.x, disabling the Securelink procedures will not allow the calls to be derouted (cnfilmiproto command can be used to turn off Secure link on a port basis). If not using the above, there is no workaround as secure link is enabled on NNI/UNI links.
pxm1Cli> cnfilmiproto <portid> -securelink no
- turns off the securelink on the NNI trunks. By default its turned on for all the interfaces.
|
CSCdr40126
|
Symptom:
If there are more than 31K connections on a single AXSM in a VIA node, the connections on the AXSM are not deleted when PNNI deroute the connection.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.
(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.
(4) There are 31K+ SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks.
(5) Down either of the trunk connecting either NODE_EP1 or NODE_EP2 to the NODE_VIA to cause connections deroute. After the deroute completes, it was observed that the connections in the NODE_VIA are not deleted, and no error were observed.
Workaround:
(1) Restrict the number of connections on the NODE_VIA to less than 31K. This can be done by configuring the partitions for NNI trunks on the NODE_VIA to support less than 31k connections (combined).
|
CSCdr40620
|
Symptom:
NO SPVCS. After PXM rebuild some interfaces might disappear.
WITH SPVCS Every time PXM card (both cards in case of redundancy) is rebooted, Node cannot come up. pnRedman may be in exception.
Condition:
If any image built between Apr 21, 2000 & Apr 29, 2000 had been used in a node, then there is a possiblity for data base corruption, which will lead to this problem.
Workaround:
No workaround.
|
CSCdr43257
|
Symptom:
Some of connections are not routed. Route trace shows that no route found because no enough bandwidth. Since the network is very complecated (113 nodes + 300 links), it is very difficult to issolate the problem. It may or may not be a bug. It need to be investigated with enhanced trace utility.
Conditions:
Large network: (113 nodes + 300 links)
Workaround:
Increase bandwidth (cell rate, LCN, links) on critical path.
|
CSCdr43665
|
Symptom:
The call does not routing with VPI/VCI assignment error.
Condition:
When you have big number of calls (around 16K) in one interfaces and switch-over.
Workaround:
Do not do switch-over when call is in progress and # of calls is around 16K.
|
CSCdr45695
|
Symptom:
Could not run "dspln", dspports, etc. Could not walk mib tables.
Conditions:
The "dsplog" CLI output might contain following message:
01-00127 05/12/2000-11:14:26 MIBS-4-SEMTAKE_FAILED E:06412 snmpSA 0x8012a2f8 snmpMibSemTake_104: Semaphore Take failed for singleThrMibFuncSem, return value 0xfffffffe.
tSmCmdTskcl: doMibTbls(): Can't get resrc semaphore.: Err from snmpMibSemTake 01-00104 05/12/2000-09:21:54 MIBS-4-SEMTAKE_FAILED E:06409 tSmCmdTskc 0x8012a2f8 snmpMibSemTake_104: Semaphore Take failed for singleThrMibFuncSem, return value 0xfffffffe.
Work around:
The Card which has this problem(dsplog -sl <x> has the above message) will have to be reset.
|
CSCdr46104
|
Symptom:
Exception in pnCcb task causing the active processor to
reset.
Condition:
Observed on derouting and rerouting SPVCs over an IISP link.
Workaround:
None.
|
CSCdr47947
|
Symptom:
After reseting the AXSM (UNI) card in endnode, and performed pxm45 switchover while the port is still in down in progress, once the AXSM card is up, and all uni ports are in "up" state, vsi error 0x502a (connection reserve failure) are observed.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.
(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.
(4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks.
(5) Reset the UNI card in NODE_EP1.
(6) While the port is in "down in progress" state, perform pxm45 swithover.
(7) VsiErr 0x5017 are observed once the UNI AXSM card is up and all UNI ports are in "up" state.
Workaround:
One of the following: (1) Do not perform pxm45 swithover while any of the UNI port is in "down in progress" state. (2) If the failure has already occured, rectify this problem by resetting the UNI card.
|
CSCdr50312
|
Symptom:
Standby card will be reset and come back in the higher revision ( 2.0(1) )
The card will then transition to the failed state.
Conditions:
Upgrading gracefully ( through the loadrev command ) on the PXM with
redundancy available ( 2 PXMs in the node ) between release 2.0(0) and 2.0(1)
Workaround:
Do a non-graceful upgrade by using the setrev command
This will cause the PXMs to be reset and come back in the higher revision
setrev 7 2.0(1)
|
CSCdr19861
|
Symptom:
Lot of VsiErr messages appear on the console.
Conditions:
(1) In a two node PNNI network with 2 NNI trunks, one with OC48 and other with OC-12 link.
(2) Add connections beyond OC-12 capacity into the OC-48 trunk.
(3) Reset the Node, if the OC-48 trunk comes up in the down state, or if the OC-48 is downed, the connections get re-routed to the OC-12 trunk.
(4) If the bandwidth capacity of the exceeds the OC-12 trunk, AXSM will reject the connections commit request beyond the interface capacity.
(5) PNNI tries to PACK in as many connections as possible into the OC-12 trunk. Some of the connection ADD requests are rejected by CAC.
Workaround:
(1) Use trunks of the same link capacity.
|
CSCdr25037
|
Symptom:
Many [vsierr] messages and [egress ConnID add failure] messages are reported by the trunk card on NODE_EP1 while the rebooted UNI card does NOT have error messages.
Conditions:
In a three-node network with two nodes (NODE_EP1 & NODE_EP2) connected directly as well as via a third node (NODE_VIA), approximately 5000 SPVCs are added between NODE_EP1 and NODE_EP2.
All of these AXSM cards operate in stand-alone (e.g., non-redundant) mode.
The UNI card in NODE_EP1 is rebooted (by resetcd from PXM45 or ESC-CTRL-X).
Immediately after the PXM45 console reports the insertion of the UNI-AXSM, a [switchcc] command is issued.
Workaround:
One of the following: (1) Do not [switchcc] at all. (2) Do not [switchcc] until the rebooted UNI-card is burning the flash (by observing a few cycles of [burning xxxxx verify ... ok] messages) (3) If the failure has already occured, rectify this problem by doing [resetsys] on every PXM45 in the network.
|
CSCdr26669
|
Symptom:
This problem rarely happens. link presents with 2WayInside state, but no route through that link found.
Conditions:
Parallel PNNI links between adjacent nodes.
Workaround:
Down then up the link.
|
CSCdr27033
|
Symptom:
Clock source does not revert back to primary bits clock when revertive mode enabled. This can also appear in the form that clock is not switched to a valid clock source that should have a good clock signal.
What is really the case is that the clock source has been previously declared as unuseable/unlockable by the clock source manager. This clock source will not be chosen again until after clock source reconfiguration.
Condition:
The clock source manager is the traffic cop for maintaining the correct/best clock source and managing the state of all clock sources. To make sure that the current clock source is valid, frequency and phase error tests are continuously run on the clock source. Should there ever be a sample that shows invalid frequency or phase error, the clock source is placed into "out of lock" state and a more intensive test is done on the clock source. If this intensive test shows enough failure, the clock source is declared unlockable.
To determine if a clock source has been labelled as unuseable, there are two methods:
1. From shellconn issue command nclkm_status. Look for the MUXA/MUXB "programmed as" lines of the display. If the source is programmed as "TOP SRM", it has been labelled as unuseable.
2. From shellconn issue command dspclockinfo. If clock source is configured but programmed to NULL, then it is labelled as unuseable. (NOTE: This display is in the process of change to be more clear about this special clock source state.)
Workaround:
Reconfigure the clock source, even if it is to the same exact configuration to clear the unlockable state. Use cnfclksrc command.
|
CSCdr27718
|
Symptom:
The SSCOP, PNNI protocol states would not be in Established state, two_way inside respectively. The protocol PDUs will be discarded at SAR level.
Conditions:
When an UNI/NNI interface is configured on the Line card.
Workaround:
If the problem persists for sometime, bring the interface administratively down and then administratively UP.
|
CSCdr28767
|
Symptom:
The SSCOP, PNNI protocol states would not be in Established state, two_way inside respectively. The protocol PDUs will be discarded at SAR level.
Conditions:
When an UNI/NNI interface is configured on the Line card.
Workaround:
If the problem persists for sometime, bring the interface administratively down and then administratively UP
|
CSCdr28772
|
Symptom:
Some pnni ports with ILMI on go down temporarily and come up. The calls are derouted and rerouted back.
Condition:
This happens on a large network which has 50k spvc endporints. The node has at least 14 trunks spread accross 6 BXM cards. Pull out one of the cards and re-insert the card.
Workaround:
This is temporary glitch on few nni ports. This happens intermitently. There is no work around yet.
|
CSCdr29013
|
Symptom:
Much lower via node reroute rate when attemping to reroute SPVCs at a higher call rate than nodal setup msg congestion threshold value.
Condition:
When massive SPVCs are being rerouted because of resetting some nodes in the network or when trying to setup SVC connections at a very high call rate.
Workaround:
Try not to exceed call setup rate of 100calls/sec for SVCs or SPVC reroute at this stage.
Additional Information:
Root cause of the problem has already been identified; with the fix, call setup acceptance rate is going to be stablized around the nodal setup msg congestion threshold, not going to drop dramatically when call attempting rate goes higher.
|
CSCdr31492
|
Symptom:
Some of the connections remain in fail state.
Condition:
Execute dnpnport on an NNI interface, it goes into down in progress state. Before the interface goes into the down state reset the AXSM having some endpoints that go through the NNI which is in down in progress. (Assuming the AXSM doesnot conatin that NNI interface).
Workaround:
This problem is not yet solvet it has no known work around.
|
CSCdr34225
|
Symptom:
Cell drops are noticed on OC3 with default line rate.
Conditions:
The line rate specified for OC3 is 353208 cells/sec. But, infact it is 353207.55 cells/sec. So cell drops are noticed if traffic is pumped in at 353208 cells/sec.
Workaround:
Use following rates( cells/sec )as max line rate for: Max rate for OC3: 353207 Max rate for OC12: TBD Max rate for T3 and E3: TBD Max rate for oc48:
|
CSCdr34707
|
Symptom:
Calls will not go through.
Condition:
The address PTSE is present in the database but the address is not present in the network reachable address table.
WorkAround:
None.
|
CSCdr34851
|
Symptom:
After addpart with incorrect parameters, the partition gets added on AXSM, but dsppnports on PXM45 either doesn't show the port, or it shows the IF status as provisioning.
After delpart, dsppnports shows the IF status up for the port on the PXM45, although dspparts on the AXSM doesn't show the partition anymore. There is no error message displayed.
Conditions:
Two conditions seen in our lab that caused this problem: - clock configured on the line associated with the partition, delpart doesn't fail, but partition removed from the database, but PNNI doesn't get informed of partition delete - tried to add partition on a vnni port with incorrect vpi range, partition added to the database, but PNNI doesn't get informed of the partition add
Workaround:
Workaround after the conditions are seen is to do resetsys on PXM45.
|
CSCdr36903
|
Symptom:
ILMI fails to transition to a steady state and PNNI ports may not come up. As a calls might fail to route or use another available heathy trunk.
Conditions:
PXM switchover with ILMI enabled. If the ILMI protocol across the peer have not reached a steady state this problem has been noticed intermittently.
Workaround:
dnpnport and uppnport the affected port(s) after the switchover is complete.
|
CSCdr39329
|
Symptom:
Few connections will be in fail state at one end point(either master end or slave end)
Conditions:
This happens when a large number of connections are established and then some line cards are reset.
Workaround:
None
Additional Information:
If the problem persists, attempt reroute for the failed connections from CLI
|
CSCdr39684
|
Symptom:
Cannot display link selection configured on PNNI port.
Conditions:
ILMI (auto-config) is enabled on the port.
Workaround:
disable ILMI (auto-config) on PNNI port.
|
CSCdr39892
|
Symptom:
The symptoms of this problem is that all traffic that is coming into the axsm card is being discarded. Specifically, ingress traffic does not go into the switch planes and since the queues in the QE48 gets full, the incoming traffic reaches the maximum cell threshold and all cells are discarded.
Conditions:
This problem may occur if the axsm card experiences multiple (more than 32) switch plane errors. Switch plane errors such as lost of sync, code violation, crc error, disparity error. Since switch plane error may occur during pxm45 switch cc's, this problem may also occur during pxm45 switch cc's.
Workaround:
Reset the axsm card that is not passing traffic.
|
CSCdr40167
|
Symptom:
User see sometimes SPVC fail to route spvc connection on AXSM card resets
Condition:
Repeated AXSM card resets on the POPEYE2 node OR repeated BXM card resets on BPX node
Workaround:
none
|
CSCdr40333
|
Symptom:
User did not have the granularity to find out why the clock when bad.
Condition:
A clock can go bad due to excessive jitter, high frequency, etc.
Workaround:
User would have to go to the clock source and verify functionality with the source equipment to find out the reason.
|
CSCdr40484
|
Symptom:
User did not have the granularity to find out why the clock when bad.
Condition:
A clock can go bad due to excessive jitter, high frequency, etc.
Workaround:
User would have to go to the clock source and verify functionality with the source equipment to find out the reason.
|
CSCdr40821
|
Symptom:
Some SPVC conns are in AIS-FAIL in standby
Conditions:
a. resedcd (PXM or BXM) b. dnpnport/uppnport (PNNI trunk) c. rebooting via nodes
Workaround:
switchcc the PXM.
|
CSCdr41012
|
Symptom:
Ports go to Down in Progress after Reset/Downing the AXSM. This is due to failure to resync the connections.
Conditions:
When large number of connections are to be resynced after a line card recovery, the control connections (signalling and routing) fails to be reinserted.
Workaround:
None.
|
CSCdr41170
|
Symptom:
After changing T3 line framing mode from ADM to PLCP, continuous vsi error messages are reported on ASXM.
Conditions:
Existing connections have used up all bandwidth corresponding to ADM framing mode (104268 cps).
Workaround:
When T3 framing mode is changed, check if the new line type cell rate is less than the SG rate sum of existing SG belonging to the line. If so, reject the command.
|
CSCdr41708
|
Symptom:
After the switchover, the new active Pxm still shows that the above inserted backcard is still missing. This will eventually cause an extra switchover when a healthier standby Pxm is ready.
Conditions:
If inserting a backcard into the standby Pxm's slot resulted in making the standby Pxm the healthier card, the standby Pxm will be made that active Pxm.
Workaround:
If backcards on both Pxms are missing/bad, always replace/insert the backcard on the active Pxm first. This will not trigger the above switchover and bug.
|
CSCdr42075
|
Symptom:
port(s) in "vc failure"
Conditions:
Have svc calls, with active and standby pxm. Pull the active
pxm and reset card, causing switchover.
Workaround:
None.
|
CSCdr43945
|
Symptom:
One can exceed the peak cell rate upto line rate thereby starving all resources to other connections. This is due to the fact that OAM and RM cells do not get policed.
Conditions:
Add a connection and pump non-user-data cells e.g OAM/RM cells using a tester or CPE.
Workaround:
For policing complience test use User data cells only.
|
CSCdr44255
|
Symptom:
Svc call on uni port getting released.
Conditions:
Make a svc call on uni(3.0/3.1) port using a tester. Pullout and put back the cable between the node and tester within 10sec(T309).
Woekaround:
This problem occurs alternately. There is no work around yet.
|
CSCdr44537
|
Symptom:
The connection does not pass the data traffic.
Condition:
The UBR SPVC provisioned with PCR=0 and resync happened.
Workaround:
Do not provision pcr=0. Reactivate the connection using dncon/upcon command.
|
CSCdr44566
|
Symptom:
Dax connections are in FAIL state
Condition:
Did a resetsys on the PXM
Workaround:
Check the endpoint interface, do a dnpnport and uppnport on those interfaces, the connection should be in ok state
|
CSCdr45063
|
Symptom:
The address or address prefix associated with a PNNI node at a lowest level peer group, if not summarized by any of the default or configured summary address, may sometimes be failed to be advertised arocss the peer group boundary even when its advertising scope is wide enough.
Conditions:
Assuming a hierarchical PNNI network originally works fine with an address A that associated with a node N at the lowest level, and A is seen as advertised across the peer group boundary just fine. Reboot the node N and A may be missing across the peer group boundary, when the identifier of the address PTSE for A differs from the one before the reboot.
Workaround:
The root of the problem has been found and a fix has been put in and verified as a correct resolution.
In this fix, the PTSE ID is now stored in the local reachable address Trie of a LGN, along with the node index of the node at the child peer group. As such, the identification of a given entry in the local reachable address Trie includes both the node index of the node and the PTSE ID at the child peer group. Note this handling is the same as already existed for network reachable address Trie.
|
CSCdr45896
|
Symptom:
1. The problem is not observable, but the problem can be identified/observed when the traffic parameters are verified by doind "dalConnParamsShow" after de-routing the connections from one trunk to another on a different card
Conditions:
1. 2 Node PNNI network 2. 2 AXSM trunks on 2 different cards 3. De-Route connections from one trunk to another trunk in another card
Workaround:
Don't de-route/re-route conns between trunks across trunks on different cards. Use multiple trunks if needed on the same card.
|
CSCdr45962
|
Symptom:
Some SPVC conns are in AIS-FAIL in active PXM after switchover
Conditions:
After multiple switchover of PXM
Workaround:
issue following command on shellconn of newly active PXM.
For axample,
pxm1> conProEnableConnTrap conProEnableConnTrap
|
CSCdr46262
|
Symptom:
When switchover occurs, all the master / slave endpoints are attempted to route / half commit, and it will hit congestion, which will not recover dspnodalcongflags will show connpendingflg set to TRUE.
Condition:
1000s of non routed master / slave SPVCs are configured on a port which is operationally down. & switchover occurs.
Workaround:
Manual Switchover : Do not try switchover
Automatic Switchover : None
|
CSCdr46945
|
Symptom:
The PNNI main task is looping when calling pnni_delete_db_ptse() for a horizontal link.
Conditions:
The PNNI main task loops infinitively in the function pnni_delete_db_ptse() when the PTSE deleted is a horizontal link.
Workarounds:
None
|
CSCdr47590
|
Symptom:
After Switchover Standby(newly active) doesn't have the same number of SPVCs as Active had before.
Condition:
When we have failure on AXSM or some port which has many thousands SPVC.
WorkAround:
None
|
CSCdr47777
|
Symptom:
After rebooting AXSM or BXM card, the OC3 sonet alarm are reported on both AXSM and BXM.
Conditions:
When connecting OC3 trunk between AXSM and BXM, if the AXSM or BXM card is reset, OC3 sonet alarms are reported on both BXM and AXSM. AXSM reports red alarms while BXM reports yellow alarm.
Workaround:
Physically pull out the Tx cable from BXM and reinsert it.
|
CSCdr48075
|
Symptom:
CWM has difficulty understanding the contents of a SNMP trap when retrieved from the RTM MIB.
Conditions:
The robust Trap Manager Mechanism support from an MGX8850 is not properly working. An additional internal data structure is being prepended to the SNMP Trap PDU.
Workaround:
There is no known workaround.
|
CSCdr50497
|
Symptom:
dspsct command does not display proper information.
Conditions:
dspsct to display content of an SCT file in PXM Disk.
Workaround:
If the SCT is already applied to an active port/card, use dspcdsct or dspportsct command to display the contents of the sct. For the SCT files not applied to any port or card, there is no workaround available on MGX platform. Use CWM to display contents of such SCTs.
|
S2 Bugs
|
CSCdm87251
|
Symptom:
When multiple applications are sending IPC message with urgent option, the sequence of these urgent messages are not maintained by the receiving task. However, the sequence of urgent messages from the same sending task will be maintained.
Condition:
When multiple applications are sending IPC message with urgent option, the sequence of these urgent messages are not maintained.
Workaround: don't use this option until the feature is supported. Currently
no applications are using this 'urgent' option.
Note: If a sending task does not have to maintain sequence of urgent messages with other task(s), i.e., sequence only needs to be maintained on a per-source task basis, then this urgent option can still be used.
Only if multiple sending tasks are sending one stream of urgent messages which need to retain the order when they arrive at the receiver task, then it may create a race condition until this feature is supported.
Workaround:
None
|
CSCdr06568
|
Symptom:
Trap number 60061 not received by CWM when AXSM T3/E3 self test fails.
Condition:
This trap is not supported at this time.
Workaround:
None
|
CSCdr07794
|
Symptom:
The "task NwClockMgr is suspended" is seen on the PXM console. Clocking services are not available when the NwClockMgr is suspended.
Condition:
Resetting the PXM or reseating the UI backcard can trigger the network clock manager to suspend.
Workaround:
Reseating the UI card, follow by resetting the PXM card may resolve this problem.
|
CSCdr19400
|
Symptom:
VSIM on the edge-node stops communicating with the slave when the via node is reset.
Condition:
It is found that VSIM stops communicating with its slave when the via node is reset or ILMI downed. It is found that VSIM has exhausted all the IPC buffers and there are no more IPC buffers to use. It has manifested in the timer handling functions not working (not being invoked) and thus VSIM is sitting idle without taking any actions. VSIM keeps all the messages Queued up in it's databases and no actions are being taken.
Workaround:
Reset the node.
|
CSCdr19527
|
Symptom:
OC3 UNI port down in progress after multiple dnport/upport and switchcc
Condition:
The two-node was configured with 10K SPVC conns.
1. resetcd each AXSM card in order.
2. Sleep about 1000 seconds
3. dnport 1/upport 1 on OC3 cards ten times for two nodes.
4. switchcc on one node (B1b)
5. repeat step 1 again.
Workaround:
dnport 1/ upport 1 again, if this doesn't work then reboot PXM
|
CSCdr19861
|
Symptom:
VsiErr Messages appear on the console.
Condition:
(1) In a two node PNNI network with 2 NNI trunks, one with OC48 and other with OC-12 link.
(2) Add connections beyond OC-12 capacity into the OC-48 trunk.
(3) Reset the Node, if the OC-48 trunk comes up in the down state, or if the OC-48 is downed, the connections get re-routed to the OC-12 trunk.
(4) If the bandwidth capacity of the exceeds the OC-12 trunk, AXSM will reject the connections commit request beyond the interface capacity.
(5) PNNI tries to PACK in as many connections as possible into the OC-12 trunk. Some of the connection ADD requests are rejected by CAC.
Workaround:
Use trunks of the same link capacity.
|
CSCdr19985
|
Symptom:
Sometimes some of ports (with ILMI on) going to ILMI query status and ILMI state becomes Undefined state.
Condition:
1. Remove the active PXM45 card, switchover takes place.
2. Reinsert the PXM45 card back.
3. Display the ports.
Workaround:
Down the port and then up the port.
|
|
