VPC Member Ports Configuration (LACP / Non LACP)

[vishaw jasrotia]

Hello All,

I had gone through VPC best practice deployment guides. It recommends to use LACP in active mode  for member ports. my question why it's recommended.

If I go with on mode (non LACP) then what will happen.

What's difference between using LACP active and on mode (non LACP) with member ports.

Thanks in advance.

[Steve Fuller · Accepted solution]

Hi,

I think LACP to be best practice for any type of link aggregation, not only vPC.

If you use static mode then one device has no understanding of how the link partner is configured and operating. When using LACP the two link partners agree on the formation of the link aggregate.

Take the example of where Switch 1 (S1) has two links configured as part of a LAG, but the ports on Switch 2 (S2) to which the two links are connected are not configured in a LAG.

If using static mode the LAG on S1 will form anyway and so S1 the will consider it OK to send traffic on both links. Traffic from a host may alternate being sent across link 1 and link 2 as, depending upon the port-channel load balancing, this is perfectly acceptable behaviour.

Now consider the view of this from the point of S2. It will first see a MAC on link 1, then on link 2, then on link 1 etc. This switch would consider the MAC as flapping.

If the LAG is using LACP, then S1 would operate the LAG differently as it would not be receiving LACPDU from S2. Depending upon the configuration of the switch, the member ports would either become disabled, or the LAG would operate in what’s considered an “Individual” state where only one link of the LAG were used.

Wikipedia also lists some advantages in the section Advantages over static configuration.

Regards

[vishaw jasrotia]

Thanks Steve for helpful comment.

In view of your example if I am doing static on S1 and S2 then how we differentiate if from LACP

Thanks

[Steve Fuller · Accepted solution]

Hi,

When both switches are configured correctly and everything operates as it should, then there is less to differentiate between static or dynamic LAG. The scenario I painted previously would not occur if both partners were configured correctly.

But that’s the point of LACP. It will manage the LAG in the event the partners are not configured correctly. I’ve encountered issues where LACP either did “save the day” or would have had we not been using static LAG.

Personally I consider this from the other point of view. Why would I not use LACP to manage a LAG? The IEEE standard is very mature, and is well implemented across multiple vendors. I’ve successfully used LACP between Cisco, Juniper, Arista, HP (switches and servers), NetApp, Red Hat Linux, Solaris, Windows etc., all without issue. IMHO the only time I would use static LAG is when one of the link partners didn’t support LACP. I see no disadvantage to its use.

Going back to your original question of "why it's recommended", then I'd suggest that from experience Cisco sees less issues when using LACP as compared to when using static LAG.

Is there a specific reason you prefer not to use LACP to manage the LAG? From a configuration perspective the only difference is a change from channel-group <group> mode active to channel-group <group> mode on.

Regards

[vishaw jasrotia]

Reason for using static to manage LAG is that, I am going to deploy this for vSphere. vSphere don't support LACP. For enabling LACP you have to use Nexus 1000v or DV Switch with vSphere.

Anyways now I am clearer with this.

Thanks for making me to understand the logic.

[Steve Fuller]

As an additional note, I'm not sure how you build your vSphere ESXi servers, but if you use PXE boot then you need to ensure that the server only enables one NIC during the boot/build process.

If the server brings both NICs up then the LAG is operational as far as the network is concerned. When the PXE process starts the server MAC is learned on the LAG, and even though the PXE process is only using one NIC, traffic could be returned to the server on either NIC. If it's sent to the server on the NIC not being used by the PXE process, the traffic gets dropped and the build process fails.

Take a read of the post PXE Boot with Link Aggregation that I raised over on the VMware vNetwork Communities forum for details.

Regards