Redundancy cisco что это
Сетевые заметки
среда, 18 июля 2012 г.
Supervisor Engine Redundancy
RPR —первый режим избыточности, введенный в программное обеспечение Cisco IOS. В режиме RPR конфигурация автозагрузки и загрузочные регистры синхронизируются между активным модулем и модулем Supervisor в ждущем режиме, модуль в ждущем режиме инициализируется не полностью, и образы на активном модуле Supervisor и модуле Supervisor в ждущем режиме не обязательно должны быть одинаковыми. При переключении модуль Supervisor в ждущем режиме становится активным автоматически, но должен выполнить процесс загрузки. Кроме того, все линейные карты перезагружаются, и оборудование перепрограммируется.
Время переключения режима RPR равно 2 или более минутам. RPR+ — улучшение режима RPR, при котором модуль Supervisor в ждущем режиме полностью загружен и линейные карты не перезагружаются при переключении. Рабочая конфигурация синхронизируется между активным модулем и модулем Supervisor в ждущем режиме. Все действия по синхронизации, унаследованные от режима RPR также выполняются. Синхронизация выполняется перед переключением, и информация, синхронизируемая на модуле в ждущем режиме, используется, когда модуль в ждущем режиме становится активным, для снижения времени простоя. Данные уровня канала передачи данных и элементов управления между активным и ждущим модулем Supervisor Engine не синхронизируются. Интерфейсы временно могут не работать после переключения, и содержимое оборудования необходимо перепрограммировать. Время переключения режима RPR+ равно 30 или более секундам. Реальное время перехода на другой ресурс при сбое зависит от размера и сложности конфигурации. NSF/SSO — и программное обеспечение Cisco IOS, и CatOS поддерживают режим бесперебойной коммутации (NSF) с сохранением состояний (SSO). Ключевая разница заключается в том, когда и как применяются эти функции, поскольку наиболее серьезное развитие они получили сначала в Cisco IOS. SSO расширяет возможности режима RPR+, обеспечивая прозрачную отказоустойчивость протоколов уровня 2 при сбое модуля Supervisor. SSO обеспечивает отслеживание состояния соединений для протоколов уровня 2. При переключении сохраняются данные таблиц оборудования PFC и DFC. Это позволяет осуществить прозрачный переход на другой ресурс при сбое на уровне 2 и уровне 4. Режим бесперебойной коммутации (NSF) и SSO работают совместно, обеспечивая целостность уровня 3 после переключения. Это позволяет маршрутизаторам, испытывающим проблемы с активным модулем Supervisor, продолжать пересылку пакетов данных по известным маршрутам, в то время как информация о протоколах маршрутизации восстанавливается и проверяется. Данная пересылка может продолжаться за счет перезапуска механизмов, обеспечивающих передачу одноранговых настроечных сообщений при переходе на другой ресурс при сбое. Это позволяет избежать ненужных отклонений от маршрутов и нестабильности сети. Время перехода на другой ресурс при сбое составляет от 0 до 3 секунд при использовании NSF/SSO.
Важно:
для SSO необходимо соответветсвие IOS image на активном и избыточном супервизоре.
В случае проблемм с %Error show slavedisk0: (Invalid DOS media or no media in slot) выполнить #format slavedisk0: и после чего скопировать IOS Image на резервный супервизор возможно появления сообщения: %PFREDUN-SP-4-BOOTSTRING_INVALID: The bootfile slavebootflash:image_name is not present in standby
(With correctly configured redundant Supervisor Engine 720s, this erroneous message might be displayed after a reload)
Команды:
redundancy
keepalive-enable
mode sso
main-cpu
auto-sync running-config
#redundancy reload peer перезагрузка избыточного супервизора
#show redundancy вывод общей информации
Enable the console of the standby supervisor on Cisco routers By default, the console of the standby supervisor on Cisco routers is disabled. If for any reason you need to enable it, do the following: router#conf t
router(config)#redundancy
router(config-red)#main-cpu
router(config-r-mc)#standby console enable
Performing a Software Upgrade
antiCisco blogs
блоги по технологиям и оборудованию cisco от инструкторов
Развлекаемся с VSS
Введение: cisco на своих «больших» коммутаторах 65 серии не так давно внедрила довольно удобную штуку VSS (14400). Такой аналог стека на 3750-х. Правда, связь между шасси осуществляется при помощи старенького etherchannel. И есть мнение, что 20Гбит/сек мало для высоконагруженного ядра. Конечно, циска внедрила механизм минимизации нагрузки на этот линк между шасси, стараясь не допустить «лишнего хопа» по VSL (Virtual Switch Link).
Данная технология здорово упрощает логическую топологию сети, уменьшает количество точек настройки да и вообще – хорошо продается 🙂
В данной заметке я хочу поделиться с вами результатами нескольких экспериментов, проведенных над VSS в рамках отладки одной ошибки. Сразу оговорюсь: ошибка была незначительная, но требовала «разобрать» VSS. Мы с Siv решили заодно потестить, что происходит в случае разных сбоев. Итак:
При сборке стека VSS необходимо учитывать несколько основных моментов:
1. Одинаковые версии софта (IOS)
Начиная с IOS12.2(33)
2. Поддерживаемые модули
Начиная с 67xx (и свежее – 68хх, 69хх). Набивка шасси не обязательно должна быть одинаковая.
3. Супервайзоры и Feature card
VS-S720-10G-3C (VS-S720-10G-3CXL)
VS-Sup2T (XL)
DFC3C (DFC3CXL) и свежее (DFC4C).
4. минимум по 2 10Г модуля для связи супервизоров (они есть встроенные в указанные супервайзоры)
Можно и больше интерфейсов 10Г, задействовав дополнительные из линейных карт.
Я намеренно подробно не касаюсь вещей, описанных в гидах, например, здесь:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vss.html
Будем считать, что вы собрали VSS по гидам и все заработало. Но вы точно не знаете (а проверять стремно), что будет, если что-то сломается. Вот и пробежимся по этим «если». Но для затравки напомню, какие основные шаги требуются при настройке.
При первоначальной настройке необходимо задать, какой из 65хх будет основным, а какой — запасным.
SW(config)# switch virtual domain #
SW(config-vs-domain)# switch <1|2>
После этого необходимо настроить на разных 65хх пару 10Г портов, связанных в etherchannel.
Важно: номера этих port-channel на разных коммутаторах должны быть РАЗНЫЕ! Иначе после объединения конфига будет ошибка. Объединение происходит при ПЕРВОНАЧАЛЬНОМ переходе к VSS.
SW# switch convert mode virtual
После этого конфигурация сохраняется в NVRAM и обе железки перезагружаются
Примечание: если надо вернуться обратно, то используем команду
SW# switch convert mode stand-alone
После этой команды весь конфиг, касающийся VSS удаляется, текущая конфигурация сохраняется в NVRAM и железка перезагружается уже с обычном режиме.
Теперь немного помучаем собранный VSS
Консоль, подключенная в запасной коммутатор, когда VSS уже собран, позволяет зайти в непривилегированный режим, но не позволяет ввести других команд, в частности enable. Это гарантированно не дает изменить настройку через вторичный коммутатор.
MSK-HQ-SC01-sdby>
Standby console disabled
При разрыве одной связи между супервайзорами только основной коммутатор ругается, но VSS остается жив без перерыва связи.
При разрыве всех связей из VSL ругаются оба коммутатора, при этом резервный тоже становится активным (даже приглашение меняется).
Важно: в нашем случае изначально был отключен механизм проверки split brain. Если такой механизм подключить, то разрыв etherchannel (VSL) не приводит к ситуации, когда оба коммутатора считают себя основными со всеми вытекающими неприятными последствиями.
При этом резервный коммутатор знает все конфигурации (и running и startup), помнит про все модули и порты на основном. Единственные отличия — в настройке принадлежности к VSS — кто первичный, а кто — вторичный коммутатор. Поэтому в частности размер файлов конфигурации не одинаковый на двух коммутаторах.
(кусочки настройки VSS)
platform hardware vsl pfc mode pfc3c
!
interface Port-channel77
no switchport
no ip address
switch virtual link 1
mls qos trust cos
no mls qos channel-consistency
!
interface Port-channel78
no switchport
no ip address
switch virtual link 2
mls qos trust cos
no mls qos channel-consistency
!
module provision switch 1
slot 1 slot-type 147 port-type 61 number 48 virtual-slot 17
slot 3 slot-type 156 port-type 31 number 24 virtual-slot 19
slot 5 slot-type 254 port-type 31 number 2 port-type 61 number 1 port-type 60 number 2 virtual-slot 21
slot 7 slot-type 284 port-type 60 number 16 virtual-slot 23
slot 9 slot-type 227 port-type 60 number 8 virtual-slot 25
!
module provision switch 2
slot 3 slot-type 156 port-type 31 number 24 virtual-slot 35
slot 4 slot-type 147 port-type 61 number 48 virtual-slot 36
slot 5 slot-type 254 port-type 31 number 2 port-type 61 number 1 port-type 60 number 2 virtual-slot 37
!
switch virtual domain 77
switch mode virtual
switch 1 priority 200
switch 2 priority 150
mac-address use-virtual
!
MSK-HQ-SC01# sh switch virtual role det
!
Switch Switch Status Preempt Priority Role Session ID
Number Oper(Conf) Oper(Conf) Local Remote
——————————————————————
LOCAL 2 UP FALSE(N ) 100(100) ACTIVE 0 0
!
MSK-HQ-SC01#show switch virtual red
My Switch /> Peer Switch /> Last switchover reason = active unit removed
Configured Redundancy Mode = sso
Operating Redundancy Mode = sso
!
Switch 2 Slot 5 Processor Information :
————————————————
Current Software state = ACTIVE
Uptime in current state = 5 minutes
Image Version = Cisco IOS Software, s72033_rp Software (s72033_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(33)SXI5, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Sat 23-Oct-10 01:29 by prod_rel_team
BOOT = sup-bootdisk:s72033-adventerprisek9_wan-mz.122-33.SXI5.bin,1;
Configuration register = 0x2102
Fabric State = ACTIVE
Control Plane State = ACTIVE
!
Peer information is not available because
it is in ‘DISABLED’ state
Если при разобранном VSS подключить обратно линки, то по прошествии примерно 20 секунд, оба видят установление связи и запасной (вторичный) пытается уйти в перезагрузку.
Feb 28 17:20:32.212: %VSLP-SW2_SP-5-RRP_MSG: Role change from Active to Standby and hence need to reload
Если на запасном был какой-то несохраненный конфиг, созданный во время разорванного VSS, то перезагрузка сразу не происходит, о чем пишется в консоль. На выбор предлагается:
— сохраниться и перезагрузить
— либо принудительно набрать команду из специального режима:
(recovery-mode)#
возможно выбрать перезагрузку соседа (peer)
!
MSK-HQ-SC01(recovery-mode)#redundancy reload shelf
Warning:The standby is not up,continuing may lead to reload of the switch
!
System configuration has been modified. Save? [yes/no]: no
Reload this shelf [confirm]
Feb 28 17:22:17.046: %SYS-SW2_SP-3-LOGGER_FLUSHING: System pausing to ensure console debugging output.
!
Feb 28 17:22:17.046: %RF-SW2_SP-5-RF_RELOAD: Shelf reload. Reason: Admin reload CLI
Feb 28 17:22:17.046: %OIR-SW2_SP-6-CONSOLE: Changing console ownership to switch processor
Если же настройки не менялись, то перезагрузка происходит автоматом.
После перезагрузки основной коммутатор насаждает свой startup-config запасному, никакого merge (слияния) не происходит. В отличие от начального конфигурирования, когда при переводе в режим VSS оба конфига сливаются в один общий файл.
В-общем, шаг влево, шаг вправо – расстрел. В смысле, ошибиться практически невозможно, циска все за нас порешала и предусмотрела, так что смело можете собирать ваши виртуальные коммутаторы, лишь бы аппаратно и программно все карточки и модули поддерживали этот режим. Сломать что-либо крайне сложно 🙂
Технологии виртуализации коммутаторов Cisco и Hewlett Packard Enterprise
Сегодня хотелось бы поговорить о двух достаточно схожих технология виртуализации коммутаторов, которые позволяют объединять несколько коммутаторов в один логический. Речь пойдёт про технологии Cisco Virtual Switching System (VSS) и HPE Intelligent Resilient Framework (IRF). В рамках статьи мы рассмотрим более подробно, как работает технология VSS, после чего поговорим о технологии IRF.
Обе технологии (VSS и IRF) позволяют нам объединять коммутаторы, используя обычные Ethernet-порты. В целом данные технологии можно отнести к технологиям стекирования. Но оба вендора стараются всё же их называть технологиями виртуализации. Cisco вообще избегает слова стек в отношении VSS.
Технология VSS позволяет объединить два физических коммутатора в один логический. Но в отличии от более классических технологий стекирования (StackWise, FlexStack) для связи коммутаторов между собой используются не какие-то специализированные кабели, а Ethernet-порты. Таким образом, коммутаторы могут находиться на относительно большом удалении друг от друга.
После объединения коммутаторы начинают работать как один логический (рисунок 1). Оба коммутатора являются активными и обеспечивают передачу пакетов. При этом управление обоими коммутаторами осуществляется одним из устройств. Другими словами, уровень обработки данных (data plane) активен на обоих устройствах. А вот уровень управления (control plane) только на одном. Вспомним, что control plane (предлагаю в дальнейшем использовать именно иностранное наименование) отвечает за логику работы коммутатора: обработку всех сетевых протоколов (L2/L3), формирование таблицы маршрутизации, заполнение таблиц CEF, ACL, QoS и т.д.
Технология VSS поддерживается на следующих коммутаторах Cisco:
После того как мы объединили два коммутатора между собой, общая производительность системы увеличивается в два раза. Это обусловлено тем, что оба коммутатора отвечают за обработку пакетов. Таким образом, мы получаем:
Активный control plane управляет работой обоих коммутаторов. Также в процессе работы происходит постоянная синхронизация состояния между активным control plane на основном коммутаторе и control plane на резервном коммутаторе для обеспечения отказоустойчивости. Управление и синхронизация выполняются через специальный канал – Virtual Switch Link (VSL).
Канал VSL – это прямое соединение между двумя коммутаторами (никаких промежуточных устройств не допускается). Для обеспечения VSL канала коммутаторы подключаются друг к другу через обычные Ethernet-порты. Но когда я говорю про обычные порты, я чуточку лукавлю. Как можно догадаться, к этим портам также есть определённые требования и эти требования варьируются в зависимости от платформы коммутаторов. Ко всем пакетам, которые передаются через канал VSL, добавляется специализированный заголовок – Virtual Switch Header (его длина 32 байта):
VSL может состоять из нескольких физических каналов (что собственно и рекомендуется делать). Это необходимо для отказоустойчивости нашей системы, а также получения необходимой пропускной способности. Агрегация осуществляется с помощью протоколов PAgP или LACP. Т.е. максимально мы можем иметь 8 активных каналов, объединённых в один логический VSL. Например, если мы используется порты 10 Гбит/с, мы получим до 80 Гбит/с при агрегировании 8 таких каналов.
Я думаю, многие заметили, что VSL канал является аналогом стековой шины. Поэтому очень интересно посмотреть на трафик, который предаётся через него:
Control plane на основном коммутаторе выполняет две функции. Первая – обеспечивает логику работы коммутатора: программирование коммутатора на основании конфигурации, обработку всех сетевых протоколов (L2/L3), формирование таблицы маршрутизации, таблиц CEF, управление портами и т.д. Вторая функция – заполнение всех аппаратных таблиц (FIB, Adjacency, ACL, QoS и т.д.) на обоих коммутаторах для обеспечения обработки пользовательского трафика (на аппаратном уровне). Control plane на резервном коммутаторе находится в состоянии горячего резерва. При этом состояние активного сontrol plane постоянно синхронизируется с резервным. Это необходимо для того, чтобы обеспечить беспрерывную работу нашего виртуального коммутатора в случае отказа основного физического коммутатора.
Синхронизируется следующая информация: параметры загрузки устройств, их конфигурация, состояния сетевых протоколов и различных таблиц (запущенных на активном control plane), состояние устройств (линейных карт, портов).
Передача управляющих данных и синхронизация состояния между основным и резервным коммутаторами, выполняется с помощью специализированных протоколов:
За синхронизацию состояния между коммутаторами отвечает механизм переключения с сохранением состояния (Stateful Switchover — SSO). Данный механизм появился достаточно давно. Например, он используется для резервирования супервизоров в рамках одного коммутатора 6500. Он же используется и в технологии VSS (придумывать что-то новое не стали). Но как мы помним, SSO не позволяет синхронизировать состояние протоколов маршрутизации. А значит при переключении на резервный коммутатор протоколы динамической маршрутизации запускаются с нуля. Что автоматически обрывает все L3-соединения с удалёнными устройствами. Т.е. мы получаем временную потерю связи с внешним миром. Для решения данной проблемы технология SSO работает в связке с технологией Non-Stop Forwarding (NSF). Данная технология выполняет следующие задачи: обеспечивает передачу пакетов L3 в момент переключения (по факту замораживает старые записи о всех маршрутах), оповещает удалённые маршрутизаторы о том, что не нужно рвать связь, а также запрашивает у них всю необходимую информацию для построения новой таблицы маршрутизации. Конечно, же удалённые устройства должны в этом случае также поддерживать технологию NSF (так сказать, быть NSF-aware).
Кстати, для справки: резервному коммутатору требуется до 13 секунд, чтобы полностью перезапустить процесс динамической маршрутизации. Поэтому без технологии NSF было бы совсем грустно.
А как быстро произойдёт переключение на второй коммутатор в случае отказа первого? Вендор на этот счёт приводит среднюю цифру 200 мсек. Для 6500E (видимо и для 6800 тоже) в ряде случаев она может достигать 400 мсек (так сказать, издержки распределённости архитектуры).
Что касается control plane стоит отметить ещё один момент. Так как активным control plane является только на одном из коммутаторов, весь трафик сетевых протоколов обрабатывается именно им. Например, трафик протоколов динамической маршрутизации (OSPF, EIGRP, пр.) должен в конечном итоге попасть на активный control plane. А значит, если он сначала попал на резервный коммутатор, этот трафик будет передан на основной коммутатор через VSL канал. При этом ответные пакеты могут быть отправлены напрямую с основного коммутатора (приоритетный вариант), а могут быть переданы через резервный. Это зависит от нескольких вещей: типа сетевого протокола и наличия прямого канала от основного коммутатора до получателя.
Если мы имеем дело с коммутаторами 4500E/6500E/6800, мы можем в каждый из них установить по два супервизора (так сказать, задублируем задублированное). VSS поддерживает и такую конфигурацию (называется она Quad-Supervisor). Это нужно в том случае, когда мы не хотим терять общую производительность системы, в случае выхода из строя одного из супервизоров. Для всех вариантов кроме Sup2T, второй супервизор в шасси работает в холодном резерве (Route Processor Redundancy). А это значит, что второй супервизор переходит в рабочий режим (становится резервным в разрезе VSS) только после перезагрузки всего шасси. В случае Sup2T, второй супервизор в одном шасси работает в режиме SSO и никакая перезагрузка не требуется.
Теперь давайте поговорим о передаче пользовательского трафика через виртуальный коммутатор VSS. Всё-таки это его главная задача. Одна из основных причин использовать VSS – возможность агрегации нескольких каналов, приходящих на разные коммутаторы (в терминах Cisco – Multichassis EtherChannel (MEC)). Речь идёт о подключении к виртуальному коммутатору внешних устройств (например, других коммутаторов).
Когда мы агрегируем несколько каналов в один логический в рамках VSS, может использоваться один из протоколов динамической агрегации (PAgP или LACP) или же статический EtherChannel (режим ON). За распределение трафика внутри логического канала отвечает механизм на базе хеш-функции. Хеш-функция применяется к определённым полям заголовков, передаваемого трафика. Например, хеш-функция может применяется к значению IP-адреса отправителя. В этом случае, если у нас агрегируется два канала, то по первому каналу будут передаваться потоки трафика, у которых IP-адреса отправителя чётные, а по второму — нечётные. Это позволяет распределять потоки трафика между разными каналами, объединёнными в один etherchannel. В более сложных вариантах на принятие решения о выборе канала могут влиять сразу несколько параметров (например, Src IP + Dst IP + Src Port + Dst Port).
В случае VSS всегда работает следующее правило: в первую очередь для передачи трафика внутри MEC используются локальные каналы связи (рисунок 5). Это сделано для того, чтобы не нагружать VSL канал. Замечу, что это утверждение для 6500E/6800 справедливо, как для случая MEC, так и для случая Equal Cost Multipath (если связность между виртуальным коммутатором и соседним устройством идёт по отдельным L3 каналам).
Причём не важно какая у нас общая пропускная способность каналов для каждого коммутатора. В нашем примере, даже имея двойную связь между SW2 и SW3, пакеты, поступившие на SW1 и адресованные получателям за SW3, всегда будут уходить через единственный локальный порт. Но если эта связь нарушится (или же изначально коммутатор SW3 был подключен только к SW2), весь трафик пойдёт через VSL канал (рисунок 6).
Отсюда делаем вывод, что рекомендованная схема работы VSS – это подключение устройств одновременно к обоим коммутаторам VSS (рисунок 7). В этом случае у нас трафик будет распределяться между обоими коммутаторами VSS и мы получим увеличение производительности всей системы практически в два раза по сравнению с одним коммутатором. В противном случае мы нагружаем VSL канал и теряем в суммарной производительности системы (расходуя на обработку одного потока трафика мощности обоих коммутаторов).
Для улучшения работы механизмов балансировки трафика внутри каналов MEC для технологии VSS были добавлены следующие функции:
Итак, мы выяснили что оба коммутатора обрабатывают трафик, при этом всё управление сосредоточено на одном из них. В качестве общей соединительной шины используется канал VSL, через который происходит передача как минимум управляющей и синхронизирующей информации. Через этот же канал резервный коммутатор узнаёт, что основной коммутатор «умер». Но что будет если этот канал разорвётся, при этом оба коммутатора будут исправными? Ответ прост, основной коммутатор останется активным, а вот резервный коммутатор посчитает, что его коллега отказал, и соответственно тоже станет активным (везде речь про control plane). А так как конфигурация у этих коммутаторов одна, мы получим в сети два абсолютно одинаковых устройства с идентичной адресацией. Думаю, не стоит говорить, к чему это приведёт. Для того чтобы избежать такой ситуации, как минимум не стоит разрывать VSL канал. Но не всегда это от нас зависит, поэтому есть механизм, который позволяют минимизировать последствия разрыва VSL канала. Данный механизм использует один из трёх методов обнаружения сбойной ситуации:
В случае работы Enhanced PAgP (прим. PAgP – проприетарный протокол) в качестве «лакмусовой бумажки» используется внешнее устройство. Каждый коммутатор VSS рассылает специальное сообщение PAgP через локальные порты в рамках одного логический канала MEC, через который подключен внешний коммутатор (рисунок 9). В таком сообщении содержится идентификатор активного коммутатора VSS. Получив ePAgP пакет, удалённое устройство его отправляет в обратную сторону. Если у нас всё хорошо, оба коммутатора отсылают один и тот же идентификатор активного коммутатора VSS. Если же оба коммутатора стали активными, каждый из них будет отсылать сообщения с собственным идентификатором (рисунок 10). А так как удалённое устройство отправляет такие сообщения обратно, оба коммутатора поймут, что наступила сбойная ситуация.
А как быстро обнаружится сбойная ситуация в этом случае? Как только коммутатор, который изначально был резервным, становится активным, он сразу же отсылает сообщение ePAgP со своим идентификатором. Таким образом, время обнаружения сбойной ситуации – доли секунд. Безусловно удалённое устройство также должно поддерживать ePAgP. Такая поддержка есть на коммутаторах 2960, 3750 (но не в стеке) и пр.
Следующий механизм — Fast Hello. В этом случае между коммутаторами VSS делается дополнительный прямой L2 канал (без промежуточных устройств). В рамках этого канала коммутаторы обмениваются сообщениями VSLP Fast Hello. И если VSL канал упал, но при этом пакеты VSLP Fast Hello продолжают ходить, у нас наступила сбойная ситуация. Время обнаружения сбойной ситуации – доли секунд (VSLP Fast Hello сообщения при падении VSL канала передаются с интервалом в 200 мсек).
Последний механизм обнаружения — IP BFD (Bidirectional Forwarding Detection). Данный механизм очень похож на работу Fast Hello, но более медленный (время обнаружения исчисляется секундами). Он может работать через прямой канал L3. Данный механизм не рекомендуется использовать из-за его медленности. Более того в последних релизах IOS он отсутствует.
Рекомендуется использовать одновременно два механизма обнаружения сбойной ситуации (обрыва VSL канала).
И так, в целом основные моменты работы технологии Cisco VSS нами рассмотрены. Остался небольшой штрих – рекомендованный дизайн использования VSS. Рассмотрим два варианта:
В первом случае отработка обрыва канала или отказа активного коммутатора VSS будет происходить средствами протокола динамической маршрутизации. При этом, так как мы будем иметь несколько равноценных маршрутов (по маршруту на каждый L3 канал), общая пропускная способность будет агрегироваться за счёт Equal Cost Multipath (ECMP). Собственно, ECMP и будет отвечать за распределение трафика по коммутаторам VSS. Во втором случае отработка обрыва канала или отказа активного коммутатора VSS будет отрабатываться аппаратно за счёт работы Multichassis EtherChannel. Благодаря средствам балансировки трафика между каналами (хеш функций) MEC будет отвечать также и за распределение трафика по коммутаторам VSS.
Сразу видны преимущества MEC по отношению к ECMP. У нас меньше логических связей с соседом (всего одна связь), меньше таблица маршрутов (от одного соседа мы принимаем всего одну копию маршрутов) и меньше нагрузка в случае отказа одного из каналов (по факту её нет, так как логический канал даже при потере одного физического будет продолжать работать). Плюс, для понимания такая конфигурация более простая.
А как же обстоят дела со временем переключения? Для unicast-трафика в обоих вариантах это время одинаковое. А вот для multicast, нет. В случае multicast-трафика время сходимости сети для ECMP существенно больше.
Из всего этого вывод: рекомендуется использовать вариант подключения с одним логическим соединением (MEC).
Хотел бы кратко затронуть ещё одно решение, которое использует в своей основе технологию VSS. Это решение — Cisco Catalyst Instant Access. Идея заключается в том, чтобы получить один большой виртуальный коммутатор внутри сети.
В этом случае в ядро сети (Instant Access parent) ставятся два коммутатора 6500E/6800 с супервизорами Sup2T и специализированными линейными платами, которые объединяются с помощью технологии VSS. В качестве коммутаторов уровня доступа (Instant Access client) используются коммутаторы Cisco 6800ia или 3560CX (их может быть до 42). Стоит отметить, что коммутаторы IA clients не имеют функций локальной коммутации и абсолютно все пакеты будут передаваться на коммутаторы ядра (IA parent). Правда, цена таких коммутаторов, как мне кажется, не совсем соответствует их функциональности. Но это отдельный разговор.
Настроить технологию VSS достаточно просто. Начиная с версии Cisco IOS XE 3.6.0E (IOS 15.2(2)E) для объединения двух коммутаторов в один виртуальный можно использовать упрощённую схему настройки — Easy VSS. Два коммутатора соединяться друг с другом и должны быть видны на уровне L3. Далее вводится команда конвертации в VSS режим на том коммутаторе, который у нас будет основным:
SwitchA# switch convert mode easy-virtual-switch
Указываются порты, которые будут образовывать VSL канал (коммутаторы должны быть уже соединены друг с другом через эти порты):
SwitchA(easy-vss)# VSL Te1/1/15 Te1/1/16
После этого оба коммутатора перезагрузятся для перехода в режим работы VSS. На этом минимальная настройка закончена.
Если мы настраиваем VSS классическим способом, фактически схема не сильно усложняется. На обоих коммутаторах мы настраиваем следующее:
SwitchA(config)# switch virtual domain 2
SwitchA(config-vs-domain)# switch 1
SwitchB(config)# switch virtual domain 2
SwitchB(config-vs-domain)# switch 2
SwitchA(config)# interface port-channel 1
SwitchA(config)# switchport
SwitchA(config-if)# switch virtual link 1
SwitchA(config-if)# no shutdown
SwitchB(config)# interface port-channel 2
SwitchB(config)# switchport
SwitchB(config-if)# switch virtual link 2
SwitchB(config-if)# no shutdown
SwitchA(config)# interface range tengigabitethernet 1/15-16
SwitchA(config-if)# channel-group 1 mode on
SwitchB(config)# interface range tengigabitethernet 1/15-16
SwitchB(config-if)# channel-group 2 mode on
SwitchA#switch convert mode virtual
SwitchB#switch convert mode virtual
После того, как коммутаторы перейдут в режим VSS, в конфигурацию автоматически будут добавлены настройки параметров QoS для VSL канала. Дополнительно (опционально) мы можем настроить функции обнаружения ситуации с двумя активными control plane, в случае разрыва канала VSL. А также задать MAC-адрес виртуального коммутатора (по умолчанию он задаётся динамически).
Давайте теперь посмотрим, что мы получим после объединения коммутаторов на примере Cisco 4500X:
Первый коммутатор у нас стал основным/активным (VSS Active, а второй – резервным (VSS Standby, Control plane первого коммутатора стал активным (Control Plane State = ACTIVE), а control plane второго — резервным (Control Plane State = STANDBY), в режиме горячий резерв (Current Software state = STANDBY HOT (switchover target)). Для обеспечения отказоустойчивости у нас используется механизм SSO (Operating Redundancy Mode = Stateful Switchover). Также мы видим, что data plane на обоих коммутаторах находится в активном состоянии (Fabric State = ACTIVE).
Следующая информация показывает, какие порты у нас используются под VSL канал:
Как мы видим, порты Te1/1/15 и Te1/1/16 используются под VSL канал. Между коммутаторами запущен протокол LMP. Через оба порта по средствам протокола LMP мы видим второй коммутатор (Hello bidir).
На этом обсуждение работы Cisco VSS предлагаю завершить и перейти к решению HPE IRF.
Про решение HPE IRF можно рассказать не так подробно, как про Cisco VSS. Это обусловлено тем, что информации по этой технологии не так много и чаще всего она носить достаточно поверхностный характер. Хотя может быть это и к лучшему, так не нужно «убивать» мозг в попытке разобраться с деталями. С другой же стороны не покидает чувство, что ты работаешь с неким чёрным ящиком.
В целом, если мы говорим про два коммутатора HPE, объединённые в стек (вендор допускает это определение), работа IRF и VSS очень похожа. Один из коммутаторов выбирается основным (Master), второй становится ведомым (Slave). Обработкой трафика занимаются оба коммутатора (т.е. data plane активен на обоих устройствах). Управление осуществляется основным коммутатором (на нём будет активным control plane), при этом его состояние синхронизируется с ведомым.
В качестве «стековой шины» используются обычные Ethernet-порты. На некоторых моделях для этого можно использовать даже порты 1 Гбит/с, но в большинстве случаев требуются порты минимум 10 Гбит/с. Между коммутаторами делается IRF канал (аналог VSL канала). Всем пакетам добавляет дополнительный заголовок (IRF tag).
Так как текущее состояние control plane синхронизируется между коммутаторами внутри стека, отказ основного коммутатора не приводит к остановке трафика. Такое поведение аналогично работе Cisco SSO. В отличии от Cisco VSS, синхронизация включает в том числе и состояния протоколов маршрутизации. А так как переключение занимает достаточно короткое время (вендором заявлено 50 мсек), соседние устройства не успевают обнаружить отказ одного из коммутаторов и разорвать L3-соединения. Поэтому аналог технологии Cisco NSF не требуется.
Также как в технологии VSS, стек IRF поддерживает агрегацию каналов, подключенных к разным коммутаторам стека. Для обеспечения согласования параметров логического канала используется протокол LACP.
Что касается временных показатель, у технологии IRF они выглядят очень неплохо. Например, отмеченные выше 50 мсек являются не средним значением, а максимальным. В ряде документов указано, что по факту переключение произойдёт быстрее. Тоже самое касается времени переключения потоков трафика в случае добавления/удаления физических каналов в рамках агрегации в один логический. Приводится значение — 2 мсек. У Cisco это значение — 200 мсек. При таких временных показателях никакие адаптивные функции хеш и не требуются.
В случае, если у нас разорвётся IRF канал и оба коммутатора решат, что нужно стать активными, IRF работает по сходному алгоритму с Cisco VSS. Один из коммутаторов сохраняет свою роль основного, второй коммутатор переходит в состояние восстановления (Recovery-state). В этом состоянии он отключает все порты кроме IRF и тех портов, для которых в ручном режиме указано, что их не нужно отключать. Как только IRF канал будет восстановлен, коммутатор, который был в состояние восстановления, перезагрузится. После перезагрузки он станет ведомым (Slave).
Схемы обнаружения данного состояния (Multi-active detection) также очень похожи на те, которые мы рассмотрели в Cisco VSS. HPE IRF поддерживает следующие варианты:
Теперь давайте, посмотрим, чем HPE IRF отличается от Cisco VSS.
Во-первых, технология IRF поддерживается на более широком модельном ряде коммутаторов. Фактически это основная технология стекирования, которая есть и на относительно дешевых коммутаторах A3100 и на дорогих модульных 12900. В стек можно объединять коммутаторы только одного модельного ряда, правда, с небольшим исключением (совместно будут работать коммутаторы серии 5800 и 5820, а также 5900 и 5920).
Во-вторых, технология IRF позволяет объединить в стек до девяти коммутаторов (для ряда моделей это значение ограничено четырьмя). Возможны две топологии подключения коммутаторов в рамках IRF: шина и кольцо.
Вариант с подключением в виде кольца является рекомендованным, так как он более отказоустойчивый. При обрыве одного соединения мы не получим ситуации с двумя активными IRF группами коммутаторов.
Судя по описанию технологии, после того, как коммутаторы объединились в стек IRF, они начинают обмениваться некими hello-пакетами для построения общей топологии стека. Далее на основании этой топологии происходит передача пакетов внутри стека IRF. К сожалению, более детальной информации найти не удалось.
Прежде чем завершить обзор IRF, нужно сказать о развитии данной технологии – enhanced IRF (eIRF). eIRF позволяет построить более иерархичную структуру, включающую два уровня – ядро и уровень доступа (используется архитектура Clos).
Коммутаторы, находящиеся на уровне ядра (уровень Spine для архитектуры Clos), будут выполнять функции управления (такие коммутаторы называются Controlling Bridges — CB). И фактически стек IRF запускается именно на них. Коммутаторы, находящиеся на уровне доступа (уровень Leaf для архитектуры Clos), будут выполнять лишь функции расширения портов и обеспечивать только передачу трафика (такие коммутаторы называются Port Extenders – PE). Коммутаторы PE (в ряде документов такие коммутаторы обозначаются аббревиатурой PEX) не имеют функций локальной коммутации и абсолютно все пакеты будут передаваться на коммутаторы ядра. На данный момент может быть два коммутатора ядра и до 30 коммутаторов уровня доступа. Все эти коммутаторы будут выглядеть как одно большое устройство. Ничего не напоминает? Конечно же, аналогичное решение у Cisco – это Instant Access.
Давайте рассмотрим пример настройки технологии IRF.
Назначаем коммутаторам member ID. Так как по умолчанию устройства имеют member member ID задаём только на втором устройстве:
[Sysname2] irf member 1 renumber 2
Renumbering the member ID may result in configuration change or loss. Continue? [Y/N]:y
[Sysname2] quit
Отключаем порты, которые у нас будут использоваться в IRF канале (по умолчанию они всегда выключены):
[Sysname1] interface range ten-gigabitethernet 1/0/7 to ten-gigabitethernet 1/0/8
[Sysname1-if-range] shutdown
[Sysname2] interface range ten-gigabitethernet 2/0/7 to ten-gigabitethernet 2/0/8
[Sysname2-if-range] shutdown
Закрепляем физические порты за IRF портами:
[Sysname1] irf-port 1/1
[Sysname1-irf-port2/1] port group interface ten-gigabitethernet 1/0/7
[Sysname1-irf-port2/1] port group interface ten-gigabitethernet 1/0/8
[Sysname2] irf-port 2/1
[Sysname2-irf-port2/2] port group interface ten-gigabitethernet 2/0/7
[Sysname2-irf-port2/2] port group interface ten-gigabitethernet 2/0/8
Включаем порты, которые у нас будут использоваться в IRF канале:
[Sysname1] interface range ten-gigabitethernet 1/0/7 to ten-gigabitethernet 1/0/8
[Sysname1-if-range] undo shutdown
[Sysname1-if-range] quit
[Sysname1] save
[Sysname2] interface range ten-gigabitethernet 2/0/7 to ten-gigabitethernet 2/0/8
[Sysname2-if-range] undo shutdown
[Sysname2-if-range] quit
[Sysname2] save
Активируем IRF порты:
[Sysname1] irf-port-configuration active
[Sysname2] irf-port-configuration active
После этого то устройство, которое будет ведомым, перезагрузится. Фабрика IRF собрана. Опционально настраиваем приоритет и функции MAD.
Давайте теперь посмотрим, что мы получим после объединения коммутаторов. Первый коммутатор (MemberID=1) у нас стал мастером (Master), второй коммутатор (MemberID=2) стал ведомым (Standby).
Информация по портам, которые используются для формирования IRF канала:
Информация по полученной топологии IRF:
Перед тем, как мы перейдём к заключительной части, хотел бы ещё раз отметить, что часть вопросов для меня остались за кадром, в особенности вопрос передачи пакетов внутри стека IRF.