《[信息与通信]zet中兴网络设备维护经验》由会员分享，可在线阅读，更多相关《[信息与通信]zet中兴网络设备维护经验（33页珍藏版）》请在金锄头文库上搜索。
1、维护经验编者的话“技术推广、经验交流、开拓视野、共同提高”是本刊的宗旨。秉承“精诚服务、凝聚顾客身上”的客户服务理念，使中兴通讯产品能更好地为客户创造价值，为客户提供更好的服务，向客户提供最好、最实用的维护经验和方法，切实提高相关专业技术人员的业务知识水平和技能，我们编辑了本辑维护经验，内容针对中兴通讯的数据产品。随着中兴通讯的数据产品在国内外的广泛应用，该产品的日常维护工作变得十分重要。本专辑共收录了中兴通讯的数据产品维护案例6篇、专题文档2篇，稿件大部分来源于中兴通讯产品维护人员，具有较高的参考价值，希望对您的维护工作有所帮助。若要查阅更多有关中兴通讯产品的维护经验文章与相关技术资料，请登
2、录中兴通讯技术支持网站（http:/）。由于水平有限，难免有不足和疏漏之处，恳请各位专家和读者批评、指正，同时也感谢大家对本专辑的关注和支持。您可以随时联系我们，讲述您的心得与体会。欢迎投稿。第1章 GAR上启用NAT的注意事项三营合肥处 杨勇一、网络环境介绍如图1所示，在GAR上启用NAT，接口Fei_1/1连接Internet，接口Fei_0/1连接内部网络。连接Internet的网段为218.11.11.64/28，其中互联地址占用了218.11.11.65和218.11.11.78（GAR的Fei1/1），剩余IP地址用于NAT转换。内部网络的网段为192.168.2.0/24。图1
3、NAT转换网络拓扑图二、故障描述1 上网高峰期GAR的CPU占用率达到70%以上；2 内部PC上网经常掉线。三、故障分析查看GAR的当前配置，如下所示：interface fei_1/1 ip address 218.11.11.78 255.255.255.240 negotiation auto ip nat outsideinterface fei_0/1 ip address 192.168.2.2 255.255.255.0 negotiation auto ip nat insideip nat startip nat pool telecom 218.11.11.66 218.1
4、1.11.77 prefix-length 24ip nat inside source list 10 pool telecom overloadip nat translation timeout class a 20ip nat translation timeout class b 60ip nat translation timeout class c 300ip nat translation timeout class d 1200ip nat translation timeout class e 600ip nat translation timeout protocol i
5、cmp aip nat translation timeout protocol ip cip nat translation timeout protocol tcp eip nat translation maximal default 200ip route 0.0.0.0 0.0.0.0 218.11.11.65ip access-list standard 10 permit 192.168.2.0 0.0.0.255首先需要判断导致CPU占用率偏高的原因，有以下几种可能：1 可能是内部网络中存在的病毒导致CPU占用率偏高，在GAR的接口Fei_0/1上添加防病毒ACL，过滤掉可疑端
6、口，但CPU占用率并没有降低，排除这种可能性。2 使用命令show ip traffic后，发现GAR上一直在发送大量的icmp unreachable报文，在内外网口上使用命令no ip unreachable限制ICMP不可达报文的产生，但CPU占用率并没有降低，排除这种可能性。3 使用命令ip nat stop或者clear ip nat translations后，CPU立刻下降到百分之几，说明正是NAT导致了GAR的CPU偏高。原因找到后，下面来分析一下该问题。使用命令show ip nat statistics查看NAT的统计信息，发现NAT的各种计数器在飞快的增长。NAT转换条目
7、不停的创建和到期肯定会消耗大量的CPU资源，检查GAR上NAT的相关配置，发现TCP的转换超时时间非常的短，只有10分钟，而用户上网用到的基本上都是TCP协议，如web，ftp等。恢复TCP的超时时间为60分钟，发现CPU占用率略有好转，持续在30%-40%左右，偶尔也会达到70%以上，这不是CPU占用率高的根本原因。使用命令show ip nat count by-used 200（200是单个IP的NAT最大连接数默认值），发现高峰期时几十个IP的NAT连接数都达到200，这是这些IP不能够打开网页的原因，而此时FTP等已经进行NAT转换的应用可能依然正常。使用clear ip nat t
8、ranslations命令后，所有IP打开网页都正常了，此时的GAR的CPU也恢复到正常值。这说明两个问题：一是所谓的PC上网掉线，其实就是因为当前该PC的NAT并发连接数达到最大值。打开网页需要建立新的连接，而此时连接数已经达到最大值，无法建立新的连接，只有等待部分连接过期后网页才能够打开，也就是过一段时间后用户又感觉上网正常了。二是当多数PC的NAT连接数达到最大值时，CPU占用率会偏高，因为拒绝新连接的建立也需要消耗CPU资源。三、解决方案目前的解决方案是使用命令ip nat translation maximal default ，提高单个IP的NAT最大连接数默认值。但由于GAR受内
9、存的限制，NAT并发连接总数只能达到65k。使用命令show ip nat statistics查看本地PC数，如100，用65k相除，单个IP的NAT最大连接数默认值可以定为600。也可以将单个IP的NAT最大连接数默认值设为60k，只用1个或2个公网地址来提供NAT功能（PAT），其余的公网IP为重要的内部设备提供静态NAT，保证这些内部设备的正常上网。但是最根本的解决方案是用NAT功能较强的GER或者ZSR来替换GAR，目前最大的NAT并发连接总数可以达到1024k。前面都是设置单个IP的NAT最大连接数默认值，在GAR的新版本中可以设置某些IP的NAT最大连接数，相关命令为ip nat
10、 translation maximal 其中在中定义相关的IP地址。第2章 PPPOE拨号用户打不开网页故障处理案例南京用服部 张金涛一、网络环境介绍如图2所示，PC挂在迅捷路由器FR40下面，FR40代替PC进行PPPOE拨号。中兴2826E进行二层VLAN透传，在上行口给数据包打上一层标签，该数据包继续上行到中兴3928，在3928上配置QinQ，给该数据包打上第二层标签，经过光电转换器和华为8512透传到UAS10800，通过远端Radius认证后上网。图2 网络拓扑图二、故障描述PC打不开网页，但是能ping通Internet上的公网IP，并且QQ运行正常。三、故障分析在PC的命令行
11、下，使用命令ping -l 1460，允许分片的情况下最大只能ping通1460字节，这是不正常的，下面分析一下该ICMP数据包沿途的封装情况。图3 封装结构图如图3所示，PC通过增加ICMP包头和IP包头，产生一个ICMP数据包，长度为1460+8+20=1488字节。由于以太网的MTU为1500，因此不用分片就可以正常转发。数据包到达路由器FR40后，经过PPPoE封装，长度为1488+2+6=1496字节，以太网的MTU为1500，因此也不用分片就可以正常转发。FR40发送数据包前，将数据包封装为以太网帧，帧长为1496+14+4=1514字节。以太网帧经过2826E和3928时，分别加
12、上内层VLAN标签和外层VLAN标签，帧长达到1514+4+4=1522字节。该帧被发送给光电转换器，这时我们发现光电转换器能转发的最大帧长就是1522字节，这是在PC上最大只能ping通1460字节的原因。为了证实我们的分析，撤掉光电转换器，将中兴3928和华为8512直接相连，则在PC上能ping通大于1460字节的数据，打开网页也没有问题。四、解决方法撤掉光电转换器只能是临时的做法，跟光电转换器的厂家联系后，得知新型号光电转换器允许通过的最大帧长已经扩大为1530字节，在现场更换了新型号光电转换器后，故障现象消失。第3章 链路捆绑的几个使用注意事项南京用服部 王枫一、故障描述1 如图4所
13、示，某局在连接远端网络的路由器上启用链路捆绑，因为两端路由器都没有千兆光口，只能通过光电转换器进行转接。图中路由器到光电转换器采用双绞线连接，光电转换器之间采用光纤连接。远端用户反映到局端的部分业务会出现中断现象。图4 网络拓扑图2 如图5所示，如果局端直接使用光纤连接远端网络，启用链路捆绑，用户也会反映部分业务中断。图5 网络拓扑图二、解决方法我们先来分析第一个故障，经检查发现，远端网络的一条上联链路中断了，所有的上行流量都走另外一条链路。登录到局端路由器上，发现路由器仍然在两条链路上发送数据包，这就是问题所在。下面来分析一下出现该问题的原因。局端和远端的路由器采用静态链路捆绑方式对接，中间
14、又通过光电转换器转接。在静态对接的情况下只要端口状态是up的，该端口就是捆绑组当中的一员，因此局端路由器不会知道两条链路中的一条已经中断，还会继续在两条链路上发送数据。同时由于默认的转发方式是per destination，因此会造成部分用户通，部分用户不通的情况，如果是使用per packet方式，所有用户都应该有严重丢包的现象。恢复出现故障的链路后问题解决，建议用户使用动态LACP方式进行对接。注意：在有光电转换器转接的情况下，必须使用动态LACP的方式进行链路捆绑。我们再来分析第二个故障，此时两台路由器之间的链路换成了两对光纤，检查链路发现其中一对光纤的一根断了，检查路由器配置发现采用的
15、也是静态链路捆绑方式。一对光纤中的一根用于发送，另一根用于接收。当其中一根断掉，两台路由器中的一台就会收不到光，表现为接口down掉，流量都转移到另外一对光纤上；但另外一台路由器能收到对端的光，接口仍然up，也就仍然是捆绑组中的一员，还会继续在两条链路上发送数据，和第一个故障类似。恢复链路后问题解决，建议用户使用动态LACP方式进行对接。注意：在设备之间是光纤连接的情况下，必须使用动态LACP的方式进行链路捆绑。第4章 OSPF中的Router LSA和Network LSA文档开发部 夏莹一、概述在OSPF网络中，路由器接收到的所有LSA都存放在链路状态数据库中，这些LSA可以完整的描述整个网络的拓扑。OSPF区域中的每台路由器的链路状态数据库都是一样的，每台路由器以自身为根，应用SPF算法，计算出到网络中的每个网段的最短路径。需要注意的是，SPF算法运行两次，第一次根据路由器链路信息计算到网络中的其他路由器的最短路径，第二次根据STUB网络信息，将网段添加到相应的路由器下。本文只介绍单个区域内的两种LSA
