B11MR3ED1.1QD1.1升版指导手册v2

B11MR3ED1.1QD1.1升版指导手册
版本入网证：
B11MR3ED1.1QD1.1的CMCC版本号为：BSSSAZ04D01
F:\My Documents\
桌面\B11 全国升版\入
文档：
TSIO：fpd_az11a
GCD: gcd_az11a_pc
一，B11MR3ED1.1QD01的相关性能
F:\My Documents\
桌面\B11 全国升版\产
二，B11升版前的检查内容
工具软件准备
按B11_MR3_Ed1.1QD1.1_CDE准备
B11_MR3_ED1.1_QD1
.1_CDE_20110715_for_
CHECK LIST
F:\My Documents\
桌面\B11 全国升版\c
三，注意事项
OMCR：
注意事项1：
OMCR B11 MR3ed1.1QD1.1的KEY文件申请现向CAE部门丁霞申请。

另外下面是MC module capacity HW licensing apply & return 流程。

背景：B11包括之前版本OMCR需要oflcf.in（limits.in）这个key文件来限制optional feature。

而从MCTRE产品推出后，OMCR还需要另外一个license.lic key文件来限制逻辑的MCTRE数量（每MCTRE硬件模块理论上可以用作1－6个逻辑TRE，根据公司价格策略需要用key来控制每OMCR上逻
辑MCTRE 总量；MCRRH 的逻辑TRE 数量也受此文件控制，且可以混合/等同计算总量）。

申请流程：新建、扩容MCTRE/MCRRH 之前，如果分公司发现现网没有MC-TRE capacity HW license 或者剩余容量已经不够工程需要（相信大家以前搞过HR/EDGE 等key 申请的同事都能容易理解这个情况），请向ASB OMO 部门的Xu Yan 提出新的license.lic key 文件申请。

需要分公司提供的申请信息请参考附件表格。

每次分公司申请LDKI 的MC-TRE/MC-RRH capacity HW licensing key 文件时，请分公司负责同事填写申请表的A 、B 、C 、E 、F 、G 、I 和J 列（其中B 列需要登录cygnus 或者vela 系统查询），剩下的D 和H 列由OMO CAE XuYan 填写核对，双方对表格有疑问再进行各自核对工作。

如果没有异议，由Xu Yan 联系LDKI 系统管理员申请license.lic key 文件。

希望每次分公司能给Xu Yan 一周左右的时间余量，因为LDKI 的license.lic 不同于以前的
oflicf.in ，keyGEN 不在ASB 员工手中，必须从LKDI 系统里面根据实际合同才能获得key 文件。

整个操作的灵活性和时效性肯定不比从前，所以请尽量提前提出申请。

返回流程：某些特定情况下现场需要将一个OMCR 上的MC-TRE capacity HW license RETURN 给LKDI 系统，然后再重新为另外一个OMCR （或者原OMCR ）制作license 。

这种情况下，分公司必须提供RETURN 之后（可用license 数量为0）的OMCR 截图，并email 给OMO （Xu Yan ）以证明RETURN 的确已经在现网设备上生效。

然后可按照正常申请流程操作，获取新的license key 文件。

注意事项2：
OMC 升版前后都要对MFS 和BSC 的同步情况做check ，有超过15分钟的，尽快按照2011 alart 0001的原则来修改。

另外如果发现有大量BSC 同步到local 的情况，请检查OMC 侧的设置，个别BSC 如果处理之后还是在local 的情况可以隔天再观察一下，但前提是确保时钟基本还是同步的。

对于MXMFS 在B10下的auditMFS.pl 结果为ERR_100的可以根据如下方法解决，切记要晚上做。

Wireless TMS GSM BSS Alert 2011 No－F:\C_backup\桌面\B10版本在做MFS的Aud
注意事项3：
升版完成后修改“CAL Maximum Size”，可能会导致进程"ascurim" crash，解决办法如下：
1)先purge所有当前告警
注释：通过更改每页显示告警数量到5000~1000，可以一次性purge all 告警
2）Stop ascurim from DSMUSM
3) Save a copy of db alarm db file,with axadmin account:
$cd /alcatel/base/as/im/
$cp db db.save
4) Restart ascurim with –rmdb option，with axadmin account：
$/alcatel/omc3/as/script/ascurim_dflt –rmdb
注释：命令执行下去后，不需要等待命令结束；不要关闭窗口，可以先将窗口放置一边，同时继续下一步，一会命令自己会执行完毕。

5) From DSMUSM perform discover for the process
Right click on ascurim@<hostname> ---> Select Discover All
6) Make all process start
注释：手动启动DSM中ascurim相关的所有进程。

7) From FM GUI, change the CAL size (according to the size of the saved db file)
With the following path:Alarm Sources—Administration—<your master hostname>
注释：根据db文件的大小来确定应该修改的CAL size。

CAL的size应该为db文件的大小除以4096，所得到的数值。

Set the CAL size to the following value
MAX CAL size = db file size/4096
e.g: If db file size is 16384000 bytes, set CAL size to 16384000/4096 4000
N.B:db file size can be obtained through ―ls –l‖ command
8) Stop ascurim from DSMUSM
9) Restore saved db file，with axadmin account:
$cd /alcatel/base/as/im/
$cp db.save db
10) Restart ascurim normally from DSMUSM (do not use –rmdb option here)
注释：通过DSMUSM启动ascurim进程，不要用命令行
注意事项4：
OMC addon （omc3.add.11_0.e1_1_1_12d）的文档第14-15页有错误，更正如下。

原文档
5.1.2. PATCH INSTALLATION (After DVD3 installation & BSCs are not declared on OMC)
Install the BSSIM patch
a) Login as user root on the target Master/Agent
b) Copy the package into /var/tmp directory
cp –p OMCGbsix11_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM_MX.gz /var/tmp
cp –p OMCGbsi11_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM.gz /var/tmp
cp –p OMCGbsix10_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM_MX_10.gz /var/tmp
cp –p OMCGbsi10_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM_10.gz /var/tmp
c) Execute the following commands
#cd /var/tmp
cp –p OMCGbsix11_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM_MX.gz /var/tmp
cp –p OMCGbsi11_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM.gz /var/tmp
cp –p OMCGbsix10_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM_MX_10.gz /var/tmp
cp –p OMCGbsi10_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM_10.gz /var/tmp
d) Save......
应该更正为：
5.1.2. PATCH INSTALLATION (After DVD3 installation & BSCs are not declared on OMC)
Install the BSSIM patch
a) Login as user root on the target Master/Agent
b) Copy the package into /var/tmp directory
cp –p OMCGbsix11_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM_MX.gz /var/tmp
cp –p OMCGbsi11_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM.gz /var/tmp
cp –p OMCGbsix10_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM_MX_10.gz /var/tmp
cp –p OMCGbsi10_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM_10.gz /var/tmp
c) Execute the following commands
#cd /var/tmp
#gzip –cd OMCGbsix11_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM_MX.gz | cpio –icdumD
#gzip –cd OMCGbsi11_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM.gz | cpio –icdumD
#gzip –cd OMCGbsix10_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM_MX_10.gz | cpio –icdumD
#gzip –cd OMCGbsi10_AZ10D53P5,handlebssim,BG_B11_MR2_BSSIM_10.gz | cpio –icdumD
d) Save......
注意事项5：
升版后如果要恢复老的hosts => 请不要直接复制、覆盖该文件，而是通过对比后用vi命令完成相关的修改工作。

否则，也有可能引发类似重庆的故障。

－－即使重装OMCR，也请注意这一点。

原因很简单: 请不要想当然的认为B10和B11的hosts是完全一致的，升版过程中也有可能增加一些重要信息，如果只是简单复制了老版本的hosts，可能会造成重要信息的丢失。

注意事项6：
结合现场问题，OMC升版过程中（包括新硬件M4000 B11系统安装）强调绝对不能忘记执行Configure the OMC-R as CLM和Declare the OMC-R to a CLM。

此处加入两处check （同时更新在OMC升版指导excel中）：
2)升版前检查/alcatel/var/share/nterm下的文件属性，和是否有重复文件。

3)在执行完Configure the OMC-R as CLM和Declare the OMC-R to a CLM之后，
打开DSM，检查clm的进程是否完好。

如果clm进程有异常，需要处理掉再继续升版流程。

【相关case】于RNUSM执行Resynchronize the OMC-R with CLM 步骤中出错
【提示错误】
ERROR:script at alcatel/omc3/osm/script/proc_upd.pl line 119 <OFLCF> line 221 【解决方法】发现目录/alcatel/var/share/nterm下的
total_app_omc,master_<hostname>，hmi_<hostname>文件均存在同名的重复文件，如提示无法删除，可以用Solaris自带的File Manager，定位目录后，删除重名文件。

其次，DSM中clm进程不存在，重新执行configure_omc_for_clm.pl后，问题全部解决。

注意事项7：
OMC升版前，对磁盘空间进行清理（主要为/alcatel目录），有利于减少文件数据传输时间，节省升版耗时。

/alcatel/var/share/AFTR/MISC/ 清理删除无用文件
/alcatel/var/maintenance/hist/ 删除时间较早的文件
find /alcatel/var/maintenance/ -name core
找到并手动删除core文件（注意是文件，不是目录）
/alcatel/var/share/AFTR/ACME/ 删除较早BSSconf文件
/alcatel/var/share/AFTR/APME/OBSYNT/ 删除较早话务报告
/alcatel/base/pypm/NT/ 如果有该目录，删除较早话务报告
/alcatel/var/share/local/obsynt/ 如果有该目录，删除较早话务报告
/alcatel/var/share/AFTR/APME/MFS/ 删除时间较早的文件
/alcatel/var/share/AFTR/APME/BSC/ 删除时间较早的文件
/alcatel/var/share/AFTR/NPO/QoS/ 删除时间较早的文件
注意事项8：
升版前需要检查/etc/hosts文件（所有Solaris设备）。

下为举例，尤其注意下4部分，都不可以缺少。

#
# Internet host table
#
::1 localhost ①
127.0.0.1 localhost ②
10.163.10.66 bcgasn002 ma1353ra loghost ③
# MFS BEGIN ④
10.163.10.82 MfsWs530
10.163.10.80 MfsWs514
# MFS END
MFS
注意事项1：
升版前mfs的telcom shelf中除了备用gpu外，至少得配置1个GPU。

不能有被LOCK掉的GPU，如果存在被LOCK掉的GPU不能被UNLOCK需要在升版前将此GPU从机架拔出。

注意事项2 ：
升版前检查MxMFS的CM参数，要求关闭enautonomousrerouting=0,或者在OMC上关闭BSC 的rerouting功能，设置如下：在IMT/bul下执行set cm[CM_1](enautonomousrerouting=0) get cm[*](*)；查看
set cm[*](*)；修改
注意事项3 ：
Mfs升版完成后，需在IMT上用get nep_profile[*](*) ；命令检查bul file是否打完整：该指令的显示结果中必须包含：
version_datap= “MFSXAZ10S”
version_datac= “MFSXAZ10S”
否则必须重打bul file。

注意事项4 ：
关于MFS升版前后检查参数和升版后的修改参数，可以提前编好bul file，在IMT的“request”里直接send到MFS里（比较节省升版时间），
附件为辽源现场所用的2个bul，“data_get.bul”可适用于所有现场（包括注意事项3里所提到的检查），“data_set data.bul”需要根据现场情况调节每个参数的具体值。

注意事项5 ：
在MXMFS升版过程当中，如果有发现板卡状态不正常的，可以先到MFS侧再check一下，确定有问题再做处理，因为有时候IMT对板卡的状态更新慢，往往显示会滞后，或者可以尝试开关IMT，特别是在处理GP翻转的时候，一定要派人在MFS侧做观察。

注意事项6 ：
MXMFS升级完之后要留意有没有“IPMB0 Diagnosis Error”的告警，如果有的话那基本在IMT 的tool－>Boards Firmware status菜单是打不开，这时候请不要进行MXMFS的firmware升级。

直到这条告警消除，并且tool－>Boards Firmware status菜单是可以打开了，才可以进行MXMFS firmware的升级。

处理“IPMB0 Diagnosis Error”的告警的方法如下，如果还是不行通知分公司报case直接升级到L2。

用PC通过local的方式连接IMT检查有没有板卡的硬件告警，如果有则更换相应的板卡，如果没有可以尝试/usr/mfs/bin/mfs_kill_imt_servers或者对MXMFS做switch over，对SMM做switch over。

注意事项7：
Mxmfs升版过程中，step6至step7时往往会由于mux1状态异常而自动倒回到step4，如下方法可防止该现象：
1，在step 6时按next进行升版
2，登陆到先前备用的station上，执行如下命令：
# buii （进入bul模式）
〉get mux [*][*]；（每隔1分钟执行这条指令，在输出信息中检查operational_state_ne1oe的状态，正常情况下在这步升版过程中，系统会自动对mux进行reset，因此状态会有enabled—>disabled enabled的变化过程）
若持续4分钟mux的状态一直处于disabled状态，则通过如下命令及时reset相关mux：〉action mux[MUX1](reset()); （一般情况都是mux1不好，若是mux2异常，则用MUX2替代）
实际过程中，指令reset不一定能成功，需要插拔硬件。

注意事项8：
用如下方法检查JBXSSW的payload，如果结果是6.5/514的，那就在MXMFS升版前换掉，如果有JBXSSW无法登陆，那就重启该JBXSSW再尝试登陆，如果还是不行那就直接更换掉。

F:\My Documents\
桌面\B11 全国升版\升
注意事项9：
万一MXMFS升级的时候，不小心把浏览器关掉了，可以通过登陆主用station，用pm命令检查是否有如下类似的进程。

/usr/bin/perl -w /usr/mfs/bin/firmwareUpgradeFiles/MFS_firmwareUpgrade -u 4 5
如果有就代表firmware升级还在继续，请隔几分钟刷新，直到该进程结束，并再等待10分钟重新打开IMT来查看板卡的firmware status。

注意事项10：
如果发现有JBXSSW不断重启的现象，同时同层另外一块SSW的状态是稳定的话，请做好如下的trace收集工作，并reset那块状态稳定的SSW来恢复。

如果同层的两块ssw 都在反复重启，请准备好teamview寻求L2远程支持。

Reset SSW的时候，可能会有如下情况发生：
If the affected SSW is located in shelf 4 in case of a multishelf configuration platform, all GP may reset.
In case affected SSW is located in the same shelf with OMCPs, following temporary misbehaviors may occur:
-GP reset;
-loose IMT connection;
-loose supervision from OMC-R;
-CS SWO;
-reset MFS;
F:\C_backup\桌面\
TSG JBXSSW reset in
BSC
注意事项1：
B11增加升版的新功能，使用如下:
在RNUSM窗口，选中BSC右键，打开菜单Show SoftwareManagement，跳出窗口SDP selection，选上升级所需的SDP包，然后在菜单View里面的add BSS添加升版所需的BSC，在这个菜单里面可以完成从generate 到accept的一系列操作，这样可以实现升版的集中管理，另外带来的一个最大的好处是可以同时操作多个BSC的升版（以前最多打开5个BSC窗口），其中选项preparation and Distribution包含了generate，download，predownload这3个操作。

注意事项2：
MXBSC activate后，当BSC开始做discover，会弹出一个窗口，显示为“Cmis status:: Communications Problem”，一定要点OK，不然有可能在follow up窗口是看不到discover的过程的
注意事项3：
升版之前检查一下DLS，如果MXBSC是IP连接的方式，内容应该如下：
B10:
R_BSC_INFO.D_IP_EXTR ==> 0
R_BSC_ADDR.D_NB_PPP ==> 0
如果不是，需要打b10_steerfile
如果忘了做，升版后可能出现的情况如下：
1.激活后TP退服
2.TP报configuration failure
3.BSC报MLPPP link failure
这时候需要检查：
B11:
R_BSC_INFO.D_IP_EXTR ==> 0
R_EXIP_CNF.D_NB_PPP ==> 0
如果不是，就要打b11_steerfile
注意事项4：
MXBSC有了一个新的trace收集工具，整合在BSC的软件里面了。

B11 trace saving
mechanism.doc
注意事项5：
MXBSC升版之前要保留如下数据：
用root用户登陆MXBSC的主用OMCP，执行如下命令，并把相关文件拷贝出来由队长保存#/usr/local/bin/mx_shelfAudit >/tmp/BSCNAME shelfAuditB10.log
#/usr/local/fw_upgrade/script/transFw -audit >/tmp/BSCNAME FWAuditB10.log
#hpibootoptions > /tmp/BSCNAME hpibootoptionsB10.log
JBXSSW的信息要按照如下文档收集，shelfaudit里面的信息是不准确的
JBXSSW信息收集.do
c
同样在MXBSC的firmware全部升级完成之后也要收集如下数据，交给队长：
#/usr/local/bin/mx_shelfAudit >/tmp/BSCNAME shelfAudit_B11.log
#/usr/local/fw_upgrade/script/transFw -audit >/tmp/BSCNAME FWAuditB11.log
#hpibootoptions > /tmp/BSCNAME hpibootoptionsB11.log
JBXSSW的信息要按照如下文档收集，shelfaudit里面的信息是不准确的
JBXSSW信息收集.do
c
下面是在firmware的升版过程中要特别关注的问题：
1. BSCNAME hpibootoptionsB10.log的格式一般如下：
hpibootoptions.do
c
只要不是0x60 0x00的OMCP和CCP板的firmware升级的时候要关注一下
2.在shelfAudit的log里面，ARTM（JAXSSW）的FW IMC是1.1.85的在升级的时候要关注一下
3. JBXSSW的信息为6.5/514的在MXBSC升版前换掉。

注意事项6：
如果在打MXBSC补丁的时候，发现传输过程很慢，特别是在mlppp的情况下，我们可以选择在MXBSC侧通过PC把补丁传入主用OMCP的/var/log/MX目录下，然后从OMC侧远程连上BSC来打，但是打补丁的时候BSC的地址就要改为172.16.33.1
注意事项7：
任何情况下均须谨慎修改/root/.ssh/known_hosts文件内容，绝对不允许清空和删除该文件！如果误删了会发生如下情况：
OMCP reset之后由于known_hosts文件问题DLS无法从主用OMCP传到备用OMCP上，导致备用OMCP无法起来，最后是找了一个同shelf BSC的文件传进去之后OMCP才恢复。

注意事项8：
MXBSC升版后一定要及时看话务报告，特别在升版前要留意该BSC是否挂在华为开MSC POOL功能的交换机下的，如果是的话升版后一定要检查真报告的18文件，其中C181E的值正常都小于10，如果有问题一般都是上百或者上千的。

解决方法是通知华为交换侧工程师对所有的A口进行管理开关（manage switch）的开关。

注意事项9：
升版前要对MXMFS和MXBSC的SMM的主备用情况，确保没有的无SMM主用的情况发生。

一旦发现SMM主用状态异常，在不影响业务的情况下首先收取相关trace，软后通过如下处理恢复：在状态为standby的SMM上通过sv_activate命令完成SMM的主备用切换，此时再登入至原主用SMM，若发现状态还是inactive，则reset 该模块使之状态更新为standby。

注意事项10：
MXBSC的firmware全部升级完之后可以用如下方法检查：
1. BSSUSM ->configuration->webmin application->pop up a window and choose “I understand the risks”->click “add exception…”->pop up a window->click “confirm security exception”->pop up a window and input username “mxadmin” and password “mxadmin” ,then click “login” ->pop up a window and click “fw upgrade info”-> click “view current firmware version level”
如果current version和recommended version一致，那就OK了
注意事项11：
BSC和MFS升版后务必要优化第一时间看报告以及安排好后续白天的维护和职守工作，一旦发现异常情况请马上汇报升版队长，地区负责人，地区技术经理等，及时报case处理故障。

TCIF
注意事项1：
TCIF升版前通过TC-NEM导出的STM-1 配置文件，该文件的命名必须为全英语字母，不能有别的字符，特别是中文。

如果有的话，按照如下方法整改。

F:\My Documents\
桌面\B11 全国升版\升
注意事项2：
TCIF升版前，通过TC-NEM检查IP conf页面，External OAM router 和External OAM mask必
须要配置。

如果现网OMC和TCIF之间没有switch连接，则可以把External OAM router配置为OMC的地址，External OAM mask配为255.255.255.0
注意事项3：
TCIF的升版过程会导致laser被关闭，检查和恢复方法如下。

检查时间点：
1. TCIF升版指导手册，步骤40之后，登陆到下层TCIF检查
2. TCIF升版指导手册，步骤79之后，登陆到上层TCIF检查
F:\My Documents\
桌面\B11 全国升版\升
切记，TCIF升级到MR3之后，切记不能用小扳手或者命令重启TCIF，如果不小心做了，都要按照上面方法检查一遍。

注意事项4：
TCIF升级完之后用TC-NEM连接上，到IP conf页面，检查O&M reachabilityTestAddr，Telecom reachabilityTestAddr, TCIF1 TelecomIp address and TCIF2 Telecom Ip address这4个值，必须全为0.0.0.0，如果不是，予以改正。

Click Save and when the message “Do you want to check the IP Netmask dependencies? (not mandatory in TDM mode)” appears select No。

并做两次TCIF的switch over
注意事项5：
千万不要去尝试打开TC-NEM的STM1 view页面里的VC12模块，一旦不小心双击打开任何一个VC12，那对应的A口就会断掉，MT120对应的A口灯慢闪。

如果不小心打开了，那解决的方法是对TCIF做switch over或者对两块TCIF同时开关电。

四．升版流程（详细操作流程见TSIO文档）
OMCR升版步骤：
OMCR升版步骤AZ31B_B11_MR3_ED1
.1_QD1.1-0726.xls OMCR补丁列表
omc3.add.11_0.308 728_12d.pdf omc3.add.11_0.309
269_12d.pdf
omc3.add.11_0.e1_
1_1_12d.pdf
OMC3.ADD.11 _0.308728_12D
OMC3.ADD.11 _0.309629_12D
OMC3.ADD.11 _0.E1_1_1_12D
OMC升级完需要做的工作：
1. 把MXBSC和G2BSC的SDP包load好（axadmin用户）另外注意CDE的第五个字母（客户码）要改好
2. 用ntpq –p检查所有MXBSC的同步情况
MX 9130 MFS 升版步骤：
F:\My Documents\
桌面\B11 全国升版\升
PATCH.MajorMigrat
MX 9135 MFS （RC23）升版步骤：
9130BSC 升级过程
F:\My Documents\
桌面\B11 全国升版\升
9120BSC 升级过程
升版详细记录G2BSC
.xls
TCIF 升级过程
D:\Documents and
Settings\paul\桌面\B
六，升版可能遇到的问题和W/A
OMC
问题1
各地有安装话务报告补丁，即在/alcatel/var/share/AFTR/NPO/QoS/目录下生成如下目录：../tongji（属性为root）
../tongji_conf（属性为root）
../tongji_gprsx（属性为root）
但是由于此脚本：
In section 4.5.3 Synchronize the OMC-R for the New PM Files：
/alcatel/omc3/migration/script/synchronizeNewOMC.pl -sameHW
是针对axadmin用户操作的，对于tongji无权限操作，会导致脚本执行失败，report failed。

所以在后续的升版中，需要提前清除掉此话务报告补丁，防止不必要的麻烦。

问题2
OMCR升版后DLS自动备份从保留时间默认为5天
修改DLS自动备份从保留5天改成保留15天，
方法如下：
在master上，axadmin用户：
MXBSC：vi 编辑/alcatel/omc3/bss/im/mx/10/conf/param.cfg把Omc_SW_Max_Backup_DLS 后面的数字5改为15；
G2 BSC：vi 编辑/alcatel/omc3/bss/im/10/conf/param.cfg把Omc_SW_Max_Backup_DLS 后面的数字5改为15；
改好后，在DSM里把所有BSC的bssim进程做stop/start。

问题3
1. OMCR升好后load CDE文件时会报错：invalid cdetable name
建议将/install/script/下的loadSDP 这个脚本中的第69行：
$cde_prefix="CDE";
改为：
$cde_prefix="MKU";
注意保持该脚本原来的相关属性
MXMFS
问题1 ：
打完MXMFS补丁后，IMT有可能会打不开，提示current IMT version不匹配，这时候有如下方法解决：
用axadmin用户执行如下命令：
Launch /usr/jdk/instances/jdk1.6.0/jre/bin/javaws –viewer
Close "Java Cache Viewer" window
In the “Java control Panel/general”,
click on “settings”
click on “delete files”
click on “OK” for the windows “delete the following temporary file ?”
click on “OK”
click on “Apply” for the window “java control panel”
click on “OK” for the window “java control panel”
问题2 ：
MXMFS升级完之后跟MXMFS出现不出话务报告的情况，我们首先去MFS里面/omcxchg/gpmres去检查MFS是不是出报告了，如果没有，联系支持，如果有的话，我们再去检查OMC里面
/alcatel/var/pm/xfer/下该MFS对应的文件xfer_FYMXMFS（ID）.excl这个文件，如果内容比MFS
里面/omcxchg/gpmres目录下的文件多，则删除了OMC里面/alcatel/var/pm/xfer/xfer_FYMXMFS （ID）.excl这个文件中多出的部分就可以了，下一个小时应该就有报告了。

问题3 ：
MXMFS的major migration补丁没有打好，怎么重新打
在一种情况下会导致major migration patch执行后窗口无法刷新且MFS无自动SWITCH OVER，最终补丁无法生效。

需要进行补丁的UNINSTALL，这种情况是：
登录到MFS的浮游IP地址（主用OMCP）--→从主用OMCP转登到备用OMCP --→再从备用OMCP重新登录回主用OMCP，并进行此补丁的操作。

导致的结果是：执行后窗口始终停留在“waiting for 60 seconds”,没有正常的流程显示，同时不会触发后续的SWITCHOVER。

需手动回车停止。

补丁失败。

原因是：执行补丁后，在对备用的OMCP自动执行reboot后导致了主备用之间的路由中断（主用登陆备用再登回到主用的路由），也就造成了执行后无法此路由上向主用OMCP的下发命令并执行后续的内部自动操作（如SWITCHOVER ）。

解决方法：在usr/mfs/bin目录下卸载此补丁，重新登陆MFS主用OMCP执行补丁操作。

问题4 ：
MXMFS完成升版9/10时，最后一步应点No以保留在OMCR上的pre-install文件，否则将影响后续未完成7/10步骤的MXMFS升版，会弹出报错：ftp transfer from MFS of /usr/mfs/etc/version_cfg failed。

如果误点了，可以再运行次预安装以补救。

问题5 ：
MXMFS在升版过程中如果出现告警"IPMB0 Diagnosis Error‖，特别是在第六步之后，同时可能伴随着SSW，SMM，MUX等板子告警的话，可以通过插拔有告警的板子的方法消除板子的告警，但是可能告警"IPMB0 Diagnosis Error‖并不会消除，这时候可以继续升版，等升版结束后，对SMM 做主备倒换，或者对MXMFS做switch over，如果还是没有消除，通知分公司报case，直接升级到L2。

问题6 ：
MXMFS升级完之后通过auditMFS.pl检查出所有的4块JBXSSW板报ERROR 705：vlan configuration error，根据TSG的描述进行了如下操作，还是无法解决
1.重新config vlan
2.用脚本reset了所有JBXSSW板
解决方法如下：
执行命令/usr/mfs/bin/mfs_new_vlan 后问题就解决了，但是这个操作要晚上做，因为要切OMCP
问题7 ：
对MXMFS实施补丁00T，在STATION上进行rpm -ivh --force --nodeps
FWUOGR-R1.5.2-P1.i686.rpm时进程吊死，用rpm -qa | grep FWUPGR检查STATION_A下没有任何东西，尝试SWITCH OVER STATION, reboot STATION 后重新执行rpm -ivh --force --nodeps FWUOGR-R1.5.2-P1.i686.rpm现象依旧为吊死状态。

解决方法：对该STATION进行system restore后，重新安装补丁正常。

问题8 ：
对MXMFS实施补丁00T，在执行./flash_upd.sh -p /dev/mtd/0 -i
ATCA-710x_2_1_15.bin 时出错，更换OMCP后重新实施补丁00T。

问题9：
MXMFS升版过程中可能会导致PVC圈杠，GPU跳no response from network的告警。

解决方法：
如果不多的话可以先完成升版再处理问题：
1.检查传输
2.对该GP做reset all操作，引起GP的切换，看是不是GP的问题导致的
如果确认不是传输或者GP硬件的原因，可以用如下方法解决。

a）同时对有问题的GP板同时做reset all的操作，可能会恢复部分，然后再对剩下的GP板继续做reset all操作，直到解决为止，如果还是不行，那就按照方法b）来解决。

B）
1.lock 该GP，对该GP所在BSC做reshuffle，断开该GP和BSC的数据
2.unlock该GP，按照流程删创GB数据（NSE,NSVC），问题解决
3.对该BSC做reshuffle
问题10：
MXMFS升版到step7，提出script alert，内容为‖connection lost with craft server! There was a unix script in progress. It’s execution will be lost.‖
解决方法如下：
- 1. –press ―OK‖ in the pop up error message window – the IMT will close automatically;
- 2 – on both stations, using grep command, check if
―restore_initial_user_group_rights.sh‖ or ―mfs_ip_four_vlans‖ are running;
o ps –edf | grep restore_initial | grep –v grep
o ps –edf | grep mfs_ip_four_vlans | grep –v grep
o if one of above two scripts or both are running, wait the scripts to finish;
o the scripts are finished (not running) when above two commands doe sn’t return any output;
- 4 –re’open the IMT;
- 5 – continue the migration according to the procedure; just pay attention that any time the IMT crash in step 7 it will reopened at the very beginning of step 7 and will perform again all steps;
- 6 – if IMT crash, perform again the steps from 1 to 5 (skip step 6 if IMT didn’t crash); 如果尝试到凌晨4:30还是过不去的话，请倒回该MFS，并在日报里面写red flag，把几个关键的时间点写清楚。

问题11：
MXMFS升版后，用IMT做system backup就有可能会在auditmfs.pl中出现如下告警：“WARNING 309: Wrong mounting point‖ /dev/hda13 --------- /mnt
解决方法如下：
分别在主备用station上执行命令umount/mnt，或者对MXMFS做一个switch over
问题12：
MFS在检查FIRMWARE STATUS时，如果有JBXSSW的Payload识别不出来（can't be retrieved）。

先用下面的方法检查该JBXSSW的payload信息，如果是6.5/514就更换之。

1. 登陆到主用的OMCP，切换到root用户
2. # telnet 172.16.x.171 450y x代表哪一层x＝3,4 y代表哪块SSM y＝1,2
举例如下：telnet 172.16.3.171 4501
telnet 172.16.3.171 4502
telnet 172.16.4.171 4501
telnet 172.16.4.171 4502
3. 然后一直回车直到出现->
4. ->后输入命令sysBoardShow回车，结果中显示BSP revision 6.5/526 为JBXSSW的payload的信息
5. 输入q 退出到->状态，然后再输入Ctrl+]退出到telnet>状态，然后再输入q回车退到OMCP的盘符下。

如果在步骤3按回车到不了->，那就把对应的SMM和MUX至为备用，重启该JBXSSW，然后再检查一下该JBXSSW的payload信息并再尝试一下firmware status菜单。

MXBSC
问题1：
MXBSC升版完后，pstree有可能执行不了，提示:’dtterm’:unknown term inal type ，
解决方案如下：在root用户下，先输入env,查看环境变量,如果发现是TERM=dtterm,就用命令declare –x TERM=”vt100”就可以解决这个问题,pstree就可以用了
问题2：
Generate时候出现问题，提示为
bsc-disk-problem: General error during opening/closing/reading/writing of a file.或者是点击download and predownload后提示：25-wrong-ip-address:PF finds the IP address is wrong 。

for the action %s.bssim-4559这样的告警
可以尝试在晚上切换OMCP再做Generate和download and predownload
问题3：
Active之后，MXBSC的SSW出现alarm "[98,10]FATAL-HW-FAILURE"，状态为FIT
问题解读：硬件问题早在升版前B10就存在，但B10的代码还没有新加端口速率的检查，所以不报，但migrate到B11后，就立即被检测到了，但按照系统设计，在BSC重起后(包含升版的activation)，OMC发alarm audit之前，BSC是不报alarm给OMC，只保存在自己的一个文件中，后面OMC发alarm audit后，再把文件中的内容读出来报给OMC。

解决方法：对SSW做reset，再报出来的alarm，additional info肯定会有，更换对应的板子就可以解决，如果还是有告警的话就更换该SSW。

问题4：
BSC在ACTIVE结束后，状态为actived,follow up窗口弹出告警―changebssim script has failed. Please do a REJECT.‖
我们通过以下方式解决：
在master上修改/alcatel/var/share/dsm/programes.cfg
UseTemplate XBssim ( <name>.....<rel>=mx/10,<arg2>="BSC_NAME".....) 将10修改为11，保存退出
先stop 该BSC的bssim进程，在master上在DSM窗口的FILE下 Load config 选择dsm.cfg,再start该BSC的bssim进程。

问题5：
MXBSC的OMCP的firmware升级可能会导致OMCP fault掉，具体现象为firmware脚本提示升级成功，但过10分钟左右，OMCP上的告警并没有消除，OMCP直接圈杠，在BSC侧表现为退服或者反复重启，解决方法：用console登陆该OMCP，直接用F12进行hot install，如果不行，可以插拔该OMCP后再尝试hot install。

问题6：
MXBSC打完补丁reset BSC后可能SSW会起不来，可以尝试对BSC开关电解决。

七，目前版本的RL，SM，OH
az31b-ed01_oh_ed0 2_rel.pdf az31b-ed01_rl_ed0
2_rel.pdf
az31b-ed01_sm_ed0
2_rel.pdf。