Mac-flap из-за роуминга клиентов по беспроводной сети

Мы работаем с беспроводной сетью Aerohove (без контроллера). Я иногда получаю mac-flaps в VLAN, привязанной к SSID. Я знаю, что это происходит из-за роумингового клиента. Проблема в том, что у компании, в которой я работаю, есть сквозные виртуальные сети (нет денег, чтобы поместить устройства L3 на уровень доступа), и я считаю, что эти mac-flaps вызывают mac-table быть сброшенным по всему домену L2 для этой VLAN ... что, в свою очередь, вызывает больше широковещательных сообщений и так далее.

Я знаю, что прекращение домена L2 на уровне доступа было бы лучшим решением, но в краткосрочной перспективе денег нет ... Есть мысли о том, как решить эту проблему?

Если ваши точки доступа просто подключают клиентов от беспроводной сети прямо к вашей проводной сети, то вы будете время от времени наблюдать это. Клиенты будут появляться из разных портов, поскольку они повторно связаны с другими точками доступа / ячейками в ESSID.

Я предполагаю, что вы говорите о Cisco IOS здесь, основываясь на термине «MACFLAP», который появляется в их сообщениях журнала, когда это происходит. Например: «% SW_MATM-4-MACFLAP_NOTIF: хост 0011.2233.4455 в vlan 123 колеблется между портом Gi1 / 1 и портом Gi1 / 2»

Это означает, что коммутатору приходится «переучивать» MAC-адрес Ethernet из порта, отличного от того, что кэшировано в таблице переадресации оборудования. Это занимает немного процессорного времени для каждого события, и если это происходит более пары раз подряд, это приведет к тому, что сообщение MACFLAP будет регистрироваться по мере того, как будет расходоваться все больше процессорного времени.

Однако это не должно приводить к очистке или очистке всей таблицы. Должны быть затронуты только записи для колеблющегося MAC-адреса источника.

Теперь, в вашем случае, если это нечастое сообщение, и это просто беспроводные клиенты, перемещающиеся с места на место, я бы не стал слишком беспокоиться об этом. Чтобы предотвратить это, потребуется некоторое централизованное завершение беспроводного клиента. Таким образом, кадры будут появляться в проводной VLAN в согласованном месте.

Однако, если это происходит часто для многих MAC-адресов, это может указывать на петлю Уровня 2, которая определенно потребует некоторого исследования. :п

События перехвата не требуют чередования входящего трафика между портами - простое изменение от входа MAC-адреса через порт A к порту B на коммутаторе достаточно быстро приведет к регистрации события перехвата; например, активная миграция виртуальной машины с одного хоста на другой часто вызывает уведомление о колебании MAC.

Как покрыли другие ответы, это ничего не будет беспокоиться о бы то ни было , пока события не намного чаще , чем то , что вы видите. Ваши опасения по поводу повторного сближения связующего дерева и очистки таблиц MAC необоснованны; это не изменение топологии для связующего дерева, и таблица просто обновляется для переброшенного MAC-адреса - другие записи на том же коммутаторе, том же VLAN или том же порту не затрагиваются.

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

Я не понимаю, почему таблица MAC будет проходить через домен L2 - ее контекст является локальным для коммутатора. Если вы присоединяете одну из точек доступа к другому коммутатору, вы должны перестать видеть уведомления macflap.