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

[Dejan Tepic]

Hello,

Thanks for your reply.

According to the interface guide, the device is able to look within the
payload. There are different scenarios but documentation states that in
some cases it goes three labels deep, some cases two etc.
For instance:
If traffic type is MPLS LSR and you use hash-2 algorithm then packet fields
used for hashing are ingress port-id, mpls label stack(three labels deep)
and source and destination ip (Used when the IP header follows the MPLS
header)

Customers are backhauled from 7210-C to BNG via PW
PE-A and PE-B are LSR in this scenario.

kind regards
Dejan


Den sön 30 jan. 2022 kl 20:17 skrev karsten_thomann--- via alcatel-nsp <
alcatel-nsp at puck.nether.net>:

> Hello Dejan,
>
> I'm not a Nokia Expert and generalizing from other vendors, but it should
> still apply.
>
> LAGs need enough entropy to do the load balancing (SRC/DST-MAC,
> MPLS-Labels,
> IP-Addresses, TCP/UDP-Ports...).
> Also the involved hardware must be able to look deep enough in the frame
> to
> find the entropy.
>
> I'm not sure how you've configured your network, but if it's really a BNG
> with
> mpls network you typically have very low entropy on the LAG, nothing on L2
> (same src/dst-mac), outer label is the same (if there is only one
> access-node
> with high traffic), inner label/PW-Label is also the same, if you're not
> using
> multiple PW for the traffic.
> If the 7210 is able to look within the payload of the PW it should find
> some
> entropy in the dst-mac, but I'm not sure if it's able to perform load
> balancing on payload of a PW.
>
> From your description I assume they are not capable of load balancing on
> PW
> Payload.
> Possible solutions that come to mind are:
> - split the traffic over more/multiple PW
> - use FAT PW, if supported
>
> If the assumptions are wrong we need some more details about the network
> to
> make other suggestions.
>
> Kind regards
> Karsten
>
> On Sunday, 30 January 2022 18:00:47 CET Dejan Tepic wrote:
> > 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----Access
> > node
> >
> >
> >
> > 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----Access
> > node
> >
> >
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/alcatel-nsp/attachments/20220130/d8bfbc9f/attachment-0001.htm>