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
8/3/2019 Resolving Routes for MPLS Traffic Engineering
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
8/3/2019 Resolving Routes for MPLS Traffic Engineering
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.
8/3/2019 Resolving Routes for MPLS Traffic Engineering
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
8/3/2019 Resolving Routes for MPLS Traffic Engineering
5/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 5
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
8/3/2019 Resolving Routes for MPLS Traffic Engineering
6/37
Resolving Routes for MPLS Traffic Engineering
6 Copyright 2000, Juniper Networks, Inc.
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.
8/3/2019 Resolving Routes for MPLS Traffic Engineering
7/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 7
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/3/2019 Resolving Routes for MPLS Traffic Engineering
8/37
Resolving Routes for MPLS Traffic Engineering
8 Copyright 2000, Juniper Networks, Inc.
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.2.2 via fxp1.0192.168.5.0/24 *[OSPF/10] 17:33:22, metric 3
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.7.0/24 *[OSPF/10] 17:33:22, metric 13> to 192.168.2.2 via fxp1.0
192.168.8.0/24 *[OSPF/10] 17:33:22, metric 13> to 192.168.2.2 via fxp1.0
192.168.9.0/24 *[OSPF/10] 17:33:22, metric 12> to 192.168.2.2 via fxp1.0
192.168.254.1/32 *[Direct/0] 17:34:14> via lo0.0
192.168.254.2/32 *[OSPF/10] 17:33:27, metric 1> to 192.168.1.2 via fxp0.0
192.168.254.3/32 *[OSPF/10] 17:33:27, metric 2> to 192.168.1.2 via fxp0.0
192.168.254.4/32 *[OSPF/10] 17:33:22, metric 2> to 192.168.2.2 via fxp1.0
192.168.254.5/32 *[OSPF/10] 17:33:22, metric 1> to 192.168.2.2 via fxp1.0
192.168.254.6/32 *[OSPF/10] 17:33:22, metric 3> to 192.168.2.2 via fxp1.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
1 *[MPLS/0] 17:34:14, metric 1Receive
8/3/2019 Resolving Routes for MPLS Traffic Engineering
9/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 9
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
mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 20:12:23, metric 1Receive
1 *[MPLS/0] 20:12:23, metric 1Receive
100004 *[RSVP/7] 18:07:14, metric 1> to 192.168.3.2 via fxp1.0, label-switched-path test_path
8/3/2019 Resolving Routes for MPLS Traffic Engineering
10/37
Resolving Routes for MPLS Traffic Engineering
10 Copyright 2000, Juniper Networks, Inc.
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.
8/3/2019 Resolving Routes for MPLS Traffic Engineering
11/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 11
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
8/3/2019 Resolving Routes for MPLS Traffic Engineering
12/37
Resolving Routes for MPLS Traffic Engineering
12 Copyright 2000, Juniper Networks, Inc.
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.
8/3/2019 Resolving Routes for MPLS Traffic Engineering
13/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 13
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
8/3/2019 Resolving Routes for MPLS Traffic Engineering
14/37
Resolving Routes for MPLS Traffic Engineering
14 Copyright 2000, Juniper Networks, Inc.
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
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
192.168.254.4/32 *[OSPF/10] 21:44:52, metric 2> to 192.168.2.2 via fxp1.0
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
192.168.254.4/32 *[RSVP/7] 21:44:52, metric 2, metric2 0> to 192.168.1.2 via fxp0.0, label-switched-path test_path
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
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
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.
8/3/2019 Resolving Routes for MPLS Traffic Engineering
15/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 15
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
8/3/2019 Resolving Routes for MPLS Traffic Engineering
16/37
Resolving Routes for MPLS Traffic Engineering
16 Copyright 2000, Juniper Networks, Inc.
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 {
type external;peer-as 65520;neighbor 172.16.1.2;
}}ospf {
area 0.0.0.0 {interface fxp0.0;interface fxp2.0;interface fxp3.0;interface fxp4.0;interface fxp1.0 {
passive;}
}}
8/3/2019 Resolving Routes for MPLS Traffic Engineering
17/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 17
RTR4 now advertises the 172.16.1.0/30 subnet into the OSPF domain.
jeff@RTR1> show route 172.16.1/16
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
172.16.1.0/30 *[OSPF/10] 00:03:46, metric 3> to 192.168.2.2 via fxp1.0
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.
8/3/2019 Resolving Routes for MPLS Traffic Engineering
18/37
Resolving Routes for MPLS Traffic Engineering
18 Copyright 2000, Juniper Networks, Inc.
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
8/3/2019 Resolving Routes for MPLS Traffic Engineering
19/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 19
RTR1's routing tables, after IGP shortcuts areenabled, are as follows.
jeff@RTR1> show route
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
10.1.0.0/16 *[BGP/170] 00:57:12, 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:57:12, localpref 100, from 192.168.254.4
AS path: 65520 I> to 192.168.1.2 via fxp0.0, label-switched-path test_path
172.16.1.0/30 *[OSPF/10] 00:51:39, metric 3> to 192.168.2.2 via fxp1.0
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
Local192.168.3.0/24 *[OSPF/10] 00:51:39, metric 2
> to 192.168.1.2 via fxp0.0192.168.4.0/24 *[OSPF/10] 00:51:39, metric 2
> to 192.168.2.2 via fxp1.0192.168.5.0/24 *[OSPF/10] 00:51:39, metric 3
to 192.168.1.2 via fxp0.0> to 192.168.2.2 via fxp1.0
192.168.6.0/24 *[OSPF/10] 00:51:39, metric 3> to 192.168.2.2 via fxp1.0
192.168.7.0/24 *[OSPF/10] 00:51:39, metric 13> to 192.168.2.2 via fxp1.0
192.168.8.0/24 *[OSPF/10] 00:51:39, metric 13> to 192.168.2.2 via fxp1.0
192.168.9.0/24 *[OSPF/10] 00:51:39, metric 12> to 192.168.2.2 via fxp1.0
192.168.254.1/32 *[Direct/0] 1d 15:19:11> via lo0.0
192.168.254.2/32 *[OSPF/10] 00:51:39, metric 1> to 192.168.1.2 via fxp0.0
192.168.254.3/32 *[OSPF/10] 00:51:39, metric 2> to 192.168.1.2 via fxp0.0
192.168.254.4/32 *[OSPF/10] 00:51:39, metric 2> to 192.168.2.2 via fxp1.0
192.168.254.5/32 *[OSPF/10] 00:51:39, metric 1> to 192.168.2.2 via fxp1.0
192.168.254.6/32 *[OSPF/10] 00:51:39, metric 3> to 192.168.2.2 via fxp1.0
224.0.0.5/32 *[OSPF/10] 1d 15:19:12, metric 1
8/3/2019 Resolving Routes for MPLS Traffic Engineering
20/37
Resolving Routes for MPLS Traffic Engineering
20 Copyright 2000, Juniper Networks, Inc.
inet.3: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
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.5.0/24 *[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
192.168.254.6/32 *[OSPF/10] 00:51:39, metric 3> 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] 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.
8/3/2019 Resolving Routes for MPLS Traffic Engineering
21/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 21
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.
10.1.0.0/16 (1 entry, 1 announced)*BGP Preference: 170/-101
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
10.2.0.0/16 (1 entry, 1 announced)*BGP Preference: 170/-101
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.
8/3/2019 Resolving Routes for MPLS Traffic Engineering
22/37
Resolving Routes for MPLS Traffic Engineering
22 Copyright 2000, Juniper Networks, Inc.
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
8/3/2019 Resolving Routes for MPLS Traffic Engineering
23/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 23
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;}
}}
8/3/2019 Resolving Routes for MPLS Traffic Engineering
24/37
Resolving Routes for MPLS Traffic Engineering
24 Copyright 2000, Juniper Networks, Inc.
The resulting routing tables and forwarding table of RTR1 are as follows.
jeff@RTR1> show route
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
10.1.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.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
172.16.1.0/30 *[OSPF/10] 00:20:26, metric 3> 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
Local192.168.3.0/24 *[OSPF/10] 00:20:26, metric 2
> to 192.168.1.2 via fxp0.0192.168.4.0/24 *[OSPF/10] 00:20:26, metric 2
> to 192.168.2.2 via fxp1.0192.168.5.0/24 *[OSPF/10] 00:20:26, metric 3
to 192.168.1.2 via fxp0.0> to 192.168.2.2 via fxp1.0
192.168.6.0/24 *[OSPF/10] 00:20:26, metric 3> to 192.168.2.2 via fxp1.0
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.9.0/24 *[OSPF/10] 00:20:26, metric 12> 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.2/32 *[OSPF/10] 00:20:26, metric 1> to 192.168.1.2 via fxp0.0
192.168.254.3/32 *[OSPF/10] 00:20:26, metric 2> to 192.168.1.2 via fxp0.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.0192.168.254.5/32 *[OSPF/10] 00:20:26, metric 1
> to 192.168.2.2 via fxp1.0192.168.254.6/32 *[OSPF/10] 00:20:26, metric 3
> to 192.168.2.2 via fxp1.0224.0.0.5/32 *[OSPF/10] 1d 23:57:15, metric 1
8/3/2019 Resolving Routes for MPLS Traffic Engineering
25/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 25
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.
8/3/2019 Resolving Routes for MPLS Traffic Engineering
26/37
Resolving Routes for MPLS Traffic Engineering
26 Copyright 2000, Juniper Networks, Inc.
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;}
}}
8/3/2019 Resolving Routes for MPLS Traffic Engineering
27/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 27
The resulting routing table is as follows.
jeff@RTR1> show route
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
10.1.0.0/16 *[BGP/170] 00:03:05, 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:03:05, localpref 100, from 192.168.254.4
AS path: 65520 I> to 192.168.1.2 via fxp0.0, label-switched-path test_path
172.16.1.0/30 *[OSPF/10] 00:00:04, metric 3> to 192.168.1.2 via fxp0.0, label-switched-path test_path
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.3.0/24 *[OSPF/10] 00:03:05, metric 2> to 192.168.1.2 via fxp0.0
192.168.4.0/24 *[OSPF/10] 00:03:05, metric 2> to 192.168.2.2 via fxp1.0
192.168.5.0/24 *[OSPF/10] 00:00:04, metric 3> to 192.168.1.2 via fxp0.0, label-switched-path test_path
192.168.6.0/24 *[OSPF/10] 00:00:04, metric 3> to 192.168.1.2 via fxp0.0, label-switched-path test_path
192.168.7.0/24 *[OSPF/10] 00:00:04, metric 13> to 192.168.1.2 via fxp0.0, label-switched-path test_path
192.168.8.0/24 *[OSPF/10] 00:00:04, metric 13> to 192.168.1.2 via fxp0.0, label-switched-path test_path
192.168.9.0/24 *[OSPF/10] 00:00:04, metric 12> to 192.168.1.2 via fxp0.0, label-switched-path test_path
192.168.254.1/32 *[Direct/0] 2d 00:23:15> via lo0.0
192.168.254.2/32 *[OSPF/10] 00:03:05, metric 1> to 192.168.1.2 via fxp0.0
192.168.254.3/32 *[OSPF/10] 00:03:05, metric 2> to 192.168.1.2 via fxp0.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
192.168.254.5/32 *[OSPF/10] 00:03:05, metric 1> to 192.168.2.2 via fxp1.0
192.168.254.6/32 *[OSPF/10] 00:00:04, metric 3> 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
8/3/2019 Resolving Routes for MPLS Traffic Engineering
28/37
Resolving Routes for MPLS Traffic Engineering
28 Copyright 2000, Juniper Networks, Inc.
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.
8/3/2019 Resolving Routes for MPLS Traffic Engineering
29/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 29
mpls {label-switched-path test_path {
to 192.168.254.4;primary through_RTR2;install 172.16.1.0/30;no-cspf;
}path through_RTR2 {
192.168.254.2 strict;}interface all;
}
The result is observed in inet.3.
jeff@RTR1> show route table inet.3
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
172.16.1.0/30 *[RSVP/7] 00:03:10, metric 2, metric2 0> to 192.168.1.2 via fxp0.0, label-switched-path test_path
192.168.254.4/32 *[RSVP/7] 00:03:10, metric 2, metric2 0> to 192.168.1.2 via fxp0.0, label-switched-path test_path
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
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
10.1.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
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.
8/3/2019 Resolving Routes for MPLS Traffic Engineering
30/37
Resolving Routes for MPLS Traffic Engineering
30 Copyright 2000, Juniper Networks, Inc.
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 {
192.168.254.2 strict;}interface all;
}
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
8/3/2019 Resolving Routes for MPLS Traffic Engineering
31/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 31
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;
}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 {
area 0.0.0.0 {interface all;
}}
8/3/2019 Resolving Routes for MPLS Traffic Engineering
32/37
Resolving Routes for MPLS Traffic Engineering
32 Copyright 2000, Juniper Networks, Inc.
RTR2
routing-options {autonomous-system 65501;
}
protocols {rsvp {
interface all;}mpls {
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 {
area 0.0.0.0 {interface all;
}}
8/3/2019 Resolving Routes for MPLS Traffic Engineering
33/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 33
RTR3
routing-options {autonomous-system 65501;
}
protocols {rsvp {
interface all;}mpls {
interface all;}bgp {
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 {
area 0.0.0.0 {interface all;
}}
8/3/2019 Resolving Routes for MPLS Traffic Engineering
34/37
Resolving Routes for MPLS Traffic Engineering
34 Copyright 2000, Juniper Networks, Inc.
RTR4
routing-options {autonomous-system 65501;
}
protocols {rsvp {
interface fxp0.0;interface fxp4.0;
}mpls {
interface fxp0.0;interface fxp4.0;
}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 {
type external;peer-as 65520;neighbor 172.16.1.2;
}}ospf {
area 0.0.0.0 {interface fxp0.0;interface fxp2.0;
interface fxp3.0;interface fxp4.0;
}}
8/3/2019 Resolving Routes for MPLS Traffic Engineering
35/37
Resolving Routes for MPLS Traffic Engineering
Copyright 2000, Juniper Networks, Inc. 35
RTR5
protocols {rsvp {
interface all;
}mpls {
interface all;}bgp {
group internal-peers {type internal;local-address 192.168.254.5;neighbor 192.168.254.1;neighbor 192.168.254.2;neighbor 192.168.254.3;neighbor 192.168.254.4;
}}
ospf {area 0.0.0.0 {
interface all;}
}
RTR6
protocols {ospf {
area 0.0.0.0 {interface all;
}
}
8/3/2019 Resolving Routes for MPLS Traffic Engineering
36/37
Resolving Routes for MPLS Traffic Engineering
36 Copyright 2000, Juniper Networks, Inc.
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;
}}
8/3/2019 Resolving Routes for MPLS Traffic Engineering
37/37
Resolving Routes for MPLS Traffic Engineering
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