Firstly, your thread title suggests you're using Load-Based Teaming (LBT), but your post says otherwise. Route based on IP hash is a mechanism for use in a LAG whereas LBT does not rely on LAGs. Which are you using?
My mistake. I have updated the title to reflect.
Our uplinks are in a port channel, and we're using IP Hash as our balancing method. I am trying to determine if there is any benefit on going through the complexity of setting up LACP and LAG groups in addition to what we have configured now.
I'm in the process of writing an article about this but don't have it ready yet. My general recommendation (and that of the experienced community), is to use load-based teaming if you're entitled to a vDS and to not use any form of LAG (be that static or LACP/dynamic). There are more pros than cons when it comes to this approach. LBT is simpler to set up, administer later, and troubleshoot because it requires no special switch-side configuration. It's also the only method that is truly able to achieve a balance of pNICs--something which neither bonding method can achieve. So when using vSphere with a vDS entitlement, the strong recommendation is to use LBT and no LAG.
That's the same conclusion that I've gotten while doing research on it. Would the push of bonding (static/LACP) from Networking be more from a legacy standpoint? Stick with what works kinda thing?
I would definitely be interested in that article once you are finished.
Generally, both in my experience and those of other experts over the years with whom I've consulted, the demand for using LAG/LACP is usually the following (ranked in order of most prevalent to least):
- Customer doesn't know how vSphere works and what features it has with networking.
- Ignorance that LAG/LACP is the only method to ensure concurrent link utilization and fail-over capabilities (linked with #1).
- Networking team thinks vSphere/ESXi is just like every other physical server / don't want to learn new features.
- Company standardization on LAG/LACP based on pre-virtualization technology.
- Existing vendor infrastructure/solution requires it (rare; archaic today)
Either #1-3 above is likely to be the reason for the mandate for LAG/LACP if it's coming from the networking team.