在网络中安装新交换机期间发生奇怪的泛洪

网络工程 思科 转变 生成树 cisco-nexus 洪水
2021-07-13 23:13:33

这是我注意到的非常奇怪的问题。在我们的数据中心,机架中的每个交换机都配置了 cisco vPC,整个数据中心运行 vPC,因此在任何时间段都没有生成树的循环。

但是我注意到一个我之前忽略的问题,当我将全新的 TOR 交换机插入机架并连接到配电交换机时,一旦我启动 vPC,它就会像镜像流量一样在网络中泛滥流量。

我在其中一个节点上设置了 tcpdump 并在控制台上观看实时数据包流,一旦我配置了 vPC,我就注意到屏幕上的泛滥非常高,简而言之,我可以看到该主机 tcpdump 命令上的每个主机流量。就像每台机器向该主机发送流量一样,它在任何地方都发生,而不仅仅是单个主机(泛滥的持续时间不到 10 秒)。

你们怎么看待这种行为,是正常的还是我应该深入?

更新 - 1

在此处输入图片说明

  • 我们有非常基本的 vPC 配置(我们没有使用 FEX)
  • TOR 交换机为 N3K,配电交换机为 N9K

[配电开关]

专有网络配置

vpc domain 4
  peer-switch
  role priority 10
  peer-keepalive destination 10.10.10.2 source 10.10.10.1
  auto-recovery
  ip arp synchronize

VPC 对等链路端口通道

interface port-channel999
  description *** vPC Peer-Link ***
  switchport mode trunk
  switchport trunk allowed vlan 10-11,20-21,28-31,40,50,100,200
  spanning-tree port type network
  speed 40000
  no negotiate auto
  vpc peer-link

连接到 TOR 交换机的链路

interface port-channel403
  switchport mode trunk
  switchport trunk allowed vlan 10-11,20-21,28-31,40,50,100,200
  speed 40000
  mtu 9216
  no negotiate auto
  vpc 403

[ TOR 开关 ]

vpc domain 403
  role priority 10
  peer-keepalive destination 172.29.30.11 source 172.29.30.10
  auto-recovery

vPC 对等链路端口

interface port-channel999
  description *** vPC Peer-Link ***
  switchport mode trunk
  switchport trunk allowed vlan 10-11,20-21,28-31,40,50,100,200
  spanning-tree port type network
  speed 40000
  vpc peer-link

中继连接到分布交换机

interface port-channel3
  switchport mode trunk
  switchport trunk allowed vlan 10-11,20-21,28-31,40,50,100,200
  speed 40000
  vpc 3

编辑 - 1

我有两种类型的服务器,有些服务器配置了 vPC 的绑定,有些服务器没有配置绑定,我可以告诉你我看到这些服务器上的这种行为没有配置绑定。

上图中服务器有两个网卡,

  • nic1 配置 VLAN 标记以运行多个 VLAN
  • nic2 为 SR-IOV 配置(此服务器是 openstack 计算节点)

我看到大量流量涌来,nic1 但没有nic2

更新 - 2

我们在数据中心有 48 个机架,每个机架有两个上面描述的 TOR 交换机,我们有两个主机配置。

  1. 绑定主机(这些主机是普通的应用程序主机) - ** 不是 ** 获取 etherror
  2. 非绑定主机(使用 SR-IOV 的 openstack 计算节点,因为 SR-IOV 不支持绑定) - 获取 Etherror

我在openstack计算节点位于机架中的任何地方都看到了这个错误,所以它无处不在,而不是特定的机架或主机,感觉就像当时 openstack 主机看到所有流量来到它们一样......就像你向主机发送不需要的流量一样。

很明显,这仅发生在非绑定服务器orphen端口上,因为其他具有绑定配置的主机没有看到这种洪水。

更新 - 3

分布(连接到核心的一个是所有 VLAN 的 ROOT 网桥)

显示生成树 vlan 200

VLAN0200
  Spanning tree enabled protocol rstp
  Root ID    Priority    32968
             Address     0023.04ee.be01
             This bridge is the root
             Hello Time  2  sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32968  (priority 32768 sys-id-ext 200)
             Address     0023.04ee.be01
             Hello Time  2  sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Po23             Desg FWD 1         128.4118 (vPC) P2p
Po24             Desg FWD 1         128.4119 (vPC) P2p

TOR 开关 (N3K)

  VLAN0200
      Spanning tree enabled protocol rstp
      Root ID    Priority    32968
                 Address     0023.04ee.be01
                 Cost        2
                 Port        4110 (port-channel15)
                 Hello Time  2  sec  Max Age 20 sec  Forward Delay 15 sec

      Bridge ID  Priority    32968  (priority 32768 sys-id-ext 200)
                 Address     0023.04ee.be73
                 Hello Time  2  sec  Max Age 20 sec  Forward Delay 15 sec

    Interface        Role Sts Cost      Prio.Nbr Type
    ---------------- ---- --- --------- -------- --------------------------------
    Po15             Root FWD 1         128.4110 (vPC) P2p
    Po131            Desg FWD 1         128.4226 (vPC) Edge P2p
    Po136            Desg FWD 1         128.4231 (vPC) Edge P2p
    Po999            Desg FWD 1         128.5094 (vPC peer-link) Network P2p
    Eth1/12          Desg FWD 2         128.12   Edge P2p
    Eth1/13          Desg FWD 2         128.13   Edge P2p

N3K vPC 连接到服务器

interface port-channel129
  switchport mode trunk
  switchport trunk native vlan 40
  switchport trunk allowed vlan 10-11,20-21,28-31,40,50,100,200
  spanning-tree port type edge trunk
  spanning-tree bpduguard enable
  speed 10000
  vpc 129

我在交换机端保留了 vPC 配置,但没有在服务器端配置绑定,所以简而言之,在交换机上显示 vPC 已关闭并且绑定已关闭,原因我没有这样做,因为我想如果明天我需要绑定我不不需要重新配置开关..

1个回答

我想我在另一个线程中设置了这个答案的路径,我花了一些时间来完成它。

...当非 portfast 端口(无论是单个端口还是端口通道)变为“FWD”时,生成树拓扑更改通知将贯穿相关生成树。

请参阅文档的这一部分:了解生成树协议拓扑更改

简而言之:TopologyChangeNotification 是由刚刚让端口进入 FWD 模式的网桥发送的。该 TCN 被根网桥通过 TopologyChangeAcknowledgement 确认。

然后根桥在相关生成树上泛洪 TC BPDU

反过来,这会导致网桥缩短(从 300 秒到 forward_delay)其 CAM 计时器并从其 MAC 地址表中清除大量地址。

这会导致未知的单播泛洪泛滥。,我相信这就是你所看到的

对此你能做些什么呢?

  • 绝对确保您的所有边缘端口都有 portfast 或 portfast 中继。您在另一个线程中询问的方式让我相信,对于面向主机的端口通道而言,情况并非如此。

  • (重新)考虑生成树域的大小。

插件

实际上,对于 RSTP,与 TC 的情况略有不同,但基本原理仍然存在:拓扑更改 BPDU 会导致交换机刷新其 CAM 表(部分),从而导致未知单播泛洪的激增。

http://www.hackandtinker.net/2015/02/19/spanning-tree-protocol-pvstrapid-pvstmst/

RSTP 仍然保留 TCN 的概念,就像传统的 STP 一样。但是,不是将 TCN 发送到根网桥(STP 之所以这样做,是因为非网桥实际上没有办法将更改传达给其他网桥,而无需要求根代表它们执行这些通知),交换机将立即泛洪设置了 TC 标志的 BPDU。任何发送或接收这些设置了 TC 位的 BPDU 的交换机都会设置一个 tcWhile 定时器,它是 hello 定时器加一秒。然后它立即泛洪在非边缘指定端口和根端口上学习的所有 MAC。然后它发送设置了 TC 标志的 BPDU,并重复该过程,快速通知拓扑中的所有交换机发生了变化。

另见此处:https : //www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24062-146.html#anc20

当网桥从邻居收到设置了 TC 位的 BPDU 时,会发生以下情况:

它清除在其所有端口上学习的 MAC 地址,除了接收拓扑更改的端口。

它启动 TC While 计时器,并在其所有指定端口和根端口上发送设置了 TC 的 BPDU(RSTP 不再使用特定的 TCN BPDU,除非需要通知传统网桥)。

[Addon-2:](评论后)

我仍然相信您有一个与主机相关的问题,因为非 portfast边缘端口(很可能是主机的端口或端口通道)进入 FWD 模式,然后触发其交换机泛洪拓扑更改 BPDU,进而触发未知的单播泛滥。

switchport block unicast在这个阶段采取措施是在找到和确认实际原因之前对抗症状 - 这不是好的工程实践。

您还需要评估未知单播洪水阻塞在您的环境中的后果。它实际上可能对一些相当安静的终端系统有害,使其在很长一段时间内无法被同行访问。一旦他们的 CAM 条目过期,而他们对等方的 ARP 缓存条目仍然有效(例如,路由器的默认 ARP 超时为 4 小时),他们对等方的单播尝试将必须是被交换机淹没的未知单播。尽管如此,由于 UUF 阻塞,这些数据包不会到达终端系统,因此终端系统不会听到这些帧,也不会对它们做出反应。因为他们保持沉默,他们所连接的交换机无法(重新)学习他们的 MAC 地址,并将继续使用他们听不到的 DstMAC 地址单播泛洪数据包......

所以:您首先要检查您的生成树中是否确实有 TCN,以及它们来自 ( show spanning-tree vlan XXX detail | include "VLAN|change|from" ) 的时间和地点

switch# show spanning-tree vlan 5 detail | include "VLAN|topo|from"
 VLAN0005 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 1 last change occurred 1979:48:37 ago
          from port-channel1133
  Times:  hold 1, topology change 35, notification 2
  Timers: hello 0, topology change 0, notification 0
 Port 4295 (port-channel200, vPC Peer-link) of VLAN0005 is designated forwarding 
 Port 5226 (port-channel1131, vPC) of VLAN0005 is root forwarding 
 Port 5228 (port-channel1133, vPC) of VLAN0005 is designated forwarding

在洪水事件之后,从根向下递归这个调查,看看 TCN 来自哪里。如果它引导您进入 ToR 交换机,那么很有可能它一定是主机的非 portfast 端口进入 FWD 模式。检查给定的 ToR 交换机链路启动/线路协议启动事件。

除此之外,如果您向网络添加新的 ToR 交换机,拓扑更改是完全正常的,因为上游交换机将不可避免地将下行链路端口/端口通道(不得是边缘端口)连接到新交换机前驱模式。

[/Addon-2:]