Назад | Перейти на главную страницу

Cisco HSRP с медленным аварийным переключением связующего дерева

У меня проблема с сетью, которую я не могу понять, так как я не сильный сетевой парень, чтобы понять это. От нашего провайдера у нас есть 2 дропа через HSRP, которые входят в наши стековые коммутаторы cisco 2960. Таким образом, у каждого переключателя есть капля. Оттуда у нас есть два устройства Astaro за коммутаторами, которые обрабатывают всю маршрутизацию межсетевого экрана и VLAN. Затем они возвращаются в Cisco 2960, а также все хосты виртуальных машин находятся на одном и том же 2960. Таким образом, это выглядит примерно так:

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

Таким образом, в любое время cisco является мастером стека, а астаро также является мастером.

Скажем, у меня есть следующий сценарий

Мастер Астаро - главный выключатель №1 в стеке - №2

Если я перезагружаю коммутатор №2, я получаю около 2 минут простоя, так как коммутатор 1 вступает во владение и все возобновляется.

Некоторые из моих конфигураций cisco выглядят так

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.

Я не понимаю, почему у меня не может быть лучшего, чем двухминутная отработка отказа, если я перезагружу коммутатор.

редактировать

ниже - конфигурация нашего "стека"

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

Astaro - это в значительной степени Linux-устройство, которое предоставляет графический интерфейс для всех iptables и таких инструментов, которые Linux предлагает для работы в сети.

Основываясь на ваших правках и комментариях, я не думаю, что вы наблюдаете задержку связующего дерева. Время простоя, которое вы описываете (2 минуты), действительно слишком долго, чтобы его можно было объяснить с помощью STP, и я как бы сомневаюсь, что серверы Linux используют STP с коммутаторами. Вы также в основном используете связующее дерево с одним коммутатором, поскольку стек коммутаторов считается одним логическим коммутатором.

Тем не менее, есть несколько настроек STP, которые, вероятно, будут хорошей идеей в вашей ситуации. Прежде всего, вы можете повторно включить Spanning-Tree в своих VLAN - нет причин для его отключения. Режим rapid-pvst - хорошая идея, если вы не пытаетесь запустить связующее дерево с ящиками Linux. Вы также можете указать коммутатору, что магистрали к вашим устройствам Linux (Gi1 / 0/2) не являются коммутаторами.

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

Это оставляет другие функции резервирования, которые у вас есть, а именно сам стек коммутаторов, HSRP и все остальное на Astaros.

Я делаю ставку на механизм восстановления после сбоя на Astaros. Поскольку вы упомянули, что один из них является «мастером», это означает, что только один активен одновременно. Какие таймеры настроены на устройствах Astaros для аварийного переключения? Есть ли у вас какие-либо журналы, в которых указано, сколько времени требуется резервному устройству, чтобы стать активным после сбоя коммутатора?

Spanning-tree не кажется правильным из-за того, что весь протокол STP выполняется на одном коммутаторе, и из-за простоя. Переключение стека коммутатора (по крайней мере, на стеке 3750) должно быть быстрее, чем это тоже, хотя вы можете подключить консоль к вторичному коммутатору, чтобы увидеть, долго ли он становится главным. HSRP (при условии, что он работает у провайдера, а не на ваших коммутаторах) также выйдет из строя намного быстрее и не должен влиять на вас.

TL; DR - я думаю, что задержку вызывают таймеры переключения на ваш Linux. Второе место занимает стек коммутаторов, которому требуется много времени, чтобы вторичный коммутатор стал ведущим.