Yes, I’m aware of the reason for the management issue. I could tolerate it, if that’s all it was. When I wanted to manage the Mimosas, I would just break the LAG temporarily. Not ideal, but workable. The problem was getting that MAC address back on the LAG from the downstream switch (Cisco 3560s). The only thing I can assume is that, due to the Mimosa units trying to use their IP addresses to communicate on the LAG, they were generating traffic on 1/2 the LAG link, which would NOT be normal LAG traffic, and somehow that was causing the loop. The Mimosa units’ Ethernet ports think they’re on a normal Ethernet connection, not 1/2 of one (one leg of the LAG).
One way around this would be to make 2 layer 3 connections through the Mimosas, each on a different network. However, the building they’re supplying, while across the parking lot, is close enough to allow roaming. If I go layer 3, I loose the ability for the roaming, wireless clients, such as cell phones, to maintain their IP address and just roam from WAP to WAP. Instead, they would need a new connection with a new IP address in the building supplied by the Mimosas.
For your suggestion to put the VLAN on the interface & not the LAG, I’ll have to think about. To run the Trunk over the link and set up the LAG, the entire link becomes part of the LAG. The interfaces on the switches are joined. I don’t know of a way to also put an Access VLAN on the port that wouldn’t be part of the LAG, just for the Mimosas to use. In other words, when creating the LAG, the interfaces are bundled. The LAG is NOT created on a per VLAN basis.