Продолжаем тему прошлой заметки. Здесь пойдет речь об очевидных и не очень последствиях появления "конфликтующих" 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 проблема практически никогда не достигает серьезных масштабов
Самой очевидной проблемой, конечно же, будет отсутствие всех "пересекающихся" 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 проблема практически никогда не достигает серьезных масштабов
А сколько MAC -ов на коммутаторе должны быть для того чтобы это стало проблемой? У нас после сегментации и включения traffic_segmentation около 50 маков. Будет ли проблема заметна? Есть практичные цифры?
ОтветитьУдалитьНа 1228/ME/B1 при таком кол-ве маков проблем не будет. Коллизии будут, но исчезающе редко. Если ревизия A1 (чипсет как у 3028, если верить прошлой статье) то на 50 маков коллизии появляются уже относительно часто. Точные цифры приводились на nag.ru и я их сейчас не помню. Но надо понимать, что синтетические тесты могут не отражать реальное поведение, т.к. принцип работы функции хеширования неизвестен, а реальные мак-адреса имеют кое какие закономерности. Плюс не всегда все устройства интенсивно работают одновременно. В общем, ситуацию с 50 маков на 3028/1228/ME/A1 я бы описал как "жить можно". :)
ОтветитьУдалитьТут данные полнее и лучше структрурированы чем на НАг-е.Там я тоже читал, в том числе и твои комментарии.
ОтветитьУдалить