Crn Tj100me r6.3

download Crn Tj100me r6.3

of 19

description

Tejas

Transcript of Crn Tj100me r6.3

Release Note TJ100MERELEASE: R6.3(TXC7 Software Bundle TPN: 130-SW0000040-S, Rev 1.0) Date: 3/6/2014 Copyright by Tejas Networks 2000-2014 All Rights reserved worldwide.

This document contains information that is the property of Tejas Networks India Ltd. This document may not be copied, reproduced, reduced to any electronic medium or machine readable form, or otherwise duplicated, and the information herein may not be used, disseminated or otherwise disclosed, except with the prior written consent of Tejas Networks Tejas Networks reserves the right, without prior notice or liability, to make changes in equipment design or specifications.

Table of Contents

51. Product Information

51.1 Software Bundle

51.2 Software Bundle

62. Limitations and Workaround

62.1 General Limitations

72.2 Open Issues

152.3 New features added in release 6.x

163. Fixed Issues

163.1 Field Issues fixed in the release

184. Upgrade Procedure

18Supported Upgrade Paths Summary

184.1 Upgrade Procedure requiring Special Considerations

184.1.1 Software Upgrade Procedure for XC16ME05 from MER5.5 to MER6.3 having ELAN04s-R1 cards.

194.1.2 Software Upgrade Procedure for XC16ME05: MER5.5 CA (REL_5_3_12_a29_10/REL_5_3_12_a29_13) to ME-R6.3 having ELAN04s-R3 card.

204.2 Upgrade Procedure from ME R6.0/6.1/6.2 to ME R6.3

215. Technical Support Centre Contact Details

Chapter

1

1. Product Information1.1 Software Bundle

TPN : 130-SW0000040-S: Software bundle TPN : 130-SW0000040-S: CRN.

1.2 Software Bundle

TPN : 400-SW0000017-S : Rev1.0 : TJ5500 TPN : 400-SW0000016-S : Rev1.1 : TJ5100Chapter

22. Limitations and Workaround2.1 General Limitations1. PDH Port protection is not allowed to be configured on Cards under Card protection.

2. EOW call will not be supported with the Overhead Tunnel in passthrough nodes.

3. In service Line rate downgrade is not supported with XC160ME01, XC16ME05, and XC4ME01 cards.

4. Engineering orderwire supported with aggregate ports only and on Redundant systems only(In TXC7 works only with Port-1)

5. Wrong TPID values on the ingress would cause a traffic drop. In case of an upgrade being done, please check the ingress TPID values to ensure that they are correct.6. Active electrical SFPs(which support auto-negotiation) are not supported.7. MPLS-TP configuration should be done from the NMS only. Node side provisioning is not supported.8. Customized TCA profiles for ETH ports on ELAN04-R3 is not supported9. Hitless restart on ELAN04 card is applicable only for normal restarts. In case the card software crashes, then the restart would be a cold restart.

10. Flow point edit feature has been disabled in this release

11. DS0CC provisioning with mixed mode setup can cause issues over a power cycle under the following conditions; a] Slot 7 is the master b] Provisioning is done without any warm restart/cold restart given. This combination of actions is rare and therefore these issues would not be prominent. In case these issues come, switchover back to the slot7 XC, everything should come back up again.2.2 Open Issues

135346| Interval Validity is shown as 0 for current day and previous day countersSynopsis: Interval validity is shown as 0 for all interfaces and flow points on ELAN04-R1/ELAN04-R3 cards for current day and previous day counters.Workaround: None.Customer Impact: Not much, counter values are correctly captured on the node. However, on the NMS, the counters for current day and previous day would be shown as Invalid.134644 |Previous day counters for VCG ports not shown post LPG switching Synopsis: Previous Day counters for VCG ports are not shown post multiple LPG switches. Workaround: A warm restart may solve the issue.Customer Impact: Minor. The issue itself is a rare occurrence and does not impact operations per se. Service level counters can be referred to in case of debugging any issues.103129: | TXC7: Force Switch Active alarm clears over power cycle and MSP states are not proper.Synopsis: In MSP, when Forced Switch to Protect is given without any fault on the work path, followed b y a Power Cycle, then the Force Switch Active alarm gets cleared over power cycle. The MSP switch status shows No request. But if there is a SF/SD on work prior to FS, then there is no issue over a power cycleWorkaround: NoneCustomer Impact: Major: In case there is SF on WORK before giving cold reboot to the system, and we give FS to protect. Then after cold reboot, the MSP state m/c is fine. This is typical field scenario where the FS to protect will be applied on MSP in case there is SF on W. In this scenario, MSP comes up properly after Cold reboot/Power cycle to node.111839 | FDB addresses on LAG FP are not flushed, on introducing link down on member ports of LAG (Distribution Mode).Synopsis: On Link Down on Member ports of LAG, the FDB addresses on LAG FP are not flushedWorkaround: FDB entries will be flushed after fdb timerCustomer Impact: Minor. Station Movement is implemented hence new path will be re-learnt for same MAC address. Also the FDB entries will be flushed after fdb timer.134603 | File system full alarm seen after multiple restartsSynopsis: On a system with almost 200 services, when multiple restarts happen, the /etc partition in the node gets filled up and this causes a file system almost full alarm to be raised.Workaround: The number of services cannot be 200, the limit where everything works fine is 100-120 services. In case the customer reaches this state, then remove the PM folder and give a warm restart to reduce the usage of space on the /etc partition. Customer Impact: Critical, if provisioning gets disabled when the /etc folder gets filled up.133531 | ELAN04 card crashes when bandwidth profile with CIR/PIR = 64/65 kbps is usedSynopsis: When bandwidth profiles with CIR/PIR values as 64/65 Kbps is used, then the internal chip driver crashes, due to which there is a traffic hit.Workaround: Change the ingress bandwidth profile to any other values other than 64/65 Kbps, and this issue would not be seen.Customer Impact: Major. However, once the workaround is applied, there should not be any issue with the card.101328 | EOPDH for VCG_E3 with TMUX card is not supported when E3 is in framed modeSynopsis: LOF is reported on E3 ports of TMUX when Framed E3 traffic is carried over VCG_E3 in EoPDHWorkaround: Use Unframed ModeCustomer Impact: Major. Cannot use Framed E3 for EoPDH application. Using E3 for EoPDH is a rare deployment.92641 | Defragmentation of telecom bus is not supported for mixed granularity. In Sonet VC11 is supported and SDH VC12 is supportedSynopsis: Telecom Bus defragmentation will not work as expected when VCG with mixed granularities are provisionedWorkaround: Some cases extra VC11 cross connects need to be deleted to accommodate SDH equivalent BandwidthCustomer Impact: Major; But mixed granularity of VC11 and VC12 in same VCG is not a deployable scenario.83363 | Collecting debug data for EoPDH card leads to 'Connection timeout'Synopsis: Connection timeout is shown when collecting the debug data for ELAN04-R3 card. This happens when the Data size is huge and the FTP timeout exceeds. Though timeout is shown, the data is actually collected. User can again go to the link and collect the debug dataWorkaround: Again click on the link to collect the dataCustomer Impact: Misguiding message. User will have to again go to the same link to collect the debug data.131661|Traffic goes down on deletion of protect pseudowire, with traffic running on the same

Synopsis: When traffic is running on the protect pseudowire in a MPLS service, and the user deletes the protect pseudowire, traffic does not switch to the work pseudowire on its own.Workaround: Do not delete the protect pseudowire when traffic is running on the same. This can be checked easily from the NMS. Switch the traffic away from the protect pseudowire and then delete the pseudowire.Customer Impact: Major, in case the customer deletes the protect path from NMS for re-routing the same, then traffic will go down, which may not be desirable.130756 | First tunnel protection switch after a restart takes 3-6 secsSynopsis: In a MPLS tunnel setup, after a restart, if the protection switching is triggered for the MPLS tunnel, then the first switch takes 3-6 secs to complete.Workaround: None.Customer Impact: Major. Restarts are common in the network due to various reasons, and protection switching will not meet the 50 ms goal.101116 | Broadcast/Multicast frames counter are not incrementing for jumbo frame in ELAN04-R3Synopsis: The Broadcast and Multicast Frames counter statistics for Jumbo frames are not updatedWorkaround: NoneCustomer Impact: Major.Will not get Jumbo frame statistics101257 | ACPSU status in WUI shows up even without power feedSynopsis: The Card status is shown up and present for ACPSU even when power feed is not connectedWorkaround: NoneCustomer Impact: Major. As alarm and performance monitoring is not available in WUI for ACPSU card, customer will not be able to get proper status of card from WUI will not be able to see power is coming or not on ACPSU card100426 | Terminal In-Band NIU loopback is supported only when monitoring type is selected as Alarm Monitoring. It is not supported when monitoring type is selected as Alarm and Performance MonitoringSynopsis: NIU loopback is supported only for DS1 ports configured as monitoring type as Alarm MonitoringWorkaround: Define Alarm Monitoring only during troubleshootingCustomer Impact: Minor. Customer will need to change the monitoring type to Alarm Monitoring during troubleshooting114471 | Traffic won't work according to Storm Control/DLF control, if it is applied while creating FP.Synopsis: On applying Broadcast/DLF Storm Control during Flow Point creation, the profile will not get applied.Workaround: Apply the Profiles after creation of Flow PointsCustomer Impact: Minor. If the profile is created during FP creation, the traffic won't work according to desired profile.Customer will have to apply the profile again after creation of Flow Point

120173 | LAG port's MTU is fixed to 1522.Traffic with MTU more than 1526 is droppedSynopsis: The MTU size of LAG is fixed to 1522. Because of this frames with MTU more than 1526 are dropped .Workaround: Set the frame size to less than 1526Customer Impact: Major. For Variable frame size packets, the packets more than 1526 frame size will be dropped.130242| Continuous crash observed when the number of hardware flows exceeds the card capability in ELAN04-R3Synopsis: When services are created on the ELAN04-R3 card which exceed the number of hardware resources available, then the card goes on a continuous reboot, till the number of services are reduced.Workaround: Delete a service which is not being used. In order to avoid this, the total number of services on the ELAN04-R3 card should not exceed 150 at the maximum.Customer Impact: Major, since the card would be unusable from a customer perspective130081| Loss measurement counters are not proper on pseudowiresSynopsis: Loss measurement counters on the pseudowires do not show the correct values for loss measurement. Even when there is no loss of packets the counters would display a loss.Workaround: A warm restart may clear the wrong values.Customer Impact: Major. Loss measurement is used to indicate the stability of the link and some random values would give the wrong picture to the customer.127035|ELAN04-R3 card did not come up on a cancel upgrade from R6 to R5.01Synopsis: On doing an upgrade to the R6 release, if for any reason the node software build reverts back to R5.01, then the ELAN04-R3 card would not come up until a cold restart is given to the system.Workaround: Cold restart the system, the card recovers post the cold restart.Customer Impact: Major. A build can get reverted during the upgrade process due to various reasons like node crash etc. When such things happen, the ELAN04-R3 card would not come up and would need to cold restart the system for the card to come up.

126651| ELAN04-R3 port level counters are showing junk values when the card is under rebootSynopsis: When the ELAN04 card is under reboot, then an attempt to view the port/service level counters would show junk values in the performance page.Workaround: Do not try to view the performance level counters when the card is down in the system. Check if the card is up before trying to view the performance counters.Customer Impact: Major. The junk values are 20 digit numbers which once viewed, remain in the performance interval, and add up to the day counters as well.

122044| Pseudowire CCM interval of 10 ms with tunnel CCM interval of 3.3 ms is not supportedSynopsis: Pseudowire CCM interval of 10 ms, with the tunnel CCM interval set as 3.3 ms is not supported, and when a tunnel switching is triggered, then the pseudowire also switches over.Workaround: None. This is a hardware limitation. In order to mitigate the impact, NMS defaults to 100 ms for the pseudowire CCM interval, so that this issue may be rarely encountered.Customer Impact: Major. Multiple hits may be seen in the traffic, when one fiber cut would happen.

117642|Memory exceeded alarms raised due to continuous protection switching of services

Synopsis: In a setup which has close to 200 services, continuous protection switching of the MPLS services, would cause the ELAN04-R3 card to go out of memory.Workaround: The maximum number of services which can be supported on this card should be 120. Any more configuration would run the risk of hitting this issue.Customer Impact: Major. Traffic can go down since the card would not have enough memory to process link down events and trigger protection switching.

130364|Switching time on Copper ports participating in a LPG group is high

Synopsis: If an LPG group is made with copper ports, then the LPG switching time is high, around 1 sec for tunnels with 3.3 ms as CCM interval.Workaround: None, the LPG group could be made over fiber ports which have better response times to link down events.Customer Impact: Major. The customer expectation of 50 ms switching for MPLS services will not be met.126963|Traffic goes down on ports with autonegotiation disabled, over an upgrade from R5.01 to R6Synopsis: Autonegotiation disabled operation on a fiber port causes the link to go down over an upgrade to R6 release, thereby causing the traffic to go down as well.Workaround: None, the issue can be avoided if auto-negotiation is enabled on the fiber ports. This is the standard expectation, and therefore should not be diffucult to achieve.Customer Impact: Major. Traffic would go down over an upgrade, which would result in an unnecessary outage.2.3 New features added in release 6.xFeatures added on the ELAN04-R3 card

1. Support for MPLS-TP services and protection. Support for tunnel level protection as well as pseudowire level protection.

2. Support for LSP ping and traceroute for debugging of MPLS-TP services.3. Support for Y.1731 based OAM on MPLS-TP services.4. Support for threshold crossing alerts on flow points for monitoring of Tx and Rx packets.5. Support for tagging enable/disable on egress interfaces.6. Support for Transparent LAN services on UNI interfaces.

7. Support for binning of performance monitoring for interface level counters.8. Support for BPDU tunneling on services.9. Support for MTU of 9612 bytes on Eth and VCG ports.

10. Support for 600 Flow Points per card.

11. FPCR edition for VLAN values.Features added on ELAN04-R1 card

1. Support for threshold crossing alerts on flow points for monitoring of Tx and Rx packets.2. Support for tagging enable/disable on egress interfaces.3. Support for Transparent LAN services on UNI interfaces.4. Support for binning of performance monitoring for interface level counters.5. Support for hitless warm restart.6. Support for BPDU tunneling on services.Features added on DS0CC card

1. Support for mixed mode provisioning on DS0CC card. Allows for grooming of DS0 connection from DS1 to E1 and vice versa2. Support for framer level alarms on DS0CC internal ports

3. Support for NXDS0 channels, for providing higher bandwidth servicesChapter

33. Fixed Issues

3.1 Field Issues fixed in the release

162189 | Router connected Eth ports not coming UP post soft. upgradationIn the previous release, it was observed that if auto-negotiation was disabled on the optical ports of the ELAN04-R3, then over an upgrade to R6.2, the ports would not come up. This issue has been fixed and now auto-negotiation disabled is supported on the optical GigE ports. Upgrade would not bring the ports down when auto-negotiation is disabled.175044 | TJ100ME_ELAN04-R3_Traffic Down issue when node goes for a watchdog resetIn the previous release, it was observed that if the LPG is switched to the protect card and the system goes for a watchdog reset for any reason, then the traffic goes down. This was because watchdog reset was not handled correctly in the software. This has now been fixed and watchdog reset does not cause any hits in the traffic running on the ELAN04-R3.

167171, 168701, 169006, 173259, 171760, 173260, 173822, 174422, 174920, 182927 | ICF alarm fluctuating on slot 6/7 cards of XC16ME05 and Memory Usage exceeded threshold on primary XC16ME05It was observed that the ICC alarm was fluctuating and the secondary card was not up. This was root caused to the fact that due to Radius being enabled on the system and a large number of alarms toggling on the interfaces, the system runs out of file descriptors which are used for all the operations on the NE. This causes the system to run out of memory and cause all sorts of unpredictable behavior. This issue is fixed in the firmware of the TXC7 card.174407 | Authentication Alarm toggling issue after RADIUS implemetationIt was observed that the authentication alarm was fluctuating. There was no reason for this alarm to come since no user was trying to login at that time. This was root caused to the fact that due to Radius being enabled on the system and a large number of alarms toggling on the interfaces, the system runs out of file descriptors which are used for all the operations on the NE. This causes the system to have all sorts of unpredictable behavior. This issue is fixed in the firmware of the TXC7 card.

172607 | ELAN04R3 traffic not switched to protection path.It was observed that on a crash in the ELAN04-R3 card, traffic did not switch to the protect card. The crash happened in flushing of the dynamic FDB, which has now been fixed. Also, on a crash of any of the agent modules of the ELAN04-R3 card, a LPG switch would take place. This would cause a hit in the traffic till the work card comes up. On all other crashes, there would be no traffic hit and no LPG switching action would happen.

175878, 176126, 176368, 176636, 182521, 165708, 176623, 165708 | VCG traffic on ELAN04-R3 goes down on its own, comes up only on changing the VCG port It was observed that traffic running on VCG interfaces of the ELAN04-R3 card go down on its own since the software was not able to read the correct VCG port number from the hardware. It is not known as to why this happens and therefore a defensive fix is introduced by virtue of which the software would correct the VCG port number on its own in case the value read from the hardware was wrong. This should ensure that traffic does not go down due to this issue.Chapter

44. Upgrade Procedure Supported Upgrade Paths SummaryReleaseBase cardCA buildSpecial Upgrade ConsiderationField Upgrade path

ME-R5.5XC16ME05REL_5_3_12_a29_10/

REL_5_3_12_a29_13Yes for

ELAN04-R3 &

ELAN04-R1Direct

ME-R6XC16ME055_3_11_a61_1NADirect

ME-R6XC16ME055_3_11_a61_11NADirect

Note: For the Upgrade Procedures with Special Upgrades Considerations, refer to the corresponding section

4.1 Upgrade Procedure requiring Special Considerations4.1.1 Software Upgrade Procedure for XC16ME05 from MER5.5 to MER6.3 having ELAN04s-R1 cards.1. This upgrade is supported for all the ME-R5.5 releases, i.e 5312a29_10/a29_132. Prior to the upgrade, check that any ingress bandwidth profiles present in the config with CIR/PIR as 64 Kbps/65 Kbps, and change the same to CIR/PIR as 66 Kbps before the upgrade.3. Upgrade the firmware of the TXC7 card first to 1_19 from the WUI. Perform a warm restart for the system to get upgrade to firmware 1_19.4. Once node comes up, there would be firmware mismatch alarms present on the node UI. Ignore the same.5. Upgrade to the R6.3 release 5_3_11_a61_14 using the unified upgrade procedure.6. Issue invoke upgrade and check that the NE comes up after the upgrade.7. Once the node comes up, ELAN04R1 firmware needs to be upgraded to 1_7 from the UI. Give a cold restart to the card. The cold restart is mandatory since there is a change in the microcode of the ELAN04S card.8. Traffic Hit in this case would be in any case less than 26 min (for two card system)

4.1.2 Software Upgrade Procedure for XC16ME05: MER5.5 CA (REL_5_3_12_a29_10/REL_5_3_12_a29_13) to ME-R6.3 having ELAN04s-R3 card.1. Copy all the Software and Firmware builds for TXC7 and ELAN04-R3 from CD to location on Server or Local PC.2. Download the firmware of the TXC7 card (ver 1_19) from the UI and provide a warm restart to the node so that the firmware gets upgraded. Once the NE comes up after the upgrade, there would be a firmware mismatch alarm, which can be ignored. Ensure that there are no Cold restart FPGA changed alarms on the ELAN04-R3 card. In case there is a Cold restart required FPGA changed alarm present on the ELAN04-R3 card, then perform a cold restart to the card, and then proceed further.3. Perform a unified upgrade to ME-R6.3 release 5_3_11_a61_14.4. Check that node comes up and there are no firmware mismatch alarms present on the node.5. Download ELAN04-R3 firmware 1_5 from the UI. Once downloaded, issue a cold restart to the ELAN04-R3 card. This cold restart is mandatory since there is a change in the micro-code in this release.

6. Total outage time for the ELAN04-R3 traffic would be 30 mins.4.2 Upgrade Procedure from ME R6.0/6.1/6.2 to ME R6.3For all the above mentioned Upgrade paths, follow the Unified Upgrade Procedure. There is no change in the ELAN04-R3 firmware, so only TXC7 needs to be upgraded. Refer to the UI guide for details on the Unified Upgrade Procedure. This upgrade can also be done from the EMS, supporting the bulk upgrade procedure. There would be no traffic hit during the upgrade since the upgrade is a warm restart only, which is hitless.Chapter

55. Technical Support Centre Contact Details

Tejas Networks provides technical support to its customers through email, phone and skype.

Helpline: 080 41719090 (Hunting Line)

080 26591080

080 26591082

Fax: +91 80 2659 1081

E-mail: [email protected]: tscsupport123

Website: www.tejasnetworks.comTejas Networks Limited

1