SYSTEM ADMINISTRATOR GUIDE     79/1543-CRA 119 1170/1-V1 Uen A    

Load Balancing

© Copyright Ericsson AB 2009. All rights reserved.

Disclaimer

No part of this document may be reproduced in any form without the written permission of the copyright owner. The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List

SmartEdge is a registered trademark of Telefonaktiebolaget L M Ericsson.
NetOp  is a trademark of Telefonaktiebolaget L M Ericsson.

Contents

1Load-Balancing Operations
1.1Load Balancing for Each Link Group
1.2Load Balancing for Each Configuration
1.3Load Balancing for Each Traffic Source

2

Load-Balancing Commands


1   Load-Balancing Operations

This section describes how to enable, monitor, and administer load balancing of traffic on the SmartEdge router.

1.1   Load Balancing for Each Link Group

Some link groups do not support load balancing, such as the access link group. Traffic in an access link group is distributed among the active ports but is not load balanced. Circuits in the link bundle are assigned group IDs and distributed per group ID (not by source and destination address as in load balancing) so that all traffic in the same group goes through the same port. This section describes load balancing link groups support.

Load balancing is supported by the following link-group types:

Note:  
If the packets are coming from a routed domain and going to an L2 domain through a BVI port, and if an ether or a dot1q link-group is part of the bridge group associated with the BVI port, either Layer 3 or Layer 4 (five-tuple hashing) load balancing can be used.

1.2   Load Balancing for Each Configuration

Certain configurations affect load balancing. For example, the following types of configurations change the load-balancing behavior:

To enable load-balancing, perform the appropriate task listed in Table 1 (For information on the commands used to do these tasks, see the Command List). Enter the service load-balance, pseudowire multi-path, and ecmp-transit commands in global configuration mode; enter the show commands in any mode.

Table 1    Load Balancing Tasks

Task

Command

Enable Layer 3 load balancing.

service load-balance ip layer-3

Enable Layer 3 and Layer 4 load balancing.

service load-balance ip layer-4

Enable pseudowire multi-path load balancing.

pseudowire multi-path (L2VPN)

Enable ECMP load balancing.

ecmp-transit

Display whether Layer 4 load balancing is enabled.

show ip route summary

Display whether pseudowire multi-path load balancing is enabled.

show pseudowire

Display whether ecmp-transit load balancing is enabled.

show configuration ldp

1.3   Load Balancing for Each Traffic Source

The following tables are divided by load balancing for traffic on the Ingress Edge Router and P (transit), meaning the Provider Label Switch Router in the center of a Multiprotocol Label Switching (MPLS) network (this router is not a PE router, this router gets routes from a third party that is not in the VPN, and this router gives those routes to a PE router). The tables show how load balancing is accomplished depending on the source of the traffic flow and applications, traffic type, paths, link groups, and other aspects of the configuration described in the legend.

The following tables show that the traffic load balancing is completed in the same manner for the following applications for all paths:

Following is the legend for the numbers used (Legend: n) in Table 2, Table 3, Table 4, and Table 5:

1. Multiple single physical links.

2. One path is a link group (dot1q, ether, or hdlc) with more than one physical links. The LG is treated as a single link first, and load-balancing first uses the method in Legend: 1. Then, distribution among LG members uses the method in Legend: 3.

3. The path is a link-group (dot1q, ether, or hdlc) with more than one member, and the load is distributed among group members.

4. If 5-tuple hashing is configured, load balancing is based on ip src, dst, ip protocol, udp/tcp src port, and dst port.

5. If queuing is enabled on a L2TP network server (LNS), the virtual node ID is used for load balancing. If L2TP ECMP is not enabled, the LNS uses inner ip src + dst for load balancing. (Only for ingress PE: The L2TP access concentrator (LAC) uses outer ip src + dst for load balancing.)

6. For P (transit): If the first nibble following the MPLS label stack is 0x4 or 0x6, it is treated respectively as an IPv4 or IPv6 payload.

Table 2    Ingress Edge Router without pseudowire multi-path

Applications

Traffic Type

Ingress Edge Router without pseudowire multi-path

Multiple Paths Legend: 1

Multiple Paths + LG
Legend: 2

LG
Legend: 3

Plain IP

IP

ip src + dst
Legend: 4

ip src + dst
Legend: 4

ip src + dst
Legend: 4

GRE with
IP over IP

IP

inner ip src + dst Legend: 4

inner ip src + dst
Legend: 4

inner ip src + dst Legend: 4

Soft GRE

IP

inner ip src + dst Legend: 4

inner ip src + dst
Legend:4

inner ip src + dst Legend: 4

IP-based MPLS (L3VPN)

IP

ip src + dst
Legend: 4

ip src + dst
Legend: 4

ip src + dst
Legend: 4

VPLS

L2 Ethernet or other

inner label

inner label

inner label

L2VPN

L2 Ethernet or other

inner label

inner label

inner label

L2TP

any

tunnel + session id Legend: 5

tunnel + session id Legend: 5

tunnel + session id Legend: 5

L2 Bridge

L2 Ethernet

NA

NA

src + dst mac

Table 3 shows how the addition of pseudowire multi-path configuration changes the information that is used by the load balancing hash algorithm for VPLS and L2VPN applications:

Table 3 shows that the addition of pseudowire multi-path configuration does not change the information that is used by the load balancing hash algorithm for the other applications.

Table 3    Ingress Edge Router with pseudowire multi-path

Applications

Traffic Type

Ingress Edge Router with pseudowire multi-path

Multiple Paths Legend: 1

Multiple Paths + LG Legend: 2

LG
Legend: 3

Plain IP

IP

ip src + dst
Legend: 4

ip src + dst
Legend: 4

ip src + dst
Legend: 4

GRE with
IP over IP

IP

inner ip src + dst Legend: 4

inner ip src + dst
Legend: 4

inner ip src + dst Legend: 4

Soft GRE

IP

inner ip src + dst Legend: 4

inner ip src + dst
Legend: 4

inner ip src + dst Legend: 4

IP-based MPLS (L3VPN)

IP

ip src + dst
Legend: 4

ip src + dst
Legend: 4

ip src + dst
Legend: 4

VPLS

L2 Ethernet (_next_header is IP)

ip src + dst
Legend: 4

ip src + dst
Legend: 4

ip src + dst
Legend: 4

L2 Ethernet (_next_header is not IP)

src + dst mac

src + dst mac

src + dst mac

Other

inner label

inner label

inner label

L2VPN

L2 Ethernet (_next_header is IP)

ip src + dst
Legend: 4

ip src + dst
Legend: 4

ip src + dst
Legend: 4

L2 Ethernet (_next_header is not IP)

src + dst mac

src + dst mac

src + dst mac

Other

inner label

inner label

inner label

L2TP

any

tunnel + session id Legend: 5

tunnel + session id Legend: 5

tunnel + session id Legend: 5

L2 Bridge

L2 Ethernet

NA

NA

src + dst mac

Table 4 shows how P (transit) load balancing is the same for all applications with or without pseudowire multi-path, but the hash algorithm is different for non IP traffic:

Table 4    P (transit) with or without pseudowire multi-path

Applications

Traffic Type

P (transit) with or without pseudowire multi-path

Multiple Paths Legend: 1

Multiple Paths + LG Legend: 2

LG
Legend: 3

All

IP
Legend: 6

ip src + dst
Legend: 4

ip src + dst
Legend: 4

ip src + dst
Legend: 4

non IP
Legend: 6

entire label stack
+ incoming slot/port

entire label stack
+ incoming slot/port

entire label stack
+ incoming slot/port

Table 5 is a detailed version of Table 4.

Table 5    P (transit) with or without pseudowire multi-path Detailed

Applications

Traffic Type

P (transit) with or without pseudowire multi-path Detailed

Multiple Paths Legend: 1

Multiple Paths + LG Legend: 2

LG
Legend: 3

Plain IP

IP

ip src + dst
Legend: 4

ip src + dst
Legend: 4

ip src + dst
Legend: 4

GRE with
IP over IP

IP

inner ip src + dst Legend: 4

inner ip src + dst Legend: 4

inner ip src + dst Legend: 4

Soft GRE

IP

ip src + dst

ip src + dst

ip src + dst

IP-based MPLS (L3VPN)

IP

ip src + dst
Legend: 4

ip src + dst
Legend: 4

ip src + dst
Legend: 4

VPLS

L2 Ethernet (_next_header is IP)

ip src + dst
Legend: 4

ip src + dst
Legend: 4

ip src + dst
Legend: 4

L2 Ethernet (_next_header is not IP)

entire label stack
+ incoming slot/port

entire label stack
+ incoming slot/port

entire label stack
+ incoming slot/port

Other

entire label stack
+ incoming slot/port

entire label stack
+ incoming slot/port

entire label stack
+ incoming slot/port

L2VPN

L2 Ethernet (_next_header is IP)

ip src + dst
Legend: 4

ip src + dst
Legend: 4

ip src + dst
Legend: 4

L2 Ethernet (_next_header is not IP)

entire label stack
+ incoming slot/port

entire label stack
+ incoming slot/port

entire label stack
+ incoming slot/port

Other

entire label stack
+ incoming slot/port

entire label stack
+ incoming slot/port

entire label stack
+ incoming slot/port

L2TP

any

tunnel + session id Legend: 5

tunnel + session id Legend: 5

tunnel + session id Legend: 5

L2 Bridge

L2 Ethernet

NA

NA

src + dst mac

2   Load-Balancing Commands

This following list provides references to the documentation that describes the syntax and usage guidelines for the commands used to enable load balancing and to show whether load balancing is enabled:

For more information on pseudowire multi-path load balancing, see the Enabling Load Balancing on Pseudowires section in Configuring L2VPN and the pseudowire multi-path command. For more information on Layer 3 and Layer 4 load balancing, see the Layer 3 and Layer 4 Load Balancing section in Configuring Basic IP Routing and the service load-balance ip command. For more information on ECMP load balancing, see the Configuring an LDP Routing Instance section in Configuring LDP and the ecmp-transit command.