[alcatel-nsp] LAG load balance issue 7210 SAS Sx 10G/100G

[Dejan Tepic]

Hello,

it looks like it's not supported on 10/100GE model we use.
  *This feature is only supported on 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE,
7210 SAS-R6 (IMMv2 cards), and 7210 SAS-R12 (IMMv2 cards). *

Thanks for your reply

Den sön 30 jan. 2022 kl 23:30 skrev Jonathon Exley <
Jonathon.Exley at chorus.co.nz>:

> It looks like the SAS-Sx on 20.9 supports hash labels.
>
>
>
> Jonathon.
>
>
>
>
>
> *From:* alcatel-nsp <alcatel-nsp-bounces at puck.nether.net> *On Behalf Of *Dejan
> Tepic
> *Sent:* Monday, 31 January 2022 9:56 am
> *To:* Andrey Elperin <mizzy at greenhell.kiev.ua>
> *Cc:* alcatel-nsp at puck.nether.net
> *Subject:* Re: [alcatel-nsp] LAG load balance issue 7210 SAS Sx 10G/100G
>
>
>
> Hello and thanks for the input.
>
>
>
> You are spot on :) and this is what I was afraid of. We have an option of
> using 100G interface as well.
>
> Hash-labels are not supported on this model as far as I know.
>
>
>
> kind regards
>
> Dejan
>
>
>
> Den sön 30 jan. 2022 kl 21:38 skrev Andrey Elperin <
> mizzy at greenhell.kiev.ua>:
>
>
> Hi Dejan,
>
> LAG hashing on any type of 7210 boxes is really very dependent on traffic
> type. I can assume that in your scenario 7210-A and 7210-B are pure LSRs.
> Also, if you mentioned BNG - it's very probable that you are using PWs
> between SR1 and 7210-C.
>
> According to the documentation in LSR role 7210 SAS-Sx have two options to
> hash LAG traffic:
>
> 1. hash-1: by outer MACs of the Ethernet packets that encapsulates an MPLS
> packets. There is not enough entropy in your case.
> 2. hash-2: by combination of ingress port ID, label stack (3 topmost
> labels) and dst IP address. But dst IP address will be used only if there
> is IP header right after MPLS header (so it won't be used in case of PWs).
>
> Looks like that the simpliest way to increase entropy in your case is to
> increase number of PWs. Also you can try to play with hash-labels, but I'm
> not sure that it's supported on SAS-Sx now.
>
> If my guess about your configuration is wrong - pardon me and please
> provide more details :)
>
> 30.01.2022 19:00, Dejan Tepic пишет:
>
> I’m having issues regarding load balance on links between several 7210 SAS
> Sx
> Here is the topology:
>
>
>
>
> SR1----100G----7210-A----2x10G----7210-B----2x10G----7210-C----10G----Accessnode
>
>
>
> Traffic egressing 7210-A is not balanced between two 10G links. Not even
> close (85/5 in percentage)
>
> Traffic egressing 7210-B even worse almost zero traffic on one link
>
>
>
> I’v checked interface configuration guide and information about LAG
> hashing. I’v tested with different algorithms hash-1, hash-2 but nothing is
> changing.
>
>  I’m having issues regarding load balance on links between several 7210
> SAS Sx
>
> Here is the topology:
>
>
>
>
> SR1----100G----7210-A----2x10G----7210-B----2x10G----7210-C----10G----Accessnode
>
>
>
> Traffic egressing 7210-A is not balanced between two 10G links. Not even
> close (85/5 in percentage)
>
> Traffic egressing 7210-B even worse almost zero traffic on one link
>
>
>
> I’v checked interface configuration guide and information about LAG
> hashing. I’v tested with different algorithms hash-1, hash-2 but nothing is
> changing.
>
>
>
> I have a ongoing TAC case and TAC suggested to make all ports in a LAG odd
> or even which i did but it didnt help.
>
> Latest TAC answer suggest everything is fine ”At this point I dont see
> this to be an issue until and unless we know the type of traffic that is
> egressing out of Lag. Its only that the fair distributed of traffic dint
> happen on to the lag ports. This could happen when there is not much
> variation available or variations that get nullify with the traffic streams
> that are egressing out of the Lag”
>
>
>
> I have updated TAC case with traffic information which is unicast traffic
> between BNG och Access nodes.
>
>
>
> Did anybody out there experienced this and solved it somehow?
>
> Kind regards
>
> Dejan
>
>
>
>
>
> _______________________________________________
>
> alcatel-nsp mailing list
>
> alcatel-nsp at puck.nether.net
>
> https://puck.nether.net/mailman/listinfo/alcatel-nsp
>
>
>
>
> --
>
> /me at home
>
> _______________________________________________
> alcatel-nsp mailing list
> alcatel-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/alcatel-nsp
>
> The content of this email (including any attachments) is intended for the
> addressee only, is confidential and may be legally privileged. If you’ve
> received this email in error, you shouldn’t read it - please contact me
> immediately, destroy it, and do not copy or use any of the content of this
> email . No confidentiality or privilege is waived or lost by any
> mis-transmission or error. This communication does not designate an
> information system for the purposes of Part 4 of the Contract and
> Commercial Law Act 2017. Although we have taken reasonable precautions to
> ensure no viruses are present in this email, we cannot accept
> responsibility for any loss or damage arising from the use of this email or
> its attachments.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/alcatel-nsp/attachments/20220131/e08fe978/attachment.htm>