LACP + VLAN trunk or separate links?

This is a kind of theoretical question, that my knowledge isn't quite up to.

The scenario is connecting two switches. Say I have 8 VLANs and 4 spare 1Gig ports to connect to another switch. Is it more efficient, for bandwidth/speed, to bundle those 4 ports up with LACP and trunk all the VLANs over the aggregated link, or is it better to not use LACP and just put 2 VLANs on each connection? Is there a difference?

In one sense, I am thinking that aggregating and putting all the VLANs down one 'pipe' makes sense, since they are likely to be unevenly utilised at any moment, meaning an unused link would be wasted capacity. But I'm not sure how LACP actually aggregates traffic, and whether the extra capacity would be available, and if the benefit is greater than overhead.

Find more posts tagged with

Comments

gc8dc95

Simply put, it would be best to create the aggregation group and trunk. This way the traffic requiring the larger pipe can use it.

--chris--

gc8dc95 wrote: »

Simply put, it would be best to create the aggregation group and trunk. This way the traffic requiring the larger pipe can use it.

This is a more dynamic use of resources.

I am green enough to know I don't know it all, so there might be use-cases where segregated LAG's would offer a benefit...but I think 90% of the time you would be best served with a single (larger) lag between switches.

stlsmoore

Using LACP and load balancing based on source IP, destination IP, and TCP/UDP port should provide pretty even load balancing. That's at least how I understand it in the Cisco Campus HA guide:

Campus Network for High Availability Design Guide - Cisco

--chris--

stlsmoore wrote: »

Using LACP and load balancing based on source IP, destination IP, and TCP/UDP port should provide pretty even load balancing. That's at least how I understand it in the Cisco Campus HA guide:

Campus Network for High Availability Design Guide - Cisco

Great link, thanks.

networker050184

Bonding the links offers a larger pipe and greater failure protection. The down side would be bandwidth contention with all VLANs sharing the aggregate bandwidth.

One thing to keep in mind due to load balancing algorithm a single traffic flow is still limited to the bandwidth of a single link. So a single flow between two hosts on either side of the LAG will only have 1G of bandwidth regardless of the configuration you go with.

xnx

Makes more sense to LAG for redundancy purposes

OctalDump

networker050184 wrote: »

One thing to keep in mind due to load balancing algorithm a single traffic flow is still limited to the bandwidth of a single link. So a single flow between two hosts on either side of the LAG will only have 1G of bandwidth regardless of the configuration you go with.

Yeah, I was thinking that might be the case. So, it would depend also how much concurrent traffic per VLAN. If each VLAN only had one host on one or the other side, it's not going to make use of the bigger pipe. Depending on how many endpoints per 1G link, you might not see any benefit from sharing, since there would be a maximum utilisation that might be below the extra capacity in the LAG. I'm guessing this comes down to how LACP handles load balancing.

Putting aside the redundancy considerations, it sounds like the optimal solution for efficient utilisation might just depend on some pretty specific details on the set up. Although it does sound like in the general case, where you'd expect many hosts per VLAN in a many to many arrangement, and traffic patterns are fairly "random", that you are better off aggregating your links.

networker050184

OctalDump wrote: »

Putting aside the redundancy considerations, it sounds like the optimal solution for efficient utilisation might just depend on some pretty specific details on the set up.

Definitely. The key to designing a proficient and stable network is knowing your traffic patterns before deciding on anything. But you can be relatively safe that at least 90% of the time or more LAG trunk is the way to go.