Both PAgP and LACP are only negotiation protocols that allow two devices to dynamically negotiate the creation of an EtherChannel. While using either of them is highly recommended, they do not influence how the EtherChannel works. The redundancy and load balancing is provided to you by the very way EtherChannel works itself.
In other words, you may use either LACP or PAgP (LACP is recommended as it is an open standard). EtherChannels negotiated by any of these two protocols will provide you with redundancy and load balancing.
While lacp or pagp aggregates the ports the most bandwidth a given ip conversation will have is whatever links you are using. Say you have 4 1 gig links channeled together , the fastest a given ip conversation can go is 1 gig as a given conversation will go over one of those 4 links . While the total traffic will be hashed across all 4 to "even" out the load .
It will also give you load balancing - but as Glen has explained, the EtherChannel technology always puts a single conversation to a single link in the EtherChannel bundle. Therefore, you will load balance multiple conversations only. This is again a fundamental feature of EtherChannel technology, and neither LACP nor PAgP can influence this.
Personally, I suggest using the src-dst-ip or even src-dst-port if supported, as this will enable your device to load balance using IP addresses or even L4 transport ports which exhibit the highest variability in different conversations. The src-dst-mac is a usable setting but the src-dst-ip will give you the same, if not better, load spreading characteristics.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...