Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Часто возникает на недорогих чипах, когда длина хэша не очень большая.
Причем насколько помню для того же DES3028 ограничение чисто железное, софтом оно никак не исправляется.
На практике сталкивался с коллизиями на DES3028, сейчас перешли на EdgeCore, вроде там таких проблем явно не заметно.
Но надо будет потестить.
Причем насколько помню для того же DES3028 ограничение чисто железное, софтом оно никак не исправляется.
На практике сталкивался с коллизиями на DES3028, сейчас перешли на EdgeCore, вроде там таких проблем явно не заметно.
Но надо будет потестить.
Да, в моем случае это был длинк, не знаю точно модель.
Для меня во всей данной истории принципиально было понять, как же это работает. Два принципиально разных подхода. Или хранится именно хеш вместо мак-а (как иногда пишут, на nag-е в том числе), тогда не будет широковещания при коллизии, или хеш используется просто как индекс для таблицы, а в таблице хранится мак и порт, тогда механизм необучаемости и широковещания понятен.
Кстати, вроде некоторые производители делают отдельную небольшую CAM именно для коллизионных мак-ов.
В более ранней статье на nag-е писали, что вообще от мак-а откусывают N-ое число разрядов и используют как индекс для массива, где хранят уже порт. Но это совсем жесть. Карточки одного производителя из одной партии тут вообще-бы доставляли.
Кстати, вроде некоторые производители делают отдельную небольшую CAM именно для коллизионных мак-ов.
В более ранней статье на nag-е писали, что вообще от мак-а откусывают N-ое число разрядов и используют как индекс для массива, где хранят уже порт. Но это совсем жесть. Карточки одного производителя из одной партии тут вообще-бы доставляли.
Хэш обычно считается как функция от мак, порт, влан.
Т.е. допустим мак+порт+влан имеют длину допустим 64бита.
А хэшфункция из них делает 48бит или меньше даже, за счет этого таблица форвардинга меньше но при поиске по ней два порта(точнее тройки мак, порт, влан) могут иметь одинаковый хэш и тогда возможны варианты, например флуд во все порты или зеркалирование трафика по двум портам у которых совпал хэш.
Т.е. допустим мак+порт+влан имеют длину допустим 64бита.
А хэшфункция из них делает 48бит или меньше даже, за счет этого таблица форвардинга меньше но при поиске по ней два порта(точнее тройки мак, порт, влан) могут иметь одинаковый хэш и тогда возможны варианты, например флуд во все порты или зеркалирование трафика по двум портам у которых совпал хэш.
Это понятно, что функция. Ее результат можно по разному использовать. Хранить непосредственно в памяти, или саму использовать как адрес в какой-то структуре данных в памяти. Не торопитесь отвечать, подумайте над последствиями того и другого подхода. Могу еще только добавить, что даже слабый хеш необратим и при первом подходе мы не будем знать, из какого мак-а это родилось. Как мы тогда поймем что это коллизия и будем/или не будем обучаться? Максимум мы обновим запись. При втором подходе мак в чистом виде не исчезает, хеш нужен только для скорости поиска и коллизию мы детектируем.
Коменты раз в 5 минут оставляют время на подумать.
Этот вопрос я изучал гдето год назад, некоторые вещи мог не правильно понять.
Но я себе представляю это так.
Приходит пакет.
Железка считает для него хэш и проверяет есть ли он в таблице форвардинга.
Если его нету, то она добавляет туда хэш, мак, порт, влан.
Приходит пакет с другого порта но хэш получается таким же.
Дальше все зависит от вендора — он может как перезаписать запись в таблице так и не трогать ее.
Получается что мак с другого порта может быть не выучен и соответственно он может как отбросить пакет, так и послать флудом на все порты.
В итоге получается что хотели сэкономить в памяти на железе (очевидно что хранить 8к записей по 8 байт дороже чем по 8к записей по 6байт). Ну и плюс операции поиска по идее должны быть быстрее на меньших объемах данных.
Этот вопрос я изучал гдето год назад, некоторые вещи мог не правильно понять.
Но я себе представляю это так.
Приходит пакет.
Железка считает для него хэш и проверяет есть ли он в таблице форвардинга.
Если его нету, то она добавляет туда хэш, мак, порт, влан.
Приходит пакет с другого порта но хэш получается таким же.
Дальше все зависит от вендора — он может как перезаписать запись в таблице так и не трогать ее.
Получается что мак с другого порта может быть не выучен и соответственно он может как отбросить пакет, так и послать флудом на все порты.
В итоге получается что хотели сэкономить в памяти на железе (очевидно что хранить 8к записей по 8 байт дороже чем по 8к записей по 6байт). Ну и плюс операции поиска по идее должны быть быстрее на меньших объемах данных.
Пара замечаний. Как железка по вашей схеме ищет этот хеш? Прямым перебором? Быстрыми методами поиска? Это все равно долго. По цисковской картинке не так. Мы сворачиваем мак в хеш. Хеш мы используем как смещение относительно какого-то базового адреса, с которого у нас начинается наша лукап таблица. Хеша нет в прямом виде в таблице форвардинга, это фактически адрес, по которому мы запишем мак и порт.
Далее, по вашей схеме флуда на все порты не получится. Никогда. Да, хеш получился таким же. Но так как в вашей схеме нет места чистому мак-у, с чего железка будет считать эту ситуацию какой-то особенной? Мы не знаем, из какого мак-а мы получили предыдущий хеш, который уже есть в таблице, может сейчас это тот же самый мак,? Узнать это невозможно, другой он или тот же самый. Порт другой? Без включенного портсекьюрити это штатная ситуация.
Далее, по вашей схеме флуда на все порты не получится. Никогда. Да, хеш получился таким же. Но так как в вашей схеме нет места чистому мак-у, с чего железка будет считать эту ситуацию какой-то особенной? Мы не знаем, из какого мак-а мы получили предыдущий хеш, который уже есть в таблице, может сейчас это тот же самый мак,? Узнать это невозможно, другой он или тот же самый. Порт другой? Без включенного портсекьюрити это штатная ситуация.
Далее, почему не будет флуда. Пришел пакет, у которого дст мак — неправильный, коллизионный. Ну и что. Сворачиваем его в хеш, хеш в таблице есть, по соотв. порту пакет и продвинут. Но порт может быть не тот, т.к. хеш тот же, но его источник — другой мак. Результат — пакет ушел, допустим, ко мне. Но никак не на все порты. Настоящий получатель его не получил, а получил другой. Это если и флуд, то этакий юникастовый. В моем реальном случае пакеты получал и я, и сосед.
Насчет флуда. Если dst mac нету в FDB, то обычное поведение это отправить пакет на все порты чтобы начать процесс обучения. А так как по каким либо причинам он не может его обучить то во все порты (поднятые) постоянно льется трафик.
Не такая ли у вас ситуация получилась?
Не такая ли у вас ситуация получилась?
На все порты мы отправляем, что бы доставить пакет. На все — потому что не знаем на какой конкретно. Это стандартное поведение.
Если будет ответный трафик и ничто не помешает обучению, ответный трафик от этого dst mac (он уже превратится в src) обучит свич, пополнит таблицу — далее трафик для этого мака будет идти адресно, только на нужный порт. Если обучение не происходит, трафик для этого мак-а всегда будет идти на все порты. Как у хаба. Это грузит сеть, создавая паразитный трафик, создает ситуацию, когда без всяких злобных поползновений кто-то получит возможность перлюстрировать чужой трафик.
Почему не получается обучить. «Неудачный» мак свертывается в хеш, хеш используется для адресации в лукап таблицу. Там уже обретается мак и порт, причем мак другой. Обучение не происходит. Даже если бы оно происходило, в «неправильный» мак превращался бы тот, что уже есть в таблице, вытесненный оттуда.
Так или иначе, один мак остается «за бортом» лукап таблицы, и трафик на такой мак будет форвардится на все порты (ну ессно кроме того, откуда он приходит, это как самоочевидное умалчиваем).
Если будет ответный трафик и ничто не помешает обучению, ответный трафик от этого dst mac (он уже превратится в src) обучит свич, пополнит таблицу — далее трафик для этого мака будет идти адресно, только на нужный порт. Если обучение не происходит, трафик для этого мак-а всегда будет идти на все порты. Как у хаба. Это грузит сеть, создавая паразитный трафик, создает ситуацию, когда без всяких злобных поползновений кто-то получит возможность перлюстрировать чужой трафик.
Почему не получается обучить. «Неудачный» мак свертывается в хеш, хеш используется для адресации в лукап таблицу. Там уже обретается мак и порт, причем мак другой. Обучение не происходит. Даже если бы оно происходило, в «неправильный» мак превращался бы тот, что уже есть в таблице, вытесненный оттуда.
Так или иначе, один мак остается «за бортом» лукап таблицы, и трафик на такой мак будет форвардится на все порты (ну ессно кроме того, откуда он приходит, это как самоочевидное умалчиваем).
На той фишке, что не происходит обучение свича, работают некоторые виды кластеров. Когда идет арп запрос для резолвинга виртуального кластерного ип в мак, сервера отвечают арп ответом, в котором мак езернет кадра не совпадает с мак-ом в арп ответе. Свич обучается, ессно, срц маку из езернет кадра. Трафик же на виртуальный ип идет на левый мак, который был в арп ответе. Т. к. этому маку свич не обучен, трафик доставляется на все порты и все ноды кластера его видят и могут обработать. Узнал это в свое время не из теории, а из практики, когда виндовые админы не объяснив фишки подняли такую вещь и зафлудили сегмент. Лечится или выделением в отдельный влан, или статической привязкой левого мак-а виртуального ип к портам нод. Второй способ не везде прокатывает. АТ-свич у меня не захотел такой мак в фдб принимать ни под каким предлогом — инвалид и точка. А циска прожевала.
Да, у 3028 есть такое.
Рецепт лечения его прост — VLAN на дом плюс DHCP Snooping (тупо отключаем Learning того, что не надо).
Рецепт лечения его прост — VLAN на дом плюс DHCP Snooping (тупо отключаем Learning того, что не надо).
Да, там только «идейно» решать, разрубая сеть на VLAN-ы с возможно меньшим количеством юзеров в каждом.
Самое неприятное, что DLink, признав проблему, сделал каменное лицо, и не то что замену, но и в общем извинений на сайте особо не принес. На фоне того, что их железо постепенно дорожает от модели к модели год за годом, поневоле задумаешься, помнить ли про них при построении проектов…
Самое неприятное, что DLink, признав проблему, сделал каменное лицо, и не то что замену, но и в общем извинений на сайте особо не принес. На фоне того, что их железо постепенно дорожает от модели к модели год за годом, поневоле задумаешься, помнить ли про них при построении проектов…
Разговор с админом провайдера (весьма опытным и грамотным товарищем) прояснил ситуацию. Это было как раз оно самое — коллизия хэш-функции MAC-адреса.
Поделитесь секретом: как вы вообще не него вышли?
Ух, какой хардкорный топик :)
Это вам не 201й по счету мануал по настройке ACL на Cisco.
Спасибо что подразмяли мой заржавевший мозг.
Таблица FDB вообще сверхъестественная вещь в некоторых коммутаторах.
Года 3 назад, при сертификации в Беларуси коммутаторов Extreme Networks, я столкнулся с ситуацией, когда записи FDB вообще не устаревали за отведенные по умолчанию 300 секунд. Часть устаревала и удалялась. Остальные записи просто оставались в таблице еще некоторое время. Видимо, индусы код писали :)
Это вам не 201й по счету мануал по настройке ACL на Cisco.
Спасибо что подразмяли мой заржавевший мозг.
Таблица FDB вообще сверхъестественная вещь в некоторых коммутаторах.
Года 3 назад, при сертификации в Беларуси коммутаторов Extreme Networks, я столкнулся с ситуацией, когда записи FDB вообще не устаревали за отведенные по умолчанию 300 секунд. Часть устаревала и удалялась. Остальные записи просто оставались в таблице еще некоторое время. Видимо, индусы код писали :)
раз.
---Как известно, если свич работает в режиме Store and forward, он обучается SRC MAC и в дальнейшем трафик для данных MAC будет форвардиться только через нужные порты.
Это не зависит от режима
В стор-энд-форвард весь фрейм бросается в буфер, и с него считывается си-эр-си для идентификации ошибок
В кат-сру после синхро-последовательности считывается дест-мак, и в соответствии с ним, если этот мак уже есть в мак-таблице, фрейм бросается в выходной буффер.
два.
коллизии, наблюдаются только на коммутаторах нижней ценовой линейки, там нету настоящего TCAM. для с2960 это не свойственно, у них ТСАМ и в этих свитчах. но в ISP-сетях их не много.
три.
иногда, если генерить маки последовательно, т.е. 000000000000-000000000001-000000000002-… — проблема отсутствует. так что, всегда в тестере выбирайте рандомные сорс-маки.
четыре.
едж-кор на некоторых коммутаторах задевелопил комманду, которая показывает коллизии, которые сейчас есть в мак-таблице.
---Как известно, если свич работает в режиме Store and forward, он обучается SRC MAC и в дальнейшем трафик для данных MAC будет форвардиться только через нужные порты.
Это не зависит от режима
В стор-энд-форвард весь фрейм бросается в буфер, и с него считывается си-эр-си для идентификации ошибок
В кат-сру после синхро-последовательности считывается дест-мак, и в соответствии с ним, если этот мак уже есть в мак-таблице, фрейм бросается в выходной буффер.
два.
коллизии, наблюдаются только на коммутаторах нижней ценовой линейки, там нету настоящего TCAM. для с2960 это не свойственно, у них ТСАМ и в этих свитчах. но в ISP-сетях их не много.
три.
иногда, если генерить маки последовательно, т.е. 000000000000-000000000001-000000000002-… — проблема отсутствует. так что, всегда в тестере выбирайте рандомные сорс-маки.
четыре.
едж-кор на некоторых коммутаторах задевелопил комманду, которая показывает коллизии, которые сейчас есть в мак-таблице.
По раз.
В целом соглашусь, вводящая в заблуждение фраза. Но у вас, имхо, неполное объяснение. Если Cut-Through считывает только дст-мак, то откуда появится леарнинг? Но он таки действительно есть, зря я это.
Циско вещает
"in theory, a cut-through switch receives and examines only the first 6 bytes of a frame, which carries the DMAC address. However, for a number of reasons, as will be shown in this document; cut-through switches wait until a few more bytes of the frame have been evaluated before they decide whether to forward or drop the packet."
и
«With today's MAC controllers, ASICs, and ternary content addressable memory (TCAM), a cut-through switch can quickly decide whether it needs to examine a larger portion of the packet headers. It can parse past the first 14 bytes (the SMAC, DMAC, and EtherType) and handle, for example, 40 additional bytes in order to perform more sophisticated functions relative to IPv4 Layer 3 and 4 headers.»
По два — логично и практика подтвердила.
По три — выбирались рандомные. Причем сначала из под винды софтиной арпфлуд. Результат был отрицательный, она часто генерила некорректные маки, на которые в консоли во время теста вылетала ругань. В итоге заюзал скапи, маки были рандомные юникасты, по ходу генерации и флуда они сохранялись в файл, файл потом сравнивался с выгруженной таблицей свича за минусом собственных мак-ов девайса (CPU)
Спасибо за коммент.
В целом соглашусь, вводящая в заблуждение фраза. Но у вас, имхо, неполное объяснение. Если Cut-Through считывает только дст-мак, то откуда появится леарнинг? Но он таки действительно есть, зря я это.
Циско вещает
"in theory, a cut-through switch receives and examines only the first 6 bytes of a frame, which carries the DMAC address. However, for a number of reasons, as will be shown in this document; cut-through switches wait until a few more bytes of the frame have been evaluated before they decide whether to forward or drop the packet."
и
«With today's MAC controllers, ASICs, and ternary content addressable memory (TCAM), a cut-through switch can quickly decide whether it needs to examine a larger portion of the packet headers. It can parse past the first 14 bytes (the SMAC, DMAC, and EtherType) and handle, for example, 40 additional bytes in order to perform more sophisticated functions relative to IPv4 Layer 3 and 4 headers.»
По два — логично и практика подтвердила.
По три — выбирались рандомные. Причем сначала из под винды софтиной арпфлуд. Результат был отрицательный, она часто генерила некорректные маки, на которые в консоли во время теста вылетала ругань. В итоге заюзал скапи, маки были рандомные юникасты, по ходу генерации и флуда они сохранялись в файл, файл потом сравнивался с выгруженной таблицей свича за минусом собственных мак-ов девайса (CPU)
Спасибо за коммент.
У длинков со слабым хешем тоже есть возможность увидеть, какие маки коллизят и кто из них попал в fdb, а кто нет. Сделано это на последних прошивках, там же появился костыль, который гарантирует попадание в fdb мультикаст мака, если с таким возникла коллизия.
P.S. теперь представьте себе, если на таком «неустойчивом» коммутаторе к коллизиям коллизия произойдет с мак-адресом шлюза, а не клиентским
P.S. теперь представьте себе, если на таком «неустойчивом» коммутаторе к коллизиям коллизия произойдет с мак-адресом шлюза, а не клиентским
Старо как мир) Пример тестирования. Наверное все таки сама тема возникает потому, что ставят не то и не туда… иначе вероятность сколько нибудь серьёзных последствий мало вероятна. Например доступ предполагает 1 порт один мак, какай уж там коллизия. Другое дело если это скажем DES-3200-28F который оптический, но как сказали в сапорте все таки доступ :)
Я в свитчинге, как свинья в апельсинах. Прочитал статью с комментариями (кстати спасибо автору, просветил).
Но у меня возникло недопонимание вот на какой предмет:
Если коммутатор хранит в FDB хеши, ну или как циска реальные данные но ищет по хешу, и при этом хеш считается из MAC+VLAN+Port, то как коммутатор, получая пакет вычисляет этот самый хеш получателя для поиска по FDB, если он наперед не знает номер порта? Сам мак и влан очевидно известны, но номер порта-то нет, собственно задачей коммутатора и является определить тот самый порт назначения, в который и почешет кадр. То есть либо я не так понял комментарии и порт в хеше не участвует, и тогда все нормально, просто я еще не проснулся, либо я что-то пропустил в этой жизни.
У меня тоже похожая ситуация (с коммутатором D-Link DES-1228 кажется), тогда я просто забил, т.к. это всего навсего мой телефон по Wi-Fi не включался в корп сеть (ну то есть к Wi-Fi он подключался, но данные не бегали), но теперь кажется понял в чем была суть проблемы.
Но у меня возникло недопонимание вот на какой предмет:
Если коммутатор хранит в FDB хеши, ну или как циска реальные данные но ищет по хешу, и при этом хеш считается из MAC+VLAN+Port, то как коммутатор, получая пакет вычисляет этот самый хеш получателя для поиска по FDB, если он наперед не знает номер порта? Сам мак и влан очевидно известны, но номер порта-то нет, собственно задачей коммутатора и является определить тот самый порт назначения, в который и почешет кадр. То есть либо я не так понял комментарии и порт в хеше не участвует, и тогда все нормально, просто я еще не проснулся, либо я что-то пропустил в этой жизни.
У меня тоже похожая ситуация (с коммутатором D-Link DES-1228 кажется), тогда я просто забил, т.к. это всего навсего мой телефон по Wi-Fi не включался в корп сеть (ну то есть к Wi-Fi он подключался, но данные не бегали), но теперь кажется понял в чем была суть проблемы.
По всей видимости и совершенно очевидно никак, если порт в вашей формуле — это дст порт, а значит формула неправильная. В статье с нага:
«Ну а полный L2 Flow Specifications содержит Source MAC, Destination MAC, Vlan ID, Source Port — 48 + 48 + 12 + 5 = 113 бит. IP Flow Specifications — еще 114 бит, а с подсетями — плюс 85 бит. Т.е. мягко говоря есть куда совершенствоваться в плане управления передачей данных. „
«Ну а полный L2 Flow Specifications содержит Source MAC, Destination MAC, Vlan ID, Source Port — 48 + 48 + 12 + 5 = 113 бит. IP Flow Specifications — еще 114 бит, а с подсетями — плюс 85 бит. Т.е. мягко говоря есть куда совершенствоваться в плане управления передачей данных. „
Действительно очевидно, что поиск получателя никак не может осуществляться на основе хеша в котором фигурирует его порт (собственно это меня и смутило), но прочитав еще раз, я понял что этого ввиду и не имелось, просто мозг как-то не правильно сложил данные и сформировал ошибочное понимание.
Ну, если подумать, то и то, что длинк хранит хеш в памяти и решение о форвардинге по нему принмает — тоже сомнительно. Не получается тогда широковещательного эффекта. Можно конечно придумать такой алгоритм, что оно получится (увидели совпадение хешей и новый не запомнили и старый удалили), но тогда получается, что если вы хост из порта в порт переключите — все, труба. Хеш тот же, порт другой. Хеш необратим, мы не можем понять, из того же он мак-а получился или из другого. Опять же мак не только в алгоритме форвардинга важен, ацл-и, разные примочки, в конце концов show нужное_подставить показывает таблицу мак-ов, а не хешей, значит в той или иной области памяти они хранятся как есть, не свернутые. Что это за экономия, когда сущности удваиваются?
Если бы этого не было, вы бы их не увидели, а это практически любое управляемое показывает.
Если бы этого не было, вы бы их не увидели, а это практически любое управляемое показывает.
Хеши там, видимо, для поиска все таки, хотя все равно сомнительно, на столько ли выигрыш большой, особенно если учесть тот факт, что сам хеш еще и посчитать нужно.
Считаются аппаратно, а не ЦПУ общего назначения. В этом и проблема, что нельзя эту слабую хеш-функцию поправить патчем, новой прошивкой. Это функционал ASIC.
www.nag.ru/articles/reviews/15583/asic-kak-mnogo-v-etom-zvuke.html
www.nag.ru/articles/reviews/15583/asic-kak-mnogo-v-etom-zvuke.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Коллизия хэш-функции MAC-адреса