Showing results for 
Search instead for 
Did you mean: 

MPLS/VPN network load balancing in the core


I've an issue about cef based load-balancing in the MPLS core in MPLS/VPN environment. If you consider flow-based load balancing, the path (out interface) will be chosen based on source-destination IP address. What about in MPLS/VPN environment? The hash will be based on PE router src-dst loopback addresses, or vrf packet src-dst in P and PE router? The topology would be:


I'm interested in load balancing efficiency if I duplicate the link between P and PE routers.

Thank you for your help!



Load balancing on tag-2-tag path is the only case when an LSR may look under the label stack.

This means that your P routerfinds IP packet under all labels and computes load balancing hash from source and destination IP addresses. Note that LSR is not trying to route the packet basing on these IP addresses; routing decision is being done by analyzing MPLS label.

In fact, LSR may not even understand meaning of these IP addresses (like P router in your case may not be aware of VRF at all). It just uses IP addresses as input numbers into hash-calculating function.

Note also that not all LSRs can do such lookup and, thus, load balancing on tag2tag path will not work on some platforms. As a general rule, routers with hardware-assited forwarding will not do accurate load balancing. They may employ other techniques to achieve some degree of balancing but it may be not as good as on software-based platforms.

hope this helps.


Cisco Employee

Yes, I agree too. Second issue, from you topology the PE has two IGP's (like ospf)  paths to each remote PE.  From the point of

of  MP-iBGP you can use the "maximum-paths ibgp x"  in order to see the hash load-balanced

addessd-family ipv4 vrf test
maximum-paths ibgp 3

Sometimes is called "multi-level load-sharing" then configuring MP-iBGP multipath,

the expect bahvior is that the BGP prefix doesn't share from IGP's load sharing structure.

However, the prefix will create the own load sharing structurefor the NEXT-HOP

sharing as a round-robin fashion.

Best regards


Hello Yesua, Marcellino, and Gabor

I had also the impression that P node could inspect inside the MPLS frame to calculate an hash using IPv4 header.

However, in other threads have been reported, for example by Cisco expert Harold Ritter,  that load balancing should happen based on VPN (internal) MPLS label.

This is probably done for efficiency reasons knowing that by default Cisco PE nodes use multiple MPLS labels for multiple VRF prefixes and or next-hops (if there are also two PE-CE links in parallel two sets of labels are advertised in BGP VPNv4 address family).

Actually this come out in a thread where there were  two parallel MPLS  links and traffic was going out only one of them.

So only possible issue is if VRF site has only one subnet and only one PE-CE link there is the risk to do not use the parallel links in sending traffic to the site.

Also ibgp maximum-paths 2 inside VRF family is effective on remote PE nodes when sending traffic to a multihomed VRF site (connected to two local PE nodes).

I tested this and works well with the known trick to have PE1 and PE2 to use two different route distinguishers so that route reflector servers in the middle can propagate both VPNv4 routes.

Hope to help


Why Cisco or other vendor not develop MP-iBGP VPNv4 load balance feature (only one RD for 2 multihome remote PE)?

Giuseppe Larosa
Hall of Fame Master

Hello Ralf,

>> Why Cisco or other vendor not develop MP-iBGP VPNv4 load balance feature  (only one RD for 2 multihome remote PE)?

Probably to be compliant with current BGP and MP BGP specifications.

Using two different RDs creates two different VPNv4 prefixes and in this way RR servers in the middle propagate both advertisements, coming from the two PE nodes serving a multihomed VRF site.

This is normally used and does not cause problems.

Hope to help


Thanks for comment giuslar,
     But in my country, a lot of service provider customer ask for this feature because they already have template format for internal service assignment and dedicated 1 RD for 1 end customer VRF, in the real scanario if end customer HQ connected dual homing to 2 PEs, it will be binding in same VRF.


Giuseppe Larosa
Hall of Fame Master

Hello Ralf,

some years ago I've worked in helping to setup a SW environment for provisioning MPLS L3 VPN and we were able to handle this:

the RD field is 64 bits wide and it allows space to code the customer-id, site-id, and a little sub-code for multiple PE support

(we used the notation ASN:value and I'm referring to the 48 bit value part)

in this way we could use a distinct RD for single homed VRF site, and dual RD for multi homed VRF.

Hope to help


Thanks for your suggestion, Giuseppe
           I understand your point, but already heard some of vendor can support on this feature.


To use unique RD on PEs for load sharing in a MPLS/VPN network has a implicit condition that there is VPNV4 Route Reflector existing in the network.

MP-BGP itself can do loadsharing with BGP multipath feature with advertising different next-hop in the VPNV4 NLRI to other PEs given no RR invovled. With RR, only one best BGP path is advertised to RR clients if there is only one RD for a prefix, even BGP multipath feature has been turned on throughly. There are multip next-hop for a BGP prefix when a subnet is dual-homed to different BGP routers, and it is very common in real network for network redundancy reason.

Multiple best paths are advertised from RR to its clients when RR receives a prefix advertisment from different PE with different RD, as the VPNV4 NLRI are treated as completely different entries, not only same prefix with different next-hop.

Well, I am not sure the limit a BGP RR can only advertise 1 best path is sourced from the BGP specification or just IOS implementation. 

-- Best Regards


On the PE router you could set different types and 2 levels of load-balancing.

For instance, in case of a DUAL-homed site, subnet A prefix for VPN A could be advertised in the VPN by PE1 or PE2.

PE1 receives this prefix via eBGP session from CE1 and keep this route as best due to external state.

PE2 receives this prefix via eBGP session from CE2 and keep this route as best due to external state.


                     PE1 ---------CE1

                   /                        \

PE3----------P1                          Subnet A

                  \                           /

                     PE2----------CE2 /


Therefore from PE3 point of view, 2 routes are available assuming that IGP metric for PE3/PE1 is equal to PE3/PE2.

The a 1rst level of load-sharing can be achieve thanks to the maximum-paths ibgp number command.

2 MP-BGP routes are received on PE3:

PE3->PE1->CE1->subnet A

PE3->PE2->CE2->subnet A

To use both routes you must set the number at 2 at least : maximum-paths ibgp 2

But gess what, in the real world an MPLS backbone hardly garantee an equal IGP cost between 2 Egress PE for a given prefix.

So it is often necessary to ignore the IGP metric by adding the "unequal-cost" keyword: maximum-paths unequal-cost ibgp 2

By default the load-balancing is called "per-session": source and destination addresses are considered to choose the path and the outgoing interface avoiding reordering the packets on the target site. Overwise it is possible to use "per-packet" load-balancing.

Then a 2nd load-sharing level can occur.

For instance:


        /       \   /                \

PE3           \/                   Subnet A

       \        /  \                  /

        \ __P2__PE2__CE2

There is still 2 MP-BGP paths :

PE3->P1->PE1->CE1->subnet A

PE3->P1->PE2->CE2->subnet A

But this time for 2 MP-BGP paths 4 IGP path are available:

PE3->P1->PE1->CE1->subnet A

PE3->P1->PE2->CE2->subnet A

PE3->P2->PE1->CE1->subnet A

PE3->P2->PE2->CE2->subnet A

For a load-balancing to be active between those 4 paths, they must exist in the routing table thanks to the "maximum-path 4 "command in the IGP (ex OSPF) process.

Therefore if those 4 paths are equal-cost IGP paths then a 2nd level load-balancing is achieved. the default behabior is the same source destination mechanism to selected the "per-session" path as mentionned before.

On an LSP each LSR could use this feature.