20世纪80年代中期，各大公司逐渐感受到了盲目地大规模扩展网络带来的后果，使用不同标准的网络之间很难通信，于是他们意识到必须摒弃先前的专用网络系统，制定一种网络之间连接的标准。1984年发布的OSI-RM开放体系模型（Open System Interconnection - Reference Model），它为各个厂商提供了一套标准，确保全世界各公司提出的不同类型网络技术之间具有良好兼容性和互操作性。
开放系统互连参考模型（Open System Interconnection - Reference Model）中的关键字“开放”与“互连”就是为解决这个问题。“开放”表示能使任何两个遵守参考模型和有关标准的系统进行连接。“互连”是指将不同的系统互相连接起来，以达到相互交换信息、共享资源、分布应用和分布处理的目的。
中铁集团某分公司进行了一次网络改造，分公司的网络用户报告说其中有一台客户端在调整办公室后无法访问总部服务器。由于总公司到分公司的路途遥远，所以采用了电话支持和网络设备远程排错的方法，最终排除了故障。
选择排查故障的思路
OSI模型并不只是一项“死”知识，而是指导网络组建和故障排除的一种原则。利用OSI模型排除网络错误工作中有3种方法可以使用。
（1）从下至上的方法：从OSI模型底端开始，顺序向上。
（2）从上至下的方法：从OSI模型顶端开始，顺序往下。
（3）分而治之的方法：从OSI模型特定层开始，确定问题是在该层、还是上层或下层。
由于分公司的其他客户端都能访问到总部的服务器，而只有一个客户端无法访问，所以应该确认服务器的应用程序是没有问题的，所以可以采用“从下至上”的方法排除网络故障，即从物理层开始。由于是远程管理，在处理此次网络故障时总部工程师并没有到现场，但最终排除了故障。他们并不是通过经验直接判断问题的症结之处，而是根据OSI的7层模型，从“物理层”开始排除问题的，当确保网卡和网络连接没有问题的时候，再“上升一层”排除问题，直至找到了最终答案。
下面排除故障中用到了一些命令，现在你可能还不了解它们，在学习完成本书后面的一些网络设置配置命令之后，你就会发现原来这些工程师的操作也不是很神奇。
故障解决思路与步骤
客户端无法访问网络的情况在企业网络故障中应该是最常见的一种，但很多管理员在排查故障的时候，不知道从何处入手。并将这台主机搬回到原信息点后能够访问网络，这就使总部工程师首先怀疑到连接这台客户端的物理层链路出现了问题。
1．物理层检查
工程师首先要求用户检查网络客户端网络的物理连接是否正常，查看网线是否与墙上端口和设备相连，连接点是否牢靠等。用户反馈这些连接部件都是正常，所以工程师决定让用户查看交换机端口的工作状态。
由于分公司采用了标准的布线环境，交换机管理良好，有完备的《网络记录文档》。因此，总部查找到这位用户使用的墙上插座端口号为A201，而且知道A201号口与交换机2号口相连。
如果工程师在现场就可查看交换机端口的指示灯状态是否正常，但现在是不可能了。所以只能远程登录到这台交换机，利用show ip interface brief 命令查看其端口是否工作正常。
一般持续绿色代表链路正常运行，如果闪烁绿色则表明正在发送或者接收数据。
3750-24#show ip interface brief
Interface IP-Address OK？ Method Status Protocol
GigabitEthernet1/0/1 unassigned YES unset up up
GigabitEthernet1/0/2 unassigned YES unset up up
GigabitEthernet1/0/3 unassigned YES unset up up
GigabitEthernet1/0/4 unassigned YES unset up up
GigabitEthernet1/0/5 unassigned YES unset down down |
从这条命令的执行结果中看到：GigabitEthernet1/0/2状态（Status）和协议（Protocol）工作都是up状态，这证明此终端的线缆连接到交换机是正常的，初步可以排除是物理层的问题。
2．检查数据链路层
既然有连接，说明网络是通的，发生物理层错误的可能性很小，所以可以将故障排查上升一层到数据链路层。因此交换机对数据包的转发是建立在MAC地址（物理地址）基础之上的，对于IP网络协议来说，它是透明的，即交换机在转发数据包时，不知道也无须知道信源机和信宿机的IP地址，只需其物理地址，即MAC地址。
是不是我们过分相信《网络记录文档》中的接口信息了，交换机的这个接口没有真正连接到这台客户端，而是连接到其他的客户端呢？此时，可以利用第二层信息的排查来确定这个错误是否存在。第二层的关键是MAC地址，可以对照交换机接口上的MAC地址和客户端的MAC地址是否相同，这样也能排除是不是当初施工时《网络记录文档》出现了问题。使用show mac address-table interface gigabitEthernet 1/0/2 命令可以显示连接此接口计算机的MAC地址信息。
3750-24#show mac address-table interface gigabitEthernet 1/0/2
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
10 0014.2275.57ac DYNAMIC Gi1/0/2
Total Mac Addresses for this criterion: 1 |
此时在客户端上查看本机的MAC地址，如果不匹配则说明交换机上的接口并不是真的连接了这台客户端。工程师让用户在客户端上执行IPCONFIG /ALL命令，然后将MAC地址和上面的进行对比，发现MAC地址是相同的。可能在数据链路层还有其他的错误，但至少“网络记录文档”并没有欺骗我们，交换机端口和客户端主机是对应的。
3．检查网络层
接下来查看第三层。在PC上使用IPCONFIG /ALL命令进行检查，输出结果显示如下：
C:\Documents and Settings\Administrator>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : officetm1
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : gwz.edu
Ethernet adapter 本地连接:
Connection-specific DNS Suffix . : zt2.cuchina.com.cn
Description . . . . . . . . . . . : Realtek RTL8168/8111 PCI-E Gigabit Ethernet NIC
Physical Address. . . . . . . . . : 00-14-22-75-57-AC
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 10.10.2.41
Subnet Mask . . . . . . . . . . . : 255.255.255.192
Default Gateway . . . . . . . . . : 10.10.2.62
DHCP Server . . . . . . . . . . . : 10.88.56.1
DNS Servers . . . . . . . . . . . : 10.88.56.1
Primary WINS Server . . . . . . . : 10.88.56.1 |
这里，可以看到PC有IP地址，但是这地址对吗？这台PC通过DHCP获得10.88.x.x范围内的地址，但是现在地址却是10.10.x.x。
终于发现了问题，DHCP服务器分发的IP地址不属于子网。这种问题多出现在PC从某个子网挪到另一个子网时，PC依然请求旧的IP地址就产生了问题，由于这台主机从另外的办公室挪过来才出现的问题，因此可以断定问题出现在网络层。
管理员尝试这样解决问题，让PC的网络接口租用的IP地址重新交付给DHCP服务器（即归还IP地址）。使用IPCONFIG /RELEASE，然后使用IPCONFIG /RENEW命令， PC就会获得正确的IP地址，所有的网络应用就都可以使用了。