resolving routes for mpls traffic engineering

8/3/2019 Resolving Routes for MPLS Traffic Engineering

1/37

White Paper

Resolving Routes for

MPLS Traffic Engineering

Jeff DoyleProfessional Services Engineer

Juniper Networks, Inc.

1194 North Mathilda Avenue

Sunnyvale, CA 94089 USA

408 745 2000 or 888 JUNIPER

www.juniper.net

Part Number: 200008-001 11/00


2/37

Copyright 2000, Juniper Networks, Inc.

Contents

Executive Summary ............................................................................................................................ 3Demonstration Network Overview.................................................................................................. 4Routing Information Databases......................................................................................................... 7Using traffic-engineering bgp.......................................................................................................... 11Using IGP Shortcuts.......................................................................................................................... 16Using traffic-engineering bgp-igp................................................................................................... 22Installing Single Prefixes .................................................................................................................. 28Appendix A........................................................................................................................................ 31

RTR1........................................................................................................................................... 31RTR2........................................................................................................................................... 32RTR3........................................................................................................................................... 33RTR4........................................................................................................................................... 34RTR5........................................................................................................................................... 35RTR6........................................................................................................................................... 35RTR7........................................................................................................................................... 36

Acronyms ........................................................................................................................................... 37

List of Figures

Figure 1:Demonstration Network Physical and Logical Topology ................................................4Figure 2:Demonstration Network BGP Topology ............................................................................5Figure 3:Demonstration Network LSP Topology .............................................................................6Figure 4:By Default, BGP Uses Both inet.0 and inet.3 ....................................................................11Figure 5:IGP Shortcuts Allow the IGP to Install Prefixes in inet.3 ...............................................18Figure 6:The traffic-engineering bgp-igp Command Causes RSVP to

Install Prefixes into inet.0 ...................................................................................................22

List of Tables

Table 1: Routing Tables for MPLS Traffic Engineering Route Resolution..................................7


3/37

Copyright 2000, Juniper Networks, Inc. 3

Executive Summary

Multiprotocol Label Switching (MPLS) traffic engineering maps certain data flows toestablished label switched paths (LSPs) rather than to data links calculated by the IGP to be

part of the best (shortest) path. Fundamental to this function is the determination of whattraffic is to be mapped to an LSP.

Traffic is mapped to an LSP at the tunnel's ingress label switching router (LSR) by designatingthe egress LSR as the next-hop router for certain destination prefixes. It is important to

understand that the LSP does not constitute an entire route to a destination. Rather, the LSP isa next-hop segment of the route. Therefore, packets can only be mapped to an LSP if theegress LSR is considered to be a feasible next-hop candidate during the route resolution

process. This paper explains the various options available with Juniper Networks JUNOS

Internet software for including LSPs in the route resolution process.

This paper assumes that you understand the basics of MPLS and the JUNOS command-lineinterface.


4/37

Resolving Routes for MPLS Traffic Engineering

4 Copyright 2000, Juniper Networks, Inc.

Demonstration Network Overview

The same network topology is used for all of the route resolution examples. This section

provides reference diagrams necessary for the understanding of the examples that arepresented in subsequent sections.

Figure 1 shows the routers, router names, physical connections, and IP addresses used in thenetwork. There are two autonomous systems and seven routers: RTR1 through RTR7. The

loopback interface addresses serve as the OSPF and BGP router IDs, and as the endpoints forIBGP and LSP connections, where appropriate.

Figure 1: Demonstration Network Physical and Logical Topology

192.168.2.1

192.168.2.2 192.168.4.2

192.168.4.1

192.168.1.2

192.168.1.1

192.168.3.2192.168.3.1

192.168.5.2

192.168.5.1

192.168.6.2

192.168.6.1

172.16.1.1192.168.7/24

192.168.8/24

172.16.1.2

RTR1Lo0: 192.168.254.1

RTR5Lo0: 192.168.254.5

RTR2

Lo0: 192.168.254.2RTR3

Lo0: 192.168.254.3

RTR6Lo0: 192.168.254.6

RTR4Lo0: 192.168.254.4

RTR7Lo0: 192.168.254.1

AS 65501

AS 65520

192.168.9/24

Prefixes

10.1.0.0/1610.2.0.0/16


5/37



The IGP used in AS 65501 is OSPF, and all internal interfaces are in area 0. The externalinterface at RTR4 linking to AS 65520 does not run OSPF. Figure 2 shows the logical BGP

topology. A full IBGP mesh is configured within AS 65501, linking all routers except RTR6. NoBGP runs on that router. An EBGP connection links RTR4 in AS 65501 with RTR7 in AS 65520.

The endpoints of the EBGP connection are the external physical interfaces of the two routers.

Figure 2: Demonstration Network BGP Topology

RTR1Lo0: 192.168.254.1

RTR5Lo0: 192.168.254.5

RTR2Lo0: 192.168.254.2

RTR3Lo0: 192.168.254.3

RTR6Lo0: 192.168.254.6

RTR4Lo0: 192.168.254.4

RTR7Lo0: 192.168.254.1

Full IBGP Mesh

EBGP

No BGP


6/37



A single LSP, named test_path, is configured from RTR1 to RTR4, as depicted in Figure 3. TheLSP Explicit Route Object (ERO) is specified to use a strict hop through RTR2, so that the LSP

takes a different path from the OSPF shortest path of RTR1-RTR5-RTR4. The LSP is signaledusing RSVP, but no CSPF is running.

Figure 3: Demonstration Network LSP Topology

RTR1

Ingress Egress

LSP test_path

Lo0: 192.168.254.1 RTR5Lo0: 192.168.254.5

RTR2Lo0: 192.168.254.2 RTR3Lo0: 192.168.254.3

RTR6Lo0: 192.168.254.6RTR4Lo0: 192.168.254.4

RTR7Lo0: 192.168.254.1

AS 65501

AS 65520

Refer to Appendix A for the base routing options, policy, and protocol configurations for all

seven routers.


7/37



Routing Information Databases

JUNOS software maintains several routing tables from which best-path information is

extracted and added to the forwarding table. Both the maintenance and use of the routingtables is protocol dependent. The routing tables relevant to MPLS traffic engineering route

resolution are inet.0, inet.3, and mpls.0.

Table 1: Routing Tables for MPLS Traffic Engineering Route Resolution

Routing Table Type Description

inet.0 Unicast routing table All unicast protocols enter their routeinformation into this table.

inet.3 MPLS routing table RSVP enters destinations reachablevia LSPs into this table; thesedestination prefixes are always the IPaddresses of LSP egress points.

mpls.0 MPLS switching table MPLS enters label bindings into thistable, and uses the information toswitch incoming MPLS-labeled packetsto outgoing interfaces.


8/37



With the default configurations listed in Appendix A running, RTR1's three routing tables areas follows.

jeff@RTR1> show routeinet.0: 20 destinations, 20 routes (18 active, 0 holddown, 2 hidden)+ = Active Route, - = Last Active, * = Both192.168.1.0/24 *[Direct/0] 17:34:14

> via fxp0.0192.168.1.1/32 *[Local/0] 17:34:14

Local192.168.2.0/24 *[Direct/0] 17:34:14

> via fxp1.0192.168.2.1/32 *[Local/0] 17:34:14

Local192.168.3.0/24 *[OSPF/10] 17:33:27, metric 2

> to 192.168.1.2 via fxp0.0192.168.4.0/24 *[OSPF/10] 17:33:22, metric 2


to 192.168.1.2 via fxp0.0> to 192.168.2.2 via fxp1.0

192.168.6.0/24 *[OSPF/10] 17:33:22, metric 3> to 192.168.2.2 via fxp1.0




192.168.254.1/32 *[Direct/0] 17:34:14> via lo0.0






224.0.0.5/32 *[OSPF/10] 17:34:15, metric 1

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

192.168.254.4/32 *[RSVP/7] 17:33:22, metric 2, metric2 0> to 192.168.1.2 via fxp0.0, label-switched-path test_path

mpls.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

0 *[MPLS/0] 17:34:14, metric 1Receive



9/37



The first table displayed is inet.0, which contains 18 active prefixes. The table here shows thatwith the exception of local and directly connected subnets, all prefixes were entered by OSPF.

The second table displayed is inet.3, containing a single entry. The destination prefix is192.168.254.4/32, which is the egress of LSP test_path, and is reachable via that LSP.

The last table is mpls.0. This table contains entries for labels 0 and 1, which are entered

automatically by MPLS when the protocol is enabled. These labels, when received, signify anLSP endpoint and a router alert, respectively. No other labels are entered into mpls.0 becauseRTR1 is not a transit router for any LSP. Contrast RTR1's mpls.0 table with that of RTR2.

jeff@RTR2> show route table mpls.0




100004 *[RSVP/7] 18:07:14, metric 1> to 192.168.3.2 via fxp1.0, label-switched-path test_path


10/37



This table shows that incoming MPLS packets with a label of 100004 are switched to interfacefxp1, following LSP test_path. You can view the full path of the LSP, including the label

bindings, by displaying the RSVP sessions on each of the four routers in the path.

jeff@RTR1> show rsvp session briefIngress RSVP: 1 sessions

To From State Rt Style Labelin Labelout LSPname192.168.254.4 192.168.254.1 Up 0 1 FF - 100004 test_pathTotal 1 displayed, Up 1, Down 0Egress RSVP: 0 sessionsTotal 0 displayed, Up 0, Down 0Transit RSVP: 0 sessionsTotal 0 displayed, Up 0, Down 0

jeff@RTR2> show rsvp session briefIngress RSVP: 0 sessionsTotal 0 displayed, Up 0, Down 0Egress RSVP: 0 sessionsTotal 0 displayed, Up 0, Down 0

Transit RSVP: 1 sessionsTo From State Rt Style Labelin Labelout LSPname192.168.254.4 192.168.254.1 Up 1 1 FF 100004 100004 test_pathTotal 1 displayed, Up 1, Down 0

jeff@RTR3> show rsvp session briefIngress RSVP: 0 sessionsTotal 0 displayed, Up 0, Down 0Egress RSVP: 0 sessionsTotal 0 displayed, Up 0, Down 0Transit RSVP: 1 sessionsTo From State Rt Style Labelin Labelout LSPname192.168.254.4 192.168.254.1 Up 1 1 FF 100004 3 test_pathTotal 1 displayed, Up 1, Down 0

jeff@RTR4> show rsvp session briefIngress RSVP: 0 sessionsTotal 0 displayed, Up 0, Down 0Egress RSVP: 1 sessionsTo From State Rt Style Labelin Labelout LSPname192.168.254.4 192.168.254.1 Up 0 1 FF 3 - test_pathTotal 1 displayed, Up 1, Down 0Transit RSVP: 0 sessionsTotal 0 displayed, Up 0, Down 0

On all four routers, the ingress and egress IP addresses of the LSP are shown. The path is

shown as an ingress path at RTR1, and packets forwarded on the LSP are assigned a label of

100004. At RTR2 the LSP is transit, and packets arriving with a label of 100004 are given anoutgoing label of 100004. Although these two labels are numerically the same, label swappingstill is taking place at RTR2; the labels have significance only between neighboring LSRs.RTR3 swaps incoming label 100004 for outgoing label 3. RTR4, the egress, pops label 3 and

routes the received packet by standard IP longest-match route lookup.


11/37



Using traffic-engineering bgp

When MPLS is enabled, the command traffic-engineering bgp is enabled by default.

Since it is a default, it is implicit and does not appear in the JUNOS MPLS configurationstanzas. The traffic-engineering bgp command causes BGP to examine both the inet.0

and the inet.3 tables when resolving a route, as shown in Figure 4. All other unicast routingprotocols consult only inet.0. The significance of this behavior is not with the resolution ofdestination addresses, but with the resolution of next-hop addresses, as the example in this

section demonstrates.

Figure 4: By Default, BGP Uses Both inet.0 and inet.3

inet .0 inet .3

IGP RSVP

IP Forwarding Table

BGP


12/37



Figure 1 shows that there are two prefixes in AS 65520 that are being advertised to AS 65501via EBGP. These prefixes are 10.1.0.0/16 and 10.2.0.0/16. However, a re-examination of RTR1's

routing tables shown in the previous section reveals that neither of the prefixes is in therouting table. Notice that the header of inet.0 shows that there are a total of 20 known prefixes,

of which 18 are active and 2 are hidden. Examining the hidden prefixes, we find the following.

jeff@RTR1> show route table inet.0 hidden detailinet.0: 20 destinations, 20 routes (18 active, 0 holddown, 2 hidden)+ = Active Route, - = Last Active, * = Both10.1.0.0/16 (1 entry, 0 announced)

BGP Preference: 170/-101Next hop type: UnusableState: Local AS: 65501 Peer AS: 65501 Age: 21 Metric2: 0Task: BGP_65501.192.168.254.4+1037 AS path: 65520 IBGP next hop: 172.16.1.2Localpref: 100

Router ID: 192.168.254.4

10.2.0.0/16 (1 entry, 0 announced)BGP Preference: 170/-101

Next hop type: UnusableState: Local AS: 65501 Peer AS: 65501 Age: 21 Metric2: 0Task: BGP_65501.192.168.254.4+1037 AS path: 65520 IBGP next hop: 172.16.1.2Localpref: 100Router ID: 192.168.254.4

The two routes are being received from RTR4 (192.168.254.4) via IBGP, but they are not beinginstalled as active routes because the next-hop address of the routes is unusable. These

unreachable next-hop addresses are reflective of default BGP behavior, in which the next-hopattribute of an externally learned route is not changed across IBGP sessions.

In the case of the prefixes from AS 65520, the next-hop address is that of RTR7's externalinterface, 172.16.1.2. When RTR1's BGP process receives these routes, it performs a route

lookup to see if the next-hop address is reachable. A quick scan of RTR1's routing tables in theprevious section shows that there are no entries to which 172.16.1.2 match. Therefore, theroutes are declared unusable.


13/37



To alleviate the situation and make the routes usable, RTR4 is configured with a policy thatoverrides the next-hop address of the external routes and adds itself as the next hop. The

policy is then applied as an export policy for RTR4's internal peers.

bgp {

group internal-peers {type internal;local-address 192.168.254.4;export next-hop-self;neighbor 192.168.254.1;neighbor 192.168.254.2;neighbor 192.168.254.3;neighbor 192.168.254.5;

}group external-peer {

type external;peer-as 65520;neighbor 172.16.1.2;

}policy-options {

policy-statement next-hop-self {from protocol bgp;then {

next-hop self;}

}}

The results are observed at RTR1.

jeff@RTR1> show route receive-protocol bgp 192.168.254.4

inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)Prefix Nexthop MED Lclpref AS path10.1.0.0/16 192.168.254.4 100 65520 I10.2.0.0/16 192.168.254.4 100 65520 I


14/37



The next-hop address was changed to RTR4's router ID, 192.168.254.4. At this point, the trafficengineering BGP becomes significant. BGP receives the prefixes and must again consult the

routing tables to learn how to reach the next-hop address. When it looks for a route to192.168.254.4, it finds the following entry.

jeff@RTR1> show route 192.168.254.4





There is an entry for 192.168.254.4/32 in both inet.0 and in inet.3. The inet.0 route follows the

OSPF shortest path, while the inet.3 route is the LSP test_path. Notice that the routepreference associated with the OSPF route is 10, while the route preference associated with theRSVP route is 7. The lower number is preferred, so the LSP is selected as the more-preferred

route to next-hop address 192.168.254.4.

BGP has now resolved the next hop for the prefixes, and it installs the routes to 10.1.0.0/16

and 10.2.0.0/16 in the routing table with the LSP as the path to the routes' next-hop address.

jeff@RTR1> show route 10/8


10.1.0.0/16 *[BGP/170] 00:24:51, localpref 100, from 192.168.254.4 AS path: 65520 I

> to 192.168.1.2 via fxp0.0, label-switched-path test_path10.2.0.0/16 *[BGP/170] 00:24:51, localpref 100, from 192.168.254.4

AS path: 65520 I> to 192.168.1.2 via fxp0.0, label-switched-path test_path

These results are indicative of the primary application of MPLS traffic engineering, which is to

give you a tool for manipulating the paths that transit traffic takes through autonomoussystems. LSPs are built in such a way that their endpoints are at BGP edge routers, and theiregress addresses are the router IDs of the edge routers. The edge routers then change the next-

hop addresses of routes learned from EBGP peers to their own router ID. As a result, routescan be resolved using the LSPs to those router IDs.


15/37



You can gain further understanding of the relationship of the IGPs and BGP to inet.0 andinet.3 by examining the forwarding table. Looking at the entry for 10.1.0.0/16 in the

forwarding table, the next-hop address is shown as 192.168.1.2.

jeff@RTR1> show route forwarding-table destination 10.1.0.0/16Internet:

Destination Type RtRef Nexthop Type Index NhRef Netif10.1.0.0/16 user 0 192.168.1.2 Push 100004 fxp0.0

192.168.1.2 is not the next hop of the BGP route, but the forwarding next hop of the LSP; inthis case, RTR2's interface (refer to Figure 1). Another clue is that the route type shows a Push

function and the Index shows an MPLS label (the label is pushed onto the packet at the ingressLSR).

The forwarding entry for 192.168.254.4 is as follows.

jeff@RTR1> show route forwarding-table destination 192.168.254.4Internet:Destination Type RtRef Nexthop Type Index NhRef Netif192.168.254.4/32 user 1 192.168.2.2 ucst 25 12 fxp1.0

Notice that the forwarding next hopfor this entry is 192.168.2.2, which is the RTR5's interface.

This path is the OSPF route. The significance of these two entries is that although BGP hasdetermined that the best path to 192.168.254.4 is via LSP test_path, the router forwards packets

with a destination address of 192.168.254.4 over the OSPF route.

These two traceroutes further illustrate the point.

jeff@RTR1> traceroute 10.1.1.1

traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 40 byte packets1 192.168.1.2 (192.168.1.2) 0.426 ms 0.237 ms 0.180 msMPLS Label=100004 CoS=0 TTL=1 S=1

2 192.168.3.2 (192.168.3.2) 0.347 ms 0.280 ms 0.270 msMPLS Label=100004 CoS=0 TTL=1 S=1

3 192.168.5.2 (192.168.5.2) 0.371 ms 0.295 ms 0.295 ms4 * * *

^Cjeff@RTR1> traceroute 192.168.254.4traceroute to 192.168.254.4 (192.168.254.4), 30 hops max, 40 byte packets

1 192.168.2.2 (192.168.2.2) 0.370 ms 0.197 ms 0.164 ms2 192.168.254.4 (192.168.254.4) 0.339 ms 0.270 ms 0.267 ms


16/37



The first trace is to a destination belonging to the 10.1.0.0/16 prefix, and follows the LSP. Thesecond trace is to 192.168.254.4, and follows the OSPF route. These results correspond to what

we observed in the forwarding table.

The behavior observed in this demonstration is a direct result of the relationships depicted in

Figure 4. The forwarding table is built based on routes in inet.0 only. BGP can look into inet.3and select an LSP as the best path to the next hop of a BGP prefix, and can add a route into

inet.0 utilizing that LSP. An entry is then made to the forwarding table from the inet.0 route.No other protocol, by default, can consult inet.3, and the inet.3 routes are not entered into

inet.0. Therefore, the forwarding entry for 192.168.254.4 is created from the only route to thatdestination in inet.0: the OSPF route.

Using IGP Shortcuts

Not everyone uses the next-hop self approach to solve the EBGP next-hop problem. Someprefer to run the IGP in passive mode on the external interfaces. The IGP is then aware of the

external subnets and enters routes to them in the inet.0 routing table. BGP, when resolving thenext-hop addresses of AS-external routes, will then use the IGP route.

Traffic-engineering BGP does not work in this situation because the next-hop addressof the BGP routes is not the router ID of any egress LSR. Therefore, traffic is only mapped toIGP routes, not to LSPs.

IGP shortcuts, also called traffic-engineering shortcuts, provide a tool by which the

link-state IGP (OSPF or IS-IS) in an AS can consider LSPs in its SPF calculations. If usingpassive external interfaces, the IGP views an LSP as a single data link toward the destinations

beyond the LSP egress.

For this example, the configuration of RTR4 is changed so that the next-hop self policy is

eliminated, and the external interface to RTR7, fxp1, is running passive OSPF.

bgp {group internal-peers {

type internal;

local-address 192.168.254.4;neighbor 192.168.254.1;neighbor 192.168.254.2;neighbor 192.168.254.3;neighbor 192.168.254.5;

}group external-peer {


}}ospf {

area 0.0.0.0 {interface fxp0.0;interface fxp2.0;interface fxp3.0;interface fxp4.0;interface fxp1.0 {

passive;}

}}


17/37



RTR4 now advertises the 172.16.1.0/30 subnet into the OSPF domain.

jeff@RTR1> show route 172.16.1/16



RTR4 advertises the prefixes from AS 65520 to its IBGP peers without changing the next-hoproute attribute. When RTR1 receives the route, it again looks into the inet.0 and inet.3 routing

tables for a route to the BGP next hop 172.16.1.2, and finds the OSPF route. The route to theAS 65520 prefixes is then installed in inet.0 using the OSPF path to the next hop.

jeff@RTR1> show route 10/8 detailinet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both10.1.0.0/16 (1 entry, 1 announced)

*BGP Preference: 170/-101Source: 192.168.254.4Nexthop: 192.168.2.2 via fxp1.0, selectedState: Local AS: 65501 Peer AS: 65501 Age: 31 Metric2: 3Task: BGP_65501.192.168.254.4+1037 Announcement bits (2): 2-KRT 4-BGP_Sync_Any AS path: 65520 IBGP next hop: 172.16.1.2Localpref: 100Router ID: 192.168.254.4

10.2.0.0/16 (1 entry, 1 announced)*BGP Preference: 170/-101

Source: 192.168.254.4Nexthop: 192.168.2.2 via fxp1.0, selectedState: Local AS: 65501 Peer AS: 65501 Age: 31 Metric2: 3Task: BGP_65501.192.168.254.4+1037 Announcement bits (2): 2-KRT 4-BGP_Sync_Any AS path: 65520 IBGP next hop: 172.16.1.2Localpref: 100Router ID: 192.168.254.4

Notice the BGP next hop of 172.16.1.2 and the forwarding next hop of 192.168.2.2, which

follows the OSPF shortest path.Referring to Figure 3 you can see that if OSPF is allowed to include the LSP in its SPFcalculations, and if the LSP is viewed as a single data link, OSPF chooses the LSP as the

shorter path to the subnets downstream of RTR4.


18/37



It is only necessary to enable IGP shortcuts on the ingress router because that is the routerperforming the SPF calculations. RTR1's OSPF configuration becomes as follows.

ospf {traffic-engineering shortcuts;

area 0.0.0.0 {interface all;}

}

It is important to understand how IGP shortcuts affect the protocol and routing table

relationship depicted in Figure 4. The IGP performs SPF calculations to subnets downstreamof LSP egress points, but the results of these calculations are entered into the inet.3 table only(Figure 5). At the same time, the IGP performs its traditional SPF calculations and enters the

results of these calculations into the inet.0 table. The result is that although the IGP is makingentries into the inet.3 table, BGP is still the only protocol with visibility into that table for the

purposes of route resolution. Therefore, forwarding to AS-internal destinations still uses theinet.0 IGP routes, and the LSPs are only used for BGP next-hop resolution.

Figure 5: IGP Shortcuts Allow the IGP to Install Prefixes in inet.3

inet .0 inet .3

IGP RSVP

IP Forwarding Table

BGP


19/37



RTR1's routing tables, after IGP shortcuts areenabled, are as follows.

jeff@RTR1> show route






192.168.1.0/24 *[Direct/0] 1d 15:19:11> via fxp0.0

192.168.1.1/32 *[Local/0] 1d 15:19:11Local

192.168.2.0/24 *[Direct/0] 1d 15:19:11

> via fxp1.0192.168.2.1/32 *[Local/0] 1d 15:19:11









192.168.254.1/32 *[Direct/0] 1d 15:19:11> via lo0.0






224.0.0.5/32 *[OSPF/10] 1d 15:19:12, metric 1


20/37




172.16.1.0/30 *[OSPF/10] 00:51:39, metric 3> to 192.168.1.2 via fxp0.0, label-switched-path test_path


192.168.6.0/24 *[OSPF/10] 00:01:35, metric 3> to 192.168.1.2 via fxp0.0, label-switched-path test_path192.168.7.0/24 *[OSPF/10] 00:51:39, metric 13

> to 192.168.1.2 via fxp0.0, label-switched-path test_path192.168.8.0/24 *[OSPF/10] 00:51:39, metric 13

> to 192.168.1.2 via fxp0.0, label-switched-path test_path192.168.9.0/24 *[OSPF/10] 00:51:39, metric 12

> to 192.168.1.2 via fxp0.0, label-switched-path test_path192.168.254.4/32 *[RSVP/7] 1d 15:18:19, metric 2, metric2 0

> to 192.168.1.2 via fxp0.0, label-switched-path test_path[OSPF/10] 00:51:39, metric 2> to 192.168.1.2 via fxp0.0, label-switched-path test_path



0 *[MPLS/0] 1d 15:19:11, metric 1Receive

1 *[MPLS/0] 1d 15:19:11, metric 1Receive

In the inet.3 table, routes were entered by both RSVP and by OSPF. Compare the OSPF routesto the addresses shown in Figure 1, and you can see that the routes are to subnets within theOSPF domain, but are downstream from the egress of LSP test_path. These routes are the

directly connected subnets of RTR4, and the directly connected subnets of downstream router

RTR6.

Notice that 192.168.5.0/24 is listed, but 192.168.4.0/24 is not. 192.168.4.0/24 is a part of thenormal OSPF shortest path and so is not considered downstream of RTR4. The LSP passes

over 192.168.5.0/24, but OSPF sees only the LSP, and therefore considers the subnet to bedownstream of RTR4.

172.16.1.0/30 is also included in inet.3, and you can see in inet.0 that BGP selected the LSP tothat subnet as the path to the next-hop address 172.16.1.2 for its routes to the two AS 65520

prefixes. In the previous section discussing traffic -engineering BGP, BGP preferred the RSVPpaths with a preference of 7 over the OSPF paths with a preference of 10. However, in thiscase, the OSPF route to 172.16.1.0/30 in inet.0 and the OSPF route to the same prefix in inet.3

both have the same preference of 10 and the same metric of 3. This point illustrates that whenBGP finds routes to a next-hop address in both inet.0 and inet.3, and all other parameters of

the two routes are equal, the inet.3 route is preferred.

A final operational note about IGP shortcuts concerns the address of the LSP egress. The

endpoints of link-state SPF trees are nodes, as represented by OSPF router IDs or IS-IS systemIDs. Therefore, IGPs can use LSPs in their SPF calculations only if the egress address of the

LSP is a loopback interface (on which OSPF router IDs and IS-IS system IDs are configured).The IGP shortcuts do not use LSPs whose endpoints are physical interfaces because theseaddresses do not represent nodes.


21/37



The following is a detailed display of the two BGP routes after IGP shortcuts are enabled.,Compare it with the earlier detailed display of the same routes without IGP shortcuts.


Source: 192.168.254.4

Nexthop: 192.168.1.2 via fxp0.0, selectedlabel-switched-path test_pathState: Local AS: 65501 Peer AS: 65501 Age: 1:45:17 Metric2: 3Task: BGP_65501.192.168.254.4+1037 Announcement bits (2): 2-KRT 4-BGP_Sync_Any AS path: 65520 IBGP next hop: 172.16.1.2Localpref: 100Router ID: 192.168.254.4


Source: 192.168.254.4Nexthop: 192.168.1.2 via fxp0.0, selectedlabel-switched-path test_pathState: Local AS: 65501 Peer AS: 65501 Age: 1:45:17 Metric2: 3Task: BGP_65501.192.168.254.4+1037 Announcement bits (2): 2-KRT 4-BGP_Sync_Any AS path: 65520 IBGP next hop: 172.16.1.2Localpref: 100Router ID: 192.168.254.4

The true usefulness of IGP shortcuts becomes apparent not when an LSP is used to reach asingle external link, as shown in the example so far, but when a single LSP is used to reach a

group of external links on several routers. For example, you might have POPs in many cities.At each POP, there might be several peering routers. With traffic engineering BGP, a full mesh

of LSPs might be required between all peering routers in all POPs. As the number of peeringrouters grows, the number of LSPs grows exponentially. Management of the LSPs begins to

take on the same problems of complexity that traffic engineering was meant to reduce.However, with IGP shortcuts, LSPs can be created to a single router within the POP, or evento a single router centrally located among a region of POPs. The total number of LSPs in the

core is reduced, and traffic engineering remains simple.


22/37



Using traffic-engineering bgp-igp

Both traffic-engineering bgp and IGP shortcuts, as presented so far, are used forBGP route resolution only. However, traffic to AS-internal destinations can also be mapped toLSPs. When traffic-engineering bgp-igp is enabled, RSVP installs the MPLSprefixes into the inet.0 table rather than the inet.3 table (Figure 6). As a result, the MPLS LSPsare now installed in the forwarding table.

Figure 6: The traffic-engineering bgp-igp Command Causes RSVP to Install Prefixes

into inet.0

inet 0

IGP RSVP

IP Forwarding Table

BGP


23/37



The traffic-engineering bgp-igp command is configured under the MPLS section ofthe JUNOS configuration. In the first example, RTR1 is configured to run traffic-engineering bgp-igp, but not IGP shortcuts.

protocols {

rsvp {interface all;}mpls {

traffic-engineering bgp-igp;label-switched-path test_path {

to 192.168.254.4;primary through_RTR2;no-cspf;

}path through_RTR2 {

192.168.254.2 strict;}interface all;

}bgp {group internal-peers {

type internal;local-address 192.168.254.1;neighbor 192.168.254.2;neighbor 192.168.254.3;neighbor 192.168.254.4;neighbor 192.168.254.5;

}}ospf {

traffic-engineering;area 0.0.0.0 {

interface all;}

}}


24/37



The resulting routing tables and forwarding table of RTR1 are as follows.




> to 192.168.2.2 via fxp1.010.2.0.0/16 *[BGP/170] 00:02:01, localpref 100, from 192.168.254.4

AS path: 65520 I> to 192.168.2.2 via fxp1.0


192.168.1.0/24 *[Direct/0] 1d 23:57:14> via fxp0.0

192.168.1.1/32 *[Local/0] 1d 23:57:14Local

192.168.2.0/24 *[Direct/0] 1d 23:57:14> via fxp1.0192.168.2.1/32 *[Local/0] 1d 23:57:14






192.168.7.0/24 *[OSPF/10] 00:20:26, metric 13

> to 192.168.2.2 via fxp1.0192.168.8.0/24 *[OSPF/10] 00:20:26, metric 13> to 192.168.2.2 via fxp1.0


192.168.254.1/32 *[Direct/0] 1d 23:57:14> via lo0.0



192.168.254.4/32 *[RSVP/7] 00:23:12, metric 2, metric2 0> to 192.168.1.2 via fxp0.0, label-switched-path test_path[OSPF/10] 00:20:26, metric 2



> to 192.168.2.2 via fxp1.0224.0.0.5/32 *[OSPF/10] 1d 23:57:15, metric 1


25/37



mpls.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both0 *[MPLS/0] 1d 23:57:14, metric 1

Receive1 *[MPLS/0] 1d 23:57:14, metric 1

Receive

jeff@RTR1> show route forwarding-table

Internet:Destination Type RtRef Nexthop Type Index NhRef Netifdefault perm 0 rjct 9 110.1.0.0/16 user 0 192.168.2.2 ucst 25 13 fxp1.010.2.0.0/16 user 0 192.168.2.2 ucst 25 13 fxp1.0172.16.1.0/30 user 0 192.168.2.2 ucst 25 13 fxp1.0192.168.1.0/24 intf 0 rslv 14 1 fxp0.0192.168.1.0/32 dest 0 192.168.1.0 recv 12 1 fxp0.0192.168.1.1/32 intf 0 192.168.1.1 locl 13 2192.168.1.1/32 dest 0 192.168.1.1 locl 13 2192.168.1.2/32 dest 0 0:90:27:c2:8a:a3 ucst 24 7 fxp0.0192.168.1.255/32 dest 0 192.168.1.255 bcst 11 1 fxp0.0192.168.2.0/24 intf 0 rslv 18 1 fxp1.0192.168.2.0/32 dest 0 192.168.2.0 recv 16 1 fxp1.0192.168.2.1/32 intf 0 192.168.2.1 locl 17 2192.168.2.1/32 dest 0 192.168.2.1 locl 17 2192.168.2.2/32 dest 0 0:d0:b7:75:ff:31 ucst 25 13 fxp1.0192.168.2.255/32 dest 0 192.168.2.255 bcst 15 1 fxp1.0192.168.3.0/24 user 0 192.168.1.2 ucst 24 7 fxp0.0192.168.4.0/24 user 0 192.168.2.2 ucst 25 13 fxp1.0192.168.5.0/24 user 0 192.168.2.2 ucst 25 13 fxp1.0192.168.6.0/24 user 0 192.168.2.2 ucst 25 13 fxp1.0192.168.7.0/24 user 0 192.168.2.2 ucst 25 13 fxp1.0192.168.8.0/24 user 0 192.168.2.2 ucst 25 13 fxp1.0192.168.9.0/24 user 0 192.168.2.2 ucst 25 13 fxp1.0

192.168.254.1/32 intf 0 192.168.254.1 locl 21 1192.168.254.2/32 user 1 192.168.1.2 ucst 24 7 fxp0.0192.168.254.3/32 user 1 192.168.1.2 ucst 24 7 fxp0.0192.168.254.4/32 user 1 192.168.1.2 Push 100004 fxp0.0192.168.254.5/32 user 1 192.168.2.2 ucst 25 13 fxp1.0192.168.254.6/32 user 0 192.168.2.2 ucst 25 13 fxp1.0224.0.0.0/4 perm 1 mdsc 8 1224.0.0.1/32 perm 0 224.0.0.1 mcst 4 3224.0.0.5/32 user 1 224.0.0.5 mcst 4 3255.255.255.255/32 perm 0 bcst 5 1

MPLS:Interface.Label Type RtRef Nexthop Type Index NhRef Netifdefault perm 0 dscd 1 1

0 user 0 recv 3 21 user 0 recv 3 2

Notice that the LSP to 192.168.254.4 was installed in the inet.0 table, along with the OSPF routeto the same destination. Since RSVP has a better route preference than OSPF, the LSP is

selected as the best route to 192.168.254.4 and is installed in the forwarding table. Notice alsothat there is no inet.3 table.


26/37



So far, there is little about traffic-engineering bgp-igp that is useful. However,when IGP shortcuts are also enabled, the IGP can again use the LSP in its calculations. Since

there is no inet.3 table, the results of the calculations are entered into the inet.0 table.

Using both traffic-engineering bgp-igp and IGP shortcuts, RTR1's configuration isas follows.

protocols {rsvp {

interface all;}mpls {

traffic-engineering bgp-igp;label-switched-path test_path {

to 192.168.254.4;primary through_RTR2;no-cspf;

}

192.168.254.2 strict;

}interface all;

}bgp {

group internal-peers {type internal;local-address 192.168.254.1;neighbor 192.168.254.2;neighbor 192.168.254.3;neighbor 192.168.254.4;neighbor 192.168.254.5;

}}ospf {

traffic-engineering shortcuts;area 0.0.0.0 {

interface all;}

}}


27/37



The resulting routing table is as follows.







192.168.1.0/24 *[Direct/0] 2d 00:23:15> via fxp0.0

192.168.1.1/32 *[Local/0] 2d 00:23:15Local

192.168.2.0/24 *[Direct/0] 2d 00:23:15> via fxp1.0

192.168.2.1/32 *[Local/0] 2d 00:23:15Local








192.168.254.1/32 *[Direct/0] 2d 00:23:15> via lo0.0



192.168.254.4/32 *[RSVP/7] 00:49:13, metric 2, metric2 0> to 192.168.1.2 via fxp0.0, label-switched-path test_path[OSPF/10] 00:00:04, metric 2> to 192.168.1.2 via fxp0.0, label-switched-path test_path



224.0.0.5/32 *[OSPF/10] 2d 00:23:16, metric 1mpls.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both0 *[MPLS/0] 2d 00:23:15, metric 1

Receive1 *[MPLS/0] 2d 00:23:15, metric 1

Receive


28/37



OSPF chose the LSP as the shortest path to destinations downstream of the LSP egress.

Additionally, because the IGP uses the LSP to reach external subnet 172.16.1.0/30, BGP alsouses the LSP in its two routes. If next-hop selfwere used at RTR4, BGP would still choose the

LSP over the IGP path.

This approach finds practical application whenever heavy traffic is routed to specific

destinations within an AS, such as server farms.

An important point about IGP shortcuts, whether used alone or in conjunction with

traffic-engineering BGP-IGP, is that IGP adjacencies are never formed across theLSPs. The IGP sees the LSP as a single data link, but does not view the egress router as a

potential peer and does not forward Hello messages across the LSP. Also, RSVP messages arenever forwarded over LSPs, preventing the possibility of an LSP being inadvertently builtwithin another LSP.

Installing Single Prefixes

A possible concern with IGP shortcuts is that it does not have granular control over what is

installed in the routing tables. There are occasions when only certain destinations should bemapped to an LSP. JUNOS software provides the option of mapping prefixes to LSPs

individually.

For this example, return RTR1 and RTR4 to their base configurations. Neither traffic-engineering bgp-igp, nor IGP shortcuts are running on RTR1; RTR4 is not runningOSPF on its external interface and is not using next-hop self. As a result, prefixes

10.1.0.0/24 and 10.2.0.0/24 in AS 65520 are not reachable at RTR1.

jeff@RTR1> show bgp next-hop-database10.1.0.0/16

Source: 192.168.254.4 Next hop not resolved10.2.0.0/16

Source: 192.168.254.4 Next hop not resolved

To make the prefixes reachable and to insure that BGP uses LSP test_path to reach the nexthop, prefix 172.16.1.0/30 is manually associated with LSP and installed in inet.3 at RTR1.


29/37



mpls {label-switched-path test_path {

to 192.168.254.4;primary through_RTR2;install 172.16.1.0/30;no-cspf;



}

The result is observed in inet.3.

jeff@RTR1> show route table inet.3




172.16.1.0/30 is installed only in inet.3. BGP can now look into the table, find a match for thenext-hop address172.16.1.2, and install the routes to the external prefixes in inet.0.

jeff@RTR1> show bgp next-hop-database10.1.0.0/16

Source: 192.168.254.4 Nexthop: 172.16.1.0172.16.1.0/30 MED 2 Next hop 192.168.1.2 Push 100004,

10.2.0.0/16Source: 192.168.254.4 Nexthop: 172.16.1.0

172.16.1.0/30 MED 2 Next hop 192.168.1.2 Push 100004,

jeff@RTR1> show route 10/8



> to 192.168.1.2 via fxp0.0, label-switched-path test_path

10.2.0.0/16 *[BGP/170] 00:07:58, localpref 100, from 192.168.254.4 AS path: 65520 I> to 192.168.1.2 via fxp0.0, label-switched-path test_path

Just as single prefixes can be installed in inet.3, single prefixes mapped to an LSP can beinstalled in inet.0 for intra-AS routing. This mapping is accomplished by appending the

active keyword to the installstatement. For example, suppose you want subnet

192.168.8.0/24 in Figure 1, internal to AS 65501, to be mapped to the LSP. RTR1'sconfiguration changes to the following.


30/37



mpls {label-switched-path test_path {

to 192.168.254.4;primary through_RTR2;install 172.16.1.0/30;install 192.168.8.0/24 active;

no-cspf;}path through_RTR2 {


}

The prefix is installed in inet.0, along with the OSPF path. Again, because RSVP carries a

better preference value than OSPF, the LSP is chosen as the forwarding path.

jeff@RTR1> show route 192.168.8.0inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both192.168.8.0/24 *[RSVP/7] 00:01:46, metric 2, metric2 0

> to 192.168.1.2 via fxp0.0, label-switched-path test_path[OSPF/10] 00:01:45, metric 13> to 192.168.2.2 via fxp1.0


31/37



Appendix A

The following are the base configurations for the seven routers of the demonstration network.

Changes from these beginning configurations are shown in the main body of the documentwhen they are discussed.

RTR1

routing-options {autonomous-system 65501;

}protocols {

rsvp {interface all;

}mpls {

label-switched-path test_path {to 192.168.254.4;

primary through_RTR2;no-cspf;



}bgp {


}}ospf {

area 0.0.0.0 {interface all;

}}


32/37



RTR2


}

protocols {rsvp {


interface all;}bgp {

group internal-peers {type internal;local-address 192.168.254.2;neighbor 192.168.254.1;neighbor 192.168.254.3;neighbor 192.168.254.4;

neighbor 192.168.254.5;}

}ospf {


}}


33/37



RTR3


}

protocols {rsvp {



group internal-peer {type internal;local-address 192.168.254.3;neighbor 192.168.254.1;neighbor 192.168.254.2;neighbor 192.168.254.4;

neighbor 192.168.254.5;}

}ospf {


}}


34/37



RTR4


}

protocols {rsvp {

interface fxp0.0;interface fxp4.0;

}mpls {


}bgp {

group internal-peers {type internal;local-address 192.168.254.4;neighbor 192.168.254.1;

neighbor 192.168.254.2;neighbor 192.168.254.3;

neighbor 192.168.254.5;}group external-peer {


}}ospf {

area 0.0.0.0 {interface fxp0.0;interface fxp2.0;


}}


35/37



RTR5

protocols {rsvp {

interface all;

}mpls {



}}

ospf {area 0.0.0.0 {

interface all;}

}

RTR6

protocols {ospf {


}

}


36/37



RTR7

routing-options {static {

route 10.1.0.0/32 {

reject;install;

}route 10.2.0.0/32 {

reject;install;

}}autonomous-system 65520;

}protocols {

bgp {group external-peers {

type external;

export statics;peer-as 65501;neighbor 172.16.1.1;

}}

}policy-options {

policy-statement statics {from protocol static;then accept;

}}


37/37


Acronyms

AS Autonomous system

BGP Border Gateway Protocol

CSPF Constrained Shortest Path First

EBGP External Border Gateway Protocol

ERO Explicit Route Object

IGP Interior Gateway Protocol

IS-IS Intermediate System to Intermediate System

LSP Label switched path

LSR Label switching router

MPLS Multiprotocol Label Switching

OSPF Open Shortest Path FirstPOP Point of presence

RSVP Resource Reservation Protocol

SPF Shortest path first

Copyright 2000, Juniper Networks, Inc. All rights reserved. Juniper Networks is a registered trademark of Juniper Networks, Inc. Internet Processor,

Internet Processor II, JUNOS, M5, M10, M20, M40, and M160 are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered

trademarks, or registered service marks may be the property of their respective owners. All specifications are subject to change without notice. Printed in

USA

resolving routes for mpls traffic engineering

Documents