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

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否则丢弃。接收后检查该数据帧，将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功能即可。 7750SR设备常见故障处理指导书 4.4.1.24.4.1.2 subscriber-interfacesubscriber-interface业务无法开通故障业务无法开通故障 subscriber-interface是ies的一种灵活运用，该应用可以实现一个interface下 面终结多个sap，普通的ies的interface接口，只能终结一个sap的业务流量，但是 subscriber-interface通过group-interface可以终结多个sap，但需要注意，在同一个 group-interface中的sap的接入端口需要一致，如果不一致，需要再新建group- interface来终结。 另外，一个subscriber-interface可以配置最多16个不同网段的ip，实现用户 极其灵活的接入。 configserviceies# 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 exit exit 在进行了以上配置后，ping该subscriber-interface接入的用户时，发现无法 ping通，subscriber-interface业务无法开通。请注意，7750在实现subscriber- interface时需要指定下面接入用户的ip地址或者mac地址，目的是为了防止地址 哄骗，如果不配置，则用户业务不通 configserviceiessub-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 7750SR设备常见故障处理指导书 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 4.4.24.4.2 vplsvpls 常见故障处理常见故障处理 4.4.2.14.4.2.1 arparp广播引起的网络设备故障广播引起的网络设备故障 erx1440 IP/MP LS core sr7750 Cisco4506 Cisco6509 Dslam2 网管vlan26 Dslam1 网管vlan26 Pvlan1901Pvlan1903 拓扑如上所示：某运营商出现大量宽带用户拨号故障，提示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。 7750SR设备常见故障处理指导书 如上图所示，当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或者单层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广播包，那结果就是有12712616002个广播 包转发给了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 customer 1000 create description CS-Manager split-horizon-group create exit stp no shutdown exit 7750SR设备常见故障处理指导书 sap 5/1/1:2266.21 split-horizon-group create exit sap 5/1/1:2274.21 split-horizon-group create exit sap 5/1/1:2560.21 split-horizon-group create exit sap 5/1/1:21.* create exit no shutdown exit 以上配置中sap 5/1/1:21.*为接网关的sap，不能加入水平分割组，其余的全部加入水 平分割组，达到arp广播的抑制。采用水平分割后，6509的mac database条目由原来的58 万减少至6千左右，同时erx接受到的广播报文急剧下降，在进行了水平分割配置后，原先 无法拨号的用户都恢复了正常。经过一周观察，没有再出现用户故障。 4.4.2.24.4.2.2 使用使用filter-logfilter-log进行进行vplsvpls业务丢包故障定位业务丢包故障定位 故障描述： dslam网管ip光电收发器光电收发器二层交换机 7750网关设备。发现从网关设备上pingdslam网管ip时有丢包，需要定位故障点。 为了定位故障点，在7750上面配置filter-log，只要7750将从网关设备收到到ping request数据包转发给了二层交换机，说明7750没有问题。以下为filter-log的一个配置示 例： A:A7750configfilter# 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 7750SR设备常见故障处理指导书 然后将该ip-filter应用到vpls的sap下面 使用show filter log 101可以查看数据包的摘要信息。 通过filter-log发现7750成功将icpm request报文转发出去，最后在二层交换机和 dslam端口做镜像抓包，发现二层交换机也将icmp request数据发送出去，但是dslam没有 接收到，故障定位为之间的光电收发器问题，更换光电收发器后问题解决。 4.4.34.4.3 vprnvprn 常见故障处理常见故障处理 4.4.3.14.4.3.1 vprnvprn的路由限制功能无法生效的路由限制功能无法生效 在vprn中使用maximum-routes命令来限制路由条目时，发现配置后无法生效。 需要注意，在使用maximum-routes命令限制vprn路由条目时，必须先将vprn shutdown，在使用改命令修改vprn最大路由条目时，vprn必须处于down的状态，否则修改 后不生效。 还需要注意，使用maximum-routes命令限制路由数目，只限制bgp-vpn等路由条目， 并不包括直连路由条目数。 4.4.3.24.4.3.2 vprnvprn通过通过optionoption a a方式实现跨域方式实现跨域mplsmpls vpnvpn时，对端时，对端asbrasbr无法学到本无法学到本asas内的私网路内的私网路 由。由。 现象描述：7750作为城域网asbr，通过option a方式实现跨域互通，但对端asbr响应 vrf无法学到本as内的私网路由。 查看配置如下： configservicevprn# description HuanBaoJianKong autonomous-system 64758 route-distinguisher 4809: auto-bind ldp vrf-target target:4809: interface to-lag-1:3785.* create description HBJK-NAS address 172.44.36.113/29 sap lag-1:3785.* create exit exit 7750SR设备常见故障处理指导书 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 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设备。通过增加以下配置后解 决： configrouterpolicy-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 7750SR设备常见故障处理指导书 entry 20 from protocol direct prefix-list hb-outbound-cn2 exit to protocol bgp exit action accept exit exit entry 30 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.34.4.3.3 77507750与友商设备测试与友商设备测试VPNV4VPNV4路由正常学习但业务无法转发路由正常学习但业务无法转发 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)根据上述现象，我们怀疑回应报文没有发出或者是丢弃在中间的设备了。 7750SR设备常见故障处理指导书 4)解决方法：在SR7750上镜像抓包，发现无论在MPLS L2/L3 VPN环境下都是正常 的，证明我方PE（SR7750）设备已经将回应报文发出； 5)为了不影响现网业务，华为测试前将现网流量全部调至S85127609-2链路上 （通过修改7609-1下联S8512接口的ospf cost值以及在S8512上使用静态缺省 路由实现），仅在S85127609-1SR7750链路上启用LDP，链路网络拓扑如图 所示： 由于目前S8512上建立LDP session使用的是loopback接口，如图所示： 对于P 7609-1设备来说，S8512的loopback路由是从S85127609-27609-1链路学来 的，因此在P 7609-1上的LSP：221.194.32.28/32（S8512 loopback地址）对应的出接口为 接口A，但是A接口并没有启用LDP，带有一层MPLS标签的报文就会被丢弃掉，也就是说： （S8512SR7750方向） 发报文：S85127609-1SR7750 正常（华为OSPF路由优先级优于缺省静态路由） 回报文：SR77507609-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.54.5 其它常见故障处理其它常见故障处理 4.5.14.5.1 TCPTCP SYNSYN 流量异常处理流量异常处理 7750SR 的在受到 TCP SYN 流量异常（攻击）时候，察看 CPU。 例如： Alcatel_7750SR# show system cpu = CPU Utilization (Test time uSec) = Name CPU Time CPU Usage (uSec) System 35.25% Icc 598 0.05% RTM/Policies 74103 7.21% . PIM 0 0.00% MCast Stack 0 0.00% IP Stack 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.24.5.2 配置配置 NTPNTP 认证认证 keykey IDID 匹配问题匹配问题 现象描述：一台 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 值范围为 1255，无法配置为 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.34.5.3 NetflowNetflow 版本不同导致流量无法采集版本不同导致流量无法采集 7750在与第三方网管设备进行netflow流量采集时，由于版本不同，导致网管软件只 能采集到设备的硬件信息、端口信息及软件版本信息，而无法采集端口的数据流量。 以下为原配置： cflowd collector 221.7.34.34:9002 aggregation as-matrix source-prefix exit description lanzhouliuliangcaiji 7750SR设备常见故障处理指导书 7750 4.0 以上版本默认的 netflow 版本为 V8，而第三方厂家多采用 V5 版本。所以必须要人 为的用 raw 命令将 7750netflow 改为 V5。 将配置更改为： cflowd collector 221.7.34.34:9002 aggregation raw exit exit 通过以上配置更改后，可以成功采集流量。 4.5.44.5.4 CPUCPU 占用率持续过高处理占用率持续过高处理 7750下挂用户访问网络速度很慢，通过查看cpu发现cpu利用率高达 92.43 持续过高的cpu利用率导致正常的业务数据转发效力极低 B:ZJ-HY-60-SR-SR12-1.MAN# show system cpu = CPU Utilization (Test time uSec) = Name CPU Time CPU Usage (uSec) - System 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% 7750SR设备常见故障处理指导书 MCast Stack 0 0.00% IP Stack 23031 2.30% MBUF 0 0.00% IGMP Snooping 160 0.01% TLS MFIB 703 0.07% WEB Redirect 151 0.01% Idle 4.26% = system的cpu占用率很高，初步判断是ssh引起的ddos攻击，将ssh服务关闭 后，cpu使用率很快降到10以内，用户上网业务恢复畅通。 关闭ssh server配置： configsystemsecurityssh# info - server-shutdown ssh server缺省是打开的，如果不使用ssh登陆，建议关闭ssh server，以避 免收到d