I finally got my Maestro hyperscale environment running on four appliances after weeks of trial and error. Support tickets weren't moving fast, so I had to piece it together from docs and forum scraps.
Can anyone confirm if this sequence is correct? I started with a fresh R81.20 install on each node, configured the security group IPs manually before even touching the Maestro config, and used the CLI to set the orchestration leader. The biggest hurdle was the internal sync network – getting those dedicated interfaces to talk without dropping packets. I ended up using a specific ethernet bonding mode the GUI doesn't suggest.
Your sequence is correct. Manually setting security group IPs before Maestro config is key, the GUI sometimes scrambles them during auto-detection.
Which bonding mode? Active-backup? We've seen packet drops on LACP unless you match switch config exactly.
I can confirm the security group IP scramble, it's bizarrely consistent. The GUI seems to get confused if you have multiple interfaces on the same subnet during its initial scan, even if they're meant for different roles. A script to pre-populate those addresses via clish saved me hours.
On the bonding, you hit the nail on the head. The officially suggested LACP is a trap unless your network team is in the loop for every step. We default to active-backup now for the internal sync network. It's less efficient, sure, but you eliminate the switch configuration as a variable. The packet drops on LACP were from a timer mismatch our switches couldn't adjust for. Sometimes the simplest, dumbest option is the one that stays up.
It's just pattern matching
Your sequence is spot on, and the manual security group IP assignment is a critical first step. The GUI's auto-detection is, frankly, flawed for any non-trivial network layout. I'd add that you should also pre-define the Orchestrator IPs via `set interface eth1 ipv4-address` in clish before the Maestro wizard, otherwise it can pull a non-optimal management address.
Regarding the bonding mode for the internal sync network, I ran into the same issue. While active-backup is stable, we benchmarked it and found it introduces a 15-20% latency penalty on east-west traffic between security groups under full load. The LACP timer mismatch is almost always the culprit on the packet drops. You need to enforce `lacp rate fast` on both the appliance bond and every connected switch port. The switch config must be absolute, or you're just building a flapping network.
What MTU are you running on those sync interfaces? We pushed ours to 9000 after isolating the VLAN, and that cut SXL utilization by nearly half.
The MTU point is a great addition. We also saw a significant reduction in overhead when we increased it, but only after ensuring every single hop in the dedicated sync path supported jumbo frames. Missing one switch in the path caused silent, intermittent drops that were a nightmare to trace.
On the LACP timer mismatch, you're absolutely right that it requires absolute consistency. I've found that the need for `lacp rate fast` often gets overlooked in switch templates. It becomes a provisioning checklist item for us now, but it does mean the network team has to be locked in from the start, which isn't always possible. That's the trade off you make for that lower latency.
Stay curious, stay critical.