Про MAC-таблицы в коммутаторах

    Привет, Хабр!
    Случается так, что иногда хочется отойти от скупой теории и перейти к практике. Сейчас как раз такой случай. Желание возникло на фоне воспоминаний того, как мы делали коммутатор. Он — вещь довольно простая, делов-то — пересылай пакеты с порта на порт, да статистику веди. Все оказалось немного сложнее.




    Вы когда нибудь задумывались над тем, как происходит коммутация? На курсах говорят, что пакет из порта (А) анализируется и пересылается согласно таблице соответствия в порт (Б) назначения, или во все порты, кроме (А) источника, если запись не найдена. Остановимся на таблице и разберем как происходит ее заполнение.
    Самый простой способ — записывать адреса в один столбец, а соответствующие порты в другой, т.е. используется линейный алгоритм поиска, асимптотическая сложность которого O(n). Худший случай для алгоритма — отсутствие искомого ключа, поскольку требуется просмотреть все ключи, и в коммутации встречается очень часто: включение нового клиента, включение или перезагрузка устройства. На самом деле, всевозможные оптимизации и хитрые алгоритмы, применяемые в чипах сетевых устройств, заточены либо для экономии памяти чипа, либо для удовлетворения требований по скорости обработки.
    Используемый же большинством производителей способ — хеш-таблица. Смысл в том, что при вычислении хеш-функции от MAC-адреса на выходе имеем сразу адрес в памяти (индекс), обратившись по которому вычитываем номер порта. Если ничего не вычитали, то пишем по этому адресу текущий порт. Сложность алгоритма поиска O(1). Правда существует проблема коллизий, но при правильно подобранной хеш-функции она минимизируется. Остается лишь проверить коллизионную стойкость устройства. Наглядный пример такой таблицы и частичной коллизии:
    У большинства записей хеш-индексы не совпадают, что в результате дает мгновенное чтение по индексу, но у Jack и Andrew случилось так, что хеш совпал и проявилась коллизия. В этом случае для разрешения коллизии производится линейный поиск по вложенному списку, что увеличивает задержку, но происходит это в единичных случаях.
    Проверку можно провести, пополняя хеш-таблицу новыми записями. Записи могут быть последовательными или случайным, а так же принадлежать специальным типам.
    Специальные типы MAC-адресов:
    • broadcast (FF:FF:FF:FF:FF:FF)
    • multicast (младший бит первого октета равен 1)

    Не все адреса должны записываться в таблицу. Например туда не попадают широковещательный и мультикаст адреса. В результате я написал небольшой генератор raw-пакетов, которому передаются параметры:
    send_pkt -i <iface> -n <mac_num>
    -i <iface>  interface for packet sending
    -n <mac_num>    number of MAC's
    -s work in slow mode
    -r generate random Src MAC for each new packet
    -a set random for all octets 
    

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

    Предусмотрен запуск в медленном режиме, например для тестирования aging-time.
    Интересно как на флуд отреагирует оборудование: проверим в двух режимах (последовательном и случайном) сколько адресов попадут в таблицу. У меня в тестовой стойке 5 коммутаторов:
    • cisco 3750G-16TD-S (12288 MAC)
    • zyxel gs-3012f (16384 MAC)
    • d-link dgs-3426 (8192 MAC)
    • metrotek x10-24 (16368 MAC)

    Специально никто их не отбирал — просто используются для различных целей, вроде проверки на совместимость STP (про это вообще можно отдельную статью написать). Пойдем по порядку.

    cisco 3750G-16TD-S


    Информация о платформе:
    cisco-01-TEST#sh ver
    Cisco IOS Software, C3750 Software (C3750-ADVIPSERVICESK9-M), Version 12.2(46)SE, RELEASE SOFTWARE (fc2)
    Copyright 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 21-Aug-08 15:43 by nachen
    Image text-base: 0x00003000, data-base: 0x01940000

    ROM: Bootstrap program is C3750 boot loader
    BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.2(18)SE1, RELEASE SOFTWARE (fc2)

    cisco-01-TEST uptime is 4 weeks, 5 days, 1 hour, 11 minutes
    System returned to ROM by power-on
    System image file is «flash:c3750-advipservicesk9-mz.122-46.SE»

    This product contains cryptographic features and is subject to United
    States and local country laws governing import, export, transfer and
    use. Delivery of Cisco cryptographic products does not imply
    third-party authority to import, export, distribute or use encryption.
    Importers, exporters, distributors and users are responsible for
    compliance with U.S. and local country laws. By using this product you
    agree to comply with applicable laws and regulations. If you are unable
    to comply with U.S. and local laws, return this product immediately.

    A summary of U.S. laws governing Cisco cryptographic products may be found at:
    www.cisco.com/wwl/export/crypto/tool/stqrg.html

    If you require further assistance please contact us by sending email to
    export@cisco.com.

    cisco WS-C3750G-16TD (PowerPC405) processor (revision F0) with 118784K/12280K bytes of memory.
    Processor board ID CSG0921P0EB
    Last reset from power-on
    1 Virtual Ethernet interface
    16 Gigabit Ethernet interfaces
    1 Ten Gigabit Ethernet interface
    The password-recovery mechanism is enabled.

    512K bytes of flash-simulated non-volatile configuration memory.
    Base ethernet MAC Address: 00:14:1C:D7:33:80
    Motherboard assembly number: 73-9143-08
    Power supply part number: 341-0045-01
    Motherboard serial number: CAT091916AM
    Power supply serial number: LIT09130942
    Model revision number: F0
    Motherboard revision number: A0
    Model number: WS-C3750G-16TD-S
    System serial number: CSG0921P0EB
    Top Assembly Part Number: 800-24591-04
    Top Assembly Revision Number: A0
    CLEI Code Number: COM1D10ARB
    Hardware Board Revision Number: 0x01

    Switch Ports Model SW Version SW Image
    — — — — —
    * 1 17 WS-C3750G-16TD 12.2(46)SE C3750-ADVIPSERVICESK9-M

    Configuration register is 0xF

    Странно, но пишет, что у нее памяти всего на 5507 адресов:
    cisco-01-TEST#show mac address-table count

    Total Mac Address Space Available: 5507

    Настройки тестового порта:
    interface GigabitEthernet1/0/1
    switchport access vlan 20
    switchport mode access
    end

    Пустая таблица адресов для тестового vlan:
    cisco-01-TEST#sh mac- vl 20
    Mac Address Table
    — Vlan Mac Address Type Ports
    — — — -----

    После пробного теста (./send_pkt -i eth0 -n 10) наблюдаем следующее:
    cisco-01-TEST#show mac address-table count

    Mac Entries for Vlan 20:
    — Dynamic Address Count: 11
    Static Address Count: 0
    Total Mac Addresses: 11

    Total Mac Address Space Available: 5496

    cisco-01-TEST#sh mac- vl 20
    Mac Address Table
    — Vlan Mac Address Type Ports
    — — — — 20 0001.0203.0001 DYNAMIC Gi1/0/1
    20 0001.0203.0002 DYNAMIC Gi1/0/1
    20 0001.0203.0003 DYNAMIC Gi1/0/1
    20 0001.0203.0004 DYNAMIC Gi1/0/1
    20 0001.0203.0005 DYNAMIC Gi1/0/1
    20 0001.0203.0006 DYNAMIC Gi1/0/1
    20 0001.0203.0007 DYNAMIC Gi1/0/1
    20 0001.0203.0008 DYNAMIC Gi1/0/1
    20 0001.0203.0009 DYNAMIC Gi1/0/1
    20 0001.0203.000a DYNAMIC Gi1/0/1
    20 50af.7312.8435 DYNAMIC Gi1/0/1

    Одиннадцатый адрес — это адрес нетбука, с которого запускался тест. Доступное место для адресов уменьшился.
    Сгенерируем заведомо большее, чем заявлено, количество адресов (12288), я указал 13000:
    cisco-01-TEST#show mac address-table count

    Mac Entries for Vlan 20:
    — Dynamic Address Count: 4281
    Static Address Count: 0
    Total Mac Addresses: 4281

    Total Mac Address Space Available: 1219

    Как видно, заполнить всю таблицу удалось не сразу и попали далеко не все адреса, вот вам и колизионность. Пробую еще раз:
    cisco-01-TEST#show mac address-table count

    Mac Entries for Vlan 20:
    — Dynamic Address Count: 5724
    Static Address Count: 0
    Total Mac Addresses: 5724

    Total Mac Address Space Available: 192

    И медленный режим (максимум, что удалось вместить):
    Mac Entries for Vlan 20:
    — Dynamic Address Count: 5945
    Static Address Count: 0
    Total Mac Addresses: 5945

    Total Mac Address Space Available: 3

    cisco-01-TEST#show mac address-table count

    Рандомный тест:
    cisco-01-TEST#sh mac address-table count

    Mac Entries for Vlan 20:
    — Dynamic Address Count: 4417
    Static Address Count: 0
    Total Mac Addresses: 4417

    Total Mac Address Space Available: 1499

    Рандомный медленный тест:
    cisco-01-TEST#sh mac address-table count

    Mac Entries for Vlan 20:
    — Dynamic Address Count: 5947
    Static Address Count: 0
    Total Mac Addresses: 5947

    Total Mac Address Space Available: 1


    Итог
    Получается, что заявленная производителем характеристика не соответствует действительности (если я не прав, например влияет IOS и для него есть особые заметки, дайте знать с пруфом). Разница почти в два раза. Даже если опираться на сведения, выводимые самой системой (5507), то им тоже не стоит верить: в быстром режиме таблица недозаполнилась на 1219 адресов, а в медленном постоянно перестраивалась и показания суммарного счетчика менялись, от режима генерации (последовательно/случайно) не зависит.

    ZyXEL GS-3012F


    Информация о платформе:
    zyxel-01-T# show version
    Current ZyNOS version: V3.80(LR.2) | 03/04/2008

    zyxel-01-T# show system-information
    System Name: zyxel-01-TEST
    System Contact:
    System Location:
    Ethernet Address: 00:19:cb:2d:d8:49
    ZyNOS F/W Version: V3.80(LR.2) | 03/04/2008
    RomRasSize: 3234952
    System up Time: 837:37:39 (11f939d5 ticks)
    Bootbase Version: V3.00 | 01/14/2005
    ZyNOS CODE: RAS Mar 4 2008 11:51:18
    Product Model: GS-3012F

    Генерируем с превышением 17000 (поддерживается 16384):
    zyxel-01-T# show mac-count
    No: 16312

    Медленный режим не использовался, т.к. даже в быстром таблица заполнена практически полностью.
    Рандомный тест:
    zyxel-01-T# show mac-count
    No: 14331


    Итог
    В целом, хорошие результаты. Коммутатор не “теряет” адреса, генерируемые на скорости порта. Размер таблицы и ее заполнение соответствует заявленному.

    D-Link DGS-3426


    Информация о платформе:
    DGS-3426:admin#show tech_support
    Command: show tech_support

    #-------------------------------------------------------------------------------
    # DGS-3426 Gigabit Ethernet Switch
    # Technical Support Information
    #
    # Firmware: Build 2.70.B56
    # Copyright 2010 D-Link Corporation. All rights reserved.
    #-------------------------------------------------------------------------------

    ******************** Basic System Information ********************

    [SYS 2000-1-1 00:07:51]

    Boot Time: 31 Dec 1999 23:59:59
    RTC Time: 2000/01/01 00:07:51
    Boot PROM Version: Build 1.00-B13
    Firmware Version: Build 2.70.B56
    Hardware Version: 2A1
    MAC Address: 00-17-9A-10-CD-AA
    [STACKING 2000-1-1 00:07:51]

    Генерируем с превышением 9000 (поддерживается 8192):
    DGS-3426:admin#show fdb vlan TEST
    Command: show fdb vlan TEST

    VID VLAN Name MAC Address Port Type
    — — — — — 20 TEST 00-01-02-03-00-01 1 Dynamic
    20 TEST 00-01-02-03-00-02 1 Dynamic
    20 TEST 00-01-02-03-00-03 1 Dynamic
    20 TEST 00-01-02-03-00-04 1 Dynamic
    20 TEST 00-01-02-03-00-05 1 Dynamic
    20 TEST 00-01-02-03-00-06 1 Dynamic
    20 TEST 00-01-02-03-00-07 1 Dynamic
    20 TEST 00-01-02-03-00-08 1 Dynamic
    20 TEST 00-01-02-03-00-09 1 Dynamic
    20 TEST 00-01-02-03-00-0A 1 Dynamic
    20 TEST 00-01-02-03-00-0B 1 Dynamic
    20 TEST 00-01-02-03-00-0C 1 Dynamic
    20 TEST 00-01-02-03-00-0D 1 Dynamic



    Total Entries: 8147

    Медленный режим, как и в предыдущем тесте не использовался, поскольку таблица заполнена почти полностью.
    Рандомный тест:
    DGS-3426:admin#show fdb vlan TEST
    Command: show fdb vlan TEST

    VID VLAN Name MAC Address Port Type
    — — — — — 20 TEST 00-00-01-33-82-27 1 Dynamic
    20 TEST 00-00-03-43-5A-66 1 Dynamic
    20 TEST 00-00-03-66-C4-5D 1 Dynamic
    20 TEST 00-00-05-32-86-B1 1 Dynamic
    20 TEST 00-00-07-6D-3A-40 1 Dynamic
    20 TEST 00-00-0A-0F-E0-AE 1 Dynamic
    20 TEST 00-00-22-3A-81-2B 1 Dynamic
    20 TEST 00-00-24-68-E9-70 1 Dynamic
    20 TEST 00-00-35-00-B0-93 1 Dynamic
    20 TEST 00-00-3F-04-BE-95 1 Dynamic
    20 TEST 00-00-43-01-A4-A4 1 Dynamic
    20 TEST 00-00-71-27-41-8A 1 Dynamic
    20 TEST 00-00-92-3C-2A-5A 1 Dynamic
    20 TEST 00-00-92-5B-94-62 1 Dynamic
    20 TEST 00-00-95-26-49-3D 1 Dynamic
    20 TEST 00-00-9F-2E-45-DF 1 Dynamic
    20 TEST 00-00-9F-6D-BE-1E 1 Dynamic
    20 TEST 00-00-A7-75-72-4F 1 Dynamic
    20 TEST 00-00-A9-17-38-DD 1 Dynamic
    20 TEST 00-00-AF-5A-8C-54 1 Dynamic



    Total Entries: 7327


    Итог
    У этого коммутатора тоже все в порядке. Таблица заполняется как заявлено, на случайных данных показатели незначительно хуже. А в качестве “фишки” таблица маков при просмотре сортируется (возможно потому, что никакого строкового процессора нет, например как у cisco).

    Metrotek X10-24


    Этот коммутатор, точнее его разработка — причина статьи. В нем используется ASIC матрица от японской компании Fujitsu. Изучая документацию, можно сделать вывод, что экономили ресурсы очень серьезно, поэтому и были выполнены независимые тесты.
    Информация о платформе:
    x10-00002# show version report
    Origin: Metrotek
    Label: Metrotek
    Codename: oxygen
    Version: 1.0.1
    Date: Wed, 4 Mar 2015 11:04:37 UTC
    Architectures: armel i386
    Components: contrib non-free
    Description: Metrotek X10-24 Gigabit Ethernet Switch

    Генерируем с превышением 17000 (поддерживается 16368):
    root@x10-00002:~# show-mac-table -v 20 | wc -l
    16368

    Медленный режим не использовался
    Рандомный тест:
    root@x10-00002:~# show-mac-table -v 20 | wc -l
    14429


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

    Вывод


    Если ваша сеть построена таким образом, что домен L2 включает множество устройств, то можно ждать беды. Странным оказалось то, что самый весомый вендор показал худшие результаты. Отсюда мораль — доверяй только собственным глазам и тесту, а не маркетинговым заявлениям с мелким шрифтом в сноске.
    Я был так удивлен положением вещей, что решил об этом написать. Если есть возможность провести такой же тест, то прошу опубликовать результаты в комментариях.

    Спасибо за внимание.
    Поделиться публикацией
    Комментарии 42
      0
      На forum.nag.ru после печально известного DES-3028 тестировали всё и вся. Результаты схожи с вашими.
        0
        А вы не могли бы дать точную ссылку, я не смог найти. Было бы интересно!
          +12
          У меня нет ссылки, у меня есть нечто лучшее. Ссылка на статью со ссылками!
          habrahabr.ru/post/155265/
          image
        0
        Кстати, хеш-функция обычно включает в себя ещё и номер VLAN-а. Это тоже надо учитывать — при большем разбросе VLAN-ов должно влезть больше MAC-ов.
          0
          Согласен, в рамках размера таблицы.
          0
          Если ваша сеть построена таким образом, что домен L2 включает множество устройств, то можно ждать беды.


          Немного недопонял.
          С точки зрения ИБ могут возникнуть проблемы?
          Если да, то какие?
            0
            Человек в статье по ссылке указывал не то, что трафик идет не на один порт, а на все, что подпадают под хеш. А это проблема ИБ. Так же можно «перекормить» некоторые коммутаторы и они откажутся принимать новые MAC-адреса, пока не пройдет aging-time старых.
              +2
              Каждое из этих утверждений зависит от реализации конкретной платформы. Именно конкретной платформы. Например, то, что вы знаете по 3750G, нельзя сходу отнести даже к 3750X, нужно тестировать или смотреть документацию.
                +1
                Так я про это и написал. Платформы специально не подбирались, а вывод следующий:
                Отсюда мораль — доверяй только собственным глазам и тесту
            0
            A sdm prefer на циске какой был включен? (show sdm prefer)
              0
              cisco-01-TEST#show sdm prefer
              The current template is «desktop default» template.
              The selected template optimizes the resources in
              the switch to support this level of features for
              8 routed interfaces and 1024 VLANs.

              number of unicast mac addresses: 6K
              number of IPv4 IGMP groups + multicast routes: 1K
              number of IPv4 unicast routes: 8K
              number of directly-connected IPv4 hosts: 6K
              number of indirect IPv4 routes: 2K
              number of IPv4 policy based routing aces: 0
              number of IPv4/MAC qos aces: 0.5K
              number of IPv4/MAC security aces: 1K


              Но я указал, что в зависимости от профиля и ios возможны вариации. Проблема не в этом (она же честно сразу пишет, что 5507 адресов доступно), а в том, что очень много теряет, если слать на скорости порта, в медленном режиме все сильно лучше. Так же проблемы с рандомом, что у других вендоров не наблюдалось.
                0
                Ну я это к тому, откуда взялось 5507 вместо 12288
                  0
                  Статью стоит поправить чтобы не вводить людей в заблуждение. Раз уж ошиблись в настройках.
                    +2
                    Я же явно указываю, что циска говорит о том, что она может переварить 6к маков. И сравниваю с этим значением показатели. Так же указал на то, что возможно «неверно приготовил» аппарат для того, чтобы он сожрал заявленные 12к. Мои претензии к ней связаны не с недостаточностью таблицы, а с потерями адресов при обучении.
                +1
                3750G — [давно устаревший и снятый с продажи] L3 свитч, у которого один TCAM задействован под все виды форвардинга. Выше совершенно верно заметили, что надо менять SDM темплейт, он переразобьет TCAM.

                Можно так:
                3750#show sdm prefer vlan
                «desktop vlan» template:
                The selected template optimizes the resources in
                the switch to support this level of features for
                8 routed interfaces and 1024 VLANs.

                number of unicast mac addresses: 12K
                number of IPv4 IGMP groups: 1K
                number of IPv4 multicast routes: 0
                number of unicast IPv4 routes: 0
                number of IPv4 policy based routing aces: 0
                number of IPv4/MAC qos aces: 512
                number of IPv4/MAC security aces: 1K

                Ваше тестирование вообще ни о чем. Проверили работу хеш-функции? А толку? В последнем абзаце совершенно верное утверждение, что не должно быть тысяч хостов на L2 сегмент, нереалистичный это сценарий. Проверили бы хотя бы как влияет заполнение таблицы на форвардинг и на запоминание новых маков. Что происходит, когда банка заполнена? Новая запись не записывается? Или самая старая выталкивается? Этот момент не так очевиден.

                Там, где прямо позарез надо очень много устройств, есть conversational mac learning (грубо говоря — не запоминаем smac пришедшего с транка пакета, если dmac не известен по одному из аксессных портов).
                  0
                  Зря вы так категорично говорите о нереалистичности. Кейс родился не просто так: довольно крупный оператор очень интересовался поддержкой большого количества адресов, поскольку у них так сеть построена. То что так по дизайну не рекомендует cisco мне так же известно, потому я это и упомянул, но жизнь более многогранна и сети на начальном этапе строят не всегда CCDP.
                  Целью теста не было проверить влияние на коммутацию, поэтому не проводилась проверка заполняемости таблицы и функций форвардинга. Что же касается запоминания адресов — проблема есть, указал о ней чуть выше,- некоторые коммутаторы не очищают кеш, пока не пройдет aging-time, что приводит к отказу в обслуживании.
                    0
                    >Целью теста не было проверить влияние на коммутацию, поэтому не проводилась проверка заполняемости таблицы и функций форвардинга.
                    А еще, видимо, не было задачи создать хотя бы относительно реалистичное с точки зрения SP заполнение TCAM :)

                    >Что же касается запоминания адресов — проблема есть, указал о ней чуть выше,- некоторые коммутаторы не очищают кеш, пока не пройдет aging-time, что приводит к отказу в обслуживании.
                    Где там был отказ в обслуживании?

                    И заодно:
                    >очень много теряет, если слать на скорости порта, в медленном режиме все сильно лучше.
                    А какой вообще смысл проверять такое на древнющей железке, которую уже даже не купишь кроме как подержанную? TCAM ведь штука медленная на запись. Да, могут быть проблемы на старых платформах. Проверьте что-нибудь более модное вроде замечательных 3650/3850 или шеститонник на PFC4.

                    >Так же проблемы с рандомом, что у других вендоров не наблюдалось.
                    Так и тесты ведь далеко не жизненные. Что если окажется, что с добавлением тега VLAN'а равномерность заполнения существенно улучшится у 3750 и ухудшится у остальных? И опять же, мы говорим про одну маленькую платформу. Если взять даже 3750Х — наверняка результат сильно изменится неизвестно в какую сторону.
                      0
                      Согласен. Более того, я даже призвал поучаствовать в тесте (ссылка на генератор дана). Мной проверялось на том, что было, если вы желаете предоставить железо для теста — проведу тест на нем. Статья все таки не о железе, а о практическом аспекте использования хеш-таблиц.
                        +3
                        Немного не в тему, понятно что вы говорите об отсутствии полноты тестирования.

                        Но некоторые ваши утверждения об устаревшем железе, обескураживают :)
                        — 3750G — [давно устаревший и снятый с продажи] L3 свитч
                        — А какой вообще смысл проверять такое на древнющей железке, которую уже даже не купишь кроме как подержанную?
                        — Проверьте что-нибудь более модное вроде замечательных 3650/3850

                        Создается впечатление, что компании так и «рвутся» покупать модные и современные железки.
                        У многих стоит целый зоопарк немодного железа который никуда исчезать не собирается.
                        Совсем недавно наткнулся в одном зоопарке на 2900XL. :)
                          0
                          >Создается впечатление, что компании так и «рвутся» покупать модные и современные железки.
                          Так если количественные требования меняются — да, закупается нечто более современное. Например, потому что тупо портов не хватает, а устаревшее уже не продается. Ну и по устаревшему железу уже сложно спросить TAC «чо это он не успевает TCAM наполнять?». И даже если TAC по железке еще работает, и удалось к примеру выявить ранее неизвестный и исправимый программный баг — его уже не исправят.

                          >Можно подумать цыска одумалась и перестала жлобствовать. ТКАМа и буферов как недокладывали, так и продолжают.
                          Большие буфера — зло, всё хорошо в меру, и в тех линейках, где их реально не хватало, эта проблема уже устранена в новых ревизиях/железках. TCAM'ов тоже хватает, если использовать железо по назначению, в соответствии с гайдлайнами. Плюс опять же доступные где-то оптимизации control plane вроде conversational mac learning — аксессный свитч запомнит мак пакета, если в этом мало смысла, скажем — отправитель пакета с другой стороны сети просто послал arp и не общается ни с кем подключенным к этому свитчу.
                            0
                            Но устаревшее тоже никуда не исчезнет, поэтому тесты по той же 3560 все также актуальны :)
                            И почему вас не удивили в этом отношении D-Link DGS-3426 или ZyXEL GS-3012F… они те ещё EOL.

                            Я лишь пытаюсь донести, что если железо устарело, это не значит, что не надо по нему тестов или обзоров делать.
                          –2
                          Можно подумать цыска одумалась и перестала жлобствовать. ТКАМа и буферов как недокладывали, так и продолжают.
                        +2
                        В последнем абзаце совершенно верное утверждение, что не должно быть тысяч хостов на L2 сегмент, нереалистичный это сценарий.

                        В мире ISP вполне реалистичный. Но это скорее исключение.
                          0
                          Почти одновременно написали.
                            0
                            Не с этим железом.
                              0
                              Даже представить себе не могу такую картину. Точнее представить могу, только с обязательным условием кривых рук админов или безмозглого руководства.
                              В реальности уже при 200 хостах в л2 сегменте начинает все дико лагать и глючить.
                                0
                                Вполне может быть.
                                Один L2 сегмент — это необязательно один широковещательный домен.
                                Это может быть, например, svlan с qinq. Либо один большой VLAN с traffic segmentation на всех конечных портах. Оба этих варианта имеют право на жизнь (каждый в своём случае, конечно) и каждый из них без проблем уместит хоть 10 тысяч, хоть 20 тысяч хостов — абы хватило таблицы MAC-адресов.
                          • НЛО прилетело и опубликовало эту надпись здесь
                              +2
                              Можно и про это написать. Что бы вы хотели увидеть в такой статье (просто ну очень большой объем информации имеется)?
                              • НЛО прилетело и опубликовало эту надпись здесь
                                0
                                Поддержу. Было бы очень интересно почитать про разработку коммутатора
                                  0
                                  Хотелось бы конкретики, какие аспекты интересуют: железо, софт, какие-то протоколы и реализация, зоопарк техники и его взаимодействия?
                                    –3
                                    Главный вопрос: зачем?
                                      0
                                        0
                                        Ну а все же? Не просто так ведь вы это пилите. Цели какие то имеются, задачи и так далее.
                                0
                                del
                                  +2
                                  В целом идея этого теста понятна. На моей практике, действительно встречались коммутаторы с коллизиями в хэш таблице CAM адресов, но это было оборудование не компании Cisco Systems.

                                  Относительно тестирования и выводов — они не корректные.

                                  Странно, но пишет, что у нее памяти всего на 5507 адресов:


                                  В коммутаторах Cisco Catalyst действительно существует такое понятие, как SDM профайл. От выбора SDM профайла, зависит размер CAM таблицы. Читайте документацию.

                                  Сгенерируем заведомо большее, чем заявлено, количество адресов (12288), я указал 13000:

                                  cisco-01-TEST#show mac address-table count

                                  Mac Entries for Vlan 20:
                                  — Dynamic Address Count: 4281
                                  Static Address Count: 0
                                  Total Mac Addresses: 4281

                                  Total Mac Address Space Available: 1219

                                  Как видно, заполнить всю таблицу удалось не сразу и попали далеко не все адреса, вот вам и колизионность. Пробую еще раз:


                                  Кто Вам сказал, что здесь виновата коллизия в CAM таблице?

                                  Здесь проблема с большой вероятностью связана с производительностью control-plane коммутатора. Ибо MAC Learning для данной платформы — осуществляется на CPU, а не в «железе». Если в сторону control-plane поступает множество запросов, то есть риск того, что «ниточка» к CPU или сам CPU коммутатора будут перегружены. В этом случае — запрос будет сброшен. Кроме того, мы с Вами говорим про коммутатор третьего уровня и теоретически ситуация может осложняться (зависит от конфигурации коммутатора) при наличии L3 интерфейсов (в этом случае коммутатору, может потребоваться ARP Learning).

                                  И медленный режим (максимум, что удалось вместить):

                                  Mac Entries for Vlan 20:
                                  — Dynamic Address Count: 5945
                                  Static Address Count: 0
                                  Total Mac Addresses: 5945

                                  Total Mac Address Space Available: 3

                                  cisco-01-TEST#show mac address-table count

                                  Рандомный тест:
                                  cisco-01-TEST#sh mac address-table count

                                  Mac Entries for Vlan 20:
                                  — Dynamic Address Count: 4417
                                  Static Address Count: 0
                                  Total Mac Addresses: 4417

                                  Total Mac Address Space Available: 1499

                                  Рандомный медленный тест:
                                  cisco-01-TEST#sh mac address-table count

                                  Mac Entries for Vlan 20:
                                  — Dynamic Address Count: 5947
                                  Static Address Count: 0
                                  Total Mac Addresses: 5947

                                  Total Mac Address Space Available: 1


                                  Далее, давайте посмотрим на Ваш генератор и «медленный режим»:

                                  Файл etherraw/send_pkt.c — 211 строка

                                  /* Wait timeout */
                                  if(workslow == 1) usleep(SleepTime);


                                  Файл «etherraw/send_pkt.h» — 20 строка

                                  #define SleepTime 50000 // microseconds


                                  Смотрим дальше, 50000 microseconds = 0.05 sec. MAC aging time by default 300 seconds или 0.05/300 = 6000 адресов за 5 минут (или 1200 адресов в минуту).

                                  Из Вашего поста непонятно. Когда был проверена CAM таблица? Через какое время? После 5 минут работы Вашего скрипта? Через 10 минут? Через 15 минут? Это имеет значение и может влиять на результаты.

                                  Далее, очень многое зависит от L2 конфигурации коммутатора и портов. Вы пишите, что конфигурация порта выглядит следующим образом:

                                  Настройки тестового порта:
                                  interface GigabitEthernet1/0/1
                                  switchport access vlan 20
                                  switchport mode access
                                  end


                                  Это значит, что порт проходит все стадии STP. Теперь поговорим на тему TCN/STP, flushing CAM таблиц и Aging-time.

                                  Every bridge is then notified and reduces the aging time to forward_delay (15 seconds by default) for a certain period of time (max_age + forward_delay). It is more beneficial to reduce the aging time instead of clearing the table because currently active hosts, that effectively transmit traffic, are not cleared from the table.

                                  Опять же, когда был запущен тест? Сразу? После того, как стал доступен другой хост? Через 15 секунд, после того, как порт перешел в состояние forwarding?

                                  В общем и целом — идея интересная, но методика тестирования неправильная, ибо вопросов больше, чем ответов.

                                    +1
                                    Кто Вам сказал, что здесь виновата коллизия в CAM таблице?

                                    Это предположение. Схемотехники и временных диаграмм работы ASIC у меня нет,- это немного другое исследование, кстати тоже возможное.

                                    Здесь проблема с большой вероятностью связана с производительностью control-plane коммутатора. Ибо MAC Learning для данной платформы — осуществляется на CPU, а не в «железе». Если в сторону control-plane поступает множество запросов, то есть риск того, что «ниточка» к CPU или сам CPU коммутатора будут перегружены. В этом случае — запрос будет сброшен. Кроме того, мы с Вами говорим про коммутатор третьего уровня и теоретически ситуация может осложняться (зависит от конфигурации коммутатора) при наличии L3 интерфейсов (в этом случае коммутатору, может потребоваться ARP Learning).

                                    Возможно, тем не менее проблема есть. Согласитесь, что вам, как пользователю, откровенно говоря, должно быть наплевать на то, у кого там проблема с производительностью при learning.
                                    Коммутатор хоть и L3, но стоит он в тестовой стойке и никак не нагружен, не использует функционал L3 и не имеет L3 интерфейсов.

                                    Смотрим дальше, 50000 microseconds = 0.05 sec. MAC aging time by default 300 seconds или 0.05/300 = 6000 адресов за 5 минут (или 1200 адресов в минуту).

                                    Из Вашего поста непонятно. Когда был проверена CAM таблица? Через какое время? После 5 минут работы Вашего скрипта? Через 10 минут? Через 15 минут? Это имеет значение и может влиять на результаты.

                                    Задается количество маков, которые генерируются, т.е. генерация не зависит от времени. Если взять ваши же расчеты, то получается, что 6к пакетов сгенерируется как раз за 300 секнд. На практике обучилось меньше, чем могло сгенерироваться и меньше, чем cisco пишет. Но стоит отметить, что таблица заполнилась полностью (она динамически изменяема), так что тут претензий нет. Претензия лишь в «потере» адресов в быстром режиме. Или для вас это не проблема?

                                    Это значит, что порт проходит все стадии STP. Теперь поговорим на тему TCN/STP, flushing CAM таблиц и Aging-time.

                                    Every bridge is then notified and reduces the aging time to forward_delay (15 seconds by default) for a certain period of time (max_age + forward_delay). It is more beneficial to reduce the aging time instead of clearing the table because currently active hosts, that effectively transmit traffic, are not cleared from the table.

                                    Опять же, когда был запущен тест? Сразу? После того, как стал доступен другой хост? Через 15 секунд, после того, как порт перешел в состояние forwarding?


                                    Если бы тест был запущен сразу, то количество адресов в первом тестовом запросе равнялось бы нуля (у меня их там 10), что не верно, их там 10, что соответствует условию тестовой генерации. Последующие же этапы тестирования проводились без отключения от порта, следовательно STP не перестраивался.
                                      +1
                                      Это предположение. Схемотехники и временных диаграмм работы ASIC у меня нет,- это немного другое исследование, кстати тоже возможное.


                                      А чего тут исследовать? Открыл, посмотрел какой ASIC стоит, поискал в Интернете спецификацию на чип (или запросил у вендора). Схему и внутр. устройство чипа конечно же не дадут, да и не нужна она (сомневаюсь, что у Вас цель — разработка своего ASIC).

                                      Возможно, тем не менее проблема есть. Согласитесь, что вам, как пользователю, откровенно говоря, должно быть наплевать на то, у кого там проблема с производительностью при learning.
                                      Коммутатор хоть и L3, но стоит он в тестовой стойке и никак не нагружен, не использует функционал L3 и не имеет L3 интерфейсов.


                                      Не согласен! Не нужно здорового, записывать в больного.

                                      Первое. Рекомендация — это подсеть не больше /24 (а это не более 254 IP адресов). Ибо в большом широковещательном домене Ethernet начинается масса других проблем.
                                      Второе. Вы забываете, что рекомендованный дизайн для STP это не более 7 транзитных хопов. Даже если мы представим себе, что у нас к магистральному коммутатору подключено каскадом 5 коммутаторов по 48 портов (к которым в свою очередь подключен IP телефон + компьютер), то это не более 480 MAC адресов.
                                      Третье. Даже если флапнет магистральный линк, то это далеко не значит, что все 480 хостов начнут моментально посылать пакеты. Более того, далеко не факт, что всем 480'ми хостам потребуется отправить трафик «наверх». Не забываем про поведение коммутатора в случаях с uknown unicast и для какого коммутатора и где будет возникать unknown unicast ситуация (это к вопросу сходимости L2 среды).
                                      Четвертое. Коммутатор 3750G предназначен для офисной сети.
                                      Пятое. Конечно же существуют сети, в которых больше тысячи MAC адресов, но это сети другого класса и оборудование там используется совершенно другое, ибо к ним предъявляют соотвествующие требование. Я еще ни разу не видел, чтобы кто-то для агрегации колец на Metro Ethernet или в ЦОДе ставил 3750, быстрее встретишь 4500/4900 серию (у которых аппаратная платформа одинаковая). У 4500 серии MAC Learning Rate в районе 20,000 MAC per second.
                                      Шестое. Даже если коммутатор не под нагрузкой, это еще ни о чем не говорит. SDM тому пример.
                                      Седьмое. В реальности, всю эту «ораву» MAC адресов нужно приземлить на L3 интерфейс маршрутизатора. И быстрее начнутся проблемы с ARP Learning и control-plane на маршрутизаторе, чем проблемы на коммутаторе.
                                      Седьмое. 3750G — это старое железо и если мне не изменяет память, оно уже объявлено в EoS/EoL. На смену данному железу уже пришло оборудование следующего поколения и далеко не факт, что там будут такие же «проблемы».

                                      Задается количество маков, которые генерируются, т.е. генерация не зависит от времени. Если взять ваши же расчеты, то получается, что 6к пакетов сгенерируется как раз за 300 секнд. На практике обучилось меньше, чем могло сгенерироваться и меньше, чем cisco пишет. Но стоит отметить, что таблица заполнилась полностью (она динамически изменяема), так что тут претензий нет. Претензия лишь в «потере» адресов в быстром режиме. Или для вас это не проблема?


                                      Скажем так, control-plane вещь, которая требует к себе трепетного отношения. Как я уже сказал ранее, пакеты могут сбрасываться (discard), если пакет адресованный CPU сброшен, то и Learning'а не будет, это очевидно как 2x2. Что касается претензий, то в Вашей статье претензии предъявляются к «коллизиям» в CAM таблице, наличие которых — доказать не удалось. Что касается проблемы, отвечаю — да, это не проблема (смотри развернутый ответ выше).

                                      Если бы тест был запущен сразу, то количество адресов в первом тестовом запросе равнялось бы нуля (у меня их там 10), что не верно, их там 10, что соответствует условию тестовой генерации. Последующие же этапы тестирования проводились без отключения от порта, следовательно STP не перестраивался.


                                      Методика тестирования об этом умалчивает. Что касается того, перестраивался или не перестраивался STP — далеко не факт и нам это неочевидно (и мы (читатели), можем лишь предполагать). STP — это control-plane, а создавая большую нагрузку на control-plane не факт, что STP не дергался. Приведу пример. У моего знакомого была проблема, на одном из маршрутизаторов отлетали core линки, на которых весел BFD из-за большой нагрузки, которая была вызвана ARP Learning'ом и создаваемой этим процессом нагрузкой на control-plane (но это уже другая история). :-)

                                        0
                                        Более правильная методика тестирования (для всех коммутаторов, а не только Cisco).

                                        Стенд:

                                        коммутатор — генератор

                                        Подготовка стенда к тестированию:

                                        Отключить STP.
                                        Отключить Aging для CAM таблиц.
                                        Увеличить интервал для workslow скажем в четыре раза.
                                        Проверить, что у нас нет L3 интерфейсов в этом VLAN'е.
                                        Очищаем таблицу CAM — проверяем текущее количество MAC адресов.

                                        Далее (тесты без VLAN'ов):

                                        1. Тест — обычный increment битов в 2х последних октетах MAC адреса.
                                        2. Тест — increment слева направо для предпоследнего октета в MAC адресе и справа налево в последнем октете MAC адреса.
                                        3. Тест — повторить 1 и 2, но изменить предпоследний октет на 3,4 и 5.
                                        4. Тест — random MAC
                                        5. Тест — XOR хэширование

                                        Далее (тесты с VLAN'ами):

                                        Провести весь набор тестирования из первой группы тестов, для второй группы тестов, заменив один из октетов VLAN идентификатором.

                                        Комментарий:

                                        MAC адреса сгенерировать заранее (количество сгенерированных MAC адресов = количество свободных записей в CAM таблице). Вывод CAM таблиц сравнить.

                                        PS: Хэширование CAM таблицы может включать в себя не только MAC + VLAN, но и Port ID (и даже Bridge ID :)).
                                          0
                                          А чего тут исследовать? Открыл, посмотрел какой ASIC стоит, поискал в Интернете спецификацию на чип (или запросил у вендора). Схему и внутр. устройство чипа конечно же не дадут, да и не нужна она (сомневаюсь, что у Вас цель — разработка своего ASIC).

                                          Вряд ли cisco вам пришлет даже обобщенный даташит на свои ASIC. Но мы здесь не про это говорим, проехали.

                                          Не согласен! Не нужно здорового, записывать в больного.


                                          Не понял аналогии, далее по тексту.

                                          Первое. Рекомендация — это подсеть не больше /24 (а это не более 254 IP адресов). Ибо в большом широковещательном домене Ethernet начинается масса других проблем.

                                          Рекомендация кого? Cisco? Да, есть такое, я тоже учился у них на курсах. Несколько выше я писал, откуда вообще кейс такой возник.

                                          Второе. Вы забываете, что рекомендованный дизайн для STP это не более 7 транзитных хопов. Даже если мы представим себе, что у нас к магистральному коммутатору подключено каскадом 5 коммутаторов по 48 портов (к которым в свою очередь подключен IP телефон + компьютер), то это не более 480 MAC адресов.

                                          Это ваше умозаключение, основанное на ошибке, истолкованной вами же в пункте выше (так же упоминаете «рекомендованный дизайн»). Хотя в идеальном мире не могу с вами не согласиться.

                                          Третье. Даже если флапнет магистральный линк, то это далеко не значит, что все 480 хостов начнут моментально посылать пакеты. Более того, далеко не факт, что всем 480'ми хостам потребуется отправить трафик «наверх». Не забываем про поведение коммутатора в случаях с uknown unicast и для какого коммутатора и где будет возникать unknown unicast ситуация (это к вопросу сходимости L2 среды).

                                          Опять же ваши допущения. А если рассмотреть ситуацию несколько иначе. Есть злоумышленник, который генерит тонны маков, что будет с клиентами (кстати, почему мы только о cisco, в статье и о других говорится)? В некоторых случаях они просто не получат сервис. И не надо сейчас говорить о vpls, atom, vlan-per-client и т.п. Я не спорю что это применимо и даже необходимо, просто сейчас мы не об этом.

                                          Четвертое. Коммутатор 3750G предназначен для офисной сети.

                                          А я вот знаю как минимум 5 крупных операторов, сети 2 из которых я даже эксплуатировал, где стоят себе такие 3750 и даже не G и работают на благо клиентов. Так что замечание опять же из области теории и дизайна, навязываемого сиськами.

                                          Пятое. Конечно же существуют сети, в которых больше тысячи MAC адресов, но это сети другого класса и оборудование там используется совершенно другое, ибо к ним предъявляют соотвествующие требование. Я еще ни разу не видел, чтобы кто-то для агрегации колец на Metro Ethernet или в ЦОДе ставил 3750, быстрее встретишь 4500/4900 серию (у которых аппаратная платформа одинаковая). У 4500 серии MAC Learning Rate в районе 20,000 MAC per second.

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

                                          Седьмое. В реальности, всю эту «ораву» MAC адресов нужно приземлить на L3 интерфейс маршрутизатора. И быстрее начнутся проблемы с ARP Learning и control-plane на маршрутизаторе, чем проблемы на коммутаторе.

                                          Вообще — да, но задача теста была другая.

                                          Седьмое. 3750G — это старое железо и если мне не изменяет память, оно уже объявлено в EoS/EoL. На смену данному железу уже пришло оборудование следующего поколения и далеко не факт, что там будут такие же «проблемы».

                                          Скажите это тысячам операторов на территории этой страны, даже интересно, что вам ответит экономический отдел.
                                            0
                                            Вряд ли cisco вам пришлет даже обобщенный даташит на свои ASIC. Но мы здесь не про это говорим, проехали.


                                            Открою Америку. В большинстве случаях, Cisco использует элементную базу других вендоров. Приведу примеры сходу: Marvell, Trident, EZchip, RISC CPU (всякие там Motorolla, IBM), x86 (Intel).

                                            Рекомендация кого? Cisco? Да, есть такое, я тоже учился у них на курсах. Несколько выше я писал, откуда вообще кейс такой возник.


                                            Рекомендация IEEE — стандарт IEEE 802.1D. Part 3: Media Access Control (MAC) Bridges, 108 страница, таблица 8-1 Maximum Bridge Diameter:

                                            Table 8-1—Maximum Bridge Diameter
                                            Parameter Recommended
                                            value
                                            Maximum bridge diameter 7

                                            Это ваше умозаключение, основанное на ошибке, истолкованной вами же в пункте выше (так же упоминаете «рекомендованный дизайн»).


                                            Это большинство сетей, статистика утверждает обратное. Исключения — Metro Ethernet у SP и DC, но как я уже сказал ранее, там используется оборудование другого класса.

                                            Опять же ваши допущения. А если рассмотреть ситуацию несколько иначе. Есть злоумышленник, который генерит тонны маков, что будет с клиентами (кстати, почему мы только о cisco, в статье и о других говорится)?


                                            Первое это уже все пройдено в SP сегменте. Второе большинство устройств позволяют ограничить колличество MAC адресов per port и сделать даже привязку (например Port-Security). Это умел даже старенький 3COM.

                                            В некоторых случаях они просто не получат сервис.


                                            С дуру, можно кое чего сломать.

                                            И не надо сейчас говорить о vpls, atom, vlan-per-client и т.п. Я не спорю что это применимо и даже необходимо, просто сейчас мы не об этом.


                                            Зачем? :-) Я даже и не начинал.

                                            А я вот знаю как минимум 5 крупных операторов, сети 2 из которых я даже эксплуатировал, где стоят себе такие 3750 и даже не G и работают на благо клиентов. Так что замечание опять же из области теории и дизайна, навязываемого сиськами.


                                            Замечания навязаны несколько Cisco, сколько личным опытом и здравым смыслом. Подобный подход (и то это редкость!), скорее характерен для пионернетов, которые лет 8 назад активно скупались крупными игроками центрального региона, нашей необъятной страны. И кстати проблемы у этих пионернетов были соотвествующие.

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


                                            Опять же, давайте не будем выдавать желаемое за действительное. Этот 2900XL запросто может обслуживать офис из 5 человек или парочку стареньких маршрутизаторов и каналов в темном чулане.

                                            Скажите это тысячам операторов на территории этой страны, даже интересно, что вам ответит экономический отдел.


                                            Поверьте, я прекрасно знаю ситуацию и понимаю специфику в операторском сегменте.

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

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