Ещё раз про хеш-коллизии в коммутаторах  



Ещё раз про хеш-коллизии в коммутаторах +9

Присказка


Поставили мы тут в тестовом режиме один коммутатор от Eltex-а — MES5248. И начали мы его по-всякому мучать — VLAN-ы настраивать, MSTP прикручивать и всячески изголяться. В лабораторных условиях видимых косяков не нашли — поставили под реальный живой трафик. И тут вылез странный глюк, на уровне неуловимого Джо — время от времени в ARP-таблице у отдельных записей отсутствовало значение в поле порт (да, они его в ARP-таблице выводят. Удобно). Попытки поймать за хвост, повторить не увенчались особым успехом. Техподдержка ломала голову себе и разработчикам, в конечном итоге пришли к наблюдению, что в ARP-таблице записи живут дольше, чем в MAC-таблице. И дольше, чем оно сконфигурировано, что, конечно баг, но не ужас какой смертельный. Осталось лишь проверить, что записи в MAC-таблице умирают по таймауту, естественной смертью, а не бывают убиты другими при хеш-коллизии.

Ну, проверять такое руками, вестимо, лень. Шутка ли — просмотри >2000 маков несколько раз подряд да найди дыры. Надо кодить. Делать под конкретный свич — дело неблагодарное, так что код получился под все свичи, которые есть в хозяйстве. Если интересно, что получилось — читайте сказку.

Сказка


В итоге родилась прожка, которая сперва чистит MAC-таблицу, а потом, примерно раз в минуту сливает её с коммутатора и анализирует. При этом считаются

1. Уникальные маки, наблюдавшиеся с начала тестирования. (Ever)
2. Уникальные маки, наблюдающиеся в текущий момент на коммутаторе.(Now)
3. Для каждого мака помнится момент времени, когда он первый раз появился в таблице. И если он в ней появляется снова через время, меньшее чем aging time — считается, что его по какой-то причине вышибло. (Early deaths)
4. Подсчитываются все такие маки. (то, что до слеша в Early deaths)

Кстати, я снимал fdb-таблицу telnet-ом, хотя можно и по snmp, о чём на хабре уже писали, в отличие от результатов UserSide, по дороге обнаружились коммутаторы, которые по telnet-у отдают fdb дико долго, а по snmp — мгновенно, например — DXS-3326GSR.

Наблюдения ведутся 20 минут.

К вящему моему удивлению, коммутатор, ради которого всё затевалось, показал себя на удивление хорошо — за время до aging time Now от Ever не отличалось и в Early deaths было пусто. Аналогично ведут себя Cisco 3750.

А вот в остальном зоопарке проблемы-таки обнаружились. Хотя большинство протестированных dlink-ов и имеют меньшую MAC-таблицу, но и общее количество адресов зачастую гораздо меньше. В результате нарисовался такой график — зависимости количества проблем от общего размера мак-таблицы.



Собственно, какие выводы — разные коммутаторы одного вендора ведут себя по-разному и количество проблем растёт очень быстро от числа маков. Орг-вывод оперативный — уменьшать количество vlan-ов на 3526. Увеличить aging time на всём оборудовании.

Дальше — судя по всему, коммутаторы разбираются с хеш коллизиями принципаиально по-разному. Некоторые — выкидывают старые маки, другие — вероятно, как-то обходят коллизию при неплотно забитой таблице. Как именно они это делают, мне не ясно — либо считают адрес по второй хеш-функции, либо кладут новый адрес в соседнюю ячейку, либо тупа броадкастят трафик до нового мака, либо ещё что-то. Если это читают представители вендоров и эта информация не секретна — поделитесь в комментариях.

В планах — доработать прогу до сбора данных и управления по SNMP, отцепить от внутренних зависимостей, выложить в паблик. Соответственно, вопрос к сообществу — стоит ли вообще это делать?

Ещё интересен такой вопрос — какие есть мысли, как удалённо ловить ситуацию с броадкастом на новые маки и оценить количество и/или объём такого трафика?
Выложить ли код в паблик

Проголосовало 92 человека. Воздержалось 63 человека.

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

Вы можете помочь и перевести немного средств на развитие сайта

Теги:



Комментарии (15):

  1. Obramko
    /#8609587 / +1

    Для DES-3200-** следует указывать ревизию.

    • mickvav
      /#8609613 / +1

      Железки или прошивки?

      • xBrowser
        /#8609799 / +2

        Для этой железки серии (A1/B1) и (C1) два разных коммутатора, с разными прошивками.

        • mickvav
          /#8610123

          3200-26 A1 три штуки на всю сеть и никаих выбросов на них нет, так что нерепрезентативно,
          можно считать, что все 3200 на картинке — C.

      • Obramko
        /#8609819

        Железки конечно. Как верно заметили выше, A/B и C серии — разные коммутаторы.

      • Yoda33
        /#8609901

        Аппаратная ревизия. К примеру A и B по синтаксису схожи, а вот C коренным образом отличается, в ней другой чипсет, иной функционал PCF. Вообще в приличном обществе ведндору бы канделябром закатили за такое. Модель одна, а фактически это разные железки. Даже прошивка имеет иную нумерацию.

        • mickvav
          /#8609989

          Ну да, dlink подобными финтами грешен и нетолько в свичах, но и в домашних роутерах. 3200-xx — что-то не могу сходу найти ни одного A или B, только C. К вечеру скриптик, подбивающий эти циферки, отработает — отчитаюсь.

          • Obramko
            /#8610169

            A и B — фактически тот же коммутатор. Там изменения не касались функционала, да и прошивка для них общая.
            А вот C — другое дело, он даже выглядит совсем по-другому.

            • mickvav
              /#8610189

              Ну нету у нас A и B в значимых количествах. И артефактов на тех, которые есть — не видно.

    • achekalin
      /#8610035 / +1

      Эта привычка D-link-а (да и не только его) — увы, много крови портит. Берут индекс успешной на рынке железки, делают новую с тем же индексом, но с новой «ревизией», делают ее плохо — и все «счастливы».

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

      Что мешает брать для нового железа новый индекс — мне сложно понять. Маркетологи, вероятно!

      Остается одно — покупать, внимательно читаю спецификацию для букв ревизии.

      • mickvav
        /#8610137

        Да, пора уже писать искуственный интеллект, который глядя на рекурсивный вывод snmpwalk-a и вооружившись какими-нибудь разумными эвристиками и google-fu раскладывает OID-ы по полочкам сам :)

  2. ksg222
    /#8609933 / +1

    Уважаемый автор, не совсем понятен орг-вывод по коммутатору 3526, предлагающий уменьшить количество vlan’нов. Как это влияет на количество хеш-коллизий? Разве не наоборот, раскидываем MAC-адреса по vlan, чтобы попытаться сделать более разнообразные хеши?

    Если посмотреть на природу хеш-коллизий, они возникают из-за того, что два разных MAC-адреса имеют одинаковое значение хеша. Поэтому, по идее, размер таблицы MAC не имеет определяющего значения при возникновении хеш-коллизий. Основная причина в самом алгоритме вычисления. Поэтому, на мой взгляд, стоило бы переформулировать название таблицы: зависимость количества проблем от количества MAC-адресов. Плюс, добавить табличку со средним значением количества проблем по моделям коммутаторов (т.е. кто и в какой степени этим страдает). Думаю, было бы интересно.

    • mickvav
      /#8609981

      Ну, понятно, что раскидывание по vlan-ам не спасёт, если у вас просто хеш функция будет общая. Более того, если в таком зоопарке плодить vlan-per-user — у нас ещё и мак роутера в паре с разными VlanID позабивает таблицу весьма. Так что «правильно» — меньше абонов в сегиенте, меньше сегментов в свиче. Идеально, наверное — по vlan-у на свич. Таблички подобью, но среднее — не вполне репрезентабельно. Думаю, правильно нарисовать среднее и максимальное количество проблем от количества маков. Нарисую, да.

    • mickvav
      /#8609993

      Да, извините — действительно, коллизионный домен при vlan-per-user сократится, если только свич не проходной для других собратьев, а чисто абонентский — тогда будет работать.