cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 

MLAG issue with SonicWALL SonicPoints

MLAG issue with SonicWALL SonicPoints

Eric_Burke
New Contributor III
Recently converted a traditional core stack of x670's to a set of MLAG piers with LACP downlinks to user stacks and wireless switches (the latter are single x460v2's). The latter are running two uplinks, one to each peer and since the update - our SonicPoints stopped provisioning properly back to the firewall located directly off the core. Essentially they would (usually) "show up" in the list of discovered SonicPoints but that was it. They just hung, staying in an unknown state. On a whim, we put another small SonicWALL directly into the POE wireless switch, moved the untagged vlan for provisioning to the same network as that devices and viola, they provisioned. Then, moved them back - no luck.

Having had a similar issue with HyperV when the LACP type was wrong (not using IP hash on the physical NIC team), I had one of our engineers simply pull the secondary LACP link - bam - SonicPoint provisioned fine. My understanding (obviously incorrect) is that the hash method should not really matter and would only affect the effectiveness of load balancing across LAG ports. Yet the only way I seem to fix issues like this when they arise is to drop the second port or something related to L2/L3 addresses. What am I missing?
1 REPLY 1

Eric_Burke
New Contributor III
Found the answer (oops). Totally unrelated to the problem we had on Hyper-V (sorry for any misdirection). Ended up we had a very simple problem - the ISC was not tagged to the provisioning VLAN for the access points. Sometimes they'd come up on the peer with the active firewall and other times, not...
GTM-P2G8KFN