交换机出现环路的原因
发布网友
发布时间：2022-03-30 00:09
共4个回答
懂视网
时间：2022-03-30 04:30
网络环路检查的方法如下：
1、了解网络的拓扑结构
设备维护人员到现场后，首先要知道或试图了解现场网络的拓扑结构。简单的说，要知道电脑是连的哪个HUB，HUB是连到机房哪台接入层交换机上，而接入层交换机又是如何与汇聚层交换相连的。
2、缩小排查范围
无论是何种拓扑结构，都应先用笔记本直连汇聚层或核心层交换机，测试网络是否正常以排除汇聚层或核心层交换机本身的故障导致的问题。
3、找出有环路的端口
当通过上述方法找到有环路的交换机后，想要找出哪个端口有环路就变得简单了。具体方法是：先给交换机断电然后再接上电源，认真观察每个端口的亮灯情况，一般要等待1分钟左右端口灯才开始闪烁，一定要观察到第一个开始快速闪烁的端口，那个端口就是有环路的端口，如果没有看清楚，重新断电后再进行观察。
4、排除故障
找出有环路的端口后，可以直接将这个端口的网线拔出，然后测试网络是否正常，网络正常后故障就被排除了。最后只要找到这个端口对应的房间将接了环路的HUB找到把网线连接正确就可以了。
热心网友
时间：2022-03-30 01:38
数据在交换机里产生环路主要是由于物理上（或者逻辑上）在在线路环路造成的，在局域网中，数据包的发送是由MAC地址来决定最终发送方向的。
对于HUB或者不支持STP的交换机，如果线路中存环路，例如两台HUBA，B的端口1，10形成一个环路，则对于每台HUB的1，10端口都有对方和自己的MAC地址表，
当AUB的一台机器发送数据到另外一台机器时，这些数据将在1，10端口上被发送，B HUB收到数据后，又会在10，1端口再次发送这些数据，而A HUB收到数据后，也会在1，10端口上发送数据，造成数据不停的在两台HUB之间反弹，最终因超时被丢弃。
一般来说，目前使用的交换机都支持STP，在STP的支持下，交换机会自己察觉环路的形成，并切断环路的一端，保证网络的正常运行。
扩展资料：
判断网络环路的思路：
由于大部分交换机几乎都支持端口环回监测功能，巧妙地利用该功能，就能让交换机自动判断出指定通信端口中是否发生了网络环路现象。
一旦在指定的以太网通信端口上启用环回监测功能后，交换机设备就能自动定时对所有通信端口进行扫描监测，以便判断通信端口是否存在网络环路现象。
要是监测到某个交换端口被网络环回时，该交换端口就会自动处于环回监测状态。
依照交换端口参数设置以及端口类型的不同，交换机就会自动将指定交换端口关闭掉或者自动上报对应端口的日志信息，日后只要查看日志信息或根据端口的启用状态，就能快速判断出局域网中是否存在网络环路现象了。
参考资料来源：百度百科--交换机环路
热心网友
时间：2022-03-30 02:56
一起典型的网络环路故障，用协议分析工具Sniffer抓了这么多的数据包，经过一番分析却没看出问题来。显然，第一眼看到大量的SYN包让我们产生了错觉，想当然地就以为是SYN Flood攻击。事后，我们就这起网络环路故障排除过程做了检讨，重新仔细地分析抓回来的这些数据包，据此解释一下前面提到这些数据包所具有的5个共同特征，以便今后遇到同类问题时能及时作出正确的反应。
先看前4个特征：汇聚交换机是网络层设备，该大楼所属VLAN的网络层接口就设置在这台汇聚交换机上，出于实施网络管理策略的需要，对已注册或没注册的 IP地址都进行了MAC地址的绑定。TCP连接要经过3次握手才能建立起来，在这里发起连接的SYN包长度为28个字节，加上14个字节的以太帧头部和 20个字节的IP报头，由Sniffer捕获到的帧长度共为62个字节（不包含4字节的差错检测FCS域）。恰巧当时访问该VLAN的单播帧是来自*的 TCP请求包，根据以太网桥的转发机制，通过CRC正确性检测后，因已做静态ARP配置，这台汇聚交换机会将该单播帧的源MAC地址转换成本机的MAC地址，其目的MAC地址依据绑定参数来更换，并重新计算CRC值，更新FCS域，经过这样重新封装后，再转发到那栋楼的接入交换机。
再看最后1个特征：网桥是一种存储转发设备，用来连接相似的局域网。这些网桥在所有端口上监听着传送过来的每一个数据帧，利用桥接表作为该数据帧的转发依据。桥接表是MAC地址和用于到达该地址的端口号的一个“MAC地址－端口号”列表，它利用数据帧的源MAC地址和接收该帧的端口号来刷新。网桥是这样来使用桥接表的：当网桥从一个端口接收到一个数据帧时，会先刷新桥接表，再在其桥接表中查找该帧的目的MAC地址。如果找到，就会从对应这个MAC地址的端口转发该帧（如果这个转发端口与接收端口是相同，就会丢弃该帧）。
如果找不到，就会向除了接收端口以外的其他端口转发该帧，即广播该帧。这里假定在整个转发过程中，网桥A、B、C和D都在其桥接表中查找不到该数据帧的目的MAC地址，即这些网桥都不知道应该从哪个端口转发该帧。当网桥A从上联端口接收到一个来自上游网络的单播帧时，会广播该帧，网桥B、C收到后也会广播该帧，网桥D收到分别来自网桥B、C的这个单播帧，并分别经网桥C、B传送回网桥 A，到此网桥A收到了该单播帧的两个副本。
在这样的循环转发过程中，网桥A不停地在不同端口（这时已经不涉及上联端口了）接收到相同的帧，由于接收端口在改变，桥接表也在改变“源MAC－端口号”的列表内容。前面已经假定网桥的桥接表中没有该帧的目的MAC地址，网桥A在分别收到这两个单播帧后，都只能再次向除了接收端口以外的其他端口广播该帧，故该帧也会向上联端口转发。
就每个单播帧而言，网桥A重复前面提到的过程，理论上，广播一次会收到21个帧，广播两次就会收到22个帧，…，广播到第n次就会收到2n个帧。总之，网桥A照这样转发下去，很快就会形成广播风暴，这个单播帧的副本最终会消耗完100BASE-X端口带宽。尽管在这期间上联端口会有许多数据帧在相互碰撞而变的不完整，令Sniffer捕获不到，但可以想象得到这个单播帧的重复出现次数仍然会非常多。我们再次检查那些抓回来的数据包，几乎都发现有当时没有注意到的重复标志。按64字节包长来计算，以太网交换机的100BASE-FX端口转发线速可达144000pps。在这种网络环路状态下， Sniffer完全有可能每秒抓到10万多个包长为66字节的数据包。
基于上述理由，由于当时那4台交换机的桥接表中都没有该包的目的MAC地址，处于上游网络的这台汇聚交换机向该大楼发送了一个TCP请求包后，就会不断地收到由该大楼接入交换机转发回来的该TCP包的副本，而且数量非常地多（形成大流量），然而，它并不会把接收到的这些包重发回去；Internet 的网络应用是基于请求/应答模式的，只有发送/接收两条信道都畅通，才能进行端到端的通信。
一旦本次网络应用中有一条信道被堵塞了，就会使得该应用因无法进行而结束。网络应用结束后，一般来说，发起请求一方不会就本次应用再次自动发出请求包。于是，在网络环路状态中普遍会有一条信道有大流量，另一条信道几乎没有流量的现象。因为VLAN有隔离广播域的功能，这些大流量不会穿越网络层，所以不会对汇聚交换机造成很大压力。
事实上，由于这种网络环路是数据链路层上的故障，只涉及到源MAC地址和目的MAC地址，不管高层封装的是什么类型的包都有可能引起广播风暴。也就是说，当时用Sniffer抓到各种各样的数据包都是有可能的。
故障预防
校园网的接入层是面向用户的网络界面，有许多不可控的成分，情况很复杂，应由专人管理，也应在设备上给予可靠性保证。本搂接入交换机是可管理型的，有STP功能，其他交换机都是非管理型交换机，没有STP功能。本来事先在该接入交换机上配置了STP功能，这起网络事故是完全可以避免的，但不知何故没有这样做，事后再做只能权当“亡羊补牢”了。
由此可见，即使接入交换机打开了STP功能，下游网络也会因某种原因构成环路，产生广播风暴，造成对上游网络本VLAN的冲击，故该接入交换机还应有广播包抑制功能，以便能将影响*在局部范围内。对于下游网络的交换机同样有这些需求，只是成本问题而已。一句话，在网络故障排除时，技术和经验固然重要，但在平时就要注意维护网络的规范连接、落实基本的防范措施更为重要。
热心网友
时间：2022-03-30 04:48
