Текущая версия на 18:15, 15 июля 2021

Общее

Кол-во свитчей, объединенных в одно шасси зависит от версии софта и модели.

Можно объединять разные модели в стек. Софт при этом должен быть одинаковым у всех свитчей.

Компоненты

VC-port

Для объединения в стек используются специальные порты VCP (Virtual Chassis Ports).

Некоторые модели свитчей имеют выделенные стековые порты, некоторые не имеют таковых.

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

SFP, SFP+, и XFP могут выполнять роль VCP портов.

Если требуется емкость более 40G между членами стека (стековые порты и кабели поддерживают именно такую скорость), можно сделать 2 линка между свитчами.

Оптические порты между двумя свитчами с одинаковой скоростью передачи, выступающие в роли VCP, автоматом объединяются в LAG (bundle). Порты с разной скоростью в LAG не соберутся.

Когда оптический порт настроен в роли VCP, он не может использоваться в других целях.

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

Все 40Gb QSFP+ порты на EX4300 под дефолту используются как VCP.

Все 10Gb порты могут быть настроены и использоваться в качестве VPC.

Master/Backup/Linecard

При объединении в стек, свитчи играют разные роли.

Master

управляет членами стека
запускает Junos
управляет шасси и control protocols (для chassis)
держит единую конфигурацию для всего стека

Если включить один свитч, который поддерживает стекирование, он будет иметь роль мастера.

Если в стеке более одного свитча, то один будет мастером, один резервным (backup), остальные - линейные карты (linecard).

Если для стека используются EX4300 и EX4600, то EX4600 должна быть назначена роль мастера.

Если для стека используются EX4200, EX4500, EX4550, то любой из них может выполнять роль мастера.

Backup

находится в состоянии подхватить роль мастера, если мастер перестанет работать
синхронизирует с мастером: состояния протоколов, forwarding tables и т.д...

Если для стека используются EX4300 и EX4600, то EX4600 должна быть назначена роль backup (то есть если есть возможность EX4600 - master, второй EX4600 - backup).

В случает использования EX4200, EX4500, EX4550 - любой подходит для роли backup.

Linecard

выполняет роль линейной карты, то есть как дополнительный свитч с портами
не запускает chassis control protocols
не может даже определить состояния интерфейсов (или ошибок), которые были настроены через master.

Mastership-priority

Для назначения роли члену стека используется mastership-priority. Значение [0-255].

Более высокое значение более приоритетно.

Дефолтное значение = 128.

Назначение одинакового приоритета master и backup позволяет более гладко произвести процесс переключения роли master на backup свитч. Также это позволяет на стать master свитчу, который после перерыва вернулся в работу, то есть избежать еще одного перерыва.

Свитч с mastership-priority = 0 всегда будет работать только в роли linecard.

Master Election

Выбирается с наибольшим mastership-priority
Выбирается тот свитч, который был master в последний раз
Выбирается тот свитч, который находится в стеке большее количество времени. (считается разница в 1 мин)
Выбирается по наименьшему mac-address

Модели свитчей никак не играют роли в выборе.

Чтобы быть точно уверенным, что нужный свитч будет выступать в роли master:

Включаем свитч (будущий master)
Задаем ему mastership-priority = 255
Задаем приоритеты другим членам стека
Включаем остальные свитчи

Member switch/Member ID

Каждый свитч, поддерживающий функцию стекирования назначает себе member-id. Если включить свитчи не объединяя их в стек, каждый из них будет иметь member-id = 0.

Когда свитчи объединили в стек, master назначает каждому члену свой уникальный member-id, исходя из порядка, в котором свитчи были включены, исходя из преднастроенного member-id.

Если в стеке был member, который физически отключили, его member-id более не будет использоваться мастером для присвоения member-id новому члену стека.

Member-id работает как номер fps-слота.

Обновление софта

В кластере все свитчи должны обязательно иметь одинаковую версию софта.

Софт можно поставить на весь кластер или на каждый свитч отдельно. Для этого используется одна и та же команда:

request system software add validate

Если в стеке используются разные модели, на них все-равно должен стоять одинаковый софт.

Чтобы избежать длительного перерыва при обновлении, можно использовать NSSU. Он позволяет обновить отдельно каждого member'а, а при использовании дополнительных HA фид, перерыв можно сделать очень коротким (или вообще без перерыва обновить).

High Availability

Само по себе использование стека из EX - уже неплохое средство для HA.

1. LAG (Link Aggregation Groups): подключать CE двумя линками на разные members.

Без HA: kernel и forwarding state инфо не сохраняется инфо на обе RE. Поэтому процесс конвергенции занимает время, также как и процесс switchover может занимать до нескольких минут, до окончания процесса не передается трафик.

GRES (Graceful routing Engine switchover): kernel и forwarding state инфо хранится на обеих RE, что обеспечивает отсутствие конвергенции и сильно сокращает перерыв в передаче графики при switchover.

NSB (nonstop bridging): l2-протоколы, поддерживающие NSB, не падают при switchover. Инфо l2-протоколов хранится на обеих RE.

NSR (nonstop routing): l3-протоколы, поддерживающие NSR, не падают при switchover. Инфо хранится на обеих RE.

Graseful Protocol Restart: передача трафика не прерывается при switchover. interface и kernel инфо зарезервирована. Когда Control plane роутера падает, роутер не сразу сообщает об этом своим соседям а ждет заданный промежуток времени. Но! сосед тоже должен уметь GR.

Управление

Из-за наличия нескольких свитчей в стеке к кластера появляется дофига консольных и mgmt портов. К какому подключиться?

При подключении к любому, нас отредиректит к master.

Если мастер сменился, то console сессия отключится от старого master и переустановится к новому.

vme-port - виртуальный, используется для управления. По логинении на ip, настроенный на vme порту, кластер редиректнет вас на master switch.

Конфигурация

Траблшутинг

show virtual-chassis
show virtual-chassis vc-ports all-members

@@ Строка 1: / Строка 1: @@
+{{#description2:Компоненты virtual chassis. Master/Backup/Linecard. Обновление софта. High Availability. Управление virtual chassis. Информация для подготовки к экзаменам Juniper.}}
 =Общее=
 Кол-во свитчей, объединенных в одно шасси зависит от версии софта и модели.
 Можно объединять разные модели в стек. Софт при этом должен быть одинаковым у всех свитчей.
+==Компоненты==
-==VCP-port==
+===VC-port===
 Для объединения в стек используются специальные порты VCP (Virtual Chassis Ports).
@@ Строка 15: / Строка 16: @@
 Если требуется емкость более 40G между членами стека (стековые порты и кабели поддерживают именно такую скорость), можно сделать 2 линка между свитчами.
-Оптические порты с одинаковой скоростью передачи, выступающие в роли VCP, объединяются в LAG (bundle).
+Оптические порты между двумя свитчами с одинаковой скоростью передачи, выступающие в роли VCP, автоматом объединяются в LAG (bundle). Порты с разной скоростью в LAG не соберутся.
 Когда оптический порт настроен в роли VCP, он не может использоваться в других целях.
-==Master/Backup/Linecard==
+VCP используются как для служебного трафика между свитчами, так и для передачи трафика между свитчами.
+Все 40Gb QSFP+ порты на EX4300 под дефолту используются как VCP.
+Все 10Gb порты могут быть настроены и использоваться в качестве VPC.
+===Master/Backup/Linecard===
 При объединении в стек, свитчи играют разные роли.
-===Master===
+====Master====
 *управляет членами стека
 *запускает Junos
@@ Строка 36: / Строка 43: @@
 Если для стека используются EX4200, EX4500, EX4550, то любой из них может выполнять роль мастера.
-===Backup===
+====Backup====
 *находится в состоянии подхватить роль мастера, если мастер перестанет работать
 *синхронизирует с мастером: состояния протоколов, forwarding tables и т.д...
@@ Строка 44: / Строка 51: @@
 В случает использования EX4200, EX4500, EX4550 - любой подходит для роли backup.
-===Linecard===
+====Linecard====
 *выполняет роль линейной карты, то есть как дополнительный свитч с портами
 *не запускает chassis control protocols
 *не может даже определить состояния интерфейсов (или ошибок), которые были настроены через master.
-===Mastership-priority===
+====Mastership-priority====
 Для назначения роли члену стека используется '''mastership-priority'''. Значение [0-255].
@@ Строка 59: / Строка 66: @@
 Свитч с mastership-priority = 0 всегда будет работать только в роли linecard.
-===Master Election===
+====Master Election====
 #Выбирается с наибольшим mastership-priority
 #Выбирается тот свитч, который был master в последний раз
@@ Строка 73: / Строка 80: @@
 #Включаем остальные свитчи
-==Member switch/Member ID==
+====Member switch/Member ID====
 Каждый свитч, поддерживающий функцию стекирования назначает себе member-id. Если включить свитчи не объединяя их в стек, каждый из них будет иметь member-id = 0.
@@ Строка 79: / Строка 86: @@
 Если в стеке был member, который физически отключили, его member-id более не будет использоваться мастером для присвоения member-id новому члену стека.
+Member-id работает как номер fps-слота.
+=Обновление софта=
+В кластере все свитчи должны обязательно иметь одинаковую версию софта.
+Софт можно поставить на весь кластер или на каждый свитч отдельно. Для этого используется одна и та же команда:
+ request system software add validate
+Если в стеке используются разные модели, на них все-равно должен стоять одинаковый софт.
+Чтобы избежать длительного перерыва при обновлении, можно использовать NSSU. Он позволяет обновить отдельно каждого member'а, а при использовании дополнительных HA фид, перерыв можно сделать очень коротким (или вообще без перерыва обновить).
+=High Availability=
+Само по себе использование стека из EX -  уже неплохое средство для HA.
+. LAG (Link Aggregation Groups): подключать CE двумя линками на разные members.
+Без HA: kernel и forwarding state инфо не сохраняется инфо на обе RE. Поэтому процесс конвергенции занимает время, также как и процесс switchover может занимать до нескольких минут, до окончания процесса не передается трафик.
+#GRES (Graceful routing Engine switchover): kernel и forwarding state инфо хранится на обеих RE, что обеспечивает отсутствие конвергенции и сильно сокращает перерыв в передаче графики при switchover.
+#NSB (nonstop bridging): l2-протоколы, поддерживающие NSB, не падают при switchover. Инфо l2-протоколов хранится на обеих RE.
+#NSR (nonstop routing): l3-протоколы, поддерживающие NSR, не падают при switchover. Инфо хранится на обеих RE.
+#Graseful Protocol Restart: передача трафика не прерывается при switchover. interface и kernel инфо зарезервирована. Когда Control plane роутера падает, роутер не сразу сообщает об этом своим соседям а ждет заданный промежуток времени. Но! сосед тоже должен уметь GR.
+=Управление=
+Из-за наличия нескольких свитчей в стеке к кластера появляется дофига консольных и mgmt портов. К какому подключиться?
+При подключении к любому, нас отредиректит к master.
+Если мастер сменился, то console сессия отключится от старого master и переустановится к новому.
+vme-port - виртуальный, используется для управления. По логинении на ip, настроенный на vme порту, кластер редиректнет вас на master switch.
+=Конфигурация=
+=Траблшутинг=
+ show virtual-chassis
+ show virtual-chassis vc-ports all-members
+=Дополнительная информация=
+*[[L2 switching and VLANs]]
+*[[Provider bridging]]
+*[[Spanning-Tree protocol (STP)]]

Virtual Chassis: различия между версиями