Klapa Mac ze względu na klientów mobilnych w sieci bezprzewodowej

Prowadzimy sieć bezprzewodową Aerohove (bez kontrolera). Czasami dostaję klapy mac w sieci VLAN powiązane z SSID. Wiem, że pochodzi to od klienta mobilnego. Problem polega na tym, że firma, dla której pracuję, ma od końca do końca vlany (brak pieniędzy na umieszczenie urządzeń L3 na warstwie dostępu) i uważam, że te klapy mac powodują tablicę mac zostać opróżnionym w całej domenie L2 dla tej sieci VLAN ... co z kolei powoduje więcej transmisji i tak dalej.

Wiem, że zamknięcie domeny L2 na warstwie dostępu byłoby najlepszym rozwiązaniem, ale w krótkim okresie nie ma pieniędzy ... Czy są jakieś przemyślenia na temat rozwiązania tego problemu?

Jeśli twoje punkty dostępowe po prostu łączą klientów z sieci bezprzewodowej bezpośrednio do sieci przewodowej, od czasu do czasu to zobaczysz. Klienci pojawią się z różnych portów, gdy ponownie skojarzą się z innymi AP / komórkami w ESSID.

Zakładam, że mówisz o Cisco IOS tutaj, na podstawie terminu „MACFLAP”, który pojawia się w ich komunikatach dziennika, gdy to nastąpi. Na przykład: „% SW_MATM-4-MACFLAP_NOTIF: Host 0011.2233.4455 w vlan 123 trzepocze między portem Gi1 / 1 a portem Gi1 / 2”

Oznacza to, że przełącznik musi „ponownie nauczyć się” adresu MAC Ethernet z innego portu niż ten, który jest zapisany w pamięci podręcznej w sprzętowej tabeli przekazywania. Zajmuje to trochę czasu procesora dla każdego zdarzenia, a wystąpienie go więcej niż kilka razy z rzędu spowoduje, że komunikat MACFLAP zostanie zalogowany, ponieważ zużywa się coraz więcej czasu procesora.

Nie powinno to jednak powodować, że cały stół zostanie opróżniony lub wyczyszczony. Wpływ powinny mieć tylko wpisy adresu źródłowego MAC trzepoczącego.

Teraz, w twoim przypadku, jeśli jest to rzadka wiadomość i po prostu klienci bezprzewodowi przemieszczają się z miejsca na miejsce, nie martwiłbym się tym zbytnio. Aby temu zapobiec, potrzebne byłoby pewne scentralizowane zakończenie klienta bezprzewodowego. W ten sposób ramki będą wyskakiwać na przewodowej sieci VLAN w spójnym miejscu.

Jeśli jednak zdarza się to często w przypadku wielu adresów MAC, może to wskazywać na pętlę warstwy 2, która z pewnością będzie wymagać zbadania. : p

Zdarzenia klapujące nie wymagają ruchu przychodzącego naprzemiennie między portami - prosta zmiana z wejścia adresu MAC portu A na port B przełącznika wystarczająco szybko spowoduje zarejestrowanie zdarzenia klapowania; na przykład migracja na żywo maszyny wirtualnej z jednego hosta na drugi często powoduje powiadomienie MAC flap.

Jak ujęły inne odpowiedzi, nie ma się czym martwić, dopóki wydarzenia nie będą znacznie częstsze niż to, co widzisz. Twoje obawy dotyczące ponownej konwergencji drzewa opinającego i opróżniania tabel MAC są bezpodstawne; nie jest to zmiana topologii dla drzewa opinającego, a tabela jest właśnie aktualizowana dla adresu MAC, który mignął - inne wpisy na tym samym przełączniku, tym samym vlan lub tym samym porcie pozostają niezmienione.

O ile nie otrzymujesz wielu powiadomień Macflap, nie martwiłbym się. Wygląda na to, że klient mobilny tymczasowo komunikuje się z dwoma punktami dostępowymi (podłączonymi do tego samego przełącznika), gdy jest on przekazywany z jednego do drugiego. Macflapy występują, ponieważ przełącznik widzi ruch z tego samego MAC na dwóch interfejsach jednocześnie. Spodziewałbym się, że macflapy zatrzymają się po zakończeniu przekazywania. Zwykłym problemem związanym z macflaps jest to, że nie przestawają - szaleństwo związane z ciągłą aktualizacją tabeli MAC wiele razy na sekundę może poważnie uszkodzić sprzęt przełącznika ($ WORK raz dosłownie stopił w ten sposób kartę nadzorczą 6500).

Nie rozumiem, dlaczego tabela MAC miałaby opróżniać domenę L2 - jej kontekst jest lokalny dla przełącznika. Jeśli podłączysz jeden z AP do innego przełącznika, powinieneś przestać widzieć powiadomienia macflap.