Cisco – Triggered removal of members of a port-channel

The load balancing on a port channel is per flow. All the traffic in a single flow will use the same port channel member. Each flow is limited to a single physical link, but different flows will use different links. The way you have it configured, a flow is determined by the source and destination IP and MAC addresses on the Nexus, meaning that any traffic with the same values for those will always use the same port channel member. There is a hash algorithm that determines which flows use which port channel members, and it is only when you have multiple flows between different devices that you get load balancing across the different links.

You seem to be sending traffic on that port channel from a single source to a single destination, and that traffic will always use the same port channel member. It is also possible that you have multiple flows that just happen to hash to the same port channel member.

If you were to load balance individual frames, rather than flows, you will end up with problems created by out-of-order packet delivery. That would be especially and extremely detrimental to VoIP.

Short answer: no.

While the STP handover in step 4 or step 3 is usually faster than 1 second there's always a gap. Make sure you're using RSTP, MSTP or RPVST though. The original and largely obsolete STP is slow on convergence.

One tiny thing might reduce the gap a little further: before step 3, decrease the trunk's STP priority value below that of the yet active port. This will already initiate the handover in step 3, so it doesn't need to be a shutdown reaction but a more 'flowing' process.

As this seems to be very delicate connection I'd stage the exact process in a lab before doing it in production.