Cisco Nexus в ядре корпоративной сети



    Коммутаторы Cisco Nexus появились на рынке достаточно давно. Данное семейство коммутаторов позиционируется в первую очередь для установки в ЦОДах. Однако последнее время сам вендор стал активно предлагать коммутаторы 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 иногда приятно удивляет, что и заставляет нас задумываться о поставленном в начале вопросе.
    CBS 51,63
    Компания
    Поделиться публикацией
    Комментарии 17
    • +1
      Да, был как-то приятно удивлен циской, когда увидел ценник под проект и в итоге был куплен джунипер.
      • 0
        «Так же есть присущая только Nexus функциональность, например, создание виртуальных агрегированных каналов Virtual Port Channel (vPC).»

        Ух ты как :)

        en.wikipedia.org/wiki/MC-LAG
        • 0
          В статье идёт сравнение только Cisco Nexus и Cisco Catalyst. У Catalyst функции vPC нет. Именно это и указанно. Про уникальность vPC в разрезе других устройств речи не идёт.
          • 0
            Почти так — есть же на шеститонниках каталистах Virtual Switching System (VSS).
            • 0
              В случае VSS у нас control-plane один и используется обычный Port Channel. В случае Nexus каждое устройство имеет свой control-plane и используется технология Virtual Port Channel. На выходе мы получаем примерно одно и тоже. Но сами технологии чуточку разные.
        • 0
          Да и модель каталистов была (может быть еще жива?) 4948 и 4900 — позиционировалась циской как быстрая серия с минимальными задержками при передачи фрэймов. С ней бы сравнить серию Nexus (без 40 и 100 Gb) — какова будет разница в производительности и ценника?

          PS: За статью спасибо!
          • 0
            Линейка коммутаторов 4900 практически умерла. Она позиционировалась для ЦОДов и, видимо, так как появились коммутаторы Nexus, перестала со временем быть актуальной. Остались только Catalyst 4948E: с гигабитными портами и не самым богатым функционалом.

            В своё время (когда появились первые модели этой линейки) она действительно выделялась в первую очередь производительностью среди других коммутаторов Cisco Catalyst. Но по сегодняшним меркам эти значения совсем не являются выдающимися.

            Что касается задержек, нашёл данные тестирования 4900M, где указывается, что средняя задержка не превосходит 19 мкс, при этом максимальная не больше 63 мкс (сказывается режим работы Store-and-forward). Это явно больше значений Nexus. И более того сравнимо с задержками в современных Catalyst.
            • 0
              А по сравнению 4500-X, которые сейчас позиционируют на ядро для каталистов?
              • 0
                navion, возможно, не совсем точно понял Ваш вопрос. Если в общем случае сравнивать Catalyst 4500X и абстрактный Nexus, всё, что указано в статье, имеет место быть.

                На вопрос: что лучше 4500X или, например, Nexus 9300, сходу на 100% ответить не удастся. Во-первых, стоит смотреть более предметно, какой функционал требуется от устройства. Например, на Nexus не будет Flexible Netflow, нет EVN и пр. Кому-то обязательно потребуется стек VSS. Пересечение по функциям большое, но совсем неполное. Во-вторых, какие требования по задержкам и производительности: Nexus 9300, конечно же, будет смотреться в этом плане более предпочтительно.

                Что касается линейки 4900, то заменой 4900M, как раз является 4500X. Хоть 4948E и не объявлен в EoS, 4500Х смотрится более выигрышно.
          • 0
            На вопрос нахрена нужен дорогой нексус в качестве ентерпрайзного ядра стать так и не ответила.
            • 0
              В определённых конфигурациях (в первую очередь при выборе решения с портами 10 Гбит/с) стоимость коммутатора Nexus сравнима, а иногда даже меньше стоимости аналогичного коммутатора Catalyst. Периодически этому способствует сам вендор (промо, уровень скидки). Именно из-за этого и возникает вопрос возможности использовать Nexus в корпоративных сетях. Переплачивать деньги за ненужный функционал и производительность в нынешнее время желающих немного.
              • 0
                Опять-таки об этом не сказанов статье. Есть только информация о том, что на нексусах есть высокоскоростные порты.
            • 0
              Можете расписать на пальцах в каком случае Nexus 3524X предпочтительней Catalyst 4500-X?
              • +1
                Вообще Nexus 3524X достаточно специализированное устройство. В первую очередь он нам пригодится, если нам требуется иметь минимальные задержки в сети (например, при подключении к торговой площадке) и иметь инструментарий их отслеживать. Также на 3524X поддерживается NAT (опять же, с минимальными задержками). Ещё момент — поддержка расширенных функций зеркалирования трафика (применение фильтров, частичное зеркалирование трафика, инжектирование временных меток и пр.).
                • +1
                  Чуточку добавлю. По цене 3524X дешевле 4500X. В некоторых случаях в 2 раза! По задержкам и производительности он лучше, чем 4500Х. Остаётся вопрос по функциональности. Большинство нужных вещей (разнообразный routing, ACL, LACP, STP и пр.) на 3524X есть. Да, что-то отсутствует. Но даже при этом, 3524X смотрится очень интересно. Это, наверное, один из самых бюджетных вариантов получить 24 порта 10Гбит/с на Cisco.
                  • 0
                    Увидев ценник и решил спросить, так как за 500 тыр из конкурентов есть только Dell N4032F.
                    • 0
                      Сравнивал только с HPE. 3524X стоит дешевле. Правда, нужно ещё смотреть, что будем цеплять к коммутатору. Если подключаем серверы, да при том того же производителя, можно использовать twinax/DAC кабели. А это очень хорошо сказывается на общей стоимости решения.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое