Hashing Algorithm:
IPv4 traffic
L2 bridged:
It will be hashed based on (mac src/dst + src/dst L3 IP + src/dst L4 ports)
L3 routed
It will be hashed based on (ip src/dst L3 + src/dst L4 ports)
IPv6 traffic
L2 bridged:
It will be hashed based on (mac src/dst + IPv6 L3 + IPv6 L4)
L3 routed
It will be hashed based on (IPv6 src/dst L3 + IPv6 src/dst L4)
Non-IP traffic
It will be hashed based on (mac src/dst)
LAG hashing does not need to match on the two sides of a LAG, as long as both sides behave “according to standards”. A LAG will accept traffic on any port, and use the hash to determine the outgoing port. This hashing is used for load-balancing, not as an authentication hash. This is the reason that a Juniper EX series can have a functioning LAG with a Cisco 3750 or 3560, although those Cisco models only support L3 hashing. On the Cisco side, L4 hashing doesn’t start until the Catalyst 4000 models.
I have, however, seen devices that require their hash to be matched exactly. VMWare ESX 3.5.x is an example. VMWare also does not support LACP, though it does support LAGs.
LACP is an optional component of a LAG. It is configured as “active” or “passive” LAG, whereas a LAG without LACP is “on” (Cisco) or simply does not have the LACP command (JunOS). When both sides support LACP, it is best practice to enable LACP. At least one side needs to be “active” for the link to be established. Note that both Juniper and Cisco default to “passive” mode. There is no drawback to configuring both sides to be “active”, this merely means that both sides can bring the link up. In interop scenarios (Juniper to vendor X), “active/active” is recommended.
A Juniper EX chooses the hash to be used automatically. The hash algorithm cannot be configured. On JunOS-based routers such as the MX series, the hashing can be configured in the “forwarding-options hash-key” stanza.
That Juniper supports L4 hashing across the board means that its load-balancing will be more evenly distributed. Consider, for example, a situation where a server has multiple connections to a SAN device. With L3 hashing, all of these connections would utilize only one link. L4 hashing will allow them to be spread out across the LAG. This is a competitive advantage over Cisco 3-series switches.
Lastly, when discussing LAGs with your clients, bear in mind that LAGs load-balance, they do not load-share. One TCP/UDP connection will use one link, and is constrained to the bandwidth of that link. It is with multiple connections that the load-balancing algorithm of a LAG comes to play.