Load-balancing traffic over RSVP-based MPLS Label-switched paths (LSPs)

Description

This KB provides an example on how to configure RSVP-based MPLS LSPs to load-balance traffic.

Symptoms

The diagram below will be used in this example; note the names of the devices are Chewie, Unabomber, and Snickers.

alt
Load-balancing RSVP-based MPLS LSPs requires configuration of the hash-key feature.

Solution

The following configuration is added to the ingress router, Chewie:

forwarding-options {
    hash-key {
        family mpls {
            label-1;
            label-2;
            payload {
                ip;
            }
        }
    }
}

Configurations for all routers:

lab@Chewie> show configuration | no-more
interfaces {
    t1-2/0/0 {
        unit 0 {
            family inet {
                address 2.2.2.1/30;
            }
            family mpls;
        }
    }
    t1-2/0/1 {
        unit 0 {
            family inet {
                address 1.1.1.1/30;
            }
            family mpls;
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 10.1.1.1/32;
            }
        }
    }
}
forwarding-options {
    hash-key {
        family mpls {
            label-1;
            label-2;
            payload {
                ip;
            }
        }
    }
}
routing-options {
    static {
	/* Optional: Allows Chewie to use the LSP's as a next-hop for pings to 10.1.1.3; otherwise only BGP routes with a next-hop of 10.1.1.3 will use the LSP's */
        route 10.1.1.3/32 {
            lsp-next-hop north;
            lsp-next-hop south;
        }
    }
    forwarding-table {
        export load-balance;
    }
}
protocols {
    rsvp {
        interface t1-2/0/1.0;
        interface t1-2/0/0.0;
    }
    mpls {
	/* This is required since the OSPF Traffic Engineering database isn't enabled */
	no-cspf;
	no-decrement-ttl;
        label-switched-path north {
            to 10.1.1.3;
            primary north;
        }
        label-switched-path south {
            to 10.1.1.3;
            primary south;
        }
        path north {
            1.1.1.2;
        }
        path south {
            2.2.2.2;
        }
        interface t1-2/0/0.0;
        interface t1-2/0/1.0;
    }               
    ospf {
        area 0.0.0.0 {
            interface t1-2/0/0.0;
            interface t1-2/0/1.0;
            interface lo0.0;
        }
    }
}
policy-options {
    policy-statement load-balance {
        then {
            load-balance per-packet;
        }
    }
}

lab@Unabomber> show configuration | no-more 
interfaces {
    e1-2/0/0 {
        unit 0 {
            family inet {
                address 3.3.3.2/30;
            }
            family mpls;
        }
    }
    t1-6/0/0 {
        unit 0 {
            family inet {
                address 2.2.2.2/30;
            }
            family mpls;
        }
    }
    t1-6/0/1 {
        unit 0 {
            family inet {
                address 1.1.1.2/30;
            }
            family mpls;
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 10.1.1.2/32;
            }
        }
    }
}
protocols {
    rsvp {
        interface t1-6/0/1.0;
        interface t1-6/0/0.0;
        interface e1-2/0/0.0;
    }
    mpls {
        interface t1-6/0/0.0;
        interface t1-6/0/1.0;
        interface e1-2/0/0.0;
    }
    ospf {
	area 0.0.0.0 {
            interface t1-6/0/0.0;
            interface t1-6/0/1.0;
            interface lo0.0;
            interface e1-2/0/0.0;
        }
    }
}

lab@Snickers> show configuration | no-more 
interfaces {
    e1-2/0/0 {
        unit 0 {
            family inet {
                address 3.3.3.1/30;
            }
            family mpls;
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 10.1.1.3/32;
            }
        }
    }
}
protocols {
    rsvp {
        interface e1-2/0/0.0;
    }
    mpls {
        interface e1-2/0/0.0;
    }
    ospf {
        area 0.0.0.0 {
            interface lo0.0;
            interface e1-2/0/0.0;
        }
    }
}

The LSPs are up:

lab@Chewie> show mpls lsp 
Ingress LSP: 2 sessions
To              From            State Rt ActivePath       P     LSPname
10.1.1.3        10.1.1.1        Up     0 north            *     north
10.1.1.3        10.1.1.1        Up     0 south            *     south
Total 2 displayed, Up 2, Down 0

There are static and OSPF routes to Snickers:

lab@Chewie> show route 10.1.1.3 
inet.0: 15 destinations, 18 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.1.1.3/32        *[Static/5] 00:06:56
                    > via t1-2/0/1.0, label-switched-path north
                      via t1-2/0/0.0, label-switched-path south
                    [OSPF/10] 00:07:01, metric 115
                    > via t1-2/0/0.0
                      via t1-2/0/1.0
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.1.1.3/32        *[RSVP/7] 00:06:56, metric 65535
                    > via t1-2/0/1.0, label-switched-path north
                      via t1-2/0/0.0, label-switched-path south

The forwarding table has two next-hops:

lab@Chewie> show route forwarding-table destination 10.1.1.3 
Routing table: inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
10.1.1.3/32        user     0                    ulst 262143     1
                                                Push 299824       t1-2/0/1.0
                                                Push 299808       t1-2/0/0.0

The no-decrement-tll switch confirms that traffic is using the LSP:

lab@Chewie> traceroute 10.1.1.3 source 10.1.1.1 
traceroute to 10.1.1.3 (10.1.1.3) from 10.1.1.1, 30 hops max, 40 byte packets
 1  10.1.1.3 (10.1.1.3)  6.120 ms  5.239 ms  5.728 ms

The output below verifies that the LSPs are load-balanced. Start with 0 packets:

lab@Unabomber> show mpls lsp statistics     
Transit LSP: 2 sessions
To              From            State     Packets            Bytes LSPname
10.1.1.3        10.1.1.1        Up              0                0 north
10.1.1.3        10.1.1.1        Up              0                0 south
Total 2 displayed, Up 2, Down 0

Sent 10 packets into the LSP's:

lab@Chewie> ping 10.1.1.3 count 10 rapid 
PING 10.1.1.3 (10.1.1.3): 56 data bytes
!!!!!!!!!!
--- 10.1.1.3 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.979/5.290/5.756/0.216 ms

The 10 packets are split evenly across the LSPs:

lab@Unabomber> show mpls lsp statistics    
Transit LSP: 2 sessions
To              From            State     Packets            Bytes LSPname
10.1.1.3        10.1.1.1        Up              5              440 north
10.1.1.3        10.1.1.1        Up              5              440 south
Total 2 displayed, Up 2, Down 0

Note: It's likely that the load balancing will not be symmetrical, due to the fact that transit traffic is load-balanced in a per-flow fashion. Some traffic flows may carry higher amounts of traffic than others.

Description

Symptoms

Solution

Related Information