Tip of the Day: Why You Should Recommend SET over LBFO

Today’s Tip… Why You Should Recommend SET over LBFO

Ever need a quick reference when asked about the positives and negatives of various teaming technologies? Here is a set of factoids and recommendations that should help you out!

Background Reading

• Switch Embedded Teaming (SET)
• Load Balancing Failover (LBFO) - Server 2012, Server 2012R2

..and now to the good stuff…

Why We Recommend Switch Embedded Teaming (SET) over LBFO on Windows Server 2016 and 2019

• SET has exceeded the stability and performance capabilities of LBFO
• LBFO does not support a number of core Microsoft scenarios including:
  • LBFO cannot team RDMA adapters and as such is not suitable for Storage Spaces Direct deployments
  • LBFO does not support VMMQ or other stateless offloads that:
    • Enable VMs to exceed ~5 Gbps throughput per virtual machine
    • Improve system efficiency
    • Improve VM density
  • LBFO does not support SDNv2, the basis of Azure Networking on-premises in Windows Server 2016 or Windows Server 2019

‘However, SET does not support LACP and teaming mechanisms at the switch layer.’ 

The Microsoft perspective on this is:

• LACP is not agile and requires switch modification, which is not easily automated, deployed, troubleshot, or maintained
• Limits you to the minimum number of queues between the teamed adapters, limiting your overall VM density on the system
• Aggregate bandwidth is irrelevant unless you need a single VM to consume more than a single adapters capability

 

Here’s hoping this helps with your next customer conversation.