TCP/IP网络故障诊断方法大全

 本文将描述一种对TCP/IP网络进行故障诊断的结构化方法。此篇可以作为引子，后面的文章我们将讨论本文所涉及到的一些关键问题。

　　那么，在你听到“TCP/IP网络故障诊断”这个词的时候，你想到了什么?许多人可能会看到一张流程图。或者说想到了操作步骤有几步的问题。还有许多人可能会感到茫然，无从下手。

　　TCP/IP的故障诊断似乎看起来简单，毕竟，这仅仅是一个拥有四层协议的体系结构，每一层有多种协议。不过，表面的简单并不意味着故障能够轻松解决。下面我们先看看：

　　传统的故障诊断方法

　　几年前，在笔者第一次学习TCP/IP的网络组建时，理解了几个简单的故障诊断的流程，这个流程大体涉及到如下的几个方面：

　　键入ipconfig，用以检查IP地址、子网掩码、默认网关是否正确。

　　1. 运行ping 127.0.0.1,查看网络适配器是否正在工作。

　　2. 运行ping 探测本机的IP地址是否正确或合法。

　　3. 试着ping同一子网内的任何一台计算机的IP地址，看是否ping通。

　　4. 试着ping一下默认网关(即路由器上将你的子网连接到网络其余部分的接口)，看是否ping通。

　　5. 试着ping不同子网的一台计算机的IP地址

　　6. 试着ping外网的一台计算机的IP地址。

　　笔者觉得这种方法有点儿僵化，因为我们几乎可以不用动脑子就可以遵循这些步骤。而且还有点儿效率低下，因为从其过程来看，它先假定你自己的计算机最可能有问题，而且问题极可能离你很近(你的网卡、计算机的IP地址配置、本地子网)，然后才是远程计算机的问题。在互联网还没有真正快速发展之前，这个方法也许不错,也就是说，在DNS成为被广泛采用的域名解析系统之前，在防火墙和VPN等成为多数企业的网络部分之前，这个方案也许不错。

　　笔者的意思是：如果你的一个用户说：“我现在不能连接到服务器上。”那么问题会出在哪里呢?我们有必要将用户的这句话分解为几部分，以便于进一步理解问题。

　　第一部分-“我不能…”：

　　那么，我们应该问一下，是否只有一个用户报告网络问题呢?如果还有其他人，他们出现的问题类似吗?如果是这样的，那么问题很清除了，你不需要采用上述的僵化方法，直接开始对用户的计算机开始故障诊断即可以。否则，问题极有可能出现在其它地方，这可能意味着你的DNS服务器离线了或你的DNS供应商服务出现了问题。或者内部网络上的某个路由器出了问题，出现丢包现象。或许你的用户正试图连接的服务器已经崩溃。

　　或许你应该停下来，想一想这些出现故障的用户可能存在的共同问题。例如，这些机器都位于相同的子网上吗?如果是这样的话，那么有可能那个子网的默认网关配置错误或者路由器瘫痪。或许是某个工作人员将连接子网的工作组交换机到骨干交换机的网络电缆切断了。或许是某个恶意用户将一个欺诈性的DHCP服务器安装到那个子网上了，这个恶意用户正窃取机器的IP地址，而将一些不可路由的地址分配给那些计算机，从而形成拒绝服务的故障。

　　当然，如果只是一个用户存在着这种问题，那么就需要我们问这样一些问题，如“计算机开机了吗?网络电缆安全地安装到了计算机的后部了吗?”

　　“…连接到…”

　　可以问这位用户这样一个问题“你所说的连接是什么意思?”这是因为“连接”是一个技术性很强的词语，许多用户其实并不真正理解所谈论的东西。为什么呢?因为存在着不同种类的连接，包括MAC级的通信、TCP会话、口令验证、访问权限和特权、跨NAT的连接、防火墙的通过、应用层的会话等等。作为网管员需要知道用户的问题是什么。当这些用户说不能“连接到”服务器时，他们正在做什么?是在访问此服务器上的一个共享吗?在访问时是否收到了一个“拒绝访问”的消息呢?这些用户是否收到一个登录窗口，提示其输入相关凭证呢?(如账户名、口令等)服务器拒绝其凭证了吗?这些用户在找到或使用活动目录中的共享时发生了问题了吗?他们发现问题的是一个映射驱动器吗?他们是不是正通过浏览网上邻居来查找服务器呢?等等。

　　这些用户仅在连接某台服务器时才出现故障吗?或者，这些用户是不是在连接到任何网络节点时都出现故障?在这里，决定问题或故障的范围是很重要的：连接是一个方面或多个方面呢?“…服务器…”

　　你搞定了这个用户，而且搞定了那台服务器，也搞定了其间的网络。它们仍不能连接?为什么呢?需要注意的是那台服务器到底在什么地方呢?它在用户的子网上吗?在一个相邻的子网上吗?在一个不同的部门上吗?在一个不同的楼层上吗?在一个不同的大楼上吗?是哪种网络将用户与特定的服务器连接起来?是无线以太网吗?是无线局域网吗?是互联网上的VPN通道吗?是拨号的modem连接吗?是线缆modem还是DSL modem?首先决定用户和服务器之间的连接类型(有可能是几种)，然后思考哪个地方有可能出现故障?有可能是CSU/DSU出了故障，可以试着给它重新加电或与应该监视CSU/DSU的供应商联系。也有可能是某人在打扫卫生时碰到了电源开关，导致某个以太网交换机离线。如果你用的是可网管型交换机，也可以检查网络管理软件的警告信息。也有可能是远程服务器所在的办公室发生了电源中断。可以试着电话咨询一下。

　　用户是仅与一台服务器无法连接，还是无法与多台服务器不能连接?其他人也不能连接到那些服务器上吗?在受影响的服务器之间有什么共同的东西吗?(问题有可能与用户的计算机有关，更有可能与网络架构自身有关)

　　“…现在”

　　时间因素在故障诊断中是至关重要的。应该问一下：问题是刚刚发生吗?上次成功连接到服务器是在什么时候?这种现象持续了多长时间?是连续性的还是间断的?断断续续的网络问题涉及到不可靠的WAN链接以及其它一些难于解决的问题，特别是这些问题持续很短暂时间或偶尔出现时更是这样。

　　时间因素还有可能将问题与可能影响网络的其它情况联系起来。问题是出现在今天上午10点20分吗?彼时你的网络还出现了哪些问题?WSUS服务器上打补丁了吗?域服务器上的预定维护实现了吗?

　　结构化的方法

　　笔者自己的TCP/IP网络的结构化故障诊断的方法由三个关键部分组成：

　　1. 决定问题的因素。也就是说要考虑如下方面：

　　客户端：即出现问题的客户端
　　服务器端：客户无法访问的服务器、打印机或其它的网络资源(如互联网)等。
　　其间的网络：线缆(如果不是无线的话)、集线器、交换机、路由器、防火墙、代理服务器，以及客户端和服务器之间的其它网络架构。
　　环境：可能会影响你的网络的外部情况，如电源的波动、建筑物的维护等等。
　　范围：一个或多个有关的客户端/服务器端。
　　期间：连续的、间断的，还是偶尔的，何时开始等。
　　出现问题的连接类型：物理层、网络层、传输层还是应用层?身份验证还是访问控制?等等。
　　标志性信息：客户端机器上的出错消息，登录对话框等等。
　　2. 在考虑到以上问题因素时，决定需要应用哪些故障诊断措施，这些措施包括：

　　验证有关客户端、服务器和网络架构硬件的物理媒体。也就是说检查电缆，确保网络适配器正确安装，并进一步查找、验证可以显示媒体断开状态的网络连接。

　　验证有关客户端、服务器、网络架构硬件的TCP/IP配置。在客户端上这意味着检查IP地址、子网掩码、默认网关、DNS设置等等。对于网络架构硬件而言，也就是指路由器上的路由表和Internet网关。

　　验证有关客户端和服务器端的路由选择的连通性。也就是说要使用ping，pathping，tracert，或其它类似的工具，便于在网络层上验证端到端的TCP/IP的连接性;采用数据包嗅探以监视传输层会话;使用nslookup，telnet和其它的工具来诊断包括域名解析问题、身份验证等应用层问题。

　　3.理解之、询问之、测试之:

　　理解协议如何工作，数据包如何由路由表转发，netdiag.exe等工具能够告诉你什么是非常关键的。成功的TCP/IP故障诊断是建立在理解TCP/IP如何工作和有关测试工具的基础之上的。如果你从来没有努力理解网络监视器的跟踪模式，那么你在诊断某些问题时就会遇到困难。

　　问一些恰当的问题对于成功的故障诊断也很关键。要学会何时按部就班，何时以跳跃性思维直奔主题是故障诊断艺术的本质所在，这还括充分使用你的左右脑，即要有充分的想象和缜密的思维。

　　最后，踏踏实实地测试，并隔离问题是很关键的，为此你需要故障诊断的工具箱。而且没有什么比丰富的经验更能帮助你解决复杂问题了。

　　小结

　　诊断TCP/IP网络的故障时可能会使人灰心丧气，不过也充满乐趣。在未来的文章中，我们将祥细阐述故障诊断的措施和工具，以帮助你成功地解决网络中出现的问题。本篇解释路由表如何工作，并阐述如何在Windows网络中诊断路由故障。在上篇文章中，笔者概括性地指出了TCP/IP网络故障诊断的结构化方法。这种方法有三个关键方面：

　　理解作为基础的网络技术和协议
　　决定问题的不同元素及其属性
　　决定应该采取哪些故障诊断措施和工具来解决问题
　　笔者以为故障诊断问题不是简单的一、两步措施就能够解决的，换句话说，故障的解决更确切地讲是一种艺术(基于直觉)而非科学(基于某种方法)。

　　TCP/IP网络的基础是路由表，这是一种TCP/IP网络上每台主机的数据结构。路由表有以下三个作用：

　　用于存储网络上其它子网的信息，以及如何到达这些网络上的主机。
　　为了达到此数据包的最终目的地，路由表可以决定每个数据包如何被转发到某台主机。
　　用于决定哪个网络接口(称为下一跳接口)应该用于转发这个数据包，从而使其到达目的地。
　　可以说，如果你想高效地诊断TCP/IP网络上的路由问题，理解路由表是很关键的。现在让我们看看路由表是如何工作的，在不同的情况下路由表的表现是怎样的，并且看看在不同的情况下需要使用哪些故障诊断的措施和工具。我们将从检查一个简单的服务器(只有一个网络接口的服务器)的路由表开始，此服务器只分配了一个IP地址。笔者选择这个例子是因为它最易理解，在笔者的下一篇文章中，我们将看一些更为复杂的例子，包括拥有多个IP地址的服务器(如web 服务器)和拥有多个网络接口的服务器(如既能连接到LAN又能连接到一个用于备份的单独的网络)。

　　只拥有一个IP地址的简单服务器的路由表

　　下面的路由表是在172.16.11.0/24网络上IP地址为172.16.11.30的服务器的路由表:

     

以下是引用片段： 　　C:/>route print 　　IPv4 Route Table 　　=========================================================================== 　　Interface List 　　0x1 ........................... MS TCP Loopback interface 　　0x10003 ...00 03 ff 25 88 8c ...... Intel 21140-Based PCI Fast Ethernet Adapter 　　(Generic) 　　=========================================================================== 　　=========================================================================== 　　Active Routes: 　　Network Destination Netmask Gateway Interface Metric 　　0.0.0.0 0.0.0.0 172.16.11.1 172.16.11.30 20 　　127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 　　172.16.11.0 255.255.255.0 172.16.11.30 172.16.11.30 20 　　172.16.11.30 255.255.255.255 127.0.0.1 127.0.0.1 20 　　172.16.255.255 255.255.255.255 172.16.11.30 172.16.11.30 20 　　224.0.0.0 240.0.0.0 172.16.11.30 172.16.11.30 20 　　255.255.255.255 255.255.255.255 172.16.11.30 172.16.11.30 1 　　Default Gateway: 172.16.11.1 　　=========================================================================== 　　Persistent Routes: 　　None

     
     为了显示这个路由表，你需要打开一个命令提示窗口，在其中输入route print。下面我们对其各个部分逐个分析便于我们理解它是如何工作的：

　　路由表中每一个路由表项(或路由)都由五个字段组成：

　　网络目标地址(Network Destination)：代表某个可能的目的地址，它是一个IP地址或子网，即表示IP数据包被转发到何处的地址。
　　掩码(Netmask):一个用于将某数据包中的IP地址中的目标地址字段与上面可能的网络地址匹配起来的位模式。
　　网关(Gateway)：下一跳的IP地址，数据包必须被转发到此，才能到达特定的目的网络。
　　接口(Interface)：下一跳的接口，这个接口必须用于将数据包进行转发，以达到特定的目的网络。
　　跳数(metric):表示到达目的的过程中经过了多少跳数(路由器数)，即路由的成本。示例一：目标主机在本地子网上

　　对于我们例子而言，假设这个特定的服务器(172.16.11.30)要将数据包发往同一子网内的另一台主机(IP地址为172.16.11.80)。那么这个数据包的源地址为172.16.11.30，目标地址为172.16.11.80。下面我们将展示Windows是如何用其路由表来决定选择使用哪条路由的：

　　1. Windows首先依次从路由表中取出每一个路由，并将数据包的目标地址(172.16.11.80)与选中路由的掩码执行逻辑“与”运算。下面展示结果，这里，路由表中的每一个路由是通过其网络目的地址确定的：

　　

Route	Netmask	172.16.11.80 AND Netmask
0.0.0.0	0.0.0.0	0.0.0.0
127.0.0.0	255.0.0.0	172.0.0.0
172.16.11.0	255.255.255.0	172.16.11.0
172.16.11.30	255.255.255.255	172.16.11.80
172.16.255.255	255.255.255.255	172.16.11.80
224.0.0.0	224.0.0.0	160.0.0.0
255.255.255.255	255.255.255.255	172.16.11.80

　　

    2. 对每一个路由来说，这个“与”运算的结果要与路由的网络目标地址比比较，而二者的一次匹配意思着这条路由可被用于将数据包转发到其目标地址。如果发现不只有一个匹配，Windows就会选用拥有最长匹配的路由(即1的位数最高的路由)。如果这并不有产生唯一的路由，Windows就任意地选用一个作为路由。从上面的列表中，这个“与”运算的结果导致了两个匹配(路由1和3)，因此Windows选择了拥有最长匹配的路由，即第三行的那个。其结果是Windows知道了使用哪个路由将数据包传送到目的地。下面是这条路由在服务器的路由表中看起来的样子：

　　Network Destination   　　Netmask     　　　 Gateway        　　　Interface Metric

　　172.16.11.0               　　255.255.255.0 　　172.16.11.30 　　　172.16.11.30 20

　　3. Windows现在要使用下面的算法来决定下一步做什么：

　　a) 如果路由的网关字段与服务器上的一个网络接口的地址相匹配(或者如果网关是空的话)，那么Windows就会用在路由中指定的接口将数据包直接发送到目标地址。

　　b) 如果路由的网关字段并不与服务器上网络接口的任意地址相匹配，Windows将会把数据包转发给路由中的网关字段的地址。

　　很明显，这里符合条件a，路由的网关字段(172.16.11.30)即为分配给服务器单个网卡的地址。Windows因此会作出决定认为目标地址位于本地子网上，这也就是说Windows不需要将数据包发送到任何路由器，而是直接发送给其目的地址。在此例中，Windows使用服务器的172.16.11.30的网络接口，简单地将数据包发送给172.16.11.80，接收主机得到了数据包。示例二：目标主机在远程子网上

　　现在，让我们继续同样的过程，不过这次我们假定服务器想把数据包发往一个不同子网上的一台主机(IP地址为172.16.10.200)。换句话说，数据包的源地址为172.16.11.30，目标地址为172.16.10.200。下面我们看一下Windows是如何利用路由表决定选择哪条路由的：

　　1. Windows从路由表中取出每一条路由，将数据包的目标地址(172.16.10.200)与路由中的掩码进行“与” 运算。运算结果如下：

   

Route	Netmask	172.16.10.200 AND Netmask
0.0.0.0	0.0.0.0	0.0.0.0
127.0.0.0	255.0.0.0	172.0.0.0
172.16.11.0	255.255.255.0	172.16.10.0
172.16.11.30	255.255.255.255	172.16.10.200
172.16.255.255	255.255.255.255	172.16.10.200
224.0.0.0	224.0.0.0	160.0.0.0
255.255.255.255	255.255.255.255	172.16.10.200

　　
    
    2. 对于每一条路由来说，“与”运算的结果要与路由中网络目标地址相比较，二者匹配意味着这条路由可被用于将数据包转发到其目标地址。从我们上面的第二张路由表，你可以看出这次只有一个匹配，也就是说是第一行，这个路由的网络目地字段(0.0.0.0)与“与”运算的结果匹配。因此Windows用来将数据包转发到其目标地址的路由即为下面的路由：

　　Network Destination 　　　Netmask 　　　　Gateway 　　　　Interface Metric

　　0.0.0.0 　　　　　　　　　　0.0.0.0 　　　　　172.16.11.1　　 172.16.11.30 20

　　3. 然后Windows就会使用前述的算法来决定下一步做什么，这次符合条件b，因为路由的网关字段(172.16.11.1)与分配给服务器的单独网卡的地址(172.16.11.30)并不匹配。Windows因此会决定目标地址位于一个远程子网上，将数据包转发给路由器，路由器通过继续转发数据包将其传送到目的地。在此例中，Windows使用服务器的172.16.11.30网络接口，将数据包发送到在网关字段中所显示的地址。一旦位于172.16.11.1的路由器收到了数据包，它会决定下一步需要采取什么步骤，才能将数据包转发到其最后的目标地址172.16.10.200，而这又依赖于172.16.11.10/24网络是172.16.11.11/24(由单个路由器连接)或一个远程网络的邻近子网(由几个中间网络之间的路由器连接)。故障诊断小技巧

　　在上述的过程中哪里会出问题呢?首先，Windows有可能无法选择一条网络目的地址字段与“与”运算的结果(即路由的掩码字段与数据包的目标字段“与”运算的结果)相匹配的路由。如果发生这种情况，你就会收到一个路由选择错误，这一般会通过一些运行在服务器上的网络应用程序指示给你。通常情况下，Windows会使用TCP来通知网络堆栈的上层，说明数据包不能送达，就会导致某种错误消息。

　　在这种情况下，你的路由表可能已经损坏，或者说，你的路由表中有一个非法的持久性路由。持久性路由指的是你通过使用route -p add手动命令添加到路由表中的路由，这种路由需要重启才可以使用，因为其值是存储在注册表中的。如果你添加了非法的路由，就会产生奇怪的结果。(虽然这种非法路由多数情况下会导致数据通信被莫名其妙地丢弃。)

　　另外一方面，如果目标主机位于一个远程子网上，Windows会将数据包转发给一个路由器(默认的网关地址)，而这个路由器又不能选择一个路由，那么这种情况就会发生：路由会将把一个ICMP(网际控制报文协议)消息：“目标不可达到(Destination Unreachable)-主机不可到达(Host Unreachable)”返回给发送此数据包的主机。此例中，TCP会通知上层协议，然后就会显示某种错误消息。

　　无论何种情况，一个处理问题的实用方法是在发送方主机上检查路由表，还要检查数据包在到达目的地的过程中沿途经过的路径所连接的路由器，查看这些路由表是否一致或已经损坏。一个损坏的路由表可以通过重置TCP/IP堆栈进行恢复(至少在Windows计算机上是这样)，具体方法是使用netsh int ip reset命令，大家可以参考微软的KB299357查找祥细资料。不过，需要注意，这种重置操作并不会清除你手动添加到路由表中的路由。

　　结论

　　我们讨论了路由表是如何工作的，并且阐述了如何诊断路由表的故障，下一篇文章我们将讨论几个更为复杂的例子，例如看看拥有多个地址和多个网卡的服务器的情况。这是网络故障诊断结构化方法的第三篇，本文谈的是如何利用Windows平台的网络连接修复特性。

　　成功的故障诊断依赖于三个重要支柱：缜密的逻辑思维、对技术与技巧的理解、诊断工具的使用经验。我们的文章主要以这三个支柱为基础。例如，在笔者的首篇文章中，我们概要地描述了一种结构化的方法，展示如何从逻辑上诊断Windows系统网络的TCP/IP网络故障。在第二篇文章中，我们重点从技术上讨论了路由表是如何工作的，并讨论了路由表问题的故障诊断技巧。今天的这篇文章中，我们将理解Windows的网络修复特性如何修复常见的网络连接问题。后面我们还有文章讨论上述的三大支柱，以帮助读者成为更为专业的故障诊断高手。

　　修复特性是一个强有力的工具，虽然大家很少用它(你用得很多吗?)，因为许多人没有真正地理解它。使用这个特性是相当简单的，只需要在网络连接上右击，从弹出的快捷菜单中选择“修复”即可。如图：

   

    
    在我们这样操作时，就会弹出一个对话框，连续地显示一系列的消息，这些消息表现了修复活动的工作过程。如图：
    
   

    
    在上面的图中，我们看到的正在进行的修复操作是“清除DNS缓存”，这仅是一个修复操作而已。背后，Windows执行的是一些命令行操作，图中的每一个过程的消息(如“清除DNS缓存”)都指明了其中的一个命令被执行了。那么，在我们使用“修复”功能时，到底系统运行了哪些命令，执行了哪些操作呢?这些命令做了什么?它们对系统产生了怎样的影响?为什么要执行这些操作或命令?下面我们一一道来：

　　第一步：DHCP更新(DHCP Renew)

　　如果你配置了网络连接使其可以通过DHCP自动地接收IP地址，就会需要这一步。如果你手动配置了连接，使用的是静态的IP地址和其它的TCP/IP配置，就不需要这一步了。此处执行的这个命令行操作类似于但不同于下面的命令：

    

以下是引用片段： 　　ipconfig /renew

    
    这个命令会试图与DHCP服务器(计算机先前的IP地址就是从此租用的)联系。如果可以联系到DHCP服务器，计算机就会确认其目前的TCP/IP配置是合法的。不过，在这个命令通过“修复”功能执行时，与通过命令行方式启动它的行为是不一样的。此时，并不是向获取其IP地址和相关DHCP配置的服务器发送一个单播的DHCP更新消息，而是向网络中的任何可用的DHCP服务器发送一个DHCP更新消息的广播包。如此做的原因在于，如果计算机目前的TCP/IP配置是非法的，计算机就可以通过要求一个新的地址租用，从任何可用的DHCP服务器那儿获取新的TCP/IP配置。执行“修复”网络连接这个操作有两个方面的影响：一是解决客户端上的DHCP配置问题，二是在无需与一个特定的DHCP服务器联系的情况下解决问题。

　　小提示：通过实施网络上的DHCP服务器的冗余机制，来防止由于DHCP服务器不可用所造成的网络问题。现在网上有不少这样的文章，读者可自己用google等搜寻。第二步：清空ARP缓存

　　这一步执行的命令行操作如下所示：

　　

以下是引用片段： 　　arp –d *

    这个命令清空本地计算机上地址解析协议(ARP)缓存中的内容。ARP是一个用于将IP地址解析为MAC地址(固化到局域网网卡内)的协议。ARP缓存包含着最近一段时间以来解析的网络节点的MAC地址。这些MAC地址被保存到计算机的缓存中，目的是与这些节点(IP地址)的通信无需重复解析就可以实现。如果ARP缓存中的一个或多个项目不正确，那么与某些IP地址的网络通信就会失败。如果某个不正确的缓存项目属于本地子网的一个点，那么与那个节点的通信就会失败。如果默认网关的缓存项目不正确，那么与远程子网节点的通信就会失败。这种类型的网络通信失败(不管是位于本地子网还是远程子网)都可以指明哪一个ARP缓存项目是不正确的(假设不正确的ARP缓存项目是问题所在)。

　　第三步：清空NetBIOS缓存

　　这一步执行的命令行操作如下所示：

   

以下是引用片段： 　　nbtstat –R

    
    这个命令会清空本地计算机上的NetBIOS缓存内容。运行这个命令还会将LMHOSTS文件中的任何项目预先装载到缓存中。在多数基于Windows的网络中，包括那些部署了活动目录和DNS域名解析的网络，老的NetBIOS名字解析仍可用于某些功能。由于可通过查询一个WINS服务器或通过运用NetBIOS广播将远程主机的NetBIOS名字解析为其相关的IP地址，这些主机到IP地址的映射就被添加到本地计算机的NetBIOS缓存中，从而与远程主机的通信在无需反复多次解析的情况下就可以实现。如果NetBIOS缓存中的一个或多个项目不正确，与网络中的某些IP主机的通信就会失败。如果本地子网主机的缓存项目不正确，那么与此主机的通信就失败。如果默认网关的缓存项目不正确，那么远程子网上的主机通信就会失败。这种网络通信失败(不管主机是在本地子网或远程子网上)可以指明NetBIOS缓存中的哪个项目不正确(假设不正确的NetBIOS缓存项目是问题所在)。

　　不正确的NetBIOS缓存项目有时是由WINS服务器上WINS数据库中的过时项目引起的。这是因为在实施WINS后，WINS要优先于NetBIOS广播的名字解析，因此损坏的或过时的WINS项目就会用不正确的项目重新注入NetBIOS缓存，即使在缓存被清空以后也是如此。这种情况的解决方案是要在WINS数据库中永久性地标记不正确的记录，再次清空NetBIOS缓存内容，然后用nbtstat –c命令监视缓存，用以确保这些不正确的项目不会再被加裁到缓存中。

　　第四步：清空DNS解析程序缓存

　　这一步执行的命令行操作如下所示：

　　

以下是引用片段： 　　ipconfig /flushdns

    这个命令清空本地计算机DNS解析程序缓存中的内容。运行这个命令还会将HOSTS文件中的任何项目预先装载到缓存中。通过查询名字服务器(DNS服务器)，远程主机完全合格的DNS名字就会被解析为相关IP地址，这些FQDN来到IP地址的映射就会被添加到本地计算机DNS解析程序的缓存中，这样一来与远程主机的通信就无需重复地进行解析。如果DNS解析程序缓存中的一个或多个项目不正确，某些IP地址的网络通信就会失败。要查看DNS解析程序缓存中当前的内容，请在命令行提示符下，键入执行ipconfig /displaydns命令。

　　如果你试图解析的远程主机的IP地址最近发生了改变，那么你可能就无法用其FQDN与那台主机通信，除非你清空DNS解析程序的缓存。当然，利用指定的TTL，缓存项目会自己就会超时，这些TTLS是在名字解析期间，从名字服务器获得的，不过，如果你注意到突然不能连接到某台远程主机，你就可以试着修复你的网络连接，清空DNS解析程序缓存。第五步：再次在WINS中注册

　　这一步执行的命令行操作如下所示：

   

以下是引用片段： 　　nbtstat –RR

    
    这个命令试图在WINS服务器上的WINS数据库中重新注册本地计算机。这也就是说本地计算机的所有NetBIOS名字都是首次发布，然后在数据库中重新更新。如果你的网络拥有WINS服务器，这当然就很有用了，不过部署活动目录和Exchange Server的多数企业环境仍在使用WINS，请参考如下网址获取更为详细的信息。 http://support.microsoft.com/default.aspx/kb/837391

　　在一台Windows计算机正常关闭时，它应该从WINS数据库释放其记录。如果一台计算机并没有正常关闭，那么这台计算机的WINS记录就不会从数据库中正常清除。WINS数据库中的过时记录将会导致网络通信问题，特别是对于象笔记本电脑等可移动计算机来说，因为它们有可能从一个网络离开，然后又挂到另外一个网络上。通过强迫计算机重新在WINS注册，使用修复功能通常能够解决这些问题。

　　第六步：在DNS中再次注册

　　在用户使用注册特性时，这一步执行的命令行操作如下所示：

　　

以下是引用片段： 　　ipconfig /registerdns

    这个命令会试图在名字服务器上的DNS数据库中再次注册本地计算机。这意味着本地计算机所有的DNS名字都是首次发布，并在DNS数据库中更新(假设你拥有活动目录网络，可以使用动态DNS(或DDNS)在数据库中注册DNS名字)。

　　结论

　　网络连接的修复特性对于诊断网络连接问题是一个有用的工具。不幸的是，多数管理人员并没有意识到这个特性是如何工作的，本文通过探索执行此动作幕后的操作试图纠正这一点。由于排除了可能的原因，如不正确的或缺失DHCP配置、非法的ARP缓存项目、非法的NetBIOS或 DNS解析程序缓存项目，或者非法的或过时的WINS或DNS数据库的过时项目，我们就可以知道这个工具是如何工作的，从而有助于缩小故障诊断努力的范围。如果你的网络存在着连接故障，而你已经确认了网络的媒体连接是正常状态(也就是没有电缆松动情况，也没有关闭集线器或拨掉交换机的电缆),那么修复特性就应该成为你努力解决问题、恢复连接的首选措施之一。

 

原文：http://blog.zol.com.cn/994/article_993017.html