Design Considerations LACP LAG

Link Aggregation Groups are multiple connections between two switches that allow the switch to aggregate links/bandwidth between them.  LAG’s are typically dumb in themselves without using Link Aggregation Control Protocol, LACP, on top.  In fact, for instance, a (4) link LAG on one switch doesn’t know if the number (4) link on the receiving switch is good or not, it will simply send packets down the link.  Let’s take a quick look at the topic – Design considerations LACP LAG and see if we can pull out a few nuggets to go by when designing connections between switches.

Design Considerations LACP LAG

Let’s start the topic conversation by considering why we use LACP vs a plain port channel LAG.  Well, there are quite a few advantages that we need to consider, however, primarily LACP offers the failover and dynamic configuration that we desire when setting up a aggregated link between two switches.  Let’s take these advantages one by one.

If you used some type of media converter between the two devices, another system wouldn’t perceive a connectivity issue.  So a static aggregation on one side would continue to send packets down the link which would cause issues.  LACP will automatically failover the link if it senses the link is no longer good.

Also, it will dynamically configure the link.  It will confirm the configuration between the two switches and verify the link is good.  In a static configuration this validation doesn’t take place.  How does this work?

LACP is made possible by special little packets called protocol data units (PDUs) which are transmitted down all links that have LACP enabled.  If it discovers there is a compatible LACP enabled device on the other end, it will form the LACP bond between the two.

The universal LAG networking symbol is the links surrounded by the elipse or circle denoting the bonded connection.


Design Considerations

There are certainly a few things that should be considered with implementing LACP LAG connections.  A few questions that you may need to ask:

  • Are the switches the same type/manufacturer/model?
  • If different hardware vendors, do they implement LACP the same way?
  • Do the algorithms match?
  • What about the LACP timeout values if different vendors?
    • Cisco uses a short timeout value, other vendors use long timeout (Dell, Extreme, etc)
    • Most of the time this can be adjusted
  • How many links will you use in the LACP LAG?
    • Most vendors support a max of (8) links in LACP
  • Make sure you don’t inadvertently create cabling loops when creating the bond before configuring
    • A good practice is to bring down the interfaces that will be used for the LACP LAG
    • Then configure the port channel and LACP
    • Then bring up the interfaces

Final Thoughts

After taking a look at design considerations LACP LAG, hopefully you have a better idea of what LACP is and a bit about how it works and why you would want to use it over the traditional plain LAG.  LACP adds many desirable features to the aggregation bond that make it superior over the traditional LAG.  Keep in mind that not every device or technology supports LACP (i.e. legacy versions of ESXi didn’t support LACP – they now do, but illustrates the need to know).  So when implementing, thoroughly know the hardware and technologies you are working with.

Back to top button