局域网交换 : 生成树协议

了解生成树协议拓扑变化

2015 年 8 月 28 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 4 月 22 日) | 反馈


交互:本文档对您的 Cisco 设备进行自定义分析。


目录


简介

当您监控生成树协议操作时,您会关系到,当您看到在统计信息日志增加的拓扑修改计数器时。STP 中的拓扑更改是正常的。但是,太多他们能有在网络性能的一影响。本文档介绍了此拓扑的以下用途:

  • 更改每 VLAN 生成树 (PVST) 和 PVST+ 环境的机制。

  • 确定是什么触发了拓扑更改事件。

  • 描述与拓扑更改机制有关的问题。

先决条件

要求

本文档没有任何特定的要求。

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您使用的是真实网络,请确保您已经了解所有命令的潜在影响。

规则

有关文档规则的详细信息,请参阅 Cisco 技术提示规则

拓扑更改机制的用途

从所接收的帧了解到,网桥可以创建与端口相关联的表,通过此端口可以到达主机的介质访问控制 (MAC) 地址。此表用于将帧直接转发到其目标端口。因此,避免了泛洪。

此表的默认老化时间是 300 秒(5 分钟)。只有在主机静默 5 分钟之后,其条目才从网桥表中消失。以下示例显示您可能希望此老化更快的原因:

在此网络中,假设网桥 B1 阻塞了通向 B4 的链路。A 和 B 是具有已建立连接的两个工作站。流量从 A 到 B 进入 B1、B2、B3,然后进入 B4。此方案显示在此情况下通过四个网桥获取的 MAC 地址表:

17a.gif

现在,假设 B2 和 B3 之间的链路发生故障。至少在 B1 以转发模式将其端口应用于 B4 之前,A 和 B 之间的通信会中断(使用默认参数的情况下最长中断 50 秒)。但是,当 A 要向 B 发送帧时,B1 仍然具有通往 B2 的条目,数据包将被发送到黑洞。当B要到达A. Communication丢失在五分钟,直到A和B MAC地址的条目老化,同样应用。

/image/gif/paws/12013/17b.gif

网桥实现的转发数据库在稳定网络中非常有效。但是,有五分钟过期时间问题的许多情况,在网络的拓扑更改后。拓扑更改机制是解决此类问题的一种方法。只要网桥检测到网络拓扑中的更改(链路断开或准备转发),就向整个桥接网络通告此事件。

操作原理部分解释了实际实现的方式。随后通知每个网桥,并将某时间段 (max_age + forward_delay) 的老化时间缩短到 forward_delay(默认为 15 秒)。这更有利于缩短老化时间而不是清除表,因为当前处于活动状态的主机(用于有效传送流量)没有从表中清除。

在本示例中,只要网桥 B2 或 B3 检测到链路断开,就会发送拓扑更改通知。所有网桥都注意到此事件并将其老化时间缩短到 15 秒。由于 B1 在其通往 B2 的端口上 15 秒内没有收到来自 B 的任何数据包,因此 B 的条目在该端口上老化。在 B4 上通往 B3 的端口上,A 的条目也会发生同样的情况。以后,当 B1 和 B4 之间的链路进行转发时,该链路上的流量将立即泛洪并重新获取。

操作 原理

本部分说明在网桥协议数据单元 (BPDU) 级别网桥如何通告拓扑更改。

当网桥认为它检测到拓扑更改时,已进行了简要说明。确切的定义是:

  • 当转发的端口断开时(例如阻塞)。

  • 当端口转换为转发模式并且网桥具有指定端口时。(这表示网桥不是独立的。)

向网络中的所有网桥发送通知的过程包括两个步骤:

  • 网桥通知生成树的根网桥。

  • 根网桥将该信息“广播”到整个网络。

通知根网桥

在常规 STP 操作中,网桥一直从其根端口上的根网桥接收配置 BPDU。但是,它从未派出BPDU往根网桥。为此,引入了称为拓扑更改通知 (TCN) BPDU 的特殊 BPDU。因此,当网桥需要对拓扑更改发出信号时,它开始在其根端口上发送 TCN。指定的网桥接收并确认 TCN,还为自己的根端口生成另一个 TCN。此过程将一直持续,直到 TCN 发现根网桥为止。

/image/gif/paws/12013/17c.gif

TCN 是非常简单的 BPDU,不包含网桥每 hello_time 秒(这是本地配置的 hello_time,不是配置 BPDU 中指定的 hello_time)发送的任何信息。指定的网桥通过立即发回设置了拓扑更改确认 (TCA) 位的正常配置 BPDU 来确认 TCN。通知拓扑更改的网桥不停地发送其 TCN,直到指定的网桥确认它为止。因此,指定的网桥将应答 TCN,即使不从其根网桥接收配置 BPDU 也是如此。

将事件广播到网络

只要根网桥得知网络中有拓扑更改事件,就会开始发送设置了拓扑更改 (TC) 位的配置 BPDU。这些 BPDU 将由网络中设置了此位的每个网桥转发。因此,所有网桥都注意到拓扑更改情况,并可以将其老化时间缩短到 forward_delay。网桥在转发和阻塞端口上接收拓扑更改 BPDU。

TC 位在 max_age + forward_delay 秒(默认情况下为 20+15=35 秒)内由根网桥设置。

17d.gif

网络中有很多拓扑更改时该怎么办

以下是一些可能由 TCN 生成的问题。随后是如何限制拓扑更改和从生成处查找的一些信息。

如果从 Cisco 设备得到 show-tech support 命令的输出,可以使用命令输出解释程序仅限注册用户)显示潜在的问题和解决方法。要使用命令输出解释程序仅限注册用户),您必须是注册客户,并且必须登录,还要启用 JavaScript。

泛洪的流量

网络中的主机越多,获取拓扑更改的可能性就越高。例如,重新通电时直接连接的主机将触发拓扑更改。在非常大型(和平面)的网络中,可以实现网络永远处于拓扑更改的状态。这就像是将老化时间配置为 15 秒,从而导致高级别的泛洪。以下正在进行服务器备份的客户发生的最坏情况。

17e.gif

接收备份的设备的条目老化是一种灾难,因为它会导致非常大的流量,从而影响所有用户。请参阅与portfast命令部分的避免生成TCN关于如何避免生成TCN的更多信息。

ATM LANE 桥接环境中的问题

此情况比快速老化隐含的正常流量的泛洪更重要。收到 VLAN 的拓扑更改后,Catalyst 交换机使用其 LAN 仿真 (LANE) 刀片对相应的仿真 LAN (ELAN) 再次确认其 LE-arp 表。由于 ELAN 中的每个 LANE 刀片在相同的时间发出相同的请求,因此如果有许多条目需要再次确认,则可能会增加 LAN 仿真服务器 (LES) 的压力。此方案包括连接性问题。如果网络对拓扑更改很敏感,则真正的问题不是拓扑更改本身,而是网络的设计。建议您尽量限制 TCN 生成以节省 LES 的 CPU(最少)。请参阅与portfast命令部分的避免生成TCN关于如何限制生成TCN的更多信息。

使用 portfast 命令避免 TCN 生成

portfast 功能是 STP 实现中 Cisco 专有的变化。此命令适用于特定端口,有两个作用:

  • 出现的端口直接置于转发 STP 模式,而不经过了解和监听过程。STP 仍在使用 portfast 的端口上运行。

  • 打开或关闭为 portfast 配置的端口时,交换机从不生成 TCN。

启用端口上的 portfast,在这些端口上,已连接的主机很可能会使这些端口的链路接通和断开(通常为用户经常重新通电的终端站)。此功能对服务器端口应该不是必要的。在通往集线器或其他网桥的端口上应该明确地避免使用此功能。在冗余链路上直接转换到转发状态的端口可能引起临时桥接环路。

拓扑更改可能非常有用,因此请不要在其链路接通或断开是网络中的一个重大事件的端口上启用 portfast

跟踪 TCN 的源

拓扑更改通知本身并不是一件坏事,但作为一名优秀的网络管理员,最好了解拓扑更改的原因,以便确保它们与真正的问题无关。识别发出拓扑更改的网桥不是一项容易的任务。然而,它在技术上并不复杂。

大多数网桥仅计数它们发出或接收的 TCN 数。Catalyst 4500/4000、5500/5000 和 6500/6000 能够显示端口和网桥的 ID,此网桥发送它们接收的最后的拓扑更改。从根网桥开始,然后可以下行到初始器网桥。有关详细信息,请参考 show spantree statistics 命令。

如果您得到来自 Cisco 设备的 show spantree statistics 命令输出,请使用命令输出解释程序仅限注册用户)显示潜在问题和解决方法。若要使用命令输出解释程序仅限注册用户),您必须作为注册用户登录,并启用 JavaScript。

结论

这里要考虑的重点是,TCN 不启动 STP 重新计算。这种可能性源自 TCN 通常与不稳定的 STP 环境相关联的事实;TCN 是这种可能性的后果,而不是原因。TCN 只影响老化时间。它不更改拓扑,也不创建环路。

拓扑更改的数量或速率本身不是问题。问题是要了解拓扑更改的意义。正常运行的网络可以体验高速率的拓扑更改。但是,应该与重大活动理想地说涉及一次拓扑更改在网络类似增长或下降的服务器或过渡的链路。这通过启用接通和断开端口上的 portfast 作为正常操作的一部分来实现。

相关的思科支持社区讨论

思科支持社区是您提问、解答问题、分享建议以及与工作伙伴协作的论坛。


相关信息


Document ID: 12013