SW_MATM-4-MACFLAP_NOTIF 这种故障如何解决？

tomyung

楼主能否提供故障出现时4506,3750和销售大厅里的交换机的sh spanning-tree的输出？完全的。

tomyung

有点像STP单向链路问题

tomyung

你的帖子基本都是sh run,也没什么有说服力的地方，不如放出sh spanning-tree来看看，故障期间的，顺便加上各trunk的show interface吧

tomyung

今天晚上，我找来一台老的2950放在销售大厅的机房，然后这台设备下面只接我一台电脑，发现还是不行。还是会 ...
qdigrp 发表于 2011-01-10 18:48

根据这个情况，我认为2950的fa0/24与上游交换机的通信有问题，接收方向应该存在严重丢包情况

。理由如下：

你的45所有vlan 的pri 设为0，37所有vlan 的pri设为4096，下接的2950默认pri为32768，没有单

独设置pri的情况，所以各vlan的spanning-tree结构应该都是一样的。

当spanning-tree正常工作时，根据你提供的TOPO，

    45＝＝＝＝37
      \          /
       \       /
        \    /
         29

45应成为根，此时29会分别从连接45、37的端口上收到BPDU，经过比较收到的BPDU中的信息（path cost/发送方bridge ID等），29会选择连接45的端口(fa0/23)为root port；同理，37也会从分别连接45、29的端口收到BPDU，并选择连接45的端口为root port。

    接下来选择29与37之间线路的指定端口，通过比较收到的BPDU中的信息，最终会选择37那边的

端口为指定端口，而29那边(fa0/24)则会转为block状态。


所以vlan 16的spanning-tree是正常的。

那为何2950的vlan 1与vlan 7的spanning-tree中的fa0/24会成为指定端口，进入转发状态？
原因是2950的fa0/24没有收到相关的BPDU。

综上，建议检查29与37之间线路的连通性（最好能有show interface输出和PING测试结果）。

tomyung

回复  tomyung


    非常感谢您的分析，我是否可以这样去理解你的意思：

  1.你认为造成故障的原因 ...
qdigrp 发表于 2011-01-11 09:19

1、根据你提供的信息，我认为是的
2、整个TOPO有没有问题我不清楚，但STP从配置上来说并没发现什么问题。

对于MAC地址flapping的问题，可以这么解释：PC在以太网中或多或少都会发一些广播和多播流量，由于你的trunk没有配置vlan过滤，这些流量是会传播到所有交换机上的，正常情况下STP会形成无环结构，所以其它交换机只会从一个端口获得PC的MAC地址。如果网络中存在单向链路问题，导致原本为block的端口变为desg状态，该端口就可能传播MAC地址信息，导致相关交换机从两个端口上获得MAC地址。

我对HSRP了解的不多，但需要提醒的是在端口状态的变化过程中，会出现MAC表被清除的情况，可能这是导致HSRP震荡的原因。

tomyung

那我应该如何避免“单向链路”的发生呢？
qdigrp 发表于 2011-01-11 09:58

比起回答这个问题，我更希望看到测试结果

tomyung

回复  tomyung


    您好，我已经测了这条备用的光纤线，发现是没有问题的，请看下图！

图中是我用 ...
qdigrp 发表于 2011-01-19 14:03

    文件内容我看不到，也下载不了，问一下测试情况，这次测试是把37--29这条线断开进行独立测试的吗？