RDC писал(а):
При схеме vlan-на-абонента, пересечения маков ни на что не влияют.
Не совсем так. Всё зависит от первоначально проекта сети. У меня много коммутаторов 3028/52 и с проблемой по пересечению я знаком.
Доп. услуги при QinQ в виде VoIP, MVR, STB + Managment и вот уже начинаются проблемы с пересечениями.
10 коммутаторов в кольце - это максимум 500 клиентов это 500 маков клиента + 500 маков шлюза, + 2,5к служебных мультикаст маков если их не резать (по 5 на клиента) + 200-300 на VoIP, MVR, STB + Managment.
Причём служебные мультикаст маки тоже являются "софтово приоритетными" и при пересечении маков не могут выбить реально действующий мак канала.
Замена технологии QinQ на Opt.82 снижает кол-во пересечений примерно в 6 раз.
Вот часть информации которая проясняет ситуацию с пересечениями.
----------------------------------------------------------------------------------
Описание пересечения хэшей.
http://xcme.blogspot.ru/2014/11/mac.htmlhttp://xcme.blogspot.ru/2014/11/hash.htmlвоскресенье, 9 ноября 2014 г.
Проблема "конфликт hash" на сетевых коммутаторах
Под конфликтом hash подразумевается такая ситуация, когда из-за организации внутренней логики коммутатора некоторые MAC-адреса считаются равными друг другу. В результате такой "ошибки" в таблицу коммутации попадает только первый MAC, а кадры, предназначенные конфликтующим MAC, разлетаются по всей сети. В постсовестких интернетах расцветом этой проблемы можно считать 2009-2010 года. Вот интересная ветка на НАГ'е, где можно почитать первые возгласы возмущения. Но некоторым сетевым администраторам проблема уже была известна. На том же НАГ'е есть статья, которая содержит технические подробности и настоятельно рекомендуется к прочтению*. А в этой заметке я попытаюсь понятно изложить природу явления для тех, кто еще не сталкивался с описанной ситуацией.
Причина "конфликта"
В памяти коммутатора MAC-адреса не хранятся как таковые. Хранятся лишь некоторые значения hash-функции, вычисленные на основе MAC и VLAN. Выглядит это примерно так: val1=hashfunc(mac1+vlan1). Другая запись для другой пары mac2 и vlan2 будет, соответственно, val2=hashfunc(mac2+vlan2). При этом для хранения подобных значений память выделяется в условиях строжайшей экономии. Грубо говоря, уникальность каждой записи реализована с некоторыми допущениями. Поэтому вероятность того, что val2 будет равно val1 существенно отличается от нуля. Если такое происходит, то mac2 считается равным mac1. Из всех таких MAC-адресов коммутатором будет изучен только первый, т.к. отличий между ними коммутатор не видит.
Проблемные модели
Из модельного ряда D-Link модели в порядке убывания вероятности конфликта можно расположить так:
DES-3028 (чипсет BCM 5347), DES-1228/ME/A1 (чипсет BCM 5347, аппаратный аналог 3028)
DES-3200-28/A1/B1 (чипсет BCM 53262), DES-1228/ME/B1 (чипсет BCM 53262), DES-1210-28/ME/B2 (чипсет BCM 53262)
DES-3528, DES-3526
DES-3200-28/C1
Возможно, стоило бы поместить серию 35xx и 3200-28/C1 в один ряд, но точных цифр у меня нет, потому пусть будет так.
Комментарии D-Link
1. Чипсеты всех современных моделей подвержены данным проблемам. Поскольку основных производителей всего два: Broadcom и Marvell, то у многих вендоров наблюдается данная проблема в той или иной степени на разных сериях коммутаторов. Старые чипсеты имели 2-х уровневый хеш, а не одноуровневый как новые, поэтому на них практически отсутствует
данная проблема, что и показывают тесты. Производители чипсетов увеличили скорость работы FDB таблицы, но как побочный эффект получили проблему с хешами. Также многое зависит от того, как реализованная память под FDB таблицу и сколько бит отпущено под одну хеш запись.
2. Наличие проблемы хэширования вовсе не говорит о том, что данная модель плохая! Каждая модель коммутатора имеет свою маркетинговую нишу и предполагает ее правильно использование. Например модели DES-3028 и DES- 3200 в большей степени рассчитаны на использование с операторской моделью QinQ. Модель DES-3528 расчитана на корпоративный сегмент, где цена оборудования имеет меньше значения нежели требуемый функционал. Модель DES-1210-xx рассчитана на использование с операторской моделью без QinQ.
3. Как видно из проведенных тестов у модели DES-3028 самая низкая устойчивость хэш функции к длинным последовательностям (самый большой процент коллизий), поэтому при использовании данной конкретной модели мы рекомендовали их (длинные последовательности) избегать. В других моделях данная проблема отсутствует.
В принципе, все так. На DES-3028 проблема выражена остро, на DES-3200-28/A1/B1 - постольку-поскольку, а на остальных моделях (из перечисленных) может быть замечена только при явно ошибочном проектировании сети.
Обнаружение проблемы
а) Устройство в сети доступно, MAC-адрес корректный (см. бит для групповой рассылки), но на порту не обнаруживается.
б) При помощи специального функционала enable flood_fdb. Коммутатор начнет следить за MAC-адресами и вести в памяти копию (т.е. этот функционал - исключительно мониторинг) конфликтов. Посмотреть табличку конфликтов можно командой show flood_fdb
Value VLAN ID MAC Address Time Stamp
------ ------- ------------------- ----------
3865 24 00-22-B0-04-6A-17 * 9978796
3865 1511 00-1A-79-11-85-E4 9978796
Одинаковое value указывает на конфликт. Звездочка говорит о том, что MAC-адрес присутствует в таблице коммутации. Таким образом, "проблемным" в данном примере является MAC 00-1A-79-11-85-E4.
В DES-3200-28/C1 такого механизма нет, т.к. считается, что данная модель не подвержена проблеме "конфликт hash".
В следующей заметке продолжим разговор о данной проблеме. Там я опишу очевидные и не очень последствия, с которыми можно столкнуться на практике.
* В статье упоминается серия коммутаторов DES-32xx. Судя по дате написания статьи, речь идет о моделях типа DES-3226, а не о серии DES-3200.
Последствия конфликта MAC-адресов
Продолжаем тему прошлой заметки. Здесь пойдет речь об очевидных и не очень последствиях появления "конфликтующих" MAC-адресов.
Самой очевидной проблемой, конечно же, будет отсутствие всех "пересекающихся" MAC-адресов в таблице коммутации. При получении кадра, адресованного такому MAC'у, коммутатор не сможет определить порт назначения (Destination Lookup Failure, DLF) и кадр будет отправлен во все порты, являющиеся участниками данного VLAN, кроме того, откуда данный кадр был получен. Тем самым коммутатор (свитч) превращается в концентратор (хаб), т.е. не справляется со своей основной задачей - коммутацией трафика. Чем больше пересекающихся MAC-адресов в сети, тем больше лишнего трафика по ней перемещается. Часть кадров при этом может теряться и конечный потребитель не получает небходимой "скорости".
Как решение здесь напрашивается сегментация сети на VLAN'ы меньшего размера, вплоть до vlan-per-user. Широковещательный домен при этом уменьшится, количество передаваемого по сети мусора тоже. В случае vlan-per-user проблема, казалось бы, устраняется полностью. Но не все так просто.
Есть еще два VLAN, которые не могут быть уменьшены слишком уж сильно. Это управляющий (management) и мультикаст (mvr) вланы. Поскольку конфликты запросто происходят между разными влан, то пересечение с абонентским MAC может вызвать "замусоривание" управляющего влана либо ухудшение работы IPTV*.
Следующая проблема - сам механизм обнаружения таких конфликтов (enable flood_fdb), где производятся вычисления, аналогичные тем, что выполняются в ASIC. То есть это не извлечение проблемного адреса из недр памяти, а вычисление, проводящееся параллельно работе чипа. Только в этом случае расходуются уже ресурсы CPU. Отсюда следует, что большой поток трафика может привести к ненужной нагрузке на CPU. На практике, к сожалению, так и получается. В модели DES-3028 CPU уходит в 100% загрузку и устройство становится недоступным. При том, если коммутатор выступает в роли релей-агента, то абоненты перестают получать адреса от DHCP. На DES-3200-28/A1/B1 ситуация несколько отличается - коммутатор с некоторой вероятностью не может ответить на ARP-запрос. Когда время жизни arp на маршрутизаторе истекает, коммутатор на некоторое время становится недоступен. Результатом будет "моргающая" карта сети.
Комментарий D-Link:
Ситуация вызвана тем, что flood_fdb (как и обсуждалось ранее) - софтовый функционал. Исправить это нет никакой возможности, рекомендация - использовать flood_fdb только для анализа проблемных ситуаций и не держать его включенным повсеместно на сети.
Загрузка cpu будет напрямую зависеть от количества, типа трафика и пр, но каких-то конкретных значений pps сказать не представляется возможным.
Таким образом, использовать flood_fdb можно только в не нагруженных сетях без мультикаста.
Еще одна проблема, предположительно связанная с "конфликтом hash" - глюки дополнительного функционала коммутаторов. Например, IP-MAC-Port Binding в режиме DHCP Snooping блокирует кадры от абонента несмотря на наличие валидной связки в своей таблице.
Ну и последнее - затруднительная диагностика проблем абонентов из-за отсутствующих на порту MAC'а адресов. То есть сразу не понятно, имеем ли мы конфликт hash или же просто что-то не так включено у самого абонента. При этом, как мы помним, flood_fdb выключен, т.к. его включение чревато потерей доступа.
Вывод: Конфликтующие MAC-адреса, помимо явной проблемы с коммутацией трафика рано или поздно приведут к труднодиагностируемым побочным проблемам. Единственный правильный выход из ситуации - физически сегментировать сеть, тем самым уменьшая общее количество MAC-адресов на проблемных устройствах**.
Меры, помогающие снизить ущерб:
1. Уменьшение размеров абонентских VLAN.
2. Уменьшение размера управляющего VLAN.
3. Отказ от использования MVR (мультикаст вещается в абонентском VLAN или не вещается вовсе).
4. Отключение изучения MAC-адресов на коммутаторах, включение сегментации трафика, когда абонент может передать кадр только в аплинк, использование auto_fdb (если позволяют свободные ресурсы коммутатора).
5. Установка проблемных коммутаторов** в конец цепочки.
6. Отказ от использования функционала IMP
Эти меры помогут выиграть время для грамотного перепланирования сети.
* Мультикаст вещается на специальные адреса для групповой рассылки, которые обрабатываются коммутатором несколько иначе, чем обычные адреса, но пересечения MAC все равно могут приводить к описанной проблеме.
** Все вышенаписанное применимо, прежде всего, к DES-3028 и DES-1228/ME/A1. На DES-3200 проблема практически никогда не достигает серьезных масштабов
Вход
Регистрация
FAQ
Поиск
