Wired Intelligent Edge (Campus Switching and Routing)

Reply
Regular Contributor I

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

ArubaOS-CX 10.01

 

Is LACP Layer 4 hashing algorithm (L4-src-dst) going to be available as an additional LACP hashing mechanism along with actually supported/implemented L3-src-dst and L2-src-dst?

Aruba Employee

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

Not at this time. Could you please elaborate the conditions where you see that L4 hashing would be required (like due to web-proxy usage, or PAT ?) ?

Regular Contributor I

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

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...    

Aruba Employee

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

ok. Thanks for this clarification regarding your usage.

 

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.

 

Regular Contributor I

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


@vincent.giles wrote:

...

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:

 

Aruba_8320_VSX_VSX_LAGs_distribution_19092018.png

 

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).

 

That's to say that LACP Hashing Algorithm (L2 vs L3 vs L4) would have (or actually has) an impact.

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: