L2VPN(VPLS-VPWS) load-balance between multiple links

[Amirmahdi.M]

Hi everobody

I've been wondering if there is a way to load balance the traffic of an l2vpn.

for example here is the secanrio:

CE1 ---- PE1 ===== MPLS Network ===== PE2 ---- CE2

---- One Link 

==== Two Links

then i configure an xconnect between the PEs, the traffic only goes through one link.

i can verify that it by entering "show mpls l2 vc [id] detail" and it only shows one nexthop.

even if i enter "show ip route [PE IP]" or show "ip cef [PE IP]" it shows me multiple paths.

Is it possible to load balance the traffic between 2 or more links? (like cef per packet balancing or something)

Thanks Amir

[MHM Cisco World]

Sure' if the two link is appear both in RIB of PE1 and PE2 then mpls will add two label and the mpls will use both label to forward traffic.

Only check RIB in PE's.

Thanks A Lot
MHM

[Amirmahdi.M]

Hi @MHM Cisco World 

I attached the log of my PE router but it looks like the traffic is only going through Te0/3/4(10.18.105.105).

i can verify it by looking at Zabbix's graph of the interfaces.

also the label stack of the l2vpn uses label 586 which is used for Te0/3/4.

Any ideas?

Thanks

Amir

[MHM Cisco World]

PE1.ROU#show ip cef 10.18.73.12
10.18.73.12/32
  nexthop 10.18.94.61 TenGigabitEthernet0/0/0 label 742()
  nexthop 10.18.105.105 TenGigabitEthernet0/3/4 label 586()
PE1.ROU#show mpls for 10.18.73.12
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
793        742        10.18.73.12/32  0             Te0/0/0    10.18.94.61
           586        10.18.73.12/32  0             Te0/3/4    10.18.105.105

 there is two path and two label as I mention before,
one via Te0/0/0 and other via Te0/3/4 
but it seem that CEF use only one interface TE0/3/4
I will check and update you how we can solve this. 

Thanks A Lot
MHM

[MHM Cisco World · Accepted solution]

 load-balance flow <<- add this under psudo class 

[Harold Ritter · Accepted solution]

Hi @Amirmahdi.M ,

The lack of load balancing capability is a known issue with L2VPN. The way to fix it is to add an entropy label (RFC6790) to each flow so that it can be load balanced properly. 

One way to do this is to enable the mpls ldp entropy label support on the PEs. This depends on this feature being supported on the PE. 

What OS and versions are your PEs currently running?

MPLS LDP Entropy Label Support:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_ldp/configuration/xe-16/mp-ldp-xe-16-book/mp-ldp-entropy.html#:~:text=Benefits%20of%20MPLS%20LDP%20Entropy%20Label%20Support,-Each%20transit%20LSR&text=If%20the%20transit%20LSR%20is,cost%20paths%20....

Regards,

[Amirmahdi.M]

Hi @Harold Ritter ,

Do you have any info or document about ASR920 supporting the entropy label feature at any version?

it does seem to have the command at cli but i dont know if it actualy supports it. like actualy working.

Thanks

Amir

[Amirmahdi.M]

Hi @Harold Ritter 

Thanks for your reply. I will definatley read about the entropt label and its features.

Do both PEs need to have the entropy label added or can it be configured only in one direction?

our PEs are mostly asr903 or asr1000 series.

these are model and image that they usually have:

ASR-903 (RSP3_400)
'asr900rsp3-universalk9.03.18.00.SP.156-2.SP-ext'
'asr900rsp3-universalk9_npe.03.18.03.SP.156-2.SP3-ext'

ASR1002-X (2RU-X)
'asr1002x-universalk9.03.13.03.S.154-3.S3-ext.SPA.bin'

Thanks

Amir

[Harold Ritter · Accepted solution]

Hi @Amirmahdi.M ,

> Do both PEs need to have the entropy label added or can it be configured only in one direction?

The mpls ldp entropy label is enabled on the egress PE. Both PEs terminating the xconnect would act as ingress/egress PEs for the pseudowire. You could enable the feature only in one direction but proper load balancing would only happen in that direction.

Bear in mind that using the entropy label will add 2 labels to the label stack (entropy label indicator (label value = 7) + actual entropy label). This needs to be taken in consideration for the core MTU. This might not be an issue if your core MTU is already way larger than the MTU on the service interfaces.

The platforms and software versions you are using should be fine.

Regards,