Virtual Chassis: различия между версиями
м |
|||
| (не показано 6 промежуточных версий этого же участника) | |||
| Строка 1: | Строка 1: | ||
{{#description2:Компоненты virtual chassis. Master/Backup/Linecard. Обновление софта. High Availability. Управление virtual chassis. Информация для подготовки к экзаменам Juniper.}} | |||
=Общее= | =Общее= | ||
Кол-во свитчей, объединенных в одно шасси зависит от версии софта и модели. | Кол-во свитчей, объединенных в одно шасси зависит от версии софта и модели. | ||
| Строка 4: | Строка 5: | ||
Можно объединять разные модели в стек. Софт при этом должен быть одинаковым у всех свитчей. | Можно объединять разные модели в стек. Софт при этом должен быть одинаковым у всех свитчей. | ||
==Компоненты== | ==Компоненты== | ||
=== | ===VC-port=== | ||
Для объединения в стек используются специальные порты VCP (Virtual Chassis Ports). | Для объединения в стек используются специальные порты VCP (Virtual Chassis Ports). | ||
| Строка 15: | Строка 16: | ||
Если требуется емкость более 40G между членами стека (стековые порты и кабели поддерживают именно такую скорость), можно сделать 2 линка между свитчами. | Если требуется емкость более 40G между членами стека (стековые порты и кабели поддерживают именно такую скорость), можно сделать 2 линка между свитчами. | ||
Оптические порты с одинаковой скоростью передачи, выступающие в роли VCP, объединяются в LAG (bundle). | Оптические порты между двумя свитчами с одинаковой скоростью передачи, выступающие в роли VCP, автоматом объединяются в LAG (bundle). Порты с разной скоростью в LAG не соберутся. | ||
Когда оптический порт настроен в роли VCP, он не может использоваться в других целях. | Когда оптический порт настроен в роли VCP, он не может использоваться в других целях. | ||
VCP используются как для служебного трафика между свитчами, так и для передачи трафика между свитчами. | |||
Все 40Gb QSFP+ порты на EX4300 под дефолту используются как VCP. | |||
Все 10Gb порты могут быть настроены и использоваться в качестве VPC. | |||
===Master/Backup/Linecard=== | ===Master/Backup/Linecard=== | ||
| Строка 73: | Строка 80: | ||
#Включаем остальные свитчи | #Включаем остальные свитчи | ||
===Member switch/Member ID=== | ====Member switch/Member ID==== | ||
Каждый свитч, поддерживающий функцию стекирования назначает себе member-id. Если включить свитчи не объединяя их в стек, каждый из них будет иметь member-id = 0. | Каждый свитч, поддерживающий функцию стекирования назначает себе member-id. Если включить свитчи не объединяя их в стек, каждый из них будет иметь member-id = 0. | ||
| Строка 81: | Строка 88: | ||
Member-id работает как номер fps-слота. | Member-id работает как номер fps-слота. | ||
=Обновление софта= | |||
В кластере все свитчи должны обязательно иметь одинаковую версию софта. | В кластере все свитчи должны обязательно иметь одинаковую версию софта. | ||
| Строка 89: | Строка 96: | ||
Если в стеке используются разные модели, на них все-равно должен стоять одинаковый софт. | Если в стеке используются разные модели, на них все-равно должен стоять одинаковый софт. | ||
Чтобы избежать длительного перерыва при обновлении, можно использовать NSSU. Он позволяет обновить отдельно каждого member'а, при этом | Чтобы избежать длительного перерыва при обновлении, можно использовать 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 | ||
show virtual-chassis vc-ports all-members | show virtual-chassis vc-ports all-members | ||
=Дополнительная информация= | |||
*[[L2 switching and VLANs]] | |||
*[[Provider bridging]] | |||
*[[Spanning-Tree protocol (STP)]] | |||
Текущая версия на 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