Load Sharing VPLS end


Userlevel 2
Hello Community,

I'm having headache about the load-balance on Aggreation Ports.

Our scenery is a MPLS network who the end point are connected by Juniper Routers.
These connections are 10G (20g agg) and have one VLAN VPLS tagged end-by-end.
The traffic doesn't get balanced even when I change the hash-algorithm and the balance type.

Is there any problem using VPLS and LACP?
Extreme introduced the load-sharing VPLS but I think that useful just for the trunk LACP/MPLS, isn't?

Thanks,
Julian Eble

49 replies

Userlevel 2
So you are looking to loadbalance LSP? Then use 15.6 ?
Userlevel 2
That's also a request that we're testing to use.
The scheme are more or less this:

Juniper =>20G LACP <= EXTREME CORE MPLS #VPLS# =>20G LACP => Juniper

The Juniper are doing the work just fine, but the Extreme are only transmiting in one port:

See below:

sh ports 47,48 utilizationLink Utilization Averages Thu Apr 16 18:16:05 2015
Port Link Link Rx Peak Rx Tx Peak Tx
State Speed % bandwidth % bandwidth % bandwidth % bandwidth
================================================================================
47 A 10000 22.01 22.01 31.02 31.02
48 A 10000 22.15 22.15 73.58 73.58

==============================================================================
47 47 LACP L3_L4 47 Y A 0
L3_L4 48 Y A 0
==============================================================================

Userlevel 2
i'm through the same problem, and i don't have answer yet.

But there is a command called "enable l2vpn sharing" and it saids make a traffic distribution betwen the interfaces LAG, however i tried update 2 x460, and them don't work fine, where i needed to do a downgrade of firmware.

if you have answer please let me know, becaus i'm the same situation.

😞
Userlevel 2
how many LSPs do you have over this LAG ? Are you running RSVP-TE or just LDP signaling ?

// Andreas
Userlevel 2
So, between the Juniper and Extreme there's no MPLS involved.
It's just L2, it's a termination of the VPLS.
The traffic are not being calculated in the hash.

But yes, in the backbone I'm using LSP and LDP.
you cannot load balance LDP signaled LSP´s. they must be RSVP signaled if you want to load balance them. although you can load balance a LSP on a LAG but as you have few # of labels the distribution is not good. the workaround is to create more LSP´s to your pseudowire.
Userlevel 2
Hello Leonardo,

I know what you is talking about, but in the end of my tunnel, there's no LSP signalling, just the raw packets...

I'm doing a lab right know, and I getting some conclusions about.
After the end of the VPLS , the LAG are hashing only when there's multiple MAC source, and the switch is not handling about the IP Source and Destionations...

I don't know if was clear enough but I will open a TAC about it...
Userlevel 2
Hello Leonardo,

I know what you is talking about, but in the end of my tunnel, there's no LSP signalling, just the raw packets...

I'm doing a lab right know, and I getting some conclusions about.
After the end of the VPLS , the LAG are hashing only when there's multiple MAC source, and the switch is not handling about the IP Source and Destionations...

I don't know if was clear enough but I will open a TAC about it...

Julian,

I'm confused now, so, are you using mpls between extreme and Juniper?

Is it problem happenning over cloud mpls, or just end network without mpls?
Userlevel 2
Hello Leonardo,

I know what you is talking about, but in the end of my tunnel, there's no LSP signalling, just the raw packets...

I'm doing a lab right know, and I getting some conclusions about.
After the end of the VPLS , the LAG are hashing only when there's multiple MAC source, and the switch is not handling about the IP Source and Destionations...

I don't know if was clear enough but I will open a TAC about it...

Welisson,

I'm nto using mpls between extreme and Juniper.
My main problem right now is the traffic without mpls.
But the traffic is coming by MPLS with VPLS tunnel.

I would like to have your skype to share my labs and try to show you my tests.
Userlevel 2
Hello Leonardo,

I know what you is talking about, but in the end of my tunnel, there's no LSP signalling, just the raw packets...

I'm doing a lab right know, and I getting some conclusions about.
After the end of the VPLS , the LAG are hashing only when there's multiple MAC source, and the switch is not handling about the IP Source and Destionations...

I don't know if was clear enough but I will open a TAC about it...

Hi Julian,

send me an email i reply my skype to you
my e-mail is welissontome [@] ig dot com dot br
Userlevel 2
Hi Leonardo

So, the question is. Why is there LAG and MPLS and they don't be possible use both at the same time?

in this case of the Julian, he has two interfaces 10Gbp/s in my case i have two interfaces gigabit, so, the ideia is increase bandwith making the LAG, but when we use MPLS we can't enjoy it.

Doesn't be so clear yet. What is reason about this don't work fine?

TKs
Userlevel 4
Hello,

The sharing algorithm is most likely at fault here. The L3_L4 streams will use the same link based on hash algorithm. Unfortunately Extreme does not do load balancing 1:1. We will load share but the traffic streams and what links they actually traverse in the share group will be dependent on the hashing algorithm. Traffic analysis would be your best bet here to determine the best share group algorithm to use to help balance the traffic but 1:1 balance will never be guaranteed.

Regards,

Joe Colatuno
Escalation Support Engineer
Userlevel 2
Hello,

The sharing algorithm is most likely at fault here. The L3_L4 streams will use the same link based on hash algorithm. Unfortunately Extreme does not do load balancing 1:1. We will load share but the traffic streams and what links they actually traverse in the share group will be dependent on the hashing algorithm. Traffic analysis would be your best bet here to determine the best share group algorithm to use to help balance the traffic but 1:1 balance will never be guaranteed.

Regards,

Joe Colatuno
Escalation Support Engineer
Hi Joe,

So, i know if depends of the traffic will be crossing the link sharing, where it can be unicast, multicast etc, but in my case i'm using all the traffic over vpls, and then, i don't have this traffic distribution or balacing between the link sharing, or be, not even 1:1, 1:2 and so, i have all the traffic been transmitted over only one port of the link sharing, and i not sure if the Extreme can to do that, also why is there Etherchannel/LACP(load Sharing in this case of the Extreme)if i can't using all switch's features?

Tks
Welisson
Userlevel 4
Hello,

The sharing algorithm is most likely at fault here. The L3_L4 streams will use the same link based on hash algorithm. Unfortunately Extreme does not do load balancing 1:1. We will load share but the traffic streams and what links they actually traverse in the share group will be dependent on the hashing algorithm. Traffic analysis would be your best bet here to determine the best share group algorithm to use to help balance the traffic but 1:1 balance will never be guaranteed.

Regards,

Joe Colatuno
Escalation Support Engineer
Hey Welisson,

Please see my response below to Julian and Douglas. Any questions further just let me know.
Userlevel 5
Based on your layout...

Juniper =>20G LACP <= EXTREME CORE MPLS #VPLS# =>20G LACP => Juniper

How many VPLS tunnels are there? It would seem to me that because the tunnels would have the same source and destination mac (assuming multiple tunnels exist) that the hash would be limited to those pairs. If that is true, that would explain the lack of sharing across the links. In a traditional lag the hash would be able to take each stream and its source mac to apply the hash to and therefore being able to distribute efficiently, when the sources mac is small the distribution would be that way as well. Any idea how many source/destination mac pairs there are in that traffic?

Bill
Userlevel 2
Based on your layout...

Juniper =>20G LACP <= EXTREME CORE MPLS #VPLS# =>20G LACP => Juniper

How many VPLS tunnels are there? It would seem to me that because the tunnels would have the same source and destination mac (assuming multiple tunnels exist) that the hash would be limited to those pairs. If that is true, that would explain the lack of sharing across the links. In a traditional lag the hash would be able to take each stream and its source mac to apply the hash to and therefore being able to distribute efficiently, when the sources mac is small the distribution would be that way as well. Any idea how many source/destination mac pairs there are in that traffic?

Bill
In this case, just one tunnel, but the point is related to the end and then we're doing the pure L2.

I had a lab where just I simulated a traffic orignated by just one source and destionation mac, but multiples source and destionation IP's and protocols.

The traffic don't get hashed and are flowing just in one interface.
Userlevel 5
Based on your layout...

Juniper =>20G LACP <= EXTREME CORE MPLS #VPLS# =>20G LACP => Juniper

How many VPLS tunnels are there? It would seem to me that because the tunnels would have the same source and destination mac (assuming multiple tunnels exist) that the hash would be limited to those pairs. If that is true, that would explain the lack of sharing across the links. In a traditional lag the hash would be able to take each stream and its source mac to apply the hash to and therefore being able to distribute efficiently, when the sources mac is small the distribution would be that way as well. Any idea how many source/destination mac pairs there are in that traffic?

Bill
OK.. Can you please share the output from "show sharing"? If the interface is only L2 then the hash can only (will only) be done on the L2 hash (source mac/destination mac). How many streams?
Userlevel 6
So, the ports 47 and 48 are the VPLS service ports connected to the Juniper devices right? If that is true, the fields that would be used by switch for hashing would be the source-mac-addresses and destination-mac-addresses (only L2 fields).

If it is only VPLS service traffic flowing out of these ports to the Juniper devices, the only option would be to use the L2 algorithm rather than L3. But if there is not a lot of source and destination mac address variation, this may not help.

If the traffic is coming into the switch through multiple ports, we could give port-based sharing a try.
Userlevel 2
So, the ports 47 and 48 are the VPLS service ports connected to the Juniper devices right? If that is true, the fields that would be used by switch for hashing would be the source-mac-addresses and destination-mac-addresses (only L2 fields).

If it is only VPLS service traffic flowing out of these ports to the Juniper devices, the only option would be to use the L2 algorithm rather than L3. But if there is not a lot of source and destination mac address variation, this may not help.

If the traffic is coming into the switch through multiple ports, we could give port-based sharing a try.
There's no VPLS between Juniper and Extreme, only L2.
Juniper are doing the EDGE router with BGP and Extreme are our CORE MPLS
So, the ports 47 and 48 are the VPLS service ports connected to the Juniper devices right? If that is true, the fields that would be used by switch for hashing would be the source-mac-addresses and destination-mac-addresses (only L2 fields).

If it is only VPLS service traffic flowing out of these ports to the Juniper devices, the only option would be to use the L2 algorithm rather than L3. But if there is not a lot of source and destination mac address variation, this may not help.

If the traffic is coming into the switch through multiple ports, we could give port-based sharing a try.
Hello Julian,

I have the same problem and it occurs just with the egress traffic, from extreme(that ends the VPLS) to my router(in this case a Mikrotik CCR-1036).
So, the ports 47 and 48 are the VPLS service ports connected to the Juniper devices right? If that is true, the fields that would be used by switch for hashing would be the source-mac-addresses and destination-mac-addresses (only L2 fields).

If it is only VPLS service traffic flowing out of these ports to the Juniper devices, the only option would be to use the L2 algorithm rather than L3. But if there is not a lot of source and destination mac address variation, this may not help.

If the traffic is coming into the switch through multiple ports, we could give port-based sharing a try.
And in other running case, it works normally, with same configuration. In this case without a router, because that I am delivering the VPLS circuit to my customer.
So, the ports 47 and 48 are the VPLS service ports connected to the Juniper devices right? If that is true, the fields that would be used by switch for hashing would be the source-mac-addresses and destination-mac-addresses (only L2 fields).

If it is only VPLS service traffic flowing out of these ports to the Juniper devices, the only option would be to use the L2 algorithm rather than L3. But if there is not a lot of source and destination mac address variation, this may not help.

If the traffic is coming into the switch through multiple ports, we could give port-based sharing a try.
Here follows the configuration, that works and that not works, in this sequence:

show sharing Load Sharing Monitor
Config Current Agg Ld Share Ld Share Agg Link Link Up
Master Master Control Algorithm Group Mbr State Transitions
==============================================================================
2 2 Static L3_L4 2 Y A 1
L3_L4 3 Y A 1
L3_L4 4 Y A 1
L3_L4 5 Y A 1
==============================================================================

System Type: X460-24x
Current State: OPERATIONAL
Image Selected: primary
Image Booted: primary
Primary ver: 15.6.1.4

#############################################################

27 27 Static L3_L4 27 Y A 0 L3_L4 28 Y A 0
==============================================================================

System Type: X460-24x
Current State: OPERATIONAL
Image Selected: primary
Image Booted: primary
Primary ver: 15.6.1.4
So, the ports 47 and 48 are the VPLS service ports connected to the Juniper devices right? If that is true, the fields that would be used by switch for hashing would be the source-mac-addresses and destination-mac-addresses (only L2 fields).

If it is only VPLS service traffic flowing out of these ports to the Juniper devices, the only option would be to use the L2 algorithm rather than L3. But if there is not a lot of source and destination mac address variation, this may not help.

If the traffic is coming into the switch through multiple ports, we could give port-based sharing a try.
See topology below:



As julian said, there's no MPLS configured between the switch B and the router or whatever other equipment in other side.
Userlevel 4
So, the ports 47 and 48 are the VPLS service ports connected to the Juniper devices right? If that is true, the fields that would be used by switch for hashing would be the source-mac-addresses and destination-mac-addresses (only L2 fields).

If it is only VPLS service traffic flowing out of these ports to the Juniper devices, the only option would be to use the L2 algorithm rather than L3. But if there is not a lot of source and destination mac address variation, this may not help.

If the traffic is coming into the switch through multiple ports, we could give port-based sharing a try.
Hey Julian and Douglas,

I am curious if you have tested with other algorithms beside L3_L4? What are the results with just static L2 algorithm? On the x460 you can also create a custom hash algorithm and change the addressed based algorithm from default xor to crc-16.The xor hash algorithm guarantees that the same egress port is selected for traffic distribution based on a pair of IP addresses, Layer4 ports, or both, regardless of which is the source and which is the destination. Possibly switching this to crc-16 could help you out

Below is the command:

configure sharing addressed-based custom hash-algorithm

configure sharing address-based custom ipv4 [i]

Again, the best algorithm for the most even distribution really depends on the traffic. This is why I recommend mirroring the traffic egressing the switch to gain a better understanding source > destination traffic we are dealing with.

I also wanted to show you an example of how different types of traffic can affect which ports traffic takes. Here is a good example on our Knowledge base of multicast traffic not being shared across a lag.

Have a look and let us know if you have any questions

http://gtacknowledge.extremenetworks.com/articles/Solution/Multicast-traffic-to-be-shared-properly-o...
So, the ports 47 and 48 are the VPLS service ports connected to the Juniper devices right? If that is true, the fields that would be used by switch for hashing would be the source-mac-addresses and destination-mac-addresses (only L2 fields).

If it is only VPLS service traffic flowing out of these ports to the Juniper devices, the only option would be to use the L2 algorithm rather than L3. But if there is not a lot of source and destination mac address variation, this may not help.

If the traffic is coming into the switch through multiple ports, we could give port-based sharing a try.
Hello Joe.

It is really the case of hash algorithm? Because on our case(Douglas) the traffic comes from only one of the interfaces and on the other comes nothing.

Reply