Downloads |
Table Of Contents
Release Notes for Cisco MGX 8950, Software Release 3.0.00
New Features and Enhancements in Release 3.0.00
DSL Access Support — Single-ended SPVC Configuration
Network Clock Distribution Protocol (NCDP)
Simple Network Time Protocol (SNTP)
Clear Service Module Configuration (clrsmcnf)
SCT File Management and User-Configurable Names
Detection of Non-native Controller Front Card and HDD Card
Service Class Template (SCT) File Information
Software/Firmware Compatibility Matrix
MGX and RPM Software Version Compatibility Matrix
Additional Compatibility Information
New Hardware in Release 3.0.00
MGX 8950 Product IDs and card types
Limitations, Restrictions, and Notes for 3.0.00
MGX Release 3.0.00 Limitations
Maximum Threshold Accuracy for PXM45
Non-native Controller Front Card and HDD Card
Limitations and Restrictions for PNNI Features
Other Limitations and Restrictions
Clearing the Configuration on Redundant PXM45Cards
Limitations and Restrictions for 2.1.x
General Limitations, Restrictions, and Notes
Limitations for rteopt via parallel links
Installing and Upgrading to Release 3.0.00
Installation and Upgrade Procedures
Quickstart Procedures for Software Upgrades
Copying Software Files to the Switch
Upgrade Procedures for PXM45 and AXSM Cards
Troubleshooting Upgrade Problems
Cisco WAN Manager Release 11.0.00
Cisco MGX 8850 (PXM45) Multiservice Switch Release 3
Cisco MGX 8850 (PXM1E) Multiservice Switch Release 3
Cisco MGX 8950 Multiservice Switch Release 3
Service Expansion Shelf PNNI Controller Release 3
Cisco MGX 8830 Multiservice Switch Release 3
Cisco WAN Switching Software Release 9.3.40
MGX 8850 (PXM1) Multiservice Switch Release 1.2.10
MGX 8250 Edge Concentrator Release 1.2.10
MGX 8230 Edge Concentrator Release 1.2.10
Documentation on the World Wide Web
Contacting TAC by Using the Cisco TAC Website
Known Anomalies in Release 3.0.00
Anomalies Resolved in Release 3.0.00
Known Route Processor Module or MPLS Anomalies
Release Notes for Cisco MGX 8950, Software Release 3.0.00
Contents
About Release 3.0.00
These release notes describe the system requirements, new features, and limitations that apply to Release 3.0.00 of the MGX 88950 multi-service switch. These notes also contain Cisco support information.
For PXM45-based switches (that is, MGX 8850 (PXM45) and MGX 8950), MGX Release 3.0.00 provides the tools for more powerful scaling. MGX Release 3.0.00 allows networks based on the MGX 8850 (PXM45) or MGX 8950 to scale to new heights in supported connections, going from the current 40K to 100K persistent connections per node, in addition to up to 150K transient connections. MGX Release 3.0.00 also allows service providers to expand ABR with VS/VD capability on the MGX 8850(PXM45) platform by doubling the number of ports supported on the AXSM/E cards.
These release notes accompany the technical manuals listed in the "Related Documentation" section.
For information about the MGX 8850 (PXM45), MGX 8850 (PXM1E), or MGX 8830 release 3.0.00, see the "Release Notes for Cisco MGX 8850 (PXM45/B and PXM1E) and MGX 8830, Software Version 3."
Type of Release
Release 3.0.00 is a software release for the MGX 8950 switch.
Locating Software Updates
This is the location for the MGX 8950 software:
•
ftp://ftp.cisco.com/cisco/wan/beta/0598xgm.
New Features and Enhancements in Release 3.0.00
Release 3.0.00 contains these new features:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
ITU APS on AXSM/B for PXM45
APS provides redundancy on SONET/SDH equipment to protect against line failure or fiber cut. APS permits the network to react to failed optical lines and/or optical interfaces by switching to an alternate line. This release supports the international standards ITU-T G.783 Annex A and B APS on AXSM/B optical modules. APS 1+1 intercard redundancy requires use of an APS connector (MGX-APS-CON) to connect adjacent back cards.The complete list of architecture mode supported by software is:
•
•
•
•
•
ITU-T APS on AXSM/B is supported on the MGX 8850 (PXM45) and MGX 8950 switches. ITU-T APS on AXSM-E is supported on MGX 8850 (PXM45).Benefits
For a line failure, the detection and signaling of the failure occurs within 10 ms and the switchover occurs within 50 ms. For a card failure, the recovery will occur in less than 250msec. Using APS is a faster way to recover than can be achieved with Y-cable redundancy or ATM layer rerouting.
DSL Access Support — Single-ended SPVC Configuration
The feature enables configuration of both the endpoints of the SPVCs at the master end of the connection. With the feature, the connection needs be provisioned using the double ended provisioning model. The slave end of the connection is activated when the connection is established by the master end. This feature provides the ability to provision single-ended SPVC connections that originate on the DSLAM.
The Single-ended SPVC Configuration feature is supported on the MGX 8850 (PXM45), MGX 8950, MGX 8830, and MGX 8850 (PXM1E) switches.
Benefits
This feature enables improved interoperability with other vendor equipment and management stations.
250K Connections
The 250K Conns feature improves the scalability of the existing PXM45 node from the current 100K connections to 250K connections. This feature is supported only on the version B of the PXM 45 card with 256M of memory. On a single node, there can be a maximum of 250K SPVC/SPVP and SVC/SVP connections, where a maximum of 100k connections are persistent, and the other 150K connections are non-persistent. However, a node will support 250k persistent connections if it is not managed by CWM.
The number of persistent connections are limited by the number of connections supported by CWM, which is currently 100K.
The 250K Connections feature is supported on the MGX 8850 and MGX 8950 switches with PXM 45 version B cards.
Benefits
Customers can provision more connections on each switch.
Path and Connection Trace
The Path and Connection Trace feature allows the user to determine the path taken by a connection. The Path Trace feature is used for new connections in the process of being established. The Connection Trace feature is used to collect information on existing connections that have already been established. The Path and Connection Trace feature supported in the previous releases is based on the pre-standard version of the ATM Forum specification. In the current release the Path and Connection Trace feature will conform to ATM Forum standard PNNI Addendum for Path and Connection Trace, Version 1.0 af-cs-0141.000.
The Path and Conn Trace feature is supported on the MGX 8850 (PXM45), MGX 8950, MGX 8830 and MGX 8850 (PXM1E) switches.
Benefits
Standards based feature enables interoperability with other vendor equipment.
Network Clock Distribution Protocol (NCDP)
Network Clock Distribution Protocol (NCDP) is the means by which an accurate clock source is chosen by a node and is distributed to the rest of the nodes within a network for the purpose of ensuring synchronized network operation. NCDP based clocking provides resiliency of clock sources in a network which is vital for delay-sensitive traffic like video and voice traffic and allows the network to proactively switch clock sources rather than waiting for the quality of the active clock source to degrade.
NCDP is disabled by default. The only configuration required to enable the clock distribution is to enable it, then add the clock source references. NCDP can be turned off on a nodal basis or an interface basis. NCDP supports clock distribution to 200 nodes in the network. If the network is larger than 200 nodes, it should have multiple clocking domains with separate clock sources.
NCDP is supported on the MGX 8850 (PXM45), MGX 8950, MGX 8830, and MGX 8850 (PXM1E) switches.
Benefits
The implementation of NCDP based clock distribution on the MGX 8800 enables service providers to deploy large scale networks with integrated clocking suitable for delay sensitive data transfer.
Simple Network Time Protocol (SNTP)
Simple Network Time Protocol (SNTP) based time of day synchronization enables MGX 8800 nodes to have network time synchronization. Accurate time of day service is provided by synchronizing to Universal Time Coordinated (UTC) time. The standard based approach allows the switch to synchronize to any SNTP/NTP time server. This provides accurate time for statistics and alarms generated on the switch and enables accurate synchronization of such events between switches. The BPX uses a similar protocol for time distribution, but with the addition of SES, the BPX can also be synchronized using SNTP. In a network of BPX 86xx and MGX 88xx switches, time must be set on the BPX in order to be distributed consistently throughout the network.
SNTP is supported on the MGX 8850 PXM45, MGX 8950, MGX 8830 and MGX 8850 (PXM1E) switches.
Benefits
The SNTP Server functionality allows MGX 88xx and BPX 86xx switches to act as SNTP servers for the network.
Priority Routing
Priority based routing allows customers to specify the priority of connections. The priority allows high priority connections to be established before low priority connections. During failures, the high priority connections are also released before low priority connections. This action enables rerouting and reestablishment of high priority connections earlier than low priority connections.
This feature is supported on the MGX 8850 (PXM45), MGX 8950, MGX 8830, and MGX 8850 (PXM1E) switches.
Benefits
The customer can offer prioritized services based on connection priority.
Per Connection Overbooking
The Per Connection Overbooking feature for SPVCs provides improved control of network utilization for multiple tiers of service on a network supporting various trunk capacities. The percentage utilization factor is used for Connection Admission Control for the connection. The actual bandwidth used for Connection Admission Control for the connection is based on the PCR/SCR configured for the connection and the percentage utilization factor configured for the connection, combined with the percent utilization configured for interfaces in the selected path.
Overbooking means that less bandwidth is reserved for a connection, however it can use more bandwidth. The feature will enable overbooking to be performed on a connection basis.
Per Conn Overbooking is supported on the MGX 8850 (PXM45), MGX 8950, MGX 8830, and MGX 8850 (PXM1E) switches.
Benefits
This feature enables service providers to provide differentiated overbooking on a per connection basis rather than only on a uniform basis allowed by interface overbooking.
Preferred Routing
Preferred routing of connections provides the network operator a means of bypassing the PNNI route selection, and configuring a specific path through the network by which a connection will follow. Preferred routes can be configured as either Preferred or Directed routes. A Preferred route is a route which will follow the configured path if available, but will revert to a PNNI-selected route if the preferred route is not available. A Directed route is a route which will follow only the configured path; if the configured path is not available, the connection will remain unrouted.
In this first implementation of Preferred routes, a set of preferred routes is configured and assigned reference numbers, referred to as route sets. As connections are configured, they can be assigned to a particular route set. Each route set can currently contain one preferred (or directed) route.
Preferred routes can currently be specified only across a single PNNI peer group.
Since the preferred route is placed in the PNNI DTL by the source node, preferred routes are interoperable with any standard PNNI implementation.
Preferred routing is supported on the MGX 8850 (PXM45), MGX 8950, MGX 8830, and MGX 8850 (PXM1E) switches.
Benefits
The customer can control the selection of routes based on criteria other than those allowed in the route selection algorithms offered by PNNI.
Clear Service Module Configuration (clrsmcnf)
The clrsmcnf feature clears the configuration for a particular service module slot without affecting the configuration of other slots. This feature clears the configuration from both memory and disk (persistent). The clrsmcnf command will be a blocking command and the service module will be unavailable for provisioning during the entire duration of the command.
The clrsmcnf feature is supported on the following modules.
•
Benefits
The clrsmcnf feature does not impact or clear the configuration of the entire shelf (clrallcnf), it only clears the configuration for a particular slot thereby limiting the impact.
Disk Sync Verify
This feature provides a verification utility to check the synchronization of the disk "data" between the active PXM and standby PXM hard disks in the D:/DB2 directory. This disk synchronization verification utility provides a method of checking the "data" between the active PXM and standby PXM hard disks when invoked through CLI. This new CLI command, dskdbverify, invokes the task of verifying the "data" between the active PXM and standby PXM hard disks. This CLI command can be invoked both on the active PXM and standby PXM.
AXSM Virtual UNI
A new port type called Virtual UNI (VUNI) is defined in addition to the already defined port types - UNI, NNI, VNNI (Virtual Trunk). This feature benefits both the MPLS and PNNI control plane.
Virtual UNI is supported on the MGX 8950 switch with the AXSM/B line cards.
Benefits
Customers can provision multiple Virtual ports each with a VP range on one physical line and thus allow transport of PNNI SPVPs. This feature removes the restrictions in previous releases with Virtual Trunks (VNNI) wherein only one VP could be defined so only SPVC could be transported across those VNNI interfaces. With Virtual Port an MGX, that is not configured with MPLS control plane (LSC) but is expected to transport PNNI and MPLS traffic to a neighboring switch configured with both MPLS and PNNI, can utilize this feature by defining a combination of VUNI (0-255 VP range) or VNNI (0-4095 range) or a VNNI (one VP only) on a single Physical ATM port thus allowing trunking as well as terminating traffic on a single physical port.
Virtual port allows the flexibility of defining separate Service Class Templates per logical Virtual port. This allows customers to engineer different behaviors of traffic on different logical ports on the same physical line.
Persistent Topology
The Persistent Topology feature enables CWM to maintain a persistent topology information of the entire network. One or more nodes will be designated as gateway nodes. Whenever CWM needs info about the network, it will query gateway nodes to collect necessary information. Gateway nodes are defined to be nodes from which CWM can query for information on the nodes contained within a peer group. A node needs to be configured to be a gateway node in every peer group through CLI or CWM before it can be used as one.
This feature will deliver the following functionality:
Cumulative collection of node info for topology database. Node info will contain nodeId, nodeName, lanIP, atmIP, sysObjId.
•
•
•
Benefits
This feature is useful to monitor the entire network as information of all the nodes irrespective of their state will be available to the CWM. It enables service providers who deploy large scale networks to keep track of the all the nodes in the network.SCT File Management and User-Configurable Names
This features implements version control for the SCT files such that the SCT files can have a major version, which would keep track of the parameters being added/deprecated, and a minor version to address limitations. A SCT management MIB was created to keep CWM and the switch in sync with respect to the MIBs. The SCT MIB contains a version parameter, and can be used to convey the minor and major versions of the SCT file. When the SCT file is modified by the user, the user can save the file as a new file or as a different version of the SCT file.
Detection of Non-native Controller Front Card and HDD Card
With this feature the runtime firmware detects when a controller front card or HDD card from another shelf/node is inserted into a node in the standby controller card slot. When the firmware detects a non-native PXM1E front (that has hard disk) or HDD back card is inserted into a node in the standby controller card slot, all the contents, except the contents in the C:FW, C:SCT, F:SCT and the image files and auto configuration files in the E:RPM, on the hard disk in the standby controller card slot will be deleted and the event log files will be backed up.
In other words, when a non-native hard disk is detected in the standby controller slot, the following files and directories will be preserved, event log files are backed up and everything else, including event log files, will be deleted on the non-native hard disk:
•
•
•
•
As a result of this feature, the hard disk on the standby controller slot no longer needs to be manually cleaned up when it is moved from another shelf/node.
Enhancements
The product enhancement requests (PERs) in Table 1 were introduced in Release 3.0.00.
Service Class Template (SCT) File Information
This section contains SCT file information for Release 3.0.00.
AXSM and AXSM/B
•
•
•
•
The check sum for the SCT files are as follows
•
•
•
•
•
•
•
•
A user can do dspsctchksum <filename> to confirm that the checksum of the Cisco-released SCT file and the file on the node match.
System Requirements
This section describes software compatible with this release, and lists the hardware supported in this release.
Software/Firmware Compatibility Matrix
Table 2 lists Cisco WAN or IOS products that are interoperable with Release 3.0.00.
Table 2 MGX 3.0.00 Compatibility Matrix
MGX and RPM Software Version Compatibility Matrix
Table 3 lists the software that is compatible for use in a switch running Release 3.0.00 software. Note that the AXSM/B cards use the same software as AXSM cards.
Additional Compatibility Information
The RPM IOS releases are as follows:
•
•
Additional Notes
The following notes provide additional compatibility information for this release:
•
•
•
•
•
•
Hardware Supported
This section lists Product IDs, 800 part numbers, and revision levels for MGX 8950 cards. It also list MGX 8950 front and back card types, and whether APS connectors are supported.
New Hardware in Release 3.0.00
There is no new hardware for MGX 8950.
MGX 8950 Product IDs and card types
Table 5 lists Product IDs, 800 part numbers, and revision levels for the MGX 8950.
Table 6 lists MGX 8950 front and back card types and whether APS connectors are supported.
Note
New and Changed Commands
Refer to the "MGX 8850, MGX 8950, and MGX 8830 Command Reference, Release 3" for details about new and changed commands. This manual is available online at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm. To access it, click on the switch name (for example, MGX 8850 (PXM45), click on Release 3, and then click on the Command Reference link.
Limitations, Restrictions, and Notes for 3.0.00
This section includes information about limitations, restrictions, and notes pertaining to MGX Release 3.0.00.
Note
MGX Release 3.0.00 Limitations
Maximum Threshold Accuracy for PXM45
There is a limitation regarding the maximum threshold accuracy for the PXM45 and PXM1E. The Qbin threshold and VI rate are stored in the form of exponent and mantissa, and some accuracy is lost in expressing the real rate. In testing the thresholds, the lack of accuracy is compounded with both of the Qbin and VI rate (draining rate) and therefore we cannot calculate a exact 100% correct discard rate.
To ensure that the user gets the rate that they have specified, the software configures Qbin depth at the next larger rate which the hardware can support. As a result, ICG and RSD are truncated. In this example, we have the following scenario:
(Refer to anomalies CSCdw89558, CSCdw85738, CSCdw89101, CSCdw89123)
Disk Space Maintenance
As the firmware doesn't audit the disk space usage and remove unused files, the disk space in C: and E: drives should be manually monitored and any unused saved configuration files, core files and firmware files and the configuration files of the MGX-RPM-PR-256/512 and MGX-RPM-XF-512 cards should be promptly deleted manually to avoid shortage of disk space to store event logs, configuration upload files in the C: drive and the configuration of MGX-RPM-PR-256/512 and MGX-RPM-XF-512 cards in the E: drive.
Non-native Controller Front Card and HDD Card
When a non-native PXM1E or HDD back card is inserted in the Standby controller slot, the firmware doesn't clean up the drives which have free disk space below 30%. So, when the standby controller card comes up, it needs to be verified whether the contents have been cleaned up or not.
When a non-native PXM1E or HDD back card is inserted in the Standby controller slot, the firmware doesn't clean up the non-auto configuration files in the E:RPM directory. These non-auto configuration files in the E:RPM directory have to be manually cleaned up after the Standby controller card becomes ready.
Due to the checks for non-native cards, when the controller front or HDD cards are swapped in the same node, the controller card that attempts to come up as Active may get reset twice.
When a non-native HDD card is inserted into the standby controller slot, verify, after the card becomes ready in the standby controller slot, its hard disk contents are deleted and synchronized the relevant files from the Active card.
clrsmcnf Limitations
For the clear service module configuration feature, if there is a controller card switchover before the clear service module configuration operation is complete, the clrsmcnf command needs to be re-issued to ensure that the configuration is completely cleared to avoid any incomplete cleanup.
For the clear service module configuration feature, using the clrsmcnf command may result in discrepancy in the PNNI configuration. For example, some connections may be in the mis-match state.
If the clrsmcnf command is given with the option to clear the software version for the slot as well, then the card will go into the failed state after the operation is complete.
While using the clrsmcnf command, the card in the specified slot is not usable until the operation has successfully completed.
APS Limitations
For AXSM-B APS, the backcard of the active card MUST be present for APS to function
New commands dspadjlnalm and dspadjlnalmcnt are now supported on AXSMB
Port LED lights on AXSM-E front cards indicate the receive status of physical line connected to it only when the card is in active state. For a standby AXSM-E card, the LEDs always remain green whether the lines are in LOS irrespective of which lines are Active (CSCdv68576).
Limitations and Restrictions for PNNI Features
PNNI requires SCR=453 cells/sec and PCR=969 cells/sec for the control connection.
SSCOP requires SCR=126 cells/sec and PCR=2000 cells/sec.
Path and Conn Trace
1. Path trace is not supported on the control port.
2. Path trace will not have the accurate information when there is a crankback on the connect path.
3. Path and Connection trace feature in Release 3.0.00 is not compatible with the path and connection trace available with previous releases
SNTP
The CWM MIB is not supported in Release 3.0.00.
Priority Routing
•
•
•
•
•
•
•
•
SPVC Interop
1. NNI SPVC Addendum Version 1.0 is not supported.
2. PNNI 1.0 Addendum (Soft PVC MIB) is not supported.
3. Terminating single-ended SPVCs on MSSBU switch Legacy Service Modules is not supported.
4. Origination of Single ended spvcs (with -slavepersflag) from Legacy Service Modules (FRSM, CESM, VISM & RPM) is not supported.
5. CC (Continuity Check) shall not be available at the slave end of a single-ended SPVC.
6. Reporting AIS detection to CWM shall not be available at the slave end of a single-ended SPVC.
7. tstdelay shall not be available at the slave end of a single-ended SPVC for POPEYE2. In case of Orion, the command is available from the PXM even for the slave endpoint.
8. The slave end of a single-ended SPVC shall not be visible to CWM.
9. If Single-ended SPVCs are originated from MSSBU switches, they can only be configured via CLI and not from CWM in the current release.
10. Single-end Provisioning will not be supported for DAX connections as no value addition is seen for Interoperability.
11. SPVC Statistics shall not be available for the slave endpoint of a single-ended SPVC because this endpoint is non-persistent.
12. When the persistent slave endpoint of an existing SPVC connection is deleted and the master endpoint is allowed to remain, the connection may get established as a single-ended spvc connection. In this case, CWM will show the connection as "Incomplete"
14. Override of SVC connections on a VPI due to an incoming SPVP request for that VPI is not supported The following override options are alone supported:
•
•
•
Preferred Route feature
a) The preferred routes can be specified only within a PNNI single peer group meaning all the nodes in the preferred route lie within the same peer group.
b) All the nodes in the network should be running Release 3.0.00 software to use preferred route feature
c) All the links specified in the preferred should be PNNI links
d) If any of the nodes in the pnni network changes its pnni node id, then the old entry in the persistent topology database in all the nodes in the network need to be deleted. If any of the preferred routes in any of the nodes in the network contains the changed node as one of the hops, then the preferred route(s) has to be modified using the new table index (in the persistent topology database) allocated for the changed node.
e) If any of the nodes in the pnni network is deleted via configuration commands from the persistent topology database, if any of the preferred routes configured at that node (where the delete command is executed) contains the deleted node as one of the hops, then the preferred route(s) has to be deleted/modified manually.
f) If any of the nodes in the pnni network is removed via physical de-commissioning and if any of the nodes in the network had some preferred routes that contain the removed node as one of the hops, then the preferred route(s) has to be deleted/modified manually.
g) Due to differences in physical port numbering, non-MSSBU nodes can only be the terminating nodes in a preferred route.
h) When a connection is routed on a route other than its preferred route and if the preferred route becomes available, the connection would not be automatically de-routed to route back to its preferred route. The user has to de-route/re-route using configuration commands. (optrte, rrtcon, dncon/upcon etc)
Persistent Topology Feature
1. In a mixed network of pre-Release 3.0.00 and 3.0.00 or later nodes, only the node name and the node id will be shown for a pre-Release 3.0.00 node in the topo DB. This is because the feature is not present in pre-Release 3.0.00 nodes.
2. If a peer group is made up of physical nodes with pre-Release 3.0.00 release logical nodes, then the info for the logical node will be stored in the Topo DB, because there is no way to distinguish between physical nodes and pre-Release 3.0.00 release logical nodes. Logical nodes with Release 3.0.00 or later SW release will not be stored in the Topo DB.
3. To delete a node info entry from the Topo DB, first remove the node itself from the network, either by disconnecting the cables, or downing all the links between that node and the network. Wait for an hour. Then, delete that node from the topo DB. This is done because, even if a node is removed from the topo DB of all nodes in the peer group, its PTSEs will still be stored in the other nodes, until they are flushed from those nodes. This would happen within an hour's time, but it is configurable as a PNNI timer value. If the node is deleted from the Topo DB within that hour's time, and the node does switchcc/reboot, then it's possible that the node info for that deleted node will be added back into the topo db.
4. When the node id of a node is changed, the old node id is added back into the Topo DB as a new node entry. In addition, the old node id will still be stored in the topo DB of all the other nodes in the PG. In order to delete this entry, wait for an hour so that the PTSEs with the old node id is flushed from the DB of all the nodes in the PG, and then delete the info of the old node id from the topo DB.
5. It is possible that the gateway nodes are not in sync in a peer group, and this could happen in many situations. For example, a gateway node is added in a peer group, then a node is deleted from the PG, and another gateway node is configured, then the info for the deleted node would not be in the second gateway node. Another example is that a node is deleted from one gateway node, but not in another gateway node.
6. When deleting a node from the PG, the node info must be deleted from all the nodes in that PG, even the non-gateway-node nodes. Otherwise, the node info for that deleted node will still be in the non-gateway-node nodes. This could cause inconsistencies later if this node is configured to be a gateway node.
NCDP
1. FRSM:NO clock sources supported on FRSM. So if the root clock is chosen to be a port on FRSM it will be a bad clock source for us and we will compute a new root clock source. Ideally No clock source should be configured on FRSM.
2. If a clock source goes bad there is no way to find out if it has become good. If the user wants NCDP to consider that clock source again he/she needs to re-add the clock source
3. Suppose a root clock source is configured on NBSM which is in redundant configuration. If a switchover of the NBSM is done there *might* be loss of clocking for some time.
4. Currently there is no way for the user to know what is the secondary (second best) clock source in NCDP mode. This might create problems for the user if he/she is trying to delete/modify the partition on the line carrying the secondary best clock source.
5. Revertive option is not provided in NCDP.
Manual Clocking
•
•
•
•
RPM-PRLimitations
Starting with Release 3.0.00, Route Processor Module (RPM) cards have their own release notes. For details on RPM cards, refer to the "Release Notes for Cisco MGX Route Processor Module (RPM/B and RPM-PR) for MGX Release 1.2.10 and MGX Release 3.0.00". These release notes are available online at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm. They are found under the switch name (for example, MGX 8850 (PXM45), Release 3, Route Processor Module, Release Notes.
Restrictions
Formatting Disks
The hard disks should not be formatted with the Release 3.0.00 backup boot or runtime firmware. The Release 3.0.00 firmware initializes the disks with DOS File System Version 2.0 where as the earlier 2.x releases use DOS File System Version 1.0. As a result, if the hard disks are formatted with Release 3.0.00 firmware, those disks will become unusable in nodes running Release 2.x firmware. Since, Release 3.0.00 firmware is backward compatible, it can use hard disks with DOS File System Version 1.0.
Saving Configurations
The C disk drive should not be used for saving multiple older configurations, images, and core dumps. The disk space on this drive is needed to save event logs and configurations, and the logs and configurations will not be correctly saved if there is inadequate disk space.
Other Limitations and Restrictions
•
•
•
•
•
•
•
•
Clearing the Configuration on Redundant PXM45Cards
Due to checks to prevent an inserted card from affecting the system, an additional step may be required when inserting two "non-native" PXM45 cards in a shelf. Insert the first PXM45, do a clrallcnf, and allow this to become active before inserting the second PXM45.
After a clrallcnf, the user needs to explicitly clean up stale SCT files (refer to anomaly CSCdw80282).
Limitations and Restrictions for 2.1.x
This section is extracted from the MGX 2.1.79 release notes. It describes the following issues for Releases 2.1.60 through 2.1.80:
•
•
•
General Limitations, Restrictions, and Notes
The following limitations and restrictions apply to this release.
Note
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Limitations for rteopt via parallel links
The following are limitations for rteopt via parallel link.
link 1 . . . . . .. . . .. . . . .link 2
Node A ------------- Node B -------------- Node C
fwd & bwd aw= 500 fwd & bwd aw= 1000
-------------
link 3 fwd & bwd aw = 2000
Configuration:
•
•
•
•
Scenario 1: Link 2 is down (e.g., via dnpnport), connections are re-routed right away but Node A hasn't had that info updated in the routing tables yet.43
So SPVC on Node A will have routing cost = 2*500 + 2*1000 = 3000, but since link 2 is down, Node B will choose link 3. But the routing cost on Node A SPVC is still 3000 as it did the calculation during the route search.
Now if link 2 is up, if you do rteopt on Node A, it gets the new route, the new path selected has a cost of 3000.
Since spvc has 3000, it doesn't re-route through link 2.
Scenario 2: Instead of link 2 down, if there is a crankback on link 2, the same result stated above will happen.
Scenario 3 (for CBR and VBR): link selection is set as maxavcr or maxcr or random on node B (via cnfpnni-selection) If link 2 has less bandwidth than link 3, and the link selection criteria at Node B is set to maxavcr, Node A will still put the cost as 3000 with least aw calculation, but Node B will choose link 3 (even though it is costlier) because it has more bandwidth.
Scenario 4 (for ABR and UBR): link selection doesn't apply to ABR and UBR. (via cnfpnni-selection. This is exactly the same as Scenario 3 as ABR and UBR follow load balancing on parallel links instead of choosing the minaw link.
Scenario 5 (for all types of service categories): After call setup, if the admin weight is increased on the link on which the call is routed, the routing cost calculated during the call setup will not get changed. So if a rteopt is done after increasing admin weights on the existing links on the connection path, the connections will not get optimized to take the newer path.
Workaround
If you dnpnport on link 2 (connections will be routed via link 3), after uppnport on link 2, then use cnfpnni-intf to change the existing admin weight on link 2 to lesser value, e.g., 800 (from 1000).
So when optrte is executed at Node A, routing cost will be = 2*500 + 800(fwd) + 1000 (bwd) = 2800 for the new route of link 2.
Since all SPVC connections have 3000 as the routing cost, connections will be rerouted on link 2.
Important Notes
This section provides general notes that apply to this release, and covers some procedures that are not yet in the manuals.
•
•
•
•
•
•
