到了4层交换，就更加复杂了，出现了更高级的转发和负载均衡技术，故障诊断故障诊断和解决就需要更多的交换机配置知识。
在安装完一台交换机后，每个交换机的半双工端口就构成了一个冲突域。假如该端口连接了一个集线器，集线器下面连接若干站点，那么冲突域会扩大。但随着交换产品的价格下跌，现在大多数新建的网络每个交换端口都只连接一个站点。因此，在半双工连接情况下，冲突域仅针对一个单独的电缆链路。
交换机通常是一个独立广播域的一部分，包括串连或者并连的任意数目的其他交换机。假如使用了OSI模型3层的功能，就可以创建多广播域，广播域的数目与VLAN数目相等。最极限的情况，假如交换机功能答应，每个端口可以配置为一个独立的广播域。可以把这种情况描述为路由到桌面。为每个端口创建一个独立的广播域后，故障诊断就会严格受限。但是假如我们把每个端口设置为一个单独的广播域，交换机在转发流量的时候，每个端口都需要路由服务，这会占用交换机CPU的有限资源。在网络环境中，对每个单独的端口进行路由请求和应答是非常困难的，我们应该避免这样的配置。不幸的是，这种情况在实际情况中非经常见，网络中经常发现服务器全部在一个子网或者广播域中，所有的客户在另外的子网或者广播域中。在这种情况下，所有的请求都必须路由。假如维护行为限制在一个单独的服务器群里，那么考虑把服务器放进单独的VLAN里。然后把使用这台服务器的用户放到同一个VLAN。这样就可以使用2层交换的桥接方式来交换流量，只有很少的请求需要路由。假如服务器支撑多于一个用户区，可以在服务器上多装一块网卡来实现到用户的2层交换连接。
对交换机进行故障诊断的5种技术
可以采取5种基本方式来透视交换机。每一种方法都不同，都有积极或者消极的一面。类似在网络中碰到的其他问题一样，没有一个最好的答案。最合适的方案往往取决于您手中可以利用到的资源（什么工具可以使用或者以前安装过什么工具），而且使用这些技术有可能造成服务中断。
即使把这些方式组合起来，也不能监测到所连接的网络，在交换的环境里面，也不像集线器那样方便监测。我们几乎不可能看到通过一个交换机的全部流量。大多数的故障诊断会假设流量会在站点和所连接的服务器之间或经过故障诊断交换机uplink口通过。而实际上假如2台主机直接传输信息的话，就不会使用交换机的uplink口或者任何其他的端口来交换流量。除非你知道具体用到哪个端口，否则是监测不到的。
举个例子，如图1，一台服务器接入一台交换机。在反映有问题的用户中，一部分是直接与这台交换机相连，另外的一部分用户是由这台交换机的uplink口从其他路由器或者交换机连接上来的。故障报告是访问服务器“慢”，这样的故障报告对技术支持工程师来说基本上没有任何价值。
图一、一个最基本的交换机环境
方法1：通过TELNET或者串行口接入服务器
高级的网络技术支持工程师或其他知道交换机密码的人在进行故障诊断时可以选择通过TELENET或者交换机的串口登陆，来检查交换机的配置。（如图2）
图 2、使用RS-232 控制端口
交换机配置可以通过上面提到的2种方法查看，虽然问题不一定是配置引起的。不管问题是操作系统有BUG还是配置不完善，都不能从配置列表中轻易的查看出。配置信息在定位交换机是否像预期的那样运行上比较有用，但针对故障诊断就不是了。为了验证交换机的配置，往往需要使用多种的交换机故障诊断方法配合。
很多交换机都带有实时的故障诊断工具，因为交换机生产厂家和型号的不同，这些故障解决工具的特征也各不相同。但是要使用好这些工具，必须依靠一定的理论知识和实际经验。
方法2：连接到一个空闲端口
最简单的故障诊断方法是在交换机的空闲端口接入一个监测工具，例如协议分析仪。
图3、从任意端口监测
把监测工具接入交换机的一个空闲端口，不用中断服务就可以查看所属广播域。该监测工具与广播域里的其他站点一样有相同的权限。
不幸的是，交换机（做为一个多端口的桥接设备）几乎不转发流量到监测端口。因为桥接设备就是这样设计的，流量直转发到所属的目的端口，不会去其他的端口。协议分析仪因此几乎监测不到流量。
图4、交换机在源端口和目的端口之间转发流量
非常少的流量会转到其他端口。站点和服务器之间可能每秒钟会转发几千个帧，但是监测端口每分钟只能看到几个帧。
转发到监测端口的流量几乎全部都是广播，包含一些零星的目的地址不明的帧。这些零星的帧是由于路由转发表老化的结果，经常是目的端口不明的帧。一些经验不够的技术人员看到这么高的广播（接近100％），却没有注重到端口利用率很低，就误判网络出现了广播风暴，其实不是。
这样查看交换网络几乎没有用，因为监测工具必须获取流量。获得的流量或者对广播域的查询对网络搜索和发现其他类型问题是有很有帮助的，但对解决用户连接慢的问题并没有多大的帮助。
