[alcatel-nsp] LAG load balance issue 7210 SAS Sx 10G/100G
Andrey Elperin
mizzy at greenhell.kiev.ua
Sun Jan 30 15:24:30 EST 2022
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/alcatel-nsp/attachments/20220130/284eed1c/attachment.htm>
More information about the alcatel-nsp
mailing list