cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2110
Views
0
Helpful
5
Replies

MPLS and equal-cost routes

Kevin Dorrell
Level 10
Level 10

Suppose I have a network on R4.  Suppose R4 is connected to R2 and R3 via equal cost links, and R2 and R3 are connected to R1, again by equal cost links.  (We have a squareThe LIB on R1 will contain (amongst others) two entries for the prefix, one with a label from R2 and one with a label from R3. The RIB on R1 will contain two equal-cost routes.

My question is: which entry makes it to the LFIB, or do both of them make it? If so, how is the traffic for the prefix distributed between the two links R2/R3?

Supplementary question: If it does distribute traffic between equal cost routes, does that mean the arrival order of the packets is not necessarily preserved? Suppose I am emulating a layer-2 connection across the MPLS cloud ... does that not need the packet order to be preserved?

Thanks is advance.

Kevin Dorrell

Luxembourg (normally)

London (this week, on training)

1 Accepted Solution

Accepted Solutions

Hello Kevin,

even in MPLS scenario traffic is load balanced per flow not per packet using an hash of internal fields IP SA and IP DA when the MPLS payload is IP.

this means that even if for routing purposes the inner IP header is not examined by a LSR router inside the MPLS cloud some hash operations are performed in order to choice a path for a flow.

We tested this several years ago for IP traffic over MPLS LSPs with traffic generators and several routers with two equal cost paths to destination.

For L2 services in some scenarios absence of load balancing is observed if the pseudowire is unique ( that is the inner label is the same, the one related to the service).

Edit:

a reference to a thread where Cisco expert Harold Ritter explains load balancing on inner label value for L2 services

https://supportforums.cisco.com/message/963873#963873

if I remember correctly I tested this and traffic of a specific pseudowire use a single path and it is not load balanced. There was also some thread in MPLS forum about this behaviour.

Multiple pseudowires between the same PE nodes ( for example Vlan based) are possible and can take different paths if available in the network topology because each of them uses a different inner (service) label value.

Hope to help

Giuseppe

View solution in original post

5 Replies 5

Marwan ALshawi
VIP Alumni
VIP Alumni

Hi Kevin,

as per Ciscopress:

Load Balancing Labeled Packets
If multiple equal-cost paths exist for an IPv4 prefix, the Cisco IOS can load-balance labeled packets, as illustrated in the Cisco IOS output of Example 3-6. You can see that the incoming/local labels 17 and 18 have two outgoing interfaces. If labeled packets are load-balanced, they can have the same outgoing labels, but they can also be different. The outgoing labels are the same if the two links are between a pair of routers and both links belong to the platform label space. If multiple next-hop LSRs exist, the outgoing label for each path is usually different, because the next-hop LSRs assign labels independently.

http://www.ciscopress.com/articles/article.asp?p=680824

hope this help

Thank you, that is an interesting article.  It brings up a couple of interesting points though:

  1. I notice that the remote tag was the same for both paths.  That probably (but not necessarily) means that both paths went to the same router, so we have two parallel lines between the two routers.  I am also interested in the situation where we have equal-cost paths to two different routers, in which case the remote tags are probably going to be different.  The text does say as much.
  2. It is intersting to notice that the byte counts switched on the two lines are decidedly uneven. Since the destination prefix is the same, if I were using normal routing I would expect them to be more evenly distributed.  I wonder why they are like that.
  3. I still have a problem wondering whether such a set-up could affect the arrival order of packets, which might mess up some layer-2 emulation applications.

Kevin Dorrell

Luxembourg / London

Hello Kevin,

even in MPLS scenario traffic is load balanced per flow not per packet using an hash of internal fields IP SA and IP DA when the MPLS payload is IP.

this means that even if for routing purposes the inner IP header is not examined by a LSR router inside the MPLS cloud some hash operations are performed in order to choice a path for a flow.

We tested this several years ago for IP traffic over MPLS LSPs with traffic generators and several routers with two equal cost paths to destination.

For L2 services in some scenarios absence of load balancing is observed if the pseudowire is unique ( that is the inner label is the same, the one related to the service).

Edit:

a reference to a thread where Cisco expert Harold Ritter explains load balancing on inner label value for L2 services

https://supportforums.cisco.com/message/963873#963873

if I remember correctly I tested this and traffic of a specific pseudowire use a single path and it is not load balanced. There was also some thread in MPLS forum about this behaviour.

Multiple pseudowires between the same PE nodes ( for example Vlan based) are possible and can take different paths if available in the network topology because each of them uses a different inner (service) label value.

Hope to help

Giuseppe

Marwan ALshawi
VIP Alumni
VIP Alumni

Ok I would say a lab test is recommended since you know the concept

Sent from Cisco Technical Support iPhone App

maayre
Level 1
Level 1

Pretty much all routers and switches use some kind of source-destination hashing (and other fields too) to chose one of the many equal cost paths. This achieves "statistical distribution" which is why in corner cases without lot of unique sources and destinations it may not appear balanced.

You would only ever worry about packet order if you had configured per-packet load balancing which is off by default on every platform I've ever seen for this exact reason.

Review Cisco Networking for a $25 gift card