如何排除交换机端口之间的MAC震荡。 (思科)

我正在一个相当小的包含物理环路的第2层网段上工作。 (我已经包含了下面的拓扑图片)。 核心交换机堆叠3850s。 其他交换机是SG300系列小型企业交换机。

在这里输入图像说明

所有交换机之间的链接是允许vlans 1,503,508,590的中继

生成树似乎正在按预期工作,连接到SW4的SW3上的接口处于阻塞状态。

我遇到的问题是,核心交换机周期性地logging到SW1和SW2的链路之间的MAC Flap事件。

%SW_MATM-4-MACFLAP_NOTIF: Host 00eb.d5f2.0b9a in vlan 1 is flapping between port Po1 and port Po2

有问题的MAC地址似乎是思科MAC(可能分配给一个端口组?),但是我无法物理地find它所属的交换机。 当我删除循环,核心说MAC是通过Po2(到SW2的链接)可用,但是SW2表示MAC通过Po1(上行到核心)可用。

我的问题是:

  • 我怎样才能确定这个MAC地址实际上属于哪个交换机呢?

  • 什么可能导致端口之间的这种周期性襟翼?

以下是所有交换机到交换机链路的当前configuration以及每个交换机的完整mac地址表。

核心交换机接口configuration:

  interface GigabitEthernet1/1/1 description Po1 Member1 switchport trunk allowed vlan 1,503,508,590 switchport mode trunk switchport nonegotiate channel-group 1 mode active end ! interface GigabitEthernet1/1/2 description Po2 Member1 switchport trunk allowed vlan 1,503,508,590 switchport mode trunk switchport nonegotiate channel-group 2 mode active end ! interface GigabitEthernet2/1/1 description Po1 Member2 switchport trunk allowed vlan 1,503,508,590 switchport mode trunk switchport nonegotiate channel-group 1 mode active end ! interface GigabitEthernet2/1/2 description Po2 Member2 switchport trunk allowed vlan 1,503,508,590 switchport mode trunk switchport nonegotiate channel-group 2 mode active end ! interface Port-channel1 description SW1 Uplink switchport trunk allowed vlan 1,503,508,590 switchport mode trunk switchport nonegotiate end ! interface Port-channel2 description SW2 Uplink switchport trunk allowed vlan 1,503,508,590 switchport mode trunk switchport nonegotiate end 

SW1接口configuration:

  interface gigabitethernet51 channel-group 1 mode auto ! interface gigabitethernet52 channel-group 1 mode auto ! interface Port-channel1 description "Core Uplink" switchport trunk allowed vlan add 503,508,590 ! interface gigabitethernet50 description "Uplink to SW3" switchport trunk allowed vlan add 503,508,590 ! 

SW2接口configuration:

  interface gigabitethernet51 channel-group 1 mode auto ! interface gigabitethernet52 channel-group 1 mode auto ! interface Port-channel1 description "Core Uplink" switchport trunk allowed vlan add 503,508,590 ! interface gigabitethernet50 description "Uplink to SW4" switchport trunk allowed vlan add 503,508,590 ! 

SW3接口configuration:

  interface gigabitethernet49 description "UPLNK to SW4" switchport trunk allowed vlan add 503,508,590 ! interface gigabitethernet50 description "UPLINK TO SW1" switchport trunk allowed vlan add 503,508,590 ! 

SW4接口configuration:

  interface gigabitethernet49 description "UPLNK to SW3" switchport trunk allowed vlan add 503,508,590 ! interface gigabitethernet50 description "UPLINK TO SW2" switchport trunk allowed vlan add 503,508,590 ! 

核心交换机MAC表为00eb.d5f2.0b9a

 Vlan Mac Address Type Ports ---- ----------- -------- ----- 1 00eb.d5f2.0b9a DYNAMIC Po1 

SW1 MAC表00:eb:d5:f2:0b:9a

  Vlan Mac Address Port Type ------------ --------------------- ---------- ---------- 1 00:eb:d5:f2:0b:9a gi50 dynamic 

SW2 MAC表00:eb:d5:f2:0b:9a

  Vlan Mac Address Port Type ------------ --------------------- ---------- ---------- 1 00:eb:d5:f2:0b:9a Po1 dynamic 503 00:eb:d5:f2:0b:9a Po1 dynamic 508 00:eb:d5:f2:0b:9a Po1 dynamic 590 00:eb:d5:f2:0b:9a Po1 dynamic 

00:eb:d5:f2:0b:9a SW3 MAC表00:eb:d5:f2:0b:9a

  Vlan Mac Address Port Type ------------ --------------------- ---------- ---------- 

00:eb:d5:f2:0b:9a SW4 MAC表00:eb:d5:f2:0b:9a

  Vlan Mac Address Port Type ------------ --------------------- ---------- ---------- 1 00:eb:d5:f2:0b:9a gi50 dynamic 503 00:eb:d5:f2:0b:9a gi50 dynamic 508 00:eb:d5:f2:0b:9a gi50 dynamic 590 00:eb:d5:f2:0b:9a gi50 dynamic 

显示“核心交换机”的cdp nei:

 Device ID Local Intrfce Holdtme Capability Platform Port ID SW2 Gig 2/1/2 146 SI SG300-52 gi52 SW2 Gig 1/1/2 146 SI SG300-52 gi51 SW1 Gig 2/1/1 123 SI SG300-52 gi52 SW1 Gig 1/1/1 123 SI SG300-52 gi51 

在Ron Maupin的大力协助下,我能够通过遵循他最初的build议来解决这个问题。 完全禁用DTP。

SG300交换机不支持DTP,默认情况下,所有中继都以Switchport mode trunk运行。 在将线路switchport nonegotiate端口与核心端口组一起交由SW1和SW2协商后,振荡停止。

我通过再次启用DTP(通过删除switchport nonegotiate )命令testing了这个,并且返回了震荡。

我不完全明白为什么核心交换机上的DTP造成这种情况。 也许DTP帧被接入交换机转发而不是被丢弃? 如果任何人可以摆脱为什么这个修复工作,那么将不胜感激。