Cisco HSRP с медленным отказоустойчивостью связующего дерева
У меня проблема с сетью, которую я не могу обернуть, так как я не сильный сетевой парень, чтобы понять это. От нашего провайдера у нас есть две капли через HSRP, которые идут в наши коммутаторы cisco 2960, которые уложены в стек. Таким образом, каждый переключатель имеет падение. Оттуда у нас есть два устройства Astaro за коммутаторами, которые управляют всеми брандмауэрами и маршрутизацией VLAN. Затем они возвращаются в Cisco 2960, а также все узлы виртуальных машин находятся на одном и том же 2960. Это выглядит примерно так:
-------------- --------------
|------ | Cisco 1 2960 | <--------> |Astaro 1 / VMS|
| ______________ --------------
----------- --------
| Uplink |
|---------- --------
| -------------- --------------
|-------| Cisco 2 2960 | <--------> |Astaro 2 / VMS|
-------------- --------------
Таким образом, в любое время cisco является мастером стека, а astaro - также мастером.
Скажи, что у меня есть следующий scenerio
Мастер Астаро - № 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.
Я в растерянности из-за того, что у меня не может быть лучше, чем 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 является управляющим портом vlan обратно в astaro
- порт 4 является портом VLAN, который восходит к Astaro
Astaro - это всего лишь устройство linux, которое предоставляет графический интерфейс для всех iptables и таких инструментов, которые linux предложит для работы в сети.
1 ответ
Исходя из ваших правок и комментариев, я не думаю, что это задержка связующего дерева, которую вы видите. Описываемое вами время простоя (2 минуты) действительно слишком велико, чтобы объяснить его STP, и я сомневаюсь, что на серверах Linux работает STP с коммутаторами. Вы также в основном выполняете связующее дерево с одним коммутатором, поскольку стек коммутаторов считается одним логическим коммутатором.
Однако есть некоторые хитрости STP, которые, вероятно, являются хорошей идеей в вашей ситуации. Прежде всего, вы можете повторно включить Spanning-Tree в своих VLAN-сетях - нет причин его отключать. Режим fast-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. Второе место занимает стек коммутаторов, который занимает много времени, чтобы вторичный коммутатор стал главным.