什么是核心交换机?核心交换机配置标准

可是，在实际工作过程中，交换机的状态很容易受到外界的干扰，那样一来局域网中就会出现各种各样的 *** 故障；为了保证 *** 运行稳定，我们必须在平时对交换机进行妥善管理、维护，避免交换机发生故障。这不，笔者在对单位局域网进行维护时，曾经遇到过物理连接不当，而造成楼层交换机无法ping通的故障现象。这种 *** 故障的排查让笔者颇费一番周折；由于该故障相对典型，而且其排查思路可供借鉴，现在笔者就将它贡献出来与大家分享。案发现场笔者所在的大楼包含若干个单位，为了保证每个单位都能独立上网，并且要求它们的上网状态不受其他单位的影响，笔者选用了路由交换机作为大楼 *** 的核心交换机，同时在交换机上对每个单位设置了不同的虚拟工作子网。由于各家单位分布在不同的楼层，每个楼层分布的单位家数也不完全相同，有的楼层有两、三家单位，有的楼层多达五、六家单位，不同楼层的单位工作子网全部通过对应楼层的交换机，连接到大楼局域网中，并通过大楼 *** 中的硬件防火墙访问Internet *** 。为了提高 *** 管理效率， *** 管理员平时都会通过远程连接方式对交换机进行管理、维护；可是，今天早上一上班，笔者在扫描诊断局域网核心交换机各个交换端口的工作状态时，发现其中某个交换端口处于down状态。查看 *** 管理档案，找到连接该端口的是四楼某二层交换机，远程登录该楼层交换机时，发现迟迟无法登录成功，使用ping命令测试该交换机的IP地址时，返回的结果为“Request time out”；就在笔者纳闷为什么没有人报故障时， *** *** 如期而至，果然来自四楼的用户开始接二连三地报修 *** 故障了。根据上述故障现象，笔者估计可能是楼层交换机的工作状态出现了意外，于是跑到该故障交换机现场，切断该设备的电源，过一段时间后再次接通电源，进行重新启动，等到启动操作完毕后，笔者又使用了ping命令测试该交换机的IP地址，此时返回的结果已经正常，而且远程登录操作也能够很顺利地进行。然而，半个小时之后，该故障交换机又出现了相同的故障现象，并且进行ping命令测试时，又返回了不正常的测试结果；后来笔者不放心，又重新经过反复启动测试，发现故障交换机始终无法正常ping通。深入排查既然经过反复重启不能解决问题，笔者估计引起该故障的原因比较复杂，考虑到这种故障现象在 *** 管理过程中经常会碰到，于是笔者按照下面的思路进行了深入排查：1、考虑到整个大楼 *** 中，只有四楼的某个楼层交换机出现这种现象，笔者初步判断可能是该楼层交换机自身问题引起的，为了能够确保可以准确定位故障原因，笔者准备利用一台工作状态正常的交换机来替换故障交换机，看看故障现象是否仍然存在；同时，将那台被怀疑可能存在问题的交换机连接到一个独立的 *** 工作环境，经过半个小时的测试、观察，笔者看到那台被连接到独立 *** 环境的故障交换机工作状态是正常的，而且在该 *** 环境下可以ping通它的IP地址，而那台新替换的交换机连接到大楼 *** 后，却不能正常ping通了；依照这些现象，笔者认为四楼的交换机自身出现问题的可能性几乎没有。2、在排除了故障交换机自身状态因素后，笔者对整个大楼 *** 的组网结构和 *** 状态重新进行了回顾。由于大楼中其他楼层的用户都能正常上网，唯独四楼的一部分用户不能上网；查阅四楼的组网资料，笔者看到四楼分布了五家单位，当时 *** 管理员在四楼布置了两台楼层交换机，将它们通过级联方式连接在一起，同时在这两台交换机中划分了五个虚拟工作子网，保证了每家单位都能独立地工作于自己的虚拟工作子网中。既然核心交换机上的对应端口已经被down掉，那么整个四楼的所有单位都不能上网才对，为什么现在只有一部分用户上报故障现象呢？等到上班时间一到，笔者立即 *** 联系其他几家没有报修 *** 故障的单位，得到的答复说他们刚刚才发现 *** 访问不正常，正准备向大楼 *** 管理员求救，如此说来整个四楼的所有单位都是不能正常上网的，那么引起该故障的原因应该在这几家单位的虚拟工作子网中。3、在将故障排查范围锁定在位于四楼的五家单位之后，笔者认为既然重新启动四楼某个交换机的设备，能够暂时地将 *** 故障恢复，只是在半个小时之后，相同的 *** 故障现象才会再次现象；对照这种特殊的现象，笔者怀疑可能是 *** 广播风暴，造成了交换机在一定时间内发生了堵塞现象，最终堵死了核心交换机的对应交换端口。为了便于分析故障，笔者利用专业的 *** 监听工具对四楼交换机的级联端口进行了 *** 传输数据包分析，结果发现无论是输入数据包流量，还是输出数据包流量，都非常地大，几乎超过了正常数值的100倍左右，这说明四楼的 *** 中出现了 *** 堵塞现象。4、那么究竟是 *** 病毒引起的 *** 堵塞，还是 *** 环路引起的 *** 堵塞呢？笔者打算观察一下故障交换机级联端口的状态信息变化，特别是输出广播包的变化，如果输出广播包每秒钟都在不停增大的话，那十有八九就能证明四楼 *** 中存在 *** 环路现象；基于这样的分析思路，笔者使用Console控制线直接连接到故障交换机上，以系统管理员身份登录进入该系统后台，同时使用display命令查看了该交换机级联端口的输出广播包的变化，并且每隔一秒钟查看一次，之后比较每次查看的结果，经过反复测试，笔者发现故障交换机的输出广播包大小果然在不断地增大着，这说明四楼的五家单位中，肯定存在 *** 环路现象。5、仔细查看了四楼的两台交换机，笔者发现它们之间的物理连接是正常的；此外，这两台交换机的各个交换端口直接与四楼各个房间的墙上上网插口相连，按理来说，只要各个房间不随意使用交换机进行级联，应该不会出现 *** 环路现象的。现在既然证明四楼 *** 中存在 *** 环路现象，这说明肯定有人在随意使用交换机进行扩展上网，我们只要找到扩展交换机，并对它的物理连接进行检查，就能迅速找到具体的故障节点了，于是笔者 *** 联系四楼各家单位的 *** 管理员，要求他们对各个办公房间进行检查，并上报使用下级交换机的房间；没有多长时间，检查结果就反馈给了笔者，竟然有10个左右的房间使用了下级交换机进行扩展上网。

6、笔者深知这10个房间的 *** 连接，最有可能出现 *** 环路现象，那究竟是哪一个房间呢？难道笔者依次要到各个房间的现场，查看他们的 *** 连接吗？经过认真考虑，笔者找来了组网资料，将这10个房间使用的交换端口号码一一找了出来，之后使用 *** 线缆直接插入到这些交换端口中，并在这些端口的视图模式状态下，依次ping故障交换机的IP地址，结果ping到第六个交换端口时，笔者发现从该端口无法正常ping通；为了判断该交换端口是否真的存在问题，笔者又在该交换端口视图模式状态下，使用display命令查看了该交换端口的状态信息，经过查看分析，笔者发现该交换端口的输入、输出数据包大小明显不正常，于是笔者估计该交换端口肯定是造成故障交换机工作状态不正常的原因。查阅档案资料后，笔者迅速根据那个交换端口号码，找到了对应的那个上网房间，到了现场后，笔者发现该房间中仅有的两个上网端口，都连接了小集线器，而这两台集线器下面都连接有几台计算机，更要命的是还有一条 *** 线将它们直接连接在了一起，这样一来这两个集线器之间就形成了一个 *** 环路，该环路造成的广播风暴最终堵塞了故障交换机的级联端口，从而造成了整个四楼 *** 都不能正常上网。