Mac-клапоть завдяки роумінгу клієнтів по бездротовій мережі

У нас працює бездротова мережа Aerohove (без контролерів). Іноді я отримую Mac-клавіші в межах VLAN, прив'язані до SSID. Я знаю, що це походить від роумінгового клієнта. Проблема полягає в тому, що компанія, над якою я працюю, закінчилася з вланами (немає грошей, щоб розмістити пристрої L3 на рівні доступу), і я вважаю, що ці мак-клапти викликають mac-таблицю щоб розмиватися по всьому домену L2 для цієї VLAN ... що, в свою чергу, спричиняє більше трансляцій тощо.

Я знаю, що припинення домену L2 на рівні доступу було б найкращим рішенням, але грошей на короткий термін немає ... Будь-які думки, як вирішити цю проблему?

Якщо ваші AP-адреси просто з'єднують клієнтів з бездротової мережі прямо на вашу провідну мережу, то ви час від часу будете бачити це. Клієнти з'являться з різних портів, коли вони повторно асоціюються з іншими AP / клітинками 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 є безпідставними; це не зміна топології для дерева, що охоплює, і таблиця просто оновлюється для МАС-адреси, яка розгорнулася - інші записи на цьому ж комутаторі, той же vlan або той же порт не впливають.

Якщо ви не отримуєте багато сповіщень про macflap, я б не хвилювався. Здається, що клієнт роумінгу тимчасово спілкується з двома AP-адресами (які підключені до одного комутатора), коли він передається від одного до іншого. Макфлапи трапляються, тому що комутатор бачить трафік з одного МАС на двох інтерфейсах одночасно. Я б очікував, що макфлапи припиняться після завершення передачі. Звичайна турбота про macflaps - це коли вони не зупиняються - тремтіння від постійного оновлення таблиці MAC кілька разів на секунду може серйозно пошкодити обладнання обладнання комутатора ($ WORK один раз буквально розтопив 6500 контрольну карту таким чином).

Я не бачу, чому таблиця MAC пролітає через домен L2 - її контекст є локальним для комутатора. Якщо ви приєднаєте один з AP до іншого перемикача, вам слід припинити бачити сповіщення macflap.