Purpose
With RSVP LSPs, load-balancing LSP traffic using bandwidth allows uneven load balancing across multiple external links that have varying amounts of available bandwidth. When you use bandwidth to load-balance an RSVP LSP, the distribution of traffic is proportional to the bandwidth configuration of each LSP. You configure load balancing at the [edit protocols rsvp] hierarchy level on the ingress router.
For uneven load balancing using bandwidth to work, you must have at least two equal-cost LSPs toward the same egress router and at least one of the LSPs must have a bandwidth value configured at the [edit protocols mpls label-switched-path lsp-path-name] hierarchy level. If no LSPs have bandwidth configured, equal distribution load balancing is performed. If only some LSPs have bandwidth configured, the LSPs without any bandwidth configured do not receive any traffic.
Keep the following information in mind when you use the load-balance statement at the [edit protocols rsvp] hierarchy level:
Before you can use bandwidth to unevenly load-balance LSP traffic, you must have the following configured on the ingress router:
Figure 13 illustrates a network configured with RSVP bandwidth.
Figure 13: RSVP Bandwidth Network
The network topology in Figure 13 illustrates a router-only network with SONET and Ethernet interfaces that consists of the following components:
In addition, the example network uses OSPF as the IGP with OSPF area 0.0.0.0. An IGP is required for the CSPF LSP, which is the default for the JUNOS software. Also, the example network uses a policy to create BGP traffic. For the full configuration of routers in this network, see Router Configurations for Bandwidth Load Balancing.
The following information is included in this example:
Purpose
Configuring bandwidth to unevenly load-balance traffic is performed in three stages. The first stage enables a load-balancing policy, the second stage configures the LPS bandwidth, and the third stage enables RSVP load balancing.
Action
To configure bandwidth to unevenly load-balance RSVP LSPs, follow these steps:
Sample Output
user@R1> edit
Entering configuration mode
[edit]
user@R1# edit protocols mpls
[edit protocols mpls]
user@R1# set label-switched-path lsp1 bandwidth 10m
[edit protocols mpls]
user@R1# show
label-switched-path lsp1 {
to 192.168.0.1;
install 10.0.90.14/32 active;
bandwidth 10m;
primary via-r4;
[edit protocols mpls]
user@R1# top
[edit]
user@R1# edit protocols rsvp
[edit protocols rsvp]
user@R1# set load-balance bandwidth
[edit protocols rsvp]
user@R1# show
load-balance bandwidth;
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
[edit protocols rsvp]
user@R1# commit
commit complete
Meaning
The sample output shows the configuration of LSP bandwidth and RSVP bandwidth on ingress router R1. The sample output shows only one LSP configured with bandwidth, however, for RSVP bandwidth to work, you must have at least two equal-cost LSPs toward the same egress router and at least one of the LSPs must have a bandwidth value configured. If no LSPs have bandwidth configured, equal-distribution load balancing is performed. If only some LSPs have bandwidth configured, the LSPs without any bandwidth configured do not receive any traffic.
When a router is performing unequal-cost load balancing between LSPs paths, the show route detail command displays a balance field associated with each next hop being used.
To verify that an RSVP LSP is unevenly load-balanced, use the following JUNOS CLI operational mode commands:
user@R1> show route protocol rsvp detail
inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
10.0.90.14/32 (1 entry, 1 announced)
State: <FlashAll>
*RSVP Preference: 7
Next-hop reference count: 7
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 10%
Label-switched-path lsp1
Label operation: Push 100768
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 20%
Label-switched-path lsp2
Label operation: Push 100736
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 30%,
selected
Label-switched-path lsp3
Label operation: Push 100752
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 40%
Label-switched-path lsp4
Label operation: Push 100784
State: <Active Int>
Local AS: 65432
Age: 8:03 Metric: 4
Task: RSVP
Announcement bits (2): 0-KRT 4-Resolve tree 1
AS path: I
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
192.168.0.1/32 (1 entry, 1 announced)
State: <FlashAll>
*RSVP Preference: 7
Next-hop reference count: 7
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 10%
Label-switched-path lsp1
Label operation: Push 100768
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 20%
Label-switched-path lsp2
Label operation: Push 100736
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 30%
Label-switched-path lsp3
Label operation: Push 100752
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 40%, selected
Label-switched-path lsp4
Label operation: Push 100784
State: <Active Int>
Local AS: 65432
Age: 8:03 Metric: 4
Task: RSVP
Announcement bits (1): 1-Resolve tree 1
AS path: I
user@R1> show mpls lsp statistics
Ingress LSP: 4 sessions
To From State Packets Bytes LSPname
192.168.0.1 192.168.1.1 Up 10067 845628 lsp1
192.168.0.1 192.168.1.1 Up 20026 1682184 lsp2
192.168.0.1 192.168.1.1 Up 29796 2502864 lsp3
192.168.0.1 192.168.1.1 Up 40111 3369324 lsp4
Total 4 displayed, Up 4, Down 0
Egress LSP: 1 sessions
To From State Packets Bytes LSPname
192.168.1.1 192.168.0.1 Up NA NA r0-r1
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
The sample output from ingress router R1 shows that traffic is distributed according to the LSP bandwidth configuration, as indicated by the Balance: xx% field. For example, lsp1 has 10 Mbps of bandwidth configured, as reflected in the Balance: 10% field.
