CE设备作为软交换网元接入IP承载网的第一道关卡，起着十分重要的作用。作为CE设备维护人员，在日常维护设备的过程中能够对常见的故障从容应对、处理是十分有必要的。
本人对CE设备的维护已半年多，现将CE维护中常遇见的故障及如何处理总结一下，与大家共同学习、交流。
一、端口变down故障处理
CE设备的端口一般分为GigabitEthernet(电口)和pos(光口)，CE 设备终端查看端口的命令为:
华为NE40E：display interface GigabitEthernet X/X/X
爱立信juniper:show interface GigabitEthernet X/X/X
爱立信SE800：show port [ Slot/Port ] detail
由于目前广州地区的CE设备品牌主要包括华为Quidway NE40E系列和爱立信的Redback SE800系列,至于爱立信的juniper、Apline 3804及Summit 48si等设备已经逐步退网。爱立信的SE800是新验收不久的CE设备，广州地区只有两对,所以本文中所提到的CE设备故障一般是指华为NE40E中出现的故障，其它品牌CE设备故障参考处理。
首先CE设备的一个端口变down情况会有两种及原因分析(见附表
一)：
情况物理状况链路状况原因分析
一up down 1.IP地址冲突,子网掩码设置错误。
2.没有设置DCE时钟。
3.没有设置对FR的,PPP 的封装。
4.Hello和Dead 的更新时钟在两端不同。
5.路由协议设置错误。
二 down down 1、物理端口被手动shutdwon。
2、由于对方的端口down 掉或者链路不通。
附表一
1、第一种情况处理：
从设备终端登陆CE设备查看端口链路层出现down情况的端口（见图一），该情况是最常见的一种故障。
物理状态为up
链路状态为down
图一
对于这种端口链路状态变down的情况处理步骤：
1)参照OSI参考模型(Open System Interconnection),第二层的链路
层协议从初始化到变Up 起来，会经过包括链路层协议本身规定的参数、能力协商，及协议所规定的定期性的链路通达性检测（例如HDLC 的
Keepalive 报文）。既然称之为“协商”，也就意味着该过程是一对一交互性进行的，既有一个发送出去的报文，也会有一个对方发送过来的回应报文。因此，如果遇到物理口Up、协议Down 的情况，建议在确认两端设备的配臵没有问题之后，用“display interface + 端口”的命令查看一下该端口的收、发报文情况。在CE设备上，“display interface”
命令的显示结果有XXXX packets input 和XXXX汇报packets output 两项，分别代表该端口上收到和发送的报文数量。正如刚才所阐述的，如果这两个数字相差很大（为了不致让以往累计的历史统计数据对问题的分析、判断造成干扰，建议先在CE设备的特权用户模式下使用“clear port”命令将端口的统计信息清空，再用“display interface + 端口”
命令进行查看），则大致可以说明在协商的过程中出了问题，造成协议不能Up起来。
2)在很多情况下，物理口Up、协议Down，用“display interface”
命令查看端口的收发报文情况，发现只有送出去的报文，收到的报文数量为零，而且连续使用“display interface”命令进行查看，进一步发现送出去的报文数量在不断增长，但是收到的报文数量始终为零。这说明了CE与网元之间的链路层协议处于Down 状态的原因：（1）在CE
与网元之间的传输链路、线缆出了问题，导致本端CE设备收不到对端网元送过来的回应报文；（2）对端网元本身出了问题，无法给本端CE 设备发送回应报文。
3)除最常用的收发报文数量比较的方法外，在“display interface”
命令的显示信息中，还有一项很重要的内容，那就是端口所收到的错误报文数量。在CE设备上的“display interface”命令显示结果的倒数第二行，有如下的信息：
0 input errors, 0 CRC, 0 frame errors
如果由于传输误码、物理线路质量比较差或者是中间的中继架位链
路出了问题，则容易导致CE设备收到的IP 报文中，很多是错误的报文。特别地，如果通过连续“display interface”查看会发现错误
的报文在不断增长，则可以判断此时网络线路质量比较差、传输有误码，或者中间的中继架位、某段电缆出了问题，导致送给本端CE设
备的报文绝大部分是错误包，这样链路层协议也肯定是不能变Up 的。
4)另外，如果通过“display interface”命令发现收、发报文的数量
基本相等，而且也没有错误包，但协议还是Down，这个时候可以在CE 设备上打开该端口的链路层协议Debug 开关，通过Debug 调试信息完整地分析一下协议的协商过程，看看到底问题出在什么地方，是出在协商的哪个阶段。不过，这种情况在实际中很少碰到。
5)最后，正如前面提到的，在CE设备中，物理口Up、链路协议Down，
可能的原因非常多，不同类型的端口、不同的协议，可能的原因都不尽相同。前面所阐述的只是常见的故障情况，具体问题还是需要具体分析。
另外很重要的一点是，协议的功能是用于互连、通信，在实际的软交换维护中，协议问题的排查同样需要各个相关部门、相关人员的通力配合，孤立、静止地去分析问题，很难取得比较好的效果。
2、第二种情况处理：
此种情况表示设备端口的物理层和链路层都已经变down的情况（见图二）：
图二
对于这种情况的端口变down的处理步骤：
1)检查该端口是否已经被手动shutdown，用命令“display interface”
查看端口状况，如果这个显示为端口administratively down 即表示已经手动shutdown，物理层都已经关闭，当然链路层就变down了。
2)如果端口看到物理层显示不是administratively down，即有可能由
于对端网元的端口已经变down或者链路不通。此时可以联系机房现场的维护人员协助查看设备的物理端口连接及线路状态。
二、链路断开故障处理
链路断开顾名思义是指CE设备所连接的网元间的链路断开、线路不通
的故障。遇到这种故障处理步骤：
1、请机房现场维护人员查看CE设备端口是否松动？如果有松动即
拨插一下，同时在远程终端登陆设备查看链路是否恢复正常。
2、电话联系传输室报障（020-********），请传输室人员协助对
链路做自环测试，查看CE设备跟对端网元的链路状况up/down情况，
查清楚到底是哪一端线路出现问题。
3、从远程终端登陆CE设备查看出现故障的端口，初步判断故障的
原因所在，并持续用ping和tracert命令测试链路传输是否恢复正常。
4、在远程终端查看日志信息，搜索有关出现故障的端口日志信息。
例如：9月18日花都CE11的端口GigabitEthernet 5/0/0出现ping
包不通的现象，从远程终端登陆设备CE11，查看到端口GigabitEthernet 5/0/0连接的网元为GZGM16，再查知GZGM16跟CE相连的IP地址如下
表：
GDGZ-NGN-CE11-H WNE40E Vlanif1410(10.132.19.6
6/28 )
10.132.19.68(2-19-PL)
10.132.19.70(3-19-PL)
GZGM
16
GDGZ-NGN-CE11-H WNE40E Vlanif1411(10.125.19.7
3/29)
10.125.19.74(2-19-SIG
-ITU)
10.125.19.75(2-19-SIG
-MPT)
GDGZ-NGN-CE11-H Vlanif1415(10.132.19.110.132.19.196(2-20-PL
WNE40E 94/28) )
10.132.19.198(3-20-PL
)
在CE11上使用 ping命令来ping对端的网元：
用短数据包去ping（-s 1000数据）可以发现是可以ping得通的，如果用长数据包（-s 3000）去ping呢？
可以看到如果用长数据包去ping对端网元时显示超时，故障可以初步判断是网元端的板卡接口有问题，可能出现连接松动或者接触不良等问题。
再查看一下CE设备的有关端口GigabitEthernet 5/0/0的日志信息：
GDGZ-NGN-CE11-HWNE40E>dis log | include 5/0/0
Logging buffer configuration and contents:enabled
注意观察可以发现端口GigabitEthernet5/0/0曾经出现连续的闪断现象，联系机房现场维护人员的核查，进一步证实GZM16到CE出现
闪断故障，通过对ETMFG-ECF之间的连接头的检查，发现ETMFG背板连接头有松散的现象。至此，只需把ETMFG背板连接头重新拨插一下，固定好就行了。
三、IP NET网管系统登陆不上CE设备
由于CE设备是通过IP NET网管平台集中连接管理的，即通过IP NET 网管系统集中控制管理。
通常在IP NET网管系统登陆不上CE设备通常会显现这样的结果：Console>>open GDGZ-NGN-CE07-HWNE40E
Deivce info not found in core !%ERROR% -- connect to device failure 这时可以通过电话直接联系IP NET网管的负责方---东信公司的负责人协助解决。
例如：10月29日西华爱立信CE19、CE20及下带的两台交换机一直登陆不上去。
1)首先联系机房现场的维护人员，核查四台CE设备是否已下电；
2)联系东信协助解决，通过利用traceroute命令进行检测，根据我们
向东信负责人提供的CE设备管理接口地址, IP NET网管负责人使用
tracert命令对数据包的传输路径进行跟踪，发现数据包至
132.97.19.48地址时截止（具体见附表二）：
附表二
可推测问题出现在网管的传输链路上，在数业室同事的协助下，发现是这四台设备的网管vlan设臵出了问题，重新设臵后解决问题。
另外，据数业室同事的反馈，由于在这四台设备上用于网管的vlan 数据配臵被丢失，造成网管登陆不上设备，这一故障虽然不是出现在CE 设备上，但对CE维护造成的隐患也是一个很大警惕。
四、小结
目前CE设备尚在努力建设中，每一对CE都互为备份承载着逐渐增加的话务量，可靠性比较强，单CE设备本身故障影响话务的情况很少。
故障主要是出现在网元跟CE相连的链路上，经常会由于网元端的板卡、接口出现问题。所以在日常处理CE设备的故障时，须特别留意CE设备所连接的网元状况。