Arista. Знакомство



    На Хабре нет ни одного поста про коммутаторы компании Arista Networks. При этом есть несколько комментариев, по-моему, достаточно положительных по смысловой окраске.

    Мне захотелось написать про эту компанию, их оборудование, операционную систему EOS и CLI.



    Отмазки


    Я не являюсь представителем вендора и у меня нет глубоких познаний по всей линейке. Топик носит обзорный характер и отражает моё личное мнение. Для мнений читателей есть комментарии и новые топики.

    История Arista


    Как сообщает книга Arista Warrior и соответствующий раздел сайта, в появлении Arista Networks виновны три ключевые фигуры:

    • Andy Bechtolsheim
      Один из основателей Sun Microsystems. В 1995 он покидает Sun и создает Granite Systems, целью которой является производство высокоскоростных сетевых коммутаторов. В 1996 компания Cisco покупает Granite Systems. Под его руководством в Cisco создается серия коммутаторов Catalyst 4500. Andy покидает Cisco в 2003 и создает Kealia — компания по производству серверов нового поколения, которую в 2004 покупает Sun.
      В 2005 он становится одним из основателем Arasta, впоследствии сменившей название на Arista Networks.
    • David Cheriton
      Один из основателей Granite Systems. Главный архитектор микросхем ASIC для линейки Catalyst 4X00 в Cisco. Так же был техническим консультантом для Google, VMware, Tibco, Cisco, Sun и нескольких стартапов.
    • Kenneth Duda
      Первопроходец в высокопроизводительном сетевом ПО и ведущий архитектор EOS в Arista. Он один из авторов спецификаций нескольких сетевых протоколов, например: VXLAN и NVGRE. Был первым наемным сотрудником в Granite Systems и вел разработку ПО для линейки Catalyst 4X00.

    Jayshree Ullal занимает должность CEO. Она была старшим вице-президентом в Cisco и несла ответственность за линейки Cisco Nexus 7000, Catalyst 4500, и Catalyst 6500. В 2005 года журнал «Network World Magazine» включил её в список «50 самых властных людей» («50 Most Powerful People»).

    Продуктовая линейка.


    Arista Networks предлагает только коммутаторы и конечно же сопутствующие товары (кабели питания, трансиверы, сервис и т.п.). Свои свитчи Arista позиционирует для применения в Центрах Обработки Данных (ЦОД).

    Краткая свободная таблица (кликабельно) по некоторым параметрам из Arista Products Quick Reference Guide (параметров больше, например, есть аппаратная поддержка VXLAN):


    Компания не производит маршрутизаторы, Wi-Fi AP, устройства SOHO, межсетевые экраны и прочие сетевые устройства.

    Merchant Silicon


    Data Plane («плоскость передачи данных») в коммутаторах Arista построен с использованием интегральных схем специального назначения — ASIC.

    По типу происхождения ASIC делятся на:
    • Custom Silicon — микросхемы, которые обычно разработаны и произведены компанией, которая производит на этих чипах коммутаторы.
    • Merchant Silicon — «коммерчески» доступные микросхемы, разработанные и произведенные компанией, которая не производит на них коммутаторы.

    Простой пример для аналогии из мира смартфонов:
    • Компания HTC не производит CPU для своих смартфонов, но смартфоны собирает и продает на, например, микросхемах Qualcomm. Это пример Merchant Silicon.
    • Компания Samsung выпускает как набор микросхем Exynos, так и смартфоны на них. В случае с Samsung — это пример Custom Silicon.

    Arista не разрабатывает собственные ASIC, а использует в своих коммутаторах Merchant Silicon от Intel и Broadcom.

    С одной стороны, в этом нет ничего уникального. Например, на ASIC StrataXGS Trident II фирмы Broadcom построены следующие коммутаторы некоторых вендоров (вендоры в алфавитном порядке):
    • Arista 7050X
    • Cisco Nexus 9000
    • Extreme Networks Summit X770
    • Juniper QFX5100

    С другой стороны, при таком подходе на первое место выходят такие параметры коммутатора, как:
    • Качество программирования и использования ресурсов ASIC. ASIC — это не просто plug and play, их ресурсами можно программно управлять (в этом заключается гибкость (в некотором диапазоне) использования этих микросхем). От качества алгоритмов и кода зависит поведение коммутатора на трафике.
    • Конструкция как внутренняя (выбор (например, вариант CPU, количество и тип ОЗУ) и компоновка элементов на платах, вентиляторы, блоки питания), так и внешняя (количество юнитов, удобство расположения портов и т.д.)
    • Качество и удобство ОС и CLI коммутатора.
    • Наличие нужных и удобных дополнительных возможностей, реализованные как на основе ASIC, так и программно на RE. При этом необходимо не забывать, что некая функция может поддерживаться в ASIC, но не поддерживаться ОС коммутатора. В этом случае, она просто не будет доступна к использованию. Хуже, когда функция, выполняющая функции Data Plane, реализована не в ASIC, а программно.

    Про такие характеристики коммутаторов Arista Networks, как задержки и работа с буфером, ходят презентации, слухи и еще раз комментарии на Хабре.

    EOS


    EOS — это модульная операционная система, которая обеспечивает работу коммутаторов Arista. Она одна для всей линейки свитчей не только по названию. Кто обновлял хотя бы раз IOS на коммутаторах Cisco знает, что IOS c3550*.bin не подойдет в тот коммутатор, где используется c3750*.bin. А кто работал с Juniper знает, что jinstall-ex-4500*.tgz не заменит jinstall-ex-4200*.tgz. У Arista пока получается делать единый файл с ОС для всей линейки. Не главный плюс EOS, но удобный.

    EOS базируется на Fedora. ОС работает на отдельном CPU (в данный момент — x86), что позволяет разделить Control Plane («плоскость управления» — CPU, EOS) и Data Plane («плоскость передачи данных» — ASIC). Всё это не ново, но есть и архитектурные особенности в EOS, которых нет в ОС других вендоров. Так, например, компоненты, необходимые для работы коммутатора, не обмениваются данными друг с другом напрямую, а делают это только через специальный менеджер-базу — Sysdb. Sysdb является как общей шиной для коммуникации между процессами, так и базой данных для рабочей информации этих процессов. Например, маршрут, пришедший по IGP, перед тем, как попасть в ASIC, передается процессом, отвечающим за IGP, в Sysdb; Sysdb сохраняет его у себя в закромах и передает в процесс, отвечающий за взаимодействие с ASIC.

    С помощью работы через Sysdb получается обеспечить большую выживаемость и стабильность. Например, что-то произошло с сервисом, отвечающим за SNMP (например, сложносформированные данные в запросе вызвали сбой), и он умер. Менеджер процессов (ProcMgr) автоматически перезапускает сервис SNMP. После запуска все сервисы обращаются к Sysdb и, если там уже есть их данные, то они их восстанавливают и продолжают с ними работать.

    При традиционном построении ОС (в том числе для сетевых устройств) компоненты, службы и сервисы передают данные между собой напрямую. Перезапуск или «падение» процесса-сервиса влечет за собой потерю всех его рабочих данных (маршрутов, статистики и прочего), а так же может сказаться на других сервисах, с которыми невезучий процесс работал и обменивался данными: они могут тоже «упасть» или потерять состояния, необходимые для работы.

    Схематичная структура «традиционной ОС» и Arista EOS:

    (картинки из «EOS Architecture Whitepaper».)

    Подобное устройство EOS не гарантирует полную устойчивость и безотказность, но все же это лучше, чем ничего. А еще с помощью функционирования через Sysdb реализован ISSU сервисов.

    CLI

    Cli (в EOS у всех запускаемых приложений от Arista имена с заглавной буквы) тоже работает через Sysdb.
    Команды CLI написаны на Python:
    [admin@localhost ~]$ cd /usr/lib/python2.7/site-packages/CliPlugin/
    [admin@localhost CliPlugin]$ ls -a *Cli*py
    AaaCli.py	     CliSchedulerCli.py      FaultInjectionCli.py	 IraIpCli.py		     MlagShowCli.py	   PimCli.py		   RipShowTechCli.py	TapAggIntfCli.py
    AclCli.py	     ClockCli.py	     FhrpCli.py			 IraIpIntfCli.py	     MlagTunnelCli.py	   PimShowTechCli.py	   RouteEventMonCli.py	TcpdumpCli.py
    AclCliRules.py	     CpuFabricCli.py	     FileCli.py			 IraShowTechCli.py	     MlagWarningCli.py	   PmbusCli.py		   RouteMapCli.py	TechSupportCli.py
    AgentCli.py	     DcbxCli.py		     FruCli.py			 IraVrfCli.py		     ModuleCli.py	   PortSecCli.py	   RoutingBgpCli.py	TrackingCli.py
    AgentPingCli.py      DebugMessageCli.py      IgmpCli.py			 LagCli.py		     ModuleIntfCli.py	   PowerCli.py		   RoutingIsisCli.py	UplinkFailureDetectionCli.py
    AgentResourceCli.py  DebuggingCli.py	     IgmpProfileCli.py		 LagIntfCli.py		     MoreCli.py		   PowerDiagsCli.py	   RoutingOspf3Cli.py	VersionCli.py
    AgentShutdownCli.py  DhcpRelayHelperCli.py   IgmpShowTechCli.py		 LagIntfMlagCli.py	     MrouteCli.py	   PsmiCli.py		   RoutingOspfCli.py	VlanCli.py
    ArpEventMonCli.py    DiagCli.py		     IgmpSnoopingCli.py		 LagShowTechCli.py	     MrouteEtbaCli.py	   PtpCli.py		   RoutingRipCli.py	VlanIntfCli.py
    ArpIp6Cli.py	     DonkeyCli.py	     IgmpSnoopingDebugCli.py	 LanzCli.py		     MrouteEventMonCli.py  QosCli.py		   SectionCliLib.py	VmTracerCli.py
    ArpIpCli.py	     EbraEthIntfCli.py	     IgmpSnoopingEtbaCli.py	 LanzIntfCli.py		     MrouteShowTechCli.py  RadiusCli.py		   SendCli.py		VmTracerIntfCli.py
    ArpIpIntfCli.py      EbraEthIntfCliModel.py  IgmpSnoopingEventMonCli.py  LauncherDaemonCli.py	     MsdpCli.py		   RedSupCli.py		   SflowCli.py		VxlanCli.py
    BackupIntfCli.py     EbraShowTechCli.py      IgmpSnoopingShowTechCli.py  LinkFlapCli.py		     NetworkCli.py	   RedSupCliFormatSpec.py  ShellCli.py		WaitForWarmupCli.py
    BeaconLedCli.py      EbraSnmpCli.py	     InstallCli.py		 LldpConfigCli.py	     NetworkToolsCli.py    RedSupFileCli.py	   SnmpCli.py		WatchCli.py
    BfdCli.py	     EmailCli.py	     IntfCli.py			 LldpStatusCli.py	     NetworkUrlCli.py	   ReloadCauseCli.py	   StormControlCli.py	XcvrCli.py
    BootCli.py	     EnvironmentCli.py	     IntfRangeCli.py		 LoggingCli.py		     OldDhcpRelayCli.py    ReloadCli.py		   StpCli.py		XcvrConfigCli.py
    BridgingCli.py	     ErrdisableCli.py	     IntfSnmpCli.py		 LoopbackIntfCli.py	     OpenFlowCli.py	   ReloadConfigSaveCli.py  StpCliLib.py
    BridgingCliModel.py  EthIntfCli.py	     Ip6NdCli.py		 MacEventMonCli.py	     PciCli.py		   ReloadElectionCli.py    StpIntfCli.py
    BridgingEtbaCli.py   EthShowTechCli.py	     IraCommonCli.py		 MacFlapCli.py		     PeerIntfCli.py	   ReloadFileSyncCli.py    SupeSessionCli.py
    CliCli.py	     EventCli.py	     IraEtbaCli.py		 ManagementActiveIntfCli.py  PfcCli.py		   RibIp6Cli.py		   SwitchIntfCli.py
    CliCliModel.py	     EventMonCli.py	     IraIp6Cli.py		 MirroringCli.py	     PhyCli.py		   RibIpCli.py		   SysMgrCliLib.py
    CliError.py	     ExtensionMgrCli.py      IraIp6IntfCli.py		 MlagConfigCli.py	     PhyConfigCli.py	   RibShowTechCli.py	   TacacsCli.py
    [admin@localhost CliPlugin]$ head VlanCli.py
    ==> VlanCli.py <==
    # Copyright (c) 2006-2011 Arista Networks, Inc.  All rights reserved.
    # Arista Networks, Inc. Confidential and Proprietary.
    
    #-------------------------------------------------------------------------------
    # This module implements VLAN configuration.  In particular, it provides:
    # -  the Vlan class
    # -  the VlanSet class
    # -  the "config-vlan" mode
    # -  the "[no] vlan <vlan_set>" command
    # -  the "[no] name <vlan_name>" command
    


    Пользователям можно изменять как встроенные команды, так и писать свои.

    Сама же работа в CLI похожа на работу в CLI Cisco IOS. Первое время кажется, что это копия (не как у Huawei, а именно копия). Но потом становятся видны доработки, которых очень не хватало в IOS.

    Например, при изменении параметров группы интерфейсов не нужно слово «range», а номера интерфейсов отображаются слева:
    localhost(config)#int e1,3,5
    localhost(config-if-Et1,3,5)#
    localhost(config-if-Et1,3,5)#load-interval 10
    

    Или можно посмотреть утилизацию интерфейсов и группы интерфейсов:
    localhost#sh int e3,e48 | i rate
      10 seconds input rate 5.26 Gbps (53.3% with framing overhead), 433507 packets/sec
      10 seconds output rate 12.2 Mbps (0.2% with framing overhead), 21824 packets/sec
      10 seconds input rate 12.2 Mbps (0.2% with framing overhead), 21826 packets/sec
      10 seconds output rate 5.26 Gbps (53.3% with framing overhead), 433546 packets/sec
    

    И совершенно не нужно курсором выделять по 3 знака в скорости порта, чтобы понять, с мегабитами или гигабитами мы имеем дело. Но и это не все. EOS отображает утилизацию интерфейса в %.

    А еще в EOS можно делать множественные пайпы и использовать программы GNU/Linux:
    sho run | grep X | grep -v Y | more

    Не нужно в режиме конфигурации перед командой добавлять «do».

    Можно посмотреть diff активной и сохраненной конфигурации:
    localhost#sh run diffs 
    --- flash:/startup-config
    +++ system:/running-config
    @@ -190,9 +190,10 @@
     !
     interface Loopback0
        ipv6 enable
    +   ipv6 address 2001:db8:ffff::ffff/128
        ipv6 address 2001:db8::1/128
        ip address 10.10.10.1/32
    -   ip address 10.255.255.1/32 secondary
    +   ipv6 ospf priority 20
        ipv6 ospf 1 area 0.0.0.0
     !
     interface Management1
    @@ -200,7 +201,6 @@
     !
     interface Vlan10
        description test
    -   shutdown
        mtu 9000
        ip address 10.1.1.1/24
     !
    

    Можно выйти в bash и осмотреться:
    localhost#bash
    
    Arista Networks EOS shell
    
    [admin@localhost ~]$ ls /
    bin   dev  export  lib    mnt      opt      proc  sbin     srv  tmp  var
    boot  etc  home    media  monitor  persist  root  selinux  sys  usr
    [admin@localhost ~]$ sudo -s
    bash-4.1# cat /proc/cpuinfo | grep name
    model name: AMD Turion(tm) II Neo N41H Dual-Core Processor
    model name: AMD Turion(tm) II Neo N41H Dual-Core Processor
    

    Все ACL задаются именами. Не нужно помнить и путаться в номерах. Для приверженцев старого подхода есть возможность в качестве имен использовать цифры.

    И так далее и тому подобное. CLI в EOS не просто копия, это самодостаточная оболочка с удобными возможностями и далеко ушедшая от прародителя.

    Extensible OS

    Слово «Extensible» в «Extensible Operating System» по задумке говорит о расширяемости функционала ОС. Достигается это за счет возможности установки своих программ, демонов, скриптов на коммутатор. Можно, например, установить и запустить клиент OpenVPN. Или, запустить скрипт на Python, или, даже ExaBGP. Можно свои поделки подружить с Sysdb, а потом, собрав в RPM пакеты, разнести по сети.

    Некоторые другие возможности EOS

    • CloudVision позволяет подключать коммутаторы Arista к XMPP серверу в роли клиентов. В «чаты» с ними можно писать команды CLI, и свитчи будут отвечать результатами их выполнения. Можно добавить несколько устройств в групповой чат и выполнять команды на всех участниках группы одновременно.
    • Advanced Event Management — это что-то вроде Cisco EEM или Junos Event Scripts: можно запрограммировать действия (команды CLI, выполнение скриптов) на определенные события (например: упал порт). Подробнее на сайте.
    • Event Monitor ведет логирование изменений MAC, ARP и таблицы маршрутизации на встроенной флеш памяти в виде базы SQLite.
    • eAPI (External API) позволяет работать с коммутатором по JSON-RPC: ввод и вывод данных в виде JSON объектов.
    • С помощью Zero Touch Provisioning (ZTP) можно автоматизировать настройку нового коммутатора. Свитч с настройками по умолчанию грузится в режиме ZTP и пытается получить сетевые настройки по DHCP. Используя option bootfile-name, которую тоже можно передать по DHCP, коммутатору можно указать URL для загрузки скрипта (на shell, или, например, на языке встроенного CLI, т.к. он является одним из вариантов shell). Если скрипт скачается успешно, то устройство его выполнит. При этом автоматизация ограничивается, наверное, только фантазией.
    • DirectFlow позволяет задавать правила (такие, как зеркалирование; изменение приоритета, VLAN, SRC/DST и т.д.), применяемые к трафику (на основе, например, SRC/DST (IP, MAC, port) или номера протокола, или номера VLAN и т.д.) из CLI (и eAPI тоже пойдет). С помощью таких правил можно, например, более выборочно зеркалировать трафик для анализа, в отличии от SPAN. Или отправлять на систему очистки только трафик для нужного IP, а не ставить эту систему в разрыв. Подобный функционал обычно описывают как преимущество при переключении коммутаторов в режим OpenFlow. DirectFlow позволяет применять правила в ASIC без OpenFlow.

    Aboot


    Aboot — это не часть EOS, а загрузчик EOS, что-то вроде Cisco ROMmon.

    Хочу о нем рассказать, потому что он очень прост и понятен. Aboot представляет из себя ни что иное, как BusyBox. Все данные, включая образы EOS и логи, хранятся на встроенной флешке. Aboot позволяет получить к ней доступ (а так же доступ к внешним USB накопителям, подключенным к USB портам) и восстановить работоспособность устройства в случае проблем. Вход в Aboot тоже простой: без танцев с бубном, без зажиманий кнопок и посылок странных кодов в консоль — CRTL+C.

    Думаю, это поможет представить простоту и возможности Aboot:
    Aboot 2.0.5-430838
    
    
    Press Control-C now to enter Aboot shell
    ^CWelcome to Aboot.
    Aboot# echo $SHELL
    /bin/sh
    Aboot# 
    arp            devmem         initblockdev   overcast-lcd   swiinfo
    ash            df             initnetdev     ping           switch_root
    autoboot       dirname        insmod         ping6          switchroot
    base64         dmesg          iostat         pmap           sync
    basename       dosfsck        ip             poweroff       sysinit
    blockdev       dropbearmulti  ipcalc         powertop       tail
    boardinit      du             kexec          ps             tar
    boot           echo           kill           pwd            tee
    bootchartd     egrep          ln             readlink       telnet
    bunzip2        env            login          realpath       tftp
    burnK7         expr           losetup        reboot         time
    burnMMX        false          ls             recover        touch
    burnP6         fdisk          lsmod          reset          tr
    busybox        fgconsole      lspci          rev            traceroute
    bzcat          fgrep          lsusb          rm             traceroute6
    cat            find           md5sum         rmdir          true
    checkpass      flashrom       mdev           rmmod          udhcpc
    chgrp          flock          mkdir          route          umount
    chmod          free           mkdosfs        rx             uname
    chown          fsck.msdos     mkfs.vfat      scp            unxz
    chroot         fsck.vfat      mknod          sed            unzip
    clear          fullrecover    mktemp         setpci         vi
    cmp            grep           modinfo        sh             vmcore-dmesg
    cp             gunzip         more           sha1sum        wget
    cpio           halt           mount          sleep          which
    cut            head           mpstat         smemcap        xz
    date           help           mv             ssh            xzcat
    dbclient       hexdump        nbd-client     stat           yes
    dd             ifconfig       netconf        stty           zcat
    devio          init           nvramtool      sum
    Aboot# exit
    Restarting system.
    


    Даже ipcalc есть для удобства.

    Применение


    Как было сказано ранее, Arista Networks целится своим оборудованием в ЦОДы и предлагает следующие варианты схем для оптимального использования:


    • Single-Tier «Spline» — гибрид Leaf («лист») и Spine («корень») — «Spline». Предлагается ставить два резервирующих друг друга коммутатора в центр ряда. Используя, например, коммутаторы типа 7316X, из его 512 портов по 40 Гбит/с можно сделать 2048 портов скорость 10 Гбит/с с помощью специального разветвителя QSFP-SFP+ (переходник с QSFP на 4 SFP+). Из 7250QX-64 получится 256 интерфейсов SFP+ всего в 2 U. Как видно из таблицы характеристик свитчей, коммутация будет без переподписки. Название — чистой воды маркетинг, но при правильном расчете и подходе реализация может быть очень выгодная по цене, простая в построении и обслуживании. Например, раньше для подключения 240 медных портов без резервирования нужно было 5 плат по 48 портов в Cisco Catalyst 6506.
    • Layer 2 / MLAG — уже ставший «классическим» Leaf and Spine, построенный на MLAG (известен и как MC-LAG). MC-LAG — это Multi-Chassis Link Aggregation Group, то есть LAG, построенный от двух устройств (в данном случае коммутаторов) к третьему устройству (коммутатору или серверу), при этом третье устройство считает, что подключено к одному устройству. Таким образом можно обойтись без STP и, что немаловажно, оба канала будут активными (active/active).
    • Layer 3 / ECMP — вариация «классического» Leaf and Spine, но при этом все линки между всеми устройствами на L3 (IPv4 и/или IPv6). Благодаря отсутствию ограничения на более двух устройств в узлах, эта схема обладает лучшей масштабируемостью, чем предыдущая. Все соединения тоже работают в активном режиме, нет STP. Защита от кольцевания трафика осуществляется на основе протоколов маршрутизации. Балансируется трафик с помощью ECMP.

    Ничто не мешает собрать кольцевую или смешанную топологию с использованием STP и его более улучшенных вариантов, включая PVST. Но это скажется отрицательно на недежности, масштабировании и удобстве эксплуатации.
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 29

      0
      я так и не понял зачем свитчу Forward capacity…
      в моем понимании у свитча должна быть огромная Switchfabtic, с пакетами он дело не имеет…
      либо это пишут в основном для того чтобы некоторые вендоры не хитрили и не делали тесты как им удобно ( большими фреймами)
        0
        В схеме с ECMP свитчи имеют дело именно с пакетами. DirectFlow или OpenFlow могут иметь дело с пакетами. Можно написать и внедрить в EOS свое приложение, которое будет иметь дело с пакетами. ASIC позволяет это сделать, почему бы тогда и не иметь forwarding capacity.
          +2
          Современные коммутаторы, особенно L3/MLS, нечто намного больше чем просто огромная switchfabric. В классике, L2, один или несколько ASIC, switchfabric, и все. Теперь добавьте сюда IPv4/v6, mpls, GRE, multicast, port mirroring, и получите то, почему указывают forwarding capacity. Перечень фич сильно зависит от архитектуры.

          Но указывать это для платформы в целом как средняя температура по больнице. Без архитектуры цифра бесполезна. В качестве маркетинг булшит сойдет. Особенно если умножать затем на jumbo frame, а не на 64 байта.

          Что можно хорошего узнать из этой цифры? Что если вдруг, по какой-то причине, нет нормального маршрутизатора и приходится использовать функционал, который нагружает forwarding engine. То очень легко заметить, что производительность в этом случае будет отставать на два порядка от того что может фабрика. Если кто путает, то два порядка это в 100 раз. (для 7508E, для остальных лень считать). Хотели получить 10Гиг на порту? получите 100Мбит :) Это при 100% нагрузке, но думаю довести до такого надо сильно постараться.
            0
            я так понимаю это если этот самый порт 10Г работает как L3 ( типа no switchport) так? вот тут и нужно обращать внимание на Mpps
            а как быть с виртуальными интерфейсами ( int vlan)? это же вроде как сэмулированный интерфейс… или я ошибаюсь
            • UFO just landed and posted this here
            • UFO just landed and posted this here
                +1
                Для CFC надо смотреть загрузку forwarding engine у супервизора, т.к. он в этом случае занимается форвардингом. В некоторых случаях нужно смотреть еще и загрузку rewrite engine.
                CFC нужен не для экономии каналов, а вообще чтобы просто подключиться к фабрике и получить 40гигабит на слот. Если бы не было CFC, то использовался бы classic bus.
                • UFO just landed and posted this here
                    +1
                    Примерно так. 16Gbps не совсем коректно и зависит от сценария использования, там вполне может быть и 20Gbps. Но в любом случае 2:1 Oversubscription на фабрике остается.
                    DFC3 выдает 48Mpps
                    • UFO just landed and posted this here
            +1
            Отличные неубиваемые железки. Мы их любим.

            А еще у них есть моделька с программируемым FCPGA на борту — жаль про нее Вы не написали. Может в следующей серии?
              0
              Александр, к сожалению, мне о них известно только то, что они есть. В этом топике не обзорено ни одной модельки. Железки правда хорошие и мне захотелось написать общий обзор. Может, кого-то вдохновит написать следующие серии.
                +1
                Обзор получился отличный.
                Спасибо.

                От себя добавлю что Layer 3 / ECMP у них функционирует с 0 drop и минимальным stdev в frame processing на wirespeed мелкими пактами вплоть до 60G. Дальше к сожалению не стали проверять. Генераторы в лабе кончились ;)
                  0
                  От себя добавлю что Layer 3 / ECMP у них функционирует с 0 drop

                  Хочется уточнить — это «интерфейсы/мидплейн/бекплейн/интерконнекты внутри линейных карт полностью прогружены, но в приоритетных очередях нет дропов»? Или «интерфейсы в среднем загружены не полностью, кратковременные всплески умещаются в буфера»? Если последнее, то свитч, проваливший такой тест, вообще лишается звания «свитч» и переименовывается в «дэлинк». Да и учитывал ли тест внутреннюю архитектуру свитча, целились ли вы в наиболее узкие места (например — целенаправленно пускать трафик с одной портгруппы на другую)?
                  и минимальным stdev в frame processing

                  Ну как бы тоже закономерно. Основной джиттер в буферах бывают.
              +2
              Давайте будем объективными…
              Но потом становятся видны доработки, которых очень не хватало в IOS.

              Ариста не конкурирует с IOS свитчами. Вот так вот. IOS свитчи на данный момент ориентированы на кампус, а ариста — на ЦОД.
              Ариста конкурирует со свитчами линейки Nexus, работающими на NX-OS. И вот там исправлены практически все указанные вами неудобства классического IOS.
                0
                Мне не хотелось обижать IOS. Она взята как пример организации CLI, который знаком, думаю, большинству. Extreme называет подобное «Legacy CLI», но это менее наглядно, чем «как IOS».
                  0
                  Я просто смотрю, маркетинг аристы в основном направлен именно против IOS («традиционной ОС»). Не надо бить стариков, они хорошо нам послужили, и они тут как бы и ни при чем. Молодежь вроде нексусов и архитектурно более причесанна (вторая картинка к ним мало относится), и в работе поудобнее, и весьма забавный (и невозможный на классическом IOS) функционал имеет.
                    0
                    Мне не удалось вспомнить про маркетинг против IOS в общении, в материалах вендора. Субъективно, мне кажется, что маркетинг направлен на подчеркивание «мы рассказываем как можно больше о внутреннем устройстве железа». Мне даже кажется, что по этому пути совсем недавно пошли и другие вендоры: Cisco подчеркивает, какой ASIC в Nexus 9K, Juniper подробно рассказывает, какое железо в QFX, но при этом там не Juniper ONE, bare-metal лезут из окоп.
                      0
                      Субъективно, мне кажется, что маркетинг направлен на подчеркивание «мы рассказываем как можно больше о внутреннем устройстве железа»

                      По сравнению с Cisco они не рассказывают ничего. От того, что там стоит броадкомовская логика, никому ни холодно ни жарко. Обычно важны не ASICи, а инфраструктура вокруг них.

                      Мой любимый пример. Два часа рассказ про передачу мультикаста конкретно на cat6500. Без упоминаний PIM/IGMP, только data plane, минимум воды. Сможете показать аналогичный материал по аристе? :)
                        0
                        Соглашусь, что рассказывать про то, что сделал сам, получается лучше. И соглашусь, что у Cisco по сравнению с любыми вендорами, очень много документации. Но есть ли подобные многочасовые передачи про устройство Nexus 9K и чтобы там был упор на бродкомовскую ASIC и Cisco ACI?
                          0
                          Но есть ли подобные многочасовые передачи про устройство Nexus 9K и чтобы там был упор на бродкомовскую ASIC и Cisco ACI?

                          Сильный упор на ASIC бессмысленен, если вы не собираетесь траблшутить его на ОЧЕНЬ глубоком уровне. Скажу по секрету, что даже TAC очень часто не знает как работает логика (собственного производства или чужая) внутри их железа. Документации временами не хватает, приходится исследовать ее методом тыка. А у клиента Cisco обычно не возникает задач, подразумевающий такое закапывание в железо. Предполагается, что он заведет кейс, а дальше TAC и разработчики будут чесать затылок.

                          Да и что вы понимаете под «упором на ASIC»? Это включает описание API, позволяющего непосредственно адресовать ему команды и анализировать результат? Вам это надо?

                          Впрочем, выбирайте.
                          www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76272 (ближе всего к запрошенному вами)
                          www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76288
                          www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76331
                          Видео когда-нибудь появится. Все-таки и сам N9K буквально вчера вышел, не всё сразу.
                            0
                            Видео появились… Ну и от броадкомовской логики там, собственно, мало что осталось, так как она ничего не умеет кроме самого базового форвардинга :)
                              0
                              Спасибо! Я попробую посмотреть после регистрации на досуге.
                  0
                  Хорошая, статья. Спасибо.
                  Слышал, что вроде в Яндекс использует Аристу в своих ДЦ.

                  Может у вас еще сил и желания хватит про свичи от Cumulus Networks, Pluribus Networks и Pica8 рассказать? Я вот слежу за ними и очень мне по душе их решения, несколько раз уже порывался написать статеечку, но как-то не сложилось.
                    0
                    То, что использует Яндекс на сети, всегда покрыто слухами. До меня же доходили слухи, что там используют и bare metal.

                    Я тоже слежу за названными компаниями. У Cumulus нет полного цикла производства свитчей, как у Arista. Они предлагает несколько производителей bare-metal коммутаторов на выбор, которые, по сути, основаны на reference design от производителя ASIC. Их ОС основана на Debian, а для привычной настройки предлагается linux shell. Dinesh Dutt из Cumulus тоже участвовал в написании стандарта для VXLAN. Подход новый: отдельно покупается железо, отдельно ОС на железо.

                    Pica8 больше нацелены на OpenFlow, а не на «стандартный» CLI.

                    CloudFlare хвалит Pluribus.

                    К сожалению, на текущем месте работы я не могу уже близко познакомиться с bare-metal коммутаторами, а в Яндекс сетевые администраторы пока не требуются. Я не знаю (и Яндекс тоже не знает), кто еще в России способен вести разработки и внедрение на столь новом подходе и в больших масштабах. Просить у Accton тестовые коммутаторы под мои личные интересы мне стыдно.

                    Если у вас есть опыт — напишите пожалуйста. Думаю, не только мне будет интересно почитать.
                      0
                      К сожалению, опыт нет. Были попытки получить Cumulus, но не увенчались успехом.
                      Рекомендую посмотреть видео с последнего, да с предпоследнего, Networking Field Days (Tech Field Days).
                      Я вот как раз сейчас просматриваю видео про Pluribus.
                        0
                        Я переписывался с Cumulus чтобы более подробно узнать некоторые аспекты, которые нигде не освещены. По результатам я сделал вывод, что сейчас они заточено только под ДЦ сегмент и под очень конкретные задачи.
                        Также была такая фраза — что к концу 2014 один из их партнеров собирается выпустить свитчи с поддержкой Cumulus Linux для, так сказать, уровня доступа с 100-ми портами и несколькими гигабитными по цене в 2-3 сотри долларов. Если такое случится, закажу себе парочку в лабу и буду экспериментировать.
                          0
                          EOS от Arista можно запустить в, например, VirtualBox и хотя бы познакомиться с CLI. У Cumulus пока такого нет и они не говорят, будет ли.
                          Функционал у Cumulus ограничен, правда. Достаточно взглянуть на документацию, которая доступна после регистрации.
                          В ОС важна не только сама ОС, но и взаимодействие с железом. Один и тот же Broadcom можно запрограммировать по разному, или запрограммировать «плохо». Наличие оборудования на разных чипах (Broadcom, Intel и т.д.) ведет к увеличению различия в связке ОС-железо. Например, на Broadcom Cumulus будет хорошо работать, а на Intel распределят внутреннюю shared память на чипе не так и будет хуже.

                          Cumulus в России не может предложить поддержку уровня Cisco или Juniper: никаких русскоязычных инженеров или follow the sun. Поддержку железа вы покупаете у производителя железа, поддержку ОС у производителя ОС. При небольших объемах, когда нельзя себе позволить менять коммутаторы, как умершие харды в RAID, это может вызвать проблемы.

                          Не все так просто. нужно считать бюджет, думать о поддержке и эксплуатации и очень тщательно тестировать.
                            0
                            С бюджетированием, поддержкой и т.п. согласен.
                            В Cumulus очень интересно посмотреть как же они сделали Linux, что можно пользовать стандартные утилиты. Какую абстракцию они туда впихнули. Но то, что функционал ограничен — это да, например, tc они не умеют перекладывать на язык чипа.

                            После TFD 7 я очень впечатлен Pluribus Networks. Посмотрим, что у них выйдет.

                    Only users with full accounts can post comments. Log in, please.