Присказка
Поставили мы тут в тестовом режиме один коммутатор от 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, отцепить от внутренних зависимостей, выложить в паблик. Соответственно, вопрос к сообществу — стоит ли вообще это делать?
Ещё интересен такой вопрос — какие есть мысли, как удалённо ловить ситуацию с броадкастом на новые маки и оценить количество и/или объём такого трафика?
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (15)
ksg222
12.10.2015 15:10+1Уважаемый автор, не совсем понятен орг-вывод по коммутатору 3526, предлагающий уменьшить количество vlan’нов. Как это влияет на количество хеш-коллизий? Разве не наоборот, раскидываем MAC-адреса по vlan, чтобы попытаться сделать более разнообразные хеши?
Если посмотреть на природу хеш-коллизий, они возникают из-за того, что два разных MAC-адреса имеют одинаковое значение хеша. Поэтому, по идее, размер таблицы MAC не имеет определяющего значения при возникновении хеш-коллизий. Основная причина в самом алгоритме вычисления. Поэтому, на мой взгляд, стоило бы переформулировать название таблицы: зависимость количества проблем от количества MAC-адресов. Плюс, добавить табличку со средним значением количества проблем по моделям коммутаторов (т.е. кто и в какой степени этим страдает). Думаю, было бы интересно.
mickvav
12.10.2015 15:31Ну, понятно, что раскидывание по vlan-ам не спасёт, если у вас просто хеш функция будет общая. Более того, если в таком зоопарке плодить vlan-per-user — у нас ещё и мак роутера в паре с разными VlanID позабивает таблицу весьма. Так что «правильно» — меньше абонов в сегиенте, меньше сегментов в свиче. Идеально, наверное — по vlan-у на свич. Таблички подобью, но среднее — не вполне репрезентабельно. Думаю, правильно нарисовать среднее и максимальное количество проблем от количества маков. Нарисую, да.
mickvav
12.10.2015 15:36Да, извините — действительно, коллизионный домен при vlan-per-user сократится, если только свич не проходной для других собратьев, а чисто абонентский — тогда будет работать.
Obramko
Для DES-3200-** следует указывать ревизию.
mickvav
Железки или прошивки?
xBrowser
Для этой железки серии (A1/B1) и (C1) два разных коммутатора, с разными прошивками.
mickvav
Организуем…
mickvav
3200-26 A1 три штуки на всю сеть и никаих выбросов на них нет, так что нерепрезентативно,
можно считать, что все 3200 на картинке — C.
Obramko
Железки конечно. Как верно заметили выше, A/B и C серии — разные коммутаторы.
Yoda33
Аппаратная ревизия. К примеру A и B по синтаксису схожи, а вот C коренным образом отличается, в ней другой чипсет, иной функционал PCF. Вообще в приличном обществе ведндору бы канделябром закатили за такое. Модель одна, а фактически это разные железки. Даже прошивка имеет иную нумерацию.
mickvav
Ну да, dlink подобными финтами грешен и нетолько в свичах, но и в домашних роутерах. 3200-xx — что-то не могу сходу найти ни одного A или B, только C. К вечеру скриптик, подбивающий эти циферки, отработает — отчитаюсь.
Obramko
A и B — фактически тот же коммутатор. Там изменения не касались функционала, да и прошивка для них общая.
А вот C — другое дело, он даже выглядит совсем по-другому.
mickvav
Ну нету у нас A и B в значимых количествах. И артефактов на тех, которые есть — не видно.
achekalin
Эта привычка D-link-а (да и не только его) — увы, много крови портит. Берут индекс успешной на рынке железки, делают новую с тем же индексом, но с новой «ревизией», делают ее плохо — и все «счастливы».
Иные организации берут партию, скажем, свичей, для дальнейшего построения сети, а потом получают, что SNMP от старой «такой же» по индексу индексу модели коммутатора не подходит к этим новым устройства. Что в новых новые же и баги, можно не говорить.
Что мешает брать для нового железа новый индекс — мне сложно понять. Маркетологи, вероятно!
Остается одно — покупать, внимательно читаю спецификацию для букв ревизии.
mickvav
Да, пора уже писать искуственный интеллект, который глядя на рекурсивный вывод snmpwalk-a и вооружившись какими-нибудь разумными эвристиками и google-fu раскладывает OID-ы по полочкам сам :)