Настройка коммутаторов cisco nexus
Обновлено: 06.07.2024
Для примера настрою коммутатор Cisco Nexus N3K-C3064PQ-10GX.
Коммутатор имеет 48 портов SFP+ 10 Gb/s и 4 QSFP+ 40 Gb/s, для соединения между коммутатором и серверами я использую DAC кабеля до 5м, но можно также использовать более длинные AOC оптические.
При первом подключении через консоль, я указал пароль для пользователя admin:
Переключился в режим конфигурирования и указал файл прошивки:
Сохранил конфигурацию, перезагрузил коммутатор и убедился что он загрузился с указанной ранее прошивки:
Далее посмотрим текущую и сохраненную конфигурации:
Во время включении коммутатора при необходимости можно перейти в режим загрузчика:
Из загрузчика также можно вручную запустить коммутатор с указанной прошивки:
Сразу выберем режим портов, так как после этого действия необходима перезагрузка устройства (например я обычно использую 48x10g+4x40g):
Добавим необходимые VLAN и при необходимости описания:
Приведу примеры настройки access и trunk портов:
Приведу пример настройки гибридного порта, Vlan 300 без тега, а все остальные vlan с тегом:
По умолчанию порты 1-48 настроены на скорость 10 Gb/s, чтобы подключить 1 Gb/s укажем:
Укажем часовой пояс и ntp сервер для синхронизации времени:
Если будут создаваться interface vlan (SVI), то активируем feature interface-vlan:
Приведу пример создания interface vlan (SVI):
Пример указания маршрута по умолчанию:
Пример настройки mgmt порта:
Можно указать hostname:
Приведу примеры просмотра различной информации:
Uptime коммутатора можно посмотреть командой:
Разрешим использование SFP модулей от сторонних производителей:
Также при использовании сторонних SFP и DAC кабелей я указывал команды ниже для интерфейсов, так как без них либо не было линка, либо он пропадал через некоторое время, например:
Также можно выключить flow-control если он не выключился автоматически:
Настроим завершение консольных сессий через 30 минут:
Пример ограничения доступа к коммутатору по IP адресам:
Пример активации telnet (но я рекомендую использовать ssh):
Для очистки конфигурации используется команда:
Пример копирования текущей и сохраненной конфигурации на TFTP сервер:
Пример восстановления конфигурации с TFTP сервера:
Смотрите также мои статьи:
Вливайтесь в общение
Добавить комментарий Отменить ответ
Здравствуйте, возможно может и сталкивались вы с такой проблемой на этом Nexus.
Есть Nexus 3064, он у меня в роли ядра.
Поднято около 30 интерфейс вланов,работает вся система чётко, активных линков около 25, то есть с этого коммутатора уходит на коммутаторы доступа, и вот есть проблема, к примеру на коммутаторе доступа пропадает электричество на 1 минуту, ну или на пол дня, потом электричество появилось, и поднимается линк на обоих сторонах, у меня на нексусе поднимается цп до 80 процентов, не надолго но поднимается, ладно бы это был 1 коммутатор ладно ещё, но когда их 10 отключается по питанию, но nexus просто замирает на 30 минут.Я честно уже незнаю что делать.
Пожалуйста помогите если это возможно.
Vyacheslav пишет:
Вы скинули стандартные логи изменения состояния линка, а насчет нагрузки на CPU, то некоторые функции типа DHCP Snooping могут влиять, хотя вряд ли так сильно, пересмотрите конфигурацию, можете еще посмотреть нет ли флуда multicast и broadcast в этот момент, также желательно чтобы в каждом vlan не было много клиентов или хотя бы чтоб между ними был изолирован трафик.
Ну во влане одна подсеть /24, и до 150 где то абонов в влане, когда линк поднимается broadcast и unicast поднимается, и по графикам(Cacti) поднимается в том влане в котором пропадал коммутатор(линк),в других вланах не поднимается,а вот изолировать трафик это хорошая идея.
Что можете посоветовать в данной ситуации?
Vyacheslav пишет:
Поделите сеть на больше VLAN, как минимум чтобы VLAN на устройство доступа был, а на устройствах доступа изолируйте трафик между портами, как изолировать трафик я писал статьи, а IP адреса ваших подсетей можно выдавать в разных VLAN.
1)В каждом влан свой шлюз.
2)Да это идея хорошая, переназначать адреса и вланы на коммутаторах это проблематично.
Кроме смены вланов никак и переназначения адресов?
Здравствуйте.
Вячеслав, процесс настройки в Вашей статье практически полностью совпадает с моими настройками N3K-C3064PQ-10GX. Но моя железка продолжает через 10-25 минут отключать 10G sfp (совместимые). Может сможете помочь советом?
Vyacheslav пишет:
Здравствуйте. Посмотрите логи и детальную статистику по sfp модулю там скорее всего можно увидеть причину, ну и я так понял у Вас указаны вручную скорость, дуплекс, отключено автосогласование, примеры команд в статье есть. Еще может быть плохой оптический сигнал и пропадать линк.
Благодарю за ответ!
У нас нет возможности обращаться в Cisco TAC за помощью по ряду причин. Поэтому ищем пути решения самостоятельно.
Да, скорость, дуплекс и автосогласование отключены согласно Ваших рекомендаций.
Самое интересное, что если использовать 1Г трансиверы, такое поведение отсутствует, даже при включенном автоматическом согласовании.
Software
BIOS: version 5.0.0
NXOS: version 9.3(7)
BIOS compile time: 06/05/2018
NXOS image file is: bootflash:///n3000-compact.9.3.7.bin
NXOS compile time: 3/10/2021 3:00:00 [03/10/2021 15:39:29]
Здравствуйте, Вячеслав!
Благодарю за Ваш отклик!
Увлекся поиском решения и не ожидал что Вы так быстро ответите.
Версия установлена крайняя, с сайта производителя.
Software
BIOS: version 5.0.0
NXOS: version 9.3(7)
BIOS compile time: 06/05/2018
NXOS image file is: bootflash:///n3000-compact.9.3.7.bin
NXOS compile time: 3/10/2021 3:00:00 [03/10/2021 15:39:29]
Хотя до этого была рекомендуемая. Максимум по времени, коммутатор работал без залипания 3 недели. Но последнее время участились случаи отказа, пришлось отключить одно плечо.
Логи ниже, но пока мне не понятна причина (три последние записи с истории самого порта).
186) Event:ESQ_REQ length:38, at 648542 usecs after Thu Mar 18 12:42:58 2021
Instance:0x1A000000, Seq Id:0x1, Ret:SUCCESS
[E_MTS_TX] Dst:MTS_SAP_TEM(1570), Opc:MTS_OPC_ETHPM_PORT_PRE_CFG(61441)
187) FSM: Transition at 648626 usecs after Thu Mar 18 12:42:58 2021
Previous state: [ETH_PORT_FSM_ST_WAIT_PRE_CFG]
Triggered event: [ETH_PORT_FSM_EV_PRE_CFG_DONE]
Next state: [ETH_PORT_FSM_ST_LINK_INIT]
188) FSM: Transition at 615642 usecs after Thu Mar 18 12:43:13 2021
Previous state: [ETH_PORT_FSM_ST_LINK_INIT]
Triggered event: [ETH_PORT_FSM_EV_PACER_TIMER_EXPIRED]
Next state: [FSM_ST_NO_CHANGE]
Curr state: [ETH_PORT_FSM_ST_LINK_INIT]
vPC (Virtual Port-Channel) - технология виртуализиции, доступная на коммутаторах Cisco Nexus (кроме Nexus 2K). Позволяет два Nexus коммутатора объединять в единое логическое L2 устройство с точки зрения нижестоящих коммутаторов или устройств (серверов).
Технология относится к семейству протоколов под названием MCEC - Multichassis EtherChannel (MLAG; vPC это вариант реализации MLAG от Cisco), в чем-то даже похожа на технологии объединения коммутаторов Catalyst - VSS и StackWise. Основное отличие от VSS состоит в том, что в vPC каждый коммутатор имеет независимый Control Plane и Management Plane, это дает гарантию того, что при отказе какого-либо компонента в ПО (OSPF процесс, например), сеть продолжит функционировать, в отличие от VSS, где сбой OSPF на Active коммутаторе не вызовет переключения Control Plane на Standby.
1.Компоненты vPC и терминология
vPC строится на базе двух коммутаторов, называемых vPC пирами (vPC peers). Один из них имеет роль vPC primary, второй vPC secondary. Primary коммутатор отвечает за генерацию BPDU (при этом данный коммутатор может и не быть STP Root), отвечает на ARP запросы, и именно он продолжает работать при потере vPC Peer Link-а. Для того, чтобы посмотреть, какой из коммутаторов является primary, а какой secondary используется команда:
Выбор роли (role priority) осуществляется на основе настраиваемого приоритета (1-65535). Коммутатор с меньшим значением приоритета выбирается как vPC primary. В случае, если приоритет одинаковый, primary становится тот, у кого меньше системный MAC адрес. Настраивается приоритет внутри vPC домена, например:
vPC роль не вытесняемая (non-preemptive)!
В vPC существуют так же следующие статусы пиров (в случае перезагрузки или выхода из строя primary vPC пира):
"secondary, operational primary" - коммутатор был изначально выбран как secondary, но в результате отказа второго коммутатора, в данный момент он работает как primary.
"primary, operational secondary" - коммутатор был изначально выбран как primary, но после возврата его в работу после сбоя или перезагрузки, например, он работает как secondary в данный момент.
Роли primary и secondary влияют так же на поведение коммутаторов в случае разрыва vPC Peer-Link. Secondary коммутатор выключает все vPC Member интерфейсы и VLAN интерфейсы (SVI), участвующие в vPC. После чего весь трафик течет через vPC primary.
1.1 Описание компонент и порядок настройки:
vPC нужно настраивать в строго определенном порядке:
1) Настройка vPC домена
2) Настройка vPC Peer Keepalive, убедиться что "peer is alive"
3) Настройка vPC Peer Link
4) Настройка vPC Member Ports
Перед началом настройки необходимо глобально включить функционал vPC и LACP на коммутаторе:
1) vPC домен (vPC domain) - Определяет 2 коммутатора, участвующих в vPC. Номер vPC домена (vPC domain ID) должен совпадать на коммутаторах, каждый коммутатор может принадлежать только к одному vPC домену!
Номер vPC домена используется для генерации vPC system-mac, который является общим для двух коммутаторов.
vPC system-mac:
00:23:04:ee:be:xx, где xx - номер vPC домена в шестнадцатеричной системе.
vPC local system-mac:
Уникальный MAC адрес коммутатора, либо VDC (если речь о Nexus 7K).
vPC system-mac используется, когда 2 коммутатора (Nexus 7K, например) представляются как единое логическое L2 устройство, vPC local system-mac используется в ситуации, когда каждое устройство выступает самостоятельно (например, когда присутствует Orphan порты).
Оба типа MAC адреса используются в качестве LACP system ID (vPC system-mac при построении LACP к vPC паре; vPC local system-mac при построении LACP только к одному из коммутаторов).
2) vPC Peer Keepalive - используется для трекинга vPC пира и обнаружения сценария dual active, в случае, если vPC Peer Link вышел из строя.
Для создания этого линка может быть использован любой L3 интерфейс коммутатора.
Рекомендации по настройке Peer Keepalive:
-Использовать отдельный L3 Etherchannel на двух разных линейных картах (1GE/10GE), в отдельном VRF. (предпочтительный вариант для N7K)
-Использовать Mgmt0 интерфейсы коммутаторов (предпочтительный вариант для N5K, можно использовать и с N7K, соединив интерфейсы супервизоров через обычный L2 коммутатор, не напрямую!)
-Использовать SVI (не рекомендуется к использованию, может привести к развалу vPC в некоторых случаях).
В случае использования SVI интерфейсов для Peer Keepalive крайне желательно (можно сказать обязательно) использовать отдельный L2 Trunk между коммутаторами и отдельный не vPC VLAN (на vPC Peer линке не разрешать этот VLAN). А при использовании MST так же настроить отдельный Instance.
4) vPC Member Ports - интерфейсы, находящиеся в L2 Port-Channel и смотрящие в сторону нижестоящих коммутаторов (серверов), через эти интерфейсы проходит Data трафик. VLAN-ы, которые разрешены на этих портах называются vPC VLAN-ами. Назначенные номера vPC должны совпадать на двух коммутаторах. Обычно, для простоты конфигурации и траблшутинга, номер vPC (vPC ID) выбирается таким же как номер Port-Channel интерфейса.
Как и в случае с Peer Link, для N7K должен использоваться одинаковый тип линейных карт на каждом из vPC пиров.
1.2 vPC Loop Prevention и Orphan:
Для защиты от петель vPC использует следующее правило:
Трафик, который пришел на коммутатор с vPC Peer Link не может быть передан на vPC Member Port, но может быть передан на Orphan порт или L3 интерфейс. За это правило отвечает механизм "vPC Check".
Orphan (eng: сирота) - ситуация, когда нижестоящее устройство имеет только одно подключение к одному из коммутаторов Nexus, формирующих vPC пару. Таких ситуаций следует избегать, но если все же есть необходимость подключить Orphan устройство, то это подключение должно быть выполнено к vPC Primary!
1.3 vPC Consistency:
Для корректной работы vPC ряд настроек и параметров на коммутаторах (vPC пирах) должен совпадать.
vPC различает два типа совпадения параметров (два типа consistency, если проще) - Type 1 и Type 2. Для работы vPC обязательно должны совпадать Type-1 параметры (существуют как глобальные - global, так и для интерфейсов - interface), например:
- STP протокол (PVST, Rapid-PVST, MSTP)
- BPDU Filter, BPDU Guard, Loop Guard
- Настройки MST региона
- Режим LACP, скорость и дуплекс на портах
В случае несовпадения какого-либо из Type-1 параметров vPC отключается на secondary коммутаторе: "Type1: vPC will be suspended in case of mismatch".
Для проверки параметров используется команда:
1.4 vPC и STP:
-После создания vPC Peer-Link на нём так же включается STP Bridge Assurance.
-Только vPC Primary коммутатор генерирует BPDU, но при этом он может не являться STP Root. В случае конфигурации по умолчанию vPC Primary будет являться STP Root (т.к. выборы происходят на основе наименьшего системного MAC, как и в STP). Каждый коммутатор использует свой System MAC в качестве BID (Root ID). Для нижестоящих устройств Root Primary коммутатора.
-vPC Secondary только передает полученные BPDU от нижестоящих коммутаторов Primary пиру через Peer Link.
-vPC пиры синхронизируют состояние STP портов (STP Port States) на своих vPC Member интерфейсах.
-По умолчанию каждый коммутатор имеет свой BID=System MAC+Priority.
У vPC для STP есть оптимизация под названием "Peer-switch", которая позволяет видеть оба vPC пира как единый STP Root. Коммутаторы используют общий Virtual BID, который формируется из vPC system-mac и приоритета. Эта оптимизация позволяет не перестраивать STP дерево в случае падения Primary vPC пира и не тратить время на сходимость (актуально в Hybrid Setup дизайне).
Приоритет STP должен при этом быть настроен одинаковым для всех VLAN - иначе оба коммутатора не будут выполнять роль общего STP Root коммутатора! (т.к. BID=MAC+Priority).
Если нижестоящий коммутатор подключен по vPC (vPC-attached): Root BID.
Если нижестоящий коммутатор подключен по STP (STP-attached): Root BID; Bridge MAC.
Настройка vPC peer-switch:
При настройке Peer-switch теряется гибкость управления для STP в случае STP-attached устройств, т.к. оба коммутатора становятся STP Root, то нет возможности настроить балансировку по классической схеме с использованием разных Root коммутаторов для разных VLAN.
Можно настраивать балансировку путем изменения STP Cost на нижестоящем коммутаторе, но этот подход не очень гибкий, хотя имеет место быть.
А настройки на основе приоритетов портов не дадут никакого результата, т.к. в любом случае для выбора кратчайшего пути STP сперва анализирует Lowest sender BID - а это System MAC каждого коммутатора Nexus, т.е. в любом случае в приоритете будет только один из них.
Более простым вариантом является опция под названием STP pseudo-information.
Она позволяет независимо настраивать STP Bridge Priority и STP Root Priority для STP-attached коммутаторов, позволяя тем самым выполнять настройки по балансировке для каждого VLAN.
1.5 vPC и HSRP:
---
2.Сценарии vPC, примеры настройки
2.1 Classic vPC:
vPC настраивается между двумя коммутаторами N7K, в качестве нижестоящего коммутатора используется N5K (либо любой другой, либо сервер) на котором настраивается обычный LACP.
"force" - команда позволяет сформировать Port-Channel на интерфейсах с разными изначальными настройками, копирует все настройки с первого интерфейса в группе на оставшиеся.
Команды для проверки:
Для vPC-attached коммутаторов Root ID будет идентичен с Bridge ID и иметь значение 0023.04ee.be01, а priority=0.
2.3 Back-to-Back vPC:
vPC настраивается на N7K в сторону N5K и наоборот. Между коммутаторами при этом получается один большой Port-Channel.
Настройка коммутаторов N7K1 и N7K2 полностью соответствует настройкам из примера 2.1 (Classic vPC).
Номер Port-channel интерфейса, как и VPC ID на коммутаторах N5K1, N5K2 может быть использован отличный от номера Port-channel интерфейса и VPC ID на N7K1 и N7K2.
FEX (Fabric Externder) - семейство VNTag (IEEE 802.1BR) "коммутаторов" Cisco Nexus 2000 (N2K). Позиционируются как ToR устройства. FEX не поддерживают локальную коммутацию и не имею консоли для управления.
Для их работы обязательно необходим родительский коммутатор (Parent Switch), через которого происходит вся коммутация и управление. В качестве Parent могут выступать Cisco Nexus 5K,6K,7K,9K. Для родительского коммутатора FEX выступает в роли удаленной линейной карты (Remote Line Card).
Плюсы и минусы использования FEX:
По-умолчанию все FEX используют так называемый "static pinning". Т.е. N2K статически мапирует свои нижестоящие интерфейсы (Host facing interfaces) к Uplink интерфейсам (Fabric interfaces). Если Fabric интерфейс только 1, то все порты FEX будут соответствовать только одному этому Fabric интерфейсу, по которому происходит подключение к родительскому коммутатору. Но если Fabric интерфейса 2 и более, то FEX произведет статическое соответствие своих Host интерфейсов к вышестоящим интерфейсам фабрики, разделив их поровну.
Например, при наличии 2-х Fabric интерфейсов половина FEX портов будет соответствовать первому Fabric интерфейсу, другая половина второму. При выходе из строя одного Fabric интерфейса, половина Host портов на FEX так же станет недоступна (они будут выключены), динамического перераспределения этих портов на рабочий Fabric интерфейс не произойдет до тех пор, пока не перезагрузится FEX коммутатор! После перезагрузки все Host интерфейсы перераспределятся на рабочий Fabric интерфейс.
Именно поэтому между Parent коммутатором и FEX рекомендуется использовать Port-Channel. Все нижестоящие порты FEX в этом случае мапируются к одному единственному Port-Channel интерфейсу и трафик распределяется, используя механизмы хеширования (Dynamic pinning).
4.Примеры настройки FEX
4.1 vPC+FEX (Host vPC):
Рекомендуемый дизайн, поддерживается как на N5K/N6K, так и на N7K. vPC строится только от FEX до серверов, каждый FEX подключается только к 1 родительскому коммутатору (Single-homed FEX).
Команды для проверки:
4.2 vPC+FEX (EvPC):
Дизайн поддерживается только на N5K/N6K. vPC строится как от FEX до серверов (Host vPC), так и внутри фабрики (Fabric vPC), каждый FEX подключается к двум родительским коммутаторам (Dual-homed FEX). ISSU в таком дизайне не поддерживается, т.к. вызывает перезагрузку обоих FEX при обновлении одного из Parent коммутаторов.
Т.к. в таком дизайне конфигурацией каждого FEX могут управлять оба Parent коммутатора, то очень легко сделать несоответствие в конфигурации для одних и тех же FEX портов с разных родительских коммутаторов (например, N5K1 e101/1/1 - access VLAN10; N5K2 e101/1/1 - access VLAN20), и при этом с точки зрения Control-Plane ошибки не будет, а вот с точки зрения Data-Plane будут проблемы.
Для N5K/N6K поддерживается функционал Config Sync, с помощью которого можно синхронизировать конфигурации на разных Parent коммутаторах. Как правило его применяют именно в таком дизайне, хотя можно использовать и без EvPC.
С точки зрения конфигурации для EvPC не нужно настраивать vPC от FEX в сторону серверов (host vPC mode), коммутатор сам выполняет эту настройку, автоматически присваивая внутренний номер vPC, настройка вручную не поддерживается.
Коммутаторы Cisco Nexus серии разработаны специально для центров обработки данных и обладают многими уникальными функциями и возможностями,
предназначенными для самых ответственных узлов сети, центров обработки данных.
Cisco Fabric Extenders (fex) позволяет объединять оборудование в единую структуру.
Его основу составляют «материнские» коммутаторы (серий Cisco Nexus 5000, Nexus 7000 ), к которым подключаются выносы FEX , выполняющие функции удаленной линейной платы.
В качестве выноса используются коммутаторы Nexus 2000
Nexus 2000 не имеют собственной системы управления. Они подцепляют операционную систему и конфиги от родительского коммутатора.
Все удаленные порты на FEX будут видны через CLI так, как будто они физически присутствуют в коммутаторе.
Конфигурация
Cхема подключения следующая
Коммутаторы Nexus 2000 (далее N2K-1 и N2K-2 )подключены оптоволокном в коммутатор Nexus 5000 (далее N5K-1 ).
Для увеличения канала используется технология PortChanel , каждый коммутатор N2K подключен к родительскому 2-мя портами.
Скорость каждого порта 10Gbit/s, на выходе мы получаем 20Gbit/s.
Настройка
Первым делом включаем сам сервис fex , вводим в режиме конфигурации команду:
Дальше создаем интерфейсы PortChannel 101 и PortChannel 102 , для каждого из коммутаторов, так мы имеем в топологии по 2 физических линка на каждый коммутатор.
Для этого в режиме конфигурации вводим команды.
После ввода этих команд создадутся два интерфейса
PortChannel 101 и PortChannel 102
Далее будут настраиваться именно эти интерфейсы.
Далее нужно указать, что эти 4 физических порта необычные, а порты для fex
Для этого в режиме конфигурации, указываем на PortChannel 101 и PortChannel 101 режим fex
Также необходимо указать номер выносного шасси командой fex associate :
В результате эти же настройки пропишутся на физические порты.
Посмотреть из можно так:
Посмотреть состояние fex можно командой:
Состояние Online , говорить о том, что дочерний коммутатор готов к работе.
Более детально можно посмотреть так:
В выводе этой команды можно увидеть, что дочерний коммутатор был обнаружен на портах
Eth1/5 и Eth1/6 , а также новые появившееся порты Eth101/1/1 , Eth101/1/2 и т.д, это порты которые находятся на N2K-1
Войти
Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal
Cisco Nexus 1000V для vSphere. Что нужно знать перед установкой
Cisco Nexus 1000V имеет два компонента, которые должны быть установлены, Virtual Supervisor Module (VSM) и модуль Virtual Ethernet Module (VEM).
• Virtual supervisor module (VSM) - это программное обеспечение управления распределенного виртуального коммутатора в Cisco Nexus 1000V. Оно работает на виртуальной машине (VM) и на базе программного обеспечения Cisco NX-OS.
• Virtual Ethernet module (VEM) - это часть Cisco Nexus 1000V, которая фактически передает трафик данных. Она работает на хосте VMware ESX 5.5. Несколько модулей VEM контролируются одной VSM. Все VEM, которые образуют домен коммутаторов, должны быть в том же виртуальном центре обработки данных, где находится и VMware Virtual Center
Когда оба компонента установлены и установлена связь от VSM к vCenter, установка Cisco Nexus 1000V будет считаться завершенной.
Шаг 1: Необходимо убедиться, что версия VMware vSphere совместима с Cisco Nexus 1000V
В таблице ниже приведен список версий компонентов VMware требующихся для Cisco Nexus 1000V:
Видео: Установка Зарезервированной Пары (Redundant Pair) модулей VSM из OVA-файла, используя приложение установки
Следуйте инструкциям в этом видео. Вы изучите:
• Как установить primary VSM в режиме Active
• Как установить secondary VSM в режиме Standby в конфигурации высокой доступности
Время видео - 10 минут
Шаг 3: Установка Virtual Ethernet Module (VEM)
Есть два варианта установки VEM. Вы можете использовать или VMware Update Manager (VUM) или интерфейс командной строки vSphere command line interface (CLI).
Вариант 1: Установка используя VUM
Следуйте инструкциям в этом видео. Вы изучите:
• Подробные настройки виртуального коммутатора хоста
• настройки VUM
• подключение vCenter
Время видео - 5 минут
Вариант 2: Установка используя CLI
Следуйте инструкциям в этом видео. Вы изучите:
• Как использовать командную строку VMware vSphere CLI для установки VEM
• Как добавить хост ESX/ESXi в распределенный коммутатор Cisco Nexus 1000V DVS
Время видео - 1 минута
Советы для ускорения установки
Следуйте инструкциям в этом видео. Вы изучите:
• Как распознать общие проблемы установки
• Как устранить проблемы и проверить корректность установки
И как говорится, если ничего не помогло, читайте инструкцию: Read more about Cisco Nexus 1000V installation on VMware vSphere
Кое-что из теории.
Cisco Nexus 1000V – это распределенный коммутатор (DVS — distributed virtual switch). Данный коммутатор представляет собой виртуальную машину, которая устанавливается в инфраструктуру vSphere в виде модуля (Virtual Supervisor Module - VSM), и сам виртуальный коммутатор, который устанавливается в ядро гипервизора в виде обновления (Virtual Ethernet Module - VEM).
VSM может быть зарезервирован по технологии High Availability (HA): один - active, второй - stand-by.
Архитектура ЦОД с Cisco Nexus 1000V:
Конструктивно Cisco Nexus 1000v – модульный коммутатор. Первые два модуля зарезервированы под менеджмент (VSM) и остальные 64 модуля под подключение виртуальных машин (VEM).
Вот сравнение Cisco Nexus 1000v vSwitch со стандартным vSphere DVS.
В VSM есть 3 интерфейса – Control, Management и Packet.
Control – мониторит статус VEM и управляет ими.
Management – порт для управления супервизором.
Packet – порт для работы протоколов CDP, IGMP и LACP.
В рекомендациях говорится, что под Control и Packet необходимо использовать разные VLAN. Выглядит разумно, так же стоит учесть – что Control должен быть в одном VLAN с Management интерфейсами хостов.
Cisco Nexus 1000 является распределительным свитчем, представленный в виде машины, устанавливаемой в основу оборудования Virtual Supervisor Module, и непосредственно сам виртуальный свитч, устанавливаемый в ядро гипервизора в качестве обновления Virtual Ethernet Module.
По своей конструкции Cisco Nexus 1000v является модульным свитчем. Первый и второй модули свитча подстроены под менеджмент, а остальные 64 направлены на подключение виртуальных машин. Данный свитч представляет собой основу виртуализированных сервисов.
На данный момент существует две лицензированных версии Cisco Nexus 1000, это Advanced Edition и Essential Edition. Вторая версия является бесплатной, но за расширение и за каждый сокет потребуется заплатить по 695 долларов.
Необходимые обязательства для VSM:
- Отличающийся отдельный ip адрес;
- Заранее установленные на продукте VMware Update Manager (VUM) и vCenter.
Для установки Cisco Nexus 1000v есть несколько требований:
- Хост обязан иметь один или более сетевых физических интерфейсов у свитчах VMware в стандартных версиях.
- Обычный VMware-свитч не должен иметь ранее запущенных на нем машин, для того чтобы предотвратить потерю соединения при миграции.
- Нужно подключить VSM соединение к серверу vCenter.
- Перед установлением ВСМ, не должно быть установлено никаких VEM.
- Для установки нужны права администрации в-центра.
Что касается хостов:
• Необходима установка vCenter, vSphere Client.
• Установка оборудования ESX/ESXi по версии 4.1.
• Наличие лицензированной Vмware Enterprise Plus и двух сетевых интерфейсов по устойчивости отказов.
• Vmnics имеют единообразные параметры.
Конструкторы этого продукта при его производстве создали множество возможностей для мобильной и оперативной настройки сети. Увеличили уровень безопасности, особенно при удаленном доступе, таких как копирование и резервирования самой важной информации на носителях, что позволило порадовать предпочтения клиентов и удовлетворить их потребности. Коммутаторы Cisco Nexus 1000 имеют отличительные параметры работы, обладают отличительной гибкостью, надежностью, эффективностью, владеют возможностью справится с большими задачами по передачи данных в виртуальной среде. Создают возможность расширять платформу для виртуально-сетевых машин. Они имеют дополнительные требования:
Читайте также: