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

13

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

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

user209
источник
Какие проблемы вы видите из-за этого, кроме всплывающего предупреждения в журнале?
Шейн Мэдден
1
Вы можете посмотреть на туннелирование, если оно действительно вызывает у вас проблемы. Хотя у Aerohive нет контроллера, я думаю, что они поддерживают туннелирование GRE до указанной точки доступа, которая затем может отбрасывать трафик на локальную коммутацию. Это вызывает оперативную проблему?
Джоди Ботам
Вам помог какой-нибудь ответ? Если это так, вы должны принять ответ, чтобы вопрос не появлялся вечно, ища ответ. Кроме того, вы можете предоставить и принять свой собственный ответ.
Рон Мопин

Ответы:

16

Если ваши точки доступа просто подключают клиентов от беспроводной сети прямо к вашей проводной сети, то вы будете время от времени наблюдать это. Клиенты будут появляться из разных портов, поскольку они повторно связаны с другими точками доступа / ячейками в 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, которая определенно потребует некоторого исследования. :п

jof
источник
1
У меня сложилось впечатление, что это не нормальная вещь для переучивания. Если я подключу свою рабочую станцию ​​от одного к другому интернет-порту, я не получу macflap. Я полагаю, что это происходит, когда он меняется пару раз назад и вперед между портами ...
user209
9

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

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

Шейн Мэдден
источник
Я согласен. Случайные макфлапы не волнуют. Полностью отличается от изменения топологии STP.
Деннис Олвани,
5

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

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

vitisimus
источник
Это случается не очень часто ... Но я думал об очистке таблиц Mac: таблица Mac может быть очищена связующим деревом, потому что это может привести к тому, что macflap будет интерпретироваться как изменение топологии. Macflap происходит на соединительных линиях, потому что точки доступа подключаются на соединительных портах ... Если это так, то таблица mac очищается через домен l2 для этого vlan ...
user209