…………………………

01/24/2007 04:06p 201 .4

15 File(s) 2555451 bytes.

4 Dir(s) 164667392 bytes free.

可以看到文件大小为2304171，这是正常的设备，再次登陆出问题的设

备dir，显示为：

Directory of cf3:

08/01/2006 11:52a 201

05/19/2006 01:35p 1816807

05/19/2006 01:35p 5747

…………………………

04/28/2007 03:10p 42775

10 File(s) 1935025 bytes.

4 Dir(s) 174178304 bytes free.

板卡重启的这台设备大小仅为1816807B，两个文件大小明显不同。

把CF3卡拔出来，拷入正确的文件，覆盖原来的即可。

是引导程序加载器文件，是引导系统启动的文件。

此问题估计是在进行设备升版的时候，只拷了，，文件，修

改了文件，却忘记更换新的文件，这样系统也能运行，但是不稳定，可能

会导致CPM板卡的自动重启。

7750SR设备常见故障处理指导书

4.2 端口常见故障处理

4.2.1 pos端口常见故障处理

目前设备pos端口只支持ppp封装，不支持hdlc-cisco封装。以一个oc48 pos端口为例，

要查看端口协议是否up，需要通过show port 6/1/48命令查看，通过show port 6/1/1

无法真正判断该端口协议层是否up

show port 6/1/48

===============================================================================

Path Info

===============================================================================

Description : STS48

Admin Status : up Oper Status : up

Mode : network CRC : crc32

Encap Type : ppp-auto Configured MTU : 9208

Operational MTU : 4472 Operational MRU : 9206

Last State Change : 05/29/2007 18:15:05 Path IfIndex : 639664129

Scramble : true

Accounting Policy : None Collect-Stats : Disabled

Net. Egress Que Pol: ZJ-NetworkEgressQ Load-balance-algo : default

Signal Label : 0x16 Rx Signal Label : 0x16

Trace String : Alcatel 7750 SR

Rx Trace String : JX-JX-QH-R1-T64

Rx Trace Str(Hex) : d7 4a 58 2d 4a 58 2d 51 48 2d 52 31 2d 54 36 34

Cfg Alarm : plop pplm puneq

Alarm Status :

===============================================================================

Traffic Statistics

===============================================================================

Input Output

-------------------------------------------------------------------------------

Octets 17119 79261

Packets 3284081914468 2

Errors 2 0

===============================================================================

===============================================================================

Port Statistics

7750SR设备常见故障处理指导书

===============================================================================

Input Output

-------------------------------------------------------------------------------

Packets 3284081914468 2

Discards 0 0

Unknown Proto Discards 0

Pos端口常见故障为协议无法up，首先需要检查端口配置，确认以下参数配置是否正确：

Scramble //加扰，要求与对端口一致，配置命令：

config port X/X/X sonet-sdh path scramble

signal-label //C2开销子节，要求与对端一致，否则传输会有诉告警，与juniper设备对接，

必须一致，配置命令：

config port X/X/X sonet-sdh path signal-label XXX

trace-string // C2开销子节，要求与对端一致，否则传输会有诉告警，与juniper设备对接，

必须一致，配置命令：

config port X/X/X sonet-sdh path trace-string XXX

crc //CRC检验位，要求与对端选择一致的CRC检验位，配置命令为：

config port X/X/X sonet-sdh path crc 32/16

clock-source //时钟源，配置应情况而定，如果二台设备直接用裸光纤互联，则一端取本地

时钟一端取线路时钟即可，如果二台设备间经传输互联，则取线路由时钟即可，配置命令有：

config port X/X/X sonet-sdh clock-source node-timed|loop-timed (node-timed为本时钟，

loop-timed 为线路时钟)

framing //帧格式，配置应该与传输一致，如果没有传输则应该与对端设备一致，配置

命令为：

config port X/X/X sonet-sdh framing sdh|sonet

7750SR设备常见故障处理指导书

4.2.2 ethernet端口常见故障处理

ethernet端口配置相对简单，引起端口无法up的原因一般为端口协商问题，可以通过

以下命令改变协商方式：configure port 5/1/1 ethernet autonegotiate设置为自协商，

或者configure port 5/1/1 ethernet no autonegotiate设置为强制。

在更改协商方式后端口一般都能up。

有时可能由于不同厂商间的端口协商问题，导致GE口存在大量的丢包现象。将GE

口的自协商关掉后，可以规避该问题。

不同厂商间端口的协商问题还可能引起端口被吊死，端口的物理状态虽然是up的，但无

法转发数据。这时，可以通过拔插光模块进行恢复。

故障举例：

7750与华为NE80通过城域波分进行GE互联。7750和NE80 GE端口均设置为强制

1000M全双工模式，两设备端口物理状态为UP，ping对端地址不通，检查端口只有发包无

收包，收发均无错误包。

通过以下步骤进行故障定位：

 检查IP地址配置确认无误，检查转发表出端口正常

 检查是否传输打环，把端口shutdown，对端端口down，排除传输打环

 修改端口模式，设置为自协商模式，端口物理状态down

 为排除端口故障，使用尾纤把7750和本机房华为设备GE端口对接，强制模式和

自适应模式均可正常ping通

 初步判断传输原因，协调传输检查传输配置，检查发现传输数据错误导致端口对

接异常，传输修改数据后业务恢复正常。

传输设备配置错误导致端口对接异常，GE端口在强制速率和双工模式的情况下，收到

光功率正常端口物理即UP，在自协商模式下还需经过速率和双工模式协商后端口才UP。端

口对接经过传输设备时需要考虑传输因素，可以首先在近端进行对接排除本端原因。

7750SR设备常见故障处理指导书

7750SR设备常见故障处理指导书

4.3 路由协议常见故障处理

4.3.1 链路无法负载均衡

现象描述：7750两条链路双上行至核心设备，两条链路metric设置一样，分别从两台核

心设备学习到缺省路由，但只有一个端口有流量。

7750SR设备常见故障处理指导书

在ospf或者isis database中可以看到有到达缺省路由相同metric的lsa，但路由表中只

有一条缺省路由，需要注意这是7750和其它厂商区别的地方，象思科设备，igp缺省就开启

了4条等值路由，无需配置。但7750需要在router下面配置ecmp 数目，否则即使数据库中有

多条相同metric的lsa，也只会选取下一跳地址最小的进行转发。无法实现流量的负载均衡。

4.3.2 等价路由情况下的PING问题

现象描述：

12000

.21

222.87.109.20/30

.22

7750-cr1

.17

222.87.109.20/30

.18

7750-cr2

8016

2.5G Pos

GE Loopback: 61.159.180.246

如上图，某运营商城域网的部分拓扑。两台7750作为城域网出口路由器上连到省12000

设备上，同时7750下挂的汇聚设备双归属到两台7750（图中只画了8016设备，实际还有其他

设备也双归属到两台7750）。

路由协议：

两台7750和下挂的汇聚设备运行OSPF协议，都在区域0内。两台7750同时和12000建立

EBGP。

两台7750通过路由策略将BGP的缺省路由引入到OSPF中，7750将此缺省路由通告给8016

policy-statement "generate-default-route"

entry 1

from

protocol bgp

prefix-list "generate-default-route"

exit

to

7750SR设备常见故障处理指导书

protocol ospf

exit

action accept

exit

exit

default-action reject

exit

这样8016上学到的缺省路由将是有两个下一跳的等价缺省路由，下一跳分别指向两台

7750。

同时，7750在向12000通告BGP路由的时候也使用了路由策略

policy-statement "TO-AS4134"

entry 1

from

protocol static

prefix-list "To-null"

exit

to

protocol bgp

exit

action accept

exit

exit

entry 10

from

protocol ospf

prefix-list "ospf-bgp"

exit

to

protocol bgp

exit

action accept

exit

exit

entry 20

exit

default-action reject

exit

也就是说，7750通告给12000的BGP路由来自静态路由和OSPF。静态路由如下

static-route 58.42.160.0/19 black-hole preference 250

static-route 59.43.2.13/32 next-hop 59.43.75.169

static-route 61.159.147.0/24 black-hole preference 250

7750SR设备常见故障处理指导书

static-route 61.159.148.0/24 black-hole preference 250

static-route 61.159.180.0/22 black-hole preference 250

static-route 61.159.184.0/23 black-hole preference 250

static-route 61.189.234.0/23 black-hole preference 250

static-route 61.189.236.0/22 black-hole preference 250

static-route 61.189.240.0/23 black-hole preference 250

static-route 202.98.204.0/24 black-hole preference 250

static-route 219.141.104.0/21 black-hole preference 250

static-route 220.172.206.0/23 black-hole preference 250

static-route 220.172.216.0/22 black-hole preference 250

static-route 222.87.88.0/21 black-hole preference 250

static-route 222.87.96.0/21 black-hole preference 250

static-route 222.87.104.0/24 black-hole preference 250

static-route 222.87.105.0/24 black-hole preference 250

static-route 222.87.109.0/24 black-hole preference 250

prefix-list "To-null"

prefix 58.42.160.0/19 exact

prefix 61.159.147.0/24 exact

prefix 61.159.148.0/24 exact

prefix 61.159.180.0/22 exact

prefix 61.159.184.0/23 exact

prefix 61.189.234.0/23 exact

prefix 61.189.236.0/22 exact

prefix 61.189.240.0/23 exact

prefix 202.98.204.0/24 exact

prefix 219.141.104.0/21 exact

prefix 220.172.206.0/23 exact

prefix 220.172.216.0/22 exact

prefix 222.87.88.0/21 exact

prefix 222.87.96.0/21 exact

prefix 222.87.109.0/24 exact

exit

这样12000上会收到从两台7750通告过来的61.159.180.0/22 BGP路由，这也会形成有

两个下一跳的等价路由，下一跳分别指向两台7750。

问题现象

现在从12000上ping 8016的环回地址61.159.180.246，发现会有丢包，丢包率在

20%-60%间随机变化。

处理步骤：

7750SR设备常见故障处理指导书

从以上原因分析可以知道，只要在7750-cr1上有去往222.87.109.17的路由，7750-cr2

上有去往222.87.109.21的路由就能够保证ping包的正确返回，

所以在两台7750上分别配置了如下静态路由：

7750-cr1 static-route 222.87.109.16/30 next-hop 222.87.109.21

7750-cr2 static-route 222.87.109.20/30 next-hop 222.87.109.17

原因分析：

从12000上出来的ping包，因为目的地址是61.159.180.246，查路由表得到匹配的路由

是61.159.180.0/20，有两个下一跳，分别是222.87.109.22和22.87.109.18，因此ping包会

以222.87.109.21和222.87.109.17为源地址分别从两个接口中发出。

我们先考虑从与7750-cr1相连接口发出的包。这个ping包的源和目的地址分别是

222.87.109.21和61.159.180.246。ping包通过7750-cr1到达8016，8016分析后发送ICMP响

应包，包的源和目的地址分别是61.159.180.246和222.87.109.21，发送时以目的地址查路

由表，得到匹配的路由表项是缺省路由，有两个下一跳，分别指向两个7750。如果，ICMP

响应包走7750-cr1，那么包能够顺利回到12000，得到的结果就是ping通。如果，ICMP响应

包走7750-cr2，那么包到达7750-cr2后，会以222.87.109.21为目的地址查路由表，在

7750-cr2上有没有去往222.87.109.21的路由呢？查询的结果是一条黑洞路由

static-route 222.87.109.0/24 black-hole preference 250

所以，ICMP响应包会被丢弃，12000上看到的结果就是ping包丢了。

7750SR设备常见故障处理指导书

12000

.21

222.87.109.20/30

.22

7750-cr1

②这条路ping

包能返回

.17

222.87.109.20/30

.18

7750-cr2

③如果ping包从

8016

这条路返回，因

7750-cr2没有到

2.5G Pos

222.87.109.21的路

由，回包被丢弃

GE

①从12000来的

ping包，原地址是

222.87.109.21 Loopback: 61.159.180.246

同样，12000上从与7750-cr2相连接口出来的包也会有同样情况，也存在ping包丢失。

12000

.21

222.87.109.20/30

.22

7750-cr1

②这条路ping

包能返回

.17

222.87.109.20/30

.18

7750-cr2

③如果ping包从

这条路返回，因

7750-cr1没有到

222.87.109.17的路

由，回包被丢弃

8016

①从12000来的ping

2.5G Pos

包，原地址是

222.87.109.17

GE Loopback: 61.159.180.246

最终的原因就是，在7750-cr1上没有去往222.87.109.17的路由，7750-cr2上没有去往

222.87.109.21的路由。

在这个案例中，业务流量其实运行很正常，但局方因为做ping操作比较多，所以在设计

路由的时候要考虑ping操作的来回路由情况。

7750SR设备常见故障处理指导书

4.3.3 访问控制列表配置不当引起路由协议DOWN掉

用户配置Management Access Filters，设定对指定源IP地址用户的Telnet访问权限，其它

的用户不能Telnet设备，配置情况如下

management-access-filter

default-action permit

entry 10

action permit

src-ip 61.159.168.0/24

dst-port 23 65535

exit

entry 20

action permit

src-ip 61.159.168.0/24

dst-port 23 65535

exit

entry 30

action permit

src-ip 61.159.167.252/32

dst-port 23 65535

exit

entry 200

action deny

exit

exit

在完成上述配置后，用户原意是想对其它的源IP地址做Telnet访问限制，但是在配置时

对最后一个entry没有指定匹配条件，仅仅指定了动作为Deny，结果引起了路由协议Down掉。

7750的Management Access Filters访问控制列表控制所有进入CPM的流量，包括路由协

议报文。控制列表中可以配置若干entry，每个entry在配置action行为之后即生效。在上面的

故障中，当路由协议的报文到来后，顺着前面的entry依次处理，都没有匹配上，来到最后

的entry 200 ，由于在最后一个entry 200 中没有指定匹配条件，那么所有的报文都认为匹配

上，于是执行deny动作把报文丢弃，致使OSPF、BGP协议Down掉。

修改最后的entry 200，指定它的匹配条件为TCP端口号23的精确匹配。

entry 200

action deny

dst-port 23 65535

exit

7750SR设备常见故障处理指导书

上面配置目的端口号时，掩码用来确定端口号的范围，65535代表精确匹配，这是默认

值。

访问控制列表对设备影响很大，在配置时一定要确认参数的正确性。

4.3.4 升级后部分路由无法正常转发

GSR-1

GSR-2

7750SR-

1

7750SR-

2

下行路由器

拓扑如上，两台7750升级完成后发现两台中其中一台路由器下联的设备针对某一个网段

的路由转发异常，从另外一台路由器带源地址转发则正常。

设备升级完成后检查路由表条目show router route-table summary显示路由表条目完整。

A:HBHG7750-1# show router route-table summary

=======================================================

Route Table Summary (Router: Base)

=======================================================

Active Available

----------------------------------------------------------------------------------------------------------------------------

Static 101 104

Direct 30 30

BGP 17757 17757

BGP VPN 0 0

OSPF 783 830

ISIS 0 0

RIP 0 0

7750SR设备常见故障处理指导书

Aggregate 0 0

Sub Mgmt 0 0

------------------------------------------------------------------------------------------------------------------------------

Total 18671 18721

通过show router route-table命令显示路由表学习正常，该路由条目有正确的转发目

的。

A:HBHG7750-1# show router route-table 58.53.195.26

=======================================================

Route Table (Router: Base)

=======================================================

Dest Prefix Type Proto Age Pref

Next Hop[Interface Name] Metric

-----------------------------------------------------------------------------------------------------------------------------

58.52.0.0/14 Remote BGP 04d02h53m 20

58.51.97.10 0

58.52.0.0/14 Remote BGP 04d02h53m 20

58.51.97.14 0

-----------------------------------------------------------------------------------------------------------------------------

No. of Routes: 2

=======================================================

在7750SR-1和7750SR-2上为保证对穿流量在城域网内部因此将IBGP和EBGP

的优先级设定成一样的。在SR-1上面针对该流量是通过互联的GE端口转发到SR-2

上面然后通过EBGP到达163骨干网络。具体配置如下：

A:HBHG7750-1>config>router>bgp# info

----------------------------------------------

always-compare-med zero

min-route-advertisement 2

multipath 16

ibgp-multipath

group "ebgp"

type external

multihop 2

preference 20

export "aggregate_to_bgp"

peer-as 4134

neighbor 202.97.30.22

exit

exit

group "ibgp"

next-hop-self

type internal

7750SR设备常见故障处理指导书

preference 20

peer-as 64923

neighbor 58.51.97.10

exit

neighbor 58.51.97.14

exit

exit

直接从7750SR-1上面发起ping 58.53.195.26地址，Ping包100%丢失。带接口源地址ping

则能ping通。为了能查明该路由的转发路径通过traceroute命令察看，发现无输出。因此又

做了一条直接转发到上联163骨干GSR的静态路由：

A:HBHG7750-1>config>router#static-route 58.53.195.26/32 next-hop 58.51.97.1

做了静态路由以后发现虽然能够顺利到达骨干GSR的下一跳路由，但在下一跳路径上丢失。

A:HBHG7750-1>config>router>bgp# traceroute 58.53.195.26

traceroute to 58.53.195.26, 30 hops max, 40 byte packets

1 58.51.97.1 (58.51.97.10) <10 ms <10 ms <10 ms

2 202.97.19.29 (202.97.19.29) <10 ms <10 ms <10 ms

3 202.97.67.180 (202.97.67.180) <10 ms <10 ms <10 ms

4 0.0.0.0 (0.0.0.0) * * *

5 0.0.0.0 (0.0.0.0) * * *

根据以上现象分析首先怀疑是外网路由出现故障，因为路由表及转发方向均正确。因此

要求电信核查该网段上层路由表。但是核查结果正常，并且发现从GSR-2 ping 7750SR-1

的时候在7750SR-1和7750SR-2之间产生了环路。

直接从7750SR-2上面ping 7750SR-1的下一跳地址及loopback地址。发现环路产生在

互联的第二条链路上。

检查转发表(FIB)，发现loopback地址在7750SR-1 IOM 2上无显示。

A:HBHG7750-1# show router fib 2 58.51.96.1/32

FIB Display

Prefix Protocol

NextHop

----------------------------------------------------------------------------------------------------------------------

--------

No Matching Entries

----------------------------------------------------------------------------------------------------------------------

--------

根据以上显示，认定FIB在重起以后没有完整的装载FIB表，导致路由信息完整，但是

仍然无法正确转发相应的数据。

7750SR设备常见故障处理指导书

此故障是由于第二个IOM卡的FIB没有正确学习到路由表中正确的目的地址造成的。因

此对该板卡进行了手工的强制重起，并将其重新初始化。重起后正确学习到了路由转发路径。

故障解决。

在割接完成以后除了对比一下路由表之外还要对相应板卡的转发表进行比对，确认其

完整性。

4.3.5 Ospf常见故障处理：

4.3.5.1 MTU配置问题导致OSPF无法与对端设备建立邻接关系

现象描述：7750通过GE链路与思科的6509对接，相应的OSPF邻居状态始终进入不了full

状态，总在init和ExchStar状态反复。

ExchStar状态说明协议在进行最初DD报文的交换，并选出DD报文发送的主从关系。在

这个过程中会对DD报文中携带的MTU值进行检查，如果对端的MTU值大于自己接口的

MTU，那么就会丢弃收到的DD报文，协议状态也就不会进一步协商。根据以上分析，我们

检查了7750的MTU配置。首先，在OSPF协议配置中没有指定与6509相连接口的MTU值，那

么协议自动会使用port下面配置的MTU来进行协议协商。可以通过show port命令检查port的

MTU是1518（注意该mtu值包括二层帧头的字节数），减去二层封装开销14Byte（6byte的源

mac地址＋6byte的目的mac地址＋2byte协议号，不包括CRC），实际用于OSPF协商的MTU是

1504，已经大于6509设备那边的MTU1500，所以6509会把7750发过去的DD报文丢弃，协议

状态会止步于ExchStar。

通过更改port的mtu为1514byte，这样ospf双方的mtu值一致才会使得ospf进入full状态。

也可以不改变port的mtu，直接通过在ospf协议下将接口的三层mtu改为和对端一致

>config>router>ospf>area# info

----------------------------------------------

interface "ge-5/1/2:51.*"

mtu 1500

exit

7750SR设备常见故障处理指导书

4.3.5.2 配置了将直连路由重分发进ospf后，直连路由没有发布出去

现象描述：7750上配置了如下policy，将直连路由重分发进ospf，但是其它

设备却无法学到7750的直连路由

>config>router>policy-options#policy-statement "to_ospf"

entry 10

from

protocol direct

exit

to

protocol ospf

exit

action accept

type 1

exit

exit

exit

其它友商设备在redistribute直连等外部路由后，会自动计算本路由器为

asbr，但7750在软件实现上和其它设备有差异，需要在ospf中指定本路由器为asbr，

否则外部路由将无法成功重分发进ospf协议。这是和其它设备差异的地方，需要

注意。进行如下配置后，其它设备学到了7750的直连路由。

>config>router>ospf# info

----------------------------------------------

asbr

4.3.5.3 OSPF参考带宽与其他厂商互联设备设置不一致引起的路由问题

故障现象：

如图，CR1（7750SR-7）、CR2（7750SR-7）、SR（7750SR-7）、8016和6509设备共处OSPF

区域0，12012与CR1、CR2建立BGP邻居。CR1和CR2将BGP学来的路由引入OSPF，同时将OSPF

学习的路由也引入BGP。

现在，用户从12012上ping SR设备（7750SR-7）的system地址，发现丢包比较严重，但

是不全丢。

CR1

S8016

7750SR设备常见故障处理指导书

POS 2.5G

GE

12012

41

100 100

CR2

SR：222.87.109.3/32

1

1

6509

原因分析：

12012设备上到SR system地址的路由是ECMP路由，两个下一跳分别指向CR1和CR2，它发

出的ping包也是负载均衡的发向CR1和CR2。在SR上抓包分析，发现ping包都是从CR1来的，

说明CR2上发生了ping丢包。正常情况ping包应该如图中绿线所示转发。

随即在CR-2上检查，发现CR-2与SR的OSPF邻居已经down掉，再详细检查发现是SR上与

CR-2相连的光纤有问题，更换后恢复正常。

至此，ping丢包问题已经解决。但SR是双联到两台CR上的，当SR与CR2的链路down掉，

ping包应该通过CR2转发过来，即图中的橙色线所示，因此也不应该丢包，这也是SR要双上

联的目的。这个问题的分析如下：

当SR与CR2的链路down掉时，我们在CR2上查询去往SR system地址的路由，查询结果是

A:GZBJ-SR7750-CR-2>config>port# show router route-table 222.87.109.3

=====================================================================Route

Table (Router: Base)

=====================================================================

Dest Prefix Type Proto Age Pref

7750SR设备常见故障处理指导书

Next Hop[Interface Name] Metric

---------------------------------------------------------------------

222.87.109.3/32 Remote OSPF 07d22h00m 10

222.87.109.26 102

---------------------------------------------------------------------

No. of Routes: 1

下一跳是222.87.109.26，再查询这个地址在哪台设备

A:GZBJ-SR7750-CR-2>config>port# show router route-table 222.87.109.26

=====================================================================

Route Table (Router: Base)

=====================================================================Dest

Prefix Type Proto Age Pref

Next Hop[Interface Name] Metric

---------------------------------------------------------------------

222.87.109.24/30 Local Local 0189d23h 0

to 8016 0

---------------------------------------------------------------------No. of

Routes: 1

可以看到这条路由是去往8016的。因此，当ping包来到CR-2后将向8016转发。8016再向

6509转发，即图中的红线所示。用户在6509上检查，发现6509上对icmp包做有限制，所以ping

包就是丢在6509上。

现在再来解释为什么当SR与CR2的链路down掉后，CR-2选择的去往SR system地址的路由

是图中的红线而不是图中的橙线。

在上面CR-2检查去往SR system地址的路由时，发现metric是102。现在我们检查各设备

的接口metric值是多少。在7750设备上检查OSPF的配置，以SR的配置为例：

A:GZBJ-SR7750-SR>config>router>ospf# info

----------------------------------------------

area 0.0.0.0

interface "system"

exit

interface "loopback"

exit

interface "to 6509"

mtu 1500

exit

7750SR设备常见故障处理指导书

interface "to GZBI-7750SR7"

exit

interface "to GZBJ-SR7750-CR-2"

exit

exit

----------------------------------------------

可以看到，接口metric使用的是默认参考带宽100G，通过计算得出各接口的metric（计

算公式：metric=参考带宽/实际带宽），GE接口是100，OC48接口是41，这可以通过查询LSA

来验证，我们检查CR-2的LSA情况：

A:GZBJ-SR7750-CR-2# show router ospf database type router 222.87.109.1 detail

=====================================================================

OSPF Link State Database (Type : Router) (Detailed)

=====================================================================

---------------------------------------------------------------------

Router LSA for Area 0.0.0.0

---------------------------------------------------------------------

Area Id : 0.0.0.0 Adv Router Id : 222.87.109.1

Link State Id : 222.87.109.1 (3730271489)

LSA Type : Router

Sequence No : 0x8000280b Checksum : 0x48e9

Age : 1291 Length : 156

Options : E

Flags : ASBR Link Count : 11

Link Type (1) : Point To Point

--------link1与CR-1相连------

Nbr Rtr Id (1) : 61.159.180.245 I/F Address (1) : 222.87.109.126

No of TOS (1) : 0 Metric-0 (1) : 41

Link Type (2) : Stub Network

Network (2) : 222.87.109.124 Mask (2) : 255.255.255.252

No of TOS (2) : 0 Metric-0 (2) : 41

Link Type (3) : Transit Network

---------lingk3与SR相连-------

DR Rtr Id (3) : 222.87.109.38 I/F Address (3) : 222.87.109.37

No of TOS (3) : 0 Metric-0 (3) : 100

Link Type (4) : Transit Network

---------link4与8016相连-------

DR Rtr Id (4) : 222.87.109.25 I/F Address (4) : 222.87.109.25

No of TOS (4) : 0 Metric-0 (4) : 100

„„其他的省略

=====================================================================

7750SR设备常见故障处理指导书

而hw和c公司的OSPF缺省参考带宽是1G，这样他们设备计算出来的GE接口metric值为1。

最后，网络中各接口的metric如图中标示所示。当CR-2与SR链路down掉后，我们可以计算出

从CR-2到SR system地址最近的路由是经过8016和6509这条，其metric值是102；而通过CR-1

这条路由的metric值有141，这也就解释了为什么CR-2选择8016作为下一跳。

4.3.5.4 移动voip大业务量倒换测试问题处理

拓扑如上，嘉兴，杭州萧山ce设备为sr7750，通过AR设备接入移动ip承载网，CE分别

以一条GE链路连接本节点的AR设备，7750通过创建两个vprn：媒体和信令vpn，每个vpn分别

与AR运行OSPF，实现路由的发布与学习，AR通过发布缺省路由引导ce出流量，并实现这两个

vpn的路由隔离。CE通过2950下挂spatial、AG等ngn设备。两台ce设备接入MC，MGW，MSC时

均采用vrrp实现冗余，提供备份能力，且ce1均为主用，并采用缺省的抢占方式。测试项目

主要为：CE-AR之间链路故障对业务的影响测试；CE故障对业务的影响测试；CE1-CE2链路故

障对业务的影响；MGW至CE媒体链路故障对业务的影响测试；MSC Server信令口主（备）用

链路故障对业务的影响测试；MGW信令口主（备）链路故障对业务的影响测试。测试要求在

以上故障发生时嘉兴和杭州萧山网络实现快速收敛，不能影响嘉兴MC和杭州萧山MSC之间的

通信，达到呼损为0的目的。

7750SR设备常见故障处理指导书

在测试中主要遇到了两个问题：

问题一：在ce1设备断电后，嘉兴MC和杭州萧山MSC之间有4s左右的呼损，不能实现业

务的快速切换。

问题二：在ce1上电后，嘉兴MC和杭州萧山MSC之间有接近5s的呼损。

问题一：MC的网关是指向ce1和ce2的vrrp虚地址上，当ce1断电后，ce2由于收不到主

用ce1发送过来的心跳报文，将会把vrrp状态由backup切换为master，在ce2变为主用之后，

MC发送的报文才可以正常转发，vrrp协议规定处于backup的设备，当3倍的message_interval

时间没有收到master发来的心跳报文，则认为当前的master已经down掉，将自己转为master

状态，由于4.0之前版本（包括4.0）sr7750的message_interval最小为1s，也就是至少要3s

以上ce2才能切换为主用，在这个时间段内MC发送的报文都被丢弃，引起了4s左右的呼损。

问题二：当ce1加电后，有接近5s的呼损，对该问题最初的判断为ce1和ce2之间的vrrp

切换太快，而快于ce1的ospf收敛引起，因为ce1和ce2之间的message_interval为100ms，当

ce1启动后，连接2950的端口一旦up，将会收到ce2发送的心跳报文，此时ce1由于优先级高，

并配置了抢占，将会立刻将自己切换为master状态，此时MC的报文将发送给ce1，但在这么

短的时间内ce1的ospf路由还没有收敛完成，引起数据被丢弃。在ce1上配置了vrrp抢占延时

8s后测试，但是问题仍然存在，还是有接近5s的呼损。说明引起该问题还有其他某个原因。

为了便于定位故障，将ce1的优先级配置为低于ce2，这样ce2一直为主用状态，ce1加

电后将不存在vrrp切换的问题，便于查找引起该问题的其他原因。

在做了以上配置更改后重新测试，发现ce1加电后仍然有接近5s的呼损，通过查看ce2

的配置，发现ce2的ospf配置有一条命令：

area 0.0.0.0

interface "To_AR2_For_Signalling"

interface-type point-to-point

hello-interval 1

dead-interval 4

metric 500（割接入网前客户要求出流量都从ce1出）

在ce1加电之前MC流量一直是发送给ce2，在ce1加电启动的瞬间，出流量的路径也仍然

是MC－2950－ce2－Ar2，当ce1加电启动后并且ce1互联ce2的ge端口up后，ospf邻居开始建

立，在ce1和ce2的ospf邻居建立过程中存在着一个路由收敛的时间，因为ce2从ce1收到

0.0.0.0/0的tpye 5的lsa后，将存在一个ospf收敛的处理过程：从ce2互联AR2出的metric

大，即为上面配置的500，从ce2互联ce1出的metric小，将会优选刚刚从ce1学到的lsa，并

根据这个优选的lsa，计算路由，把下一跳为ce1的缺省路由加入路由表，删除之前下一跳为

ar2的缺省路由，所以，ce1启动后有接近5s的呼损，就是由于这个ospf的收敛引起的，将

7750SR设备常见故障处理指导书

metric 500去掉后，ce2和ce1虽然存在路由收敛，但ce2出流量，一直是选择从AR2出，ospf

的收敛过程并没有引起缺省路由下一跳的变化，从而没有影响MC的数据转发。在将metric

500删除后经过测试，发现呼损为0。

在进行了上一步的测试后，再将ce1的优先级调高，并配置抢占，再进行测试，发现还

有4s多的呼损。此时问题就是一开始分析的vrrp切换时间快于ospf收敛引起，当ce1的互联

2950的fe端口up的瞬间，由于vrrp的message interval很小，达到了100ms ，所以将会立即

抢占过来，但此时ce1的ospf还没有收敛完成，造成了呼损。后来在vrrp里面配置了

init-delay，将vrrp抢占配置了延迟8s钟再抢占。经过以上两个配置调整后，经过测试，达

到了呼损为0的目的。

问题一解决方法：

将sr7750升级至5.0版本，5.0版本支持vrrp的快速切换，message_interval时间最小

可以设置为100ms，将sr升级至5.0R6，并更改message_interval为100ms，ce1断电后测试呼

损为0。

interface "To_2950_Mc_1" create

address 10.70.64.18/28

vrrp 40

backup 10.70.64.17

priority 200

ping-reply

message-interval milliseconds 100

exit

sap 1/1/8 create

exit

exit

问题二解决方法：

将ce2的ospf中metric 500去掉，规避ospf路由收敛而引起的呼损，并配置ce1的vrrp

抢占延时8s，等ce1的ospf收敛完成后再抢占过来

interface "To_2950_Mc_1" create

address 10.70.64.18/28

vrrp 40

backup 10.70.64.17

priority 200

ping-reply

init-delay 8

message-interval milliseconds 100

exit

sap 1/1/8 create

exit

exit

7750SR设备常见故障处理指导书

4.3.6 isis常见故障处理

4.3.6.1 MD5的HASH算法版本不匹配导致ISIS验证失败

7750SR启用ISIS的PSNP、CSNP、LSP及Hello的MD5验证后，与HW厂家路由器

对接，ISIS邻居正常，HW厂家路由器能正学习到7750SR发出的路由，而7750SR12无法

通过ISIS学习到HW厂家路由器的路由，当取消验证，双方均可通过ISIS正常相互学习路

由。

7750SR软件版本：TimOS4.0R11

HW厂家路由器软件版本：VRP5.3

首先将验证改成明文验证，经测试7750SR可以与HW厂家通过ISIS正常进行路由交互。

问题定位为验证问题。

通过检查MD5验证算法密钥的一致性，二边密钥一致。

最后修改MD5验证的HASH算法版本后，7750SR已可以通过ISIS与HW厂家路由

器在启用验的条件下正常交互路由信息。

7750SR修改HASH算法版本的命令：

config system security hash-control [read-version {1 | 2 | all}] [write-version {1 | 2}]

该命令可以修改使用HASH算法读写的版本，可根据具情况修改，缺省情况读写均为

version 2。

HASH算法版本不一致，HASH算出的结果也不一致，导致MD5验证失败。据现场测

试与C厂家对接时也存在类似现象，均可以通过修改HASH算法来实现互通。

4.3.6.2 与第三方设备（测试仪表类）建立ISIS邻接关系时遇到的问题

现象描述：7750SR12通过GE口与测试仪表（IXIA）对接，并在端口上启ISIS协议。

当双方接口类型配置为broadcast时，邻居关系能够正常建立。当双方接口类型配置为point

to point时，邻居关系无法建立。

7750SR软件版本：TimOS4.0R11

测试仪表厂家：IXIA

7750SR设备常见故障处理指导书

首先将双方接口类型改成broadcast，经测试7750SR可以与测试仪表建立isis邻居关系。

再将双方接口类型改成point to point，邻居关系无法建立。Isis在点对点网络中使用三次握

手方式来建立邻接关系。在7750SR侧修改isis下的邻接关系检测方式为严格检测方式，

7750SR与测试仪表正常建立isis邻居关系。在与第三方设备启ISIS协议时，可能会用到该

项设置

7750SR修改严格邻接检测方式的命令：

config router isis strict-adjacency-check

该命令可以使7750SR在建立isis邻居的过程中使用严格的三次握手方式。

4.3.7 bgp常见故障处理

4.3.7.1 IBGP连接经常重启故障案例

7750 与华为NE80E （BGP RR）间的ibgp关系不定期重建。

以下为log告警信息：

7750SR设备常见故障处理指导书

59154 2007/07/16 11:02:52.69 UTC WARNING: BGP #2011 - Peer 1: 221.130.211.253

"VR 1: Group IPNET-VPN: Peer 221.130.211.253: remote end closed connection"

59153 2007/07/16 11:02:46.78 UTC WARNING: BGP #2002 - Peer 1: 221.130.211.253

"VR 1: Group IPNET-VPN: Peer 221.130.211.253: moved from higher state ESTABLISHED to lower

state IDLE due to event TCP SOCKET ERROR"

出现这个问题后，根据7750的系统日志和抓包结果看，发现7750与相关bgp邻居间并未

收到或发送notification消息，而是在出现tcp socket error的告警后，中断tcp连接并重

新建立bgp session。由此判断是由本端侦测到连接问题而重置bgp session。检查后发现所

有受影响的7750都打开了bgp-peer-tracking的功能，在某一台中关闭该功能后，bgp连接到

目前为止保持稳定。

配置如下：

……

bgp

no enable-peer-tracking

hold-time 180

keepalive 60

从故障现象看，这不是单点问题也与bgp消息无直接关系，而与bgp tcp连接有关。7750

中enable-peer-tracking是用来加快bgp收敛和响应速度的，在激活的状态下一旦在路由表

中发现bgp对端邻居不可达则立即中止该连接而无需等待bgp消息超时。

在本例中7750打开了该功能，所以一旦出现bgp邻居地址路由振荡就有可能重置此连接。

据此，在AR3/AR4/AR5/AR6查看bgp 事件纪录及路由表状态，可以确定bgp连接的震荡是

由IGP(ISIS)的变化引起的，而在enable-peer-tracking的状态下7750会迅速发现该问题且

重置bgp连接。整理记录如下：

AR3:

show time

Tue Jul 17 09:05:29 UTC 2007

A:BJBJ-BA-IPNET-RT03-7750SR12# show router route-table

=============================================================================

==

Route Table (Router: Base)

=============================================================================

==

Dest Prefix Type Proto Age Pref Next Hop[Interface

Name] Metric

7750SR设备常见故障处理指导书

„..

221.130.211.254/32 Remote ISIS 00h16m37s 18 10.1.1.221

5007

„..

59923 2007/07/17 08:48:56.33 UTC WARNING: BGP #2002 - Peer 1: 221.130.211.254

"VR 1: Group IPNET-VPN: Peer 221.130.211.254: moved from higher state ESTABLISHED

to lower state IDLE due to event TCP SOCKET ERROR"

AR4:

show time

Tue Jul 17 08:57:41 UTC 2007

A:BJBJ-BA-IPNET-RT04-7750SR12# show router route-table

=============================================================================

==

Route Table (Router: Base)

=============================================================================

==

Dest Prefix Type Proto Age Pref

Next Hop[Interface Name] Metric

-----------------------------------------------------------------------------

--

„

221.130.211.254/32 Remote ISIS 00h08m53s 18 10.5.64.1

5009

„..

No bgp bouncing since disabling peer-tracking.

AR5:

show time

Tue Jul 17 09:03:17 UTC 2007

A:BJBJ-BA-IPNET-RT05-7750SR12# show router route-table

=====================================================Route Table (Router:

Base)

=====================================================Dest Prefix

Type Proto Age Pref

7750SR设备常见故障处理指导书

Next Hop[Interface Name] Metric

-----------------------------------------------------------------------------

--

„„

221.130.211.254/32 Remote ISIS 00h14m42s 18

10.1.1.217 5321

„„

7540 2007/07/17 08:48:55.28 UTC WARNING: BGP #2002 - Peer 1: 221.130.211.254

"VR 1: Group IPNET-VPN: Peer 221.130.211.254: moved from higher state ESTABLISHED

to lower state IDLE due to event TCP SOCKET ERROR"

AR6:

show time

Tue Jul 17 09:01:46 UTC 2007

A:BJBJ-BA-IPNET-RT06-7750SR12# show router route-table

=====================================================Route Table (Router:

Base)

=====================================================Dest Prefix Type

Proto Age Pref Next Hop[Interface Name]

Metric

-------------------------------------------------------„„

221.130.211.254/32 Remote ISIS 00h13m12s 18

10.5.66.1 5324

„„

4471 2007/07/17 08:48:55.21 UTC WARNING: BGP #2002 - Peer 1: 221.130.211.254

"VR 1: Group IPNET-VPN: Peer 221.130.211.254: moved from higher state ESTABLISHED

to lower state IDLE due to event TCP SOCKET ERROR"

可以发现所有的bgp session中断都与对端地址路由的振荡有关，而这种振荡是全局性

的，并非单点现象，7750只是根据配置（peer-tracking）迅速的对振荡做出了反应。

在存在路由震荡的网络中，应关闭BGP 的peer-tracking 功能，BGP 邻居通过hold time

控制。查找IGP振荡的原因。

BGP peer tracking功能用来tracking BGP peer，一旦peer 的loopback路由在IGP路由表中

消失（不可达），立即触发BGP断开连接（session），该功能的打开最大程度加快了BGP路

由的收敛。

1. BGP next hop address tracking功能

7750SR设备常见故障处理指导书

默认BGP通过每60秒scan一次RIB&查找BGP下一跳可达信息来选择，确认最优路由，

这种方式下，IGP路由震荡很容易造成黑洞路由和环路。而next hop address tracking功能是事

件驱动的，打开该功能后，在BGP peer session已经建立情况下， BGP next hop 的变化会立

即触发BGP收敛。

2. 7750实现机制

7750在整个系统设计架构中就采用了事件触发机制，避免scan，polling方式无法及时

处理事件的矛盾，因此在BGP下一跳发生改变时，7750可以迅速作出反应，避免黑洞和环路，

BGP能迅速收敛。也就是说7750从系统设计上就已经保证了对next hop address tracking的功

能的支持。

3. 在Lab测试中，以三台7750模拟RR和AR，在一台AR 宕机后，在另一台AR

上通过CLI查看到BGP路由迅速收敛。

综上所述，PEER-TRACKING和next hop address tracking并非同一功能。next hop address

tracking是7750实现BGP快速收敛的基本功能，PEER-TRACKING是7750 私有的功能。

4.3.7.2 BGP宣告路由不全问题的处理

两台7750在将静态路由通过路由策略发布到BGP时，其中一台SZX-7750-1无法将部分

路由发送给EBGP邻居。

首先，在设备上执行了以下查询步骤：

1、policy-statement中指定的Prefix-list路由存在于"Static Route Configuration"的静态路

由配置中。

2、这些需要发送的路由存在于路由表中。

3、查询SZX-7750-1 BGP发送给EBGP的路由，缺少以下条目：

58.223.224.0/24

202.102.15.0/24

202.102.41.0/24

4、通过clear router bgp neighbor *.*.*.* 重新建立BGP session，仍然无法发出以上路由。

5、在BGP中删除并重新导入Policy策略，shutdown EBGP邻居，故障依旧。

7750SR设备常见故障处理指导书

经过进一步的检查，发现BGP Router-id存在异常：设备配置的Router-id是61.132.78.33，

而显示的Router-id却是61.132.78.32。分析是配置曾经发生变更所致。

将BGP进程重新启动后，BGP Router-id与配置一致，路由宣告成功。

SZX-7750-1# config router bgp

SZX-7750-1>config>router>bgp# shutdown

SZX-7750-1>config>router>bgp# no shutdown

建议保持Route-id稳定，避免不必要的更改。如果更改，应该重新启动OSPF，BGP等

路由协议进程，以保证新的Router-id得到应用。

4.3.7.3 7750路由宣告问题的处理

故障描述：7750通过BGP向其邻居宣告路由，完成配置后路由不会自动宣告，必须手动

clear BGP neighbor后路由才能宣告。

导致此现象的原因是配置问题。命令config router triggered-policy用来控制是否自

动根据策略配置宣告路由。配置了此命令后，必须通过clear router bgp neighbor

(soft) 命令触发路由更新；如果将此配置关闭，则BGP会根据

policy-option的配置自动宣告路由。此命令默认disable。

命令triggered-policy提供了控制路由宣告的一种手段，可以根据需要配置。

4.3.8 mpls常见故障处理

4.3.8.1 由于更改system地址后没有restart ospf导致MPLS-TE FRR故障

故障描述：新增业务需要布署MPLS-TE FRR，拓扑结构如下图，PE1的system地址重

新规划（规划后的system地址为10.10.10.11），配置完成后，发现无法实现FRR。

7750SR设备常见故障处理指导书

主用LSP

bypass LSP

ospf area

P3

P1 P2

PE11PE21

故障现象表现为：在PE2上show router mpls lsp path detail，发现MPLS LSP PATH

中的Actual Hops 下没有detour 标识。

A:PE2>config>router>mpls# show router mpls lsp path detail

===============================================================================

MPLS LSP Path (Detail)

===============================================================================

Legend :

@ - Detour Available # - Detour In Use

b - Bandwidth Protected n - Node Protected

===============================================================================

-------------------------------------------------------------------------------

LSP toPE1 Path loose

-------------------------------------------------------------------------------

LSP Name : toPE1 Path LSP ID : 20

From : 10.10.10.22 To : 10.10.10.11

Adm State : Up Oper State : Up

Path Name : loose Path Type : Primary

Path Admin : Up Path Oper : Up

OutInterface: 1/2/1 Out Label : 131064

Path Up Time: 0d 00:00:28 Path Dn Time : 0d 00:00:00

Retry Limit : 0 Retry Timer : 30 sec

RetryAttempt: 0 Next Retry In : 0 sec

Bandwidth : No Reservation Oper Bandwidth : 0 Mbps

Hop Limit : 255

Record Route: Record Record Label : Record

Oper MTU : 9198 Negotiated MTU : 9198

7750SR设备常见故障处理指导书

Adaptive : Enabled MBB State : Fail

Include Grps: Exclude Grps :

None None

Path Trans : 15 CSPF Queries : 14

Failure Code: noError Failure Node : n/a

ExplicitHops:

No Hops Specified

Actual Hops :

192.168.2.1(10.10.10.22)

-> 192.168.2.2(10.10.10.2) Record Label : 131064

-> 10.12.0.1(10.10.10.1) Record Label : 131059

-> 192.168.1.1(10.10.10.11) Record Label : 131055

ComputedHops:

192.168.2.1 -> 192.168.2.2 -> 10.12.0.1 -> 192.168.1.1

===============================================================================

在PE2上通过show router ospf opaque-database，没有Adv Rtr Id为10.10.10.11的database

项。

A:PE2>config>router>mpls# show router ospf opaque-database

===============================================================================

OSPF Opaque Link State Database (Type : All)

===============================================================================

Type Id Link State Id Adv Rtr Id Age Sequence Cksum

-------------------------------------------------------------------------------

Area 0.0.0.0 1.0.0.1 10.10.10.1 505 0x80000005 0xa03

Area 0.0.0.0 1.0.0.1 10.10.10.2 969 0x80000004 0x10fb

Area 0.0.0.0 1.0.0.1 10.10.10.3 1284 0x80000005 0x12f6

Area 0.0.0.0 1.0.0.1 10.10.10.4 1021 0x8000002c 0xc718

Area 0.0.0.0 1.0.0.1 10.10.10.22 1255 0x80000005 0x5e84

Area 0.0.0.0 1.0.0.1 10.10.10.33 300 0x80000005 0x8a42

Area 0.0.0.0 1.0.0.1 10.10.10.34 1113 0x8000002b 0x4262

Area 0.0.0.0 1.0.0.1 10.10.10.45 1764 0x80000004 0xbcf8

-------------------------------------------------------------------------------

No. of Opaque LSAs: 8

Ospf TE使用opaque LSA，MPLS TE使用ospf的opaque LSA type 10，由于ospf

opaque-database中没有10.10.10.11的database，因此发生了该故障。

通过在configure router ospf下shutdown，然后no shutdown，重启ospf进程。

重启ospf进程后，在PE2上show router ospf opaque-database，存在Adv Rtr Id为

10.10.10.11的database项。

A:PE2>config>router>mpls# show router ospf opaque-database

7750SR设备常见故障处理指导书

===============================================================================

OSPF Opaque Link State Database (Type : All)

===============================================================================

Type Id Link State Id Adv Rtr Id Age Sequence Cksum

-------------------------------------------------------------------------------

Area 0.0.0.0 1.0.0.1 10.10.10.1 649 0x80000005 0xa03

Area 0.0.0.0 1.0.0.1 10.10.10.2 1113 0x80000004 0x10fb

Area 0.0.0.0 1.0.0.1 10.10.10.3 48 0x80000006 0x10f7

Area 0.0.0.0 1.0.0.1 10.10.10.4 1165 0x8000002c 0xc718

Area 0.0.0.0 1.0.0.1 10.10.10.11 22 0x80000002 0x38c3

Area 0.0.0.0 1.0.0.1 10.10.10.22 1399 0x80000005 0x5e84

Area 0.0.0.0 1.0.0.1 10.10.10.33 444 0x80000005 0x8a42

Area 0.0.0.0 1.0.0.1 10.10.10.34 1257 0x8000002b 0x4262

Area 0.0.0.0 1.0.0.1 10.10.10.45 126 0x80000005 0xbaf9

-------------------------------------------------------------------------------

No. of Opaque LSAs: 9

相应地，PE2上show router mpls lsp path detail也出现了detour标识。

A:PE2>config>router>mpls# show router mpls lsp path detail

===============================================================================

MPLS LSP Path (Detail)

===============================================================================

Legend :

@ - Detour Available # - Detour In Use

b - Bandwidth Protected n - Node Protected

===============================================================================

-------------------------------------------------------------------------------

LSP toPE1 Path loose

-------------------------------------------------------------------------------

LSP Name : toPE1 Path LSP ID : 20

From : 10.10.10.22 To : 10.10.10.11

Adm State : Up Oper State : Up

Path Name : loose Path Type : Primary

Path Admin : Up Path Oper : Up

OutInterface: 1/2/1 Out Label : 131064

Path Up Time: 0d 00:01:29 Path Dn Time : 0d 00:00:00

Retry Limit : 0 Retry Timer : 30 sec

RetryAttempt: 0 Next Retry In : 0 sec

Bandwidth : No Reservation Oper Bandwidth : 0 Mbps

Hop Limit : 255

Record Route: Record Record Label : Record

Oper MTU : 9198 Negotiated MTU : 9198

7750SR设备常见故障处理指导书

Adaptive : Enabled MBB State : Fail

Include Grps: Exclude Grps :

None None

Path Trans : 15 CSPF Queries : 14

Failure Code: noError Failure Node : n/a

ExplicitHops:

No Hops Specified

Actual Hops :

192.168.2.1(10.10.10.22)

-> 192.168.2.2(10.10.10.2) @ Record Label : 131064

-> 10.12.0.1(10.10.10.1) Record Label : 131059

-> 192.168.1.1(10.10.10.11) Record Label : 131055

ComputedHops:

192.168.2.1 -> 192.168.2.2 -> 10.12.0.1 -> 192.168.1.1

===============================================================================

另外，在部署ospf te时，需要注意所有的设备都必须在相同的area内，因为ospf te所采

用的lsa类型为type 10，type 10类型的lsa只在本区域内泛洪。

4.3.8.2 由于不同厂商mpls分发机制不同引起的业务故障

P1

5/2/1

5/2/2

P2

5/2/2

5/2/1

PE1

PE2

故障描述：某运营商城域网拓扑如上，两台核心设备为思科crs-1，汇聚设备为sr7750，

两台7750作为pe设备，crs-1作为p设备，IGP为ospf，两台7750开启ECMP， 7750（pe1）和

7750（pe2）开启vpls业务，pe1与两台核心p设备ldp邻居状态正常，pe2只与p1建立ldp邻居，

pe2与p2没有建立ldp邻居，此时vpls业务出现故障，在pe2上学不到pe1过来的mac地址，但

是在pe1上却可以学到pe2过来的mac地址，并且在两台pe上用show service id xx sdp 查看

状态是正常的。

7750SR设备常见故障处理指导书

原因分析：在mpls的控制平面，标签控制方式分为两种：有序标签控制方式（ordered）

和独立标签控制方式（Independent）。只有当LSR收到某一特定FEC下游标签映射时、或者

LSR是LSP的出口节点时，该LSR才向上游分配标签，这种方式称为有序标签控制方式，与此

相反，LSR只要有某一特定FEC的路由信息，就会向上游分配该FEC标签的方式称为独立标签

控制方式。

PE1与P1和P2都建立了ldp邻居关系，PE2只和P1建立了ldp邻居关系，对vpls的控制平

面来说，PE1可以和远端PE2成功建立sdp，因为存在一条有效的LSP：PE1P1PE2。同样地，

对PE2来说，也可以和远端PE1成功建立sdp，因为同样存在一条有效的LSP：PE2P1PE1。

对于控制平面，一条有效的LSP即可使得sdp成功建立，所以此时在两台PE上通过show

service id xx sdp 查看状态是正常的。这是vpls的控制平面的情况。

当双向的sdp都建立成功后，就可以承载vpls流量，我们再看看vpls的转发平面。当PE1

的vpls学到下面交换机的广播帧后，会将该广播帧加上双层mpls标签，外层标签即为到达PE2

system地址的所分配标签，由于思科设备的mpls分发机制为独立标签控制方式，也就是只要

路由表里面有的路由，P2都会分配标签给他的上游设备，虽然PE2没有分配标签给P2，但由

于P2采用了独立标签控制方式，PE1是可以收到P2分配的去往PE2 system地址的标签的。查

看PE1的标签绑定，可以发现去往PE2的system地址有两个标签，一个标签是由P1分配的，出

接口为5/2/1；另一个标签由P2分配的，出接口为5/2/2。PE1由于开启了ECMP，去往PE2将会

有两条等值路由，由于这两条路由的下一跳都分配了标签，7750将会根据hash算法随机选择

一个标签进行转发，并且以后的转发都使用这个标签，负载均衡是基于流，而非基于包的。

假设转发表决定了从5/2/2接口转发，此时PE1会选择P2分配的标签，封装到数据包的头部，

然后从接口5/2/2转发给P2。由于路由驱动标签转发，P2收到该数据包后，查找FEC映射表，

发现应该从直连PE2的接口进行转发，但是从该接口并未收到PE2分配的标签，从而导致数据

无法被封装而被丢弃。也就是说PE1的mac地址传递到P2的时候被丢弃，无法再继续被转发到

PE2，从而导致PE2无法学到PE1的mac地址。同样可以分析，当PE2收到下面的广播帧后，虽

然也有两条等值路由，但是只有P1给PE2分配去往PE1 system地址的标签，PE2没有选择，只

能采用P1分配的标签，加到数据头部，转发给P1，P1收到后将会把数据再转发给PE1，这个

过程是没有问题的，沿途LSP没有发生断裂，所以PE1是可以学到PE2的mac地址。

同样可以分析，如果PE2至P2的ldp邻居成功建立，PE2至P1的ldp邻居没有建立，那么

将不会出现故障，PE2将可以学到PE1的mac地址，因为PE1P2PE2没有发生LSP断裂。PE1

也可以学到PE2的mac地址，PE2通过PE2P2PE1这条LSP传送给PE1。

7750SR设备常见故障处理指导书

该问题是由不同厂家的mpls分发机制不同而引起的故障，如果核心设备为7750将不会

出现这种问题，因7750是采用有序标签控制方式，P2将不会分配标签给PE1，PE1只能选择P1

分配的标签，不会引起lsp的断裂。但思科采用独立标签控制方式也不是什么缺陷，因为这

两种方式都是rfc规定的两种模式，将PE2至P2的ldp邻居建立即可解决。

这种由于不同厂家的mpls分发机制不同的问题需要注意规避。华为、7750、juniper

路由器均是采用有序标签控制方式，思科采用独立标签控制方式。不同的标签分发机制有可

能引起vpn业务问题，处理障碍时可以作为一个考虑点进行分析。

4.4 业务常见故障处理

4.4.1 ies常见故障处理

4.4.1.1 ies割接后业务不通，对端用户无法ping通

现象描述:将原来思科6509上的专线用户割接至7750上后，ies业务不通。

在同网段应用ping 命令是用来测试网络通达的最普通方法，例如从A主机ping到B主

机，Ping命令会构建一个固定格式的ICMP请求数据包，然后由ICMP协议将这个数据包连同地

址一起交给IP层协议，IP层协议将填入目的地址，本机IP地址作为源地址，加上一些其他的

控制信息，构建一个IP数据包，并在一个映射表中查找出目标ip地址所对应的物理地址，一

并交给数据链路层。后者构建一个数据帧，目的地址是IP层传过来的物理地址，源地址则是

本机的物理地址，还要附加上一些控制信息，依据以太网的介质访问规则，将它们传送出去。

7750SR设备常见故障处理指导书

目的主机收到这个数据帧后，先检查它的目的地址，并和本机的物理地址对比，如符合，则

接收;否则丢弃。接收后检查该数据帧，将IP数据包从帧中提取出来，交给本机的IP层协议。

同样，IP层检查后，将有用的信息提取后交给ICMP协议，后者处理后，马上构建一个ICMP

应答包，发送给主机A，其过程和主机A发送ICMP请求包到主机B一模一样。

在故障处理中A主机能找到B主机的MAC，说明物理链路应该没有问题，但却ping不通B

主机，所以需要确认在B主机里是否也能找到A主机的MAC。当时立即选取一个故障网吧检查，

发现网吧的路由器作了MAC地址绑定。至此，故障原因找到，为网吧路由器作了MAC绑定。

Ies还可能出现另一种故障，从思科交换机割接上来后ies业务不通，原因为用户端网关

地址配置错误，因为思科交换机是缺省打开了arp-proxy功能的，计算用户端的网关地址配

置错误，也不会影响用户的上网业务。而7750缺省是关闭arp-proxy功能的，所以引起了这

些用户从思科交换机割接至7750后业务不通，此时只需在7750响应ies接口下打开arp-proxy

功能即可。

4.4.1.2 subscriber-interface业务无法开通故障

subscriber-interface是ies的一种灵活运用，该应用可以实现一个interface下面

终结多个sap，普通的ies的interface接口，只能终结一个sap的业务流量，但是

subscriber-interface通过group-interface可以终结多个sap，但需要注意，在同一个

group-interface中的sap的接入端口需要一致，如果不一致，需要再新建

group-interface来终结。

另外，一个subscriber-interface可以配置最多16个不同网段的ip，实现用户

极其灵活的接入。

>config>service>ies# info

----------------------------------------------

subscriber-interface "test" create

address 1.1.1.1/30

address 1.1.2.1/24

group-interface "test1" create

sap 5/1/5:999.999 create

exit

exit

group-interface "test2" create

sap 5/1/4:888.888 create

exit

7750SR设备常见故障处理指导书

exit

exit

在进行了以上配置后，ping该subscriber-interface接入的用户时，发现无法

ping通，subscriber-interface业务无法开通。请注意，7750在实现subscriber-interface

时需要指定下面接入用户的ip地址或者mac地址，目的是为了防止地址哄骗，如

果不配置，则用户业务不通

>config>service>ies>sub-if# info

----------------------------------------------

address 1.1.1.1/30

address 1.1.2.1/24

group-interface "test1" create

sap 5/1/5:999.999 create

anti-spoof ip --------配置通过ip指定下挂主机，也

可以选择通过mac指定下挂主机

host ip 1.1.2.2 --------配置下挂主机ip

host ip 1.1.2.3 --------配置下挂主机ip

exit

exit

group-interface "test2" create

sap 5/1/4:888.888 create

anti-spoof ip

host ip 1.1.1.2

host ip 1.1.2.7

exit

exit

7750SR设备常见故障处理指导书

4.4.2 vpls常见故障处理

4.4.2.1 arp广播引起的网络设备故障

IP/MPLS

core

erx1440

sr7750

Cisco6509

Pvlan1901

Dslam1

网管vlan26

Cisco4506

Pvlan1903

Dslam2

网管vlan26

拓扑如上所示：某运营商出现大量宽带用户拨号故障，提示678故障（远程计算机没有

反应）。同一台dslam接入，出现有的用户可以拨号，有的用户无法拨号的现象。Bras的cpu

利用率极高，达到90％以上。

拓扑简介：以某节点为例：dslam的业务vlan和网管vlan透传至4506时被打上qinq的双

层vlan，4506将该双层vlan流量透传至6509，6509再分别将业务流量透传至erx1440，网管

流量透传至sr7750，sr7750通过配置vpls将双层vlan转换为单层vlan（内层vlan）再透给

6509，6509最后将网管流量通过与sr互联的另一条链路透传至sr7750并被终结在7750。

如上图所示，当dslam1发出一个arp广播请求时，4506收到后将会打上外层vlan1901，

内层vlan为26，透传至6509，6509这时会生成mac表项，表项条目为vlan1901，端口号，学

到的dslam1的 mac地址。6509然后将arp广播分别透传至erx1440和7750，erx1440收到后去

掉外层和内层vlan，解封装后丢弃arp广播包。6509同时会透传该arp广播包至7750，对于同

一个vpls来说，vpls内的sap点都处于同一个广播域，当vpls中的某个sap点接受到广播数据

后，7750采取的措施和普通交换机没有什么区别，将会向所有同一广播域内的端口（sap点）

泛洪该广播包，因此7750将会去掉接受到的广播包的双层vlan，并重新封装双层vlan或者单

7750SR设备常见故障处理指导书

层vlan。比如，将会封装成外层1903内层26的广播包和单层vlan26的广播包，然后透传给

6509，6509收到后将会在mac 转发表中再添加一个条目：vlan1903，端口号，学到的dslam1

的mac地址。最后再将该arp广播包透传给erx1440，erx1440解封装后丢弃广播包。

可以设想，7750如果一个vpls内有127个sap点，那么其中任何一个sap收到arp广播包，

将会泛洪到别的126个sap点，也就是说，任何一个sap点收到的arp广播包将被复制成126个

arp广播包，并往下转发给6509，6509也将会再添加126个mac的条目，如果这127个sap在某

段时间内都受到了接入dslam的arp广播包，那结果就是有127×126＝16002个广播包转发给

了6509，并导致6509新增加16002个mac条目。6509会把这16002个广播包透传给erx1440。而

衢州电信的某些节点网管vpls内的sap点很多，超过100个。导致6509的mac表项非常巨大，

达到5-8万个条目，巨大的mac database表项，对6509的转发效率构成制约，更严重的是

erx1440将会花费很大的资源去处理这些数目庞大的广播包，引起cpu升高，正常的拨号用户

由于没有资源去处理，而被丢弃，引起部分用户拨号无法连接。

由于网管vlan只要求和网关互通就可以，并不需要网管直接能够互通，所有在7750上采

用水平分割的策略，隔离各个接dslam的sap，将这样的sap加入水平分割组，接网关的sap

并不加入水平分割组，达到大幅减少arp广播的目的，同时不会影响dslam等设备的网管。以

下为一个水平分割的典型配置：

vpls 300021 customer 1000 create

description "CS-Manager"

split-horizon-group "300021" create

exit

stp

no shutdown

exit

sap 5/1/1:2266.21 split-horizon-group "300021" create

exit

sap 5/1/1:2274.21 split-horizon-group "300021" create

exit

sap 5/1/1:2560.21 split-horizon-group "300021" create

exit

sap 5/1/1:21.* create

exit

no shutdown

exit

7750SR设备常见故障处理指导书

以上配置中sap 5/1/1:21.*为接网关的sap，不能加入水平分割组，其余的全部加入水

平分割组，达到arp广播的抑制。采用水平分割后，6509的mac database条目由原来的5－8

万减少至6千左右，同时erx接受到的广播报文急剧下降，在进行了水平分割配置后，原先无

法拨号的用户都恢复了正常。经过一周观察，没有再出现用户故障。

4.4.2.2 使用filter-log进行vpls业务丢包故障定位

故障描述： dslam网管ip光电收发器光电收发器二层交换机7750

网关设备。发现从网关设备上pingdslam网管ip时有丢包，需要定位故障点。

为了定位故障点，在7750上面配置filter-log，只要7750将从网关设备收到到ping

request数据包转发给了二层交换机，说明7750没有问题。以下为filter-log的一个配置示

例：

A:A7750>config>filter# info

----------------------------------------------

log 102 create //定义filter-log

description "Default filter log"

destination memory 20000 //抓20000个 数据包

exit

ip-filter 100 create //定义filter配置需要抓包的内容

default-action forward

entry 1 create

match protocol icmp

exit

log 101

action forward

exit

exit

然后将该ip-filter应用到vpls的sap下面

使用show filter log 101可以查看数据包的摘要信息。

通过filter-log发现7750成功将icpm request报文转发出去，最后在二层交换机和

dslam端口做镜像抓包，发现二层交换机也将icmp request数据发送出去，但是dslam没有接

收到，故障定位为之间的光电收发器问题，更换光电收发器后问题解决。

7750SR设备常见故障处理指导书

4.4.3 vprn常见故障处理

4.4.3.1 vprn的路由限制功能无法生效

在vprn中使用maximum-routes命令来限制路由条目时，发现配置后无法生效。

需要注意，在使用maximum-routes命令限制vprn路由条目时，必须先将vprn shutdown，

在使用改命令修改vprn最大路由条目时，vprn必须处于down的状态，否则修改后不生效。

还需要注意，使用maximum-routes命令限制路由数目，只限制bgp-vpn等路由条目，并

不包括直连路由条目数。

4.4.3.2 vprn通过option a方式实现跨域mpls vpn时，对端asbr无法学到本as内的私网路

由。

现象描述：7750作为城域网asbr，通过option a方式实现跨域互通，但对端asbr响应

vrf无法学到本as内的私网路由。

查看配置如下：

>config>service>vprn#

description "HuanBaoJianKong"

autonomous-system 64758

route-distinguisher 4809:4545002

auto-bind ldp

vrf-target target:4809:4545002

interface "to-lag-1:3785.*" create

description "HBJK-NAS"

address 172.44.36.113/29

sap lag-1:3785.* create

exit

exit

interface "to-lag-1:3799.*" create

description "HBJK-WuShuiChuLi"

address 172.44.36.1/29

sap lag-1:3799.* create

exit

exit

interface "TO-6/1/10:101" create

description "TO-CZ-CN2-PE-HuanBaoJianKong"

address 42.13.255.254/30

sap 6/1/10:101 create

7750SR设备常见故障处理指导书

exit

exit

static-route 42.13.0.0/16 black-hole

bgp

group "hb-ebgp"

peer-as 4809

neighbor 42.13.255.253

exit

exit

exit

no shutdown

通过配置，可以看到在bgp中没有配置policy，这是7750和其它厂家的区别，思科设备

会自动将vpnv4路由重分发进入vrf的bgp路由表中，但7750需要通过策略，将bgp-vpn路由重

分发进bgp路由，否则vrf的bgp路由无法发送给对端asbr设备。通过增加以下配置后解决：

>config>router>policy-options#

prefix-list "hb-outbound-cn2"

prefix 42.13.0.0/16 prefix-length-range 16-32

exit

policy-statement "hb-outbound-cn2"

entry 10

from

protocol bgp-vpn

prefix-list "hb-outbound-cn2"

exit

to

protocol bgp

exit

action accept

exit

exit

entry 20

from

protocol direct

prefix-list "hb-outbound-cn2"

exit

to

protocol bgp

exit

action accept

exit

exit

entry 30

7750SR设备常见故障处理指导书

from

protocol static

prefix-list "hb-outbound-cn2"

exit

to

protocol bgp

exit

action accept

exit

exit

exit

bgp

group "hb-ebgp"

export "hb-outbound-cn2"

peer-as 4809

neighbor 42.13.255.253

exit

exit

exit

4.4.3.3 7750与友商设备测试VPNV4路由正常学习但业务无法转发

7750与友商华为、REDBACK测试时，发现华为公司测试用产品S8512与我方的SR7750、

REDBACK的SE800在进行MPLS L2/L3 VPN对接时均不通，具体问题如下：

MPLS L2 VPN测试，对方学习不到的我方MAC，但我方SR7750可以学习到对方MAC，无法

转发；MPLS L3 VPN双方都可以学习到对方私网路由，但是无法转发。

在相同的组网结构下，我方7750自测，设备间MPLS L2/L3 VPN对接均正常。

7750SR设备常见故障处理指导书

问题分析如下：

MPLS L2 VPN环境下，我方可以学习到对方（华为）MAC，证明ARP request报文已经到

达对方，对方回应ARP reply报文，并且我方已经收到。而对方学习不到我方MAC证明在对方

要么没有发出ARP request报文，要么发出ARP request后但没有收到我方的ARP reply报文，

这样也就是说在MPLS L2 VPN环境下是可以实现报文单通的，通过对方抓包分析可以证明这

点：

1) （对方ARP request已经打上标签发出去，但没有收到我方的回应）

2) 在MPLS L3 VPN环境下，双方都可以学习到对方路由，证明MP-BGP建立是正常的，

路由学习也正常，抓包结果显示我方的icmp echo报文同样是发出去了，但是没

有收到回应；

3) 根据上述现象，我们怀疑回应报文没有发出或者是丢弃在中间的设备了。

4) 解决方法：在SR7750上镜像抓包，发现无论在MPLS L2/L3 VPN环境下都是正常

7750SR设备常见故障处理指导书

的，证明我方PE（SR7750）设备已经将回应报文发出；

5) 为了不影响现网业务，华为测试前将现网流量全部调至S8512—7609-2链路上

（通过修改7609-1下联S8512接口的ospf cost值以及在S8512上使用静态缺省

路由实现），仅在S8512—7609-1—SR7750链路上启用LDP，链路网络拓扑如图

所示：

由于目前S8512上建立LDP session使用的是loopback接口，如图所示：

对于P 7609-1设备来说，S8512的loopback路由是从S8512—7609-2—7609-1链路学来

的，因此在P 7609-1上的LSP：221.194.32.28/32（S8512 loopback地址）对应的出接口为

接口A，但是A接口并没有启用LDP，带有一层MPLS标签的报文就会被丢弃掉，也就是说：

（S8512—SR7750方向）

发报文：S8512—7609-1—SR7750 正常（华为OSPF路由优先级优于缺省静态路由）

回报文：SR7750—7609-1丢弃（华为OSPF路由优先级优于缺省静态路由）

为什么在相同测试环境下，我方和redback的设备间可以互通呢？原因就在于双方的

loopback地址的路由都是从正常启用了LDP的接口学到的，因此就不存在此问题。

1) 在7609-1上添加一条指向S8512 loopback口的静态路由后问题解决;

7750SR设备常见故障处理指导书

此外， 7750在处理带有MPLS LSP的普通IP报文时与友商设备不一致，友商设备是只要

有标签优先走标签，如果没有标签就走路由，而我方设备是优先走路由，只有涉及VPN转发

时才会使用标签交换，因此在S8512与SR7750互ping loopback地址的时候是可以通的。

因为SDP通道的建立是以IGP为基础建立的，当配置MPLS-L2/3VPN业务的时候，即使SDP

通道UP，MPLS也UP， 但很可能因为没在建立SDP的IGP通道的链路上启用MPLS，LDP，而导致

虽然MP-BGP建立正常学习到VPNV4路由，但业务转发时却因无法正常进行标签交换而造成报

文丢弃。

4.5 其它常见故障处理

4.5.1 TCP SYN流量异常处理

7750SR的在受到TCP SYN流量异常（攻击）时候，察看CPU。

例如：

Alcatel_7750SR# show system cpu

=========================================

CPU Utilization (Test time 1026391 uSec)

=========================================

Name CPU Time CPU Usage

(uSec)

System 361837 35.25%

Icc 598 0.05%

RTM/Policies 74103 7.21%

……..

PIM 0 0.00%

MCast Stack 0 0.00%

IP Stack 584895 56.98%

…….

Idle 0 0.00%

如上显示中，CPU的System进程高达35.25%

7750SR路由器对于那些必须经过CPM上的CPU进行处理的流量可以通过cpm-filter命令来

进行识别，该命令作用于流量到达CPM CPU之前的P-Chip芯片上，并可根据情况选择这些

流量通过、拒绝或对其进行cpm-queue限速。

正常情况下系统只开放如下端口：

TCP 179：用于BGP连接

TCP 22：用于SSH登录

TCP 646：用于LDP

UDP 161：用于SNMP

7750SR设备常见故障处理指导书

UDP 123：用于NTP

对于TCP来说，用于BGP,LDP,SSH的对端我们都是可以明确定义，因此可以做如下配置参考：

cpm-queue

queue 40 create

rate 100 cir 100

exit

exit

cpm-filter

ip-filter

entry 1 create

action accept

match protocol tcp

src-ip 192.168.0.199/32

exit

exit

entry 2 create

action queue 40

match protocol tcp

tcp-syn true

exit

exit

no shutdown

exit

exit

其中BGP、LDP、SSH的原地址在通过entry 1的方式指定。

安全建议：在设备开局的时候，考虑设备运行安全作必要的安全配置是必须的：比如TCP

SYN/ACK攻击、登陆控制、ICMP的控制、常见病毒端口控制，以及LOG的配置。

4.5.2 配置NTP认证key ID匹配问题

现象描述：

一台7750通过JUNIPER M320上联省网，NTP服务器在郑州，7750做为

client，原设计中NTP的authentication-key ID为371，所有厂家统一，测试过程中发

现7750的认证状态始终为down

Show system ntp detail

=============================================

NTP Status

=============================================

7750SR设备常见故障处理指导书

Enabled : Yes Stratum : 3

Admin Status : up Oper Status : down

Server enabled : No Server keyId : none

System Ref Id : 211.138.24.99 Auth Check : No

=============================================

同机房也有华为设备，同一条链路传递信息，不存在链路问题，7750查看配置发现7750

authentication-key ID配成了100跟设计中NTP服务器的ID值371不一样， 7750设备

NTP ID值范围为1－255，无法配置为371，如果要认证成功，7750

与NTP 服务器的ID值必须配置为相同的。最后统一修改NTP ID为小于255

的值－ 139，修改配置后，问题解决。

Show system ntp detail

=============================================

NTP Status

=============================================

Enabled : Yes Stratum : 3

Admin Status : up Oper Status : up

Server enabled : No Server keyId : none

System Ref Id : 211.138.24.99 Auth Check : Yes

=============================================

需要注意NTP的authentication-key值的范围，在提出设计方案的时候避免配置与设

计不匹配问题。

4.5.3 Netflow版本不同导致流量无法采集

7750在与第三方网管设备进行netflow流量采集时，由于版本不同，导致网管软件只

能采集到设备的硬件信息、端口信息及软件版本信息，而无法采集端口的数据流量。

以下为原配置：

cflowd

collector 221.7.34.34:9002

aggregation

as-matrix

source-prefix

exit

description "lanzhouliuliangcaiji"

7750 4.0以上版本默认的netflow版本为V8，而第三方厂家多采用V5版本。所以必须要

人为的用raw命令将7750netflow改为V5。

将配置更改为：

7750SR设备常见故障处理指导书

cflowd

collector 221.7.34.34:9002

aggregation

raw

exit

exit

通过以上配置更改后，可以成功采集流量。

4.5.4 CPU占用率持续过高处理

7750下挂用户访问网络速度很慢，通过查看cpu发现cpu利用率高达92.43％

持续过高的cpu利用率导致正常的业务数据转发效力极低

B:# show system cpu

=========================================

CPU Utilization (Test time 999643 uSec)

=========================================

Name CPU Time CPU Usage

(uSec)

-----------------------------------------

System 987346 92.43%

Icc 1868 0.18%

RTM/Policies 1390 0.13%

OSPF 1081 0.10%

MPLS/RSVP 2488 0.24%

LDP 362 0.03%

IS-IS 0 0.00%

RIP 0 0.00%

VRRP 121 0.01%

BGP 322 0.03%

Services 2063 0.20%

IOM 0 0.00%

CFLOWD 0 0.00%

IGMP 0 0.00%

PIM 0 0.00%

MCast Stack 0 0.00%

IP Stack 23031 2.30%

MBUF 0 0.00%

7750SR设备常见故障处理指导书

IGMP Snooping 160 0.01%

TLS MFIB 703 0.07%

WEB Redirect 151 0.01%

Idle 936543 4.26%

=========================================

system的cpu占用率很高，初步判断是ssh引起的ddos攻击，将ssh服务关闭

后，cpu使用率很快降到10％以内，用户上网业务恢复畅通。

关闭ssh server配置：

>config>system>security>ssh# info

----------------------------------------------

server-shutdown

ssh server缺省是打开的，如果不使用ssh登陆，建议关闭ssh server，以避免

收到ddos攻击而影响设备的转发。

4.5.5 设备升级后不能读取以前全部配置的问题

7750SR由TiMOS 4.0R7升级到TiMOS 4.0R11后，因原配置中IS-IS路由部分，在与

邻居路由器对接时启用了message-digest验证，升级后的7750SR在重启的过程中读取配置

文件，读到IS-IS验证字段落时，读取hash key失败，导致自IS-IS配置开始到后面的配

置都无法读取并运行。

软件版本：TiMOS 4.0R11

以下为告警信息

Attempting to exec primary configuration file:

'cf3:' ...

System Configuration

Log Configuration

System Security Configuration

Redundancy Configuration

Card Configuration

Port Configuration

System Sync-If-Timing Configuration

Management Router Configuration

7750SR设备常见故障处理指导书

Router (Network Side) Configuration

ISIS Configuration

MINOR: CLI Malformed hash key provided.

MAJOR: CLI #1009 An error occurred while processing a CLI command -

File cf3:, Line 273: Command "hello-authentication-key

"3fn1FdsuFwSmDH5jNQNZ07Rm7qXdBQaG44mnt/yyjnY" hash2" failed.

CRITICAL: CLI #1002 The system configuration is missing or incomplete because an error

occurred while processing the configuration file.。

采用以下步骤解决该问题

1、

2、

3、

将原来CF3：上的文件备份下来。

将配置文件中hello-authentication-key字段拿掉。

将更改过后的配置文件上传到7750SR的CF3：中，确认bof文件中的主用启动配

置文件为该新上传的文件。

4、

5、

6、

用admin redundancy synchronize config命令将主备CPM配置文件同步。

admin reboot now重新启动设备，配置文件能够正常读取并运行。

将hello-authentication-key字段加上，查看IS-IS邻居状态是否正常。

2024年9月16日发(作者：宁依云)

7750SR设备常见故障处理指导书

中国移动通信集团山西有限公司

7750SR设备常见故障处理指导书

上海贝尔阿尔卡特股份有限公司

工程服务部

二零零七年十月

7750SR设备常见故障处理指导书

1 检查硬件运行状态 .............................................................................................................................. 4

1.1

7750

SR硬件介绍 .......................................................................................................................... 4

1.2

设备启动 ....................................................................................................................................... 6

1.3

检查管理连接状态 ..................................................................................................................... 10

1.3.1 Console

口连接

.................................................................................................................... 10

1.4

检查机箱状态 ............................................................................................................................. 12

1.4.1

机箱状态

.............................................................................................................................. 12

1.5

检查电源 ..................................................................................................................................... 13

1.6

检查风扇 ..................................................................................................................................... 14

1.7

检查SF/CPM状态 ....................................................................................................................... 14

1.7.1 SF/CPM LED

状态

................................................................................................................ 14

1.7.2 SF/CPM

排错命令

............................................................................................................... 16

1.7.3

检查

SF/CPM

状态详情

.................................................................................................... 18

1.8

检查

IOM

状态 .......................................................................................................................... 22

1.9

检查MDA

状态 .......................................................................................................................... 24

2 系统级排错 ........................................................................................................................................ 25

2.1

硬件初始化常见问题 ................................................................................................................. 25

2.2

检查文件配置 ............................................................................................................................. 27

2.2

验证系统管理配置信息 ............................................................................................................. 32

2.3

显示系统信息 ............................................................................................................................. 32

2.4

验证同步和冗余状态 ................................................................................................................. 33

3 OA&M排错命令 ................................................................................................................................ 34

3.1

LSP

诊断命令 .............................................................................................................................. 35

3.2

SDP

D

IAGNOSTICS

........................................................................................................................ 35

3.3

业务诊断 ..................................................................................................................................... 36

3.4

VPLS

MAC

诊断 ......................................................................................................................... 36

3.5

OAM

命令汇总 ........................................................................................................................... 37

4 常见排错案例 .................................................................................................................................... 38

4.1

硬件常见故障处理 ..................................................................................................................... 38

4.1.1

内存损失造成不能正常启动

.............................................................................................. 38

4.1.2

设备启动不成功

.................................................................................................................. 39

4.1.3 MDA

卡无法注册

............................................................................................................... 40

4.1.4

主控板无法注册

.................................................................................................................. 40

4.1.5 console

口无法输出信息

.................................................................................................... 41

4.1.6

软件升版不当导致

CPM

反复重启

...................................................................................... 41

4.2

端口常见故障处理 ..................................................................................................................... 44

4.2.1 pos

端口常见故障处理

......................................................................................................... 44

4.2.2 ethernet

端口常见故障处理

.................................................................................................. 46

4.3

路由协议常见故障处理 ............................................................................................................. 48

7750SR设备常见故障处理指导书

4.3.1

链路无法负载均衡

.............................................................................................................. 48

4.3.2

等价路由情况下的

PING

问题

............................................................................................. 49

4.3.3

访问控制列表配置不当引起路由协议

DOWN

掉

.............................................................. 54

4.3.4

升级后部分路由无法正常转发

.......................................................................................... 55

4.3.5 Ospf

常见故障处理：

........................................................................................................... 58

4.3.5.1 MTU配置问题导致OSPF无法与对端设备建立邻接关系 ........................................................... 58

4.3.5.2 配置了将直连路由重分发进ospf后，直连路由没有发布出去 ............................................. 59

4.3.5.3 OSPF参考带宽与其他厂商互联设备设置不一致引起的路由问题 ......................................... 59

4.3.5.4 移动voip大业务量倒换测试问题处理 .................................................................................... 63

4.3.6 isis

常见故障处理

................................................................................................................. 66

4.3.6.1 MD5的HASH算法版本不匹配导致ISIS验证失败 ...................................................................... 66

4.3.6.2 与第三方设备（测试仪表类）建立ISIS邻接关系时遇到的问题 ......................................... 66

4.3.7 bgp

常见故障处理

................................................................................................................. 67

4.3.7.1 IBGP连接经常重启故障案例 .................................................................................................... 67

4.3.7.2 BGP宣告路由不全问题的处理 .................................................................................................. 71

4.3.7.3 7750路由宣告问题的处理 ........................................................................................................ 72

4.3.8 mpls

常见故障处理

............................................................................................................... 72

4.3.8.1 由于更改system地址后没有restart ospf导致MPLS-TE FRR故障 ....................................... 72

4.3.8.2 由于不同厂商mpls分发机制不同引起的业务故障................................................................. 76

4.4

业务常见故障处理 ..................................................................................................................... 78

4.4.1 ies

常见故障处理

.................................................................................................................. 78

4.4.1.1 ies割接后业务不通，对端用户无法ping通 .......................................................................... 78

4.4.1.2 subscriber-interface业务无法开通故障 ............................................................................ 79

4.4.2 vpls

常见故障处理

................................................................................................................ 81

4.4.2.1 arp广播引起的网络设备故障 .................................................................................................. 81

4.4.2.2 使用filter-log进行vpls业务丢包故障定位 ........................................................................ 83

4.4.3 vprn

常见故障处理

............................................................................................................... 84

4.4.3.1 vprn的路由限制功能无法生效 ................................................................................................ 84

4.4.3.2 vprn通过option a方式实现跨域mpls vpn时，对端asbr无法学到本as内的私网路由。 . 84

4.4.3.3 7750与友商设备测试VPNV4路由正常学习但业务无法转发 ................................................... 86

4.5

其它常见故障处理 ..................................................................................................................... 89

4.5.1 TCP SYN

流量异常处理

........................................................................................................ 89

4.5.2

配置

NTP

认证

key ID

匹配问题

............................................................................................ 90

4.5.3 Netflow

版本不同导致流量无法采集

................................................................................... 91

4.5.4 CPU

占用率持续过高处理

................................................................................................... 92

4.5.5

设备升级后不能读取以前全部配置的问题

...................................................................... 93

7750SR设备常见故障处理指导书

1 检查硬件运行状态

1.1 7750 SR硬件介绍

7750 SR由机箱、SF/CPM、IOM、MDA构成。7750 SR分为SR-12、SR-7、SR-1 3种型

号。

SR-12 共有12个插槽，其中2个插槽为主控板（SF/CPM）插槽，10个插槽为业务板插

槽，最多可插10个IOM、20个MDA。SR-7共有7个插槽，其中2个插槽为主控板（SF/CPM）

插槽，5个插槽为业务板插槽，最多可插5个IOM，10个MDA。SR-1主控板固化在机箱内，

不需要外配主控板和IOM，最多提供2个MDA插槽。

7750 SR-12的IOM 槽位从左起至右编号为1至10槽，板卡为垂直方向定位。每个IOM

上目前最多可以安装2个MDA，MDA的编号为上槽slot 1，下槽slot 2。

7750 SR-12最多可以安装2块SF/CPM，位于中间2槽，这2个槽位被分别命名为slots A

和B。至少1个SF/CPM 必须安装，冗余的SF/CPM工作在 stanby状态，一旦主用SF/CPM出

现故障，冗余SF/CPM将自动接管系统控制。

7750 SR-12在面板前部安装滤风器、SF/CPM、 IOM,、和MDA，电源和风扇在后部安

装。 见图1和图2。

7750SR设备常见故障处理指导书

图1: 7750 SR-12前面板图

1

2

3

4

5

6

7

8

9

10

11

Cable management system

Chassis slot numbers

MDA (installed)

Full slot panel blank

SF/CPM

MDA blank panel

Rack mounting brackets

Air vent

ESD plug

Compact flash slots

Compact flash slot 3 (cf3:)

表1： 机箱前面板功能表

7750SR设备常见故障处理指导书

图2: 7750 SR-12 后面板图

1

2

3

4

5

6

7

8

9

10

Grounding studs

Rack mounting brackets

Impeller (fan) trays

VDC studs for DC power cable

RTN studs for DC power cable

Safety cover

OFF/ON DC switch

Impeller (fan) tray faceplate

DC PEMs. The top slot is referred to as PEM Slot 1. The lower slot is

referred to as PEM Slot 2.

DB-25 connector (status)

表2: 机箱后面板功能表

1.2 设备启动

7750 SR 启动前必须把装有Timos软件CF卡安装在slot #3上，系统启动时首先寻找

文件，如果找不到

，

系统将不停重启，直到成功找到。在找到

文件后系统开始根据BOF文件中的配置初始化，BOF文件应当与放在同一个驱动器

中，BOF文件中含有操作系统和配置文件等参数。如果找不到BOF文件，系统将提示人工指

7750SR设备常见故障处理指导书

定一个操作系统和配置文件。配置文件中包括机箱、IOM、MDA、板卡的配置以及系统、

路由协议和业务的配置。

使用show boot-messages 命令查看最近一次启动的启动信息：

ALA-## show boot-messages

===============================================================================

cf3:/

===============================================================================

Boot log started on CPU#0

Build: X-4.0.R1 on Thu Apr 27 12:42:18 PST 2006 by builder

CPUCTL FPGA version: 1A

Boot rom version is v11

Booted from Control PROM 1

>>>Testing mainboard

>>>Validating SDRAM from 0x7ff00000 to 0x80000000

>>>Testing SDRAM from 0x02200000 to 0x7ff00000

>>>Testing Compact Slot Empty

>>>Testing Compact Slot Empty

>>>Testing Compact OK (SILICONSYSTEMS INC 256MB)

Peripheral FPGA version is 0x14

Board Serial Number is 'NS063640181'

Chassis Serial Number is 'NS063750999'

Searching for on local drives:

Searching cf3 for ...

*************************************************************************

Total Memory: 2016MB Chassis Type: sr12 Card Type: belarus_r1_200G

TiMOS-L-4.0.R6 boot/hops ALCATEL SR 7750 Copyright (c) 2000-2006 Alcatel.

All rights reserved. All use subject to applicable license agreements.

Built on Tue Sep 26 15:41:34 PST 2006 by builder in /rel4.0/b1/R6/panos/main

TiMOS BOOT LOADER

Time from clock is THU JAN 04 17:33:36 2007 UTC

Switching serial output to done

Looking for cf3:/ ... OK, reading

Contents of Boot Options File on cf3:

primary-image cf3:/7750-TiMOS-4.0.R6

primary-config cf3:/

autonegotiate

duplex full

speed 100

7750SR设备常见故障处理指导书

wait 3

persist off

console-speed 115200

Hit a key within 1 second to change

Primary image location: cf3:/7750-TiMOS-4.0.R6

Loading image cf3:

Version C-4.0.R6, Tue Sep 26 15:27:25 PST 2006 by builder in

/rel4.0/b1/R6/panos/main

text:(8953795-->27994056) + data:(996705-->8555536)

Executing TiMOS image at 0x2800000

Total Memory: 2016MB Chassis Type: sr12 Card Type: belarus_r1_200G

TiMOS-C-4.0.R6 cpm/hops ALCATEL SR 7750 Copyright (c) 2000-2006 Alcatel.

All rights reserved. All use subject to applicable license agreements.

Built on Tue Sep 26 15:27:25 PST 2006 by builder in /rel4.0/b1/R6/panos/main

___ ___ ___ ___

/ /__ / /

: ___ /::| | /:: /::

: /__ /:|:| | /:/: /:/

/:: ___/ /:/|:|__|__ /:/ : _:~

/:/:__ /__ /:/ |::::__ /:/__/ :__ / : __

/:/ __/ /:/ / __/~~/:/ / : /:/ / : : __/

/:/ / /:/ / /:/ / : /:/ / : :__

__/ __/ /:/ / ::/ / ::/ /

/:/ / ::/ / ::/ /

__/ __/ __/

Time from clock is THU JAN 04 17:33:54 2007 UTC

===============================================================================

cf3:/bootlog_

===============================================================================

Boot log started on CPU#0

Build: X-4.0.R1 on Thu Apr 27 12:42:18 PST 2006 by builder

CPUCTL FPGA version: 1A

Boot rom version is v11

Booted from Control PROM 1

>>>Testing mainboard

>>>Validating SDRAM from 0x7ff00000 to 0x80000000

7750SR设备常见故障处理指导书

>>>Testing SDRAM from 0x02200000 to 0x7ff00000

>>>Testing Compact Slot Empty

>>>Testing Compact Slot Empty

>>>Testing Compact OK (SILICONSYSTEMS INC 256MB)

Peripheral FPGA version is 0x14

Board Serial Number is 'NS063640181'

Chassis Serial Number is 'NS063750999'

Searching for on local drives:

Searching cf3 for ...

*************************************************************************

Total Memory: 2016MB Chassis Type: sr12 Card Type: belarus_r1_200G

TiMOS-L-4.0.R6 boot/hops ALCATEL SR 7750 Copyright (c) 2000-2006 Alcatel.

All rights reserved. All use subject to applicable license agreements.

Built on Tue Sep 26 15:41:34 PST 2006 by builder in /rel4.0/b1/R6/panos/main

TiMOS BOOT LOADER

Time from clock is THU JAN 04 04:46:39 2007 UTC

Switching serial output to done

Looking for cf3:/ ... OK, reading

Contents of Boot Options File on cf3:

primary-image cf3:/7750-TiMOS-4.0.R6

primary-config cf3:/

autonegotiate

duplex full

speed 100

wait 3

persist off

console-speed 115200

Hit a key within 1 second to change

Primary image location: cf3:/7750-TiMOS-4.0.R6

Loading image cf3:

Version C-4.0.R6, Tue Sep 26 15:27:25 PST 2006 by builder in

/rel4.0/b1/R6/panos/main

text:(8953795-->27994056) + data:(996705-->8555536)

Executing TiMOS image at 0x2800000

Total Memory: 2016MB Chassis Type: sr12 Card Type: belarus_r1_200G

TiMOS-C-4.0.R6 cpm/hops ALCATEL SR 7750 Copyright (c) 2000-2006 Alcatel.

7750SR设备常见故障处理指导书

All rights reserved. All use subject to applicable license agreements.

Built on Tue Sep 26 15:27:25 PST 2006 by builder in /rel4.0/b1/R6/panos/main

___ ___ ___ ___

/ /__ / /

: ___ /::| | /:: /::

: /__ /:|:| | /:/: /:/

/:: ___/ /:/|:|__|__ /:/ : _:~

/:/:__ /__ /:/ |::::__ /:/__/ :__ / : __

/:/ __/ /:/ / __/~~/:/ / : /:/ / : : __/

/:/ / /:/ / /:/ / : /:/ / : :__

__/ __/ /:/ / ::/ / ::/ /

/:/ / ::/ / ::/ /

__/ __/ __/

Time from clock is THU JAN 04 04:46:58 2007 UTC

1.3 检查管理连接状态

1.3.1 Console 口连接

7750 SR 提供本地Console口进行系统管理，在水平摆放时，Console口位于SF/CPM左部，

如图3所示：

图3：Console口

Console连接故障排查

如果不能建立Console连接，最可能的原因是仿真终端的设置问题，仿真终端的正确设

置参见表3：

表3：Console口配置参数

7750SR设备常见故障处理指导书

另外问题的原因可能与Console线的管脚分布有关，7750 SR Console线为9针一公头一

母头全直通线，管脚定义如图4所示：

图4：Console线管脚图

Telnet 连接

7750 SR 提供通过management port 的telnet连接，如图5所示：

图5: Mgmt Port

Telnet排障

如果无法通过管理口 telnet 7750，检查是否为管理口分配了IP地址、网关等参数，这

些参数在BOF里配置，可以使用 show bof 命令查看。

ALA-1# show bof

=====================================================================

autonegotiate

primary-image ftp://test:test@/./

primary-config ftp://test:test@/./

secondary-image cf3:/i650/

secondary-config cf3:/

address /20 active

address /20 standby

primary-dns

dns-domain

autonegotiate

7750SR设备常见故障处理指导书

duplex full

speed 100

wait 2

persist off

console-speed 115200

=========================================================================

ALA-1#

1.4 检查机箱状态

1.4.1 机箱状态

使用

show chassis

命令查看机箱运行状态，显示设备类型、板卡数、端口数、设备序

列号以及电源和风扇等信息：

B:Dut-D# show chassis

=====================================================

Chassis Information

=====================================================

Name : Dut-D

Type : 7750 SR-7

Location :

Coordinates :

CLLI code :

Number of slots : 7

Number of ports : 19

Critical LED state : Off

Major LED state : Off

Minor LED state : Off

Base MAC address : 00:03:fa:14:cf:a7

Admin chassis mode : a

Oper chassis mode : a

Hardware Data

Part number : 3HE00186AAAA01

CLEI code :

Serial number : NS042450133

Manufacture date : 06172004

Manufacturing string :

Manufacturing deviations :

Time of last boot : 2006/06/16 09:37:51

Current alarm state : alarm cleared

Environment Information

7750SR设备常见故障处理指导书

Number of fan trays : 2

Number of fans : 4

Fan tray number : 1

Status : up

Speed : half speed

Fan tray number : 2

Status : up

Speed : half speed

Power Supply Information

Number of power supplies : 2

Power supply number : 1

Defaulted power supply type : none

Status : not equipped

Power supply number : 2

Defaulted power supply type : dc

Status : up

=====================================================

B:Dut-D#

1.5 检查电源

使用

show chassis

和

show chassis power-supply

检查当前的电源状态、错误指示等。

7750 SR 至少有1个电源工作才能正常工作。

B:Dut-D# show chassis power-supply

=========================================================================

Chassis Information

=========================================================================

Power Supply Information

Number of power supplies : 2

Power supply number : 1

Defaulted power supply type : dc

Status : up

Power supply number : 2

Defaulted power supply type : dc

Status : up

=========================================================================

7750SR设备常见故障处理指导书

1.6 检查风扇

使用

show chassis

和

show chassis environment

检查当前的风扇状态、错误指示等。

7750 SR-12必需有2个风扇正常才能正常工作。

ALA-4# show chassis environment

========================================================================

=

Chassis Information

========================================================================

=

Environment Information

Number of fan trays : 3

Number of fans : 6

Fan tray number : 1

Status : up

Speed : half speed

Fan tray number : 2

Status : up

Speed : half speed

Fan tray number : 3

Status : up

Speed : half speed

========================================================================

=

ALA-4#

1.7 检查SF/CPM状态

最低配置要求

至少安装1个SF/CPM

至少1个CF卡安装在 SF/CPM的Slot #3

1.7.1 SF/CPM LED状态

检查SF/CPM的显示灯LED状态，定位故障，如图6所示：

7750SR设备常见故障处理指导书

图6: SF/CPM 前面板

Key Indicator

3 Status

Category

Potential Problem Indication

Amber: Operationally

administratively up.

Unlit: Not operational,

administratively down.

down

shutdown,

but

or

3 M/S

(Master/Slave)

M/S

(Master/Slave)

Ctl Green (blinking): Indicates that the SF/CPM is

operating as the secondary SF/CPM in a

redundant configuration.

Green (blinking): Indicates that the SF/CPM is

operating as the secondary clocking reference in

a redundant system.

Unlit: Clock not initialized.

Green (blinking): Clock in (internal) holdover

state

Amber (blinking): Clock in free running state

Unlit: Clock not initialized.

Amber: The reference is enabled (no shutdown)

but not qualified.

Unlit: Not in use, not configured.

BITS Status:

Amber: The reference is enabled (no shutdown)

but not qualified.

Unlit: Not in use, not configured.

Amber: Indicates an error condition with an

installed power entry module in the associated

slot.

Unlit: Indicates that a power entry module is not

installed or not recognized.

Amber: Indicates a fan tray failure.

Unlit: Indicates that a fan tray is not installed.

Amber (blinking): Error condition exists.

Amber (solid): Indicates that the slot is in an

3 Ref

3 Timing

3 Reference 1,2

3 Reference 3

3 Power Supply 1,2,3,4

3

3

Fan Status

Compact Flash

1,2,3

1,2,3

7750SR设备常见故障处理指导书

operationally down mode. (This is the only

mode to safely remove the flash card.)

Unlit: A flash card is not installed in the slot.

3

3

Alarms

Alarms

OT

Crit

Red: An over-temperature condition exists.

Red: A critical condition exists, such as a severe

over-temperature condition, a fan tray failure,

an over-current condition in a power module, or

an out-of-tolerance voltage.

Red: A serious condition exists, such as an

over-temperature condition, a fan tray failure,

an over-current condition in a power module, or

an out-of-tolerance voltage.

Amber: A serious condition exists, such as a

component failure.

Unlit: Operationally down.

3 Alarms Maj

3

10

10

Alarms

Mgmt

Mgmt

Min

Link

Data Amber (blinking): Error condition.

表3： SF/CPM现场显示描述

1.7.2 SF/CPM 排错命令

下表为SF/CPM排错常用命令：

Task Recommended CLI command(s)

show card

admin redundancy force-switchover

[now]

1 显示 SF/CPM 状态

2 切换至备份SF/CPM (假设备份

SF/CPM存在)

3 检查切换是否成功 show card

表4： SF/CPM排错常用命令

命令示例:

1.

show card

SR12# show card

===============================================================================

Card Summary

===============================================================================

slot card card card admin operational

allowed provisioned equipped state state

-------------------------------------------------------------------------------

1 all supported iom-20g iom-20g up up

2 all supported iom-20g up down

3 all supported iom-20g up down

6 all supported iom-20g up down

9 all supported iom-20g up down

7750SR设备常见故障处理指导书

A all supported sfm-400g sfm-400g up up/active

B all supported sfm-400g sfm-400g up up/standby

===============================================================================

2. admin redundancy force-switchover [now]

(切换前)

SR12# show card

===============================================================================

Card Summary

===============================================================================

slot card card card admin operational

allowed provisioned equipped state state

-------------------------------------------------------------------------------

1 all supported iom-20g iom-20g up up

2 all supported iom-20g up down

3 all supported iom-20g up down

6 all supported iom-20g up down

9 all supported iom-20g up down

A all supported sfm-400g sfm-400g up up/active

B all supported sfm-400g sfm-400g up up/standby

===============================================================================

SR12# admin redundancy force-switchover now

(切换后)

SR12# show card

===============================================================================

Card Summary

===============================================================================

slot card card card admin operational

allowed provisioned equipped state state

-------------------------------------------------------------------------------

1 all supported iom-20g iom-20g up up

2 all supported iom-20g up down

3 all supported iom-20g up down

6 all supported iom-20g up down

9 all supported iom-20g up down

A all supported sfm-400g sfm-400g up up/standby

B all supported sfm-400g sfm-400g up up/active

===============================================================================

7750SR设备常见故障处理指导书

1.7.3 检查 SF/CPM 状态详情

使用下列命令进一步检查SF/CPM状态信息：

Task Recommended CLI command(s)

1 检查 SF/CPM 详细信息 show card

detail

(注：SF/CPM 槽位编码为 “A”和

“B”.)

2 检查与SF/CPM 相关的LOG

3 检查系统cpu使用状态

4 检查系统内存使用状态

show log log-id

subject

（注：缺省的log-id为99；

在此等于

“Card A”或者 “Card B” ，区分大小写)

show system cpu

show system memory-pools

5 检查系统在线时间 show system info

表5： SF/CPM深入排错命令

命令示例：

1.

show card detail

SR12# show card A detail

===============================================================================

Card A

===============================================================================

slot card card card admin operational

allowed provisioned equipped state state

-------------------------------------------------------------------------------

A sfm-400g sfm-400g sfm-400g up up/active

sfm-200g

BOF last modified : N/A

Config file version :

Config file last modified : N/A

Config file last saved : N/A

CPM card status : active

Flash - cf1:

Administrative State : up

Operational state : not equipped

7750SR设备常见故障处理指导书

Flash - cf2:

Administrative State : up

Operational state : not equipped

Flash - cf3:

Administrative State : up

Operational state : up

Serial number : 103616B2304W340

Firmware revision : HDX 2.1

Model number : SanDisk SDCFB-128

Size : 125,038 KB

Free space : 96,836 KB

Hardware Data

Part number : 3HE00018AAAA01

CLEI code :

Serial number : NS041410366

Manufacture date : 04112004

Manufacturing string :

Manufacturing deviations :

Administrative state : up

Operational state : up

Status : software running

Temperature : 44C

Temperature threshold : 68C

Software boot version : X-2.0.R1 on Tue May 4 15:07:26 PST 2004 by*

Software version : TiMOS-C-2.0.R4 cpm/hops ALCATEL SR 7750 Co*

Time of last boot : 2004/09/07 08:16:04

Current alarm state : alarm cleared

Base MAC address : 00:03:fa:0c:e4:4a

Memory capacity : 2,016 MB

===============================================================================

2.

show log log-id subject

SR12>show>log# log-id 99 subject "Card A"

===============================================================================

Event Log 99

===============================================================================

Description : Default System Log

Memory Log contents [size=500 next event=20 (not wrapped)]

7750SR设备常见故障处理指导书

6 2004/07/19 06:37:41.48 MINOR: CHASSIS #2002 - Card A

"Class CPM Module : inserted"

3.

show system cpu

SR12# show system cpu

=========================================

CPU Utilization (Test time 1001407 uSec)

=========================================

Name CPU Time CPU Usage

(uSec)

-----------------------------------------

System 1427 0.14%

Icc 50 ~0.00%

RTM/Policies 0 0.00%

OSPF 0 0.00%

MPLS/RSVP 0 0.00%

LDP 0 0.00%

IS-IS 0 0.00%

RIP 0 0.00%

VRRP 0 0.00%

BGP 0 0.00%

Services 4 ~0.00%

IOM 5607 0.55%

SIM 79 ~0.00%

CFLOWD 0 0.00%

Idle 994240 99.28%

=========================================

4.

show system memory-pools

SR12# show system memory-pools

===============================================================================

Memory Pools

===============================================================================

Name Max Allowed Current Size Max So Far In Use

-------------------------------------------------------------------------------

System No limit 118,489,688 118,489,688 114,333,488

Icc 8,388,608 1,048,576 1,048,576 33,616

RTM/Policies No limit 4,194,336 4,194,336 2,507,136

OSPF No limit 0 0 0

MPLS/RSVP No limit 1,048,576 1,048,576 76,000

LDP No limit 0 0 0

7750SR设备常见故障处理指导书

IS-IS No limit 0 0 0

RIP No limit 0 0 0

VRRP No limit 0 0 0

BGP No limit 0 0 0

Services No limit 2,097,152 2,097,152 1,700,136

IOM No limit 199,156,416 199,156,416 195,826,168

SIM No limit 1,048,576 1,048,576 392

CFLOWD No limit 0 1,048,576 0

-------------------------------------------------------------------------------

Current Total Size : 327,083,320 bytes

Total In Use : 314,476,936 bytes

Available Memory : 640,711,688 bytes

===============================================================================

5.

show system info

SR12# show system information

======================================================================

System Information

======================================================================

System Name : sim9

System Contact :

System Location :

System Coordinates :

System Up Time : 3 days, 20:20:40.40 (hr:min:sec)

SNMP Port : 161

SNMP Engine ID : 0000197f000000008eb1ff00

SNMP Max Message Size : 1500

SNMP Admin State : Disabled

SNMP Oper State : Disabled

SNMP Index Boot Status : Not Persistent

BOF Source : cf1:

Image Source : primary

Config Source : N/A

Last Booted Config File: N/A

Last Boot Cfg Version : N/A

Last Boot Config Header: N/A

Last Boot Index Version: N/A

Last Boot Index Header : N/A

Last Saved Config : N/A

Time Last Saved : N/A

7750SR设备常见故障处理指导书

Changes Since Last Save: No

Max Cfg/BOF Backup Rev : 5

Cfg-OK Script : N/A

Cfg-OK Script Status : not used

Cfg-Fail Script : N/A

Cfg-Fail Script Status : not used

Management IP Addr : 138.120.199.177/24

DNS Server : 138.120.118.196

DNS Domain :

BOF Static Routes :

To Next Hop

138.120.0.0/16 138.120.199.1

128.251.10.0/24 138.120.199.1

======================================================================

1.8 检查 IOM 状态

当IOM安装、启动以后，应当检查安装的IOM与配置的IOM类型是否匹配，如果不匹配，

IOM将处于offline状态。使用 show boot-messages命令查看IOM的启动过程是否正常。 To 使

用 show card 命令检查当前IOM运行状态。如下所示：

使用

clear card

命令重置IOM（重启动，必须指定槽位号）。

SR12# clear card 1

SR12# show log log-id 99 subject "Card 1"

===============================================================================

Event Log 99

===============================================================================

Description : Default System Log

Memory Log contents [size=500 next event=292 (not wrapped)]

7750SR设备常见故障处理指导书

291 2004/07/28 14:28:35.57 MINOR: CHASSIS #2002 - Card 1

"Class IO Module : inserted"

288 2004/07/28 14:28:16.77 MINOR: CHASSIS #2003 - Card 1

"Class IO Module : removed"

使用

show card detail

命令显示重置的时间

SR12# show card 1 detail

===============================================================================

Card 1

===============================================================================

slot card card card admin operational

allowed provisioned equipped state state

-------------------------------------------------------------------------------

1 iom-10g iom-20g iom-20g up up

iom-20g

IOM Card Specific Data

Clock source : none

Available MDA slots : 2

Installed MDAs : 2

Hardware Data

Part number : 3HE00020AAAA01

CLEI code :

Serial number : NS041110257

Manufacture date : 03192004

Manufacturing string :

Manufacturing deviations :

Administrative state : up

Operational state : up

Status : software running

Temperature : 56C

Temperature threshold : 68C

Software boot version : X-2.0.R1 on Tue May 4 15:07:26 PST 2004 by*

Software version : TiMOS-I-2.0.R5 iom/hops ALCATEL SR 7750 Co*

Time of last boot : 2004/07/28 14:29:11

Current alarm state : alarm cleared

Base MAC address : 00:03:fa:0c:e6:88

===============================================================================

7750SR设备常见故障处理指导书

1.9 检查MDA 状态

在安装MDA之前必须安装、配置IOM，否则MDA将一直处于administratively 和

operationally down的状态，无法工作。

当MDA安装和激活候，检查安装的MDA是否与配置的MDA类型匹配，如不匹配MDA将一直

处于offline 状态。使用

show mda

检查MDA当前状态。

使用

show mda detail

检查MDA的详细状态和告警信息，所有信息如下表：

7750SR设备常见故障处理指导书

2 系统级排错

本章讲述7750SR系统配置排错方法，包括硬件初始化、BOF配置、CPM冗余、系统时间

配置、CARD/IOM/MDA/PORT的配置等，以及排错所使用的常用命令。

2.1 硬件初始化常见问题

7750 SR 硬件初始化发生在设备加电启动或重启动时。缺省情况下，系统查找位于CF3

上的文件，文件中的代码用来执行BOF文件（）中的系统初

始化命令。这个行为是缺省的并且不能修改。BOF文件同样必须位于CF3上。

排错注意事项：

如果 未被找到, 系统初始化将失败

Boot Option File （BOF）配置

7750 SR 使用 Boot Option File (BOF) 启动系统，BOF文件包含执行以下任务的信息：

1)

2)

3)

4)

5)

6)

7)

8)

9)

在BOF文件中不需要配置以上所有信息，以下是1个BOF文件信息：

设置CPM 以太网管理端口 (speed, duplex, auto)

分配 IP 地址给CPM 以太网管理端口

为 CPM以太网管理端口

设置Console 口参数

配置 DNS 域名

配置 Primary, Secondary, Tertiary 系统软件位置

配置 Primary, Secondary, Tertiary 配置文件位置

配置主备SF/CPM同步参数

配置系统持续性参数

7750SR设备常见故障处理指导书

BOF相关命令

Task CLI commands

Display current admin# display-config [detail|index]

system configuration info

show version

Display the

configuration

Modify a

configuration

BOF show bof [cflash-id|booted}

BOF

bof# [no] address ip-addr/mask [active | standby]

[no] autonegotiate

no console-speed

no dns-domain

[no] primary-config file-url

no primary-dns

[no] primary-image file-url

[no] secondary-config file-url

no secondary-dns

[no] secondary-image directory-url

[no] static-route ip-prefix/mask next-hop ip-addr

[no] tertiary-config file-url

no tertiary-dns

[no] tertiary-image file-url

BOF

bof# save cflash-id

admin# save [file-url] [detail] [index]

Save a

configuration

Reboot

BOF排错注意事项

7750SR设备常见故障处理指导书

admin# reboot

BOF中必须至少指定1个系统软件，如果系统软件不能加载，系统启动将失败，需要人工

干预。

如果启动时找不到配置文件，系统将使用缺省配置启动，SNMP保持在SHUTDOWN的状态，

而SNMP traps会继续发送，系统使用traps、log、console 消息通知用户相关问题的存在。

要激活全部SNMP功能，需要no shutdown snmp。

如果BOF没有定义配置文件，那么在系统重启时任何对配置的修改均将丢失。

当改变BOF配置时注意保存配置。

2.2 检查文件配置

7750 SR 的文件系统是基于DOS的文件系统，在7750 SR里，每个SF/CPM最多可以安

装3个CF卡(cf1:, cf2: or cf3:)。

由于上面所述的设备名称暗指本SF/CPM上的CF卡，所以其名称是相对的设备名称，

而在DOS 文件系统里, “:” 代表1个设备。绝对的设备名称由CF卡加上“－”以及SF/CPM槽

位号码构成，例如“cf1-A:” 指A槽上SF/CPM上的CF1。

以下命令用于检查文件系统：

Task CLI commands

1 To find the config file and the flash card show bof

(cf#) it is saved on

2 To find a file on the cf3 on the active file dir

SF/CPM card file dir cf3:

3 To find a file on the cf3 of slot B file dir cf3-B:

(whether the SF/CPM in Slot B is active

or standby)

4 To change directory (from one flash file cd cf3-A:

card (cf3-B) to another (cf3-A) )

5 To look at config file on cf3 file type file-url

(ex.

file type

cf3:/log/log-190252)

7750SR设备常见故障处理指导书

Examples of output of the commands:

1. show bof

SR12# show bof

BOF (Memory)

primary-image cf3:imagesR4

primary-config cf3:SPIRIT_

address 138.120.199.117/24 active

address 138.120.199.118/24 standby

primary-dns 138.120.118.196

secondary-dns 138.120.118.198

dns-domain

static-route 128.251.10.0/24 next-hop 138.120.199.1

static-route 138.120.0.0/16 next-hop 138.120.199.1

autonegotiate

duplex full

speed 100

wait 3

persist on

console-speed 115200

2. file dir

SR12# file dir

Volume in drive cf3 on slot A has no label.

Directory of cf3:

09/08/2004 05:53a 1729589

09/08/2004 08:51a 4110

09/06/2004 02:29a