作者：《网络运维与管理》杂志社
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
网络运维与管理2014超值精华本试读：
前言
关于本书《网络运维与管理》（原《网管员世界》）作为一本专门面向于网络管理技术人员的专业杂志，已经走过了十余年的风雨历程，长期以来，该杂志一直以帮助企业提高企业IT基础设施运营水平、提高企业网管人员的管理水平为目标和宗旨，为企业的网络技术人员提供了一个技术和经验交流的平台，成为在网络管理技术人员中颇具影响力的IT专业媒体。为了更好地帮助广大网络技术人员提高网络管理技术水平，《网络运维与管理》杂志特别推出《网络运维与管理2014超值精华本》，内容包括2013年全年《网络运维与管理》杂志故障诊断、系统运维、信息安全、终端管理、网络管理栏目精彩文章的汇总。
故障诊断
收集了《网络运维与管理》杂志2013年在故障诊断栏目中的精华文章和优秀专题，既是网络管理员在日常工作中排障查错的工具手册，又是网络管理员提高网络管理水平的技术宝典。
系统运维
操作系统和各种应用软件的配置与管理，是网络管理员的又一项工作，系统运维以数十篇精彩的实例文章，剖析在操作系统和应用软件使用过程中遇到的各类问题的解决方法，为网络管理员朋友在对操作系统和应用软件的配置和管理方面等提供了众多的方法和技巧。
信息安全
网络安全是网络管理员在日常工作中关注的重点，安全管理将几十篇网络安全的实用性和应用性文章呈现给广大的读者，帮助读者朋友从容应对网络安全方面的问题。
终端管理
桌面终端管理始终是网络管理技术人员最繁重的工作之一，本章主要的内容就是在终端维护过程终端经验总结和分享，并包含了大量经验和技巧。
网络管理
对于广大网络管理人员来说，网络设备的管理和维护是他们重要的一项工作，设备维护以大量精彩翔实的文章为广大网络管理人员在管理和网络维护方面提供了鲜活的实例和参考，能够帮助网络管理技术人员完成从网络管理菜鸟到高手的转变。本书编委会
主 编：孙浩峰
编 委：张碧薇 孙红娜 王 鹏第1章 故障诊断MAC地址漂移引故障
福建 余小珊
导读 笔者最近遇到了一起由光传输设备的以太网板端口MAC地址漂移引起的网络故障。此故障原因比较隐蔽，而MAC地址漂移只是故障的具体表现，问题的根源出在光传输设备上。下面就将由光传输设备的以太网板卡兼容性差，而导致MAC地址漂移的网络故障实例与读者分享。
MAC地址漂移在网络故障中十分常见，在2011年第21期《网络管理员世界》中就有一篇《透过表象看MAC地址漂移》的文章，全面介绍了造成MAC地址漂移的几种常见原因及其实例。笔者最近也遇到了一起由光传输设备的以太网板端口MAC地址漂移引起的网络故障。本故障原因比较隐蔽，而MAC地址漂移只是故障的具体表现，问题的根源出在光传输设备上。由于光传输设备应用于通信节点机务站，主要支撑通信传输业务，严格地讲不专属于网络设备，所以它与网络设备的兼容性，直接决定了网络的稳定性和可靠性。网络结构
单位总部与两个分部主干网络之间采用中兴公司光传输设备，通过光纤连接网络拓扑结构图（如图1所示）。总部端一节点汇聚网络设备为华三S3610三层交换机，设置VLAN 10和VLAN 20，分别是分部1和分部2的所属VLAN，所连接的端口分别为光传输设备以太网板卡的E1/1和E1/2口。VLAN 10的网关地址为：10.10.10.1/24，VLAN 20的网关地址为：10.10.20.1/24。
在光传输设备管理应用程序中设置以太口与光纤链路的对应关系，即E1/1口连接分部1，E1/2口连接分部2。分部1和分部2的网络接入设备为华三S3600-IE三层交换机，在两个分部的三层交换机中分别设置节点测试地址为：10.10.10.2/24和10.10.20.2/24。图1 网络拓扑结构故障现象
由于总部节点汇聚交换机S3610损坏，临时更换为一台华三S3600-EI交换机，于是故障出现。笔者发现，总部的S3600-EI交换机有时可以Ping通分部交换机的测试节点地址，而分部的交换机却经常无法Ping通总部交换机的各个网关地址，网络陷于瘫痪。
检查确认设备配置无误后，使用命令查看交换机接口，数据包CRC校验正常，没有错误包。查看总部三层交换机ARP表项，表项正常。更换另一台S3600-EI，现象仍然存在。将新的S3610替换回来后，故障消失。
根据以上情况可以判断，链路和网络设备都没有问题，故障是更换了交换机所致。但同样是三层交换机，为什么华三3610可以，而华三3600却不行呢?故障排除
两种型号的交换机一定存在着某些区别，但区别在哪里，一时也难住了笔者。还是还原故障现场，通过反复测试分析，终于找到故障规律：当连接分部1和分部2的VLAN接口同时处于Up状态，且VLAN有三层报文发出时，故障重现。将分部1或分部2的VLAN接口关闭，即只保持一个VLAN接口处于Up状态时，故障消失。
根据故障规律，分别激活VLAN 10和VLAN 20，在分部1和分部2的三层交换机中查看ARP表，突然发现，VLAN 10和VLAN 20的网关地址（10.10.10.1和10.10.20.1）对应的MAC地址居然是一致的。问题会不会出在这里呢?于是重新换回3610，再次查看两个分部三层交换机中的ARP表，发现两个VLAN网关地址的MAC地址不一致。
通过上述实验，确认故障原因为MAC地址漂移所致。当使用3600交换机时，VLAN 10和VLAN 20的网关地址对应同一个MAC地址，而VLAN 10和VLAN 20的接口同时接入光传输设备的以太网板端口。也就是说，光传输设备的以太网板的两个端口同时学习到了同一个MAC地址，于是产生MAC地址漂移，造成网络故障。当使用3610交换机时，两个VLAN对应不同的MAC地址，光传输设备的以太网板上并不会出现MAC地址漂移。如果要使用3600交换机，需更改光传输设备以太网板端口工作模式为透传模式，并关闭端口MAC地址学习功能。故障分析
经查阅资料得知，S3610交换机拥有多个MAC地址，每个VLAN的网关可以分配不同的MAC地址。而S3600-EI三层交换机仅有一个MAC地址，且每个VLAN虚接口使用同一个MAC地址发送报文。但以上故障的关键并不在此，而是由于早期的光传输设备的以太网板对IVL（独立VLAN学习）协议支持较差，即与三层交换机等网络设备的兼容性不够，当同一网络设备（如低端的三层交换机，它通常仅固化有1个MAC地址）通过同一以太网板不同端口连接时，它并不支持“MAC地址+端口”的识别方式，无法区分使用同1个MAC地址的不同端口发出的数据，因而会产生MAC地址漂移的现象。
本故障实例可以说是由以上两种设备各自缺陷影响叠加在一起共同产生的，也就是我们通常所说的设备不兼容。这种兼容性问题在不同类设备之间体现得尤为明显。目前在组网中，网络设备与通信传输设备搭配使用十分频繁，我们一定要重视两者间的兼容性问题。交换机配置为何丢失
福建 黄文毅
导读 单位进行网络标准化配置时，交换机VLAN信息丢失，交换机重启后出现异常。是什么原因导致配置信息丢失呢?
最近，单位进行网络标准化配置，操作过程为，配置模板生成核心网络设备的配置文档，再导入startup-config配置，将配置文件导入路由器、交换机中。
标准化配置结束后，有一天因为更换UPS电池，将路由器、交换机电源关掉。重新开机后，发现交换机所有端口的指示灯变成橙色，局域网内的设备连接都出现了异常。我们使用的交换机型号为Cisco WS-2950。故障分析
在这次掉电前交换机运行正常，除进行标准化配置外，没做其他改动。用笔记本电脑通过Console口连接交换机，交换机开机正常，使用show run命令，发现配置信息中有关VLAN的信息都没有了，难怪所有的端口指示灯都显示不正常，原来是VLAN配置信息丢失造成的。试着重新导入原先的配置文档，交换机又能正常工作了。这是怎么回事?
经思科确认，单位这次进行网络标准化配置工作，在交换机中配置了VTP和VLAN信息，该信息不能通过导入startup-config配置的方式实现。如果使用startup-config导入配置，在导入时交换机会载入原来的vlan.dat配置，之后会将vlan.dat文件初始化。用show vlan查看，各VLAN信息还在，这个设置可能会在交换机下一次重启时生效，导致交换机VLAN信息丢失，进而导致交换机重启后出现异常。故障解决
出现VLAN信息丢失，可以通过手工进行补录。Cisco交换机不同的IOS，VTP、VLAN配置命令不同。在Cisco 2950中可以使用以下命令配置VTP、VLAN。
1.配置VTP
config terminal
vtp version 2（设置VTP版本）
vtp domain（输入VTP域名，如果没有域名，则不用运行此命令）
vtp mode server（设置VTP模式）
vtp password（这里输入VTP口令，如果没有口令则不运行此命令）
2.配置VLAN
config terminal
vlan 10（根据需要设置VLAN编号及VLAN名）
name OA
vlan 20
name PROD
……
手工补录完成后，还应确认vlan.dat文件大小。在Enable权限下，输入命令：dir
结果如图1所示。查看flash目录下vlan.dat文件的大小为正常状态。经验总结
正常情况下，在对新的路由器、交换机进行配置，或者设备出现故障后，通过配置备份文档导入路由器、交换机的配置，是网络管理员常用的方法。但诸如此类IOS的Bug却可能给我们的工作带来意想不到的麻烦，在设置完成后要多留心，保存配置后最好要重启设备，并认真查看、核对配置的完整性。图1 输入命令“dir”分区表影响Linux安装
福建 黄文毅
导读 单位一台装有Windows XP的计算机上安装Suse时，遇到报错信息：“没有可分区磁盘！”，笔者经过排查发现，是磁盘分区表错误导致。通过修改分区表参数，最终使问题得以解决。
笔者由于工作需要，经常需要在一台计算机上同时安装Windows和Linux两种系统，即实现一机双系统的工作模式。
最近，笔者在一台已经安装了Windows XP的计算机上面安装SUSE Linux，操作刚进行到“分析计算机”的环节时，却遇到了在以前安装时没有遇到过的状况，显示“使用分区工具Parted无法读取磁盘/dev/sda上的分区”。当时笔者没有把它当回事儿，继续单击“下一步”进行安装。不料，当运用专家分区程序进行分区操作时，弹出报错信息：“没有可分区磁盘！”至此，只好终止安装。故障排查
由于笔者之前曾多次安装一机双系统，都比较顺利，因此最初对安装失败的原因没有做深入的思考，认定是安装盘造成的故障。但是当更换了几个不同版本的安装盘后，发现所有Linux版本都遇到了同样的问题，因此排除了安装盘的问题。进而将问题的原因锁定到计算机的磁盘上面。
下一步就是思考计算机磁盘的哪些设置会导致Linux安装盘无法读取磁盘分区。
由于之前帮同事将计算机自带的Windows 7改装为Windows XP时遇到过需要将硬盘模式由AHCI改为IDE才能进行安装的经历，因此想到同样是“硬盘模式”导致这次的问题。但进入BIOS更改了硬盘模式后，再安装问题依旧，因此硬盘模式也不是造成安装失败的原因。
是不是计算机的分区有问题造成的呢?于是，查找了一些关于分区表的资料后，放入Ubuntu安装盘，选择“试用Ubuntu”，进入Ubuntu桌面后，打开终端，使用“sudo fdisk-lu”命令，查看磁盘分区情况，显示结果如图1所示。
由此可见，磁盘总共分了5个区：sda1为主分区；sda2为扩展分区，包含两个逻辑分区；sda5、sda6和sda3为用来保存系统备份的隐藏分区。仔细观察可以发现，隐藏分区sda3的起始柱面和结束柱面，居然都包含在逻辑分区sda2内！初步估计这就是问题所在。进一步使用“sudo parted/dev/sda print”命令查看分区信息，显示“错误：分区之间不能重叠”，由此进一步肯定了故障的原因就是磁盘“分区重叠”造成的。图1 查看磁盘分区情况故障分析
这台计算机为单位新购置的一台品牌机，原装的Windows XP操作系统一直工作正常，未出现过任何问题，怎么会出现“分区重叠”呢?原来，电脑买来的时候是一个大分区加上一个隐藏的恢复分区，均为主分区。为了寻求方便快捷，直接从网上下载了一个分区软件进行了快速分区，而没有使用系统自带的分区工具，应该就是那时把分区表搞乱了。故障解决
首先想到的是利用电脑自带的“一键恢复”功能，将所有文件进行备份，然后重启电脑，按住“F2”键，进入“一键恢复”界面（如图2所示），单击“初始恢复”，在功能描述里面显示“初始恢复”能够将系统分区恢复到出厂状态。几分钟后恢复完成，重启电脑进入系统后，发现所有分区仍在，只是分区中的内容都被清除了，“分区重叠”的问题依然存在。图2 一键恢复
既然原有的分区无法删除，那就只能想办法更改分区表了。由于笔者没有直接更改分区表的经验，担心发生误操作会导致分区表的问题更加严重，保守起见，选择使用论坛上评价较高的Disk Genius软件来对分区表做更改。
下载该软件并安装后，打开软件即显示出分区表所存在的问题（如图3所示）：“扩展分区终止位置与未格式化2有重叠”等，并给出了更正方法。单击“更正”按钮，软件并未自动对分区表错误进行更正，于是根据软件给出的更正方法，手动将扩展分区sda2和逻辑分区sda6（软件中显示的为扩展分区和新加卷H）终止柱面的数值都改为比隐藏分区sda3的起始柱面数值小的值，然后保存更改，重启计算机后再打开软件，就没有报错信息显示了。
再次进行Suse的安装时，未出现报错信息，安装过程一切正常，使用至今，Suse和Windows XP一切正常，问题得以解决。图3 运用Disk Genius软件对分区表做更改经验总结
由于笔者对分区表的了解较少，以及遇到问题后的惯性思维，导致故障的处理过程还是多走了一些弯路。现在，新购置的计算机普遍硬盘都比较大，并且新机器通常都未做分区，很多对计算机了解较少的用户都会选择从网上下载分区工具进行分区。
如果使用非系统自带的软件，很有可能会把分区搞乱。一方面，有些第三方软件并不能适应QEM厂商的特殊隐藏恢复分区，另一方面，一些老软件和系统存在兼容性问题。因此，建议用户在给新机器分区时，慎重选择分区工具。最后再说一句，硬盘有价，数据无价！操作时要三思而后行。路由器改造闹故障
福建 黄永生
导读 本单位有一批用于特殊用途的Cisco 2500系列路由器，经过硬件接口改造和重新上载IOS后，用于特殊用途的网络。在路由器改造过程中，对以太网接口电气特性进行了重新定义。然而，由于自制的IOS系统中存在缺陷，引发了路由器故障。
本单位有一批用于特殊用途的Cisco 2500系列的路由器，经过硬件接口改造和重新上载IOS后，用于特殊用途的网络。改造后路由器被命名为TCJ202路由器，在一次组网训练过程中，出现了较为特殊的故障。TCJ202路由器的E2口与中兴交换机连接，组网结构如图1所示。故障现象
在TCJ202路由器的E2口配置IP地址后，使用Ping测试命令，无法Ping通PC1、PC2、PC3等终端，连接PC终端的交换机为普通交换机，PC1、PC2、PC3等终端之间相互能Ping通，交换机没有故障。经检查
路由器发现，路由器与交换机相连接的E2接口MAC地址为全“1”，如图2所示。图1 网络拓扑结构故障分析
我们尝试修改了E2端口的MAC地址后，再配置IP地址，就可以Ping通PC1、PC2等终端，如图3所示。图2 MAC地址全为“1”图3 修改MAC地址
为什么要在修改路由器的以太网MAC地址后再配置IP地址才能使用该端口呢?由于IP数据包常通过以太网发送，以太网设备并不识别32位IP地址：它们是以48位以太网地址传输以太网数据包的。因此，IP驱动器必须把IP目的地址转换成以太网目的地址。交换机无法识别全为“1”的MAC地址，致使数据包无法转发，在路由器上当然无法Ping通PC终端。
为查找不能Ping通的原因，我们在路由器上删除startup-config文件后，重启路由器，使用show interface e2命令查看时，发现其MAC地址又恢复到“1”，查看其他以太网端口，其MAC地址均全为“1”。
我们在找不到故障的具体原因时，Debug工具提供了丰富而详细的调试信息功能，Debug信息主要用来进行数据调测或者故障定位，使用debug ip packet命令显示路由器上任意接口接收或发送的每个数据包的源和目的IP地址时，显示以太网接口地址均为“ff-ff-ff-ff-ff-ff”。故障解决
在路由器改造过程中，对以太网接口电气特性进行了重新定义。同时，根据改造后的需求自己编写了IOS系统，在自制的IOS系统中存在一定的缺陷，所有以太网端口的MAC地址赋值全为“1”，而正是这一缺陷引起了路由器故障，致使路由器只有在重新配置以太网端口的MAC地址的情况下，才能正常使用。
针对上述故障，我们将这一情况通报给IOS开发人员。开发人员修改升级IOS软件后，对路由器的IOS重新上载，在路由器上重新配置用户数据，网络恢复正常。防毒墙客户端为何离线
广州 张鹏
导读 近日，单位局域网内中的部分用户，趋势防毒墙网络版的客户端程序运行不正常，客户端程序状态显示为脱机，无法从控制中心同步病毒定义。是什么原因造成的呢?
近日，单位局域网内部分用户反应，趋势防毒墙网络版的客户端程序运行不正常。经检查发现，客户端程序状态显示为脱机，无法从控制中心同步病毒定义。经确认，这些终端能够正常访问网络中的其他应用，只是无法获取病毒定义更新。尝试将趋势客户端程序卸载后重新安装，故障仍旧出现问题依然存在。故障分析
经过上述检查和处理可以得出如下结论：
1.存在部分终端能够从服务端获取病毒定义更新，说明服务端程序运行正常，能够正常提供更新服务。
2.重装客户端程序无法恢复故障，排除了因为客户端程序损坏导致故障的可能性。
3.由于客户端程序都是由服务端打包程序产生的，安装过程中不需要人工干预，所以出现问题的可能性不大。
问题到底出在哪里呢?一时间没有了思路，于是就联系了趋势科技的技术咨询。在趋势售后工程师的指导下开始故障排查。故障排查过程
趋势售后服务工程师挺负责任，发过来的指导处理方法竟然有两页纸之多。按照此前故障分析得出的结论，直接过滤掉那些“检查数据库是否损坏”、“是否设置了Internet代理”之类的处理步骤，直接检查服务器和客户端的通信是否正常。找到服务器端程序安装目录下的Trend Micro\OfficeScan\PCCSRV\Ofcscan.ini文件，查找到“Client_LocalServer_Port=XXXXX”和“Master_DomainPort=XXXXX”的键值，确认客户机通信端口号和服务器端的端口号。分别在服务器和客户端使用telnet客户机和服务器的通信端口（格式telnet IP地址通信端口号），均可以正常访问，说明客户和服务器两端提供服务的端口都是打开的，不存在无法访问的问题。
无奈之下，只好硬着头皮按照客服的指示，把所有的处理办法都试了一遍，可依然没有任何头绪。没办法，只好按照客服的要求搜集了服务器及客户端的配置文件和日志信息，打包上传，寄希望于售后工程师能够有些发现。同时，笔者觉得既然部分终端是可以正常连接服务器的，那么我们可以对比正常终端与异常终端的配置来分析客户端程序无法联机的原因。
据了解，趋势客户端程序与服务端不同，所有的配置信息都是存放在注册表中的。在“运行”输入“regedit”，展 开 到“HKLM\SOFTWARE\TrendMicro\PC-cillinNTCorp\CurrentVersion\”对 比 两 台 计 算 机的配置，没有发现异常。特别是几个关键的配置“LocalServerPort”、“Server”等都是完全相同的。
此时，笔者注意到一个现象，域管理的计算机几乎都是联机并可以更新。而两台终端配置表“Domain”项目中不同，两台计算机一个在域环境下，一个还在工作组中。这个会不会有影响呢?
抱着“怀疑一切”的态度，找了一台计算机入域。重启计算机后，果然发现杀毒软件显示为“联机”状态，不久病毒定义也自动更新了。
有了这个发现，笔者联想到此前在对比两台计算机注册表时发现“Server”表项的键值为“Secsvr”，也就是服务器的名称，而不是服务器的IP地址。会不会是因为入域后域名能够解析为IP地址，所以才能够联机的呢。笔者找了几台显示为“脱机”的终端，在运行中输入“\\secsvr”，均提示无法连接服务器，而直接输入\\[IP地址]却可以正常访问。
经与趋势客服工程师确认，服务端安装分为服务器名和IP两种连接方式，我们在安装服务器时选择的是服务器名的方式，导致部分组用户无法以服务器名的方式正常访问杀毒控制中心，才引发的本次故障。故障解决
至此，我们已经找到故障点。至于如何解决这一故障，笔者当时考虑也有两种方法，一是重装服务器，选择以IP的方式连接服务器；二是配置客户端能够正常解析服务器名称。
笔者选择了配置客户端的方法，毕竟只有少数办公用户不在域中，工作量要小很多。而且有些工作组中的用户是在防火墙之外的不信任用户，无法入域。所以笔者选择了修改Hosts文件的方法。在Windows\System32\drivers\ect\目录下找到Hosts文件，用记事本打开Hosts文件，按照格式增加一条杀毒服务器的名字解析条目，如图1所示。图1 增加一条杀毒服务器的名字解析条目
现在再试试“立即更新”，很快客户端的病毒定义就被同步到了最近的版本。经验总结
查阅了一下维护记录，前一段时间，由于网络管理员维护时误删了服务端的一些文件，只好重装了杀毒服务器。可能是在重装过程中不小心选择了服务器名连接，导致了部分工作组用户无法正常通过服务器名获取更新。
笔者在故障排查阶段，虽然对比了注册表的配置选项，可是两台终端一台在域环境下运行，而另一台则在工作组环境下运行。虽然配置相同，可是工作组环境下的计算机无法正常解析服务器名，导致无法正常更新。
在处理故障时，我们往往把注意力集中在故障软件上，而忽略了整体环境造成的影响也是十分巨大的。解决病毒库更新故障
山西 徐宏哲
导读 笔者公司使用趋势科技提供的“防毒墙控制管理中心（TMCM）”，采用两级服务器部署模式，父级TMCM服务器从趋势科技官方更新，子级TMCM服务器从父级TMCM服务器更新。然而更新失败，错误主要是“HTTP 404 Not Found”。经排查，是IIS设置有问题。
笔者公司多年来一直使用趋势科技网络版防毒系统，随着公司客户端数量的不断增加，对于各个终端的统一监控管理势在必行。由于公司内外网物理隔离，趋势科技的网络版防毒产品只能了解网段内各终端的情况，对于跨网段终端的统一监控管理则显得薄弱。还好，趋势科技提供了“防毒墙控制管理中心（TMCM）”。部署服务器
按照趋势科技的介绍，防毒墙控制管理中心（TMCM）是一个多层安全管理解决方案，管理员可使用它从一个中央位置控制防病毒和内容安全软件或设备，而不需考虑程序或设备的物理位置或平台如何。TMCM还可用来识别漏洞和感染位置，有助于规划有效的部署和响应计划。
根据前期规划设计，笔者公司决定采用两级服务器部署模式。父级TMCM服务器从趋势科技官方更新，子级TMCM服务器从父级TMCM服务器更新。
TMCM程序的安装和设置比较简单，按照操作手册即可。很快，笔者就将两台TMCM服务器部署完毕了。登录父级TMCM服务器，采用默认的从趋势科技官网更新病毒库及插件程序，手动下载。耐心等待片刻后，更新成功。故障现象
登录子级TMCM服务器，进入管理控制界面后，手动指定更新源的具体路径。更新源地址按照以下格式输入：
http：//父 级 TMCM IP 地 址/tvcsdownload/activeupdate，并分别设置了手动下载参数和预设下载参数。之后，单击手动更新，进行首次更新。等待片刻后，更新竟然没有成功（如图1所示）。图1 手动下载失败故障排查
1.怀疑网络问题
既然提示是“来源网络上的一般故障”，那应该是网络问题吧。但是在子级TMCM上Ping父级TMCM，网络是可达的，Telnet父级TMCM的TCP 80端口也是可以的。这说明网络是没问题的。
2.怀疑更新源路径设置问题
既然是网络问题，应该最有可能的就是子级TMCM的更新源路径设置有问题。
将设置的更新源地址与趋势科技提供的技术手册仔细对比，没有发现什么问题。唯一有点儿不同的是，个别字母要区分大小写。难道还要区分大小写?
将子级TMCM更新源路径设置改为http：//父级TMCM IP地址/tvcsdownload/ActiveUpdate，保存后执行“手动下载”，故障现象一样。看来更新源路径设置没有问题，而且拼写是不区分大小写的。
3.怀疑是程序包下载出错
子级TMCM的手动下载更新总是在进度条进行到90%左右时，就会报出错误提示。莫非父级TMCM虽然从趋势官网下载成功，但下载回来的更新包程序会不会在下载过程中出错导致子级TMCM报错呢?为了验证笔者的这一想法，按照以下步骤进行。（1）登录父级TMCM，进入安装目录，找到\Trend Micro\Control Manager，先备份AU_Data下的所有文件，然后将AU_Data下的所有文件删除（保留AU_Data空目录）。
找到\Trend Micro\Control Manager\WebUI，先备份Download下的所有文件，然后将Download下的所有文件删除（保留Download空目录）。（2）登录子级TMCM，再次执行“手动下载”命令。
执行后，结果同样出现故障提示。
4.查看错误日志
登录子级TMCM，进入安装目录，找到\Trend Micro\Control Manager\AU_Data\AU_Log，里 面 有 个TmuDump.txt文件，双击打开它，发现有错误信息（如图2所示）。图2 错误信息“HTTP 404 Not Found”
从错误信息中可以看出，错误主要是：HTTP 404 Not Found。
例如：
Err 20121206 15：44：38 6616 6992 HttpConnection：Client Error：HTTP 404 Not Found
Err 20121206 15：44：38 6616 6992 TmDownloader：Connection fail when try to open resource故障解决
1.查找故障源
查找与“HTTP 404 Not Found”相关的资料得知，故障原因无非是三种：（1）无法在所请求的端口上访问Web站点。（2）Web服务扩展锁定策略阻止本请求。（3）MIME映射策略阻止本请求。
经分析，“无法在所请求的端口上访问Web站点”和“Web服务扩展锁定策略阻止本请求”可能性不大，最有可能导致以上故障的就是“MIME映射策略阻止本请求”，凭借经验这应该是IIS设置问题。但是具体该设置成什么类型，这就需要咨询趋势官方了。笔者就此问题咨询了趋势技术工程师，得到了较为详细的操作步骤。
2.设置IIS
登录子级TMCM，打开本机的IIS，打开站点下的虚拟目录，进入其中的Download虚拟文件夹（如图3所示）。图3 进入Download虚拟文件夹
在右侧面板中找到Server.ini，按右键单击它，打开属性窗口。在Server.ini属性对话框中打开HTTP头选项卡，打开此栏下面的MIME类型（如图4所示）。图4 Server.ini属性对话框
在MIME类型对话框中选择添加，添加新的MIME类型。
扩展名：.*
MIME类型：application/pctet-stream，单击“确定”按钮即可（如图5所示）。
设置完成后，通过命令“IISRESET”，将IIS服务重新启动后，再次执行“手动下载”，更新成功。至此，故障原因找到并顺利解决。图5 MIME类型对话框VLAN无法阻止广播风暴
浙江 周云翔，张斌
导读 广播风暴是一个大家都熟悉的网络故障，轻者影响信息化业务使用，重者造成全网络瘫痪。笔者单位是一个大型企业，各子公司都有自己独立的VLAN，然而却无法隔离并阻止广播风暴的发生。经过一段时间的努力，我们总结出了控制广播风暴的有效方案。
笔者所在的集团公司网络规模庞大，子公司多达四十余家，公司骨干网络由两台Cisco 6500中心交换机和三台Cisco 4000分中心交换机组成。各子公司都通过Cisco 3500交换机连接到骨干网，各子公司都有自己独立的VLAN，通过规则实现有效的访问控制。所有的VLAN和路由信息都配置在中心交换上，并实现冗余。网络拓扑结构如图1所示。图1 网络拓扑结构
近两年笔者单位每年都会发生几次网络广播风暴，故障发生时通常是公司的信息系统使用人员经常断线，或者发觉网络速度很慢，或者网络有丢包现象，这时候中心交换机CPU利用率通常会达到100%峰值。此时，基本就能判断出网络发生了广播风暴。故障处理
处理广播风暴最有效的方法就是快速找到广播源，笔者采用手工分段断网的方式，对每家子公司逐个断网，断网后故障现象消失、CPU利用率正常，则锁定该子公司为广播源，然后继续在该子公司内用同样的方法分段查找，直到找到源头。
为什么不采用在交换机上输入命令行的方式，查看端口异常流量来判断广播源头呢?在实际工作中我们发现，因为此时交换机CPU利用率很高，登录上去后经常会有大量的报警信息在滚动，命令行方式已经很难操作了。
目前我们排查出的广播风暴原因，一般都是某台主机中毒或者是用户接线不当造成了网络环路引起的。为什么VLAN无法阻止广播风暴
VLAN中文名为“虚拟局域网”，是一种将局域网设备从逻辑上划分成一个个网段，从而实现虚拟工作组的数据交换技术。理论上讲，同一个VLAN中所有设备都是同一个广播域的成员，并接收所有的广播。而不同VLAN成员的交换机，所有的端口都会对广播数据进行过滤，也就是说VLAN本身就能够阻止广播风暴的扩散。
为什么一家子公司的广播风暴没有被锁定在这家公司的VLAN里，反而风暴波及到整个集团骨干网络呢?经过分析，这与整个集团公司骨干网络的设计结构有关系。
集团公司两台中心交换是Cisco 6500三层交换机，其最大特点是交换和路由功能都运行在一起，因此全部子公司的VLAN信息和路由网关信息，都配置在这两台中心交换上，并做了HSRP冗余。两台中心交换的配置信息完全一样，只有运行优先级的区别，目的是当其中一台交换机出现故障时，另一台交换机能及时接管，从而保证整个骨干网的稳定。
当其中一家子公司出现广播风暴时，该公司的VLAN中会出现大量广播包，从而引起运行该VLAN和路由的CPU利用率急剧上升，而该Cisco 6500的CPU利用率急剧上升，会将VLAN运行切换到另一台Cisco 6500中心交换上，进而导致另一台Cisco 6500的CPU利用率也急剧上升，从而使整个网络陷入瘫痪中。控制广播风暴的有效方案
从实际工作中我们感觉到，广播风暴的控制是个复杂的问题，需要从技术和管理两方面相结合才能达到从根本上“治愈”的效果。根据集团公司网络的实际情况，我们给出了以下三种方法联合“施治”，可以从根本上杜绝广播风暴的发生。
1.做好网络接入管理
由于广播风暴都是由某台主机中毒或者是用户接线不当造成的网络环路引起，为此我们在管理上要做到两点。从集团层面进行全网防病毒处理，保证所有电脑都装有防病毒软件，并进行集中式管理。取消所有办公室内用户私自加装Hub或Switch进行网络扩展，减少用户乱接入的情况发生，集中统一由各子公司的网管室或楼层交换机进行接入。
针对这两点，我们专门下发了管理制度，明确了工作方式和责任。
2.调整VLAN部署，减少广播风暴影响范围
由于整个集团的VLAN信息都在两台中心交换上，广播风暴发生时直接冲击两台中心交换，为此利用现有的三台分中心Cisco 4000交换，将各子公司的VLAN和路由信息分别部署到五台交换机上，分离广播风暴的影响范围。
当然，条件允许的话，可以购买一些纯路由设备，将三层交换机上的路由进行单独配置，这样隔离广播风暴的效果会更好。
3.启用思科交换机广播数据包抑制分析
为了缓解过量的广播数据包对网络带来的不利影响，思科交换机设计了广播抑制特征，通过命令配置，使交换机操作系统会自动监测经过其设备的网络流量，当发现广播数据包比较多时，交换机会采取两个方法：要么是丢弃过量的广播数据包，要么是禁用接收过量的流量端口。具体命令如下：
第一个参数thresho1d%，是允许通过的广播数据包流量最大值。
第二个参数violation，是当交换机发觉广播数据流量超过规定最大值时，采用何种方法来处理。排查网络时断时续故障
■安徽 叶明
导读 笔者最近遇到两起用户投诉网络时断时续的故障，现将排除的过程介绍如下，以帮助网络管理员朋友加深对问题的理解并找寻合理的对策。网络环路引起的网络故障
通常有人投诉网络完全中断或不稳定而无法使用的时候，我们会从硬件和软件两个方面分析，分别找到问题可能出现的原因，或者更换设备线路、或者调整网络配置。一般一台电脑出现此类故障时，问题可能出现在核心三层交换机、交换机、线路、用户终端之间的任何一个环节，但是如果一批电脑出现这样的问题那多半就是网络设备的故障了。
1.故障现象
一次接到某办公室投诉，说网络每隔20分钟就要断一下。在排除交换机本身硬件故障（如状态灯不正常、所有端口指示灯不停闪烁等故障现象）、网线已经正常连接以后，陆续又有其他不同地点的用户报告网络不稳定。
2.故障排查
登录他们共同的上层三层交换机，用dis log查看日志，发现有如下信息：
显然是网络中存在环路，根据VLAN信息很容易找到了擅自连接交换机引起环路的那台电脑。原来笔者那天有事，没有及时帮该用户连网，而用户又急着使用网络，就自己乱接，于是造成了这起故障。
3.故障分析
问题看起来是解决了，但是有两个令笔者困惑的问题：（1）笔者在网络中每台交换机（包括申告故障办公室的二层交换机）都设置了stp enable，为什么没有起作用呢?如果说是stp重新计算引起网络路由的不稳定，那最慢也应该几分钟就达到稳定状态了。（2）引起交换机环路的位置与申告故障者根本就不在同一个楼，虽然他们最终接入了同一个三层交换机，但是环路引起的阻塞应该只是发现环路的端口，怎么波及面这么广呢?
根源在于华为交换机默认每个端口都开放了环路检测功能（loopback-detection），对于下行端口，如果交换机发现某个端口有其自身的MAC地址，就会认为此端口下有环路，默认情况下会将此端口设置为受控态，该端口不再学习MAC地址，并且其流量与其他端口隔离，以避免网络风暴影响其他端口。而设定了stp（stp/rstp/mstp）的网络，每个交换机相对的上行端口默认也是检测环路的，于是在网络有环路的时候，stp与环路检测机制就发生了冲突，因为环路检测机制会将发现环路的端口Up/Down，这会影响到stp协议报文传送，进而使得stp的计算结果未能将出现环路的端口discarding掉。而且这样的计算是全网的，会耗费交换机的大量资源并且引起端口的不断迁移，影响到全网的性能，所以就会出现前面所述的网络动荡。
4.故障解决
找到了问题的症结，解决故障就好办了，只要将交换机上行端口的环路检测功能关闭即可。进入端口态，执行“undo loopback-detection enable”，关闭干路的环路检测。
通过这个故障也明白了另一起故障的原因，当时也是同样的一台三层交换机下另一个方向的一对光电转换器坏了，使得三层交换机检测到该端口环路，也是影响到了整个网络。不同的是，当时三层交换机下的网络完全中断，后来换了一对光电转换器就好了，因为故障解决了也就没有对该问题深究，结果造成了同样原因引起的故障。网络病毒引起的网络故障
公司有一个三层交换机是专门连接各个基站的监控系统，因为接入的晚，没有布放光纤直接接入核心路由器，而是暂时连接到附近的二层交换机上，网络一直也还稳定。
1.故障现象
最近接到申告，说他们的整个网络都中断了。因为设备比较重要所以非常紧张，赶紧现场检测。重新做了网线、重启了机器，然后网络恢复了正常。本以为只是一个偶然的故障，也许是某个不经意的动作将它修复了，然后便把这个故障放在一边了。可是随后一两天断断续续地出现同样的网络全断情况，而且非常随机，有网时间有长有短，发生的时间也不固定。
2.故障排查
检测CPU负荷、拔网线减小负载……，征求了各种意见，能想到的方法都用了，效果还是不佳。终于，问题严重到与它相连的二层交换机也无法访问，此时我们才发现了原因。
原来交换机可以对端口下的广播包通过命令“broadcast-suppression 10”（广播包占比不超过10%）加以限制，但是对多播包（multicasts）却没有限制的命令，由于网络中某台电脑感染病毒，大规模地发送多播包，造成相连网络的堵塞。也因此整个故障现象如此随机不可捉摸。
经过对端口出入流量的检查，最终定位到一台双网卡的机器，迅速将其隔离，故障随之消失。经验总结
从以上表象类似但原因不同这一点说起来，网络技术算得上是一门有一定技术含量的技术，但是理论知识只是基础，往往实践经验会使我们更迅速成长。所以事后我们应该及时总结，思考如何采用优化技术手段、完善管理制度等方法，使我们管理的网络更加稳定安全。
就以上问题而言，我们在配置stp的时候，可以采取将不参与stp计算的端口关闭stp功能、指定某台交换机为stp树根、启动根保护等方法来加快stp的计算性能，提高网络的安全性，我们还可以通过规章考核明令禁止私拉乱接、禁止双网卡接入等不安全的行为提高整个网络的运维水平。
从另一方面说，如果每个网络管理员有一个很好的老师，就会有一个比较好的基础平台，可以学习到很多良好的习惯与有价值的技巧。如果身边没有这样的老师，就需要自己更多一点独立思考，时常从不同的角度想想怎样才可以更好地打造出更稳定更安全的网络。虽然有些问题会使人焦头烂额，但事实上每一个技术的难题都是一次难得的锻炼机会，它教会我们去更全面地思考，去关注容易被忽视的细节，以免我们在同样的地方摔倒。路由器Netflow查故障点
福建 郭磊，余小珊
导读 单位内网发现网络有丢包和高延时现象，由于路由器前端没有任何流量控制和监测设备，且不便安装，只能利用路由器本身的功能查找故障原因。笔者启用路由器Netflow功能，对串口板所有接口进出的数据包进行监控和分析，终于找出了故障点。网络被病毒攻击特征
网络蠕虫病毒利用主机操作系统漏洞，通过网络对其他主机主动进行攻击，大量消耗网络带宽和路由器CPU资源，导致网络时延和丢包率急剧增加，有时甚至导致网络瘫痪。
此类蠕虫病毒攻击主机的方式主要有两个特征：
1.攻击的端口一般固定，常见的“红色代码”、“冲击波”、“震荡波”、“SQL蠕虫王”等病毒扫描的端口通常是80、135、445、1434。
2.攻击的目的地址为大量的非法地址，即无网络路由的IP地址，蠕虫病毒正是通过向这些非法地址大量发送数据包，占用路由器等设备大量资源和带宽，使设备死机或瘫痪。
目前，路由器和防火墙等设备都能监控到网络上主机连接的目的地址和目的端口，通过监控其目的地址和目的端口是否出现异常，就能基本判定某主机是否感染了类似的病毒。下面笔者就介绍一下通过路由器Netflow功能来判别蠕虫病毒主机的实例。故障现象
单位内部网络拓扑结构如图1所示，三个分部的网络分别通过2M线路接入总部，所连接的串口分别对应总部路由器的S3/3：0、S3/4：0和S3/5：0，总部路由器的以太口G0/1连接其内部网络用户。总部使用的路由器型号为思科7600。
某日，网络管理员发现到分部1、2、3的网络有丢包和高延时的现象，于是查询路由器工作状态，发现这些分部网络所接入接口的串口板负荷很高，流入的数据量比平时大很多，且该串口板的CPU利用率持续超过70%。各分部也不断上报网络时断时续，丢包严重。图1 网络拓扑结构故障分析与排除
根据故障现象，依次断开分部1、2、3的网络进行测试，发现每当断开分部3的网络时故障便消失，恢复分部3的网络时故障就重现，显然问题出在接口S3/4：0所连接的分部2网络上，最有可能的是该网络上的主机感染了网络病毒而引起的。由于路由器前端没有任何流量控制和监测设备（如防火墙），且不便安装，要找出故障的具体原因，只能利用路由器本身的功能。于是笔者便启用路由器Netflow功能，对串口板所有接口进出的数据包进行监控和分析，其配置过程如下：
1.在全局模式下启动NetFlow功能及设置采样率。
2.在需要启用NetFlow功能的接口上启用该功能，如在接口S3/4：0上启用。
其中参数“ingress”或“outgress”指对进入或流出接口的数据包进行捕获，要分别配置。
3.配置完成后，即可查看接口所捕获的数据包信息。
显示的部分信息如下：
其中，“SrcP”和“DstP”是十六进制方式显示的TCP/IP端口号。如3F24为十进制的16164，0050为十进制的80。
当数据包量很大时，可以使用“include关键字”方式进行过滤，只显示包含特定字符的数据包。如果只需要查看端口号为445的数据包时，用如下命令：
为了便于分析对比，将NetFlow功能启用到串口板的各个接口中去，然后查询NetFlow数据信息（命令：sh ip cache flow），发现连入接口“S3/4：0”的一台主机（IP地址为：6.156.153.1）数据信息异常。其基本情况：一是该IP地址（6.156.153.1）向大量非法的IP地址发送数据包，这些非法的IP地址在网络中没有路由，且地址没有规律，好像是随机产生的；二是其连接的目的地址的目的端口号为01BD，转换为十进制数为445端口，而其他接口的NetFlow数据信息并未发现异常（如接口S3/5：0，图2中下划线所示）。图2 查询NetFlow数据信息
进一步通过命令“sh ip cache flow|include 445”筛选NetFlow数据信息。如图3所示，只有连入接口S3/4：0的一台主机，IP地址为6.156.153.1向大量外网主机的445端口进行连接，其特征可以确定该主机感染了“SQL蠕虫王”病毒。通知分部2网络管理员断开该主机，故障排除。经验总结
Netflow是由思科设计的一种数据交换方式，其工作原理是，利用标准的交换模式处理数据流的第一个IP包数据，生成Netflow缓存，随后同样的数据基于缓存信息在同一个数据流中进行传输，不再匹配相关的访问控制等策略，Netflow缓存同时包含了随后数据流的统计信息。Netflow记录下每个TCP/IP事务的信息，它不像tcpdump那样提供网络流量的完整记录，但是当汇集起来时，它更加容易阅读和分析，实际上它完成的是一种简单的数据流信息的监控功能。此功能不涉及路由器之间的任何连接协议，它也不要求对数据包本身或其他任何网络设备进行任何外部修改，所以，Netflow交换对现有的网络可以说是完全透明的。图3 筛选NetFlow数据信息
另外，因为Netflow交换在每个互联的网络设备中独立地进行，所以并不需要在网络中每个路由器上都操作它，网络规划人员可以在路由器的各个接口上有选择地激活Netflow交换（Netflow数据输入和输出），这样就可以在特定的网络位置上进行数据交换的监控和记账。
Netflow数据信息具有不冗余、统计性强、易分析等特点，这对于一般性网络监控和分析十分适合。我们还可以利用Netflow采集软件将Netflow数据输出并存储到远端工作站或服务器上，以便利用各种分析工具进行进一步的分析处理。思科提供了NFC采集Netflow数据，其他许多厂家也提供类似的采集软件。
值得注意的是，比起其他的交换模式，Netflow要消耗路由器更多的内存和CPU资源，所以在启用Netflow功能之前，我们要清楚路由器的处理能力及资源负荷，避免因为启用Netflow功能而影响到路由器的正常工作。巧用故障路由救网络
新疆 谢军军
导读 单位有几个办公室的网络出现故障，经查是路由器WAN口损坏了。在新设备没有到来之前，我们利用损坏WAN口的故障路由尽快恢复了网络。
客户单位反映，几个办公室的网络早晨上班时无法访问。由于该单位网络为生产网，带上工具立即赶往现场。故障排查
到达现场后发现，该单位采用一拖二的网络结构，由于各办公室只有一个信息点，而每个办公室有三四个人上班，所以各办公室均安装有无线路由器，设备室为路由器PPPOE功能，各办公室使用路由器无线功能（如图1所示）。
打开笔记本电脑通过有线连接到办公室无线路由器，计算机可以快速获取到地址192.168.2.100，浏览器打开192.168.2.1，输入用户名和密码，显示运行状态发现：WAN口无法获取IP地址。
立即将2＃路由器WAN口网线拔下插到计算机上，计算机网卡立即显示正在获取IP地址，显示已连接，网页输入192.168.1.1，输入用户名和密码，显示WAN口运行状态，WAN口PPPOE拨号正常，看来问题还是出在2＃路由器上。同时登录到3＃路由器上，故障现象相同：WAN口无法获取IP地址，流量统计为0。
从以往的维护经验来看：2＃、3＃路由器WAN口同时损坏。
同时通过检测：设备LAN口和WiFi功能正常。故障处理
故障原因找到了，下面的工作就是用户单位购买更换路由器了。但维护单位提出来：能否先让所有网络恢复，确保工作人员正常办公，来回购买设备需耽误不少时间。
既然如此，正好可以废旧利用，接线如图2所示。图1 原办公环境网络结构图2 采用WAN口损坏路由的网络结构
将2＃和3＃WAN口的网线分别接到各自的LAN口上，使用其交换功能，设置需要注意的是需将2＃和3＃路由器LAN口地址更改为不同的IP地址（必须同1＃路由器LAN口一个网段）。
对于2＃和3＃路由器，如果不使用其DHCP功能，只需将其改为不启用即可。如想使用其DHCP功能，需要注意的是必须指定DHCP池的网关为1＃路由器LAN口IP地址，同时需要指定DNS服务器。因为如不设定则获取的网关为2＃路由器的LAN口地址，DNS以为LAN口地址，造成无法上网和域名解析。
对2＃和3＃路由器设置完成后，接入笔记本电脑，无论是有线还是无线，设备获取地址正常，测试网络访问正常，故障解决。经验总结
当然，在设备交换功能和WiFi功能正常的时候，还有其他的可用之处，比如现阶段用得最多的路由器的个网桥功能；企业网中固定IP地址时也可通过这种路由器实现无线功能（借助路由器的DHCP功能，设置同上面基本相同）。
在长期的网络维护工程中还发现，路由器出现故障最多的就是设备WAN口故障，通常由于电压不稳、线路中窜入电压或设备晃电以及静电等原因造成设备端口烧坏，所以用户在设备的使用中要进行定期维护，不使用时尽量关闭设备，降低不必要的损失。排查帧中继故障
福建 黄永生
导读 帧中继是一种分组交换技术，它使用SVC和PVC连接到远程设备，使用多种不同的参数来确定链路开销以及确定可靠的传送。出现故障的环节还有很多，排除故障主要从三个方面入手：排除链路故障、排除帧中继远程路由器的连通性故障、排除帧中继端到端连通性的故障。
帧中继是由ITU-T（国际电信联盟-电信标准部）标准化的高性能WAN协议，并得到了广泛应用，帧中继是一种面向连接的数据链路技术，已经被简化以提供高性能和高效率。而对于防止传输错误，它依赖于上层协议和可靠的光网络和数据网络。
帧中继定义路由器与服务提供商的本地接入交换设备之间的互联过程，它并没有定义数据在帧中继服务提供商网络中的传输方式。
连接到帧中继WAN的设备分为以下两类：
DTE：通常被认为是特定网络的终端设备，如帧中继接入设备、路由器、网桥等。
DCE：是指运营商所拥有的网间设备，如调制解调器、帧中继交换机等。
帧中继通过为每对DTE设备分配连接标识符（DLCI），提供了一种在单一物理链路上统计复用多具逻辑数据会话（称为虚电路VC）的方法。交换设备接收到帧后，它会分析连接标识符，然后将帧转发到相关的出站端口，在传输第一个帧之前会建立到目的地的完整路径。
排除帧中继故障主要从三个方面入手：一是排除链路故障；二排除帧中继远程路由器的连通性故障；三排除帧中继端到端连通性的故障。帧中继配置步骤
帧中继基本配置一般有以下几步骤：
第一步，选择帧中继所需的接口。
第二步，配置网络层地址，如IP地址。
第三步，选择用于封装端到端数据流量的帧中继封装类型。
/*选项Cisco表示使用Cisco封装类型，ietf是Internet工程任务组标准*/
试读结束[说明：试读内容隐藏了图片]