高手教你轻松排除网络故障:你的网络不可能不发生故障。因此, 从现实的角度来讲，你的设计应当考虑到故障的问题。然而, 网络设计总是要面临商业的利益考虑各种平衡：效率与成本、性能与可维护性等等。虽然说网络设计要尽量减少故障率，但是这种减少很可能与其它的限制相矛盾。对于这些问题没有简单的解决方案。然而，这里有几条建议对许多类型的网络都适用。
在组建网络或者重新组合网络时，作为网络规划者的你就应该采用一些网络设计原理，有了这些原理，你才可以使你的网络少出问题，尽可能减少故障所能带来的影响，或者简化故障分析的过程。
在设计网络时考虑故障问题需要对系统如何产生故障有一个全面的了解。因此，在开始讨论设计原理之前，有必要首先回顾一下系统故障类型。这里将以几种不同的故障类型开始。尽管这种概括可能有些简单化，但是已经足够用了。
简单故障：
也许最简单的故障类型就是单一位置的故障或者一个简单故障。这种故障，出问题的部分仅仅是你的网络上的一个组件不工作了。理论上讲，哪个设备出了问题是很明显的，但是通常这并不是问题的关键。在许多种情况下，许多个设备同时出现了故障。比如说，如果网络的唯一一台DNS服务器出现了电缆连接故障，服务器就会无法访问，DNS也无法解析，其它服务中的电子邮件也不能运行。实际上，故障只有一个，就是连接器。一旦这个位置进行了修复，所有的问题都立刻消失了。
互相无关联的多个故障：有时候你可能会面临同时出现或者差不多同时出现的多个故障。通常你会有一种多重故障的错觉，就像上面的例子中所提到的一样，是电缆出了问题。但是有时候确实是不止一个设备发生了故障。在互相无关联的故障当中，出现故障的时间几乎完全是巧合，故障之间并无联系。不幸的是，无关联故障可能很难解决，原因有三：第一，你必须意识到确实发生了多重故障；第二，区分几种故障现象可能会比较困难。最后，总想去寻找根本不存在的关联是人的天性。这种天性往往会误导你。
连续故障：
一种故障引发的其它故障被称为连续故障。在这种故障中，每个故障都需要单独处理。比如说，突然断电会破坏接口。为了使设备重新工作，你必须修复或更换电源和接口（建议首先更换电源）。区分真正的连续故障和单一故障影响其他设备这两种情况会比较困难。但是尽管这种区别对于你的用户来说并无差别，可是在故障诊断时却很重要。
系统故障：
也许最致命的故障就是系统故障了。这是一个经常被滥用和误用的术语。系统故障源于系统组件之间意外、不明显的互相影响。这种互相影响可能是独立故障对于其它设备的作用，或者仅仅来自设备的不兼容。系统故障的发生条件是不熟悉的、未经计划的，或者没被发现的或者不能马上理解的意外的相互影响。多个简单故障如果没有相互影响就不算是系统故障。连续故障也不是，因为相互影响可以很容易理解。也许解释系统故障的最好办法是举一个例子。案例分析：
几年前，李在扩展自己创建的一个校园网时遇到了一个系统故障。理论上说，这个校园网包括了四个子网：一个是大学管理系统，一个是员工网，一个学生实验室网络，还有一个校园互联网连接的接入网络，以及拨入服务等等。开始，这些子网都连接到一个用作email服务器、DNS服务器和路由器的主机。每个子网都是由很多通过hub连接的主机构成的。
一开始这种结构已经足够了，但是没多久之后就需要扩展原来的网络硬件， 这个校园网下一步的发展目标是安装一个单独的路由器，并以交换机取代为数众多的hub。决定关掉电子邮件服务器的路由功能，但是仍然使之保持对四个子网的连接。据称这样可以提高效率，因为本地电子邮件可以无须通过路由器，而且可以提供冗余，因为电子邮件系统在路由器关闭时仍然可以正常工作。因为不同网络的许多用户互相距离很近，所以选择了支持虚拟局域网（VLAN）的交换机。
为了了解这种结构是如何导致系统故障的，有必要首先了解采用的主机和交换机。电子邮件/DNS服务器采用了一个四倍以太网卡适配器，每个网络接口，或者端口采用的是同样的以太网或者MAC地址而不是每个端口采用不同的MAC地址。尽管这不是常规的做法，但是销售商的文件指出IEEE把每个端口使用相同的地址（工作站地址）还是不同的地址（端口地址）这个问题的选择权留给了开发商。（根据原来的配置，由于每个MAC地址都在不同的网络上，所以一切运行正常。）
交换机的一个特征是它们从通过它们的数据中得到MAC地址，然后利用这些信息来控制数据的处理。当一个数据包到达一个端口，它的MAC来源地址就进入了这个端口的地址列表。交换机还搜索每个端口的地址列表来查询目的地址。 如果发现了相对应的地址，它就会将数据包发送到具有包含MAC地址的地址列表的端口，而且，它不会再把数据包发送到其它的端口了。（如果目标地址不在交换机的任何地址列表当中，这时交换机就会像一个hub一样从每个端口把数据包发送出去。）由于设备可能会从一个端口移到另一个端口，一般情况下，当交换机把一个MAC地址添加到一个端口的地址列表时，它会删除其它列表中的这个地址。在具有“传统”交换机的情况当中，采用了工作站地址方法的邮件服务器不会出任何问题。子网的交换机甚至还不知道其它网络中到底发生了什么。
现在考虑一下在这个方案中采用VLAN的含义。VLAN设备的思想是一个物理设备可以被分成几个虚拟设备。如果你有三位教员，两位员工以及四位学生同时在同一个布线室，使用传统的交换机，你需要三个不同的交换机，因为有三种不同类型的用户，每种类型的用户需要分成不同的子网。而且，为了把每个交换机都连接到骨干网，我们需要三种不同的电缆布线连接。有了具有VLAN功能的交换机，交换机可以分为三个逻辑交换机。每个逻辑交换机用于处理单独的网络数据。因此，我们只需要买一台交换机。而且，如果我们在骨干网上采用了VLAN技术，我们在骨干网和布线室之间只需要一根电缆（主干线）连接。每一端的交换机都可以都可以分拣数据并把数据发送到相应的逻辑交换机。显然，VLAN在许多情况下可以显著节约投入。
这就引发了一个有趣的问题：在支持VLAN的交换机上是如何管理地址列表的呢？具体地说，当在某个地址列表上添加了一个设备，那应该是在物理交换机上清除所有端口上的地址列表呢，还是仅仅清除同一个逻辑交换机端口上的呢？由于设备可能会从一个网络移动到另外一个网络，你可能会推断地址应该从一个物理交换机上的所有地址列表中清除掉。许多VLAN交换机也正是这样做的。但是这个决定在用于电子邮件服务器的工作站地址方式时出现了问题。
问题是这样的：电子邮件服务器需要同时入住所有的四个网络。当来自某个服务器的数据包到达交换机的某个端口时，服务器到其他端口的连接就断掉了。网络仍然需要向相应的逻辑交换机发送数据包，但是逻辑交换机这时需要将数据包发送到每个端口，因为在任何一个地址列表中都找不到地址。除非有人在与服务器对话，交换机才会快速稳定下来。但是在同时对话中，问题出现了。
由于服务器之间寻址方案之间的不兼容和VLAN的使用毫无疑问是问题的根源所在，所以原因很简单。问题出现的频率很高，所以整个网络的性能表现非常差，经常发生丢包和掉线的现象。荒谬的是，交换机地址列表却经常溢出。这似乎是分拣来自干线数据的问题，或者别的什么问题。由于经常发生这样的问题，在事实发生之后很长时间才可以把片面的解释归结到一起。如果这是生产系统的问题，那就不可能回过头来仔细研究这个问题。一旦掌握了问题发生的原理，就可以做些改变来改正错误。Ifconfig被用来把不同的MAC地址分配给服务器上的每个端口。 系统特性和系统故障
正如前面所提到的，系统故障的特点是两个或多个部分以一种不明显的或意外的方式进行的不受欢迎的相互影响。我们可以看出，上面的例子刚好符合系统故障的定义。网络的每个部分单独或者在某些环境下面运行都很正常。是不同部分的相互影响导致了故障的产生。服务器的多重连接产生了多重相互影响，而由于这些相互影响不明显，所以诊断和排除这类故障非常困难。
那么系统故障在那些情况下容易发生呢？在Charles Perrow的经典著作Normal Accidents一书中，他分析了从核电站到空中交通管制系统的许多不同的系统。简单地说，他识别出了导致系统故障的几种因素。首先，系统越简单，系统就越不容易发生故障。复杂的系统中有更多的容易出错的东西，更多的相互影响的可能，以及由于在某个部分确实发生了故障的时候有更多的东西需要弄清楚，因此就有更多的出现不明显或者隐藏的相互影响的可能。复杂系统的信息只能间接地收集到或者推断出来。
其次，线性系统与具有很多混合连接的系统相比，出现系统故障的几率更低。具有许多交叉连接的系统有许多组件间交互作用的方式。在具体的交叉连接当中，那些隐性的交叉连接最可能导致系统故障难以诊断。
与线性密切相关的是系统各部分之间的结合度。结合度比较松散，线性系统出错概率就小，结合度紧密，相互影响就发生频繁而且不容易消除。
如果你停下来去想，这些特性都是在意料之中的。但是除非当你停下来并去考虑他们，否则非常容易忽视掉。粗略地说，我把大多数网络归为复杂但相对线性系统一类。（确切地说大多数网络都是树状结构，但是这里指的是设备之间简单明显的线性路径。）大多数硬件往往是相当紧密地连接在一起的，但是使用硬件的协议可能会提供松散连接。但是如果你不这样认为，也没有关系。把系统归为线性还是非线性，紧密连接还是松散连接，简单还是复杂主要还是个人判断。这些都是真正的相关归类。更重要的是能够从这个角度比较不同的网络设计而不是给一种设计归为那一类。
故障诊断
很不幸的是，当你开始故障诊断时，故障类型往往十分模糊。尽管说把所有可能都考虑到会对问题解决有所帮助，但是通常的情况是你没办法把故障归结为哪一类，直到你解决了故障为止。
人们在深入了解情况之前总是在一开始的时候就认为所有的故障都是简单故障。首先从故障的表面现象开始，然后再深入下去。在前一个DNS服务器连接故障中，你可能会从电子邮件软件所报告的DNS故障信息开始，然后开始查找DNS信息。这样你就会发现DNS服务无法实现，随之你就会发现无法连通DNS服务器。这样你就离故障的根源越来越近了。在机械系统中，顺藤摸瓜通常是一个很重要的方法。在网络中，逻辑上的顺藤摸瓜取代了它的位置。
了解不同的故障类型是有帮助的。在诊断一个简单故障时，通常的做法是采用分段解决的方法。在刚刚的例子中，主动将你的注意力转移而不是集中到症状本身可以少走很多弯路。花费时间在检查电子邮件配置文件上或查询DNS会白白浪费大量的时间。在两个或多个设备几乎同时出现故障时，故障诊断会更加困难，因为解决了一个问题并不能使系统恢复正常。因此，能够想到可能会出现多个故障并能想象出多个故障的综合症状对解决问题是很重要的。对于多个故障，当你向解决其中一个问题迈进时，你可能却在离解决另一个问题更远。通常是你排除了一个故障，系统的故障现象就变了。这也是发现多个故障的一个基网络设计
可能导致故障的网络特性时会大有帮助。但是这个方法并不是万能的。在网络设计中，你的目标自然会首先包括避免故障，并减小故障所产生的影响，简化故障的排除。不幸的是，这两个目标是矛盾的。例如，考虑了故障影响的设计必然会使远程故障信息收集更为困难。
简单故障：
一般的建议适用于避免简单故障,采用可靠的设备，经常维护和检测设备,每天更新系统日志，通过使用几个相同的协议和选择几个相同的设备厂商来尽可能简化所用的东西。不幸的是，仅仅使用几个协议限制了你的网络功能；而标准化配置设备意味着你可能会在这些设备上花费更多的钱。并不是所有的情况下采用同一个厂商的产品都是最经济的方案。而特别的需要会浪费许多钱去购买不必要的设备。这在这些里些建议中是毫无疑问的。
多重故障和连续故障：
当然, 尽量减少简单故障是防止多重故障的基础，不管是独立故障，连续故障还是系统故障。下一步是分开以减少网络组件的互相影响。分开可以通过分开数据连接层或通过采用子网分开网络级别来实现。尽管有时候被忽视，出于安全的考虑，防火墙不应该受到限制。它们可以作为一种一般性工具来控制子网之间的数据交换。但是由于分开限制了交互，数据收集就变的更加困难了。 如果你确实划分了网络，（而且你当然应该考虑划分到最小网络单位），内建检查点是很重要的。
最简单的就是每个区内的一些你可以远程登录并安装了数据收集工具的计算机。我Network Troubleshooting Tools一书中介绍了许多有用的工具。你还可以通过配置网络设备如路由器来收集这方面的信息。如果预算允许，你还可以考据增加RMON类似的设备。当然，你应该会想到，这么做会增加网络的复杂性。比如，你可能需要重新配置路由器或者防火墙使SNMP数据能够通过，至少能到达相应的主机。本线索，尤其是在系统故障中。系统故障：
由于系统故障是最难诊断的故障（而且，其后果也可能是惨重的损失），你可能需要在构建你的网络时要特别注意避免或减少这类故障。上面所说的都会有帮助。下一步就是考虑哪些系统特性可能会导致系统故障。
首先, 尽量使你的网络成为线性布局。树状结构的网络相对来说比较好。总的来说，除了偶尔有冗余连接之外大多数网络都是线性的（或者说是树状的）。具有讽刺意味的是，添加冗余路径可能反而会有相反的效果。因为潜在的问题，这是网络需要仔细测试的一个方面。当你添加了额外的路径，你需要知道有产生问题的潜在可能。尽量选择能完成任务的最简单的结构。
大多数网络中单个设备都是相对紧密联合的，尽管使用他们的许多协议和服务可能会连接松散，缓冲和冗余需要在设计时明确考虑到。这可以由某些协议办到，但不是所有的协议都可以。可能的话，根据情况进行选择。
复杂性和效率通常都是和系统紧密相关的。具有讽刺意味的是，最简单的解决方案反而很少有效率高的。因此，有时候需要某种程度的复杂性来实现所要求的功能。复杂性在许多情况下也提高了可靠性。总的来说，如果能满足要求，还是简单些为好，但是前提是它能胜任工作。最后，正如前面所提到的，对于系统故障来说，关键因素是相互影响是隐性的而且不可预知。为了避免出现这种问题，你需要尽可能多地知道你的网络发生了什么事情。不幸的是，这同网络设计的基本原理直接冲突：透明度。从用户的角度来看，网络如何工作的详细内容跟他们无关。因此，网络的设计向用户隐藏了这些细节。如果一个网络在TCP过程中发生了丢包现象，协议会安排在用户不知情的情况下重新发送。也许网络速度会显得很慢，但是这就是顾客所唯一会注意到的事情。从故障分析者的角度来说，隐藏的信息才是你最终需要的东西。解决问题需要你对网络运行的原理有透彻的了解和一系列优秀的收集信息的工具。
结论
工程似乎总是要涉及到均衡：线性对冗余性，简单性对效率，透明度对信息收集。这需要在组建网络时仔细平衡。没有万能的解决方案。可靠性的改进或者易诊断性将会始终是需要花费力气去做的事。但是诊断任何问题的第一步都应该是了解究竟发生了什么事。比较一下你的备选方案的复杂程度并尽量推断出可能在什么地方发生问题
