<div dir="ltr">I would like to share an update to this issue and how we have solved the problem or at least it seems so.<div><br></div><div>As many of you have pointed out this issue was caused by lack of entropy between BNG and access node. All of our routers between the two are LSR. According to book "Designing ip/mpls based ethernet layer2 services" by Frank Xu, SRA No1, it is suggested to make one of our LSR service aware for that service with heavy traffic. To do that with least amount of overhead it is suggested to use epipe service with vc-switching enabled. This allows router to perform hashing based on mac/ip.</div><div><br></div><div>This is what we have done between access node and last LSR. (our access node(PE) is running mpls as well). Traffic balances pretty much even across 2x10G.</div><div>For now we do not see any downsides or side effects.</div><div><br></div><div>Happy new year everyone!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den mån 31 jan. 2022 kl 22:05 skrev Dejan Tepic <<a href="mailto:dejantep@gmail.com">dejantep@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks for the suggestion but that's not an option for the time being. Interesting though.<br>Wouldn't that result in a lot more overall configuration? Today we use one VPLS to backhaul customers to BNG. Works great except this issue with LAG.<div>Are you practicing this already with Nokia products?</div><div><br></div><div>kind regards</div><div>Dejan<br><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den mån 31 jan. 2022 kl 20:43 skrev Jonathon Exley <<a href="mailto:Jonathon.Exley@chorus.co.nz" target="_blank">Jonathon.Exley@chorus.co.nz</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-NZ">
<div>
<p class="MsoNormal"><span>Maybe you will need to change your service model to have multiple epipes between 7210A and 7210C, and change
</span>SR1----7210A to use access interfaces.<u></u><u></u></p>
<p class="MsoNormal">If you use qinq on your access node you could have a VLL per SVID.
<span><u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:8pt;font-family:Verdana,sans-serif">Jonathon<br>
<br>
</span><span><u></u><u></u></span></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Dejan Tepic <<a href="mailto:dejantep@gmail.com" target="_blank">dejantep@gmail.com</a>>
<br>
<b>Sent:</b> Monday, 31 January 2022 7:34 pm<br>
<b>To:</b> Jonathon Exley <<a href="mailto:Jonathon.Exley@chorus.co.nz" target="_blank">Jonathon.Exley@chorus.co.nz</a>><br>
<b>Cc:</b> <a href="mailto:alcatel-nsp@puck.nether.net" target="_blank">alcatel-nsp@puck.nether.net</a><br>
<b>Subject:</b> Re: [alcatel-nsp] LAG load balance issue 7210 SAS Sx 10G/100G<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hello,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">it looks like it's not supported on 10/100GE model we use.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <i>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). </i><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks for your reply <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Den sön 30 jan. 2022 kl 23:30 skrev Jonathon Exley <<a href="mailto:Jonathon.Exley@chorus.co.nz" target="_blank">Jonathon.Exley@chorus.co.nz</a>>:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal">It looks like the SAS-Sx on 20.9 supports hash labels.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Jonathon.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:12pt"><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> alcatel-nsp <<a href="mailto:alcatel-nsp-bounces@puck.nether.net" target="_blank">alcatel-nsp-bounces@puck.nether.net</a>>
<b>On Behalf Of </b>Dejan Tepic<br>
<b>Sent:</b> Monday, 31 January 2022 9:56 am<br>
<b>To:</b> Andrey Elperin <<a href="mailto:mizzy@greenhell.kiev.ua" target="_blank">mizzy@greenhell.kiev.ua</a>><br>
<b>Cc:</b> <a href="mailto:alcatel-nsp@puck.nether.net" target="_blank">alcatel-nsp@puck.nether.net</a><br>
<b>Subject:</b> Re: [alcatel-nsp] LAG load balance issue 7210 SAS Sx 10G/100G</span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">Hello and thanks for the input.<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">You are spot on :) and this is what I was afraid of. We have an option of using 100G interface as well.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Hash-labels are not supported on this model as far as I know. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">kind regards<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Dejan<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">Den sön 30 jan. 2022 kl 21:38 skrev Andrey Elperin <<a href="mailto:mizzy@greenhell.kiev.ua" target="_blank">mizzy@greenhell.kiev.ua</a>>:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin:5pt 0cm 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal"><br>
Hi Dejan,<br>
<br>
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.<br>
<br>
According to the documentation in LSR role 7210 SAS-Sx have two options to hash LAG traffic:<br>
<br>
1. hash-1: by outer MACs of the Ethernet packets that encapsulates an MPLS packets. There is not enough entropy in your case.<br>
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).<br>
<br>
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.<br>
<br>
If my guess about your configuration is wrong - pardon me and please provide more details :)<br>
<br>
30.01.2022 19:00, Dejan Tepic пишет:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">I’m having issues regarding load balance on links between several 7210 SAS Sx<br>
Here is the topology:<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">SR1----100G----7210-A----2x10G----7210-B----2x10G----7210-C----10G----Accessnode<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Traffic egressing 7210-A is not balanced between two 10G links. Not even close (85/5 in percentage)<u></u><u></u></p>
<p class="MsoNormal">Traffic egressing 7210-B even worse almost zero traffic on one link<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"> I’m having issues regarding load balance on links between several 7210 SAS Sx<u></u><u></u></p>
<p class="MsoNormal">Here is the topology:<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">SR1----100G----7210-A----2x10G----7210-B----2x10G----7210-C----10G----Accessnode<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Traffic egressing 7210-A is not balanced between two 10G links. Not even close (85/5 in percentage)<u></u><u></u></p>
<p class="MsoNormal">Traffic egressing 7210-B even worse almost zero traffic on one link<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal">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”<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I have updated TAC case with traffic information which is unicast traffic between BNG och Access nodes. <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:12pt">Did anybody out there experienced this and solved it somehow?
<u></u><u></u></p>
<p class="MsoNormal">Kind regards<u></u><u></u></p>
<p class="MsoNormal">Dejan<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>alcatel-nsp mailing list<u></u><u></u></pre>
<pre><a href="mailto:alcatel-nsp@puck.nether.net" target="_blank">alcatel-nsp@puck.nether.net</a><u></u><u></u></pre>
<pre><a href="https://puck.nether.net/mailman/listinfo/alcatel-nsp" target="_blank">https://puck.nether.net/mailman/listinfo/alcatel-nsp</a><u></u><u></u></pre>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12pt"><br>
<br>
<u></u><u></u></p>
<pre>-- <u></u><u></u></pre>
<pre>/me at home<u></u><u></u></pre>
</div>
<p class="MsoNormal">_______________________________________________<br>
alcatel-nsp mailing list<br>
<a href="mailto:alcatel-nsp@puck.nether.net" target="_blank">alcatel-nsp@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/alcatel-nsp" target="_blank">https://puck.nether.net/mailman/listinfo/alcatel-nsp</a><u></u><u></u></p>
</blockquote>
</div>
</div>
<p class="MsoNormal">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.
<u></u><u></u></p>
</div>
</blockquote>
</div>
</div>
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.
</div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Hälsningar<div><br></div><div><b>Dejan Tepic</b></div><div><a href="http://www.dejantepic.org" target="_blank">www.dejantepic.org</a> | <a href="https://www.instagram.com/dejantep/" target="_blank">Instagram</a> | <a href="https://www.facebook.com/fineartbydejan" target="_blank">Facebook</a></div><div><br></div></div></div>