Mac-flap debido a clientes móviles en la red inalámbrica

Estamos ejecutando una red inalámbrica Aerohove (sin controlador). De vez en cuando recibo mac-flaps dentro de la VLAN vinculada a un SSID. Sé que esto proviene de un cliente de roaming. El problema es que la compañía para la que trabajo tiene vlans de extremo a extremo (no hay dinero para poner dispositivos L3 en la capa de acceso) y creo que estas mac-flaps causan la mac-table enjuagarse en todo el dominio L2 para esa VLAN ... lo que a su vez provoca más transmisiones, etc.

Sé que terminar el dominio L2 en la capa de acceso sería la mejor solución, pero no hay dinero a corto plazo ... ¿Alguna idea sobre cómo lidiar con este problema?

Si sus AP solo conectan clientes de la red inalámbrica directamente a su red cableada, entonces verá esto de vez en cuando. Los clientes aparecerán desde diferentes puertos a medida que se vuelven a asociar a otros AP / células en el ESSID.

Supongo que está hablando de Cisco IOS aquí, basado en el término "MACFLAP", que aparece en sus mensajes de registro cuando esto sucede. Por ejemplo: "% SW_MATM-4-MACFLAP_NOTIF: el host 0011.2233.4455 en vlan 123 está aleteando entre el puerto Gi1 / 1 y el puerto Gi1 / 2"

Lo que esto significa es que el conmutador tiene que "volver a aprender" una dirección MAC de Ethernet desde un puerto diferente al que está almacenado en caché en la tabla de reenvío de hardware. Esto lleva un poco de tiempo de CPU para cada evento, y suceder más de un par de veces seguidas hará que el mensaje MACFLAP se registre a medida que se consume más y más tiempo de CPU.

Sin embargo, esto no debería hacer que toda la tabla se vacíe o se borre. Solo las entradas para la dirección MAC de origen de aleteo deberían verse afectadas.

Ahora, en su caso, si este es un mensaje poco frecuente y solo se trata de clientes inalámbricos que se mueven de un lugar a otro, no me preocuparía demasiado por esto. Para evitar esto, se necesitaría una terminación centralizada del cliente inalámbrico. De esta manera, los marcos aparecerían en la VLAN cableada en un lugar consistente.

Sin embargo, si esto sucede con frecuencia para muchas direcciones MAC, podría ser indicativo de un bucle de capa 2 que definitivamente necesitará algo de investigación. :pag

Los eventos de aleteo no requieren tráfico de ingreso alternando entre puertos: un simple cambio de ingreso de una dirección MAC en el puerto A al puerto B en un conmutador lo suficientemente rápido hará que se registre un evento de aleteo; por ejemplo, una migración en vivo de una máquina virtual de un host a otro a menudo causará una notificación de aleteo MAC.

Como las otras respuestas han cubierto, no hay nada de qué preocuparse hasta que los eventos sean mucho más frecuentes de lo que estás viendo. Sus inquietudes sobre la convergencia del árbol de expansión y el vaciado de las tablas MAC son infundadas; no es un cambio de topología para el árbol de expansión y la tabla se está actualizando para la dirección MAC que se movió; otras entradas en el mismo conmutador, el mismo vlan o el mismo puerto no se ven afectadas.

A menos que esté recibiendo muchas notificaciones de macflap, no estaría preocupado. Parece que el cliente itinerante se está comunicando temporalmente con dos AP (que están conectados al mismo conmutador) mientras se está transmitiendo de uno a otro. Los macflaps se producen porque el conmutador ve el tráfico del mismo MAC en dos interfaces al mismo tiempo. Esperaría que los macflaps se detengan cuando se complete la transferencia. La preocupación habitual con los macflaps es cuando no se detienen: la paliza de actualizar constantemente la tabla MAC varias veces por segundo puede dañar seriamente el hardware de un conmutador ($ WORK una vez literalmente derritió una tarjeta de supervisor 6500 de esa manera).

No veo por qué la tabla MAC se vaciaría a través del dominio L2: su contexto es local para el conmutador. Si conecta uno de los AP a un conmutador diferente, debe dejar de ver las notificaciones de macflap.