Fabric extender что это
antiCisco blogs
блоги по технологиям и оборудованию cisco от инструкторов
Cisco Fabric Extenders
Итак, прежде чем продолжить тему про vPC, нам просто необходимо затронуть еще одну технологию, которую Cisco предлагает на коммутаторах Nexus5k/7k. Речь сейчас пойдет о Cisco FEX.
По сути FEX представляет собой некую замену традиционным коммутаторам уровня доступа. Специальная серия коммутаторов Cisco Fabric Extenders Nexus 2000 интегрируются с родительским коммутатором, которым может быть более старшая железка 5000/5500/5600/7000/7700. У N2K напрочь отсутствует Control, Management Plane (да и даже умных ASIC’ов то нет). Они подцепляют операционную систему и конфиги от родительского коммутатора.
Прим. FEX не осуществляют локальную коммутацию трафика. Вместо этого весь трафик отправляется по uplink’ам на вышестоящий коммутатор, где и обрабатывается всеми политиками.
Т.е. логически топология, в которой есть один родительский коммутатор и много FEX’ов будет представлять из себя структуру, в которой есть всего один коммутатор (да, т.е. никакого STP или IGP между FEX и родителем), у которого имеется приличное количество линейных плат.
Соответственно все удаленные downlink порты на FEX (их еще называют host портами) будут видны через CLI так, как будто они физически присутствуют в коммутаторе.
При внедрении FEX, Вы должны учесть некоторые моменты относительно host портов:
Прим. Коммутаторов N2K существует великое множество. Поэтому при выборе модели нужно учитывать такие параметры, как количество и скорость host/fabric портов. А также количество fabric портов (uplink’и в сторону родительского коммутатора). Кол-во fabric портов фиксировано для каждой модели и не превышает 8 линков по 10Гб (т.е. теоретическое бутылочное горлышко). Актуальные модели можете посмотреть здесь: http://www.cisco.com/c/en/us/products/collateral/switches/nexus-2000-series-fabric-extenders/data_sheet_c78-507093.html?cachemode=refresh
Конфигурация и верификация
При настройке FEX первым делом необходимо включить саму fex-фичу (Я буду приводить примеры на коммутаторе Nexus 5500). Делается это командой feature fex. Никаких дополнительный лицензий не требуется.
Из вывода видно, что дочерний свитч N2K был обнаружен на портах E1/7-8 (Po100), а также в самом низу можно увидеть новые появившиеся интерфейсы E100/1/X, которые физически располагаются на FEX коммутаторе.
Также полезной может быть команда
Состояние Online говорит о том, что дочерний коммутатор полностью готов к работе (на него подгружено ПО, конфиги). Статус Discovered говорит о том, что железка видит еще один FEX на каких-то своих портах, но связь с ним не настроена на данный момент.
Cisco Adapter Fabric Extender
Available Languages
Download Options
The Cisco ® Fabric Extender architecture provides a highly scalable, unified server-access platform across a range of 100 Megabit Ethernet, Gigabit Ethernet, 10 Gigabit Ethernet, unified fabric, copper and fiber connectivity, rack and blade server, single OS, and virtual embedded bridge environments and directly connected virtual machines. The Cisco Nexus ® 5000 Series Switches is well suited to support today’s traditional Gigabit Ethernet while allowing transparent migration to 10 Gigabit Ethernet and unified fabric technologies. It also allows flexible and scalable deployment options for virtualized environments that use virtual embedded bridges and highly optimized direct virtual machine connectivity.
The Cisco Nexus 2000 Series Fabric Extenders are the first products in the Cisco Fabric Extender architecture. With more than 3000 customers and more than 3 million ports sold, the Cisco Nexus 2000 Series has proven its exceptional business value and operational simplicity. The Cisco Nexus 2000 Series Fabric Extenders act like remote line cards for a parent Cisco Nexus switch. Together, the Nexus 2000 Series Fabric Extenders and the parent Cisco Nexus switch form a distributed modular system.
The Cisco Fabric Extender architecture enables:
● Architecture flexibility: The common, scalable, and adaptive architecture across data center racks and points of delivery (PoDs) is server and server adapter agnostic and supports several connectivity options, physical topologies, and evolving needs.
● Highly scalable server access: Scalable Gigabit and 10 Gigabit Ethernet server access is offered, with no reliance on Spanning Tree Protocol.
● Simplified operations: One single point of management and policy enforcement using upstream Cisco Nexus switches eases the commissioning and decommissioning of server racks through zero-touch installation and automatic configuration of fabric extenders.
● Increased business benefits: The extremely cost-effective in-rack cabling solution offers consolidation, rack-space reduction, reduced power and cooling, investment protection through feature inheritance from the parent switch, and the capability to add functions without the need for a major equipment upgrade of server-attached infrastructure. All these factors contribute to reduced operating expenses (OpEx) and capital expenditures (CapEx).
● Open standards-based implementation: The Cisco Fabric Extender architecture uses IEEE 802.1Qbh standard. The introduction of the Cisco Adapter Fabric Extender (Adapter FEX) provides the same architectural benefits for the network interface card (NIC) as are provided for the physical access layer. Adapter FEX is logically an extension of the parent switch inside the server.
Interfaces of Adapter FEX are local logical ports on the parent switch. Adapter FEX uses innovative server connectivity (I/O connectivity) technology that enables on-demand creation of virtual NICs (vNICs) or virtual host bus adapters (vHBAs) on a single NIC. With Adapter FEX, a single physical adapter port is presented as multiple logical adapter ports to the server OS and the network, as if it were multiple physical adapter ports. A dual-port 10GE Adapter FEX can support hundreds of Peripheral Component Interconnect Express (PCIe) standards-compliant virtual interfaces that can be configured by the server administrator.
Each vNIC and vHBA created on the adapter automatically corresponds to a virtual Ethernet (vethernet) port on the parent switch to which the Adapter FEX is connected. Network properties are then assigned to each of the logical interfaces by the network administrator to help guarantee advanced quality of service (QoS) and granular bandwidth allocation.
Adapter FEX technology extends the current benefits of the Cisco Nexus 2000 Series Fabric Extender architecture to the server NICs, providing architecture flexibility, high scalability with 4000 logical interfaces, and one single point of management and policy enforcement, which result in increased business benefits.
In the Cisco UCS B-Series Blade Servers, the Cisco UCS M81KR Virtual Interface Card (VIC) is the first product that implements Cisco Adapter FEX technology.
Expanding this capability outside the Cisco UCS B-Series, the Cisco Nexus 5500 platform can support adapters implementing the Adapter FEX technology. An ecosystem of adapter vendors is now about to support this technology using the IEEE 802.1Qbh standard, the first vendor being Cisco itself, with the Cisco UCS P81E VIC (Figure 2), designed for use with Cisco UCS C-Series Rack-Mount Servers. Other adapter vendors will soon follow, providing adapters that support this capability. Both Cisco Nexus 5500 platform and the Cisco Nexus 2000 Series Fabric Extenders support the Adapter FEX technology across a variety of adapter platforms. Therefore, the offering can now be expanded outside a Cisco UCS environment to third-party server vendors that support IEEE 802.1Qbh-capable adapters.
Adapter FEX technology provides exceptional scalability and flexibility for both virtualized and non-virtualized environments, enabling on-demand, cost-effective solutions for data center server connectivity.
Features and Benefits
The Cisco Adapter FEX technology addresses these main challenges:
● Organizations are deploying virtualized workloads to meet the strong needs to save costs and reduce physical equipment. Virtualization technologies and the increased number of CPU cores, however, require servers to be equipped with a large number of network connections. For example, a typical VMware server has six 1 Gigabit Ethernet ports and two 4-Gbps Fibre Channel ports corresponding to the eight cables needed to connect to the eight upstream network ports. This increase has a tremendous impact on CapEx and OpEx because of the large number of adapters, cables, and switch ports, which directly affects power, cooling, and cable management costs.
● Network administrators struggle to link the virtualized network infrastructure and virtualized server platforms to the physical network infrastructure without degrading performance and with a consistent feature set and operational model.
● With a consolidated infrastructure, it is challenging to provide guaranteed bandwidth, latency, and isolation of traffic across multiple cores and virtual machines.
● Data center designs call for efficient cabling and reduced power and cooling because of stringent budgetary constraints.
● In virtualized environments, network administrators experience lack of visibility into the traffic that is exchanged among virtual machines belonging to the same host. Administrators also face challenges in establishing and enforcing policies and maintaining configurations and policies consistently across mobility events. They often also see a dramatic increase in the number of management points; disparate provisioning, management, and operational models; and inconsistency between the physical and virtual access layers.
Adapter FEX provides these benefits:
● Flexible and efficient deployment for non virtualized environments
● Scalability for traditional virtualized environments using virtual embedded bridges
● Highly optimized virtual machine connectivity for virtualized environments
Adapter FEX technology can be used in virtualized server environments to make the network infrastructure virtual machine aware (future). In this context, it is referred to as the Cisco Virtual Machine Fabric Extender (VM-FEX). This fabric extender integrates with the server virtualization management tool, allowing the user to bind a virtual machine to a vNIC carved out of Adapter FEX. This binding makes it possible to use an external hardware switch for switching the virtual machines traffic, having a single point of management and policy enforcement on the switch and enabling virtual machine migration support with port profile consistency. It provides tools with the same level of visibility, security, and troubleshooting for virtual machines as customers are accustomed to using for physical devices.
The portfolio of Cisco virtual machine networking products provides a variety of options that meet a range of customer needs:
● Hypervisor switching with the Cisco Nexus 1000V Series Switches
● Hardware switching with the Cisco VM-FEX and Cisco Nexus 5500 platform
● Hardware switching with the Cisco VM-FEX and Cisco Unified Computing System
Across all these solutions, virtual machine networking enables:
● Policy-based virtual machine networking
● Transparent network and security policy mobility with virtual machine migration
● Non-disruptive operational model, with the network administrator managing both virtual and physical networking resources with a consistent set of tools
Adapter FEX technology provides these main business benefits to IT departments:
● On-demand design and deployment of data center applications to enable cloud deployments with reuse of existing equipment: The wire-once model enables subsequent deployment of unified fabric and virtualization technologies.
● Exceptional scalability: 4000 logical host-facing ports are managed through a single point of configuration.
● Infrastructure efficiency through consolidation: The network is simplified by reducing the number of adapters, cables, and network ports, also reducing the number of network devices and the management overhead and thus lowering CapEx and OpEx.
● Ease and consistency of management: The server administrator can independently configure the adapter to a certain number of logical NICs, repurposing the physical NIC in real time as application needs evolve with little impact on the network and storage teams. At the same time, the network team can preconfigure the advanced network configuration, lowering the overall management overhead. Both teams continue to use traditional management tools with BIOS- or OS-based management tools on the server side and the command-line interface (CLI) on the network side.
Roles and Provisioning
Adapter FEX technology introduces outstanding flexibility and detailed control for both the network and server administrators. For each logical NIC that the server administrator defines on the Adapter FEX, the network administrator is responsible for the definition of the necessary network configuration.
On each Cisco Nexus switch connected to the server hosting the Adapter FEX, the network administrator creates port profiles (type vethernet) to be associated with the vNICs of the adapter. For example, if four vNICs (two for data, one for management, and one for backup) are required on the server, the network administrator creates one port profile for each type of vNIC (user_data, user_management, and user_backup) and configures relevant properties and policies (VLAN, bandwidth, QoS, application control lists [ACLs], etc.) in the port profile. Following is an example of a port-profile configuration:
port-profile type vethernet user_data
switchport trunk allowed vlan 2-100
switchport trunk native vlan 2
switchport mode trunk
port-profile type vethernet user_management
switchport access vlan 1
port-profile type vethernet user_backup
switchport mode trunk
switchport trunk allowed vlan 2-100
switchport trunk native vlan 2
mac port access-group mac_acl1
ip port access-group ip_acl1 in
ipv6 port traffic-filter ipv6_acl1 in
On the Adapter FEX, the server administrator now creates all the necessary vNICs and applies the relevant port profile as defined by the network administrator. To do this, the server administrator accesses the adapter configuration utility on the server and creates the desired number of vNICs with the desired properties (unique channel numbers, MAC addresses, and port-profile names). Names of port profiles (type vethernet) configured on the switch are pushed down to the server adapter as soon as connectivity is established. These port-profile names will be available in a drop-down list in the adapter configuration utility.
Figure 3 shows the configuration using the Cisco UCS P81E managed through the Cisco Integrated Management Controller (CIMC) tool.
Platform Support and Compatibility
Adapter FEX technology is supported on the new Cisco Nexus 5500 platform, which extends the industry-leading versatility of the Cisco Nexus 5000 Series of purpose-built 10 Gigabit Ethernet data center-class switches and provides innovative advances toward higher density, lower latency, and multilayer services. The Cisco Nexus 5500 platform is well suited for enterprise-class data center access-layer deployments and smaller-scale midmarket data center aggregation deployments across a diverse set of physical, virtual, storage-access, and high-performance-computing (HPC) data center environments. Adapter FEX connectivity is also supported by the Cisco Nexus 2000 Series Fabric Extenders, allowing cascading of the Fabric Extenders.
The Cisco Nexus 5548UP Switch (Figure 4) is a 1RU 10 Gigabit Ethernet and Fibre Channel over Ethernet (FCoE) switch offering up to 960-Gbps throughput and up to 48 ports. The switch has 32 1- and 10-Gbps fixed Enhanced Small Form-Factor Pluggable (SFP+) Ethernet and FCoE ports and one expansion slot.
The Cisco Nexus 5596UP Switch (Figure 5) is a 2RU 10 Gigabit Ethernet and FCoE switch offering up to 1.92-Tbps throughput and up to 96 ports. The switch has 48 1/10-Gbps fixed SFP+ Ethernet and FCoE ports and three expansion slots.
The Cisco Nexus 2232PP 10GE Fabric Extender (Figure 6) is a fabric extender controlled by the upstream parent switch. It operates as a remote line card, using the Port Extension technology described by prestandard IEEE 802.1Qbh. It provides 32 10 Gigabit Ethernet and FCoE SFP+ server ports and eight 10 Gigabit Ethernet and FCoE SFP+ uplink ports in a compact 1RU form factor.
Adapter FEX technology can also be supported when servers are connected to a Cisco Nexus 5500 switch through the Cisco Nexus 2232PP 10GE Fabric Extender. This support is possible because of the flexibility of the IEEE 802.1Qbh standard, which allows cascading of Port Extenders (Figure 7).
A Cisco innovation, the Cisco UCS P81E VIC (see Figure 2) is a virtualization-optimized FCoE PCIe 2.0 x8 10-Gbps adapter designed for use with Cisco UCS C-Series Rack-Mount Servers. The VIC is a dual-port 10 Gigabit Ethernet PCIe adapter that can support up to 128 PCIe standards-compliant virtual interfaces, which can be dynamically configured so that both the interface type (NIC or host bus adapter [HBA]) and identity (MAC address and worldwide name [WWN]) are established using just-in-time provisioning. In addition, the Cisco UCS P81E supports the Adapter FEX capability in bare-metal servers as well as virtualized environments.
Cisco UCS P81E, when functioning as an AdapterFEX, supports up to 16 vNICs. Each vNIC can connect to the network using one of the two Cisco UCS P81E 10 Gigabit Ethernet uplink ports as an active uplink and the other as a standby uplink.
A Cisco Nexus 5500 switch will support 128 vethernet interfaces, and up to 256 VLANs can be configured on each of these interfaces.
Cisco Nexus в ядре корпоративной сети
Коммутаторы Cisco Nexus появились на рынке достаточно давно. Данное семейство коммутаторов позиционируется в первую очередь для установки в ЦОДах. Однако последнее время сам вендор стал активно предлагать коммутаторы Nexus для установки в корпоративную сеть в качестве ядра сети. И тут сразу возникает вопрос, а подойдёт ли для такой задачи Nexus? Понятно, раз предлагают, значит подойдёт. Но давайте на этом чуточку заострим наше внимание.
Nexus (в переводе с английского) – связь, нексус, узы, звено, цепь.
Не́ксус (лат. nexus — «связь, сцепление») — имеет множество значений в разных областях, но в общем случае обозначает центральную часть какой-либо сущности, центр сцепления каких-нибудь связей.
Анонс одного из первых коммутаторов данного семейства Cisco Nexus 7000 произошёл в 2008 году. Однако долгое время они позиционировались и на бумаге, и в умах в первую очередь для построения сети ЦОДа. Время шло, и из статуса диковинного устройства данные коммутаторы потихоньку стали превращаться в более обыденные. Семейство коммутаторов за это время сильно расширилось. Более того, оно стало даже чуточку избыточным. Не всегда на 100% стало понятно, какой именно Nexus стоит использовать. На сегодняшний день представлены коммутаторы с фиксированной конфигурацией (Nexus 3000, 5000, 6001, 9300) и модульные (Nexus 6004, 7000, 9500), коммутаторы для установки в блейд-корзину (Nexus 4000, B22). Также есть специализированные коммутаторы – расширители фабрики (Fabric Extenders), это Nexus 2000 и B22. Даже есть виртуальный коммутатор Nexus 1000V (хотя слово «даже» не очень уместно, так как облака – это наше всё). Продолжать классификацию можно ещё долго, однако наша задача не в этом.
Давайте посмотрим, чем же именно семейство коммутаторов Nexus отличаются от самых обычных коммутаторов семейства Catalyst. Так как вопрос достаточно объёмный, рассмотрим его укрупнёнными мазками. Коммутаторы Nexus в первую очередь рассчитаны на работу в ЦОДах, где необходимо обеспечивать непрерывную «прокачку» большого количества трафика зачастую с минимальными задержками. Отсюда вытекают архитектурные особенности коммутаторов Nexus.
«Прокачка» большого количества трафика обеспечивается наличием разнообразных портов в том числе на скорости до 100 Гбит/с, а также производительностью внутренней фабрики. Стоит отметить, что нет единой архитектуры коммутаторов. Различные модели Nexus строятся на основе различных архитектур. Есть варианты построения на базе только Crossbar-фабрики (такая фабрика предполагает наличие большого количества путей между элементами коммутатора – ASIC’ами). Есть варианты реализации архитектуры Switch on Chip – SoC (когда вся логика заключена внутри чипа ASIC, а передача пакета между портами идёт через общую память внутри чипа). Также есть комбинированные варианты — Crossbar-фабрика вместе с SoC. Во всех случаях производительность коммутаторов Nexus достаточна для передачи больших объёмов сетевого трафика.
Минимизация задержек в коммутаторах Nexus обеспечивается за счёт архитектурных особенностей. В частности, большинство коммутаторов Nexus обеспечивают режим коммутации пакетов Cut-through. Как мы помним, коммутаторы семейства Catalyst работают в режиме Store-and-forward. В режиме Store-and-forward коммутатор начинает передачу пакета только после того, как он его весь получил. В режиме Cut-through передача пакета происходит после получения первых 64 байт. А значит, в режиме Cut-through задержка пакета в коммутаторе всегда постоянная и не зависит от его длины. Также в борьбе с минимизацией задержек при передаче пакетов внутри коммутатора участвуют различные схемы работы внутренней фабрики (superframing, очереди на входе и пр.). Например, Superframing обеспечивает склеивание пакетов друг с другом при их передаче через внутреннюю фабрику, что позволяет эффективно расходовать пропускную способность данной фабрики. Для примера, задержки в коммутаторах Catalyst 3850 достигают 50 мкс (зависит от размера пакета). При этом задержка в коммутаторе Nexus 3548 в специальном режиме составляет всего 190 нс. Для остальных коммутаторов Nexus – 1-2 мкс.
За непрерывность «прокачки» трафика отвечают разнообразные архитектурные особенности как железа, так и программного обеспечения. С точки зрения железа – это дублирование различных блоков в устройстве (избыточные вентиляторы, несколько блоков питания, фабрик и пр.). Также присутствуют различные схемы контроля и мониторинга компонент коммутатора (Connectivity Management Processor и пр.), которые позволяют заметить проблемы на самом раннем этапе. С точки зрения программного обеспечения имеем специализированную операционную систему NX-OS и букет различных функций. NX-OS в отличии от привычного IOS является модульной программной архитектурой. Каждая функция выполняется как отдельный процесс. А значит, если у нас проблема, например, с OSPF, мы можем перегрузить только процесс OSPF. Трогать всю систему не придётся. На коммутаторах Nexus поддерживаются различные функции, которые позволяют нам получить высокий уровень отказоустойчивости. Например, поддержка протоколов обеспечения резервирования шлюза по умолчанию (First Hop Redundancy Protocols), динамической маршрутизации вместе с Nonstop Forwarding, протоколы STP и прочее. Так же есть присущая только Nexus функциональность, например, создание виртуальных агрегированных каналов Virtual Port Channel (vPC).
В дополнение к указанным выше особенностям коммутаторов Nexus стоит добавить, что они поддерживают достаточно широкий спектр функций, специфичных именно для этого семейства. По большому счёту все эти функции продиктованы областью применения Nexus – в качестве коммутаторов ЦОДа. К таким функциям относятся и обеспечение конвергентного доступа (поддержка протокола FCoE), и виртуализация коммутатора (Virtual device contexts – VDC: физический коммутатор мы можем разделить на несколько виртуальных), и поддержка оверлейных технологий (например, FabricPath), а также программно-определяемых сетей (Application Centric Infrastructure – ACI) и т.д.
Думаю, уже стало понятно, почему коммутаторы Nexus устанавливаются в ЦОДах. Давайте попробуем сфокусироваться всё-таки на изначальном вопросе, а именно: можно ли поставить Nexus вместо Catalyst в ядро обычной корпоративной сети? На текущий момент мы не выявили никаких противопоказаний. Наоборот, отметили, что коммутаторы Nexus обладают различными положительными характеристиками, хотя и необходимыми в первую очередь в ЦОДах. Посмотрим теперь на те аспекты, которые необходимы нам от устройства при работе в корпоративной сети.
Первый вопрос, который волнует: а что там с командной строкой? Не придётся переучиваться? В целом, ответ: нет, не придётся. Командные строки достаточно похожи. Есть особенности, но они не фатальные. Например, при настройке различных функций их необходимо изначально активировать с помощью команды «feature». Порты независимо от типа называются Ethernet. Синтаксис большинства стандартных команд практически идентичен.
Второй вопрос, какие порты я могу получить? Тут широкая линейка Nexus’ов нас ничем не ограничивает. Доступны варианты с портами 1, 10, 40 и 100 Гбит/с. Много вариантов устройств с различным количеством портов. Отдельно стоит упомянуть, что коммутаторы Nexus поддерживают подключение к себе расширителей (Fabric Extender). Это как линейная карта в модульном коммутаторе, только выполненная в виде отдельного устройства. Сам по себе Fabric Extender не реализует никакой логики. Весь трафик всегда передаётся на родительское устройство (полноценный коммутатор Nexus). Благодаря Fabric Extender’ам можно получить большой логический коммутатор с различными портами. А так как Fabric Extender – это отдельное устройство, установить его мы можем как можно ближе к подключаемому к нему оборудованию, что обеспечивает определённые удобства при построении сети. Кстати, аналогичное решение в мире Catalyst – Instant Access. Правда в мире Nexus вендор пошёл дальше, предоставив возможность «дотянуть» порт коммутатора непосредственно в виртуальную машину. Т.е. создаётся иллюзия, что каждая виртуальная машина подключена напрямую в железный коммутатор Nexus.
А что со стандартным функционалом на коммутаторах Nexus?
Если мы посмотрим на L2-функции, то найдём всё, что нам необходимо: виртуальные сети (VLAN, Private VLAN), поддержку протоколов предотвращения петель STP, а также различные «гарды» (Root Guard, BPDU Guard и пр.), агрегацию портов Port Channel и т.д.
Что касается L3-функций, ситуация аналогичная: поддержка статической и динамической маршрутизации (EIGRP, OSPF, BGP, ISIS), маршрутизации на основе политик (PBR), поддержка протоколов резервирования шлюза по умолчанию (HSRP, VRRP, GLBP), GRE-туннелей и т.д. Поддерживаются протоколы для работы с multicast-трафиков: IGMP и PIM.
С точки зрения функций безопасности также имеем стандартный набор: списки доступа ACL (IP, MAC, VLAN), ограничение доступа на уровне порта (Port Security), различные функции борьбы с подменами адресов (DHCP snooping, Dynamic ARP inspection, IP source guard). Присутствуют механизмы борьбы с широковещательными штормами (Storm Control) и защиты уровня управления (Control Plane Policing).
Для обеспечения мониторинга и управления всё необходимое присутствует: SNMP, NTP, Netflow, различные реализации SPAN, Embedded Event Manager и другое. Более того в отличие от коммутаторов Catalyst на Nexus поддерживается возможность управления через протокол сетевого управления NETCONF, а также запуска скриптов на базе Python.
Помимо всего перечисленного коммутаторы Nexus, как я уже отметил ранее, поддерживают достаточно большой спектр и других различных технологий, правда, менее востребованных в корпоративных сетях: MPLS, LISP, VXLAN, OTV и пр.
Вроде как, отметил основные моменты. Хотя нет, упустил часть, касающуюся качества обслуживания QoS. Функциональность QoS зависит от платформы и типа линейных карт. Безусловно, коммутаторы Nexus имеют свои особенности: очереди на входе, поддержка различных протоколов управления потоками, согласования параметров обслуживания трафика и динамического управления полосой (802.1Qbb и 802.1Qaz). Однако в целом настройка политик схожа с настройками для коммутаторов Catalyst. Используется привычная схема Modular QoS CLI. Основные отличия: QoS включён по умолчанию и все порты доверяют значениям QoS в пакетах (CoS, DSCP). Ещё один момент: в большинстве коммутаторов Nexus приоритетная очередь (priority queuing) ничем не ограничена, а значит может утилизировать всю полосу пропускания (для остальных очередей возможна ситуация «голодания» — starvation).
Думаю, стоит упомянуть, чего нет в коммутаторах Nexus. На них не поддерживается стекирование в любом виде. Хотя это совсем и не проблема. Для обеспечения подключения устройств в отказоустойчивом варианте к двум разным коммутаторам Nexus используется технология Virtual Port Channel (vPC). Она позволяет агрегировать несколько физических интерфейсов в один логический. При этом коммутаторы Nexus, куда приходит агрегированный канал, продолжают работать независимо друг от друга. Между собой они лишь синхронизируют параметры и состояние агрегированного канала vPC.
В модульные коммутаторы Nexus нет возможности ставить сервисные модули, как это можно делать в коммутаторах Catalyst 6500/6800 (например, модуль межсетевого экранирования ASA-SM, модуль анализатора трафика NAM, контроллер беспроводной сети WiSM и пр.). Также на коммутаторах Nexus нет функции передачи питания по Ethernet (Power over Ethernet), собственно это и логично.
Давайте подведём итог. С точки зрения управления, проблем возникнуть не должно. Консоль NX-OS очень похожа на консоль IOS. С выбором устройства также трудностей не будет. Семейство коммутаторов очень многообразно. Поддерживается необходимый стандартный функционал для работы коммутатора в корпоративной сети в качестве её ядра. А значит, можем подключать к коммутатору Nexus более привычные коммутаторы Catalyst (или коммутаторы других производителей). Таким образом смело отвечаем на поставленный в начале статьи вопрос: в большинстве случаев коммутатор Nexus можно без проблем установить в корпоративную сеть в качестве ядра сети. Его функциональности для большинства задач хватит.
Заметим, коммутаторы Nexus всё-таки в первую очередь позиционируются для ЦОДов. И они, конечно же, не являются полноценной заменой коммутаторов Catalyst. В большинстве случаев мы их можем использовать в корпоративной сети. Но не всегда. Следует тщательно смотреть на требования к сети.
В заключение коснёмся ценового аспекта. Он остался за кадром. Понятное дело, цена очень важный фактор, на который зачастую смотрят в первую очередь. Конечно же, при сравнении коммутаторов Nexus с другими семействами можно сразу отметить, что близость стоимости решений достигается только для коммутаторов с портами 10 Гбит/с. Не стоит думать, что коммутаторы Nexus будут конкуренты с обычными коммутаторами с портами 1 Гбит/с. Для семейства коммутаторов Nexus стандартными портами являются именно порты 10 Гбит/с. Обязательно нужно считать полную стоимость коммутатора: стоимость железа и лицензий, так как зачастую лицензии дают очень приличное увеличение цены. Но при всём при этом, ценовая политика вендора в разрезе коммутаторов Nexus иногда приятно удивляет, что и заставляет нас задумываться о поставленном в начале вопросе.