Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

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

0

0

Article ID: KB12995 KB Last Updated: 07 May 2009Version: 1.0
Summary:
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.


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.

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search