Resolving Routes For MPLS Traffic Engineering

White Paper
Resolving Routes for MPLS Traffic Engineering
Jeff Doyle Professional 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
Contents
Executive Summary ............................................................................................................................ 3 Demonstration Network Overview .................................................................................................. 4 Routing Information Databases......................................................................................................... 7 Using traffic-engineering bgp.......................................................................................................... 11 Using IGP Shortcuts.......................................................................................................................... 16 Using traffic-engineering bgp-igp................................................................................................... 22 Installing Single Prefixes .................................................................................................................. 28 Appendix A........................................................................................................................................ 31 RTR1........................................................................................................................................... 31 RTR2........................................................................................................................................... 32 RTR3........................................................................................................................................... 33 RTR4........................................................................................................................................... 34 RTR5........................................................................................................................................... 35 RTR6........................................................................................................................................... 35 RTR7........................................................................................................................................... 36 Acronyms ........................................................................................................................................... 37
List of Figures
Figure 1: Figure 2: Figure 3: Figure 4: Figure 5: Figure 6: Demonstration Network Physical and Logical Topology ................................................4 Demonstration Network BGP Topology ............................................................................5 Demonstration Network LSP Topology .............................................................................6 By Default, BGP Uses Both inet.0 and inet.3 ....................................................................11 IGP Shortcuts Allow the IGP to Install Prefixes in inet.3 ...............................................18 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
Copyright 2000, Juniper Networks, Inc.
Executive Summary
Multiprotocol Label Switching (MPLS) traffic engineering maps certain data flows to established 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 what traffic is to be mapped to an LSP. Traffic is mapped to an LSP at the tunnel's ingress label switching router (LSR) by designating the 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 is a next-hop segment of the route. Therefore, packets can only be mapped to an LSP if the egress 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-line interface.
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 are presented in subsequent sections. Figure 1 shows the routers, router names, physical connections, and IP addresses used in the network. 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 for IBGP and LSP connections, where appropriate. Figure 1: Demonstration Network Physical and Logical Topology
Prefixes 10.1.0.0/16 10.2.0.0/16
RTR7 Lo0: 192.168.254.1
172.16.1.2
AS 65520
RTR1 Lo0: 192.168.254.1 192.168.2.1 192.168.2.2 192.168.1.1
RTR5 Lo0: 192.168.254.5
172.16.1.1
RTR4 Lo0: 192.168.254.4 192.168.6.1 192.168.6.2 192.168.9/24
192.168.7/24 192.168.8/24 RTR6 Lo0: 192.168.254.6
192.168.4.1 192.168.4.2 192.168.5.2
192.168.1.2 192.168.3.1 RTR2 Lo0: 192.168.254.2
192.168.5.1 192.168.3.2 RTR3 Lo0: 192.168.254.3
AS 65501
The IGP used in AS 65501 is OSPF, and all internal interfaces are in area 0. The external interface 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. No BGP 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
RTR7 Lo0: 192.168.254.1
RTR5 Lo0: 192.168.254.5
EBGP
RTR1 Lo0: 192.168.254.1
RTR4 Lo0: 192.168.254.4 Full IBGP Mesh
RTR6 Lo0: 192.168.254.6 No BGP RTR2 Lo0: 192.168.254.2 RTR3 Lo0: 192.168.254.3
A single LSP, named test_path, is configured from RTR1 to RTR4, as depicted in Figure 3. The LSP 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 signaled using RSVP, but no CSPF is running. Figure 3: Demonstration Network LSP Topology
RTR7 Lo0: 192.168.254.1
AS 65520
RTR1 Lo0: 192.168.254.1
RTR5 Lo0: 192.168.254.5
RTR4 Lo0: 192.168.254.4
RTR6 Lo0: 192.168.254.6
Ingress
Egress
LSP test_path
RTR2 Lo0: 192.168.254.2
RTR3 Lo0: 192.168.254.3
AS 65501
Refer to Appendix A for the base routing options, policy, and protocol configurations for all seven routers.
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 routing tables 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 Type Unicast routing table MPLS routing table Description All unicast protocols enter their route information into this table. RSVP enters destinations reachable via LSPs into this table; these destination prefixes are always the IP addresses of LSP egress points. MPLS enters label bindings into this table, and uses the information to switch incoming MPLS-labeled packets to outgoing interfaces.
Routing Table inet.0 inet.3
mpls.0
MPLS switching table
With the default configurations listed in Appendix A running, RTR1's three routing tables are as follows. jeff@RTR1> show route inet.0: 20 destinations, 20 routes (18 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.0/24 *[Direct/0] 17:34:14 > via fxp0.0 192.168.1.1/32 *[Local/0] 17:34:14 Local 192.168.2.0/24 *[Direct/0] 17:34:14 > via fxp1.0 192.168.2.1/32 *[Local/0] 17:34:14 Local 192.168.3.0/24 *[OSPF/10] 17:33:27, metric 2 > to 192.168.1.2 via fxp0.0 192.168.4.0/24 *[OSPF/10] 17:33:22, metric 2 > to 192.168.2.2 via fxp1.0 192.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 1 *[MPLS/0] 17:34:14, metric 1 Receive *[MPLS/0] 17:34:14, metric 1 Receive
The first table displayed is inet.0, which contains 18 active prefixes. The table here shows that with 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 is 192.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 an LSP endpoint and a router alert, respectively. No other labels are entered into mpls.0 because RTR1 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 1 100004 *[MPLS/0] 20:12:23, metric 1 Receive *[MPLS/0] 20:12:23, metric 1 Receive *[RSVP/7] 18:07:14, metric 1 > to 192.168.3.2 via fxp1.0, label-switched-path test_path
This table shows that incoming MPLS packets with a label of 100004 are switched to interface fxp1, 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 brief Ingress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 192.168.254.4 192.168.254.1 Up 0 1 FF 100004 test_path Total 1 displayed, Up 1, Down 0 Egress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0
jeff@RTR2> show rsvp session brief Ingress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 192.168.254.4 192.168.254.1 Up 1 1 FF 100004 100004 test_path Total 1 displayed, Up 1, Down 0 jeff@RTR3> show rsvp session brief Ingress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 192.168.254.4 192.168.254.1 Up 1 1 FF 100004 3 test_path Total 1 displayed, Up 1, Down 0 jeff@RTR4> show rsvp session brief Ingress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress RSVP: 1 sessions To From State Rt Style Labelin Labelout LSPname 192.168.254.4 192.168.254.1 Up 0 1 FF 3 - test_path Total 1 displayed, Up 1, Down 0 Transit RSVP: 0 sessions Total 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 an outgoing label of 100004. Although these two labels are numerically the same, label swapping still 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.
10
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 configuration stanzas. 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 routing protocols consult only inet.0. The significance of this behavior is not with the resolution of destination 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
IGP
BGP
RSVP
inet .0
inet .3
IP Forwarding Table
11
Figure 1 shows that there are two prefixes in AS 65520 that are being advertised to AS 65501 via 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 the routing 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 detail inet.0: 20 destinations, 20 routes (18 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 10.1.0.0/16 (1 entry, 0 announced) BGP Preference: 170/-101 Next hop type: Unusable State: <Hidden Int Ext> Local AS: 65501 Peer AS: 65501 Age: 21 Metric2: 0 Task: BGP_65501.192.168.254.4+1037 AS path: 65520 I BGP next hop: 172.16.1.2 Localpref: 100 Router ID: 192.168.254.4 10.2.0.0/16 (1 entry, 0 announced) BGP Preference: 170/-101 Next hop type: Unusable State: <Hidden Int Ext> Local AS: 65501 Peer AS: 65501 Age: 21 Metric2: 0 Task: BGP_65501.192.168.254.4+1037 AS path: 65520 I BGP next hop: 172.16.1.2 Localpref: 100 Router ID: 192.168.254.4
The two routes are being received from RTR4 (192.168.254.4) via IBGP, but they are not being installed 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-hop attribute 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 external interface, 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 the previous section shows that there are no entries to which 172.16.1.2 match. Therefore, the routes are declared unusable.
12
To alleviate the situation and make the routes usable, RTR4 is configured with a policy that overrides 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 path 10.1.0.0/16 192.168.254.4 100 65520 I 10.2.0.0/16 192.168.254.4 100 65520 I
13
The next-hop address was changed to RTR4's router ID, 192.168.254.4. At this point, the traffic engineering 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 to 192.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 route preference associated with the OSPF route is 10, while the route preference associated with the RSVP 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_path *[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
10.2.0.0/16
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 autonomous systems. LSPs are built in such a way that their endpoints are at BGP edge routers, and their egress addresses are the router IDs of the edge routers. The edge routers then change the nexthop addresses of routes learned from EBGP peers to their own router ID. As a result, routes can be resolved using the LSPs to those router IDs.
14
You can gain further understanding of the relationship of the IGPs and BGP to inet.0 and inet.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/16 Internet: Destination Type RtRef Nexthop Type Index NhRef Netif 10.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; in this 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 ingress LSR). The forwarding entry for 192.168.254.4 is as follows.
jeff@RTR1> show route forwarding-table destination 192.168.254.4 Internet: Destination Type RtRef Nexthop Type Index NhRef Netif 192.168.254.4/32 user 1 192.168.2.2 ucst 25 12 fxp1.0
Notice that the forwarding next hop for 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 has determined 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 packets 1 192.168.1.2 (192.168.1.2) 0.426 ms 0.237 ms 0.180 ms MPLS 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 ms MPLS 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 ms 4 * * * ^C jeff@RTR1> traceroute 192.168.254.4 traceroute 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 ms 2 192.168.254.4 (192.168.254.4) 0.339 ms 0.270 ms 0.267 ms
15
The first trace is to a destination belonging to the 10.1.0.0/16 prefix, and follows the LSP. The second 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.3 and 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 that destination in inet.0: the OSPF route.
Using IGP Shortcuts

Not everyone uses the next-hop self approach to solve the EBGP next-hop problem. Some prefer 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 the next-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 address of the BGP routes is not the router ID of any egress LSR. Therefore, traffic is only mapped to IGP 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 using passive 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; } } }
16
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-hop route 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 the AS 65520 prefixes is then installed in inet.0 using the OSPF path to the next hop. jeff@RTR1> show route 10/8 detail inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.1.0.0/16 (1 entry, 1 announced) *BGP Preference: 170/-101 Source: 192.168.254.4 Nexthop: 192.168.2.2 via fxp1.0, selected State: <Active Int Ext> Local AS: 65501 Peer AS: 65501 Age: 31 Metric2: 3 Task: BGP_65501.192.168.254.4+1037 Announcement bits (2): 2-KRT 4-BGP_Sync_Any AS path: 65520 I BGP next hop: 172.16.1.2 Localpref: 100 Router ID: 192.168.254.4 10.2.0.0/16 (1 entry, 1 announced) *BGP Preference: 170/-101 Source: 192.168.254.4 Nexthop: 192.168.2.2 via fxp1.0, selected State: <Active Int Ext> Local AS: 65501 Peer AS: 65501 Age: 31 Metric2: 3 Task: BGP_65501.192.168.254.4+1037 Announcement bits (2): 2-KRT 4-BGP_Sync_Any AS path: 65520 I BGP next hop: 172.16.1.2 Localpref: 100 Router 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 SPF calculations, 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.
17
It is only necessary to enable IGP shortcuts on the ingress router because that is the router performing 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 downstream of 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 making entries 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 the inet.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
IGP
BGP
RSVP
inet .0
inet .3
IP Forwarding Table
18
RTR1's routing tables, after IGP shortcuts are enabled, 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_path *[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 *[OSPF/10] 00:51:39, metric 3 > to 192.168.2.2 via fxp1.0 *[Direct/0] 1d 15:19:11 > via fxp0.0 *[Local/0] 1d 15:19:11 Local *[Direct/0] 1d 15:19:11 > via fxp1.0 *[Local/0] 1d 15:19:11 Local *[OSPF/10] 00:51:39, metric 2 > to 192.168.1.2 via fxp0.0 *[OSPF/10] 00:51:39, metric 2 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 00:51:39, metric 3 to 192.168.1.2 via fxp0.0 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 00:51:39, metric 3 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 00:51:39, metric 13 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 00:51:39, metric 13 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 00:51:39, metric 12 > to 192.168.2.2 via fxp1.0 *[Direct/0] 1d 15:19:11 > via lo0.0 *[OSPF/10] 00:51:39, metric 1 > to 192.168.1.2 via fxp0.0 *[OSPF/10] 00:51:39, metric 2 > to 192.168.1.2 via fxp0.0 *[OSPF/10] 00:51:39, metric 2 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 00:51:39, metric 1 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 00:51:39, metric 3 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 1d 15:19:12, metric 1
10.2.0.0/16
172.16.1.0/30 192.168.1.0/24 192.168.1.1/32 192.168.2.0/24 192.168.2.1/32 192.168.3.0/24 192.168.4.0/24 192.168.5.0/24
192.168.6.0/24 192.168.7.0/24 192.168.8.0/24 192.168.9.0/24 192.168.254.1/32 192.168.254.2/32 192.168.254.3/32 192.168.254.4/32 192.168.254.5/32 192.168.254.6/32 224.0.0.5/32
19
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 192.168.5.0/24 *[OSPF/10] 00:51:39, metric 3 > to 192.168.1.2 via fxp0.0, label-switched-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_path 192.168.7.0/24 *[OSPF/10] 00:51:39, metric 13 > to 192.168.1.2 via fxp0.0, label-switched-path 192.168.8.0/24 *[OSPF/10] 00:51:39, metric 13 > to 192.168.1.2 via fxp0.0, label-switched-path 192.168.9.0/24 *[OSPF/10] 00:51:39, metric 12 > to 192.168.1.2 via fxp0.0, label-switched-path 192.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 [OSPF/10] 00:51:39, metric 2 > to 192.168.1.2 via fxp0.0, label-switched-path 192.168.254.6/32 *[OSPF/10] 00:51:39, metric 3 > to 192.168.1.2 via fxp0.0, label-switched-path mpls.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0 1 *[MPLS/0] 1d 15:19:11, metric 1 Receive *[MPLS/0] 1d 15:19:11, metric 1 Receive In the inet.3 table, routes were entered by both RSVP and by OSPF. Compare the OSPF routes to the addresses shown in Figure 1, and you can see that the routes are to subnets within the OSPF 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 the normal 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 be downstream 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 to that 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 RSVP paths with a preference of 7 over the OSPF paths with a preference of 10. However, in this case, 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 when BGP 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 system IDs. 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 these addresses do not represent nodes.
test_path test_path
test_path test_path test_path test_path test_path test_path
20
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, selected label-switched-path test_path State: <Active Int Ext> Local AS: 65501 Peer AS: 65501 Age: 1:45:17 Metric2: 3 Task: BGP_65501.192.168.254.4+1037 Announcement bits (2): 2-KRT 4-BGP_Sync_Any AS path: 65520 I BGP next hop: 172.16.1.2 Localpref: 100 Router ID: 192.168.254.4 10.2.0.0/16 (1 entry, 1 announced) *BGP Preference: 170/-101 Source: 192.168.254.4 Nexthop: 192.168.1.2 via fxp0.0, selected label-switched-path test_path State: <Active Int Ext> Local AS: 65501 Peer AS: 65501 Age: 1:45:17 Metric2: 3 Task: BGP_65501.192.168.254.4+1037 Announcement bits (2): 2-KRT 4-BGP_Sync_Any AS path: 65520 I BGP next hop: 172.16.1.2 Localpref: 100 Router ID: 192.168.254.4 The true usefulness of IGP shortcuts becomes apparent not when an LSP is used to reach a single 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 peering routers 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 even to 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.
21
Using traffic-engineering bgp-igp

Both traffic-engineering bgp and IGP shortcuts, as presented so far, are used for BGP route resolution only. However, traffic to AS-internal destinations can also be mapped to LSPs. When traffic-engineering bgp-igp is enabled, RSVP installs the MPLS prefixes into the inet.0 table rather than the inet.3 table (Figure 6). As a result, the MPLS LSPs are now installed in the forwarding table. Figure 6: The traffic-engineering bgp-igp Command Causes RSVP to Install Prefixes into inet.0
IGP
BGP
RSVP
inet 0
IP Forwarding Table
22
The traffic-engineering bgp-igp command is configured under the MPLS section of the JUNOS configuration. In the first example, RTR1 is configured to run trafficengineering 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; } } }
23
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.0 *[BGP/170] 00:02:01, localpref 100, from 192.168.254.4 AS path: 65520 I > to 192.168.2.2 via fxp1.0 *[OSPF/10] 00:20:26, metric 3 > to 192.168.2.2 via fxp1.0 *[Direct/0] 1d 23:57:14 > via fxp0.0 *[Local/0] 1d 23:57:14 Local *[Direct/0] 1d 23:57:14 > via fxp1.0 *[Local/0] 1d 23:57:14 Local *[OSPF/10] 00:20:26, metric 2 > to 192.168.1.2 via fxp0.0 *[OSPF/10] 00:20:26, metric 2 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 00:20:26, metric 3 to 192.168.1.2 via fxp0.0 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 00:20:26, metric 3 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 00:20:26, metric 13 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 00:20:26, metric 13 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 00:20:26, metric 12 > to 192.168.2.2 via fxp1.0 *[Direct/0] 1d 23:57:14 > via lo0.0 *[OSPF/10] 00:20:26, metric 1 > to 192.168.1.2 via fxp0.0 *[OSPF/10] 00:20:26, metric 2 > to 192.168.1.2 via fxp0.0 *[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.0 *[OSPF/10] 00:20:26, metric 1 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 00:20:26, metric 3 > to 192.168.2.2 via fxp1.0 *[OSPF/10] 1d 23:57:15, metric 1
10.2.0.0/16
172.16.1.0/30 192.168.1.0/24 192.168.1.1/32 192.168.2.0/24 192.168.2.1/32 192.168.3.0/24 192.168.4.0/24 192.168.5.0/24
192.168.6.0/24 192.168.7.0/24 192.168.8.0/24 192.168.9.0/24 192.168.254.1/32 192.168.254.2/32 192.168.254.3/32 192.168.254.4/32
192.168.254.5/32 192.168.254.6/32 224.0.0.5/32
24
mpls.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0 *[MPLS/0] 1d 23:57:14, metric 1 Receive 1 *[MPLS/0] 1d 23:57:14, metric 1 Receive jeff@RTR1> show route forwarding-table Internet: Destination default 10.1.0.0/16 10.2.0.0/16 172.16.1.0/30 192.168.1.0/24 192.168.1.0/32 192.168.1.1/32 192.168.1.1/32 192.168.1.2/32 192.168.1.255/32 192.168.2.0/24 192.168.2.0/32 192.168.2.1/32 192.168.2.1/32 192.168.2.2/32 192.168.2.255/32 192.168.3.0/24 192.168.4.0/24 192.168.5.0/24 192.168.6.0/24 192.168.7.0/24 192.168.8.0/24 192.168.9.0/24 192.168.254.1/32 192.168.254.2/32 192.168.254.3/32 192.168.254.4/32 192.168.254.5/32 192.168.254.6/32 224.0.0.0/4 224.0.0.1/32 224.0.0.5/32 255.255.255.255/32 MPLS: Interface.Label default 0 1
Type RtRef Nexthop perm 0 user 0 192.168.2.2 user 0 192.168.2.2 user 0 192.168.2.2 intf 0 dest 0 192.168.1.0 intf 0 192.168.1.1 dest 0 192.168.1.1 dest 0 0:90:27:c2:8a:a3 dest 0 192.168.1.255 intf 0 dest 0 192.168.2.0 intf 0 192.168.2.1 dest 0 192.168.2.1 dest 0 0:d0:b7:75:ff:31 dest 0 192.168.2.255 user 0 192.168.1.2 user 0 192.168.2.2 user 0 192.168.2.2 user 0 192.168.2.2 user 0 192.168.2.2 user 0 192.168.2.2 user 0 192.168.2.2 intf 0 192.168.254.1 user 1 192.168.1.2 user 1 192.168.1.2 user 1 192.168.1.2 user 1 192.168.2.2 user 0 192.168.2.2 perm 1 perm 0 224.0.0.1 user 1 224.0.0.5 perm 0
Type Index NhRef Netif rjct 9 1 ucst 25 13 fxp1.0 ucst 25 13 fxp1.0 ucst 25 13 fxp1.0 rslv 14 1 fxp0.0 recv 12 1 fxp0.0 locl 13 2 locl 13 2 ucst 24 7 fxp0.0 bcst 11 1 fxp0.0 rslv 18 1 fxp1.0 recv 16 1 fxp1.0 locl 17 2 locl 17 2 ucst 25 13 fxp1.0 bcst 15 1 fxp1.0 ucst 24 7 fxp0.0 ucst 25 13 fxp1.0 ucst 25 13 fxp1.0 ucst 25 13 fxp1.0 ucst 25 13 fxp1.0 ucst 25 13 fxp1.0 ucst 25 13 fxp1.0 locl 21 1 ucst 24 7 fxp0.0 ucst 24 7 fxp0.0 Push 100004 fxp0.0 ucst 25 13 fxp1.0 ucst 25 13 fxp1.0 mdsc 8 1 mcst 4 3 mcst 4 3 bcst 5 1
Type RtRef Nexthop perm 0 user 0 user 0
Type Index NhRef Netif dscd 1 1 recv 3 2 recv 3 2
Notice that the LSP to 192.168.254.4 was installed in the inet.0 table, along with the OSPF route to 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 also that there is no inet.3 table.
25
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 is as 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; } } }
26
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_path 10.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:15 Local 192.168.2.0/24 *[Direct/0] 2d 00:23:15 > via fxp1.0 192.168.2.1/32 *[Local/0] 2d 00:23:15 Local 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 1 mpls.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0 *[MPLS/0] 2d 00:23:15, metric 1 Receive 1 *[MPLS/0] 2d 00:23:15, metric 1 Receive
27
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 also uses the LSP in its two routes. If next-hop self were 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 the LSPs. 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 are never forwarded over LSPs, preventing the possibility of an LSP being inadvertently built within 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 be mapped 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 trafficengineering bgp-igp, nor IGP shortcuts are running on RTR1; RTR4 is not running OSPF 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-database 10.1.0.0/16 Source: 192.168.254.4 Next hop not resolved 10.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 next hop, prefix 172.16.1.0/30 is manually associated with LSP and installed in inet.3 at RTR1.
28
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 192.168.254.4/32 *[RSVP/7] 00:03:10, metric 2, > to 192.168.1.2 via fxp0.0, *[RSVP/7] 00:03:10, metric 2, > to 192.168.1.2 via fxp0.0, metric2 0 label-switched-path test_path metric2 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 the next-hop address 172.16.1.2, and install the routes to the external prefixes in inet.0. jeff@RTR1> show bgp next-hop-database 10.1.0.0/16 Source: 192.168.254.4 Nexthop: 172.16.1.0 172.16.1.0/30 MED 2 Next hop 192.168.1.2 Push 10.2.0.0/16 Source: 192.168.254.4 Nexthop: 172.16.1.0 172.16.1.0/30 MED 2 Next hop 192.168.1.2 Push 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 *[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 be installed in inet.0 for intra-AS routing. This mapping is accomplished by appending the active keyword to the install statement. 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's configuration changes to the following.
100004,
100004,
10.2.0.0/16
29
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.0 inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.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
30
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 document when 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; } }
31
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; } }
32
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; } }
33
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; } }
34
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; } }
35
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; } }
36
Acronyms
AS BGP CSPF EBGP ERO IGP IS-IS LSP LSR MPLS OSPF POP RSVP SPF Autonomous system Border Gateway Protocol Constrained Shortest Path First External Border Gateway Protocol Explicit Route Object Interior Gateway Protocol Intermediate System to Intermediate System Label switched path Label switching router Multiprotocol Label Switching Open Shortest Path First Point of presence Resource Reservation Protocol 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.
37

Resolving Routes For MPLS Traffic Engineering

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Resolving Routes For MPLS Traffic Engineering

Încărcat de

Drepturi de autor:

Formate disponibile

White Paper

Resolving Routes for MPLS Traffic Engineering

Jeff Doyle Professional Services Engineer

Copyright 2000, Juniper Networks, Inc.

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

Demonstration Network Overview

Prefixes 10.1.0.0/16 10.2.0.0/16

RTR7 Lo0: 192.168.254.1

RTR1 Lo0: 192.168.254.1 192.168.2.1 192.168.2.2 192.168.1.1

RTR5 Lo0: 192.168.254.5

RTR4 Lo0: 192.168.254.4 192.168.6.1 192.168.6.2 192.168.9/24

192.168.7/24 192.168.8/24 RTR6 Lo0: 192.168.254.6

192.168.4.1 192.168.4.2 192.168.5.2

192.168.1.2 192.168.3.1 RTR2 Lo0: 192.168.254.2

192.168.5.1 192.168.3.2 RTR3 Lo0: 192.168.254.3

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

RTR7 Lo0: 192.168.254.1

RTR5 Lo0: 192.168.254.5

RTR1 Lo0: 192.168.254.1

RTR4 Lo0: 192.168.254.4 Full IBGP Mesh

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

RTR7 Lo0: 192.168.254.1

RTR1 Lo0: 192.168.254.1

RTR5 Lo0: 192.168.254.5

RTR4 Lo0: 192.168.254.4

RTR6 Lo0: 192.168.254.6

RTR2 Lo0: 192.168.254.2

RTR3 Lo0: 192.168.254.3

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

Routing Information Databases

Routing Table inet.0 inet.3

MPLS switching table

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

Using traffic-engineering bgp

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

Using IGP Shortcuts

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

Copyright 2000, Juniper Networks, Inc.

Resolving Routes for MPLS Traffic Engineering

172.16.1.0/30 192.168.1.0/24 192.168.1.1/32 192.168.2.0/24 192.168.2.1/32 192.168.3.0/24 192.168.4.0/24 192.168.5.0/24