简介
StartFragment
思科网真Touch是思科网真设备的下一代用户界面设备,替换Cisco IP电话7975 (和某种传统7970)。此发表物将解释联系设备的引导程序操作和每个步骤的故障排除选项。
有思科联系的7个步骤关于Cisco Touch,以下过程用来表示。
步骤1 – 3特点是一个简单的蓝色屏幕没有下拉菜单。
步骤4 – 7特店一个“更加俏丽的’蓝色的背景并且带有下拉菜单来表示进度。
一个X超出的编号表示步骤失败。
· 考虑一个步骤“停留”,如果这个号码强调并且下拉菜单在中間消失。
· 步骤1-3考虑如果一个突出的号码卡住这个界面超过5分钟。
结束部分
步骤 1
步骤#1是设备的POST (Power On Self Test)相位。
· “X”表示自检失败。
· “Stuck”表明有硬件问题。
两个案件都将会需要RMA。
步骤 2
在步骤#2 UBoot从存储设备装载到内存。对故障设备会进行备份槽位。
· “X”示写入RAM失败。
· “Stuck”表明启动装载程序配置正确或不正确。
两个案件将要求RMA。
步骤 3
在步骤#3设备执行在Uboot镜像的一个CRC校验装载到RAM。
· “X”示CRC校验失败。
· “Stuck”表明这两个激活和备份的银行是堕落的。
两个案件将要求RMA。
步骤 4
在步骤#4期间设备试图通过DHCP从解码器获取到一个IP地址。
· “X”表示设备不能获取到IP地址。“不能跟解码器通信”会在屏幕上被看到。
· “Stuck”表明从解码器收到的没有响应。
故障排查
确保一切东西都是正确地连接基于系统布线图
确认是否Touch显示出在编码器的arp列表运用admin CLI命令直到在arp列表中Touch拥有了主机名 本地正如所示如下:
admin:utils arp list
Address HWtype HWaddress FlagsMask Iface
tbblackout1.local ether 1c:df:0f:76:fd:9a CM eth0.2130
tbcam2.local (incomplete) eth0.2140
ts2.local ether 1c:df:0f:76:fc:ac CM eth0.2120
ts3.local ether 1c:df:0f:76:fc:aa CM eth0.2130
uidev1.local ether 30:e4:db:d1:5b:7e C eth0.2120
ts4.local ether 1c:df:0f:76:fc:b8 CM eth0.2140
rtp12-calo-497-gw-vlan1 ether 00:d0:01:d6:34:00 C eth0.10
tbcam1.local (incomplete) eth0.2140
Entries:8 Skipped: 0 Found: 8
验证DHCP服务运行在解码器上并使用admin cli命令行直到服务列表如下所示:
admin:utils servicelist
Service State
---------- --------
System_Log [Running]
Cisco_Log [Running]
DHCP_Srvr [Running]
NTP [Running]
SNMP_Srvr [Stopped]
Discovery_Protocol [Running]
TouchCtrl_Srvr [Running]
MSI_Services [Stopped]
8021x [Running]
Calling_Services [Running]
HTTP_Srvr [Running]
Security_Srvr [Running]
Telephone_Srvr [Running]
如果DHCP_Srvr服务不运行,则请使用admin cli命令直到DHCP_Srvr开始服务。
尝试从admin cli命令行去ping这个Touch直到网络能够ping通如下所示:
admin:utils networkping uidev1.local
PING uidev1.local(192.168.2.3) from 172.18.253.105: 56 data bytes
64 bytes from192.168.2.3: seq=0 ttl=64 time=1.123 ms
64 bytes from192.168.2.3: seq=1 ttl=64 time=0.588 ms
--- uidev1.localping statistics ---
2 packetstransmitted, 2 packets received, 0% packet loss
round-tripmin/avg/max = 0.588/0.855/1.123 ms
潜在的bug
CSCua03327DNS通信问题导致Touch会卡住,在检查触点4的时候发现发生在1.8.x版本,已经在1.9.1版本和6.x版本修复了。
步骤 5
在步骤#5中镜像从UCM获取图像和处理的设备。有几潜在的子步聚在这个阶段能被看到,如下所示的此:
备份槽位闪烁。这种情况不应该在工厂制作意外出现。
或者激活的槽位程序闪烁,当启动从(备份/激活)槽位 (不正常)
激活的Linux 槽位闪烁 (从tftp下载或者升级)
· x与“不可能检索到启动镜像”表示:
· 需要花费多于15分钟的时间来获取镜像或者下载速率是小于52 Kb/s每45s
· x与“破损启动镜像”表示:
· 获取到一个镜像但是是破损的或者无标记的. (检查MD5哈希)
· x与“不能提取的镜像”表示:
· 这是一个软件包问题。 (检查CopFile的全部3个组件)
· x与“不能升级的闪存”表示:
· 闪烁失败的镜像。(硬件问题–返还设备)
排除故障
验证电话在UCM中加载部分的设备概要文件,不包含一个扩展部分(例如sbn, spa 或者 loads)。编解码器将自动加载扩展部分。
验证编解码器恰当的解析加载的文件,通过查看NV注册使用admin cli命令:在运行时间内show tech的输出信息包括正确的条目如下:
ctsdevImageAddr :包含UCM的ip地址和带有端口号为6970的主机名
ctsmainImageName :包含编解码器镜像文件的文件名。
ctsdevImageName :包含Touch的固件的文件名。
示例如下所示:
NV registry:
autoUpgrade=true
AuxAudioSource=0
NetworkMessageDisabled=false
NetLatencyLevelWarn=200000
NetLatencyLevelErr=400000
sipCallHold=true
idleRedirect=Normal
loadS2=CTS.1-9-0-46R-K9.P2.SPA
pllCalibrationValue=0xa0
loadS6=CTS.6-0-2-28R-K9.P2.SPA
loadS5=CTS.6-0-1-50R-K9.P2.SPA
cameraVerUpg=false
audioExtVerUpg=false
cippsVerUpg=false
displayVerUpg=false
vfpgaVerUpg=false
priorSlotInfo=SWITCH
upgSlotInfo=TX6.0.2(28) P2 2013-05-15 01:07
panicLogPresentPhone=0
panicLogPresentCLI=0
currentprtn=6
displayAtBoot=CTS-DISP-65-GEN4
ctsdevImageAddr=http://14.80.94.145:6970
ctsmainImageName=CTS.6-0-2-28R-K9.P2.SPA
ctsdevImageName=CTSDEV.6-0-2-28R-K9.P1.SPA
securityCfgMode=auth
ctsPeriodicLogStartReal=0
ctsPeriodicLogPeriod=0
panicLogPresentWeb=0
如果看起来没什么价值然后确认UCM是正确的固件并且下载这个文件在TFTPserver上。
如果ctsdevImageAddr是一个主机名而不是一个IP地址验证,一个解码器可以解决主机名的问题,通过使用admin cli命令直到广播主机的主机名哪个主机名正如在ctsdevImageAddr输出所显示是正确的。
通过编解码器用ping的命令到UCM的主机名和ip地址,可以验证UCM的可达性。
如果UCM的连通性被验证,可以被确认UCM有适合的文件在TFTP 服务器上被加载,并且编解码器是正确的加载文件,则应该调查UCM和编解码器之间的路径问题。某些常见问题如下:
1. 固件是通过TCP端口6970被下载的,而不是通过UDP端口69正如TFTP文档中建议的。
2. 当需要做分片时,默认情况下UCM在所有TCP数据包上设置DF比特,并且试图通过学习MTU的路径依靠ICMP 类型3 (目的不可达)代码4 (分片需求)的信息。如果ICMP被防火墙阻塞,那么UCM将假定,最大值MTU是可接受,并且包含固件的TCP数据包可能从来不会到达编解码器。 此问题可以通过在UCM和解码器上抓包来确认。要解決此问题,要么需要将ICMP消息允许到达UCM,要么需要将UCM的MTU大小在网络中调整为可能的最低值。一个临时的解决方案就是通过使用admin cli 命令行设置network pmtud disable去禁用在UCM上PMTU的发现。注意:这个操作将导致网络暂时性的中断连接在UCM上,并且可能有在UCM上出现意想不到的影响,所以这个只能作为临时应急方案。
总之,很可能这个固件本身是有问题的。验证以下:
1. 镜像被用SPA扩展名标记。
2. 固件文件的MD5数量总和正确。
步骤 6
在步骤#6期间固件文件的内容会被解压缩到系统文件中,并且Touch的软件系统会被加载。
· “X”表示解压缩的镜像有问题。在Touch设备上会看到“不能解压启动镜像”。
· “Stuck”表示镜像太大,Touch设备没有足够的内存。你无法停在这一步上,在第6步中,设备会在90秒后重新启动。
可能的问题:
· 在CRC’s被计算和储存之前,已获得的镜像的文件系统块已经被损坏。
· 设备上的空间。
步骤 7
在步骤#7期间Touch应用程序启动。
· “X”表明某些东西停止了Touch的应用程序,或者外围Touch本身在升级装。这些问题都不应该发生在开发以外的范围。
其他问题
Touch在步骤#3以后闪烁
这是正常,Touch将在步骤#3和步骤#4中的加载提升图形卡开始这个期间加载图形卡驱动。
Touch在步骤#5以后重新启动
在步骤#5后Touch将重新启动,如果在它检测到一个外部的升级需求的话。然后它将重新启动到步骤#1并且正常启动。