☰

具有生成树慢速故障转移功能的 Cisco HSRP

tag-icon • tag-icon cisco hsrp
具有生成树慢速故障转移功能的 Cisco HSRP

我遇到了一个网络问题，我无法理解，因为我不擅长网络。从我们的提供商那里，我们有 2 个通过 HSRP 的 drop，它们进入堆叠的 cisco 2960 交换机。因此，每个交换机都有一个 drop。从那里，我们在交换机后面有两个 Astaro 设备，它们处理所有防火墙和 VLAN 路由。然后，它们反馈到 Cisco 2960，而且所有 VM 主机都在同一个 2960 上，所以它看起来像

                           --------------              --------------
                   |------ | Cisco 1 2960 | <--------> |Astaro 1 / VMS|
                   |       ______________              --------------
----------- --------
| Uplink  | 
|---------- -------- 
                   |       --------------              --------------
                   |-------| Cisco 2 2960 | <--------> |Astaro 2 / VMS|
                           --------------              --------------

因此，在任何时候，思科都是堆栈的主控，而阿斯塔罗也是主控。

假设我有以下场景

主 Astaro 是 #1 主交换机在堆栈中是 #2

如果我重新加载交换机＃2，我将会得到大约 2 分钟的停机时间，因为交换机 1 会接管并且一切会重新协商。

我的一些思科配置如下

spanning-tree mode rapid-pvst 
spanning-tree extend system-id
no spanning-tree vlan 1,100

interface GigabitEthernet1/0/1
 switchport access vlan 100
 switchport mode access
 switchport nonegotiate
 duplex full
!
interface GigabitEthernet1/0/2
 switchport mode trunk
 switchport nonegotiate
!
interface GigabitEthernet1/0/3
 switchport mode access
 switchport nonegotiate
!
interface GigabitEthernet1/0/4
 switchport access vlan 100
 switchport mode access
 switchport nonegotiate
!

端口 1 通向我的提供商，端口 2-4 通向交换机 astaro，用于管理端口/vlan 端口和 wan 端口。

我不知道为什么如果我重新启动交换机，就不能实现比 2 分钟更好的故障转移。

编辑

以下是我们的“堆栈”的配置

sw1a>show switch
Switch/Stack Mac Address : 64d8.1431.6a80
                                           H/W   Current
Switch#  Role   Mac Address     Priority Version  State
----------------------------------------------------------
 1       Member 0cd9.960b.5b00     15     1       Ready
*2       Master 64d8.1431.6a80     10     1       Ready
  • 交换机上的端口 1 是我们的上行链路
  • 端口 2 是 WAN 端口，它返回到 astaro
  • 端口 3 是返回到 astaro 的管理 vlan 端口
  • 端口 4 是返回到 astaro 的 vlan 端口

astaro 只是一个 Linux 设备，它为 Linux 为网络提供的所有 iptables 和类似工具提供了一个 GUI。

答案1

根据您的编辑和评论，我不认为您看到的是生成树延迟。您描述的停机时间（2 分钟）实在太长，无法用 STP 来解释，我有点怀疑 Linux 服务器是否在交换机上运行 STP。您基本上也在执行单交换机生成树，因为交换机堆栈被视为一个逻辑交换机。

不过，有些 STP 调整可能对你的情况有用。首先，你可以在 VLAN 上重新启用 Spanning-Tree —— 没有必要关闭它。除非你试图在 Linux 机器上运行 spanning-tree，否则 rapid-pvst 模式是个好主意。你还可以告诉交换机，通往 Linux 设备 (Gi1/0/2) 的中继不是交换机。

spanning-tree vlan 1,100
interface GigabitEthernet1/0/2
spanning-tree portfast trunk

剩下的就是其他的冗余功能，即交换机堆栈本身、HSRP 以及 Astaros 上的任何内容。

我猜 Astaros 的故障恢复机制。既然您提到其中一个是“主”，那就意味着任何时候只有一个处于活动状态。Astaros 设备上为故障转移设置了什么样的计时器？您是否有任何日志表明交换机发生故障后备用设备需要多长时间才能恢复活动状态？

生成树似乎不太合适，因为所有 STP 都在一台交换机上完成，而且停机时间也较长。交换机堆栈（至少在 3750 堆栈上）故障转移也应该比这更快，尽管您可以将控制台连接到辅助交换机，以查看它是否需要很长时间才能接管主交换机。HSRP（假设它在提供商处运行，而不是在您的交换机上运行）也会比这更快失败，并且不会对您造成影响。

TL;DR -- 我认为是 Linux 机器上的故障转移计时器导致了延迟。其次是交换机堆栈需要很长时间才能让辅助交换机接管主交换机。

相关内容