Re: ArubaOS-CX 10.01 VSX: LAG LACP Layer 4 hashing algorithm

‎09-18-201808:03 AM

Hello Giles,

actually our VSX is running with initial 13 VSX LAGs (this number is going to increase): our LACP peers are IBM system running PowerVM (VIOS) and those peers are set with src/dst port as hashing alghorithm (for their outgoing traffic to the VSX)...we're asking if having a VSX that provides Layer 4 hashing algorithm - in our specific case where traffic will remain southbound the VSX - would be benefical with respect having only Layer 3 that is used for selecting outgoing links on involved VSX LAGs...

Re: ArubaOS-CX 10.01 VSX: LAG LACP Layer 4 hashing algorithm

When you have 2 links in a VSX LAG, one physical link per each switch,

the hashing algorithm is not used to determine which link is being used.

Instead, we have a internal mechanism that optimizes the traffic to stay local to the switch (to avoid sending the traffic over ISL that would add one hop in the traffic path, which is not necessary).

The hashing algo would have an impact if you would have 4 links in VSX LAG, 2 per switch, downstream to the server.

So the desicion criteria in your case is actually the way the packet is received on CX-SW1 or on CX-SW2: this is your hypervisor that decides - based on its L4 hashing algo - to send packet to CX-SW1 or CX-SW2.

Each switch will locally process the packet if the destination is reachable behind a dual-attached VSX-LAG (which is your case).

I hope this clarifies. In a nutshell, in your case, hashing-tuning for L2 or L3 or L4 (if we would have) has no effect.

Re: ArubaOS-CX 10.01 VSX: LAG LACP Layer 4 hashing algorithm

The hashing algo would have an impact if you would have 4 links in VSX LAG, 2 per switch, downstream to the server.

Hi Giles, really thanks for this explanation, really useful.

Our acutal setup has 13 VSX LAGs each one made of multiple member links (from 2 links up to 3 links on about half of our total number of VSX LAGs we deployed), this clearly on each Aruba 8320 node.

Table below summarize our production scenario VSX LAGs quite well:

assignments are not static - especially regarding actual lag8-lag13 group with respect to lag1-lag7 group - indeed we're planning in a very near future to refactor lag8-lag13 (single leg VSX LAGs on each node) into multi-members VSX LAGs (as now is happening on lag1-lag7 group) that's because we're going to host a lot of new servers, each one having multiple 10Gbps ethernet links.

Consider that systems speak each others and also through TSM (lag1); lag128 used for VSX ISL is not listed ((2+2) x 40Gbps).